Эволюция корпоративной аналитики: от Excel к ClicData и Amazon QuickSight
Для роста и нормального функционирования компании руководители принимают различные решения: сколько и каких сотрудников нанять, нужно ли брать кредит для закрытия кассового разрыва, сколько денег выделить на закупку печенек в следующем квартале, стоит ли инвестировать в новое оборудование и т. д. Чтобы принять решение, нужна информация. Недостоверная информация или ее недостаток могут привести к ошибочным решениям, что, в свою очередь, вызовет проблемы. Поэтому любая компания, независимо от размера, строит систему аналитики и отчетности.
С чего все обычно начинается?
Наиболее распространённое решение на старте — это использование Excel и Google Spreadsheet для ведения отчетности и построения графиков.
Эти инструменты достаточно мощные. Позволяют хранить данные в виде файлов с таблицами, строить графики для отчетов, работать с данными, используя формулы и встроенные аналитические функции, а также писать собственные скрипты для обработки данных и, например, для рассылки отчетов по почте.
Все это прекрасно работает, пока ваша команда небольшая. Однако, по мере роста компании и усложнения ее структуры, возникают проблемы. Увеличиваются объем данных для анализа, количество их источников, потребителей и ответственных за них сотрудников. Каждый отдел создает собственные файлы для отчетности, а данные из источников собираются самостоятельно. В большом числе отчетов сложнее ориентироваться, и часто отчеты, построенные на основе одних и тех же данных, дают разные результаты.
Почему так получается?
Отсутствие единой и понятной структуры данных. Разное именование данных вносит путаницу и затрудняет понимание, что и как мы считаем.
Отсутствие единого источника правды. Сами данные в отчеты различных подразделений могут вноситься с ошибками.
Показательный пример — наш личный опыт. Однажды CEO обратился в три разных подразделения, связанных с субподрядчиками, с простым вопросом: «Сколько подрядчиков работало на нас в прошлом квартале?». Он получил ответ, но не так быстро, как хотел, ведь в ворохе таблиц еще надо было найти нужные данные. А самое интересное — каждое подразделение дало разные цифры.
Это стало последней каплей, и мы пошли искать решение, которое помогло бы решить наши проблемы.
А можно все собрать в одном месте?
Надо было решить три основные задачи:
Создать единый доверенный источник данных, к которому смогут обращаться все желающие.
Создать единую систему именования данных.
Создать единую точку входа для всех отчетов.
Первое устранит расхождение в данных от разных подразделений. Второе упростит понимание данных, уберет разночтение терминов и понятий, а также позволит новым пользователям быстрее искать нужные данные. Наконец, третье упорядочит системы аналитики и отчетности, устранит дубли отчетов и даст возможность любому заинтересованному сотруднику быстро найти интересующий его отчет.
По сути, нам нужен Data Warehouse со всеми данными компании, ETL для преобразования данных в нужную форму и система визуализации. В настоящее время существует множество BI-инструментов и систем, которые могут предоставить все необходимые функции. В то время мы выбрали ClicData.
Что нам дала ClicData?
Более 250 коннекторов к различным системам, что упростило загрузку данных.
Централизованное хранилище данных.
Инструмент для ETL, который позволяет в визуальном редакторе создавать различные цепочки преобразований. Это удобно для людей без технического опыта.
Неплохой инструмент для визуализации данных.
Благодаря ClicData, мы построили систему, которая обеспечила единый доверенный источник данных, позволила реализовать конвенцию имен и терминов, облегчающую понимание данных. Настроили систему мониторинга, которая отслеживала корректность данных в источниках. Ну и, конечно же, создали единую точку входа для поиска любого отчета в компании.
Казалось бы, цели достигнуты. Но и в этой бочке меда нашлась ложка дегтя.
Переезжаем в AWS QuickSight
Чего нам не хватило в ClicData?
Невозможность сохранить настроенный ETL для быстрого восстановления.
Отсутствие версионирования для процессов ETL. Это делало любые изменения, если о них не сообщить, незаметными для пользователей. Из-за этого изменения, внесенные в промежуточных преобразованиях, могли нарушать работу системы в других местах, а поиск и устранение этих изменений отнимали много времени.
Сложность реализации некоторых преобразований данных через встроенный визуальный редактор. В некоторых случаях то, что решалось не слишком сложным SQL запросом, приводило к громоздким и сложным преобразованиям в ClicData.
Новое решение на основе сервисов AWS выглядит следующим образом:
Импорт данных из внешних источников осуществляется через AppFlow. Для многих популярных сервисов в AppFlow уже существуют готовые коннекторы, которые позволяют легко импортировать данные. Для систем, у которых готовых коннекторов нет, были написаны собственные лямбды для импорта данных.
Все сырые данные сохраняются в Glue Data catalog.
Для преобразования и обработки данных используем Glue Job.
Финальные данные сохраняются в Glue Data catalog.
Для координации всех процессов используем State Machines (Step Functions).
Визуализация отчетов на основе данных из Final Glue Data Catalog осуществляется с помощью QuickSight.
Итоговая схема упрощенно выглядит следующим образом:
Все Glue джобы написаны на Python с использованием библиотеки Pandas. От использования PySpark решили отказаться, так как это позволило использовать меньше ресурсов AWS и снизить стоимость запуска Glue Job.
Весь код хранится в репозитории, и теперь все изменения можно отследить по истории коммитов. Использование Terraform позволяет легко развернуть всю систему одним кликом. Данные доступны в Amazon QuickSight, а еще с ними можно поработать напрямую, используя Athena.
Дополнительно была разработана система мониторинга (дополнительные Glue джобы), которая обнаруживает ввод некорректных или неполных данных и вовремя сигнализирует об этом ответственным за данные сотрудникам.
Что касается цены такого решения, то в готовом виде расходы на AWS сервисы почти в 2 раза меньше, чем цена использования готового BI сервиса, но в момент активной разработки потратиться все же придется!
В итоге мы получили систему, которая позволяет контролируемо вносить изменения в ETL процесс. Все пользователи использует один доверенный источник данных, а топ-менеджмент может принимать решения на основе актуальных и проверенных данных.
