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