Системы данных стремятся к производству

За последние десять лет произошел почти полный оборот инструментов, доступных специалистам по данным. Глядя на сегодняшний современный стек данных, можно увидеть, что большинство инструментов (dbt, Looker, Snowflake, Fivetran, Hightouch, Census) не были коммерчески доступны в 2012 году. Целые категории (ELT, Reverse ETL, облачные хранилища) и платформы (активация данных, сетки данных) , структуры данных, контракты данных). (Или, в некоторых случаях, специалисты по данным заново открыли многолетние методы SWE.) Подписчики Twitter + Substack, проекты с открытым исходным кодом, карьеры и компании взлетали и падали. Возможностей предостаточно.

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

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

Системы стремятся к производству

• Резюме : работа с ценными данными и выходные данные в конечном итоге используются в сценариях использования, которые становятся все более важными / производственного уровня.
• Возможность : результаты группы данных могут быть распространены на гораздо большую и более значимую поверхность.
• Проблема : поскольку выходные данные потребляются более важными вариантами использования, не происходит соответствующего «укрепления» рабочих процессов, которые изначально были настроены очень упрощенным образом.
• Решение : создайте путь для облегченных потоков, которые будут переведены в «производство», отметьте время, затраченное на укрепление систем, по мере того, как они приближаются к производственному уровню.

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

• Резюме : данные могут быть преобразованы на многих этапах своего пути, бизнес-логика живет в различных инструментах.
• Возможности : современные инструменты обработки данных позволяют заинтересованным сторонам получать доступ к данным и выполнять преобразования последней мили, чтобы двигаться быстрее и разблокировать себя.
• Проблема : бизнес-логика в стеке делает воспроизводимость невозможной, преобразования последней мили не приносят пользы другим потребителям данных.
• Решение : Сократите области, в которые можно внедрить бизнес-логику, создайте политики «времени жизни» для преобразований последней мили, создайте культуру стандартизации + отмечайте доступ к кросс-функциональным кодовым базам.

Лето 2019 . Популярность газированной воды не остановить, но все еще есть некоторые не подозревающие мамы и владельцы магазинов алкогольных напитков. Вы инженер-аналитик на рынке алкоголя B2C. Ваши менеджеры по работе с клиентами (эксперты по употреблению алкоголя) ЗНАЮТ, что Когти разлетятся с полок, если только вы сможете достать их в магазинах. Это неуловимая система парето-улучшения на рынке в духе «выигрыш/выигрыш/выигрыш», где более качественные запасы приносят пользу покупателю, розничному продавцу и компании. Вам было поручено определить самые продаваемые товары, которых нет в винном магазине в вашей сети.

1. Внутреннее использование (инструмент BI/Looker)

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

select
  s.store_id,
  skus.sku_id,
  skus.market_rank
from dim_stores as s
left join tbl_top_selling_market_skus as skus
  on s.market_id = skus.market_id
left outer join dim_store_inventory as inv
  on s.store_id = inv.store_id
  and inv.sku_id = skus.sku_id
  and inv.remaining_qty > 0
where inv.sku_id is null
order by store_id, skus.market_rank desc
;

…первоначальный менеджер по работе с клиентами дает обратную связь на панели инструментов на протяжении всего процесса.

Примечание. Инструмент BI — это инфраструктура группы данных. Никакие идеи/прецеденты/продукты не вышли из сферы компетенции группы обработки данных. Ошибка имеет незначительные последствия, обратная связь вероятна + немедленная.

2. Внутреннее использование (Внутренние инструменты / Salesforce)

Однако команда по продажам / работе с клиентами / управлению учетными записями не проводит весь день в Looker — они проводят весь день в Salesforce. Наличие двух открытых браузеров — это боль. Это пример использования обратного ETL из учебника. Поместите данные там, где они будут использоваться . Несколько лет назад это было сложно, теперь это тривиально — подпишите поставщика обратного ETL, переместите свои точки данных из A в B менее чем за день.

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

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

Примечание. Salesforce НЕ является инфраструктурой группы обработки данных. Идеи и варианты использования вышли из сферы компетенции команды обработки данных, но не компании. Ничто не обращено к покупателю. Ошибка имеет незначительные последствия, но обратная связь не гарантируется. Добавлена ​​дополнительная логика (через человеческое суждение).

3. Внешнее использование (автоматизация маркетинга)

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

Необходимо еще несколько столбцов, после чего необработанная таблица подвергается обратному ETL-обработке в Hubspot/Iterable/Braze. Сотрудник CRM вносит последние штрихи в кампанию по электронной почте, и кампания по электронной почте под названием «Главные товары, которые вы не носите с собой» запускается.

… сотрудник CRM, отвечающий за электронную почту, замечает, что некоторые из самых продаваемых товаров (по количеству) — это глотки алкоголя. Это не соответствует видению бренда компании / варианту использования, желаемому клиентом. Большинство систем электронной почты допускают дополнительный уровень логики — сотрудник CRM использует свое суждение, чтобы отфильтровать любые элементы объемом 50 мл или меньше.

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

4. Внешнее использование (производственное приложение)

Команда данных получает информацию от команды AM и CRM: некоторые винные магазины довольно старомодны и не проверяют электронную почту. Другие винные магазины относятся к новой школе, и они не хотят ждать целую неделю, чтобы получить электронное письмо о том, что в тренде на их рынке. Группа решает зациклить команду приложения для розничной торговли, чтобы поместить «Главные товары, которые вы не носите с собой» в производственное приложение, на котором работают все розничные продавцы. Группа обработки данных перемещает свои выходные данные в корзину AWS S3, где они используются инженерами-технологами. Сотрудники винных магазинов теперь могут видеть этот список каждый день, без необходимости обращаться к менеджеру по работе с клиентами или переписываться по электронной почте. White Claw и Whispering Angel продаются в каждом магазине Америки.

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

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

И последнее предположение: группа инженеров, отвечающая за использование каналов инвентаризации (отличная от команды, отвечающей за приложение для розничной торговли), переходит на новую схему инвентаризации. Они не знают ни об одном шаге проекта «Главные предметы, которые вы не носите с собой», ни о зависимостях, которые команда данных построила поверх их работы, ни о зависимостях, которые другие построили поверх работы группы по данным. Они удаляют исходную таблицу. NULLs перетекают в Looker, Salesforce, Hubspot и производственное приложение для розничной торговли. Команда данных сломала prod.

Давайте вспомним, что произошло, и хорошее, и плохое:

С точки зрения специалиста по данным, который начал свою карьеру до «активации данных», все, что только что произошло (кроме финала), невероятно! То, что начиналось как инструментальная панель Looker, быстро превратилось в производственное приложение, демонстрирующее ценность для бизнеса на каждом этапе. Никакие ресурсы SWE не требовались до самого конца — когда предложенный продукт уже был одобрен пользователями.

Воздействие и карьерная траектория специалиста по данным ограничены областью, на которую он может повлиять. Аналитик бизнес-аналитики 2012 года был ограничен внутренними презентациями Tableau +. Современный специалист по работе с данными МОЖЕТ размещать строки в Salesforce, запускать маркетинговые электронные письма и создавать продукты данных для использования в производственных службах и приложениях. Это потрясающая новость!

С плохой стороны: профессионалы данных десять лет назад привыкли к сообщениям «Эй, данные выглядят не так». Худшим сценарием было добавление неправильных показателей в колоду доски. Сегодня команда обработки данных может просыпаться с уведомлениями Pagerduty о том, что они сломали Salesforce, Hubspot и производственное приложение, если Pagerduty даже настроена . Активация данных повысила ставки того, что может сломать команда данных.

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

Это не значит, что это не может быть дорого! Представьте себе результат науки о данных, который прогнозирует отток клиентов, и промо-код на 5 долларов отправляется, когда эта вероятность пересекает определенный порог. Теперь представьте, что модель неправильно переобучена, или перекалибрована, или что-то еще. Те же каналы активации данных могут быть использованы для непреднамеренной отправки промо-кодов на миллионы долларов.

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

Если вы помните дополнительную бизнес-логику:

• Менеджер по работе с клиентами использовал свое суждение и пропустил рекомендацию SKU спиртных напитков в пивных / винных магазинах.
• Сотрудник CRM удалил артикулы <= 50 мл из-за соображений, связанных с брендом.
• Команда приложения розничного продавца удалила сильно сезонные SKU из-за отзывов клиентов.

Итак, что мы можем сделать, чтобы решить эти проблемы?

Системы склонны к производству

Страшные истории, общие проблемы и технические решения для производственных систем были красноречиво описаны в твиттере данных и подстеке. Решения — это, в основном, лучшие практики, о которых SWE знали на протяжении десятилетий (или, как сказал Зак Кантер по-другому , разработка данных в статус-кво — это просто разработка программного обеспечения без передовых практик ). Несколько частей/принципов, которые лучше всего запомнились мне при работе с данными:

Команды обработки данных не контролируют свои входные данные (h/t Nick Schrock )

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

• Допустимость отдельных строк ( intкогда вы ожидаете int, <50 когда вы ожидаете <50)
• Достоверность агрегированных строк (предположения о степени детализации, бизнес-контекст вокруг количества строк, количество строк относительно вчерашнего дня, распределения агрегаций, таких как суммы, средние значения, p90s, медианы)
• Существование / устаревание данных (в последний раз таблицы обновлялись)

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

Это решения, которые могут быть реализованы группами обработки данных, которые выбирают правильные инструменты (нам нравятся «Большие надежды» ) и прилагают усилия. Это 20% проблемы. Оставшиеся 80% организационных и коммуникационных проблем являются причиной поломки систем. Вот общекорпоративные решения:

Создание выпусков данных производственного уровня

Или преднамеренно создавать данные . Компании, которые считают, что наука о данных сильна, также должны верить в намеренное создание производственных данных для использования машинного обучения и расширенной аналитики (h/t Yali Sasoon). Это требует партнерства с инженерами и согласования всей компании с тем, что данные могут создаваться преднамеренно, а не мучительно извлекаться.

Создавайте и отмечайте путь к производству

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

Системы стремятся к слепой федерации

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

Используйте единую плоскость управления для управляемой событиями оркестровки

Fivetran, dbt и Hightouch имеют возможность планировать задания с помощью расписаний cron и пользовательского интерфейса. Это позволяет строить оркестровку таким образом, чтобы не отображались неявные зависимости. Представьте, что Hightouch планируется перемещать exp_fb_click_idsкаждый день в 8 утра через пользовательский интерфейс. Fivetran и dbt не имеют представления об этой зависимости, как и те, кто участвует в кодовых базах выше по течению от Hightouch.

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

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

Группы данных должны быть знакомы с тем, как dbt предлагает структурировать проекты . Как правило, промежуточный слой организован и назван таким образом, что делает однозначное отношение к входным данным источника предельно четким. Используйте аналогичный шаблон для выходных данных. В той же степени должно быть очевидно, что объект Salesforce Opportunity и Account представляет собой таблицу dbt в промежуточной стадии, должно быть очевидно, что экспорт данных используется для одного и только одного варианта использования.

select * -- Extremely clear this comes from one and only one place
from raw.salesforce.opportunity
;

select * -- Extremely clear this comes from one and only one place
from raw.salesforce.account
;

select * -- Extremely clear this goes to one and only one place
from ml_outputs.model_results.exp_top_items_retailer_app
;

select * -- Extremely clear this goes to one and only one place
from ml_outputs.model_results.exp_top_items_salesfrce
;

Вместо того, чтобы резюмировать слоистость, я снова направлю вас к замечательной теме и определению Жана-Мишеля Лемье. Его общий совет с некоторыми особенностями данных, которые сработали для меня.

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

Сократите области, где бизнес-логика может быть внедрена на последней миле:

Hightouch и Census допускают преобразования SQL. Фифтран привык . Большинство потребителей активации данных (CRM Sales/CX, CDP) допускают либо уровень бизнес-логики SQL, либо уровень бизнес-логики с низким/отсутствием кода. По возможности не пишите бизнес-логику в этих инструментах. Если вы будете следовать однозначному сопоставлению экспорта группы данных с последующими вариантами использования, ваш обратный ETL всегда может быть:

select * from exp_table_for_single_use_case;

Изменения в бизнес-логике следует применять к этой модели dbt, а не к последней миле.

Создайте политики «Время жить» для преобразований последней мили:

Команда данных не может полностью избавиться от преобразований последней мили. Вы не хотите, чтобы ваши заинтересованные стороны чувствовали, что они заблокированы командой обработки данных. Всегда будет необходимость вносить исправления или повторять бизнес-логику, которая быстрее, чем обновление dbt PR + Snowflake.

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

Политика «Время жить» — это гравитационное откат к централизации. Разрешить преобразования «последней мили», но просмотреть их и вернуть бизнес-логику на центральный уровень БД/науки о данных с частотой, которая подходит для вашей группы обработки данных и заинтересованных сторон.

Создавайте культуру стандартизации + отмечайте доступ к кросс-функциональным кодовым базам

Люди по умолчанию пишут бизнес-логику в наиболее удобном для них инструменте. Для сотрудника CRM это может быть Hubspot / Iterable / Braze. Лучший способ для групп данных предотвратить разрастание бизнес-логики — это не только ограничить преобразования последней мили в других инструментах, но и пригласить других в свои инструменты.

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

Посадка самолета:

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

• Современный стек данных позволяет команде обработки данных производить все, что угодно, независимо от того, должны ли они быть, и без разрешения или видимости производственного инженера.
• Современный стек данных позволяет заинтересованным сторонам бизнеса добавлять бизнес-логику «последней мили» для поддержки производственных рабочих процессов, независимо от того, должны ли они быть такими, и без разрешения группы данных или видимости.

В какой-то момент ваши продукты данных сломают рабочее приложение. Маркетинговые электронные письма будут отправлены, чего не должно было быть. Команда CRM будет обвинять команду данных, команда данных будет обвинять команду инженеров-производителей. Один из самых важных уроков, который я усвоил, но с которым до сих пор сталкиваюсь каждый день: способность войти в напряженную комнату/масштабировать и напомнить всем, что мы все в одной команде, — это суперсила. Это настоящее резюме того, как запускать системы данных в производство.

Если вы можете создать культуру, в которой:

• Инженеры по производству создают выхлоп данных с намерением и волнением того, как данные будут использоваться.
• Члены группы данных ищут варианты использования, запрашивают отзывы и спрашивают своих заинтересованных лиц: «Эй, что вы на самом деле делаете с данными, которые я вам отправляю?»
• SWE могут наставлять и улучшать передовой опыт и стандарты групп обработки данных, чтобы поднять специальные потоки данных до производственного уровня.
• Члены группы данных могут наставлять и повышать уровень заинтересованных сторон бизнеса в отношении того, как добавить бизнес-логику, рамки для того, где логика принадлежит
• Каждая команда приглашает других в свою кодовую базу и поощряет долгосрочную перспективу общей архитектуры компании.

Ян Макомбер — руководитель отдела обработки данных и аналитики в Ramp, первой и единственной корпоративной карте, которая помогает компаниям тратить меньше. Ранее он был вице-президентом по аналитике и обработке данных в Drizly.

Есть и четвертая тенденция! Следите за новостями Data Systems Tend Towards Calculation , которых было слишком много, чтобы уместить их в одну статью.