За рамками ETL и ELT: Мишель Трико, соучредитель и генеральный директор компании Airbyte, рассказывает на портале The New Stack о том, как будут развиваться системы интеграции данных в ближайшие годы.

Интеграция данных значительно изменилась с тех пор, как данные стали централизовываться в хранилищах и озерах данных. ELT (Extract-Load-Transform) заменило ETL (Extract-Transform-Load), сделав аналитиков автономными в получении доступа к необходимым им данным в этих хранилищах.

Появились новые решения реверсивного ETL (Reverse ETL), позволяющие операционным группам получать доступ к консолидированным данным из тех же хранилищ. В отрасли этот новый стандарт называют современным стеком данных. И если в 2008 г., согласно Accenture, подход, основанный на данных, использовали только 30% наиболее дорогих компаний, таких как Amazon, Apple и Microsoft, то теперь их доля выросло до 70%.

Проблема с понятием «современное» заключается в том, что современное сегодня завтра становится устаревшим. И это приводит к вопросу: как будет развиваться интеграция данных с учетом тех трендов, которые мы видим? Обсудим, с какими проблемами столкнутся компании и что им следует предпринять для их решения.

Текущие проблемы ELT

Неспособность удовлетворить все потребности

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

  • «Длинный хвост» потребностей. Решения ELT не в состоянии угнаться за количеством инструментов, которые используются внутри компании. Все ELT-решения останавливаются на уровне 150-200 коннекторов данных. Причина проста: самое сложное в интеграции данных — это не создание коннекторов, а их поддержка. Любое облачное решение с закрытым исходным кодом будет ограничено в возврате инвестиций (ROI). И его разработчикам невыгодно поддерживать длинный хвост коннекторов, поэтому они фокусируются только на самых популярных интеграциях.
  • Индивидуальные потребности. У всех компаний разные потребности в данных для одних и тех же инструментов, которые они используют. Если по какой-то случайности в ELT-решении отсутствует один поток API для какого-либо инструмента, у компании не остается другого выбора, кроме как создавать и поддерживать его самостоятельно.

Это справедливо как для ELT, так и для реверсивного ETL.

Отсутствие обеспечения качества и отслеживания происхождения данных при реверсивном ETL

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

Как будут решаться сегодняшние проблемы

Консолидация ELT и реверсивного ETL

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

У этой консолидации есть несколько важных преимуществ:

  • Выполнение ELT позволяет компаниям отслеживать данные на уровне реверсивного ETL. Команды будут знать, откуда берутся данные, если ELT занимается один и тот же инструмент, что сокращает усилия по инженерии данных.
  • В рамках одной платформы облегчается мониторинг все конвейеров, что также сокращает усилия по инженерии данных.

Open Source-перспективы

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

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

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

Новая операционная система для конвейеров данных

Хранилища (Snowflake, BigQuery, Redshift и т. д.) быстро становятся операционной системой для данных, местом, где выполняются все операции с данными компании, а также экосистемой приложений для работы с данными, построенных на их основе.

Та же концепция может быть применена к интеграции данных — на уровне платформы, которая может делать следующее:

  • ELT и реверсивный ETL с Open Source-коннекторами, которые можно настраивать по своему усмотрению;
  • активное сообщество инженеров данных, стимулированное к поддержке длинного хвоста коннекторов;
  • отслеживание происхождения данных;
  • наблюдаемость во всех конвейерах данных;
  • интеграция с другими инструментами стека данных компании для обеспечения совместимости.

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

Заключение

Поскольку, согласно IDC, темпы роста объемов данных, создаваемых компаниями, в период до 2025 г. составят 23%, наличие эффективной операционной системы конвейеров данных еще никогда не было столь важным. И это того стоит: по оценкам Capgemini, доходы организаций, управляемых данными, на 70% выше, чем у их коллег. Пришло время организациям преодолеть эти проблемы ELT, внедрив операционную систему конвейеров данных.