Analytics craft

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

Когда мы думаем о реальных сценариях, мы естественно склонны думать о ключевых рисках и механистических причинах. Однако в более абстрактном мире данных многие наши тесты данных часто склоняются к одной из двух крайностей: применению шаблонных тестов (null, PK-FK отношения и т.д.) из мира традиционного управления базами данных или игре с новыми инструментами, которые обещают поймать наши самые дикие ошибки с помощью обнаружения аномалий и искусственного интеллекта.

Между этими двумя крайностями лежит разрыв, который заполняется человеческим интеллектом. Инженеры аналитики могут создавать более эффективные тесты, внедряя свое понимание того, как были созданы данные, и особенно как эти данные могут пойти наперекосяк (тема, о которой я писала ранее). Хотя такие выразительные тесты будут уникальны для нашей области, скромные изменения в нашем мышлении могут помочь нам реализовать их с помощью наших стандартных инструментов. Этот пост демонстрирует, как простое проведение тестов по группам может расширить вселенную возможных тестов, повысить чувствительность существующего набора и помочь держать наши данные "на правильном пути". Эта функция теперь доступна в dbt-utils.

В седьмом классе я решил, что пора выбрать реалистичную карьеру, к которой я буду стремиться, и поскольку в моей жизни был бухгалтер, которым я действительно восхищался, я выбрал именно это. Примерно десять лет спустя я закончил обучение по специальности бухгалтерский учет с дополнительной специализацией в области бизнес-информационных систем (что по сути означает, что я программировал на C# в четырех или пяти классах). Я быстро сдал экзамены CPA и стал сертифицированным бухгалтером, как только выполнил требование о двухлетнем опыте. Первые несколько лет я работал в небольшой фирме, занимаясь составлением налоговых деклараций, но мне казалось, что я недостаточно учусь, поэтому я перешел в более крупную фирму прямо перед началом пандемии. Факторы, которые привели меня к смене отрасли, многочисленны, но я постараюсь быть кратким: налоговая индустрия полагается на недоплату своим работникам для поддержания маржи и предотвращения избыточности, моя будущая работа в качестве менеджера не привлекала меня, и моя работа двигалась в направлении, которое меня не вдохновляло.

Почему мы это создали: Краткая история команды профессиональных услуг dbt Labs​

Если вы посетили Coalesce 2022, вы знаете, что секрет раскрыт — команда профессиональных услуг dbt Labs — это не просто группа опытных консультантов по данным; мы также межгалактическая группа инопланетян, путешествующих по Млечному Пути с миссией помочь аналитическим инженерам успешно внедрять и управлять dbt по всей галактике.

После того как ваше будет построено, подавляющее большинство ваших данных будет поступать из других SaaS-инструментов, внутренних баз данных или платформ данных клиентов (CDP). Но есть еще один незамеченный герой в наборе инструментов аналитической инженерии: скромная электронная таблица.

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

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

Данные — это индустрия обходных путей. Большинство людей в этой области случайно попадают в нее, осматриваются, и если им нравится то, что они видят, они строят здесь карьеру. Это особенно верно в области аналитического инжиниринга. Каждый аналитический инженер, с которым я разговаривала, представлял себя занимающимся чем-то другим, прежде чем случайно найти эту работу. Это поднимает вопрос: как можно стать аналитическим инженером намеренно? Это вопрос, на который стремится ответить Программа Foundry от dbt Labs.

Давайте обсудим, как преобразовать события из архитектуры микросервисов, управляемой событиями, в реляционные таблицы в хранилище данных, таком как Snowflake. Вот несколько вопросов, которые мы рассмотрим:

• Почему вам может понадобиться использовать такую архитектуру
• Как структурировать ваши сообщения о событиях
• Как использовать макросы dbt, чтобы упростить загрузку новых потоков событий

Когда вы учились в школе, играли ли вы когда-нибудь в "Телефон"? Первый человек шепчет слово второму, тот шепчет его третьему, и так далее. В конце цепочки последний человек громко объявляет услышанное слово, и, увы! Оно превращается в совершенно непонятное слово, не имеющее ничего общего с оригиналом. Такова жизнь без инженера по аналитике в вашей команде.

Итак, у вас есть бизнес-вопрос, у вас есть сырые данные в вашем , и у вас настроен dbt. Вы в идеальной позиции, чтобы быстро завершить создание этого подготовленного набора данных! Или нет?

Почему люди используют cherry pick для верхних веток?​

Самая простая стратегия ветвления для внесения изменений в код вашего репозитория dbt проекта — это иметь единственную основную ветку с кодом уровня продакшн. Чтобы обновить ветку main, разработчик должен:

1. Создать новую ветку для функции непосредственно от ветки main
2. Внести изменения в эту ветку для функции
3. Протестировать локально
4. Когда будет готово, открыть pull request для слияния изменений обратно в ветку main

Если вы только начинаете работать с dbt и решаете, какую стратегию ветвления использовать, этот подход — часто называемый "непрерывным развертыванием" или "прямым продвижением" — является оптимальным. Он предоставляет множество преимуществ, включая:

• Быстрый процесс продвижения для внесения новых изменений в продакшн
• Простая стратегия ветвления для управления

Основной риск, однако, заключается в том, что ваша ветка main может стать уязвимой для багов, которые могут проскользнуть через процесс утверждения pull request. Чтобы провести более интенсивное тестирование и контроль качества перед слиянием изменений в коде в продакшн, некоторые организации могут решить создать одну или несколько веток между ветками для функций и main.

Если вы когда-либо слышали о Мари Кондо, вы знаете, что у нее невероятно успокаивающий и медитативный метод наведения порядка в физических пространствах. Ее метод КонМари заключается в категоризации, избавлении от ненужных вещей и создании устойчивой системы для хранения вещей.

Как аналитический инженер в вашей компании, разве это не идеально описывает вашу работу?! Я люблю думать о практике аналитического инжиниринга как о применении метода КонМари к моделированию данных. Наша цель как аналитических инженеров не только организовать и очистить данные, но и спроектировать устойчивый и масштабируемый проект трансформации, который будет легким для навигации, роста и потребления конечными пользователями.

Давайте поговорим о том, как применить метод КонМари к новому проекту миграции. Возможно, вам поручили распаковать кухню в вашем новом доме; другими словами, вы инженер, нанятый для переноса ваших устаревших SQL-запросов в dbt и обеспечения их бесперебойной работы. Это может означать, что вы берете запрос из 1500 строк SQL и перерабатываете его в модульные части. Когда вы закончите, у вас будет производительный, масштабируемый, легкий для навигации поток данных.

Анализ финансовых данных редко бывает "увлекательным". В частности, создание и анализ данных финансовой отчетности может быть чрезвычайно сложным и не оставляет места для ошибок. Если вам когда-либо не повезло создавать финансовые отчеты для нескольких систем, то вы понимаете, насколько это может быть невероятно раздражающим — каждый раз изобретать велосипед заново.

Этот процесс может включать множество вариаций, но обычно он предполагает часы, дни или недели работы с финансовым отделом для:

• Понимания, что должно быть включено в отчеты
• Моделирования этих отчетов
• Проверки этих отчетов
• Внесения корректировок в вашу модель
• Вопросов о своем существовании
• Повторной проверки этих отчетов

Вы можете представить, насколько много времени может занять этот процесс. К счастью, вы можете использовать основные принципы бухгалтерского учета и другие инструменты для более легкого и эффективного создания действенных финансовых отчетов. Таким образом, вы сможете потратить больше времени на углубленный финансовый анализ.

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

Иногда нам везет, и у нас есть источники данных с уже встроенными ключами — например, данные Shopify, синхронизированные через их API, имеют простые в использовании ключи на всех таблицах, записанных в ваше хранилище. Если это не так, или если вы строите модель данных с составным ключом (то есть данные уникальны по нескольким измерениям), вам придется полагаться на какую-то стратегию для создания и поддержания этих ключей самостоятельно. Как это сделать с помощью dbt? Давайте разберемся.

Чем больше становится экосистема данных, тем больше ее пользователи и заинтересованные стороны ожидают от нее согласованности. По мере того как соотношение моделей данных к числу членов команды (не говоря уже о заинтересованных сторонах) стремительно растет, согласованная модель часто выступает в качестве каркаса для этого роста.

Сегодня самым большим инструментом в арсенале является размерное моделирование, которое предлагает достаточно согласованности, чтобы стать доминирующим подходом в этой области. Но что, если мы закроем этот ящик с инструментами, сделаем перерыв и вместо этого обратимся к нашей книжной полке?

Другими словами, что если мы расскажем историю?

Когда вы запускаете задачу, содержащую более 1700 моделей, как определить, что является "хорошим" временем выполнения? Если весь процесс занимает 3 часа, это замечательно или ужасно? Хотя существует множество возможных ответов в зависимости от размера набора данных, сложности моделирования и исторических времен выполнения, суть обычно заключается в вопросе "достигли ли вы своих SLA"? Однако в мире облачных вычислений, где счета выставляются на основе использования, вопрос на самом деле звучит так: "достигли ли вы своих SLA и остались в рамках бюджета?"

Здесь, в dbt Labs, мы использовали вкладку Model Timing в нашем внутреннем аналитическом проекте dbt, чтобы помочь нам выявить неэффективности в нашей инкрементальной задаче dbt Cloud, что в конечном итоге привело к значительной экономии средств и созданию пути для периодических проверок улучшений.

Примечание редактора — с момента создания этого поста, владение пакетом pre-commit-dbt перешло к другой команде, и он был переименован в dbt-checkpoint. Настроен редирект, что означает, что приведенный ниже пример кода все еще будет работать. Также можно заменить repo: https://github.com/offbi/pre-commit-dbt на repo: https://github.com/dbt-checkpoint/dbt-checkpoint в вашем файле .pre-commit-config.yaml.

В dbt Labs у нас есть лучшие практики, которым мы предпочитаем следовать при разработке проектов dbt. Одна из них, например, заключается в том, что все модели должны иметь как минимум тесты unique и not_null на их первичный ключ. Но как мы можем применять такие правила?

Этот вопрос становится трудным для ответа в крупных проектах dbt. Разработчики могут не следовать одним и тем же соглашениям. Они могут не знать о прошлых решениях, и проверка pull-запросов в git может стать более сложной. Когда в проектах dbt сотни моделей, трудно понять, какие модели не имеют определенных тестов и не соблюдают ваши соглашения.

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

Если ваша команда активно работает с хранимыми процедурами, и вы когда-либо сталкивались со следующими или похожими проблемами:

• дашборды не обновляются вовремя
• Изменение кода конвейера на основе запросов от ваших потребителей данных кажется слишком медленным и рискованным
• Трудно отследить происхождение данных в вашем производственном отчете

Стоит рассмотреть, может ли альтернативный подход с dbt помочь.

Существует множество причин, по которым вы, как инженер по аналитике, можете захотеть зафиксировать полную историю версий данных:

• Вы работаете в отрасли с очень высокими стандартами управления данными
• Вам нужно отслеживать крупные OKR с течением времени, чтобы отчитываться перед заинтересованными сторонами
• Вы хотите создать окно для просмотра истории с прямой и обратной совместимостью

Это часто ситуации с высокими ставками! Поэтому точность в отслеживании изменений в ваших данных имеет ключевое значение.

Давайте представим ситуацию. Вы — инженер по аналитике в вашей компании. У вас есть несколько реляционных наборов данных, поступающих в ваш хранилище, и, конечно, вы можете легко получить доступ к этим таблицам и преобразовать их с помощью dbt. Вы правильно объединили таблицы и имеете почти в реальном времени отчеты о связях для каждого entity_id, как они существуют в данный момент.

Но в какой-то момент ваш заинтересованный пользователь хочет знать, как каждый объект изменяется с течением времени. Возможно, важно понять тенденцию продукта на протяжении его жизненного цикла. Вам нужна история каждого entity_id во всех ваших наборах данных, потому что каждая связанная таблица обновляется по своему собственному графику.

Какая ваша первая мысль? Ну, вы опытный инженер по аналитике и знаете, что хорошие люди из dbt Labs имеют решение для вас. И тут вас осеняет — ответ в снимках!

Если вы читаете эту статью, вероятно, вы хотите узнать, как лучше оптимизировать ваши запросы в Redshift, и, возможно, вы хотите узнать, как это сделать в сочетании с dbt.

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

Инженеры по аналитике (AEs) постоянно работают с названиями моделей в своем проекте, поэтому именование важно для поддерживаемости вашего проекта в том, как вы к нему обращаетесь и работаете в нем. По умолчанию, dbt будет использовать имя файла вашей модели в качестве имени представления или таблицы в базе данных. Но это означает, что имя имеет жизнь за пределами dbt и поддерживает многих конечных пользователей, которые, возможно, никогда не узнают о dbt и откуда взялись эти данные, но все равно будут обращаться к объектам базы данных в базе данных или инструменте бизнес-аналитики (BI).

Конвенции именования моделей обычно создаются AEs для AEs. Хотя это полезно для поддерживаемости, это исключает людей, для которых именование моделей должно в первую очередь приносить пользу: конечных пользователей. Хорошие конвенции именования моделей должны создаваться с одной мыслью: предполагайте, что ваш конечный пользователь не будет иметь никакого другого контекста, кроме имени модели. Папки, схемы и документация могут добавить дополнительный контекст, но они могут не всегда присутствовать. Ваши имена моделей всегда будут отображаться в базе данных.

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

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