KonMari ваши данные: Планирование миграции запросов с использованием метода Мари Кондо

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

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

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

в ЭТО!

Это сила метода КонМари. Давайте применим метод конкретно к данным:

Метод КонМари

1. Обязуйтесь вместе с заинтересованными сторонами навести порядок в этом проекте
2. Представьте идеальное состояние этого запроса
3. Завершите удаление ненужных моделей и столбцов
4. Наведите порядок по категориям
5. Следуйте правильному порядку — от конечного к началу
6. Убедитесь, что результат приносит радость, то есть удовлетворяет все потребности потребителей

Готовы навести порядок?! Призовите Мари Кондо!

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

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

Шаг 1: Обязуйтесь вместе с заинтересованными сторонами навести порядок в этом проекте

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

Воспользуйтесь возможностью встретиться с вашими заинтересованными сторонами и убедитесь, что все на одной волне. Это, вероятно, ваши читатели отчетов и создатели отчетов.

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

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

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

Вот несколько примерных вопросов, которые вы захотите задать на этой первоначальной встрече:

• Как в настоящее время используется эта таблица данных?
• Какие преобразования выполняются поверх этой таблицы? Агрегации? Фильтры? Корректировки? Объединения?
• С какими проблемами вы сталкиваетесь с этой таблицей? Медленно выполняется запрос? Неправильные результаты? Отсутствующие столбцы? Ненужные столбцы?
• На какие вопросы вы хотите, чтобы эта таблица ответила? Можно ли разбить эти вопросы? То есть, можно ли разбить эту таблицу на более мелкие таблицы, каждая из которых отвечает на разные части вопроса? Или лучше оставить ее как одну таблицу?
• Как мы можем сгруппировать эти источники? Подумайте о потреблении — где эти подзапросы будут потребляться в дальнейшем? Имеет ли смысл объединять эти источники на более ранних этапах?
• Если исходный вывод таблицы неверен, есть ли у них таблица с правильными данными, с которой мы можем свериться? Как мы узнаем, что это правильно?

Шаг 2: Представьте идеальное состояние вашего проекта

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

Давайте спланируем, как распаковать наш запрос. Возможно, вы работаете с этим: более 30 источников, все упакованы в один СУПЕР-запрос 🦸.

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

Теперь мы можем взглянуть на детали этого кода и начать категоризацию. Вы можете начать строить, как это может выглядеть как DAG в инструменте для картирования процессов, таком как Whimsical.

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

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

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

*Прежде чем обвинять меня в мечтательности, это результат реального клиентского проекта! Мы разбили почти 1500 строк кода в одном запросе на этот красивый водопад. Мари Кондо была бы горда.

Хотя вы не обязаны проектировать ваш поток именно так, крайне важно учитывать модульность, читаемость, масштабируемость и производительность в вашем дизайне. Проектируйте с намерением! Помните, не ставьте вилки слишком далеко от посудомоечной машины.

Шаг 3: Завершите удаление ненужных моделей и столбцов

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

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

Вот несколько вещей, на которые стоит обратить внимание:

• Избавьтесь от неиспользуемых источников — есть пакет для этого!
• Удалите столбцы, которые импортируются с помощью CTE, но просто засоряют ваш запрос
• Приводите только те столбцы, которые вам нужны (это особенно важно для BigQuery и Redshift для повышения производительности)
• Где возможно, делайте то же самое с строками! Применяется ли фильтр в конечном запросе, который можно переместить в CTE или даже в промежуточную модель?
• Помните, что в большинстве случаев более производительно фильтровать и обрезать данные до того, как произойдут объединения

Шаги 4 и 5: Наведите порядок по категориям и следуйте правильному порядку — от начала к концу

Мы готовы распаковать нашу кухню. Используйте ваш дизайн как руководство для модульности.

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

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

Стройте с целью масштабирования — когда вам могут понадобиться эти промежуточные модели снова? Придется ли вам повторять те же объединения? Надеюсь, вы спроектировали с достаточным намерением, чтобы знать, что ответ на последний вопрос — "нет". Избегайте повторения объединений!

Шаг 6: Убедитесь, что результат приносит радость, то есть удовлетворяет все потребности потребителей

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

Задайте себе эти вопросы:

• Приносит ли мой законченный дизайн радость? То есть, выполнил ли я свою сборку в соответствии с моим масштабируемым дизайном?
• Легко ли в нем ориентироваться? Легко ли его понять?
• Все ли части легко использовать, когда мне нужно будет воспользоваться модульностью в будущем?
• Хорошо ли выполняется мой конечный запрос и удовлетворяет ли он все потребности потребителей?

Если ваш ответ "да" на эти вопросы, вы вызвали РАДОСТЬ. Отличная работа, друг! Если ответ "нет", подумайте, какие части нужно спланировать заново. Если ваш код не масштабируем или его трудно использовать потребителям, начните с первого шага снова — соберите ваших потребителей, постарайтесь понять, где произошел сбой в коммуникации, и перепроектируйте.