Был в прошлом году, было отлично! В этом году будет еще больше гостей!

15-16 Мая 2024 м. Павелецкая.

Билеты тут: The Trends 2.0

The Trends 2.0

Локация: ->>

Присоединяйся!

Массово запустили минты и рынок заполнился, флор доходит до 3 тон за 10 млн. Но купить по такой цене практически нереально. Видимо боты работают.

Brickspacer ...

https://getgems.io/collection/EQDia1dY5G5_J4LDaqW9xPyLw2T3s25y6U1W1nSkQ3BRzM7x/EQCgHRAZM3EsPlNy9UbvATjbOhur9A4S_TAnNSi_XtOfPS2a

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

Видеохолсты художника не только доступны для покупки на рынке криптоарта, но и демонстрируются на видных выставках в мировых культурных столицах, таких как Токио, Дубай, Пекин, Берлин, Лондон и Нью-Йорк.

Хочу тартугу))

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

I Contain Multitudes: https://rarible.com/ICMultitudes-OE/items

Гейб Вайс – художник смешанных медиа и NFT, живущий в районе залива. Художник-самоучка вдохновлен уличным искусством и философией стоицизма и использует подход потока сознания в своей работе, чтобы исследовать восприятие реальности.

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

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

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

https://gabeweis.com/

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

Или 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
Интересные участники. И конечно Вини тоже там:

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