Платформа данных 101: зачем она нужна и как ее построить
Привет, Хабр! Я Максим Еремин, руководитель направления развития PaaS и Big Data в beeline cloud. Расскажу, как эффективно использовать корпоративные данные: какие сложности с хранением и обработкой данных мы наблюдаем на примере наших клиентов и какие технологические решения предлагаем им для построения платформы данных.
Ключевые особенности работы с данными
Мы в beeline cloud работаем с 2000+ клиентов — от небольших компаний до крупных предприятий, банков и других финансовых организаций. Все они имеют дело с данными и накапливают их в своих информационных системах — это и 1С, и различные CRM и ERP.
В какой-то момент компании приходят к пониманию, что по мере накопления данных их можно использовать для управленческого учета, построения аналитических моделей, оценки рисков (например, кредитоспособности клиентов в банках), оптимизации цепочек поставок и многих других вещей. Однако поставить накопленные терабайты на службу бизнесу оказывается не так просто — уже на этом шаге большинство сталкивается с тем, что данные в компании хранятся во множестве систем и источников, они не централизованы. Либо внутри одного источника данные разрознены — например, в 1С ценность для анализа представляют отдельно взятые столбцы из разных таблиц.
Обычно это приводит сразу к ряду проблем:
Подготовка отнимает время — приходится выгружать данные из разных систем.
Нет прямых связок для построения отчетов и аналитики. Если источников несколько, их содержимое приходится совмещать вручную. При этом данные могут говорить об одном и том же —, но из-за того, что они разрознены или у них может не совпадать ID, их все равно будет сложно сопоставить.
Для подготовки отчетов и аналитики иногда приходится брать «грязные» данные — те, что не были очищены и запрепроцессированы. Возрастает количество ошибок — появляются пропуски, невалидные данные, тестовые данные, которые могли появиться в базе на этапе внедрения системы. Искать ошибки в таких случаях также приходится вручную. Уже на этом этапе отчетность может разниться с реальностью.
В итоге подготовка отчетов и аналитики сильно тормозит процессы вместо того, чтобы ускорять и облегчать их, делать работу организации эффективнее.
Можно попытаться нанять больше аналитиков и продолжать проводить выгрузку, сопоставление и процессинг данных вручную. Но в ситуации, когда их объем со временем только увеличивается (по нашим оценкам, ежегодный прирост может составлять 10–15% для малого и среднего бизнеса и 20–25% — для крупных компаний) гораздо эффективнее будет автоматизировать хотя бы часть работы в несколько шагов:
Организовать централизованное корпоративное хранилище, то есть единую базу, в которую будут сливаться данные всех систем.
Организовать процесс очистки и препроцессинга данных (приводить данные к нормализованному виду, а потом уже перемещать в корпоративное хранилище).
Подключить источники данных с помощью ETL-инструментов к корпоративному хранилищу данных (КХД).
Организовать в КХД предметно-ориентированные таблицы представления (витрины данных).
Использовать СУБД, способную работать с параллельными запросами к сводам данных объемом 3–5 ТБ. С такими объемами может быть сложно работать с помощью Postgres, так как она рассчитана скорее на транзакционные, нежели аналитические, запросы или работу с многомерными кубами.
У каждого из этих этапов есть свои тонкости и особенности, поэтому ниже расскажу про подход, которого придерживаемся мы в beeline cloud.
Как мы бы предложили решить задачу
Попробую расписать подробнее процесс обработки и хранения корпоративных данных:
Сбор данных. Основная идея — предоставить простой с точки зрения подключения интерфейс (UI или API) для сбора данных из CRM, ERP, HR-приложений и разнообразных систем бухгалтерского учета. Обычно для этих целей применяют два инструмента: Apache Kafka и Apache NiFi. Первый отвечает за передачу данных в очередь сообщений (push), а второй — помогает эти данные «вытянуть» (pull).
Препроцессинг. После получения данных нужно провести их предварительную обработку. Организовать ETL-процесс позволяет все тот же Apache NiFi. В качестве планировщика можно использовать Apache Spark и Apache Airflow. Источником может быть как точка входа данных, так и корпоративное хранилище.
Хранение данных. В зависимости от скорости записи и доступа к данным, а также от уровня обработки, хранение можно разделить на «холодное» и «теплое». Холодное хранилище — это data lake, куда попадают неструктурированные, сырые и грязные данные. Для работы с ним используют стек Hadoop, включая Airflow, Spark и HBase. Теплое хранилище содержит уже структурированные и очищенные данные, подготовленные для анализа и подходящие для построения отчетности.
В крупных компаниях данные должны быть доступны сразу нескольким аналитикам, которые, в свою очередь, могут готовить разные отчеты — например, бухгалтерские и финансовые. В таком контексте встает вопрос построения и обработки сложных аналитических запросов. Классические СУБД хорошо переваривают LTP-запросы, но могут испытывать трудности при обработке агрегаций с внутренними вычислениями, подбором данных и дальнейшей подготовкой для предиктивной аналитики.
Также необходим слой данных, который будет служить буфером для «горячего» слоя и хранить фактуру, которая все еще разбросана по каким-то предметным категориям, но может потребоваться для составления новой отчетности. В случае с компактными базами данных можно применить vSQL, но на масштабе такой подход показывает себя не лучшим образом. В прошлом для этих задач использовали коммерческие решения иностранных вендоров, сейчас компании все чаще обращаются к Greenplum.
Решение Greenplum широко применялось и раньше. Это —массивно-параллельная СУБД для реализации корпоративных хранилищ данных. Она заточена под работу со сложными запросами и большими объемами данных свыше 100–500 ТБайт.
Долгое время продукт распространялся под свободной лицензией, но в мае этого года владелец заархивировал проект на GitHub и перешел к коммерческой модели распространения. Иными словами, все новые версии Greenplum будут с закрытым исходным кодом. Однако сегодня продолжают развиваться форки, разработчики которых совершенствуют СУБД. На российском рынке таким проектом является Arenadata DB. У Arenadata сильная и опытная команда разработки в сообществе Greenplum. В мае текущего года компания официально заявила о том, что изменение статуса всех публичных репозиториев Greenplum на архивный не окажет негативного влияния на развитие продукта Arenadata DB. Команда Arenadata была готова к подобному сценарию и заранее обеспечила возможность разработки Arenadata DB в рамках собственного форка.
Мы пообщались с техническим экспертом Arenadata Алексеем Струченко в рамках вебинара: он рассказал о технологическом стеке платформы и, в частности, об особенностях ADB.
Витрины данных, визуализация и аналитика. На этом этапе аналитик может подключиться к витрине, настроить доступ к таблицам и начать формировать графики, чтобы дополнить отчетность визуализацией на основе чистых, подготовленных, агрегированных данных. Достаточно будет единожды настроить систему для определенного типа отчетов и итеративно накапливать и обрабатывать данные.
Так выглядит платформа данных в beeline cloud
Главные преимущества такого подхода — чистота и стандартизация данных. А также упрощение работы аналитиков: вместо того, чтобы обрабатывать данные, они тратят время на более сложные и важные задачи. Не говоря уже о том, что результат их работы становится точнее и лучше отражает реальное положение дел в компании. Правда, есть и другое, менее очевидное преимущество — построение платформы данных открывает для компаний возможность прорабатывать новые сценарии их использования.
Возьмем, к примеру, автоматизацию первой линии поддержки. Раньше сотрудникам первой линии приходилось вручную искать или перепроверять ответы на вопросы. Если же компания начала систематически собирать и обрабатывать соответствующие данные с помощью платформы, ничего не мешает поработать с ними более глубоко. Компания может обучить нейросеть, интегрировать ее с сервис-деском и автоматизировать поиск подходящих ответов, например, на первой линии поддержки.
Почему платформы данных строят в облаке
Развернуть такую платформу можно как в облаке, так и «на земле» (on premise). Наши коллеги из Arenadata отмечают, что еще два-три года назад многие компании тяготели ко второму варианту, но сейчас все больше бизнесов выбирают для организации платформы данных облако. В его пользу выступают несколько аргументов:
Снижение затрат на физические серверы. Очевидно, что в формате on premise компании придется закупать железо — платформа подразумевает хранение большого объема данных (плюс бэкап). Аппаратуру нужно не только купить, но и поддерживать и обновлять — в среднем оборудование устаревает за 5–10 лет.
Перевод CAPEX в OPEX (потребление ресурсов помесячно) позволяет расширяться (и сужаться — при необходимости) более гибко и экономично.
Сокращение ТСО. Облако позволяет компаниям тратить меньше денег на поддержку, разработку, внедрение решения по сравнению с on premise. В ходе одного из наших вебинаров я подробно подсчитал TCO для компании, в которой работает 50 человек, и сравнил стоимость on premise варианта с бесплатным Greenplum с одной стороны и нашей инфраструктуры в облаке с продуктами Arenadata — с другой. On prem вариант оказывается дороже облачной платформы в части затрат на команду разработки (люди, которые будут внедрять и развивать ПО с точки зрения внутренних интеграций — этот момент я разобрал в деталях), оборудование и его обслуживание.
Если вас заинтересовала тема: вместе с Arenadata мы подготовили еще один вебинар «От разрозненных данных к управляемой платформе хранения». Там мой коллега из Arenadata Антон Близгарев просчитывает стоимость развертывания и обслуживания платформы данных на примере компании-ритейлера, которая выбирала между вариантом on premise и облаком. Мы не только считаем, во сколько обойдется «железо+лицензии», но и обсуждаем вопросы обеспечения безопасности, стоимости потерь при простое и предсказуемости расходов при построении платформы данных.
