Zero-ETL, ChatGPT и будущее инженерии данных

Zero-ETL, ChatGPT и будущее инженерии данных новые технологии и перспективы

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

Самыми заметными, недавними примерами являются Snowflake и Databricks, разрушающие понятие базы данных и вводящие новую эру современного стека данных.

В рамках этого движения Fivetran и dbt фундаментально изменили поток данных от ETL к ELT. Hightouch прерывает “поглощение мира” SaaS в попытке сдвинуть центр тяжести к хранилищу данных. Monte Carlo присоединилась к схватке и сказала: “Возможно, ручное кодирование модульных тестов инженерами – не лучший способ гарантировать качество данных”.

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

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

  • Zero-ETL нацелена на импорт данных
  • Искусственный интеллект и крупномасштабные языковые модели могут изменить процесс преобразования
  • Контейнеры продуктов данных рассматриваются как основной строительный блок данных

Придется ли нам всё перестраивать (снова)? Пока эра Hadoop еще не закончилась.

Ответ – да, конечно, нам придется перестраивать наши системы обработки данных. Вероятно, несколько раз за нашу карьеру. Настоящие вопросы заключаются в том, почему, когда и как (в таком порядке).

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

Практичность и компромиссы

Фото от Tingey Injury Law Firm на Unsplash

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

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

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

Zero-ETL

Что это такое: Неправильное название для одной вещи; конвейер данных все еще существует.

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

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

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

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

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

Преимущества: Снижение задержки. Отсутствие дублирования хранения данных. Одно источников сбоя меньше.

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

Кто ведет это: За этим модным словом стоит Amazon Web Services (Aurora to Redshift), но Google Cloud Platform (BigTable to BigQuery) и Snowflake (Unistore) также предлагают подобные возможности. Snowflake (Secure Data Sharing) и Databricks (Delta Sharing) также стремятся к тому, что они называют “активное совместное использование данных без копирования”. Этот процесс на самом деле не включает ETL, а открывает расширенный доступ к данным непосредственно в их месте хранения.

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

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

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

Одна большая таблица и большие языковые модели

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

На сегодняшний день существует множество стартапов, которые стремятся использовать возможности больших языковых моделей, таких как GPT-4, для автоматизации этого процесса, позволяя пользователям “запрашивать” данные своим естественным языком в удобном интерфейсе.

По крайней мере до момента, когда нашим новым роботизированным повелителям не станете официальным языком Бинарный код.

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

Но что, если эту сложность удалось бы упростить, заполнив всю необработанную информацию в одну большую таблицу?

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

Как концепция, это не настолько утопично. Некоторые команды данных уже используют стратегию одной большой таблицы (One Big Table, OBT), которая имеет своих сторонников и противников.

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

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

Недостатки: Это слишком большая свобода?Специалисты по данным знакомы с мучительными особенностями данных (часовые пояса, что такое “учетная запись”?), в отличие от большинства заинтересованных сторон в бизнесе. Выгодно ли нам иметь представительство вместо непосредственной демократии данных?

Кто руководит этим: Супер ранние стартапы, такие как Delphi и GetDot.AI. Стартапы, такие как Narrator. Более установленные игроки, в чем-то делающие это, например Amazon QuickSight, Tableau Ask Data или ThoughtSpot.

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

Контейнеры продуктов данных

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

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

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

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

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

Кто руководит этим: Nextdata, стартап, основанный создателем концепции data mesh Замаком Дехгани. Nexla также занимается этой областью.

Практичность и потенциал разблокирования ценности: Хотя Nextdata только недавно вышла из тени, и контейнеры продуктов данных все еще развиваются, многие команды данных уже видели доказанные результаты от внедрения data mesh. Будущее таблицы данных будет зависеть от конкретной формы и реализации этих контейнеров.

Бесконечное преобразование жизненного цикла данных

Фото по zero take на Unsplash

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

Значение термина “склад данных” изменилось радикально с термином, введенным Биллом Инмоном в 1990-х годах. Теперь вместо конвейеров ETL используются конвейеры ELT. Озеро данных уже не настолько аморфно, как было всего два года назад.

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

Термин “нулевой ETL” кажется угрожающим, потому что (неточно) предполагает смерть конвейеров, и без конвейеров нам нужны данные инженеры?

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

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

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

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

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

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

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