0x00 Предисловие

1. Тема статьи

В этой статье в основном объясняется важная часть хранилища данных:Как спроектировать иерархию данных!Другие материалы о хранилище данных можно найти в предыдущей статье.

Обсуждение многоуровневого хранения данных в этой статье подходит для некоторых из следующих сценариев, выходящих за рамки сценариев.orОпытные боги хранилища данных не должны тратить время на просмотр.

Создание данных только началось, и большая часть данных непосредственно состыковывается сразу после доступа к необработанным данным.
Когда построение данных доходит до определенного этапа, обнаруживается, что использование данных неорганизованно, и различные предприятия напрямую рассчитываются из исходных данных.
Различные повторяющиеся вычисления серьезно расходуют вычислительные ресурсы, а производительность необходимо оптимизировать.

Структура статьи

Сначала я столкнулся со многими подводными камнями, когда работал над хранилищем данных.Из-за моих ограниченных ресурсов, когда я столкнулся с хранилищем данных, я почувствовал, что в интернет-индустрии очень мало успешного опыта работы с хранилищами данных, и в Интернете было трудно найти практические материалы. А те немногие классические книги слишком теоретические, и действительно лучше жить, чем умереть. К счастью, сейчас это препятствие пройдено, поэтому я трачу больше времени на то, чтобы разобраться в своих мыслях, и помогаю другим друзьям меньше наступать на ямы. Структура статьи следующая:

Зачем стратифицировать? Этот вопрос задавали несколько студентов. Таким образом, значение стратификации должно быть разъяснено.
Поделитесь классической моделью многоуровневого хранения данных, а также ролью каждого слоя данных и способами его обработки.
Поделитесь дизайном двух слоев данных и используйте эти два практических примера, чтобы проиллюстрировать, как хранить данные в каждом слое.
Дайте несколько предложений, не лучших, но для справки.

0x01 Почему многослойность

Одной из основных причин многоуровневого хранения данных является более четкий контроль над данными при управлении данными. В частности, существуют следующие причины:

Четкая структура данных: каждый уровень данных имеет свою область действия, чтобы нам было легче находить и понимать при использовании таблиц.
ДАННЫЕ BLOODLINE TRASSING: в простых условиях его можно понять таким образом. То, что мы наконец-то дам целостность бизнеса, является бизнес-таблицей, который можно использовать напрямую, но есть много источников. Если есть проблема с источником Таблица, мы надеемся, что сможете быстро и точно найти ее. На проблему и понять объем его вреда.
Сокращение повторяющейся разработки: стандартизируйте стратификацию данных и разработайте некоторые общие данные среднего уровня, что может значительно сократить повторяющиеся вычисления.
Упрощайте сложные проблемы. Относительно просто и легко понять, что сложная задача разбивается на несколько шагов для выполнения, и каждый уровень обрабатывает только один шаг. И легко поддерживать точность данных.Когда есть проблема с данными, вы не можете восстановить все данные, а нужно только начать восстановление с проблемных шагов.
Исключения маски для необработанных данных.
Чтобы скрыть влияние службы, вам необходимо повторно получить доступ к данным, не изменяя службу один раз.

Зависимость каждой таблицы в системе данных подобна потоку проводов.Мы все надеемся, что она регулярна, понятна и проста в управлении, как показано на следующем рисунке:

Однако большая часть итоговых результатов зависит от сложных зависимостей и хаотичных уровней, поэтому разобраться в утверждениях таблицы, как показано на следующем рисунке, будет сложно:

0x02 Как наслаивать

1. Теория

Теоретически мы делаем абстракцию, и хранилище данных можно разделить на следующие три уровня, а именно: уровень операций с данными, уровень хранилища данных и уровень продукта данных.

1. Полное название ODS — Operational Data Store.

«Предметно-ориентированный» уровень обработки данных, также известный как уровень ODS, является уровнем, наиболее близким к данным в источнике данных.После извлечения, очистки и передачи данных в источнике данных, то есть легендарного ETL, он устанавливается в этот слой. Данные этого уровня обычно классифицируются в соответствии с методом классификации исходной бизнес-системы.

Однако данные на этом уровне не эквивалентны исходным данным. Когда исходные данные загружаются в этот слой, такие действия, какустранение шума(Например, есть часть данных, где возраст человека составляет 300 лет, что является аномальными данными и требует предварительной обработки),дедупликация(Например, в таблице личных данных есть два дубликата данных для одного и того же ID, которые нужно дедуплицировать в один шаг при доступе), поляСоглашения об именахДождитесь серии операций.

2. Уровень хранилища данных (DW) — это основная часть хранилища данных.

Здесь данные, полученные от уровня ODS, строят различные модели данных по предметам. Этот слой будет иметь более глубокую связь с многомерным моделированием, вы можете обратиться к предыдущим статьям.

3. Уровень продукта данных (APP), этот уровень предназначен для предоставления данных результатов, используемых для продукта данных.

Здесь данные, в основном предоставляемые для информационных продуктов и анализа данных, обычно хранятся в ES, Mysql и других системах для онлайн-систем, а также могут храниться в Hive или Druid для анализа данных и интеллектуального анализа данных. Например, данные отчета, о которых мы часто говорим, или своего рода большая широкая таблица обычно размещаются здесь.

2. Техническая практика

Эти три технических подразделения относительно крупнозернисты, и мы разделим их позже. Перед этим давайте поговорим о том, как обычно передаются данные каждого слоя. Вот лишь краткое введение в несколько часто используемых инструментов с акцентом на основное направление индустрии открытого исходного кода.

1. Уровень источника данных → уровень ODS

На самом деле это крупное поле битвы, где наша технология больших данных играет свою роль. Есть два основных источника наших данных:

Для бизнес-библиотек часто используется Sqoop для извлечения, например, мы регулярно извлекаем один раз в день. Что касается режима реального времени, вы можете рассмотреть возможность использования Canal для мониторинга Binlog Mysql, и вы можете получить к нему доступ в режиме реального времени.
Журналы скрытых точек, онлайн-система будет вводить различные журналы, эти журналы обычно сохраняются в виде файлов, мы можем использовать Flume для регулярного извлечения или использовать Spark Streaming или Storm для доступа в режиме реального времени, конечно, Kafka будет также играть ключевую роль.
Другие источники данных будут более разнообразными, что связано с конкретным бизнесом и не будет здесь повторяться.

Уведомление:На этом уровне это не должен быть простой доступ к данным, но следует учитывать определенный объем очистки данных, например, обработку аномальных полей, нормализацию имен полей, унификацию полей времени и т. д. Как правило, это легко игнорируются, но они очень важны.Особенно, когда мы делаем автоматическую генерацию различных функций на более позднем этапе, это будет очень полезно. Позже будут статьи.

2. ODS, DW → Уровень приложения

Также есть два основных вида:

Тип ежедневной запланированной задачи: например, наша типичная ежедневная вычислительная задача, вычисление данных за предыдущий день рано утром каждый день и чтение отчета утром. Такого рода задачи часто рассчитываются с помощью Hive, Spark или необработанных программ MR, а окончательный результат записывается в Hive, Hbase, Mysql, Es или Redis.
Данные в реальном времени: эта часть в основном используется различными системами реального времени, такими как наши рекомендации в реальном времени и портреты пользователей в реальном времени.Как правило, мы будем использовать Spark Streaming, Storm или Flink для расчета и, наконец, попадем в Es , Hbase или Redis.

0x03 например

В интернете много примеров, поэтому я не буду их перечислять, приведу лишь пример стратификации данных, что автор участвовал в разработке в первые дни. Проанализируйте первоначальную идею и недостатки этой конструкции. Оригинальное изображение и содержание.

Первоначальный дизайн был разделен всего на 6 слоев, из которых после удаления метаданных осталось еще 5 слоев. Ниже приводится анализ оригинальной дизайнерской идеи.

буферный слой

Концепция: также известный как уровень интерфейса (стадия), он используется для хранения ежедневных добавочных данных и данных об изменениях, таких как журнал бизнес-изменений, полученный Canal.
Метод генерации данных: получать исходные данные непосредственно из kafka, требовать, чтобы бизнес-таблицы генерировали обновления, удаляли и вставляли данные каждый день, генерировали бизнес-таблицы только для вставки данных, а данные напрямую вводились в уровень детализации.
План обсуждения: Поместите журнал канала только непосредственно в буферный слой, если другие сервисы с данными застежки-молнии также войдут в буферный слой.
Метод хранения журнала: используйте внешний вид impala и формат файла parquet, чтобы облегчить чтение данных, которые должны быть обработаны MR.
Метод удаления журнала: долгосрочное хранение, могут быть сохранены только данные за последние несколько дней. План обсуждения: прямое долговременное хранение
Схема таблицы: обычно создавайте разделы по дням
Именование библиотек и таблиц. Имя библиотеки: буфер, имя таблицы: Предварительный формат рассмотрения: буферДатаИмя бизнес-таблицы, которое будет определено.

Детальный уровень (ODS, Operational Data Store, DWD: детали хранилища данных)

Концепция: это уровень подробных данных хранилища данных. Он осаждает данные уровня STAGE и снижает сложность извлечения. В то же время организация информационной модели ODS / DWD в основном соответствует форме обработки бизнес-транзакций предприятия. , и концентрирует различные профессиональные данные.Дробность слоя такая же, как и у слоя stage, который относится к общедоступным ресурсам анализа
Метод генерации данных: часть данных поступает напрямую из kafka, а часть данных синтезируется из данных интерфейсного слоя и исторических данных. Необходимо изучить способ синтеза данных каротажа каналов.
План обсуждения: метод синтеза данных канала следующий: каждый день полные данные предыдущего дня в слое деталей и новые данные вчера синтезируются в новую таблицу данных, покрывающую старую таблицу. Также используйте историческое зеркальное отображение для еженедельного/месячного/ежегодного хранения исторического зеркала в новой таблице.
Метод хранения журнала: Прямые данные используют внешний вид импалы, формат файла паркета, синтетические данные канала являются вторичными сгенерированными данными, рекомендуется использовать внутреннюю таблицу, следующие слои - это все данные, сгенерированные из импалы, рекомендуется использовать внутреннюю таблицу + static/ динамический раздел.
Метод удаления журнала: долговременное хранение.
Схема таблицы: обычно секции создаются по дням, а поля секции выбираются по конкретному бизнесу без учета времени.
Именование библиотек и таблиц. Имя библиотеки: ods, имя таблицы: Предварительный формат рассмотрения odsДатаИмя бизнес-таблицы, которое будет определено.
Старый метод обновления данных: прямая перезапись

Уровень легкой агрегации (MID или DWB, основа хранилища данных)

Концепция: переходный уровень между уровнем DWD и уровнем DM в хранилище данных уровня краткой сводки, который должен легко интегрировать и суммировать производственные данные уровня DWD (он может включать сложную очистку и обработку, например, генерацию на основе в журналах PV).данные сеанса). Основное различие между легким комплексным слоем и DWD заключается в том, что области их применения различны.Данные DWD поступают из производственной системы и не удовлетворяют некоторые непредвиденные потребности в осадках;легкий комплексный слой является мелкозернистым. для аналитических приложений Статистика и осадки
Метод генерации данных: легкая сводная таблица создается на уровне детализации в соответствии с определенными бизнес-требованиями. Данные, требующие сложной очистки в слое деталей, и данные, которые необходимо обработать MR, также обрабатываются и затем подключаются к слою легкой сводки.
Способ хранения журнала: внутренняя таблица, формат паркетного файла.
Метод удаления журнала: долговременное хранение.
Схема таблицы: обычно секции создаются по дням, а поля секции выбираются по конкретному бизнесу без учета времени.
Именование библиотек и таблиц. Имя библиотеки: dwb, имя таблицы: Формат предварительного рассмотрения: dwbДатаИмя бизнес-таблицы, которое будет определено.
Старый метод обновления данных: прямая перезапись

Предметный уровень (DM, рынок данных или DWS, служба хранилища данных)

Концепция: также известна как витрина данных или широкая таблица. В соответствии с бизнес-подразделением, таким как трафик, заказы, пользователи и т. д., создается широкая таблица с множеством полей для обеспечения последующих бизнес-запросов, анализа OLAP и распределения данных.
Метод генерации данных: он рассчитывается и генерируется на основе данных слоя легкой сводки и слоя деталей.
Метод хранения журнала: используйте внутреннюю таблицу impala, формат файла parquet.
Метод удаления журнала: долговременное хранение.
Схема таблицы: обычно секции создаются по дням, а поля секции выбираются по конкретному бизнесу без учета времени.
Именование библиотек и таблиц. Имя библиотеки: dm, имя таблицы: Предварительный формат рассмотрения: dmДатаИмя бизнес-таблицы, которое будет определено.
Старый метод обновления данных: прямая перезапись

Прикладной уровень (приложение)

Концепция: прикладной уровень основан на бизнес-потребностях, и результаты, полученные из первых трех уровней статистики данных, могут быть непосредственно предоставлены для отображения запроса или импортированы в Mysql для использования.
Метод генерации данных: генерируется слоем детализации, кратким сводным слоем и слоем витрины данных.Как правило, требуется, чтобы данные поступали в основном из слоя витрины.
Метод хранения журнала: используйте внутреннюю таблицу impala, формат файла parquet.
Метод удаления журнала: долговременное хранение.
Схема таблицы: обычно секции создаются по дням, а поля секции выбираются по конкретному бизнесу без учета времени.
Именование библиотек и таблиц. Имя библиотеки: Предварительно установлено Apl. Кроме того, в зависимости от бизнеса нет ограничений на библиотеку.
Старый метод обновления данных: прямая перезапись.

0x04 Как быть элегантнее

Упомянутый выше дизайн на самом деле относительно детализирован, но может быть немного больше слоев, и может быть много путаницы при различении, где должна храниться таблица. В этой главе мы разработаем набор уровней хранилища данных и добавим таблицы измерений и некоторые временные таблицы на предыдущей основе, чтобы сделать наше решение более элегантным.

На рисунке ниже с некоторыми незначительными изменениями мы удалили слой буфера в предыдущем разделе, поместили слой киоска данных и слой световой сводки на один и тот же слой, а также разделили таблицы измерений и временные таблицы.

Объясните здесь роль DWS, DWD, DIM и TMP.

DWS: уровень мягкой сводки, делает предварительную сводку поведения пользователя на уровне ODS, абстрагирует некоторые общие параметры: время, ip, идентификатор и создает некоторые статистические значения в соответствии с этими измерениями, например, время пользователя в каждый раз. период, количество товаров, купленных под разными логинами и т. д. Выполнение здесь слоя агрегации света сделает расчет более эффективным, на его основе будет гораздо быстрее рассчитывать поведение только 7 дней, 30 дней и 90 дней.Мы надеемся, что 80% бизнеса можно рассчитать с помощью нашего уровня DWS, а не ODS.
DWD: этот уровень в основном решает некоторые проблемы с качеством и целостностью данных. Например, информация о данных пользователя поступает из множества разных таблиц, и часто возникают такие проблемы, как задержка потери данных.Чтобы облегчить лучшее использование данных каждым пользователем, мы можем создать экран на этом уровне.
DIM: этот уровень относительно прост.Например, ясно, что такая информация, как код и название страны, географическое положение, китайское название, изображение национального флага и другая информация, хранится на уровне DIM.
TMP: будет много временных таблиц для расчета каждого слоя, а слой DWTMP специально разработан для хранения временных таблиц нашего хранилища данных.

0x05 Вопросы и ответы

Некоторые друзья задавали некоторые вопросы, некоторые из которых не были четко объяснены ранее, поэтому я добавлю их сюда.

Вопросы и ответы 1: Взаимосвязь между dws и dwd

В: Являются ли dws и dwd параллельными, а не последовательными? Ответ: Параллельно слой dw спрашивает: Фактически для одних и тех же данных эти два процесса являются последовательными? Ответ: dws будет делать сводку, dwd и ods имеют одинаковую степень детализации, и нет никакой зависимости между двумя слоями Q: Да, тогда сводка в dws не была обработана на предмет качества и целостности данных, или она делается отдельно. Это процесс, связанный с качеством, так почему бы не агрегировать его поверх dwd? На самом деле мой вопрос заключается в том, существует ли какая-либо обработка качества данных для слегка агрегированных результатов данных dws? Ответ: одс Просто зайдите прямо в dws, нет необходимости проходить через dwd, позвольте мне привести пример вашего поведения при просмотре, я сделаю небольшое резюме и помещу его прямо в dws. Однако ваш техпаспорт должен быть составлен из множества таблиц.Мы собрали полный техпаспорт из четырех-пяти паспортов и поместили его в dwd. Затем в слое приложения нам нужно создать портретную таблицу, включающую данные о пользователях и поведении пользователей за прошлый год, мы напрямую получаем данные из dwd, а затем делаем слой статистики на основе dws, который становится приложением. стол . Конечно, это не абсолютно, наличие зависимостей у dws и dwd в основном зависит от того, есть ли такое требование.

Q&A 2: Разница между ods и dwd

В: Я до сих пор не понимаю разницы между слоями ods и dwd После слоя ods я чувствую, что dwd бесполезен. Ответ:Ну я так понимаю.С идеальной точки зрения,если данные слоя ods очень регулярны и могут в принципе удовлетворить большинство наших потребностей,это конечно хорошо.На данный момент слой dwd на самом деле это не нужно. Однако в реальности сложно гарантировать качество данных на уровне ods, ведь источники данных разные, и у пушера тоже будет своя логика пуша, в этом случае нам нужно пройти дополнительный слой dwd. Маскировка некоторых низкоуровневых различий. В: Я, наверное, понимаю, не так ли? dwd в основном выполняет некоторые операции по очистке и нормализации данных на уровне ods, а dws в основном выполняет небольшое суммирование данных слоя ods? О: Да, примерно так это можно понять.

Q3: Что делает уровень приложения?

В: Считаете ли вы, что уровень витрины данных неуместен? Должна ли таблица витрины данных для каждого предприятия быть в DWD или в приложении? Ответ: На этот вопрос не так просто ответить. Я думаю, что главное - уточнить, что делает слой витрины данных. Если ваш слой витрины данных содержит некоторые широкие таблицы, которые могут использоваться бизнес-стороной, вы можете разместить его в приложении. слой. Если уровень витрины данных, о котором вы говорите, является более общей концепцией, то на самом деле dws, dwd и app — это все содержимое витрины данных. Вопрос. Считаются ли данные, хранящиеся в Redis и ES, уровнем приложения? Ответ: Да, мое личное понимание, приложение Уровень в основном хранит некоторые относительно зрелые таблицы, которые могут использоваться бизнес-стороной. Эти таблицы могут находиться в Hive или импортироваться из Hive в систему с более высокой производительностью запросов, например Redis или ES.

0xFF Сводка

Стратификация данных — очень важная часть хранилища данных, она не только определяет задачу одного уровня, но и напрямую влияет на построение ряда функций, таких как анализ кровного родства, автоматическая генерация признаков и управление метаданными. Поэтому он подходит для раннего рассмотрения.

Кроме того, вам не нужно слишком заботиться о названии каждого слоя, просто следуйте своим предпочтениям.

В этой статье представлены некоторые из собственных представлений и идей автора о хранилищах данных, которые не обязательно точны или универсальны, но могут использоваться в качестве справочной идеи. Если у вас есть какие-либо вопросы, пожалуйста, не стесняйтесь общаться.