Хранилище данных Meituan OneData
Terms
OneData: предлагаемый Alibaba стандарт построения хранилища данных
Резюме
Основываясь на идее OneData и существующей бизнес-структуре, Meituan предложила новые стандарты и цели:
Метод реализации: единая фокусная точка и экспорт Единое управление: унифицированное управление бизнесом, унифицированное управление проектированием и унифицированное управление приложениями снизу для обеспечения трех характеристик и трех эффектов построения хранилища данных.Единый экспорт:
- Стандартная доставка
- Управление активами данных: унифицированное измерение, экспорт метаданных индикаторов и т. д.
На основе этого реализована многоуровневая модель:
Нормальная разработка должна следовать процессу ODS-DWD-DWT-DWA-APP и делать Технические характеристики разработки:
- Обычный поток: ODS>DWD->DWT->DWA->APP Когда появляется отношение ODS>DWD->DWA->APP, это означает, что предметный домен не полностью покрыт. Данные DWD должны попадать в DWT, позволяя использовать DWD->DWA для очень редко используемых таблиц. Старайтесь избегать расширенных таблиц DWA, использующих DWD и DWT (домен объекта, к которому принадлежит DWD).
- В принципе, следует по возможности избегать создания DWT-таблиц в одной и той же предметной области, иначе это повлияет на эффективность ETL.
- Таблицы, которые напрямую используют ODS в DWT, DWA и APP, запрещены.
- На таблицы ODS можно ссылаться только с помощью DWD.
- Обратные зависимости запрещены, например, таблица DWT зависит от таблицы DWA.
Платформа управления данными Meituan
Цель строительства
Определение, метод расчета и источник данных унифицированных показателей
при абстрагировании одной функцииСпособствует управлению и вмешательству в обеспечение согласованности данных/показателей на уровне управления
Резюме
Общая схема архитектуры:
Архитектура платформы управления данными:
Процесс управления платформой данных
Архитектура и практика синхронизации данных Meituan DB с хранилищем данных
Terms
Binlog: Binlog — это двоичный журнал MySQL, который записывает все изменения данных в MySQL.Синхронизация master-slave самого кластера MySQL основана на Binlog.
фон проблемы
Самый прямой способ передачи бизнес-данных из БД в хранилище данных — выборка и загрузка данных пакетами, но по мере расширения бизнеса могут возникнуть следующие проблемы:
- Узкое место в производительности: с ростом масштабов бизнеса поток данных «Выбрать из MySQL» -> «Сохранить в локальный файл» -> «Загрузить в Hive» занимает все больше и больше времени, что не может удовлетворить требования времени для последующего производства хранилища данных.
- Выбор большого объема данных непосредственно из MySQL оказывает большое влияние на MySQL, что, вероятно, приведет к медленным запросам и повлияет на нормальные услуги в бизнес-линии.
- Поскольку синтаксис самого Hive не поддерживает примитивы SQL, такие как обновление и удаление, он не может хорошо поддерживать данные, которые встречаются в MySQL с помощью Update/Delete.
решение
Изменено на решение CDC + Merge, то есть сбор Binlog в реальном времени + автономная обработка бизнес-данных восстановления Binlog. Причина в следующем:
Во-первых, Binlog генерируется потоковой передачей.Посредством сбора Binlog в реальном времени часть требований к обработке данных распределяется на поток в реальном времени из пакетной обработки один раз в день. Независимо от производительности или ограничения доступа к MySQL, будут значительные улучшения.
Во-вторых, Бинлог сам фиксирует тип изменения данных (Вставка/Обновление/Удалить), благодаря некоторой семантической обработке можно добиться точного восстановления данных.
Схема архитектуры автономной коллекции Binlog
Объединить блок-схему
Участие в проектах с открытым исходным кодом
Канал Алибаба
LinkdeIn Camus