Привет, я – Ильдар Райманов и я руковожу департаментом в «БАРС Груп», который отвечает за развитие BI-решений в компании. Имея широкий опыт по работе с данными, а также обладая отраслевой экспертизой, мы решили попробовать сформировать центр компетенций, который, позволяя обрабатывать большие массивы данных, сможет обеспечить сервис по формированию знаний на те или иные предметные запросы клиентов.
Data-Office включает в себя сразу несколько составляющих – это проработанное хранилище, включающее как «озеро больших данных», так и подготовленные витрины, процессы наполнения данных из систем источников, механизмы проверки качества данных; команда методологов, которые понимают, о чем говорят те или иные цифры согласно отраслевой специфике, ну и конечно набор различных софтверных инструментов, основным из которых является платформа бизнес-аналитики Alpha BI, разработанная компанией «БАРС Груп».
Чтобы информация воспринималась еще более понятно, постараюсь раскрыть простым языком ключевые термины, акцентировано выделенные в тексте.
Если говорить подробнее о подходах и шагах, то в рамках Data-Office нами определена следующая последовательность:
1. Разбор предметной области – выделяется Команда методологов, которая описывает предметную область, основные сущности, готовит для основного хранилища логическую модель данных.
Кто такие методологи? Это по сути отраслевые эксперты, которые понимают суть данных. Если, например, мы говорим о финансах, то это могут быть бухгалтера и финансисты, если же речь про медицину, то это врачи и иные квалифицированные медработники. Именно их понимание и позволяет построить логическую модель данных, а именно набор сущностей, который будет анализироваться вместе со связями – какое отношение какая сущность может иметь по отношению к другой.
2. На основе логической модели данных готовится нормализованная физическая модель, подключаются архитекторы данных. Тут уже, конечно, нужны ИТ-специалисты, ведь именно они набор сущностей переводят в таблицы, создают необходимые внешние ключи, атрибуты, индексы – то есть как раз и строят так называемую физическую модель.
3. Прорабатывается модель потока данных, устанавливаются источники и варианты интеграции. Модель потока данных – это набор передаваемых данных с описанными правилами: откуда и куда, по каким условиям, с какой периодичностью.
4. Как правило, поскольку речь идет о большом объеме данных, то изначально данные из источников попадают в формате «как есть» в буфер данных — первый слой «сырых данных». Тут преследуется как цель снижения времени на прогрузку данных, так и цель иметь у себя набор первичных данных, чтобы сохранить возможность в случае необходимости раскрутить цепочку анализа до самого первого значения.
5. Прорабатываются вопросы трансформации данных из буфера во второй слой — нормализованное хранилище, а также вопросы по периодичности обновления и хранения информации в буфере, тут же решается вопрос по инкрементальному обновлению. Также прорабатываются вопросы качества данных, методы и инструменты. Под качеством данных подразумевается соответствие информации требуемому логическому содержанию. Начинается все с простых валидаций форматно-логического контроля и заканчивается уже более сложными методологическими паттернами.
6. Методологи анализируют потребительские кейсы, и на основе этого описываются возможные витрины данных, то есть специально подготовленные наборы данных, которые должны помогать отвечать на те или иные вопросы.
Команда BI-разработчиков уже непосредственно формирует набор витрин, который представляет собой аналитическое хранилище данных – третий слой.
7. Стоит отметить, что параллельно ведется работа над формированием Глоссария данных (подробным методологическим описанием) и постоянной актуализацией связи самих сущностей хранилища с этим самым детальным методологическим описанием.
8. Набор инструментов в ходе описанного выше процесса может отличаться в зависимости от задач. В основном используется платформа бизнес-аналитики Alpha BI, на базе которой строятся и слои хранилище на PostgreSQL и решаются задачи ETL средствами самой платформы.
9. Непосредственно работа с подготовленными витринами также идет через Alpha BI. Получая потребность в получении знаний – изначально Команда методологов анализирует задачу и накладывает ее на имеющуюся логическую модель, далее уже Команда BI-разработчиков, получив предметно-ориентированную постановку, реализует на базе витрин необходимые выборки, ОЛАП-Кубы, дашборды, отчеты. Случается, что витрина несколько трансформируется, либо создается новая, если того требует ситуация.
Если говорить про инструменты и большие данные, нельзя не упомянуть и про опыт работы с модным «на кухне BigData» уже не первый год Hadoop – слоем для хранения большого объема сырых исторических данных.
С технической точки зрения, взаимодействие Alpha BI с Hadoop осуществляется через слой, построенный на базе массово-параллельной аналитической СУБД Greenplum с использованием протокола PXF (Platform Extension Framework).
Аналогично с использованием Greenplum реализована и возможность оперативного анализа и работы с горячими данными, которые, к примеру, обновляются каждые 10 секунд. В случае с горячими данными взаимодействие через Greenplum строится с in-memory БД Apache Ignite также с использованием PXF протокола.
По окончании суток данные из таблицы Ignite переносятся в HDFS и удаляются из Ignite.
Подводя итоги, хочется еще раз резюмировать – данные должны работать и приносить пользу. Чтобы максимально извлекать из них знания, следует уделять внимание всем вышеперечисленным аспектам: грамотно подходить к построению хранилища, определять оптимальные потоки данных, разбираться в предметной области «цифр», подбирать инструмент под задачу.
Вместе с тем, разумеется, стоит уделять отдельное внимание формированию Команды и сегментированию ее на разные типы задач, в каждом из которых должны работать профи-единомышленники.
И тогда ваши данные своими миллионами и миллиардами строк и терабайтами памяти действительно начнут работать, давать знания, а значит приносить пользу!
Буду рад ответить на ваши вопросы в комментариях!)
