(Исходный контент Ma Honeycomb Technology, общедоступный идентификатор: mfwtech)

1. Хранилище данных сотовой связи Ma и центр обработки данных

В последние годы популярность концепции промежуточной платформы данных не ослабевает. С 2018 года Mafengwo также начала собственное исследование данных на промежуточном этапе.

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

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

Таким образом, центр обработки данных — это скорее изменение управленческого мышления и структуры организации. В соответствии с этой идеей мы построили центр обработки данных Mafengwo на основе наших собственных бизнес-характеристик.Основная структура выглядит следующим образом:

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

2. Базовая архитектура хранилища данных

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

Как показано на рисунке, он разделен на 3 слоя:Уровень бизнес-данных, общедоступный уровень данных и уровень данных приложения, позиционирование, цели и принципы построения каждого слоя различны.

(1) Уровень бизнес-данных: Содержит два уровня STG (уровень буфера данных) и ODS (уровень операционных данных), структура данных этих двух уровней почти такая же, как у бизнес-данных.

STG: Также называемая областью подготовки данных, она предназначена для кэширования временных данных из извлечения БД, анализа сообщений и журналов, а ее структура соответствует бизнес-системе; она отвечает за очистку и преобразование ненужных и нерегулярных данных; этот уровень служит только уровень ODS;
ODS: Уровень операционных данных расположен в области резерва бизнес-деталей и отвечает за сохранение исторических данных об изменениях после точки времени доступа к данным.В принципе, все данные сохраняются. В конструкции модели используются две формы застежки-молнии и расходомера в соответствии с характеристиками изменения данных бизнес-таблицы.

(2) Уровень общедоступных данных: подразделяется на три уровня: DWD (уровень подробных данных), DWS (уровень сводных данных) и DIM (уровень общедоступных измерений), которые в основном используются для обработки и хранения интегрированных подробных данных бизнес-процессов, а также общедоступных измерений детализация после легкой или тяжелой агрегации данные индикатора. В качестве основного уровня хранилища уровень общедоступных данных позиционируется с точки зрения бизнеса, извлекая общий доступ к данным и статистические требования для хранилища данных, чтобы создавать общедоступные данные, ориентированные на поддержку приложений и предоставление общих услуг доступа к данным.

DWD: этот уровень представляет собой подробные данные интегрированного бизнес-процесса, отвечающего за вертикальную и горизонтальную интеграцию данных различных бизнес-сценариев, избыточную обработку общих общих измерений и обработку подробной информации о бизнес-метках;
DWS: Слой сводных данных немного и сильно агрегирует данные индикатора общего измерения в соответствии с темой;
DIM: Унифицированное и стандартизированное определение измерений для обеспечения обмена информацией об измерениях.

(3) Уровень данных приложения: уровень DWA, в основном используемый для персонализированной обработки данных каждого продукта или бизнес-направления, таких как данные о коммерческих продуктах, рекомендации по поиску, контроль рисков и т. д.

3. Дизайн модели данных

3.1 Выбор метода

Модель данных — это абстракция характеристик реальных данных, а метод проектирования модели данных — это метод индуцирования и обобщения данных. В настоящее время в отрасли существует две основные методологии проектирования моделей, одна из которых предложена Биллом Инмоном, отцом хранилища данных.Моделирование парадигмыМетод, также известный как ER-моделирование, пропагандирует построение модели данных с точки зрения предприятия сверху донизу; второй метод пропагандируется мастером Ральфом Кимбаллом.объемное моделированиеМетод выступает за построение модели данных снизу вверх от бизнес-требований.

В среде больших данных система данных бизнес-системы сложна, структура данных разнообразна, часто меняется и должна быстро реагировать на различные сложные бизнес-потребности.Вышеупомянутые две традиционные теории больше не могут удовлетворить потребности Интернета. хранилища данных. В этом контексте Mafengwo Data Warehouse применяет смешанный метод проектирования моделей, «управляемый спросом и управляемый данными», для выбора моделей в соответствии с различными уровнями данных. В основном это рассматривается в следующих четырех аспектах:

1. Тематическая ориентированность: Классифицируйте бизнес-данные, используя метод разделения тем в теории моделей парадигмы.

** 2. Гарантия согласованности: ** Используя идею структуры шины в теории моделей измерений, создайте единую таблицу измерений согласованности и таблицу фактов согласованности для обеспечения согласованности.

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

4. Гарантия эффективности: Разумно принимайте такие методы, как уменьшение размерности, изменение размерности и увеличение избыточности, чтобы обеспечить эффективность расчета данных и запросов.

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

Горизонтальная интеграция: Горизонтальная интеграция заключается в интеграции данных из нескольких источников данных одного и того же бизнеса в модель.Если есть пересечение бизнес-данных из нескольких источников данных, вам необходимо выбрать резервирование в соответствии с заданными бизнес-правилами, чтобы избежать пересечения интегрированные бизнес-данные. Например, если данные о продукте не управляются основными данными, информация о продуктах разных бизнес-направлений будет разбросана по различным таблицам бизнес-системы, что не может удовлетворить требования анализа данных на уровне предприятия. быть горизонтально интегрированы в соответствии с тематикой бизнеса.
Вертикальная интеграция: полный бизнес-поток обычно должен проходить по нескольким каналам, а информация о каждом узле создается в разное время и хранится в разных таблицах данных. Вертикальная интеграция заключается в интеграции информации каждого ключевого узла в одном и том же бизнесе в широкотабличную модель всего процесса бизнеса. Этот метод принят при построении модели транзакции заказа Mafengwo, которая будет подробно описана ниже.

3.2 Цели проектирования

Ma Honeycomb Data Warehouse нацелена на точность, простоту использования и своевременность проектирования моделей для удовлетворения разнообразных потребностей бизнес-персонала в данных.

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

3.3 Процесс проектирования

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

запрос исследования: собирать и понимать требования бизнес-стороны, достигать консенсуса в отношении калибра конкретных требований, проводить анализ на уровне полей таблицы после сортировки функций, выполняемых бизнес-системой или системными модулями, участвующими в требованиях, и проверять данные для обеспечения существующие данные могут удовлетворить потребности бизнеса.
дизайн модели: Предварительно классифицировать модели в соответствии с требованиями и результатами бизнес-исследований и выбрать соответствующие предметные области для хранения модели; после определения предмета перейти к этапу проектирования модели данных, а процесс проектирования логической модели должен учитывать такие ключевые вопросы, как построение структуры шины и определение спецификации модели; проектирование физической модели основано на логической модели с учетом таких факторов, как производительность хранилища. Процесс физического воплощения логической модели является окончательной физической реализацией логической модели. Физическая модель в целом соответствует логической После того, как проектирование модели завершено, необходимо войти в режим просмотра и сопоставления.
Разработка модели: это процесс реализации кода сценария расчета модели, включая сопоставление данных, реализацию сценария, проверку тестов и другие процессы разработки. После завершения модульного теста деловая сторона должна быть уведомлена о совместной проверке данных модели, сборе проблем проверки и возвращении для проверки рациональности дизайна модели.
Модель выходит в эфир: проверенную модель можно развернуть в производственной онлайн-среде. После выхода в интернет необходимо настроить мониторинг модели и быть в курсе состояния предоставления сервисов данных для бизнеса. Мы также публикуем документы с описанием сущностей и атрибутов модели для потребителей данных хранилища, чтобы модель можно было лучше применять.

3.4 Тематическая классификация

На основе обзора существующих отделов и бизнес-систем Mafengwo Data Warehouse разработала в общей сложности 4 домена больших данных (транзакции, трафик, контент, участники), которые подразделяются на 11 тем:

Если взять в качестве примера построение модели транзакции заказа Mafengwo, проектирование, основанное на бизнес-производственной шине, является общей моделью, то есть сначала исследуется весь процесс транзакции заказа, находятся ключевые узлы в процессе и основная фактическая информация, которая происходит на каждом узле, подтверждается. Модель является носителем данных.Что нам нужно сделать, так это обобщить фактическую информацию о каждом узле в производственной шине через модель (или модельную систему).

Заказ автобуса производства:

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

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

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

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

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

В-четвертых, построение цепочки инструментов хранилища данных

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

1. Инструмент синхронизации данных

Инструмент синхронизации в основном решает две проблемы:

Синхронизация данных из исходной системы в хранилище данных
Синхронизируйте данные хранилища данных с другими средами

Далее основное внимание уделяется синхронизации данных из исходной системы в хранилище данных.

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

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

2. Платформа планирования задач

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

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

Разработанная нами функция «повторного запуска одним щелчком мыши» может отображать все пост-задачи, от которых зависят связанные задачи, и поддерживать выборочное удаление или виртуальное выполнение задач на любом узле:

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

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

3. Инструменты управления метаданными

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

(1) Управление родословной

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

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

Ниже представлена диаграмма кровных отношений в модели данных, восходящие и нисходящие линии представлены разными цветами:

(2) Управление знаниями данных

Благодаря четкому и подробному описанию технических и бизнес-метаданных формируются знания о данных, а персоналу, работающему с данными, предоставляется лучшее руководство. Наши знания о данных в основном включают описание объекта и описание атрибута, а именно:

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

5. Приложение хранилища данных - индикаторная платформа

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

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

Стандарт определения индикатора ясен, прост для понимания, в нем нет двусмысленности, а классификация понятна.
Процесс производства индикаторов прост, прозрачен и настраивается
Эффективность индексного запроса должна соответствовать быстрому ответу.
Гибкое и контролируемое управление правами на индикаторы

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

в:

Хранилище данных является источником данных индикаторов, и в настоящее время все индикаторы обрабатываются единообразно через хранилище данных.
Управление индикаторами включает в себя создание индикаторов и управление метаданными индикаторов: хранилище данных отвечает за производство и создание самых основных и основных индикаторов; другой персонал может выводить индикаторы в соответствии с правилами на основе этих индикаторов; управление метаданными записывает конкретный исходный путь индикаторов, объясняет Источником данных индикатора является таблица хранилища данных, либо Kylin, MySQL или ES.
Словарь индикаторов представляет определение, калибр, описание и т. д. индикаторов для внешнего мира, чтобы обеспечить прозрачность и интерпретируемость индикаторов.
Сервис данных принимает запрос индикатора, оценивает стоимость запроса по различным сценариям, выбирает оптимальную ссылку для запроса индикатора и возвращает результат запроса индикатора.
Многомерный запрос будет отображать индикаторы и измерения, которые могут предоставлять службы запросов через интерфейс.Пользователи могут выбирать индикаторы на основе измерений или выбирать измерения на основе показателей для запроса конкретных данных, которые им нужны.
Управление разрешениями осуществляется от начала до конца и может поддерживать управление разрешениями на уровне таблицы, индекса и значения измерения.

6. Резюме

Создание корпоративных данных должно пройти несколько основных этапов:

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

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

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

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

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

Автор статьи: Ян Бо, руководитель отдела исследований и разработок Mafengwo Data Warehouse.