https://superrare.com/0xb932a70a57673d89f4acffbe830e8ed7f75fb9e0/anitya-47535

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

Все было 🤘

Оригинал: https://alirezasadeghi1.medium.com/open-source-data-engineering-landscape-2024-8a56d23b7fdb

PDF

Исходный пост был опубликован на Practical Data Engineering Substack.
Введение
Пока широко распространенный хайп вокруг Генеративного ИИ и ChatGPT взволновал мир технологий, 2023 год стал еще одним захватывающим и живым годом в ландшафте инженерии данных, который стабильно становился более разнообразным и сложным, с непрерывным инновационным и эволюционным процессом на всех уровнях аналитической иерархии.
С продолжающимся распространением инструментов с открытым исходным кодом, фреймворков и решений возросло количество вариантов, доступных для инженеров данных! В таком быстро меняющемся ландшафте важность быть в курсе последних технологий и тенденций не может быть переоценена. Умение выбирать правильный инструмент для нужной работы – это важный навык, обеспечивающий эффективность и актуальность в условиях постоянно меняющихся вызовов инженерии данных.
Будучи внимательным наблюдателем за тенденциями в инженерии данных в моей роли старшего инженера данных и консультанта, я хотел бы представить ландшафт открытых исходных данных в начале 2024 года. Это включает в себя выявление ключевых активных проектов и важных инструментов, давая читателям возможность принимать обоснованные решения при навигации в этом динамичном технологическом ландшафте.
Почему представлять еще один ландшафт?
Почему тратить усилия на представление еще одного ландшафта данных!? Есть аналогичные периодические отчеты, такие как известный MAD Landscape, State of Data Engineering и Reppoint Open Source Top 25, однако ландшафт, который я представляю, фокусируется исключительно на инструментах с открытым исходным кодом, в основном применимых к платформам данных и жизненному циклу инженерии данных.
MAD Landscape предоставляет очень полное представление о всех инструментах и услугах для машинного обучения, искусственного интеллекта и данных, включая как коммерческие, так и открытые исходники, тогда как представленный здесь ландшафт предоставляет более полное представление о активных проектах с открытым исходным кодом в части данных MAD. Другие отчеты, такие как Reppoint Open Source Top 25 и Data50, фокусируются больше на поставщиках SaaS и стартапах, тогда как этот отчет фокусируется на самих проектах с открытым исходным кодом, а не на услугах SaaS.
Ежегодные отчеты и опросы, такие как Github’s state of open source, ежегодный опрос Stackoverflow и отчеты OSS Insight, также являются отличными источниками для получения представления о том, что используется или популярно в сообществе, но они охватывают только ограниченные разделы (например, базы данных и языки) общего ландшафта данных.
Поэтому из-за моего интереса к открытым стекам данных я составил список инструментов с открытым исходным кодом и услуг в экосистеме инженерии данных.
Так что без дополнительного ожидания, вот Экосистема открытых исходных данных инженерии 2024 года:

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

1. Исключаются любые устаревшие, архивные и заброшенные проекты. Некоторые заметные устаревшие проекты – это Apache Sqoop, Scribe и Apache Apex, которые все еще могут использоваться в некоторых производственных средах.
2. Исключаются проекты, которые были полностью неактивны на Github в течение последнего года и едва упоминаются в сообществе. Например, Apache Pig и проекты Apache Oozie.
3. Исключаются проекты, которые все еще довольно новы и не получили много внимания в виде звезд Github, форков, а также публикаций в блогах, демонстраций и упоминаний в онлайн-сообществах. Однако некоторые многообещающие проекты, такие как OneTable, которые достигли некоторых значимых результатов и реализованы на основе существующих технологий, упоминаются.
4. Инструменты для науки о данных, машинного обучения и искусственного интеллекта исключены, за исключением инструментов платформы и инфраструктуры машинного обучения, так как я сосредотачиваюсь только на том, что связано с дисциплиной инженерии данных.
5. Перечислены различные типы хранилищ данных, такие как реляционные OLTP и встроенные системы баз данных. Это потому, что дисциплина инженерии данных включает в себя работу с множеством различных внутренних и внешних систем хранения, используемых в приложениях и операционных системах (BSS), даже если они не являются частью стека аналитики.
6. Названия категорий выбраны как можно более общими на основе того, куда инструмент вписывается в стек данных. Для систем хранения используются основная модель базы данных и рабочая нагрузка базы данных (OLTP, OLAP) для группировки и маркировки систем, но, например, “Распределенные SQL DBMS” также называются HTAP или масштабируемыми SQL-базами данных на рынке.
7. Некоторые инструменты могут принадлежать к более чем одной категории. VoltDB является как базой данных в памяти, так и распределенной SQL DBMS. Но я старался разместить их в категории, по которой их больше всего признают на рынке.
8. Для некоторых баз данных может быть нечеткая граница в отношении категории, к которой они на самом деле принадлежат. Например, ByConity утверждает, что является решением для хранилищ данных, но построен на основе ClickHouse, который признан как движок реального времени OLAP. Поэтому до сих пор неясно, является ли он системой OLAP в реальном времени (способной поддерживать запросы менее чем за секунду) или нет.
9. Не все перечисленные проекты являются полностью Переносимыми инструментами с открытым исходным кодом. Некоторые из проектов скорее являются Open Core, чем открытым исходным кодом. В моделях Open Core не все компоненты полной системы, предлагаемой основным поставщиком SaaS, являются открытыми исходниками. Поэтому при принятии решения о принятии инструмента с открытым исходным кодом важно учитывать, насколько переносим и действительно открыт исходный код проекта.

Обзор категорий инструментов
В следующем разделе кратко обсуждается каждая категория.

1. Системы хранения
   Системы хранения являются самой крупной категорией в представленном ландшафте, в основном благодаря недавнему взлету специализированных баз данных. Две последние всплескающие категории – это векторные и потоковые базы данных. Примеры открытых потоковых баз данных – Materialize и RaisingWave. Векторные базы данных также испытывают быстрый рост в области систем хранения. Я разместил векторные системы хранения в разделе ML Platform, поскольку они в основном используются в стеках ML и AI. Распределенные файловые системы и объектные хранилища также размещены в своей собственной связанной категории – это Платформа для хранилищ данных.
   Как упоминалось в разделе критериев выбора, системы хранения группируются и маркируются на основе основной модели базы данных и рабочей нагрузки. На самом высоком уровне системы хранения могут быть классифицированы на три основных класса: OLTP, OLAP и HTAP. Они могут быть дополнительно классифицированы на основе SQL против NoSQL для OLTP-движков и офлайн (не в реальном времени) против реального времени (результаты менее секунды) для OLAP-движков, как показано на следующей диаграмме.

2. Платформа для хранилищ данных
   Платформа для хранилищ данных продолжает совершенствоваться в прошедшем году, и Gartner поместил Data Lake на склон просвещения в своем издании 2023 года Цикла гиперцикла управления данными.

Для слоя хранения распределенные файловые системы и объектные хранилища по-прежнему являются основными технологиями, служащими основой как для реализаций хранилищ данных на месте, так и для облачных. В то время как HDFS по-прежнему является основной технологией, используемой для кластеров Hadoop на месте, распределенное объектное хранилище Apache Ozone набирает обороты, чтобы предоставить альтернативную технологию хранения данных на месте. Cloudera, основной коммерческий поставщик Hadoop, теперь предлагает Ozone в рамках своего предложения CDP Private Cloud.
Выбор формата сериализации данных влияет на эффективность хранения и производительность обработки. Apache ORC остается предпочтительным выбором для колоночного хранения в экосистемах Hadoop, в то время как Apache Parquet стал де-факто стандартом для сериализации данных в современных хранилищах данных. Его популярность обусловлена компактным размером, эффективным сжатием и широкой совместимостью с различными движками обработки.
Еще одним ключевым трендом в 2023 году стало разделение слоев хранения и вычислений. Многие системы хранения теперь предлагают интеграцию с облачными решениями для хранения объектов, такими как S3, используя их врожденную эффективность и эластичность. Такой подход позволяет масштабировать ресурсы обработки данных независимо от хранения, что приводит к экономии затрат и улучшенной масштабируемости. Поддержка Cockroachdb S3 в качестве хранилища и предложение Confluent по долгосрочному хранению данных тематической кафки на S3 дополнительно иллюстрируют этот тренд, подчеркивая растущее использование хранилищ данных как экономичных, долгосрочных решений для хранения.
Одним из самых горячих событий 2023 года стало появление открытых форматов таблиц. Эти фреймворки по существу действуют как абстракция таблицы и виртуальный уровень управления данными, находящийся над вашим хранилищем данных и слоем данных, как показано на следующей диаграмме.

Пространство открытых форматов таблиц в настоящее время контролируется ожесточенной борьбой за главенство между следующими тремя основными претендентами:
Apache Hudi: Изначально разработанный и открытый Uber, с основной целью разработки для обновлений данных практически в реальном времени и транзакций ACID.
Apache Iceberg: Родившийся из команды инженеров Netflix.
Delta Lake: Созданный и открытый Databricks, с безупречной интеграцией с платформой Databricks.
Полученное финансирование ведущими поставщиками SaaS в этой области в 2023 году – Databricks, Tabular и OneHouse – подчеркивает интерес рынка и их потенциал для дальнейшего развития управления данными на хранилищах данных.
Более того, сейчас разворачивается новый тренд с появлением объединенных уровней хранилищ данных. OneTable (недавно открыт OneHouse) и UniForm (в настоящее время не open source предложение от Databricks) – это первые два проекта, которые были объявлены в прошлом году. Эти инструменты выходят за рамки индивидуальных форматов таблиц, предлагая возможность работы со всеми тремя основными претендентами под одним зонтом. Это позволяет пользователям использовать универсальный формат, предоставляя данные обработчикам в их предпочитаемых форматах, что приводит к увеличению гибкости и мобильности.

3. Интеграция данных
   Ландшафт интеграции данных в 2023 году не только продолжает оставаться под влиянием установленных игроков, таких как Apache Nifi, Airbyte и Meltano, но также появляются многообещающие инструменты, такие как Apache Inlong и Apache SeaTunnel, предлагающие привлекательные альтернативы со своими уникальными преимуществами.
   Тем временем Streaming CDC (Change Data Capture) дальше совершенствуется, подпитываемый активной разработкой в экосистеме Kafka. Плагины Kafka Connect и Debezium стали основным выбором для практически в реальном времени захвата данных из систем баз данных, а коннекторы Flink CDC получают популярность для развертывания с использованием Flink в качестве основного движка потоковой обработки.
   За пределами традиционных баз данных инструменты, такие как CloudQuery и Streampipe, упрощают интеграцию данных из API, предоставляя удобные решения для внедрения данных из различных источников, что отражает растущую важность гибкой интеграции с облачными сервисами.
   В области промежуточных событий и сообщений Apache Kafka сохраняет свою сильную позицию, хотя конкуренты, такие как Redpanda, сокращают разрыв. $100 млн. финансирование серии C Redpanda в 2023 году показывает растущий интерес к альтернативным брокерам сообщений, предлагающим низкую задержку и высокую пропускную способность.

4. Обработка и вычисления данных
   Мир потоковой обработки продолжал нагреваться в 2023 году! Apache Spark и Apache Flink остаются правящими чемпионами, однако Apache Flink сделал серьезные заголовки в 2023 году. Облачные гиганты, такие как AWS и Alibaba, присоединились к предложениям Flink в качестве сервиса, а приобретение Confluent Immerok для собственного полностью управляемого предложения Flink в качестве сервиса показывает моментум за этим мощным двигателем.
   В экосистеме Python доступны библиотеки обработки данных, такие как Vaex, Dask, polars и Ray, для использования многоядерных процессоров. Эти библиотеки параллельного выполнения дополнительно открывают возможности для анализа массивных наборов данных в привычной среде Python.
5. Управление рабочим процессом и DataOps
   Оркестрация рабочих процессов, вероятно, является самой насыщенной категорией в представленной экосистеме данных, наполненной установленными тяжеловесами и захватывающими новичками.
   Инструменты-ветераны, такие как Apache Airflow и Dagster, по-прежнему демонстрируют свою мощь и остаются широко используемыми движками во время недавних ожесточенных дебатов в сообществе о распаковке, повторной упаковке и упаковке против распаковки движков оркестрации рабочих процессов. С другой стороны, за последние два года GitHub стал свидетелем появления нескольких убедительных претендентов, которые захватили значительное внимание. Kestra, Temporal, Mage и Windmill заслуживают внимания, каждый из них предлагает уникальные преимущества. Новички могут удовлетворять изменяющиеся потребности современных потоков данных, будь то сосредоточенность на серверной оркестрации, как Temporal, или на распределенном выполнении задач, как Mage.
6. Инфраструктура и мониторинг данных
   Последний опрос Grafana Labs подтверждает, что Grafana, Prometheus и стек ELK продолжают доминировать в области наблюдаемости и мониторинга. Компания Grafana Labs сама была довольно активной, представив новые инструменты с открытым исходным кодом, такие как Loki (для агрегации журналов) и Mimir (для долгосрочного хранения Prometheus), чтобы дополнительно укрепить свою платформу.
   Одной из областей, где инструменты с открытым исходным кодом кажутся менее распространенными, является управление и мониторинг кластеров. Это, вероятно, связано с тенденцией к облачной миграции, уменьшающей необходимость в управлении крупными локальными платформами данных. Хотя проект Apache Ambari, однажды популярный для управления кластерами Hadoop, фактически был заброшен после слияния Hortonworks и Cloudera в 2019 году, недавнее возрождение вызывает некоторую надежду на его будущее. Однако его долгосрочная судьба остается неопределенной.
   Что касается планирования ресурсов и развертывания рабочих нагрузок, Kubernetes кажется предпочтительным планировщиком ресурсов, особенно на облачных платформах.

7. Платформа ML
   Платформа машинного обучения стала одной из самых активных категорий с беспрецедентным ростом и интересом к векторным базам данных, специализированным системам, оптимизированным для хранения и извлечения высокомерных данных. Как подчеркнуто в отчете DB-Engines за 2023 год, векторные базы данных стали самой популярной категорией баз данных в прошлом году.
   Инструменты MLOps также играют все более важную роль в эффективном масштабировании проектов машинного обучения, обеспечивая плавную работу и управление жизненным циклом приложений ML. Поскольку сложность и масштаб развертывания ML продолжают расти, инструменты MLOps стали неотъемлемыми для оптимизации разработки, развертывания и мониторинга моделей ML.
8. Управление метаданными
   В последние годы управление метаданными заняло центральное место, подталкиваемое растущей потребностью в управлении и улучшении доступа к данным. Однако отсутствие комплексных платформ управления метаданными побудило гигантов технологической отрасли, таких как Netflix, Lyft, Airbnb, Twitter, LinkedIn и Paypal, создать свои собственные решения.
   Эти усилия принесли значительные вклады в сообщество с открытым исходным кодом. Инструменты, такие как Amundsen (от Lyft), DataHub (от Netflix) и Marquez (от WeWork), являются решениями внутрикорпоративного разработки, которые были открыты и находятся в активной разработке и вкладе.
   Что касается управления схемами, здесь пейзаж остается относительно стабильным. Hive Metastore продолжает быть основным решением для многих, поскольку на данный момент нет альтернативных решений с открытым исходным кодом для его замены.
9. Аналитика и визуализация
   В области бизнес-аналитики (BI) и визуализации Apache Superset выделяется как самая активная и популярная альтернатива лицензионным SaaS решениям BI.
   Что касается распределенных и массово-параллельных обработчиков (MPP), некоторые эксперты утверждают, что большие данные мертвы и большинству компаний не требуется распределенная обработка крупномасштабных данных, предпочитая использовать одиночные мощные серверы для обработки своих объемов данных.
   Несмотря на это утверждение, распределенные массово-параллельные обработчики (MPP), такие как Apache Hive, Impala, Presto и Trino, остаются распространенными в крупных платформах данных, особенно для данных в петабайтном масштабе.
   Помимо традиционных обработчиков MPP, еще одним трендом, набирающим обороты, являются единые исполнительные движки. Движки, такие как Apache Linkis, Alluxio и Cube, предоставляют промежуточный запрос и вычисление между верхними приложениями и базовыми двигателями.

Заключение
Это исследование открытой ландшафта инжиниринга данных представляет лишь мгновенный взгляд на динамичный и живой мир данных. Хотя важные инструменты и технологии были рассмотрены в различных категориях, экосистема продолжает быстро развиваться, появляясь новые решения.
Помните, что это не исчерпывающий список, и “лучшие” инструменты в конечном итоге определяются вашими конкретными потребностями и применением. Не стесняйтесь поделиться любыми замечательными инструментами, которые я упустил и которые, по вашему мнению, должны были быть включены.
Оригинальный пост был опубликован на Practical Data Engineering Substack.

Представляем data mesh 2.0: Новая эра управления данными
Вступление: Почему data mesh актуален?

Оригинал:
https://medium.com/capital-one-tech/introducing-data-mesh-2-0-a-new-era-of-data-governance-27170c7a75cb

PDF

В мире Big Data организация должна уделять внимание двум основным аспектам для эффективного использования данных:

1. Легкость управления данными: Масштабируемое хранение, вычисления, обнаружение и слои предоставления как для аналитических данных, так и для метаданных, чтобы “преимущество масштаба” реализовалось как в плане затрат, так и в производительности, при этом стандартизация и управление становятся более простыми.

2. Доверие к данным: Также требуется объединение аспекта обработки данных с децентрализованным доменным или институциональным знанием для повышения качества и последующей авторитетности/доверительности данных.

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

Растущая потребность в Data Mesh:
Озера данных предоставляют организациям дешевую платформу хранения для хранения больших объемов полиглотных данных, что начало эру серии распределенных инструментов обработки данных и аналитики для работы с этими данными. Но вскоре они превратились в болота данных — место сброса данных для различных доменов/LOBs с неясным видением потребностей потребления и отсутствием владения и ограничений в отношении дублирования.

Это в конечном итоге привело к серьезным проблемам с:

• Недостатком качества данных и надежности (авторитетный vs неавторитетный источник правды)
• Плохим управлением метаданных (регистрация и поиск) и обнаружимостью
• Отсутствием управления и стандартизации (низкая точность как данных, так и метаданных)

И парадигма Data Mesh была представлена для решения этого нового набора проблем в мире озера данных.

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

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

Парадигма Data Mesh основана на четырех принципах:

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

2. Данные как продукт
   Этот принцип направлен на снижение трения и затрат на обнаружение, понимание, доверие и, в конечном итоге, использование качественных данных. Владельцы продукта данных в домене должны глубоко понимать, кто пользователи данных, как они используют данные и какие методы они предпочитают для их использования. Продукт данных, состоящий из кода, данных и метаданных, а также инфраструктуры, является архитектурным квантом архитектуры Data Mesh. https://www.oreilly.com/library/view/building-evolutionary-architectures/9781491986356/ch04.html

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

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

Федеративное вычислительное управление
Data mesh следует архитектуре распределенной системы, где существует коллекция независимых продуктов данных, сосуществующих бок о бок, но с независимым жизненным циклом, созданных и развернутых, вероятно, независимыми командами.
Однако, чтобы получить ценность в виде данных более высокого порядка, инсайтов или машинного интеллекта, необходимо, чтобы эти независимые продукты данных взаимодействовали между собой; чтобы можно было их коррелировать, создавать объединения, находить пересечения или выполнять другие операции с графами или множествами с масштабированием.
Таким образом, реализация data mesh требует модели управления, которая принимает децентрализацию и самосуверенитет домена, создавая и придерживаясь набора глобальных правил (правил, применяемых ко всем продуктам данных и их интерфейсам) для успешной взаимосовместимости и автоматического выполнения решений об управлении платформой — федеративного вычислительного управления.
Основные элементы принципов data mesh
В общем, согласно принципам data mesh:
Продукт данных является архитектурным квантом разработки концепции, владения, производства, предоставления и управления аналитическими данными.
Продукт данных представляет собой композицию всех компонентов для предоставления данных — код, данные и метаданные и инфраструктура — все в ограниченном контексте домена.
Таким образом, помимо определения и управления своими продуктами данных, каждый домен также должен поддерживать собственную инфраструктуру для создания и предоставления этих продуктов данных, соблюдая набор глобальных правил управления для обеспечения взаимодействия продуктов данных.
Подробное обсуждение принципов и архитектуры можно найти здесь. https://martinfowler.com/articles/data-mesh-principles.html

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

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

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

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

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

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

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

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

Представляем data mesh 2.0
Что, если мы заимствуем принципы data mesh и реализуем их через ряд самообслуживающих горизонтальных платформ для обработки данных, обработки и управления данными, управляемых централизованными командами?
Из мира data mesh:
Принятие идеи владения доменом продуктов данных, что повышает доверие к данным.
Включение продукта данных в логический ограниченный контекст, что дополнительно увеличивает владение и доверие.
Использование принципа самообслуживания для удовлетворения как общих, так и дополнительных потребностей в управлении у каждого домена, что значительно сокращает время выхода на рынок.
Совмещение этих принципов с принципами горизонтальных корпоративных платформ
Централизованные платформы для обработки данных — особенно управления метаданными (включая управление и правила качества данных), захвата данных, курирования, вычисления характеристик, создания и обслуживания продуктов данных — для получения преимуществ инноваций однократного применения и обработки на масштабе с более низким общим затратами и более простым управлением
Стандартизация в процессах и инструментах проектирования и выполнения времени выполнения для значительного увеличения взаимосовместимости продуктов данных при снижении затрат на выполнение
Горизонтальные платформы значительно упрощают трассировку и мониторинг, что дополнительно увеличивает доверие к данным. Использование данных для повышения качества данных и их надежности с помощью превентивных и реактивных функций уведомлений, легко реализуемых однократно на центральной платформе и использованных многими
Использование подхода Built by One Leveraged by Many (BOLM)
Сохранение преимуществ озера данных: В мире общедоступных облачных вычислений озеро данных представляет собой набор управляемых полиглотных папок, расположенных на облаке, с уже зрелой структурой управления, чтобы управлять этими папками в соответствии с их внутренними и внешними потребностями (финансы, аудит, соответствие, обмен данными с внешними организациями и т. д.). Все, что нужно организации, – это организовать эти папки в соответствии с ее потребностями.

Чтобы data mesh 2.0 функционировал, горизонтальные корпоративные платформы должны обладать следующими возможностями:

1. Безболезненные и хорошо управляемые средства внутреннего исходного кода и совместной разработки, чтобы домены могли создавать собственные уникальные (или повторно используемые) возможности внутри платформы:
   • Способность привести код домена и запустить его на платформе, при условии соблюдения управляющих механизмов, установленных платформой.

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

3. Горизонтальная платформа применяет корпоративную модель данных для кросс-доменных составных продуктов данных, в то время как домены имеют гибкость добавлять дополнительные сущности и атрибуты к этим продуктам данных по мере необходимости (без изменения ключей продуктов данных).

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

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

https://www.capitalone.com/tech/cloud/

Изначально опубликовано на https://www.capitalone.com.
Автор: Арья Басу, Архитектор данных, Банковская архитектура. Арья является архитектором данных с опытом более двух десятилетий в области данных и облака. В настоящее время он работает в команде Банковской архитектуры, фокусируясь на архитектуре данных.
ЗАЯВЛЕНИЕ О РАЗГЛАШЕНИИ: © 2024 Capital One. Мнения принадлежат индивидуальному автору. Если не указано иное в этом сообщении, Capital One не связана и не одобряет ни одну из упомянутых компаний. Все товарные знаки и другая интеллектуальная собственность, использованные или отображаемые, являются собственностью их соответствующих владельцев. Capital One не несет ответственности за содержание или политику конфиденциальности связанных сторон сайтов.

Оригинал: https://apacheseatunnel.medium.com/comprehensive-guide-to-installing-and-configuring-seatunnel-and-seatunnel-web-on-centos-7-x-d98827edf2fc

UPD: Появился официальный docker 🔥

Или PDF

Для этой настройки я использовал виртуальную машину с установленной CentOS 7.x, на которой также установлены Java 15 и MySQL 8.0.28. Эти первоначальные шаги, будучи базовыми, пропущены здесь, так как они прямолинейны и были рассмотрены в предыдущих статьях. Среда настроена на одном экземпляре виртуальной машины CentOS 7.x, требуя открытия портов 8081, 3306 и 5801 в брандмауэре для обеспечения сетевой доступности.

II. Установка и развертывание SeaTunnel
Загрузка установочного пакета Начните с установки версии и загрузки пакета SeaTunnel с использованием wget. Распакуйте пакет с помощью tar.

export version=“2.3.3”
wget “https://archive.apache.org/dist/seatunnel/${version}/apache-seatunnel-${version}-bin.tar.gz”
tar -xzvf “apache-seatunnel-${version}-bin.tar.gz”

Установка переменных среды
Добавьте каталог SeaTunnel в ваш путь для удобного доступа.

vi /etc/profile.d/seatunnel.sh

Add the following variables

export SEATUNNEL_HOME=/root/apache-seatunnel-2.3.3 #What is set here is the decompression directory of seatunnel.
export PATH=$PATH:$SEATUNNEL_HOME/bin

Установка плагинов коннектора
Перейдите в каталог /root/apache-seatunnel-2.3.3 и выполните скрипт установки плагина.

sh bin/install-plugin.sh 2.3.3

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

Копирование файла JAR в каталог lib.

Запуск SeaTunnel
Используйте следующие команды для запуска SeaTunnel в каталоге /root/apache-seatunnel-2.3.3:

sh bin/seatunnel-cluster.sh -d -DJvmOption=”-Xms1G -Xmx1G”
or
nohup sh bin/seatunnel-cluster.sh 2>&1 &

Проверьте процесс с помощью jps и убедитесь, что в журналах в каталоге logs нет ошибок.

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

III. Выполнение демонстрации официальной задачи для клиента
Перейдите в каталог /root/apache-seatunnel-2.3.3 и выполните команду запуска:

$SEATUNNEL_HOME/bin/seatunnel.sh --config $SEATUNNEL_HOME/config/v2.batch.config.template

Эта команда взята с официального веб-сайта, и результаты выполнения следующие:

[root@es1 apache-seatunnel-2.3.3]# $SEATUNNEL_HOME/bin/seatunnel.sh --config $SEATUNNEL_HOME/config/v2.batch.config.template
WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.
December 19, 2023 12:11:20 上午 com.hazelcast.internal.config.AbstractConfigLocator
message: Loading configuration ‘/root/apache-seatunnel-2.3.3/config/seatunnel.yaml’ from System property ‘seatunnel.config’
December 19, 2023 12:11:20 上午 com.hazelcast.internal.config.AbstractConfigLocator
message: Using configuration file at /root/apache-seatunnel-2.3.3/config/seatunnel.yaml
December 19, 2023 12:11:20 上午 org.apache.seatunnel.engine.common.config.SeaTunnelConfig
message: seatunnel.home is /root/apache-seatunnel-2.3.3
December 19, 2023 12:11:20 上午 com.hazelcast.internal.config.AbstractConfigLocator
message: Loading configuration ‘/root/apache-seatunnel-2.3.3/config/hazelcast.yaml’ from System property ‘hazelcast.config’
December 19, 2023 12:11:20 上午 com.hazelcast.internal.config.AbstractConfigLocator
message: Using configuration file at /root/apache-seatunnel-2.3.3/config/hazelcast.yaml
December 19, 2023 12:11:20 上午 com.hazelcast.internal.config.AbstractConfigLocator
message: Loading configuration ‘/root/apache-seatunnel-2.3.3/config/hazelcast-client.yaml’ from System property ‘hazelcast.client.config’
December 19, 2023 12:11:20 上午 com.hazelcast.internal.config.AbstractConfigLocator
message: Using configuration file at /root/apache-seatunnel-2.3.3/config/hazelcast-client.yaml
2023-12-19 00:11:21,149 INFO com.hazelcast.client.impl.spi.ClientInvocationService – hz.client_1 [seatunnel] [5.1] Running with 2 response threads, dynamic=true
2023-12-19 00:11:21,233 INFO com.hazelcast.core.LifecycleService – hz.client_1 [seatunnel] [5.1] HazelcastClient 5.1 (20220228 – 21f20e7) is STARTING
2023-12-19 00:11:21,234 INFO com.hazelcast.core.LifecycleService – hz.client_1 [seatunnel] [5.1] HazelcastClient 5.1 (20220228 – 21f20e7) is STARTED
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.hazelcast.internal.networking.nio.SelectorOptimizer (file:/root/apache-seatunnel-2.3.3/starter/seatunnel-starter.jar) to field sun.nio.ch.SelectorImpl.selectedKeys
WARNING: Please consider reporting this to the maintainers of com.hazelcast.internal.networking.nio.SelectorOptimizer
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
2023-12-19 00:11:21,294 INFO com.hazelcast.client.impl.connection.ClientConnectionManager – hz.client_1 [seatunnel] [5.1] Trying to connect to cluster: seatunnel
2023-12-19 00:11:21,298 INFO com.hazelcast.client.impl.connection.ClientConnectionManager – hz.client_1 [seatunnel] [5.1] Trying to connect to [localhost]:5801
2023-12-19 00:11:21,352 INFO com.hazelcast.core.LifecycleService – hz.client_1 [seatunnel] [5.1] HazelcastClient 5.1 (20220228 – 21f20e7) is CLIENT_CONNECTED
2023-12-19 00:11:21,352 INFO com.hazelcast.client.impl.connection.ClientConnectionManager – hz.client_1 [seatunnel] [5.1] Authenticated with server [localhost]:5801:772efc0a-4c18-4a4b-baa7-b82b9ae4a395, server version: 5.1, local address: /127.0.0.1:36095
2023-12-19 00:11:21,356 INFO com.hazelcast.internal.diagnostics.Diagnostics – hz.client_1 [seatunnel] [5.1] Diagnostics disabled. To enable add -Dhazelcast.diagnostics.enabled=true to the JVM arguments.
2023-12-19 00:11:21,384 INFO com.hazelcast.client.impl.spi.ClientClusterService – hz.client_1 [seatunnel] [5.1]

Members [1] {
Member [localhost]:5801 – 772efc0a-4c18-4a4b-baa7-b82b9ae4a395
}

2023-12-19 00:11:21,421 INFO com.hazelcast.client.impl.statistics.ClientStatisticsService – Client statistics is enabled with period 5 seconds.
2023-12-19 00:11:21,706 INFO org.apache.seatunnel.engine.client.job.JobExecutionEnvironment – add common jar in plugins :[]
2023-12-19 00:11:21,733 INFO org.apache.seatunnel.core.starter.utils.ConfigBuilder – Loading config file from path: /root/apache-seatunnel-2.3.3/config/v2.batch.config.template
2023-12-19 00:11:21,799 INFO org.apache.seatunnel.core.starter.utils.ConfigShadeUtils – Load config shade spi: [base64]
2023-12-19 00:11:21,848 INFO org.apache.seatunnel.core.starter.utils.ConfigBuilder – Parsed config file: {
“env” : {
“execution.parallelism” : 2,
“job.mode” : “BATCH”,
“checkpoint.interval” : 10000
},
“source” : [
{
“schema” : {
“fields” : {
“name” : “string”,
“age” : “int”
}
},
“row.num” : 16,
“parallelism” : 2,
“result_table_name” : “fake”,
“plugin_name” : “FakeSource”
}
],
“sink” : [
{
“plugin_name” : “Console”
}
]
}

2023-12-19 00:11:21,885 INFO org.apache.seatunnel.api.configuration.ReadonlyConfig – Config uses fallback configuration key ‘plugin_name’ instead of key ‘factory’
2023-12-19 00:11:21,886 INFO org.apache.seatunnel.api.configuration.ReadonlyConfig – Config uses fallback configuration key ‘plugin_name’ instead of key ‘factory’
2023-12-19 00:11:21,895 INFO org.apache.seatunnel.plugin.discovery.AbstractPluginDiscovery – Load SeaTunnelSink Plugin from /root/apache-seatunnel-2.3.3/connectors/seatunnel
2023-12-19 00:11:21,911 INFO org.apache.seatunnel.plugin.discovery.AbstractPluginDiscovery – Discovery plugin jar: FakeSource at: file:/root/apache-seatunnel-2.3.3/connectors/seatunnel/connector-fake-2.3.3.jar
2023-12-19 00:11:21,912 INFO org.apache.seatunnel.plugin.discovery.AbstractPluginDiscovery – Discovery plugin jar: Console at: file:/root/apache-seatunnel-2.3.3/connectors/seatunnel/connector-console-2.3.3.jar
2023-12-19 00:11:21,915 INFO org.apache.seatunnel.engine.core.parse.ConfigParserUtil – Currently, incorrect configuration of source_table_name and result_table_name options don’t affect job running. In the future we will ban incorrect configurations.
2023-12-19 00:11:21,915 INFO org.apache.seatunnel.api.configuration.ReadonlyConfig – Config uses fallback configuration key ‘plugin_name’ instead of key ‘factory’
2023-12-19 00:11:21,915 INFO org.apache.seatunnel.api.configuration.ReadonlyConfig – Config uses fallback configuration key ‘plugin_name’ instead of key ‘factory’
2023-12-19 00:11:21,916 WARN org.apache.seatunnel.engine.core.parse.ConfigParserUtil – This configuration is not recommended. A source/transform(FakeSource) is configured with ‘result_table_name’ option value of ‘fake’, but subsequent transform/sink(Console) is not configured with ‘source_table_name’ option.
2023-12-19 00:11:21,919 INFO org.apache.seatunnel.engine.core.parse.MultipleTableJobConfigParser – start generating all sources.
2023-12-19 00:11:21,919 INFO org.apache.seatunnel.api.configuration.ReadonlyConfig – Config uses fallback configuration key ‘plugin_name’ instead of key ‘factory’
2023-12-19 00:11:21,953 INFO org.apache.seatunnel.plugin.discovery.AbstractPluginDiscovery – Load SeaTunnelSource Plugin from /root/apache-seatunnel-2.3.3/connectors/seatunnel
2023-12-19 00:11:21,970 INFO org.apache.seatunnel.plugin.discovery.AbstractPluginDiscovery – Discovery plugin jar: FakeSource at: file:/root/apache-seatunnel-2.3.3/connectors/seatunnel/connector-fake-2.3.3.jar
2023-12-19 00:11:21,974 INFO org.apache.seatunnel.plugin.discovery.AbstractPluginDiscovery – Load plugin: PluginIdentifier{engineType=’seatunnel’, pluginType=’source’, pluginName=’FakeSource’} from classpath
2023-12-19 00:11:22,003 INFO org.apache.seatunnel.engine.core.parse.MultipleTableJobConfigParser – start generating all transforms.
2023-12-19 00:11:22,003 INFO org.apache.seatunnel.engine.core.parse.MultipleTableJobConfigParser – start generating all sinks.
2023-12-19 00:11:22,004 INFO org.apache.seatunnel.api.configuration.ReadonlyConfig – Config uses fallback configuration key ‘plugin_name’ instead of key ‘factory’
2023-12-19 00:11:22,011 INFO org.apache.seatunnel.api.configuration.ReadonlyConfig – Config uses fallback configuration key ‘plugin_name’ instead of key ‘factory’
2023-12-19 00:11:22,090 INFO org.apache.seatunnel.engine.client.job.ClientJobProxy – Start submit job, job id: 789162834679300097, with plugin jar [file:/root/apache-seatunnel-2.3.3/connectors/seatunnel/connector-fake-2.3.3.jar, file:/root/apache-seatunnel-2.3.3/connectors/seatunnel/connector-console-2.3.3.jar]
2023-12-19 00:11:22,893 INFO org.apache.seatunnel.engine.client.job.ClientJobProxy – Submit job finished, job id: 789162834679300097, job name: SeaTunnel
2023-12-19 00:11:22,956 WARN org.apache.seatunnel.engine.client.job.JobMetricsRunner – Failed to get job metrics summary, it maybe first-run
2023-12-19 00:11:24,370 INFO org.apache.seatunnel.engine.client.job.ClientJobProxy – Job (789162834679300097) end with state FINISHED
2023-12-19 00:11:24,416 INFO org.apache.seatunnel.core.starter.seatunnel.command.ClientExecuteCommand –
***********************************************
Job Statistic Information
***********************************************
Start Time : 2023-12-19 00:11:21
End Time : 2023-12-19 00:11:24
Total Time(s) : 2
Total Read Count : 32
Total Write Count : 32
Total Failed Count : 0
***********************************************

2023-12-19 00:11:24,416 INFO com.hazelcast.core.LifecycleService – hz.client_1 [seatunnel] [5.1] HazelcastClient 5.1 (20220228 – 21f20e7) is SHUTTING_DOWN
2023-12-19 00:11:24,422 INFO com.hazelcast.client.impl.connection.ClientConnectionManager – hz.client_1 [seatunnel] [5.1] Removed connection to endpoint: [localhost]:5801:772efc0a-4c18-4a4b-baa7-b82b9ae4a395, connection: ClientConnection{alive=false, connectionId=1, channel=NioChannel{/127.0.0.1:36095->localhost/127.0.0.1:5801}, remoteAddress=[localhost]:5801, lastReadTime=2023-12-19 00:11:24.411, lastWriteTime=2023-12-19 00:11:24.371, closedTime=2023-12-19 00:11:24.420, connected server version=5.1}
2023-12-19 00:11:24,422 INFO com.hazelcast.core.LifecycleService – hz.client_1 [seatunnel] [5.1] HazelcastClient 5.1 (20220228 – 21f20e7) is CLIENT_DISCONNECTED
2023-12-19 00:11:24,431 INFO com.hazelcast.core.LifecycleService – hz.client_1 [seatunnel] [5.1] HazelcastClient 5.1 (20220228 – 21f20e7) is SHUTDOWN
2023-12-19 00:11:24,433 INFO org.apache.seatunnel.core.starter.seatunnel.command.ClientExecuteCommand – Closed SeaTunnel client......
2023-12-19 00:11:24,433 INFO org.apache.seatunnel.core.starter.seatunnel.command.ClientExecuteCommand – Closed metrics executor service ......
2023-12-19 00:11:24,438 INFO org.apache.seatunnel.core.starter.seatunnel.command.ClientExecuteCommand – run shutdown hook because get close signal

Загрузите установочный пакет.
Установочный пакет доступен по следующему адресу:
https://seatunnel.apache.org/download
Распакуйте:

tar -zxvf apache-seatunnel-web-bin-${project.version}.tar.gz

Распакованный каталог выглядит следующим образом:

3.2.1 Ручная инициализация
Перед продолжением вручную выполните сценарий, а затем обновите информацию о подключении к базе данных в файле application.yml.

3.2.2 Использование сценария для инициализации базы данных
Прежде всего, установите следующие переменные среды:

export HOSTNAME=“localhost”
export PORT=“3306”
export USERNAME=“root”
export PASSWORD=“123456”

Затем выполните:

sh apache-seatunnel-web-bin-2.3.3/script/init_sql.sh

Сценарий инициализации базы данных или настройка информации о подключении к базе данных в application.yml

3.2.1 Ручная инициализация
Прежде чем продолжить, выполните сценарий вручную, а затем обновите информацию о подключении к базе данных в файле application.yml.
3.2.2 Использование сценария для инициализации базы данных
Прежде всего, установите следующие переменные среды:

export HOSTNAME=“localhost”
export PORT=“3306”
export USERNAME=“root”
export PASSWORD=“123456”

Затем выполните:

sh apache-seatunnel-web-bin-2.3.3/script/init_sql.sh

Если возникают конфликты с именами переменных среды, рассмотрите возможность переименования их в init_sql.sh, добавив префикс, например, STWEB_. Это позволит вам без проблем выполнить команду инициализации.
3.3 Изменение порта и источника данных
Отредактируйте файл conf/application.yml, чтобы обновить номер порта и информацию об источнике данных.

3.4 Копирование файлов конфигурации
Вам потребуется скопировать файлы apache-seatunnel-2.3.3/config/hazelcast-client и apache-seatunnel-2.3.3/connectors/plugin-mapping.properties в каталог apache-seatunnel-web-bin-2.3.3/conf.

3.5 Копирование файлов JAR в каталог lib.

3.6 Запуск приложения
Выполните следующую команду для запуска приложения:

sh bin/seatunnel-backend-daemon.sh start

Проверьте процессы Java с помощью jps, как показано ниже:

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

sh seatunnel-backend-daemon.sh start

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

3.7 Доступ к домашней странице
Для доступа к домашней странице используйте адрес ip:8081/ui, который является портом, настроенным в файле conf/application.yml.

http://192.168.1.4:8081/

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

service mysqld start # Start the MySQL service
service mysqld status # Check the status of the MySQL service
service mysqld stop # Stop the MySQL service
service mysqld restart # Restart the MySQL service
systemctl enable mysqld.service # Set MySQL service to start on boot
systemctl is-enabled mysqld.service # Confirm MySQL service is set to start on boot

3.8 Выполнение синхронизации данных из одной таблицы MySQL-JDBC в другую таблицу MySQL-JDBC
Выполнение прошло успешно, но на моей виртуальной машине с CentOS 7.x не была установлена среда Hadoop 3.1.3. Несмотря на это, в журналах не было обнаружено ошибок, что указывает на необязательный характер среды Hadoop, как указано в официальной документации. Однако для тех, кто компилирует и собирает локально без Hadoop, могут возникнуть ошибки установки, поэтому рекомендуется устанавливать Hadoop, чтобы избежать подобных проблем.

Заключение
Этот руководство направлено на упрощение установки и настройки SeaTunnel и SeaTunnel-Web в среде CentOS 7.x, решая возможные трудности на пути. Надеюсь, что этот материал поможет упростить процесс настройки и способствует более гладкой работе ваших задач по интеграции данных. Если вам понравилось это руководство, не забудьте поставить лайк, поделиться и подписаться для получения дополнительных идей. Удачной обработки данных!

Оригинал: https://medium.com/oolooroo/data-mesh-at-scale-integrating-semantic-layers-in-large-scale-systems-8bd1562b0fea

Введение
В стремительно развивающейся области архитектуры данных поиск систем, которые были бы масштабируемыми и эффективными, привел к появлению инновационных концепций и фреймворков. Среди них Data Mesh приобрел популярность как парадигма, обещающая революцию в обработке сложных данных в крупных организациях. Однако масштабируемость и эффективность Data Mesh в реальных приложениях в значительной степени зависят от его интеграции с другими технологическими компонентами, в первую очередь с семантическим уровнем.
Data Mesh, с его децентрализованным, ориентированным на домены подходом, предлагает убедительное решение для преодоления вызовов, созданных увеличивающимся объемом, скоростью и разнообразием данных в современных предприятиях. Его цель – демократизировать данные, распределяя владение и контроль доменно-специфическим командам, тем самым повышая гибкость и отзывчивость. Тем не менее, несмотря на все перспективы Data Mesh, его масштабируемость и функциональность на корпоративном уровне сталкиваются с существенными трудностями, в основном связанными с обеспечением когерентности, интероперабельности и эффективного управления данными в различных доменах.
Вступает семантический уровень – технология, разработанная для наложения на системы данных, предоставляя унифицированный, согласованный вид данных по всей организации. Семантический уровень играет ключевую роль в переводе сложных данных в формат, понятный и используемый для различных заинтересованных сторон, независимо от их технической экспертизы. Он служит ключевым элементом, который обеспечивает эффективную работу Data Mesh в масштабе, решая ключевые проблемы, такие как обнаружение данных, управление и интеграция.
Цель этой статьи – исследовать симбиотическое взаимодействие между Data Mesh и семантическим уровнем, с акцентом на том, как последний делает первый успешным в условиях крупномасштабных сред. Разбирая механику этой интеграции, статья прояснит трансформационный потенциал сочетания Data Mesh с семантическим уровнем, обрисовывая пути использования полного потенциала данных в корпоративной среде.
В следующих разделах будет более подробно рассмотрено Data Mesh и семантический уровень, их интеграция, вызовы и будущие перспективы этого сотрудничества в области архитектуры данных. Цель – предоставить всеобъемлющее понимание того, почему и как семантический уровень является ключевым элементом для эффективной работы Data Mesh в масштабе.

Scaling the Heights of Data Mesh: A Semantic Layer Expedition

Понимание Data Mesh
Определение и принципы Data Mesh
Data Mesh представляет собой новаторский подход в архитектуре данных, который фундаментально переосмысливает управление и использование данных в крупных организациях. Он базируется на четырех основных принципах:

1. Децентрализованная собственность данных, ориентированная на домены: Data Mesh выступает за перенос владения данными к командам, специализирующимся в определенной области, предоставляя им возможность управлять данными и контролировать их. Эта децентрализация дает командам автономию в обработке своих данных, выстраивая управление данными в соответствии с экспертизой домена.

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

3. Инфраструктура данных как сервис: Data Mesh подчеркивает важность предоставления командам самообслуживаемой инфраструктуры данных. Этот подход позволяет командам получать доступ, обрабатывать и анализировать данные без сильной зависимости от центральных ИТ- или данных-команд, способствуя гибкости и скорости.

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

Трудности масштабирования Data Mesh
Несмотря на трансформационный потенциал Data Mesh, его масштабирование в крупных организациях сталкивается с несколькими трудностями:

1. Интероперабельность и интеграция: Обеспечение интероперабельности и интеграции данных в различных децентрализованных доменах может быть сложным. Существует риск создания сило данных, что может привести к несогласованности и неэффективности.

2. Управление и стандартизация: Сбалансировать децентрализованный контроль с эффективным управлением и стандартизацией сложно. Требуется тонкий подход для обеспечения качества данных и соблюдения стандартов во всех доменах.

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

4. Культурные и организационные изменения: Принятие Data Mesh часто предполагает изменение корпоративной культуры. Переход от централизованной к децентрализованной модели требует согласия на всех уровнях организации и изменения в том, как команды взаимодействуют с данными.

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

...

Исследование Семантического Уровня
Определение и Цель Семантического Уровня
Семантический уровень является ключевым компонентом в современной архитектуре данных, действуя как мост между исходными данными и конечными пользователями, которым необходимо интерпретировать и использовать эти данные. Его цель – предоставить последовательный, унифицированный и понятный взгляд на данные по всей организации, независимо от сложностей или технических разнородностей в их основе.
Смысл семантического уровня заключается в абстрагировании технических деталей хранения данных, их форматов и схем, предоставляя пользователям упрощенный, ориентированный на бизнес взгляд на данные. Эта абстракция позволяет пользователям, включая тех, кто не обладает технической экспертизой, легко взаимодействовать с данными, анализировать и извлекать из них инсайты.
Основные Характеристики и Функции Семантического Уровня
Абстрагирование данных: Семантический уровень абстрагирует сложности основных структур данных, представляя упрощенный, ориентированный на бизнес взгляд. Эта абстракция позволяет пользователям фокусироваться на анализе данных, а не на сложностях управления ими.
Согласованная интерпретация данных: Он обеспечивает согласованную интерпретацию данных в организации путем стандартизации определений, метрик и KPI. Эта согласованность критична для поддержания целостности и надежности данных.
Доступность и Удобство использования: Предоставляя более доступный интерфейс, семантический уровень способствует широкому использованию данных в организации, позволяя неспециалистам в области технологий использовать данные для принятия решений.
Интеграция и Интероперабельность: Семантический уровень облегчает интеграцию данных из различных источников и форматов, способствуя интероперабельности и уменьшая риски образования сило данных.
Улучшенное Управление и Безопасность: Он поддерживает управление данными, обеспечивая контроль доступа, стандарты конфиденциальности данных и требования к соответствию, гарантируя ответственное и безопасное использование данных.
Оптимизация запросов и производительность: Для эффективной работы семантический уровень должен оптимизировать запросы, чтобы минимизировать нагрузку на основные источники данных и улучшить время ответа на запросы конечных пользователей.
Управление метаданными: Семантический уровень должен эффективно управлять метаданными, предоставляя контекст и смысл данных, что критично для понимания линейности данных.
Семантический уровень играет ключевую роль в преобразовании сырых, сложных данных в действенные идеи. Его интеграция в архитектуры Data Mesh, как обсуждается в следующем разделе, является ключевым моментом для преодоления проблем масштабирования и сложности, связанных с децентрализованными средами данных.

Semantic Layer Architecure

Интеграция Семантического Уровня в Data Mesh
Преодоление Проблем Масштабирования в Data Mesh
Интеграция семантического уровня в архитектуру Data Mesh играет ключевую роль в преодолении проблем масштабирования. Data Mesh, своей природой, включает в себя несколько децентрализованных доменов, каждый из которых имеет свои модели данных и структуры. С увеличением числа этих доменов растет сложность управления и интеграции данных в организации. Семантический уровень выступает в роли унифицирующей силы, предоставляя последовательное, охватывающее всю организацию толкование данных, независимо от их источника или формата.
Повышение Обнаружимости и Интероперабельности Данных
В среде Data Mesh семантический уровень помогает сделать данные легко обнаруживаемыми и доступными в различных доменах. Он предоставляет общий язык для данных, преодолевая различия в моделях доменов и делая возможным и эффективным анализ данных между доменами.
Интероперабельность, обеспечиваемая семантическим уровнем, гарантирует, что данные из различных доменов могут интегрироваться без проблем, уменьшая риск образования сило данных и несогласованной аналитики.
Улучшение Управления Данными
Управление данными в децентрализованной среде, такой как Data Mesh, может быть сложным. Семантический уровень способствует управлению, обеспечивая согласованные определения данных, стандарты конфиденциальности и контроль доступа во всех доменах.
Этот уровень также играет ключевую роль в управлении соблюдением, так как он может отслеживать и контролировать, как данные используются и распространяются внутри организации, обеспечивая соблюдение законодательных и регуляторных стандартов.
Содействие Гибкому Управлению Данными
Семантический уровень дает командам доменов возможность эффективнее управлять своими данными, упрощая сложности интеграции и интерпретации данных. Эта гибкость критична для бизнеса, который должен быстро реагировать на изменения на рынке или внутренние требования.
Балансировка Децентрализации с Согласованностью
Интеграция семантического уровня в Data Mesh находит баланс между децентрализацией и согласованностью. В то время как Data Mesh позволяет доменам работать независимо, семантический уровень обеспечивает унифицированное понимание и подход к данным в этих доменах. Этот баланс является ключом к достижению масштабируемости и эффективности в условиях крупномасштабных сред данных.
В заключение, интеграция семантического уровня в Data Mesh решает ключевые проблемы масштабирования, интероперабельности и управления. Он выступает в роли катализатора, который не только обеспечивает эффективную работу Data Mesh в масштабе, но также усиливает его общую ценность в управлении сложными данными.
Проблемы и Соображения при Интеграции Семантического Уровня в Data Mesh
Хотя интеграция семантического уровня в Data Mesh предлагает значительные преимущества, она также представляет уникальные проблемы и соображения. Эффективное их решение является ключом к раскрытию полного потенциала этой интеграции.
Сложности в Реализации:
Техническая сложность: Разработка и внедрение семантического уровня, который эффективно взаимодействует с несколькими децентрализованными доменами данных, может быть технически сложной задачей. Требуется глубокое понимание как архитектуры данных, так и бизнес-контекста.
Трудности Интеграции: Бесшовная интеграция семантического уровня с существующей инфраструктурой данных, особенно в организациях с устаревшими системами, может быть сложной. Этот процесс часто требует значительных модификаций существующих конвейеров данных и решений для хранения данных.
Организационные и Культурные Асп

екты
Управление Изменениями: Внедрение семантического уровня в рамках структуры Data Mesh включает значительные организационные изменения. Выработка культуры, которая принимает этот новый подход к управлению данными, является ключевым фактором успеха.
Навыки и Обучение: Внедрение семантического уровня требует специализированных навыков. Организации должны инвестировать в обучение своего персонала или привлекать новые кадры для эффективного управления и использования этого уровня.
Поддержание Качества и Согласованности Данных
Обеспечение согласованного качества данных и их определений во всех доменах становится более сложным с введением семантического уровня. Требуется непрерывный мониторинг и управление для поддержания целостности и полезности данных.
Балансировка Гибкости и Стандартизации
Хотя семантический уровень способствует стандартизации интерпретации данных, важно уравновешивать это с гибкостью, необходимой для различных доменов. Нахождение правильного баланса критично для того, чтобы семантический уровень не стал узким местом или не помешал инновациям, специфичным для домена.
Масштабируемость и Оптимизация Производительности
По мере роста объема данных важно обеспечить эффективное масштабирование семантического уровня, сохраняя при этом высокую производительность. Это требует тщательного планирования и непрерывной оптимизации.
Управление и Соблюдение Законов
Внедрение семантического уровня включает в себя решение сложных проблем управления и соблюдения законов, особенно в регулируемых отраслях. Гарантировать, что семантический уровень соответствует всем соответствующим законам и нормативам, является важным.
Для решения этих проблем и учета соображений организации должны принять стратегический и всесторонний подход к интеграции семантического уровня в их архитектуру Data Mesh. Ключ к успеху заключается в тщательном планировании, понимании уникальных потребностей организации и непрерывных итерациях и усовершенствования.

Заключение и Перспективы
Сводка Основных Находок
В данной статье была рассмотрена ключевая роль семантического уровня в увеличении масштабируемости и эффективности архитектур Data Mesh. Интеграция семантического уровня решает фундаментальные проблемы в рамках Data Mesh, особенно в областях масштабируемости, интероперабельности и управления, предоставляя унифицированный, последовательный взгляд на данные в разнообразных доменах.
Значимость Семантического Уровня в Data Mesh
Семантический уровень выступает как существенный активатор для Data Mesh, особенно в масштабных и сложных средах данных. Он упрощает доступ и анализ данных, обеспечивает согласованную интерпретацию данных и способствует лучшему управлению и соблюдению. Эти факторы являются ключевыми для раскрытия полного потенциала Data Mesh, позволяя организациям более эффективно и отзывчиво использовать свои данные.
Проблемы и Стратегические Соображения
Несмотря на значительные выгоды, интеграция семантического уровня в Data Mesh не обходится без своих трудностей. Среди них – техническая сложность, необходимость специализированных навыков, поддержание качества данных и поиск баланса между стандартизацией и гибкостью. Решение этих проблем требует стратегического подхода, опирающегося на крепкое руководство, эффективное управление изменениями и непрерывную адаптацию и обучение.
Будущие Последствия и Развитие
В перспективе интеграция семантических уровней в архитектуры Data Mesh собирается сыграть ключевую роль в эволюции практик управления данными. По мере развития технологий мы можем ожидать:
Технологические Достижения: Дальнейшие разработки в области искусственного интеллекта и машинного обучения могут усовершенствовать возможности семантических уровней, делая их более динамичными и интеллектуальными в обработке сложностей данных.
Более Широкое Принятие и Созревание: По мере того как больше организаций применяют эту интеграцию, лучшие практики и методологии, вероятно, будут созревать, предоставляя более стандартизированные подходы к внедрению.
Влияние на Культуру Данных: Ожидается, что эта интеграция повлияет на организационные культуры данных, акцентируя более коллективный и демократизированный подход к управлению данными.
Инновации в Управлении Данными: Непрерывное развитие семантических уровней в архитектурах Data Mesh, вероятно, стимулирует инновации, предлагая новые способы управления и извлечения ценности из данных.
В заключение, интеграция семантического уровня в Data Mesh представляет собой значительный прогресс в области архитектуры данных. Он обещает сделать Data Mesh более масштабируемым, управляемым и эффективным, особенно в сложных и богатых данными средах. По мере того как эта область продолжает развиваться, она несомненно представит новые вызовы и возможности, но потенциальные выгоды для организаций в более эффективном использовании их данных являются существенными и убедительными.

Смотрим тут: https://www.nftenergy.art
Интересные участники. И конечно Вини тоже там:

Что бы все мечты сбылись. Мира, здоровья и добра!

https://medium.com/airbnb-engineering/data-quality-score-the-next-chapter-of-data-quality-at-airbnb-851dccda19c3

Автор: Кларк Райт

Введение

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

С 1,4 миллиарда кумулятивных посещений гостей на конец 2022 года рост Airbnb вынудил нас прийти к точке перегиба, где ухудшение качества данных начало препятствовать работе наших специалистов по данным. Еженедельные отчеты по метрикам были трудно подготовить в срок. Вроде бы базовые метрики, такие как “Активные объявления”, зависели от сложной сети зависимостей. Для проведения значимой работы с данными требовалось значительное институциональное знание для преодоления скрытых трудностей с данными.

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

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

Как мы могли бы распространить выигрыши и лучшие практики Midas на весь наш хранилище данных?

В этом блоге мы расскажем о нашем инновационном подходе к оценке качества данных — Оценке качества данных Airbnb (“DQ Score”). Мы расскажем, как мы разработали DQ Score, как он используется сегодня и как он будет поддерживать следующий этап обеспечения качества данных в Airbnb.

Масштабирование качества данных

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

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

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

Мы определили следующие цели для оценки:

Эволюция нашего понимания качества данных за пределами простого двоичного определения (сертифицированные против несертифицированных).
Выравнивание входных компонентов для оценки качества данных.
Обеспечение полной видим

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

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

Полное охват — оценка может быть применена к любому активу данных офлайн-хранилища данных
Автоматизированность — сбор входных данных, определяющих оценку, на 100% автоматизирован
Действенность — оценка легко обнаруживается и используется как для производителей, так и для потребителей
Многомерность — оценку можно разложить на столбы качества данных
Эволютивность — критерии оценки и их определения могут меняться со временем
Хотя они могут показаться простыми или очевидными, установка этих принципов была критичной, поскольку они направляли каждое принятое решение в разработке оценки. Вопросы, которые в противном случае могли бы сорвать прогресс, были сопоставлены нашими принципами.

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

У нас также был ряд входных сигналов, которые более прямо измеряли качество (сертификация Midas, проверка данных, ошибки, SLA, автоматические проверки качества данных и т. д.), в то время как другие были более похожи на показатели качества (например, правильная принадлежность, хорошая гигиеничность управления, использование инструментов планирования). Были ли более явные и прямые измерения качества более ценными, чем показатели?

Руководствуясь нашими принципами, мы в конечном итоге определили четыре измерения качества данных: Точность, Надежность (Своевременность), Управление и Удобство использования. Было несколько других возможных измерений, которые мы рассматривали, но эти четыре измерения были наиболее смысловыми и полезными для наших практиков данных и имели смысл как оси улучшения, на которых нам важно и мы готовы инвестировать в улучшение наших данных вдоль этих измерений.

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

Мы также могли бы взвесить каждое измерение в соответствии с нашим восприятием его важности для определения качества. Мы учитывали 1) сколько оценочных компонентов принадлежит каждому измерению, 2) обеспечивая быстрый умственный расчет, и 3) какие элементы важны больше всего для наших практикующих, чтобы распределить 100 общих баллов между измерениями:

The “Dimensions of Data Quality” and their weights

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

Unpacking the Data Stewardship Dimension

Представление Рейтинга для Практиков

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

К счастью, у нас было два существующих инструмента, которые сделали бы это гораздо проще: Dataportal (каталог данных и пользовательский интерфейс для исследования данных Airbnb) и Unified Metadata Service (UMS). Сам рейтинг вычисляется в ежедневном автономном потоке данных, который собирает и преобразует различные элементы метаданных из наших систем данных. Завершающий этап потока данных загружает рейтинг для каждого актива данных в UMS. Подключив DQ Score к UMS, мы можем предоставлять рейтинг и его компоненты наряду с каждым активом данных в Dataportal, отправной точке для всех открытий и исследований данных в Airbnb. Оставалось только разработать его представление.

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

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

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

1. Единый высокоуровневый рейтинг от 0 до 100. Мы установили категориальные пороги “Плохо”, “Хорошо”, “Отлично” и “Превосходно” на основе анализа профилирования нашего хранилища данных, который изучал существующее распределение нашего Рейтинга DQ. Подходит для быстрой высокоуровневой оценки общего качества набора данных.

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

3. Полная детализация рейтинга + Шаги по улучшению, где пользователи данных могут видеть, в чем конкретно актив уступает, и продюсеры данных могут предпринять меры для улучшения качества актива.

Все три эти представления показаны на скриншотах ниже. Стандартное представление предоставляет измерения “Баллы за категорию”, категориальный дескриптор “Плохо” вместе с 40 баллами и шагами по улучшению.

Full data quality score page in Dataportal

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

Full score detail presentation

Как сегодня используется рейтинг

Для производителей данных рейтинг предоставляет:

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

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

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

Что дальше

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

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

Благодарности

Рейтинг DQ не был бы возможен без участия нескольких кросс-функциональных и кросс-организационных коллег. К ним относятся, но не ограничиваются: Марк Стейнбрик, Читта Широлкар, Джонатан Паркс, Сильвия Томияма, Феликс Оук, Джейсон Флиттнер, Ин Пан, Логан Джордж, Вуди Чжоу, Мишель Томас и Эрик Риттер.

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

Если вас интересует такая работа, ознакомьтесь с некоторыми из наших связанных вакансий.

****************

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

Перевод ChatGPT

https://medium.com/free-code-camp/the-rise-of-the-data-engineer-91be18f1e603

В 2011 году я присоединился к Facebook в качестве инженера по бизнес-аналитике. К моменту моего ухода в 2013 году я уже был инженером по данным.
Меня не повысили и не перевели на новую должность. Вместо этого в Facebook поняли, что наша работа выходит за рамки классической бизнес-аналитики. Роль, которую мы создали для себя, представляла собой совершенно новую дисциплину.
Моя команда была на переднем крае этой трансформации. Мы разрабатывали новые навыки, новые способы ведения работы, новые инструменты и, как правило, отказывались от традиционных методов.
Мы были первопроходцами. Мы были инженерами по данным!
Инженерия данных?
Наука о данных как дисциплина проходила свой период подросткового самоподтверждения и самоопределения. В то же время инженерия данных была немного младшей сестрой, но проходила через что-то похожее. Дисциплина инженерии данных брала подсказки от своей старшей сестры, определяя себя также в противопоставлении и находя свою уникальную идентичность.
Как и у данных ученых, у инженеров по данным есть кодирование. Они высокоаналитичны и интересуются визуализацией данных.
В отличие от данных ученых и вдохновленные более зрелым родителем, программной инженерией, инженеры по данным строят инструменты, инфраструктуру, фреймворки и сервисы. Фактически можно утверждать, что инженерия данных ближе к программной инженерии, чем к науке о данных.
В отношении ранее существовавших ролей область инженерии данных может рассматриваться как суперсет бизнес-аналитики и хранилища данных, внедряя более многоэлементные элементы программной инженерии. Эта дисциплина также интегрирует специализацию вокруг операций так называемых распределенных систем “больших данных”, концепций расширенной экосистемы Hadoop, потоковой обработки и вычислений в масштабе.
В малых компаниях, где еще не формализована команда по инфраструктуре данных, роль инженера по данным может также включать в себя нагрузку по настройке и обслуживанию инфраструктуры данных организации. К этим задачам относятся установка и обслуживание платформ, таких как Hadoop/Hive/HBase, Spark и подобных.
В более крупных средах часто происходит специализация и создание формальной роли для управления этой нагрузкой, по мере роста потребности в команде инфраструктуры данных. В этих организациях автоматизация некоторых процессов инженерии данных ложится на руки как команде по инженерии данных, так и команде по инфраструктуре данных, и часто эти команды сотрудничают для решения более высокоуровневых проблем.
В то время как инженерный аспект роли расширяется, другие аспекты исходной роли бизнес-инженера становятся второстепенными. Области, такие как создание и поддержание портфелей отчетов и панелей, не являются первостепенным вниманием инженера по данным.
ETL меняется
Мы также наблюдаем общий отход от инструментов ETL с интерфейсом перетаскивания и редактирования в сторону более программного подхода. Знание продуктовых платформ, таких как Informatica, IBM Datastage, Cognos, AbInitio или Microsoft SSIS, не так распространено среди современных инженеров

по данным и заменяется более общими навыками программной инженерии, а также пониманием программных или конфигурационно-управляемых платформ, таких как Airflow, Oozie, Azkabhan или Luigi. Также довольно распространено, что инженеры разрабатывают и управляют своими собственными оркестраторами/планировщиками заданий.
Есть множество причин, почему сложные программы не разрабатываются с использованием инструментов перетаскивания и редактирования: в конечном итоге код – это лучшая абстракция для программного обеспечения. Хотя за пределами этой статьи сложно спорить на эту тему, легко предположить, что те же самые причины применимы к написанию ETL, как и к любому другому программному обеспечению. Код позволяет использовать произвольные уровни абстракции, работает с любыми логическими операциями знакомым способом, хорошо интегрируется с контролем версий, легко версионируется и сотрудничает. Факт того, что инструменты ETL эволюционировали в сторону графических интерфейсов, кажется каким-то отклонением в истории обработки данных и, безусловно, заслуживает собственного интересного блога.
Давайте подчеркнем тот факт, что абстракции, предлагаемые традиционными инструментами ETL, являются нецелевыми. Конечно, есть необходимость в абстрагировании сложности обработки данных, вычислений и хранения. Но я бы утверждал, что решение не заключается в предоставлении примитивов ETL (таких как источник/цель, агрегации, фильтрация) в форме перетаскивания и редактирования. Нужны абстракции более высокого уровня.
Например, примером нужной абстракции в современной среде данных является конфигурация экспериментов в рамках структуры тестирования A/B: какие все эксперименты? какие связанные обработки? какой процент пользователей должен быть выставлен? какие метрики ожидается, что каждый эксперимент повлияет? когда вступает в силу эксперимент? В этом примере у нас есть структура, которая получает точный, высокоуровневый ввод, выполняет сложные статистические вычисления и предоставляет вычисленные результаты. Мы ожидаем, что добавление нового эксперимента приведет к дополнительным вычислениям и результатам. Важно отметить в этом примере, что входные параметры этой абстракции не соответствуют параметрам, предлагаемым традиционным инструментом ETL, и что создание такой абстракции в интерфейсе перетаскивания и редактирования было бы невозможно.
Для современного инженера по данным традиционные инструменты ETL в значительной степени устарели, потому что логику нельзя выразить с помощью кода. В результате необходимые абстракции не могут быть выражены интуитивно в этих инструментах. Учитывая, что роль инженера по данным в значительной степени заключается в определении ETL, и зная, что для этого нужен совершенно новый набор инструментов и методологии, можно утверждать, что это заставляет дисциплину перестраиваться с нуля. Новый стек, новые инструменты, новый набор ограничений и, во многих случаях, новое поколение специалистов.

Меняющаяся модель данных

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

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

• Дальнейшая денормализация: поддержание заменителей ключей в измерениях может быть трудным и делает фактические таблицы менее читаемыми. Использование естественных, понятных человеку ключей и атрибутов измерений в фактических таблицах становится более общим, уменьшая необходимость в дорогостоящих объединениях, которые могут быть сложными для распределенных баз данных. Также следует отметить, что поддержка кодирования и сжатия в сериализационных форматах, таких как Parquet или ORC, или в базах данных, таких как Vertica, решает большинство проблем с производительностью, которые обычно сопутствуют денормализации. Эти системы научились нормализовывать данные для хранения самостоятельно.
• BLOB: современные базы данных имеют растущую поддержку для BLOB через встроенные типы и функции. Это открывает новые возможности в арсенале моделировщика данных и может позволять фактическим таблицам хранить несколько зерен одновременно, когда это необходимо.
• Динамические схемы: с появлением MapReduce, растущей популярностью хранилищ документов и поддержкой BLOB в базах данных становится проще эволюционировать схемы базы данных без выполнения DML. Это упрощает итеративный подход к хранилищу данных и устраняет необходимость в полном консенсусе и согласовании до разработки.
• Систематическое создание снимков измерений (хранение полной копии измерения для каждого цикла ETL, обычно в отдельных разделах таблицы) в качестве общего способа обработки измерений со скользящим изменением (SCD) – простой универсальный подход, требующий небольших усилий инженерии и который, в отличие от классического подхода, легко понимается при написании ETL и запросов. Также легко и относительно дешево денормализовать атрибут измерения в фактическую таблицу, чтобы отслеживать его значение в момент транзакции. В ретроспективе сложные техники моделирования SCD не интуитивны и снижают доступность.
• Соответствие, как в соответствующих измерениях и метриках, по-прежнему чрезвычайно важно в современной среде данных, но с необходимостью хранилищ данных двигаться быстро и с привлечением большего числа команд и ролей для участия в этом усилии, это менее императивно и скорее является компромиссом. Согласование и сходимость могут происходить как фоновый процесс в областях, где болевая точка расхождения становится неприемлемой.
• Также, в более общем смысле, можно утверждать, что с товаризацией циклов вычислений и с более продвинутыми пользователями данных, чем раньше, становится менее необходимым предварительное вычисление и сохранение результатов в хранилище данных. Например, можно использовать сложные задания Spark, которые могут вычислять сложный анализ по требованию, а не планироваться для включения в хранилище данных.

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

ие аспекты его создания и эксплуатации. Фокус инженера по данным – это хранилище данных, и он вращается вокруг него.

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

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

Также роль команды по инженерии данных заключается в том, чтобы быть “центром компетенции” через определение стандартов, bewt-практик и процессов сертификации для объектов данных. Команда может эволюционировать, чтобы принимать участие или лидировать программу образования, предоставляя свои основные компетенции для помощи другим командам в становлении лучшими участниками хранилища данных. Например, у Facebook есть программа образования “Data Camp”, а Airbnb разрабатывает аналогичную программу “Data University”, где инженеры данных ведут занятия, обучая людей, как быть компетентными в области данных.

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

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

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

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

Интеграция данных

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

Разрешение SaaS определять справочные данные без интеграции и обмена общим основным ключом — это катастрофа, которую следует избегать любой ценой. Никто не хочет вручную поддерживать два списка сотрудников или клиентов в двух разных системах, а тем более заниматься нечетким сопоставлением при возвращении их данных по управлению персоналом в их хранилище данных.
Еще хуже, руководители компаний часто заключают сделки с поставщиками SaaS, не рассматривая настоящие вызовы интеграции данных. Рабочая нагрузка по интеграции систематически занижается поставщиками, чтобы облегчить продажи, и оставляет инженеров данных замешанными на неучтенной, недооцененной работе. Не говоря уже о том, что типичные API SaaS часто плохо разработаны, неясно документированы и “гибкие”: что означает, что вы можете ожидать изменений без предупреждения.

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

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

• ввод данных: сервисы и инструменты для “парсинга” баз данных, загрузки журналов, извлечения данных из внешних хранилищ или API, …
• вычисление метрик: фреймворки для вычисления и суммирования метрик, связанных с участием, ростом или сегментацией
• обнаружение аномалий: автоматизация потребления данных для оповещения о нештатных событиях или существенных изменениях тенденций
• управление метаданными: инструменты для генерации и потребления метаданных, упрощающие поиск информации в хранилище данных и вокруг него
• экспериментирование: фреймворки тестирования A/B и экспериментов часто являются ключевой частью аналитики компании с существенным компонентом инженерии данных
• инструментирование: аналитика начинается с регистрации событий и атрибутов, связанных с этими событиями, инженеры данных имеют заинтересованность в том, чтобы убедиться, что высококачественные данные захватываются вверх по потоку
• сессионизация: конвейеры, специализированные в понимании последовательности действий во времени, позволяющие аналитикам понимать поведение пользователя
  Как и программисты, инженеры данных должны постоянно стремиться автоматизировать свои рабочие нагрузки и создавать абстракции, позволяющие им подниматься по лестнице сложности. Хотя характер рабочих процессов, которые можно автоматизировать, различается в зависимости от окружения, необходимость в автоматизации обща для всех.

Навыки, необходимые для работы

Владение SQL: если английский язык — это язык бизнеса, то SQL — язык данных. Как успешно может быть предприниматель, не зная хорошо английский? Несмотря на то что технологии приходят и уходят, SQL по-прежнему стоит крепко, как лингва франка в мире данных. Инженер по данным должен быть способен выражать любую степень сложности на SQL, используя техники, такие как “коррелированные подзапросы” и оконные функции. Основы SQL/DML/DDL настолько просты, что не должны оставаться тайной для инженера по данным. Помимо декларативной природы SQL, он/она должны уметь читать и понимать планы выполнения запросов в базе данных, иметь представление о том, как работают индексы, различные алгоритмы объединения и распределенное измерение в плане выполнения.

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

Проектирование ETL: написание эффективных, устойчивых и “развиваемых” ETL имеет ключевое значение. Я планирую расширить эту тему в предстоящем блоге.

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

В целом
За последние 5 лет, работая в Силиконовой долине в Airbnb, Facebook и Yahoo!, и взаимодействуя обширно с командами по данным различных компаний, таких как Google, Netflix, Amazon, Uber, Lyft и десятки компаний разных размеров, я замечаю растущий консенсус относительно того, каким образом “инженерия данных” развивается, и почувствовал необходимость поделиться некоторыми из моих наблюдений.
Я надеюсь, что этот материал может служить своего рода манифестом для инженерии данных, и я надеюсь вызвать реакции от сообщества, работающего в связанных областях!

Перевел chatGPT

https://blog.devgenius.io/comparison-of-the-open-source-query-engines-trino-and-starrocks-cf959049f9ab

В этом посте мы хотим сравнить Trino, популярный распределенный движок для выполнения аналитических запросов на больших объемах данных с интерактивными задержками, с StarRocks.
Источники информации

Мы консультировались с участниками StarRocks (Хэнг Чжао, член TSC StarRocks; Дориан Чжэн, активный участник StarRocks). Что касается Trino, мы использовали веб-сайт Trino и поиск в Google для исследования различных тем. Мы сравнили последние версии обоих продуктов на октябрь 2023 года.
Возрождение Trino/Presto

Изначально Presto был задуман и разработан в Facebook (теперь известном как Meta) для того, чтобы позволить их аналитикам выполнять интерактивные запросы в их обширном хранилище данных Apache Hadoop. Проект, возглавляемый Мартином Траверсо, Дэйном Сандстромом, Дэвидом Филлипсом и Эриком Хуангом, начался в 2012 году как решение для преодоления ограничений Apache Hive, который ранее использовался для SQL-аналитики в обширном хранилище данных Facebook, но оказался слишком медленным для обширных потребностей компании. Presto был публично внедрен в Facebook в том же году и позже был представлен в виде open source в ноябре 2013 года.

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

• Мог эффективно обрабатывать большие наборы данных и сложные запросы (по сравнению с другими технологиями, доступными на тот момент).
  a. Конкретно, гораздо быстрее, чем технология MapReduce, такая как Apache Hive, которая тогда была актуальной.
  b. Мог подключаться к множеству различных источников данных: в частности, подключаться к нескольким базам данных одного типа с возможностью объединения наборов данных между базами данных (например, горизонтальное масштабирование экземпляров баз данных).
• Мог масштабироваться для удовлетворения потребностей крупных организаций: Facebook продемонстрировал, что Presto может работать, и другие технологические “единороги” быстро приняли его для своих потребностей в хранилище данных.
• Open Source: кто не хочет, чтобы кто-то другой проводил исследования и разработку программного обеспечения за “бесплатно”?

Проект Presto претерпел значительные изменения за десятилетие. В 2018–2019 годах, после ухода оригинальных основателей из Facebook, проект разделился на две ветки: PrestoDB и PrestoSQL. Это разделение было ответом на изменяющиеся потребности и направление сообщества Presto.
Trino возник из ветви PrestoSQL. В январе 2021 года PrestoSQL был переименован в Trino. Trino сохранил свои корни в обработке данных большого объема, принимая архитектуру Massively Parallel Processing (MPP) и разрабатываясь на Java. Это отличало его от традиционных фреймворков MapReduce, улучшая его способность эффективно обрабатывать и обрабатывать большие объемы данных.

Изменение требований пользователей

С момента появления Trino/Presto они удовлетворительно соответствовали большинству потребностей пользователей в анализе данных на тот момент. Тем не менее стоит отметить, что требования пользователей к анализу данных по-прежнему постоянно меняются и развиваются. Это особенно явно после того, как мир был завоеван мобильным интернетом и приложениями SaaS, с пользовательским анализом и аналитикой в реальном времени, становящимися важными трендами для предприятий.
Основные проявления этого тренда следующие:

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

Именно из-за этих новых трендов несколько инженеров баз данных начали новый проект базы данных в 2020 году, названный StarRocks, и официально открыли его исходный код в сентябре 2021 года. StarRocks был передан в Linux Foundation в начале 2023 года. Хотя он существует недолго, влияние StarRocks, кажется, стремительно растет. В настоящее время сотни крупных предприятий по всему миру используют StarRocks в производственных средах.

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

Сходства между Trino и StarRocks
У StarRocks и Trino много сходств в технических характеристиках.

Massively Parallel Processing (MPP)
Обе системы используют MPP в качестве своей распределенной среды выполнения. В этой среде запрос разбивается на множество логических и физических блоков выполнения и выполняется одновременно на нескольких узлах. В отличие от шаблона scatter-gather, используемого многими другими продуктами для аналитики данных в их распределенных вычислительных средах, MPP может использовать больше ресурсов для обработки запросов. Из-за этой среды обе системы могут использоваться для работы с петабайтами данных, и сотни крупных компаний уже используют эти системы в своих производственных средах.

Cost-based Optimizer (CBO)
У обеих систем есть Cost-based Optimizer. В запросах с многотабличным объединением, помимо исполнителя запроса, оптимизированные планы выполнения также могут сыграть ключевую роль в улучшении производительности запроса. Благодаря CBO обе системы могут поддерживать различные функции SQL, включая сложные запросы, объединения и агрегации. Как Trino, так и StarRocks успешно прошли тесты TPC-H и более сложного теста TPC-DS.

Pipeline Execution Framework
У обеих систем есть Framework выполнения конвейера. Основная цель Framework выполнения конвейера – улучшение эффективности использования многозадачных ресурсов в запросе на одном компьютере. Его основные функции охватывают три аспекта:

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

ANSI SQL Support
Обе системы соответствуют ANSI SQL. Это означает, что аналитики могут использовать язык запросов, с которым они наиболее знакомы в своей повседневной работе, без необходимости дополнительных затрат на обучение. Инструменты бизнес-аналитики, которыми часто пользуются предприятия, также легко интегрируются с StarRocks или Trino.

Различия между Trino и StarRocks
Хотя есть некоторые сходства в технической реализации, мы также видим некоторые явно различные технические характеристики между этими двумя видами систем.

Векторизированный движок запросов

StarRocks – это нативный векторизированный движок, реализованный на C++, в то время как Trino реализован на Java и использует ограниченную технологию векторизации. Технология векторизации помогает StarRocks более эффективно использовать вычислительную мощность ЦП. Этот тип движка запросов обладает следующими характеристиками:

• Полностью использует эффективность управления данными в столбцах. Такой движок запросов читает данные из колоночного хранилища, и способ управления данными в памяти, а также способ обработки операторов данных, является колоночным. Такие движки могут более эффективно использовать кэш ЦП, повышая эффективность выполнения ЦП.
• Полностью использует SIMD-инструкции, поддерживаемые ЦП. Это позволяет ЦП завершать больше вычислений данных за меньшее количество тактовых циклов. Согласно данным, предоставленным StarRocks, использование векторизированных инструкций может улучшить общую производительность в 3-10 раз.
• Более эффективно сжимает данные, что значительно снижает использование памяти. Это делает такой тип движка запросов более способным обрабатывать запросы с большим объемом данных.

Фактически Trino также исследует технологию векторизации. У Trino есть некоторый SIMD-код, но он отстает по сравнению с StarRocks по глубине и охвату. Trino все еще работает над улучшением своих усилий по векторизации (см. https://github.com/trinodb/trino/issues/14237). Проект Velox в Meta направлен на использование технологии векторизации для ускорения запросов Trino. Однако до сих пор очень мало компаний официально использовали Velox в производственных средах.

Материализованный вид

У StarRocks есть несколько функций материализованных видов, которых у Trino нет. Материализованный вид – это продвинутый способ ускорения общих запросов. Как StarRocks, так и Trino поддерживают создание материализованных видов; однако у StarRocks есть возможность:

• Автоматически переписывать запросы для улучшения производительности запроса. Это означает, что StarRocks автоматически выбирает подходящие материализованные виды для ускорения запросов. Пользователям не нужно переписывать свои SQL-запросы, чтобы использовать материализованные виды.
• Выполнять обновление материализованного вида на уровне раздела, что позволяет пользователю добиться лучшей производительности и масштабируемости при снижении потребления ресурсов.
• Возможность записи материализованных видов на локальный диск вместо удаленного диска/хранилища. Это означает, что пользователи могут использовать высокую производительность локального диска. Локальное хранилище использует собственный колоночный формат хранения StarRocks, который лучше поддерживает выполнение векторизированного движка запросов.

У Trino в настоящее время нет этих функций:

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

Система кэширования

Система кэширования в StarRocks сложнее, чем в Trino. StarRocks реализует кластер-осведомленный кэш данных на каждом узле. Этот кэш использует комбинацию памяти и диска, которую можно использовать для промежуточных и конечных результатов запроса. В результате этого компонента StarRocks имеет возможность кэшировать метаданные Apache Iceberg на локальных дисках для лучшей производительности запросов. StarRocks также поддерживает предварительное заполнение кэша, установку приоритетов кэша и установку черных списков кэша.

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

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

Система кэширования Trino работает только на уровне памяти. Это делает ее очень быстрой и предполагает использование более многочисленных и крупных виртуальных машин с памятью. Ведется работа по поддержке кэширования на локальном диске для “горячего кэша”.
Подробнее читайте по ссылкам https://github.com/trinodb/trino/pull/16375 и https://github.com/trinodb/trino/pull/18719.

Производительность соединения

Как Trino, так и StarRocks могут поддерживать сложные операции соединения. Однако StarRocks способен предоставить более высокую производительность. Это происходит потому, что, помимо векторизированного движка запросов, StarRocks также обладает некоторыми специальными техническими возможностями.
Переупорядочивание соединений – это техника, которая может быть использована для улучшения производительности запросов к базе данных, включающих множественные соединения. Она работает путем изменения порядка выполнения соединений.
Стоимость выполнения запроса соединения зависит от размера таблиц, участвующих в соединении, и порядка выполнения соединений. Переупорядочивая соединения, можно найти более эффективный план соединения. Переупорядочивание соединений может выполняться оптимизатором или может быть указано вручную пользователем. Оптимизатор обычно пытается переупорядочить соединения для минимизации стоимости запроса.
Существует несколько различных алгоритмов, которые могут использоваться для переупорядочивания соединений. Некоторые из наиболее распространенных алгоритмов, реализованных в StarRocks, включают:

• Жадный алгоритм: Жадный алгоритм работает путем повторного выбора пары таблиц с наименьшей стоимостью соединения и их объединения.
• Алгоритм динамического программирования: Алгоритм динамического программирования работает построением таблицы, содержащей стоимость соединения каждой пары таблиц. Затем алгоритм использует эту таблицу для поиска оптимального плана соединения.
• Алгоритм исчерпания: Техника выполнения соединений данных, особенно подходящая для больших наборов данных. Он работает разбиением операции соединения на более мелкие, более управляемые задачи, что позволяет выполнять соединения с наборами данных, которые слишком велики для помещения в память.
• Переупорядочивание соединений слева-направо: Эвристический алгоритм, используемый для оптимизации порядка соединений в запросе. Алгоритм начинает с самой маленькой таблицы и затем рекурсивно соединяет ее с следующей по размеру таблицей, пока все таблицы не будут соединены.
• Алгоритм ассоциативности соединения: Техника оптимизации порядка соединений в запросе. Он работает путем использования свойства ассоциативности соединений, которое утверждает, что порядок соединений можно изменить без влияния на результат.
• Алгоритм коммутативности соединения: Техника оптимизации порядка соединений в запросе. Он использует свойство коммутативности соединений, которое утверждает, что порядок операндов соединения можно изменить без влияния на результат.
  В целом StarRocks реализует (по последним данным) на 5 алгоритмов больше, чем Trino.

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

Поддержка локальных и глобальных фильтров во время выполнения
Осведомленность о перемешивании
Отправка максимума/минимума, в фильтр в хранилище
Оценка стоимости на основе
Поддержка кэша фильтров во время выполнения
Передача фильтра во время выполнения в обе стороны
SIMD-фильтр Блума
Адаптивный выбор фильтров во время выполнения соединения
Поддержка фильтрации во времени выполнения с несколькими столбцами

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

Высокая доступность

У StarRocks есть два типа узлов, каждый из которых способен достигнуть высокой доступности через конкретные стратегии. Узлы Front End являются безсостоятельными, и высокую доступность можно достичь, развернув нечетное количество узлов Front End. Эти узлы используют протокол Raft для выбора лидера среди себя. Узлы Back End поддерживают механизм с множественными репликами, обеспечивая, что отказ любого узла не влияет на работу системы. Таким образом, StarRocks может выполнять горячие обновления системы. Во время обновления системы онлайн-сервисы системы не будут затронуты.

Trino не имеет встроенной поддержки высокой доступности (HA). Координатор Trino – единственная точка отказа в системе. Если этот узел выходит из строя, вся система становится недоступной. Это означает, что при каждом обновлении системы онлайн-сервисы Trino должны быть приостановлены на определенное время. До сих пор проект Trino не предложил решения этой проблемы. Подробнее читайте по ссылке https://github.com/trinodb/trino/issues/391.

Источники данных и открытые форматы таблиц

Как сторонники концепции Data Mesh, сообщество Trino всегда стремилось к интеграции большего количества источников данных. До сих пор Trino разработал более 60 различных коннекторов, обеспечивающих подключение к различным источникам данных, включая реляционные базы данных, озера данных и другие. Это позволяет Trino выступать в качестве унифицированного движка запросов для предприятий, облегчая совместный анализ данных из различных источников. Это особенно полезно для крупных предприятий с несколькими бизнесами и разнообразными источниками данных. В настоящее время StarRocks более ориентирован на запросы открытых озер данных и имеет меньше коннекторов для других источников данных.

StarRocks поддерживает чтение как для Apache Iceberg, Apache Hudi, Apache Hive, так и для Delta Lake. Кроме того, StarRocks также поддерживает ограниченные возможности записи в Apache Iceberg. Результаты бенчмарк-тестирования показывают, что StarRocks работает быстрее в качестве движка запросов для озер данных. Trino поддерживает чтение и запись как для Apache Iceberg, Apache Hudi, Apache Hive, так и для Delta Lake. Согласно дорожной карте StarRocks, возможности записи в открытые озера данных будут улучшены в ближайшее время.

Возможности Data Lakehouse StarRocks

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

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

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

Бенчмарк

Команда StarRocks провела бенчмарк-тестирование на наборе данных TPC-DS объемом 1 ТБ. Они использовали StarRocks и Trino для запроса одной и той же копии данных, хранящихся в формате таблицы Apache Iceberg с файлами Parquet. Результат заключается в том, что общее время ответа на запрос в Trino медленнее в 5,54 раза по сравнению с StarRocks. Подробнее см. по ссылке https://www.starrocks.io/blog/benchmark-test

Вывод

Trino/Presto — это очень известный движок запросов с открытым исходным кодом. Когда у предприятий есть несколько источников данных и необходимо анализировать данные из этих источников единым образом, Trino является подходящим выбором. По сравнению с Trino, StarRocks — это новый движок запросов с открытым исходным кодом, обладающий множеством инновационных и уникальных решений. Используя StarRocks в качестве движка запросов для озер данных, клиенты могут легко достичь высокопроизводительного опыта запросов. Более того, клиенты могут использовать различные методы для дополнительного ускорения запросов, достигая более низкой задержки и более высокой конкурентоспособности. StarRocks также отличный выбор для запросов к озерам данных.

Перевод сделал ChatGPT

https://medium.com/@ashokgr/data-in-the-future-54e7ed1a6874

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

Фото Drew Beamer на Unsplash

Я вернулся после короткого перерыва. Кажется, отпуск (?) был полезным, и я избавился от большей части цинизма, который я нес в своей серии рассказов. Этот контент наполнен фактами с добавлением сарказма (не мой лучший, но вы можете винить в этом мой отпуск).
Введение
Вы когда-нибудь слышали о Гипотезе Гайи? Айзек Азимов предложил свою собственную версию, описывая планету Гайя в своей серии “Фонд”. Я считаю Азимова своим гуру в области современных вычислений. Почему? Потому что он писал о планете, где существует коллективное сознание и память, где последняя информация распределяется среди умов говорящих поселенцев, а более старая информация распределяется среди животных, деревьев/растений, даже воды и камней. Вы можете задать любой вопрос говорящему поселенцу, и он отправит вопрос соответствующим умам и соберет необходимую информацию для ответа. Звучит знакомо? Это Тиринг данных и распределенные вычисления!!! Написано еще в 1980-х годах!!! (Я прочитал эту серию в 2000-х годах.) Разве это не круто? Э? Э? Э? Если вам не кажется, вы можете заняться любовью самим к себе... подождите, Роберт Ладлум написал это в своем романе. В любом случае, вернемся к Азимову.
Примечание: Мне следовало бы прочитать серию “Фонд” снова перед тем, как написать этот контент... надеюсь, что я смогу вспомнить достаточно.
Будущее
Гари Селдон наблюдал за кампусом своего любимого университета Стрилинга через окно своего космического транспорта, на котором он собирался приземлиться. Он только что вернулся после посещения всех 19 поселенческих планет, которые были частью его любимого проекта за последние 30 лет. Он хотел, чтобы эти космические транспорты были быстрее, хотя он путешествовал всего лишь <1 миллисекунду на Warp 10. Такова была его нетерпеливость.
Паря по коридорам университета к своему офису, Гари злился на себя, размышляя, как могли быть такими неточными его расчеты Психоистории?
30 лет назад он выбрал несколько отдаленных планет для проведения своего эксперимента по управлению и процветанию. Его подход был очень прост:
Выбрать благородного министра для руководства делами планеты.
Создать Ресурсный обзорный комитет, который будет оценивать любую новую потребность и план, тщательно рассматривая каждое предложение по добыче и использованию ресурсов планеты.
Очень простые/четкие правила для управления деятельностью министра и комитета обзора.
Единственная цель – процветание граждан планеты путем использования ее ресурсов.
Во время своего последнего визита он заметил, что все вышло из-под контроля, и исполнение плана было в разрухе. Он хотел узнать, что пошло не так с его расчетами Психоистории, которые никогда не ошибались.
Ситуация
15 лет назад Гари посетил все 19 планет и предсказал, что на каждой из них будут свои доли дураков/тупиц и даже предателей. Но он никогда не ожидал, что на планетах будут непросы (должен ли я торговать этим?), то есть граждане с отрицательным прогрессивным взглядом, которые могут свергнуть целые планеты (не регрессивные люди, но прогрессивные во всех неправильных направлениях... О боже, только что я описал пробужденных?). Дураки, предатели и непросы были под влиянием коррумпированных поставщиков открытых технологий, которые продали им змеиное масло (данные – новое змеиное масло?). Это привело к следующему на каждой планете:
Неуправляемая добыча ресурсов планеты и их хранение в огромных океанах ресурсов.
Игнорирование Комитета обзора, а параллельно к нему начал работать тень-параллельный Ресурсный комитет, управляемый беспомощными людьми на основе надежд и ожиданий славы.
Планета тратила в 5–10 раз больше денег, чем требовалось для вероятной будущей готовности, которая так и не реализовалась.
И недавно те же технологические поставщики вернулись с новым змеиным маслом о том, как использовать добываемые ресурсы с новым подходом, который был просто стандартизацией/формализацией дерьмового подхода, уже принятого ранее.
В общем, высокие расходы с нулевой/минимальной ценностью.
Гари должен был докопаться до сути этого!!!

Анализ
Гари держал в руке Прайм Радиант, чтобы проверить, что пошло не так с его расчетами 30 лет назад. Черт побери! Анализ путешествия во времени был возможен только в течение 30 дней по умолчанию (максимум, который, в каком-то смысле, был бы дороже, чем мозги Гари). Гари подумал, давайте пересчитаем расчет, в конце концов, у его Прайм Радиант было 2²⁴ наносерверов с неограниченным объемом ОЗУ. Для этого анализа требовалось стакан 200-летнего виски с планеты Скатч, красивой страны с удивительными замками и акцентом.
Его повторный запуск был инициирован, и он начал размышлять о Райтоне (версия на Расте 1.999.999²⁴ + среда Python версии 1.99²⁴, написанная на Расте) — кто, черт возьми, заставляет разработчиков Райтона писать сложные операции с наборами данных с хэшированием/слиянием/вложенными соединениями? Что не так с этими людьми?

Пока он размышлял о том, стоило ли ему использовать Snowplow вместо этой ерунды, он почувствовал, как наносерверы в его мозгу уносятся вдаль. Черт возьми, опция автомасштабирования его среды Theta Lake + Park врывалась в наносерверы в его мозгу. Он хлебнул виски, чтобы убить несколько клеток мозга и остановить это автомасштабирование. Ему следовало лучше знать, чтобы сбросить конфигурации, и он с облегчением вздохнул, что не выбрал Snowplow, который автомасштабировался бы в 2 раза с каждым запросом до (2⁶⁵⁵³⁶ + 2) наносерверов и поглотил бы все его мозговые клетки за несколько секунд... Фью! Мог бы пропустить этот напиток Скатч, подумал он.

Результаты и завершение
Он был раздражен и решил использовать Психоисторию для расчета и предсказания того, когда будет выпущен новый/эффективный фреймворк обработки данных. В любом случае, он установил опции автомасштабирования на 1–2²⁴ (мин. и макс.), чтобы убедиться, что Прайм Радиант справится со всей нагрузкой. Он понял, что неоднозначные результаты потребуют его секретного запаса. Он пошел в свой шкаф, взял свое любимое виски и обнаружил результаты, которые были беспокойными:

Он использовал неверный алгоритм для корреляции наборов данных. Я – тот чертов Райтон-разработчик, заставленный создавать эти соединения наборов данных, он подумал, может быть, ему не следовало использовать установку Theta-Lake & Park для запуска своих алгоритмов психоистории, с его отвратительной производительностью вставки строки за строкой и новым определением ACID, он размышлял.

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

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

С правильными алгоритмами на месте, он закончил свой отчет с предсказанием (чертов 2023 год, он будет предсказательным только до тех пор, пока проект Сингулярности не станет реальностью), что Второй и Третий Фонды будут созданы для пошагового успеха, но гораздо лучше.

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

Заключение: Никакого. Если вы разобрались в том, что было описано, дай вам пять. Если нет, удачи. Я – энтузиаст по технологиям/данным (нагруженный термин) с опытом около 25 лет в области разработки приложений и архитектуры решений данных. Вы можете связаться со мной по адресу ashokgr@gmail.com в отношении моего контента, и, пожалуйста, учтите – я провожу несколько часов в неделю обсуждая данные с друзьями/связями и буду отвечать, когда это возможно.

Перевод выполнил чат гпт :)

https://medium.com/@jordan_volz/is-it-time-for-composable-data-systems-aaa72e0aa9bd

В 1970 году Эдгар Ф. Кодд опубликовал работу “Реляционная модель данных для крупных общих банков данных” во время работы исследователем в IBM. Эта влиятельная статья стала началом бурного развития систем обработки данных в течение десятилетий, что продолжается и по сей день. Среди тех, кто был вдохновлен этой статьей, были Майкл Стоунбрейкер и Ларри Эллисон, которые немедленно начали реализовывать реляционную модель в системах обработки данных, которые позже стали известными как Oracle и Ingres (позже Postgres — т.е. после Ingres). Фактически любая современная система обработки данных обязана значительной благодарностью работе Кодда.

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

Стонхендж, оригинал монолитов.

Переместимся на три десятилетия после статьи Кодда, и произошли существенные изменения в технологии и обществе. Мы онлайн, web 2.0 в полном разгаре, и данные повсюду. Системы стали крупнее, быстрее и мощнее. Системы управления реляционными базами данных (RDBMS) прошлого уступили место базам данных MPP, затем “большим данным” и распределенным системам. SQL как лингва франка данных уступил место Python и R. Монолитные системы обработки данных также уступили место... еще более монолитным системам обработки данных. Некоторое время мы пытались убедить себя, что “озера данных” — это нечто другое, но роза под другим именем...

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

За последние два десятилетия выделились два основных тренда в технологии, которые существенно повлияли на мир данных:

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

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

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

Пятьдесят лет назад это действительно было верным утверждением. Почти каждая компания только начинала работу с данными, поэтому каждая система данных была более или менее первой системой данных для этой компании, что означало, что это также была система, в которой “все данные”. Сегодня это не соответствует положению дел большинства компаний в их стратегии данных. Обычно у компаний есть несколько уровней устаревших систем, которые устарели, но не выведены из строя. Это могут быть старые продукты, старые приобретения, новые приобретения, операции теневого IT, целый набор заброшенных проектов по искусственному интеллекту и так далее. Данные распределены по множеству различных систем, нет недостатка в языках, написанных для работы с данными (SQL, Python, R, Scala, Java, Julia и т. д.), и все меньше и меньше людей, понимающих, как работают эти старые системы. То, что я все чаще встречаю на практике в современных командах по обработке данных, даже когда ваша система данных работает невероятно хорошо, результаты, которые вы получаете, часто неудовлетворительны, потому что в ней отсутствуют все данные, которые вам нужны на повседневной основе.

Ожидания также были более умеренными в прошлом, чем они сейчас. Пятьдесят лет назад сделать что-либо с данными было победой. Сегодня все намного сложнее, поскольку компании пытаются использовать большие языковые модели (LLM), чтобы создавать приложения с генеративным искусственным интеллектом ко-пилота во всех своих продуктах. Увеличившаяся сложность просто мутит воду и продолжает углублять разрыв между данными и пониманием бизнеса.

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

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

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

Удивительно, что миграция не решила всех наших проблем. (С любезного разрешения dilbert.com)

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

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

Для современной организации данных монолитные системы уже не подходят. Так в чем же альтернатива? Композиционные системы обработки данных, построенные на открытых стандартах обработки данных.
Обзор композиционных систем обработки данных
Систему обработки данных можно разбить на 3 основные части:
Хранилище данных: часть, которая хранит данные, доступные пользователям.
Движок данных: часть, которая выполняет операции с данными, как указано пользователями.
Пользовательский интерфейс: часть, с которой взаимодействуют пользователи для инициирования операций. Обычно предоставляется в виде языкового интерфейса или API.
В монолитных системах эти компоненты практически не разделены. Система была построена для использования определенным образом, и потребители системы должны смириться с выбором разработчиков. Используя систему, вы неявно фиксируете свой выбор для хранилища данных, движка данных и пользовательского интерфейса.

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

Представьте себе инженера данных, который пишет рабочий процесс Apache Spark на Java, который считывает данные из внутренней базы данных Oracle и выгружает данные в хранилище S3. Затем ученый по данным создает систему рекомендаций с использованием этих данных на Python и сохраняет результаты в транзакционной базе данных для использования в приложении, предназначенном для конечного пользователя. Для многих компаний сегодня такой рабочий процесс легко мог бы включать три или более систем обработки данных, и интеграция была бы довольно сложной, но в композиционной системе обработки данных это было бы совершенно нормально.

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

1. Модульность: Каждый компонент в системе данных легко может быть заменен другим компонентом того же типа (например, слой хранения).
2. Автономность: Компоненты должны быть разработаны так, чтобы не требовать использования других компонентов.
3. Стандартизированные API: Компоненты должны использовать стандартный набор API для облегчения передвижения данных по системе.
4. Расширяемость: Компоненты должны позволять пользователям легко расширять функциональность, не требуя переписывания всего компонента.

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

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

1. При создании движка, как мы вообще можем обрабатывать любой тип пользовательского интерфейса, который пользователи могли бы хотеть использовать? Кажется, что любой новый интерфейс/язык потребует значительной работы по разработке.
2. Точно так же, как мы можем обрабатывать любое произвольное хранилище данных?
3. После того как мы разрушаем систему обработки данных, как мы затем снова соединяем эти разрывы, чтобы предоставить пользователям приятный опыт? Это сложные вопросы, и я считаю, что именно этот пропасть удерживала нас в области монолитных систем обработки данных в последние пятьдесят лет.

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

Apache Arrow начался как встроенное столбцовое представление данных, но проект существенно вырос за годы, и с добавлением компонентов, таких как Arrow Flight, Flight SQL и ADBC. Теперь доступно множество инструментов для помощи системам в эффективном общении, и, таким образом, передача данных в формате Arrow никогда не была такой простой. Таким образом, Arrow может очень эффективно действовать как связующее звено между слоем хранения и двигателем в композиционной системе обработки данных при условии:

1. Слой хранения данных поддерживает создание и прием данных в формате Arrow.
2. Двигатель данных может принимать и обрабатывать данные Arrow.

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

Substrait — это кросс-языковая спецификация для операций обработки данных, или так называемое “промежуточное представление” (IR) для реляционной алгебры. Это означает, что вместо управления сетью соединений между интерфейсами и двигателями композиционная система обработки данных должна только указать:

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

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

Теория хороша только в том случае, если ее лучше всего применять, поэтому естественно возникает вопрос “Работает ли это на практике?” Неудивительно, что многие высокотехнологичные компании уже строят композиционные системы обработки данных на основе Apache Arrow и Substrait. Например, в недавней презентации Two Sigma обсуждается использование Arrow и Substrait, вместе с Acero, для создания системы стриминговой фичификации. Meta также недавно открыла код Velox, унифицированного двигателя выполнения, который работает с Substrait и Arrow и, очевидно, может использоваться для начала создания основ композиционной системы. Кроме того, новая база данных DuckDB, пользующаяся популярностью, совпадающим образом поддерживает как Substrait, так и Arrow.

Velox использует открытые стандарты для построения композиционного двигателя обработки данных.
Композиционная система обработки данных варится уже довольно долгое время и теперь, похоже, пришло идеальное время для ее появления. Большинство компаний уже накопили достаточный технический долг, чтобы количество данных необходимых решений, которые могут легко работать с различными слоями хранения. Рост принятия облака подчеркивает разделение вычислений и хранения, что является естественной точкой входа для композиционных систем. Кроме того, появление открытых стандартов, таких как Apache Arrow и Substrait, означает, что создание и использование композиционных систем стало намного проще, чем это было бы всего пять лет назад. Это значительное изменение в архитектуре данных, которое принесет радикальные выгоды для потребителей.

Преимущества композиционных систем обработки данных:

1. Гибкость:
   • Композиционные системы предоставляют пользователям максимальную гибкость. Общие жалобы от конечных пользователей монолитных систем включают: a) Отсутствие поддержки предпочитаемого ими языка работы (например, SQL-системы, которые не имеют интеграции с API для dataframe, или системы на основе API для dataframe, не обладающие хорошей поддержкой SQL, R против Python и т.д.) и b) Реалистичные сценарии использования требуют данных, заточенных под более чем одну систему. В композиционных системах пользователи получат свободу работать на выбранном ими языке и легко подключаться к разным источникам данных. Это повышает производительность команд обработки данных, поскольку они могут придерживаться знакомого интерфейса для всех своих работ и не сталкиваются с барьерами между системами данных.

2. Производительность:
   • Не секрет, что многие системы данных затянуты техническим долгом, который сложно и дорого устранить. С течением времени системы данных теряют свою “современность” и, вероятно, будут превзойдены более новыми системами по производительности. Это явление мы видели много раз за последние пятьдесят лет, и нет причин считать, что оно прекратится в ближайшее время. Для компаний, которые заинтересованы в получении передовой производительности от своих систем данных, это означает, что они постоянно оценивают новые системы и переносят рабочие нагрузки на новые системы, предлагающие лучшую производительность. Многие также сталкиваются с дополнительной сложностью или ухудшением пользовательского опыта только потому, что производительность для них настолько важна. Системы передового уровня, оптимизированные под производительность, часто не сосредотачиваются на обеспечении отличного пользовательского опыта. Результатом является множество своевременных и дорогостоящих миграций данных, переписывание рабочих процессов и общее напряжение в команде обработки данных, так как им трудно следовать современным тенденциям. Принятие композиционной платформы обработки данных позволило бы этим организациям минимизировать нарушения в потоках данных, сохраняя при этом использование передовых технологий. Предположим, что выходит новый слой хранения, обещающий значительное улучшение времени доступа и ускорение нескольких рабочих процессов. Команда данных может начать использовать его, не переписывая рабочих процессов или изменяя двигатель, просто переместив некоторые данные и попробовав его. Или, если появляется новый двигатель, обещающий значительный прирост производительности для ключевых рабочих процессов, его легко можно заменить, не изменяя кода рабочего процесса или перемещая данные. Фактически, композиционные системы обработки данных упрощают оптимизацию собственных рабочих процессов вокруг производительности и всегда позволяют использовать последние достижения в проектировании систем обработки данных.

3. Управление затратами:
   • Вместе с повышенной гибкостью и увеличением производительности композиционные системы обработки данных предоставляют потребителям гораздо больший контроль над затратами на систему. Монолиты, по определению, представляют собой комплексные предложения, и потребители, вероятно, платят за функции, которые они не используют, и/или застревают при использовании дорогостоящих и сложных проприетарных компонентов, которые позднее трудно мигрировать. Композиционные системы предоставляют модульные компоненты, что позволяет организациям данных более детально соответствовать дизайн системы своим потребностям. Для компаний, которые хотят получить максимальную производительность, они могут решиться на роскошный двигатель с поддержкой поставщика и использовать хранилища данных с открытым исходным кодом и интерфейсы пользователя. Это также позволяет компаниям более легко использовать преимущества достижений в области аппаратного ускорения, которые распространяются в последние несколько лет и которые должны значительно снизить общую стоимость владения (TCO) их систем данных

.

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

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

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

Чтобы узнать больше:

Voltron Data предоставляет отличный обзор композиционных систем, который стоит прочитать всем, кто интересуется этой темой и хочет начать что-то новое с своими данными.

Перевод с GPT 3.5