Что такое моделирование данных с использованием запросов?

Понимаем моделирование данных через запросы

Если вы пропустили это, несколько недель назад у меня было живое шоу с одним из соавторов “Fundamentals Of Data Engineering”, который определил концепцию моделирования данных на основе запросов.

Теперь он ссылался на стандартные концепции моделирования данных, которые включают:

1. Концептуальное
2. Логическое
3. Физическое
4. но добавляют 4-е – моделирование данных, основанное на запросах

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

• Мягкие навыки, которыми должен обладать каждый специалист по обработке данных
• Векторные базы данных для ваших приложений LLM + Streamlit
• Самообслуживание аналитики данных как иерархия потребностей

Вместо этого, мы, вероятно, просто создаем таблицы для поддержки одного запроса. Или, вновь по словам Джо, моделируем данные, основанные на запросах.

Но что такое моделирование данных, основанное на запросах, и есть ли оно место в мире данных?

Моделирование данных, основанное на запросах

Источник: автор

Теперь нет официального определения для моделирования данных на основе запросов, или моделей JIT, хотя в прошлом у нас был термин ‘ schema-on-read‘, который в чем-то похож.

Но думаю, что многие из нас знают, что это.

Это создание таблиц или наборов данных в ответ на запрос одного стороннего лица. Возможно, есть некоторый сбор требований, но только для одного заинтересованного лица.

Преимущества моделирования данных, основанного на запросах

Как и любой выбор, который вы делаете как инженер, есть плюсы и минусы.

• Быстрое получение первоначальных идей – Самое явное преимущество разработки подхода на основе запросов – это скорость получения идей (по крайней мере, в краткосрочной перспективе).
• Самообслуживание – Инструменты, такие как dbt, стали отличным входом в данные для многих команд. Они также помогли ускорить возможность аналитикам и тем, кто владеет SQL, перейти от запроса к таблице. В свою очередь, это также привело команды к достижению «Священного Грааля» самообслуживания гораздо быстрее. Когда я впервые начал в мире данных, я обратился к команде EDW с запросом, который я создал и должен был выполнить. Мне пришлось ждать 3-4 месяца, чтобы увидеть его внедренным…в виде представления. Это было нечто невероятное. Многие аналитические команды не могут эффективно работать в такой среде и, в свою очередь, скорее всего создадут личную команду IT и все равно создадут хранилище данных.
• Заинтересованные стороны будут довольны в краткосрочной перспективе – Многие команды данных застревают в петлях постоянного разработки JIT, потому что заинтересованным сторонам часто требуется это делать. Менеджеры и директоры нуждаются в цифрах, чтобы передать их вице-президентам, вице-президенты нуждаются в цифрах, чтобы передать их руководству, и руководство нуждается в цифрах, чтобы передать их совету директоров. И постоянное давление оказывает давление на новоиспеченных аналитиков или перегруженных инженеров данных, которые хотят/были вынуждены выполнять то, что требует их менеджеры.

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

Ответы.

Все довольны.

Недостатки моделирования данных, основанного на запросах

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

• Уменьшение гибкости при необходимости в изменениях – Хотя время разработки ускоряется, возможность реагировать и изменять то, что делает система, будет ухудшаться по мере накопления большего количества моделей, зависимостей и технического долга. Каждая новая слабая связь в развивающейся сложной системе приводит к возможной точке отказа, о которой никто может не знать.
• Отсутствие согласованных метрик – Когда команды данных применяют подход JIT, есть большая вероятность того, что одни и те же метрики будут разрабатываться несколькими командами с использованием несколько различных методологий, что приводит к классической проблеме, когда числа команд не совпадают. Многие компании, которые я видел, включая FB, создают посредством слоя метрик или портала, который помогает определить ключевые метрики и указывает, где они используются.
• Spaghetti Pipeline – Когда JIT сильно полагается, созданные системы потоков данных могут быстро превратиться в спагетти-потоки. Вы обнаружите себя с 18 DAG, чтобы понять, что поле customer_category, о котором вы думали, что оно приходит из источника A, на самом деле заполняется местом назначения B и в конечном итоге возвращается обратно в источник A (я видел это).
• Менее надежные наборы данных – Помимо риска зависимости от самого себя. Еще одна проблема заключается в том, что даже кажущееся незначительным изменение в одном потоке данных может иметь серьезные последствия. Поскольку ни одна таблица не определена как основная, и контроль минимален, трудно полностью понять вес изменения. Сейчас у нас есть решения для этого, такие как поток данных; но до некоторой степени, если вы слишком полагаетесь на поток данных, чтобы определить, насколько важен набор данных, у вас возможно уже есть проблема.
• Стоимость – Когда я впервые начал работать в мире данных, заинтересованные стороны сказали мне, что они хотят получить данные в режиме реального времени для своих панелей управления. Поэтому я нажал “живые данные” на моих панелях Tableau и опубликовал их.

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

С учетом всех этих недостатков, имеет ли Query-Driven Modeling место в мире данных?

Возможность Query-Driven Models в мире данных

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

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

Это в основном то, что мы имели в Facebook.

Команда, в которой я работал, создала то, что я называл “Data As Infra”. То есть таблицы, которые мы строили, использовались многими другими командами в Facebook. Другие инженеры данных создавали свои представления и аналитику на основе того, что мы создавали.

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

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

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

Источник: Чад Сэндерсон

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

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

Не разрабатывать надежные наборы данных можно поддерживать несколько вариантов использования.

Дизайн — это после мыслей

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

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

Возьмем, например, балку, подвергшуюся новым нагрузкам в здании.

В конечном итоге, она рушится и, вероятно, стягивает с собой еще несколько балок.

Является ли запросо-ориентированное моделирование типом моделирования данных? Конечно.

Но вы должны хорошо понимать риски.

Статья изначально опубликована здесь. Перепечатано с разрешения.