Всем привет! Меня зовут Алексей, и я уже более 20 лет в ИТ, занимался разработкой, затем системным анализом и управлением проектами, а в последние годы ­– интеграционными потоками, данными и архитектурой систем. Сейчас я работаю в Quillis на позиции технического руководителя команды инженеров данных. Сегодня мы попробуем найти почти универсальное решение для организации, которая на определенном этапе развития столкнулась с необходимостью управлять накопленными корпоративными данными о продажах, клиентах, товарах и любых других сущностях.

Глобально, а это вообще зачем делается?

Чтобы прокачивать прибыль – иначе становится очень сложно выдержать конкуренцию и масштабировать бизнес.

Допустим, но, когда это можно назвать необходимым?

Когда с объемом данных и количеством источников перестают справляться электронные таблицы и обрабатывающие их вручную сотрудники.

Бизнес-проблема

Итак, давайте представим ситуацию, когда процессы уже усложнились настолько, что руководство логично приходит к мысли о необходимости выстраивания Хранилища данных – загадочной структуры, иногда с красивым названием Data Lake, которая решит все проблемы интеграции, обработки и хранения данных.

Основная цель внедренного решения – собрать данные и получить из них отчетность, которой можно доверять.

Дополнительная цель – широкие возможности интеграции почти с любыми информационными системами как в части забора информации, так и шэринга (например, когда нужно отдать данные партнерам или подрядчикам).

Решение должно быть простым и не ресурсозатратным. То есть, даже если у нас уже есть определенный штат ИТ-специалистов, которые могут взять на себя реализацию, было бы лучше, если бы у них была возможность заниматься более важными делами. Кроме того,  мы уверены, что вариантов решения и платформ очень много, и мы точно найдем решение под себя – это позитив. Однако есть в этой бочке меда и кое-что невкусное: риск. Ведь ошибка в выборе может стоить очень дорого, и это совершенно не вписалось бы в концепцию оптимизации ресурсов и увеличения прибыли. Поэтому действуем осторожно и рассматриваем только надежные и проверенные связки. Спойлер: мы бы предложили в данном случае PostgreSQL + Airflow + Python-скрипты.

Какие дополнительные и крайне полезные для владельца бизнес-проблемы задачи возникают в этот момент (полезные, потому что дают дополнительную выгоду в перспективе и реальную прибыль):

• необходимость описания и оптимизации бизнес-процессов;

• необходимость определения владельцев сущностей и их атрибутов;

• составление требований к пониманию данных, которыми обладает организация.

Какие ключевые ИТ-задачи мы имеем:

• выбор СУБД (системы управления базами данных), как платформы для ядра системы;

• выбор механизмов интеграции с источниками данных;

• выбор инструмента отчетности.

Эти три компонента позволяют нам закрыть базовые потребности процесса управления данными – получить данные, преобразовать их, сохранить и вывести в отчетность. ETL-pipeline для Data lake, да.

А теперь самое время перейти к нашей конкретной связке PostgreSQL + Airflow + Python-скрипты, и рассказать об этом подробнее.

СУБД PostgreSQL как хранилище

Вообще, сразу хотим дать добрый совет: СУБД лучше всего выбирать не по отзывам или технологической крутизне, а, исходя из компетенций штатных сотрудников. Это поможет ускорить развертывание, практически исключит капканы, в которых можно надолго застрять и немного упростит дальнейшую поддержку, развитие и интеграцию между базами.

Но самый простой, надежный, как молоток или Тойота, эффективный вариант на данный момент на рынке - PostgreSQL. Широко распространенная, бесплатная, безопасная СУБД. Учитывая мировую турбулентность и сложности с импортозамещением – актуальная и доступная.

Airflow как оркестратор

Оркестратор – система управления рабочими процессами (workflow management) и планирования задач, которая позволяет автоматизировать процедуры и координировать их выполнение по расписанию и с зависимостями (в том числе и на разных серверах).

Почему именно Airflow?

Это один из ключевых и наиболее популярных проектов известной экосистемы Apache, но это не единственный положительный момент.

Главные плюсы и, по совместительству, причины нашего выбора:

• открытое программное обеспечение;

• нативная поддержка Python;

• легкость установки и настройки;

• низкие требования к ресурсам сервера;

• невысокие требования к компетенциям;

• возможность масштабирования;

• веб-графический интерфейс.

Программирование цепочки задач (DAG в Airflow) – это простой и достаточно шаблонный процесс. Их настройка и запуск в большинстве случаев не представляет никаких сложностей.

Еще хочется сказать, что Airflow желательно разместить на собственном сервере отдельно от СУБД, но максимально близко в рамках одного сегмента локальной сети. При этом нельзя забывать, что ему потребуется выход в Интернет для доступа к источникам или клиентам за пределами корпоративной сети – например, чтобы забирать необходимые данные с каких-либо внешних сайтов.

И последнее: из Airflow можно, в том числе, просто вызывать хранимые процедуры на стороне СУБД Хранилища, чтобы забирать данные из источника напрямую через связанные базы данных, а не производить перегрузку через Python, нагружая оперативную память лишними задачами.

Python-скрипты как модули интеграции

И раз уж мы упомянули про Python, то самое время перейти к нему. Сегодня этот язык является одним из наиболее простых, удобных и широко распространенных языков программирования. К нему есть огромное количество доступных и проверенных библиотек, позволяющих работать с любыми источниками данных – базы данных, файлы, веб-сервисы, сайты, облачные платформы и вообще, кажется, всё, что изобретено прогрессивным человечеством.

Технически скрипты помогают забрать данные из источника, преобразовать их и положить в целевую структуру в Хранилище (обычно это stage-уровень, куда данные складываются «как есть» от источника, с незначительными преобразованиями).

Запустить скрипты на Python так же просто, как поставить на скачку файл в браузере: внутри самих задач Airflow скрипт запускается как модуль. Из важного на этом этапе, если вы любите, когда вас окружает порядок, мы рекомендуем программно разделять на модули код самого DAG и код программы, выполняющей ETL-процесс. Это позволит легко тестировать программы и выполнять их отдельно от среды Airflow.

Преобразование данных можно выполнять как в Python-среде Airflow, так и SQL-процедурами на стороне Хранилища после загрузки. Баланс между этими вариантами следует определить самостоятельно, исходя из эффективности, наличия компетенций и доступных ресурсов (серверных и человеческих). Переживать тут практически не о чем, все можно регулировать в процессе. Для преобразования в Python также есть множество библиотек, из которых наиболее известной и классической является Pandas. И, кстати, развивая компетенции команды в этом направлении, в том числе, можно получить в дальнейшем возможности реализации простых задач машинного обучения собственными силами. Например, сегментация и прогнозирование.

И еще очень классным бонусом является то, что в модулях Python иногда удобно реализовать рассылку данных пользователям в любые доступные каналы, такие как Telegram или электронную почту.

Jupyter Notebook как среда разработки

Можно выбрать любую IDE (среду разработки), которая будет наиболее эффективна и удобна для конкретной компании, но мы не можем не упомянуть Юпитер. Очень удобный онлайн-блокнот, позволяющий легко запускать скрипты в веб-интерфейсе и работать с ними командой совместно – просто рекомендация.

BI-система

В итоге, получив инструмент интеграции данных в Хранилище по расписанию, компания приходит к необходимости построить витрины данных, которые затем будут использоваться аналитиками. Само построение Хранилища по выбранной схеме, механизмы инкрементальной загрузки и прочие детали структуры данных лучше оставить явно за пределами статьи…

Данные для потребителей могут быть предоставлены либо через прямой доступ к витринам посредством SQL или выборки данных в Excel и прочие электронные таблицы – но удобнее и эффективнее будет внедрить BI-систему для визуализации и представления данных в любых доступных формах отчетности.

К сожалению, в текущих условиях многие платформы, являющиеся лидерами на рынке BI-систем, недоступны. Такие как Qlik Sense, Tableau и даже Power BI. Впрочем, порог входа для внедрения подобных систем тоже не самый низкий – требует некоторых компетенций, затрат и ресурсов.

На российском рынке представлены несколько BI-систем, которые позволяют достаточно эффективно выгружать данные из Хранилища и строить различные варианты форм визуализации. В системах этого класса обычно реализован единый механизм доступа к данным вне зависимости от типа источника, и подключение к Хранилищу, которое содержит понятную модель данных, не составляет труда. Некоторые решения позволяют вообще частично или полностью отказаться от Хранилища, оставив СУБД в качестве промежуточной базы данных для вспомогательных задач или быстрой разработки - подобные компоненты берут на себя хранение наборов данных и ETL-процессы.

Масштабирование и расширение возможностей

Масштаб полученной системы можно наращивать без значительных доработок

Для расширения интеграционных возможностей можно рядом с Airflow построить шину данных, API-сервисы, в том числе, основанные на витринах Хранилища или других компонентов, добавить брокеры сообщений и прочее, что потребуется при дальнейшем развитии организации и переходе на новый уровень технологической зрелости.

Наработанные навыки команды и данные, собранные в логические и понятные структуры, позволят использовать возможности подключения элементов машинного обучения для сегментации и прогнозирования – переиспользуя уже существующие компоненты: БД для хранения моделей, Python для их построения, Airflow для управления цепочками ETL-задач.

до тех пор, пока компоненты не перестанут справляться с объемом данных. Но даже в этом случае вы смогли бы заменить часть компонентов без критичных затрат. А дальше для Вас открыта дорога в эффективную работу даже с реально огромными объемами BigData. Например, можно добавить компоненты экосистемы Hadoop, встроив их в архитектуру, или же построив рядом со стандартным реляционным Хранилищем колоночную структуру, оптимизированную под OLAP.

Требуемые компетенции

Уровень компетенций для реализации подобного решения требуется не очень значительный:

• базовые знания unix-подобных систем для развертывания платформ (например, Ubuntu);

• базовые навыки Python для создания задач Airflow (на основе примеров, найденных в доступных источниках);

• навыки Python для интеграционных скриптов;

• знания библиотек обработки данных;

• базовые навыки администрирования для настройки связи компонентов;

• хорошие знания SQL для создания Хранилища данных и ETL-процедур;

• отличные навыки поиска вариантов правильных решений в Интернете и телеграм-каналах (это, возможно, самое важное).

Однако не все так просто, как хотелось бы, потому что очень важно иметь внутри организации действительно сильного технического архитектора для определения правильных потоков данных и целевой структуры Хранилища, и усилия команды бизнес-аналитики для уточнения сущностей данных, их атрибутов и жизненного цикла.

Серверные мощности не критичны, можно закладывать затраты только на диски для Хранилища и оперативную память для Airflow и Python-скриптов.

Итог

Если объем накопленной информации больше не позволяет бездействовать, то описанная выше система может стать настоящим спасением.

С использованием широко распространенных решений на основе открытого ПО, можно даже силами внутренней команды, обладающей нужными навыками и знаниями, построить базовое хранилище данных и процессы интеграции, и заложить основу для развития – как технологической платформы организации, так и внутренних компетенций.