Comments 14
хорошая статья, спасибо. если можно пару вопросов, в большинстве случаев по вашему опы у, вы:
- в своих ЕТЛ всегда делаете инкрементальные загрузки в хранилище или перелопачиваете всю базу источника?
- тащите более менее сырые по-строковые данные из источников (максимум джоны нескольких таблиц) или также группируете и тащите уже аггрегированные данные?
еще пару вопросов в догонку: у вас лейк только в проде или аналитики также имебт доступ к дев/тестовой среде, где они могут отточить свои аналитияеские запросы/дешборды прежде чем пушить их в прод?
Привет, спасибо!
- У нас процентов 85 загрузок инкрементальные по ts. Обычно это все транзакционные данные. Где-то процентов 10 грузятся полной перезаписью (для справочников). Остальные 5 процентов мы снепшотим — снимаем полные срезы с таблицы источника для отслеживания динамики стейтов (например, атрибутов профиля пользователей)
- Тащим все AI IS. Без джойнов и т.д. Это делается для того, чтобы потребители данных могли понимать, что именно лежит в источнике без учета наших манипуляций. Преобразуем данные мы уже только на уровне витрин
Отличная статья! Спасибо! А почему выбор пал именно на Cloudera Hadoop? Насколько я знаю в бесплатной версии у них ограничено кол-во узлов в кластере. Вы ограничились этим или приобретали Enterprise версию? Почему не выбрали Hortonworks? Да она не без недостатков и нужно поработать напильником, но вроде как полностью опенсорс.
Несколько лет назад, в момент выбора сборки, Cloudera нам она показалась чуть более подходящей:
В целом, нам будем уже крайне дорого менять сборку, но если бы мы выбирали прямо сейчас, то может быть выбрали бы Hortonworks
P.S. Ограничения по хостам нет даже в community версии
- В Mail.ru уже был опыт ее использования
- В ней есть Impala, которая чуть менее стабильна чем hive, но крайне быстра и нравится нашим аналитикам
В целом, нам будем уже крайне дорого менять сборку, но если бы мы выбирали прямо сейчас, то может быть выбрали бы Hortonworks
P.S. Ограничения по хостам нет даже в community версии
Спасибо за статью, очень познавательно.
Если будет возможность ответить было бы интересно узнать следующее… При таком количестве и разнообразии источников есть ли потребность в каталогизации данных, Какой инструментарий используете или планируете использовать? Как технически и организационно решаете вопросы с администрированием доступа? Есть ли необходимость в консолидации, гармонизации исходных данных перед передачей их аналитиками, если да, то какие архитектурные последствия для вашего data lake это имеет?
Спасибо.
Если будет возможность ответить было бы интересно узнать следующее… При таком количестве и разнообразии источников есть ли потребность в каталогизации данных, Какой инструментарий используете или планируете использовать? Как технически и организационно решаете вопросы с администрированием доступа? Есть ли необходимость в консолидации, гармонизации исходных данных перед передачей их аналитиками, если да, то какие архитектурные последствия для вашего data lake это имеет?
Спасибо.
Спасибо!
Потребность в каталогизации определённо имеется. Сейчас мы всю мета-информацию храним в json’ах — по одному на каждый источник. На основе этих json’ов и строится забор данных из Airflow. Мы обдумываем создание центра управления загрузками через мету, но писать о нем пока рано.
Доступы нас к источникам
Доступы аналитиков к хранилищу
Концепция Data Lake подразумевает хранение данных из источников AS IS, так что мы приводим их к единому виду уже только на уровне витрин.
Потребность в каталогизации определённо имеется. Сейчас мы всю мета-информацию храним в json’ах — по одному на каждый источник. На основе этих json’ов и строится забор данных из Airflow. Мы обдумываем создание центра управления загрузками через мету, но писать о нем пока рано.
Доступы нас к источникам
- Почти все наши источники находятся в инфраструктуре Mail.ru и ими управляют специальные админы. Для получения доступов с нашей стороны требуется задача на них, а они уже пропиливают дырки, заводят пользователя и каталогизируют это на своей стороне
Доступы аналитиков к хранилищу
- Для управления правами к базам внутри нашего Hadoop используется самописная веб тула поверх AD. В ней мы по таскам раздаем доступы аналитикам к данным конкретных проектов
Концепция Data Lake подразумевает хранение данных из источников AS IS, так что мы приводим их к единому виду уже только на уровне витрин.
Спасибо за ваш ответ.
Относительно гармонизации источников здесь ваш коллега делился аналогичным опытом и описывал подход с RAW>ODD>RDS>MART архитектурой. Подобное видение также исповедует Alex Gorelik в своей работе The Enterprise Big Data Lake. С вашей точки зрения как практика и имея ввиду специфику задач стоящих перед вами это чересчур?
Относительно гармонизации источников здесь ваш коллега делился аналогичным опытом и описывал подход с RAW>ODD>RDS>MART архитектурой. Подобное видение также исповедует Alex Gorelik в своей работе The Enterprise Big Data Lake. С вашей точки зрения как практика и имея ввиду специфику задач стоящих перед вами это чересчур?
Идея Юры Емельянова из статьи нам близки. Во-первых, они имеют опыт успешной реализации. Во-вторых, Юра был первым архитектором нашего хранилища)
Однако, в нашем случае, при широком хранилище (более 5000 таблиц) и независимых потребителях данных мы не используем слой RDS (или DDS). У нас 3 уровня данных:
Основная причина такого подхода — наши аналитики ходят видеть в хранилище именно ту структуру данных, которая есть в источниках их проектов. Они сами независимо друг от друга выбирают эту структуру со своими разработчиками игр под свои конкретные аналитические нужды.
Единая для всех структура данных создается нами уже только для слоя DMA (витрин), который используется для BI и кросс-проектной аналитики.
Однако, в нашем случае, при широком хранилище (более 5000 таблиц) и независимых потребителях данных мы не используем слой RDS (или DDS). У нас 3 уровня данных:
- RAW. Он же закрытый от потребителей STG для промежуточного хранения сырья
- ODA (Operational Data Area) для хранения данных в формате близком к AS IS. Таких данных более 95 процентов от всего объема хранилища
- DMA (Data Mart Area) для витрин
Основная причина такого подхода — наши аналитики ходят видеть в хранилище именно ту структуру данных, которая есть в источниках их проектов. Они сами независимо друг от друга выбирают эту структуру со своими разработчиками игр под свои конкретные аналитические нужды.
Единая для всех структура данных создается нами уже только для слоя DMA (витрин), который используется для BI и кросс-проектной аналитики.
Добрый день, спасибо за интересную статью!
- Есть ли у вас интерфейсы для ведения ручных данных, по типу oracle apex?
- Какие подходы выбраны с точки зрения документирования решения, в данном подходе наверное в части витрины? Описываете ли вы трансформации загрузки в витрину? Excel/csv или word, или храните на уровне метабазы/кода? Аналогичный вопрос по ведению бизнес/логической/физической модели.
Добрый день!
- На текущий момент ручные данные добавляются аналитиками через веб интерфейс Hadoop (HUE) непосредственно в свои именные базы. Решение рабочее, но только для аналитиков. Для снижения порога вхождения подумываем реализовать простенький веб интерфейс для этой задачи
- Весь DMA слой (Data Mart Area) у нас детально описан в Confluence. Слой сырья ODA (Operational Data Area) задокументирован уже не так полно. Мы рассматриваем варианты автоматизации этой документации, но пока не пришли к конечному решению (нужно ли это, а если нужно, то как именно)
Sign up to leave a comment.
Клиентоориентированный Data Lake в игровой компании