На текущий момент ручные данные добавляются аналитиками через веб интерфейс Hadoop (HUE) непосредственно в свои именные базы. Решение рабочее, но только для аналитиков. Для снижения порога вхождения подумываем реализовать простенький веб интерфейс для этой задачи
Весь DMA слой (Data Mart Area) у нас детально описан в Confluence. Слой сырья ODA (Operational Data Area) задокументирован уже не так полно. Мы рассматриваем варианты автоматизации этой документации, но пока не пришли к конечному решению (нужно ли это, а если нужно, то как именно)
Идея Юры Емельянова из статьи нам близки. Во-первых, они имеют опыт успешной реализации. Во-вторых, Юра был первым архитектором нашего хранилища)
Однако, в нашем случае, при широком хранилище (более 5000 таблиц) и независимых потребителях данных мы не используем слой RDS (или DDS). У нас 3 уровня данных:
RAW. Он же закрытый от потребителей STG для промежуточного хранения сырья
ODA (Operational Data Area) для хранения данных в формате близком к AS IS. Таких данных более 95 процентов от всего объема хранилища
DMA (Data Mart Area) для витрин
Основная причина такого подхода — наши аналитики ходят видеть в хранилище именно ту структуру данных, которая есть в источниках их проектов. Они сами независимо друг от друга выбирают эту структуру со своими разработчиками игр под свои конкретные аналитические нужды.
Единая для всех структура данных создается нами уже только для слоя DMA (витрин), который используется для BI и кросс-проектной аналитики.
Потребность в каталогизации определённо имеется. Сейчас мы всю мета-информацию храним в json’ах — по одному на каждый источник. На основе этих json’ов и строится забор данных из Airflow. Мы обдумываем создание центра управления загрузками через мету, но писать о нем пока рано.
Доступы нас к источникам
Почти все наши источники находятся в инфраструктуре Mail.ru и ими управляют специальные админы. Для получения доступов с нашей стороны требуется задача на них, а они уже пропиливают дырки, заводят пользователя и каталогизируют это на своей стороне
Доступы аналитиков к хранилищу
Для управления правами к базам внутри нашего Hadoop используется самописная веб тула поверх AD. В ней мы по таскам раздаем доступы аналитикам к данным конкретных проектов
Концепция Data Lake подразумевает хранение данных из источников AS IS, так что мы приводим их к единому виду уже только на уровне витрин.
Прямо сейчас наши аналитики могут создавать свои собственные дашборды и писать любые запросы к хранилищу, однако, не могут писать свой ETL. Его мы полностью контролируем сами. Но скорее всего мы будем менять эту часть и отдавать часть не критичного ETL на сторону аналитиков
У нас процентов 85 загрузок инкрементальные по ts. Обычно это все транзакционные данные. Где-то процентов 10 грузятся полной перезаписью (для справочников). Остальные 5 процентов мы снепшотим — снимаем полные срезы с таблицы источника для отслеживания динамики стейтов (например, атрибутов профиля пользователей)
Тащим все AI IS. Без джойнов и т.д. Это делается для того, чтобы потребители данных могли понимать, что именно лежит в источнике без учета наших манипуляций. Преобразуем данные мы уже только на уровне витрин
Однако, в нашем случае, при широком хранилище (более 5000 таблиц) и независимых потребителях данных мы не используем слой RDS (или DDS). У нас 3 уровня данных:
Основная причина такого подхода — наши аналитики ходят видеть в хранилище именно ту структуру данных, которая есть в источниках их проектов. Они сами независимо друг от друга выбирают эту структуру со своими разработчиками игр под свои конкретные аналитические нужды.
Единая для всех структура данных создается нами уже только для слоя DMA (витрин), который используется для BI и кросс-проектной аналитики.
Потребность в каталогизации определённо имеется. Сейчас мы всю мета-информацию храним в json’ах — по одному на каждый источник. На основе этих json’ов и строится забор данных из Airflow. Мы обдумываем создание центра управления загрузками через мету, но писать о нем пока рано.
Доступы нас к источникам
Доступы аналитиков к хранилищу
Концепция Data Lake подразумевает хранение данных из источников AS IS, так что мы приводим их к единому виду уже только на уровне витрин.
В целом, нам будем уже крайне дорого менять сборку, но если бы мы выбирали прямо сейчас, то может быть выбрали бы Hortonworks
P.S. Ограничения по хостам нет даже в community версии