Точк а зрения dbt
В 2015-2016 годах команда из RJMetrics имела возможность наблюдать и участвовать в значительной эволюции аналитической экосистемы. Семена dbt были задуманы в этой среде, и точка зрения, изложенная ниже, была написана, чтобы отразить то, чему мы научились, и как, по нашему мнению, мир должен измениться. dbt — это наша попытка решить проблемы рабочего процесса, которые мы наблюдали, и, таким образом, эта точка зрения является наиболее основополагающим заявлением о целях проекта dbt.
Остальная часть этого документа в значительной степени не редактировалась с оригинального поста.
Аналитика сегодня
Центр тяжести в зрелых аналитических организациях сместился от проприетарных, комплексных инструментов к более компонуемым решениям, состоящим из:
- скриптов и/или инструментов интеграции данных,
- высокопроизводительных аналитических баз данных,
- SQL, R и/или Python, и
- инструментов визуализации.
Это изменение открыло значительные возможности, но аналитические команды (включая нашу) все еще сталкиваются с трудностями в постоянной доставке высококачественной аналитики с низкой задержкой.
Мы считаем, что у аналитических команд есть проблема с рабочим процессом. Слишком часто аналитики работают в изоляции, и это создает неоптимальные результаты. Знания изолированы. Мы слишком часто переписываем анализы, которые уже были написаны коллегой. Мы не понимаем нюансов наборов данных, с которыми мы менее знакомы. Мы различаемся в наших расчетах общей метрики.
Мы убедились после сотен разговоров, что эти условия в значительной степени являются статус-кво даже для сложных аналитических команд. В результате организации страдают от снижения скорости принятия решений и качества решений.
Аналитика не должна быть такой. На самом деле, руководство по решению этих проблем уже существует — в наших командах по разработке программного обеспечения. Те же методы, которые используют команды разработчиков программного обеспечения для совместной работы над быстрым созданием качественных приложений, могут применяться и к аналитике. Мы считаем, что пришло время создать открытый набор инструментов и процессов, чтобы это произошло.
Аналитика — это сотрудничество
Мы считаем, что методы и рабочий процесс зрелой аналитической команды должны иметь следующие функции сотрудничества:
Контроль версий
Аналитический код — будь то Python, SQL, Java или что-то еще — должен быть под контролем версий. Анализ меняется по мере эволюции данных и бизнеса, и важно знать, кто что изменил и когда.
Обеспечение качества
Плохие данные могут привести к плохим анализам, а плохие анализы — к плохим решениям. Любой код, который генерирует данные или анализ, должен быть проверен и протестирован.
Документация
Ваш анализ — это программное приложение, и, как и любое другое программное приложение, у людей будут вопросы о том, как его использовать. Даже если это может показаться простым, на самом деле строка "Доход" может означать десятки вещей. Ваш код должен быть снабжен базовым описанием того, как его следует интерпретировать, и ваша команда должна иметь возможность добавлять к этой документации по мере возникновения дополнительных вопросов.
Модульность
Если вы создаете серию анализов о доходах вашей компании, и ваш коллега делает то же самое, вы должны использовать одни и те же входные данные. Копирование и вставка — не лучший подход здесь — если определение базового набора изменится, его нужно будет обновить везде, где оно использовалось. Вместо этого подумайте о схеме набора данных как о его публичном интерфейсе. Создавайте таблицы, представления или другие наборы данных, которые предоставляют согласованную схему и могут быть изменены, если изменится бизнес-логика.
Аналитический код — это актив
Код, процессы и инструменты, необходимые для создания этого анализа, являются основными инвестициями организации. Мы считаем, что рабочий процесс зрелой аналитической организации должен обладать следующими характеристиками, чтобы защитить и развивать эти инвестиции:
Среды
Аналитика требует нескольких сред. Аналитики нуждаются в свободе работать, не влияя на пользователей, в то время как пользователи нуждаются в гарантиях уровня обслуживания, чтобы они могли доверять данным, на которые они полагаются для выполнения своей работы.
Гарантии уровня обслуживания
Аналитические команды должны поддерживать точность всех анализов, которые были переведены в производство. Ошибки должны рассматриваться с той же степенью срочности, что и ошибки в производственном продукте. Любой код, выводимый из эксплуатации, должен проходить процесс устаревания.
Проектирование для поддерживаемости
Большая часть затрат на разработку программного обеспечения приходится на этап поддержки. Из-за этого инженеры-программисты пишут код с учетом поддерживаемости. Однако аналитический код часто бывает хрупким. Изменения в базовых данных ломают большинство аналитических кодов так, что их трудно предсказать и исправить.
Аналитический код должен быть написан с учетом поддерживаемости. Будущие изменения в схеме и данных должны быть предвидены, и код должен быть написан так, чтобы минимизировать соответствующее воздействие.
Аналитические рабочие процессы требуют автоматизированных инструментов
Часто большая часть аналитического рабочего процесса является ручной. Перемещение данных от источника к назначению, от этапа к этапу может занимать большую часть времени аналитика. Инженеры-программисты создают обширные инструменты для поддержки ручных частей своей работы. Чтобы реализовать предлагаемые нами аналитические рабочие процессы, потребуются аналогичные инструменты.
Вот один пример автоматизированного рабочего процесса:
- модели и анализ загружаются из нескольких репозиториев контроля версий,
- код настраивается для данной среды,
- код тестируется, и
- код разворачивается.
Такие рабочие процессы должны быть построены для выполнения одной командой.