Analytics craft

Alteryx — это платформа визуальной трансформации данных с удобным интерфейсом и инструментами перетаскивания. Тем не менее, Alteryx может испытывать трудности с увеличением сложности в рамках конвейера данных организации и может стать неоптимальным инструментом, когда компании начинают работать с большими и сложными преобразованиями данных. В таких случаях переход на dbt может быть естественным шагом, поскольку dbt предназначен для управления сложными конвейерами преобразования данных более масштабируемым, эффективным и явным образом. Также этот переход включал миграцию с локального SQL Server на облачные вычисления Snowflake. В этой статье мы описываем различия между Alteryx и dbt и как мы сократили время выполнения клиента в Alteryx с 6 часов до 9 минут с помощью dbt и Snowflake в Indicium Tech.

Команды процветают, когда каждому члену команды предоставляются инструменты, которые наилучшим образом дополняют и усиливают их навыки. Вы бы не дали Криштиану Роналду теннисную ракетку и не ожидали бы идеальной подачи! В Roche предоставление правильных инструментов нашим коллегам было критически важным для того, чтобы увеличить нашу команду по работе с данными с 10 основных инженеров до более чем 100 участников всего за два года. Мы приняли как dbt Core, так и dbt Cloud в Roche (решение dbt-squared, если хотите!) для быстрого масштабирования нашей платформы данных.

Примечание редактора — этот пост предполагает средний уровень знаний Jinja и разработки макросов в dbt. Для введения в Jinja в dbt ознакомьтесь с документацией и бесплатным курсом Jinja, Macros, Packages.

Jinja приносит много возможностей в dbt, позволяя нам использовать ref(), source(), условный код и макросы. Но, хотя Jinja приносит гибкость, она также добавляет сложность, и, как часто бывает с кодом, вещи могут работать не так, как ожидалось.

Макрос debug() в dbt — отличный инструмент для тех, кто пишет много кода на Jinja, но может быть сложно понять, как его использовать и какие преимущества он приносит.

Давайте погрузимся в последний случай, когда я использовал debug() и как он помог мне решить ошибки в моем коде.

Аудит таблиц — это важная часть ежедневных задач аналитиков данных, особенно при рефакторинге таблиц, созданных с использованием SQL-хранимых процедур или Alteryx Workflows. В этой статье мы представляем, как пакет audit_helper может (как следует из названия) помочь в процессе аудита таблиц, чтобы убедиться, что рефакторинг модели дает (почти) такой же результат, как и оригинальная, основываясь на нашем опыте использования этого пакета для поддержки наших клиентов в Indicium Tech®.

В Teads мы используем BigQuery (BQ) для построения нашей аналитической платформы с 2017 года. Как было представлено в предыдущей статье, мы разработали конвейеры, которые используют множественные свертки, агрегируемые в витринах данных. Большинство из них вращаются вокруг временных рядов, и поэтому разделение на основе времени часто является наиболее подходящим подходом.

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

За последние несколько месяцев Montreal Analytics, консалтинговая компания полного цикла в области данных, обслуживающая организации по всей Северной Америке, сертифицировала более 25 инженеров аналитики dbt, что принесло им награду dbt Platinum Certification 2022 года.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итак, у вас есть бизнес-вопрос, у вас есть сырые данные в вашем data warehouse, и у вас настроен 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, что в конечном итоге привело к значительной экономии средств и созданию пути для периодических проверок улучшений.