Для роста и нормального функционирования компании руководители принимают различные решения: сколько и каких сотрудников нанять, нужно ли брать кредит для закрытия кассового разрыва, сколько денег выделить на закупку печенек в следующем квартале, стоит ли инвестировать в новое оборудование и т. д. Чтобы принять решение, нужна информация. Недостоверная информация или ее недостаток могут привести к ошибочным решениям, что, в свою очередь, вызовет проблемы. Поэтому любая компания, независимо от размера, строит систему аналитики и отчетности.
С чего все обычно начинается?
Наиболее распространённое решение на старте — это использование 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 процесс. Все пользователи использует один доверенный источник данных, а топ-менеджмент может принимать решения на основе актуальных и проверенных данных.
ссылка на оригинал статьи https://habr.com/ru/articles/824450/
Добавить комментарий