#Kafka #Kafkaдляразработчиков #статьи
🍩Поговорим про события в брокере Kafka.
Событие в Kafka — это факт, описывающий изменение состояния объекта (например, заполнение топика сообщениями или разбиение топика на разделы). Kafka узнает о новом событии благодаря механизму регистрации событий. Регистрация событий — это считывание текущего состояния объекта и сравнение этого состояния с более ранним.
В случае, если текущее состояние объекта отличается от предыдущего, брокер Kafka автоматически регистрирует новое событие, а также создает поток событий, в который помещаются все события зарегистрированные в данный момент времени.
Поток событий (event stream) представляет собой коллекцию (множество) событий, которые происходят одновременно в данный момент времени.
Читайте далее про особенности работы в примерах.
@BigDataSchool_ru
https://kafka-school.ru/blogs/kafka-events/

#BigData #DataLake #статьи
🧳Зачем нужно внешнее хранилище метаданных Apache Hive?
Apache Hive используется для доступа к данным, хранящимся в распределенной файловой системе Hadoop (HDFS) через стандартные SQL-запросы.
Это NoSQL-хранилище обеспечивает управление распределенными данными и метаданными благодаря службе Hive Metastore, которая предоставляет интерфейс через экономичный протокол для чтения, записи и обновления метаданных для таких сред, как Apache Spark, Presto и пр. HDFS, в свою очередь, часто используется в качестве основы для Data Lake, откуда BI-приложения и аналитические системы забирают нужную информацию.

Хранилища метаданных играют очень важную роль в работе Data Lake. По умолчанию Hive записывает информацию хранилища метаданных в базу данных MySQL в файловой системе главного узла. Хранилище содержит описание таблицы и базовых данных, на основе которых она построена, включая имена разделов, типы данных и т.д. Когда кластер завершает работу, все его узлы отключаются, включая главный узел. При этом локальные данные теряются, поскольку файловые системы узла используют эфемерное хранилище. Если нужно сохранить хранилище, следует использовать внешнее хранилище за пределами кластера Apache Hive.
Например, из сервисов Amazon это могут быть каталог данных Glue, RDS или Aurora.

Также можно запустить высокодоступную и масштабируемую службу Hive Metastore на AWS EKS, что соответствует безсерверной архитектуре обработки данных: не нужно поддерживать физический кластер для вычислений. (Запуск только службы Hive Metastore на кластере AWS EMR будет стоить дорого, поскольку придется платить за сервис EMR и EC2 главного узла, но это не масштабируется, поскольку работает на одном EC2.)

Для простого масштабируемого и высокодоступного способа размещения службы Hive Metastore можно использовать кластер EKS, упаковав хранилище метаданных Hive в контейнер и запускать их в масштабируемых подах Kubernetes.

Как это сделать, рассмотрим далее.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/hive-metastore-service-on-aws-eks.html

#BigData #Kafka #статьи
🧑🏻‍💻Lighthouse для мониторинга.
Еще один полезный для дата-инженера и администратора инструмент - легковесная система с открытым исходным кодом, предоставляет наглядный графический интерфейс с потоковой передачей данных в реальном времени, чтобы отслеживать потоки продюсеров и потребителей.
Также Lighthouse обеспечивает оперативное представление основных показателей производительности для визуализации работоспособности кластера Kafka.
Lighthouse создан с использованием Next.js, GraphQL, Apollo и Prometheus, с планами рефакторинга в Typescript.
Инструмент использует рендеринг на стороне сервера во время сборки, что позволяет почти мгновенно доставлять пользователю значения отслеживаемых метрик, чтобы проводить диагностику системы и делать прогнозы для любого варианта использования.
Lighthouse использует предопределенный набор параметров GraphQL для запросов к серверу Prometheus, позволяя напрямую отображать данные о кластере Kafka в GUI.
После загрузки Lighthouse следует заменить конечную точку Prometheus своей собственной в файле .env, чтобы подключиться к своему кластеру и метрикам, доступным во время выполнения.

Далее читайте: Чем плохи медленные потребители для Apache Kafka, как их обнаружить и ускорить.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/slow-consumers-in-kafka-and-default-configurations.html

#Kafka #DataScience #статьи
🌊Для чего нужны потоки в Kafka и как они работают.
Потоки в Kafka — это неизменяемые коллекции данных, которые предназначены для добавления данных в топики Kafka.
Kafka-потоки также являются потоками фактов, где каждый факт представляет собой уникальное и неизменяемое событие (event). Данные потоков хранятся в виде структуры ключ-значение (key-value).
Создавать Kafka-потоки можно двумя способами:

1. с помощью библиотеки Kafka Streams
2. с помощью платформы KSQL

Каждый из этих способов мы подробно рассмотрим далее на практических примерах.
@BigDataSchool_ru
https://kafka-school.ru/blogs/kafka-streams-building/

#BigData #DWH #статьи
🌐Мю-архитектура и Data Mesh.
На смену конвейерной модели пришла сетка данных (Data Mesh), которая предполагает совместную работу в распределенной топологии вместо создания очередного конвейера.
Этот подход фактически упрощает обработку, т.к. не требуется точной подстройки временных окон между собой. Также снижается потребность в высоких вычислительных мощностях из-за снижения объема обрабатываемых данных.
Кроме того, результаты становятся более точными, т.к. расхождения, вызванные временными задержками, сведены к минимуму.

В итоге Data Mesh становится основой для новой архитектуры данных, называемой μ (Мю).
Мю-модель — это рекурсивно повторяющийся шаблон микропроцессоров данных, состоящий из триплетов соединения μ-продуктов: источника, процессора и приемника данных.
Фактически, Data Mesh становится способом перейти от ETL-конвейеров к µ-архитектуре через лямбда и каппа-модели.

Идея μ-продукта приводит к инициативам по устранению технологической неоднородности отдельных технологий, чтобы построить базовую сетку данных. Сегодня для этого отлично подходят платформы потоковой передачи событий, такие как Apache Kafka.
Таким образом, архитектура Мю позволяет создавать продукты данных как представление топологии.

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

Читайте далее, что не так с конвейерной моделью обработки данных и почему архитектура Data Mesh с потоковой передачей событий не решают всех проблем пакетной парадигмы.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/what-is-mu-model-of-data-architecture.html

#AirFlow #ETL #статьи
🟢Краткий обзор Apache AirFlow 2.4

Apache Airflow 2.4 содержит более 45 новых функций, 40 улучшений, 50 исправления ошибок и изменения в документации.

Ключевыми изменениями являются следующие:
✔️новая функция, которая позволяет разработчикам DAG создавать более мелкие, автономные группы цепочки, которые объединяются в крупный рабочий процесс. Эти наборы данных представляют собой абстрактную концепцию и пока не имеют возможности прямого чтения или записи, но они ускоряют планирование ETL-конвейеров, работая быстрее ExternalTaskSensor и TriggerDagRunOperator.
✔️упрощение управления конфликтующими зависимостями Python с помощью нового ExternalPythonOperator. Его декоратор @task.externalpython позволяет запускать функцию Python как задачу AirFlow в предварительно настроенной виртуальной среде или даже в совершенно другой версии Python.
✔️динамическое сопоставление задач теперь включает поддержку expandkwargs, чтобы назначить несколько параметров оператору, отличному от TaskFlow и преобразовать параметры непосредственно перед запуском задачи. Также добавлена поддержка дополнительных типов ввода для использования с функцией динамического сопоставления задач.
✔️Новый триггер CronTriggerTimetable делает синтаксис планирования AirFlow более похожим на cron, привычный большинству дата-инженеров.
✔️Наконец, сделаны значительные улучшения пользовательского интерфейса, включая возможность детализировать файлы журналов из представления сетки.

Еще Apache AirFlow 2.4 включает следующие добавления:
✔️декораторы @task.shortcircuit и @task.kubernetes
✔️команда удаления ролей в CLI и поддержка TaskGroup в ExternalTaskSensor
✔️экспериментальный parsingcontext, чтобы включить оптимизацию динамической обработки DAG в рабочих процессах
✔️отображение неконфиденциальных значений конфигурации во вкладке администрирования (Admin -> Configuration)
✔️имя оператора отдельно от класса, т.е. больше нет PythonDecoratedOperator при использовании TaskFlow.

Далее рассмотрим некоторые из этих новинок более подробно.

@BigDataSchool_ru
https://www.bigdataschool.ru/blog/airflow-2-4-release-overview.html

#BigData #ETL #статьи
🎢Как происходит балансировка нагрузки в кластере Apache NiFi.

В версии NiFi 1.8.0 балансировка нагрузки была добавлена ​​между каждым процессором в любом соединении, а также реализован способ настроить автоматическую балансировку нагрузки между узлами.
Также в Apache NiFi есть функция, позволяющая выводить из эксплуатации и отключать узлы от кластера, а также выгружать все их данные. Это особенно важно для Kubernetes и динамического масштабирования для обеспечения эластичности.
Эластичное масштабирование нужно для рабочих нагрузок, которые меняются в течение дня или года.
Чтобы соответствовать соглашениям об уровне обслуживания и срокам, можно увеличивать масштаб в пиковые периоды и уменьшайте его для экономии расходов.
Эта функция балансировки нагрузки демонстрирует возможности распределения большого набора данных или захвата неструктурированных данных в другом центре обработки данных, разделения и передачи, а затем использования привязки атрибутов к узлу для восстановления данных в определенном порядке.

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

Также большим файлом может быть какой-либо архив, например, zip-файл, содержащий множество файлов разных типов, которые надо направить к одному и тому же узлу NiFi на основе корневого имени файла или типов вложенных файлов.

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

✔️без балансировки нагрузки — это значение по умолчанию
✔️циклический режим (Round Robin) – потоковые файлы будут распределяться по кластеру в циклическом режиме. Если узел отключен от кластера или не может связаться с узлом, данные, поставленные в очередь для этого узла, будут автоматически перераспределены на другие узлы.
✔️один узел, когда все потоковые файлы будут распределены на один узел в кластере. Если же этот узел отключен от кластера или с ним невозможно связаться, данные, поставленные в очередь для этого узла, останутся в очереди до тех пор, пока узел снова не станет доступным. Все соединения, для которых настроена эта стратегия, будут отправлять данные на один и тот же узел.

Далее подробно рассмотрим стратегии балансировки и распределания данных.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/nifi-load-balancing.html

#AirFlow #DataScience #VertexAI #статьи
💡Что такое Vertex AI Pipelines от Google.
Google Vertex AI — это новый набор инструментов для поддержки сквозного жизненного цикла ML-решений и MLOps-задач.
Он состоит из множества инструментов, включая Workbench, Feature Store, бессерверный конвейер Kubeflow, задания, эксперименты и отслеживание метаданных, реестр ML-моделей, конечные точки для развертывания их в онлайн, пакетные прогнозы и много других полезных функций.
Vertex AI интегрируется со многими открытыми ML-фреймворками, такими как TensorFlow, PyTorch и scikit-learn, а также поддерживает все среды машинного обучения через настраиваемые контейнеры для обучения и прогнозирования.

Ключевыми достоинствами Vertex AI с точки зрения MLOps являются следующие:
✔️бессерверные решения сокращают затраты на инфраструктуру и развертывание. Стоимость использования стартует от 0,03$ за запуск конвейера и цена ресурсов Google Cloud.
✔️оптимизация функций и вариантов использования специально для машинного обучения
✔️поддержка кэширования.

Перечень недостатков Vertex AI Pipelines более широкий:
✔️отсутствие планировщика требует использовать сторонние инструменты, такие как Cloud Scheduler и Cloud Function, Jenkins, AirFlow или что-то еще
✔️нет поддержки микроконвейеров, а разрабатывать большие сквозные конвейеры может быть очень сложно, долго и дорого
✔️нет поддержки взаимозависимых и динамических DAG
✔️отсутствие CLI, что затрудняет протестировать конкретную задачу или конвейер
✔️невозможность запустить конвейеры локально
✔️недостаточные контроль и наблюдаемость по сравнению с AirFlow на Kubernetes
✔️привязка к инфраструктуре Google может вызвать дополнительные сложности и проблемы с настройкой сети, VPN и брандмауэра. В большинстве случаев компоненты конвейера должны взаимодействовать с пользовательской инфраструктурой, например, считывать данные из базы данных или взаимодействовать с конечными точками. Однако, бессерверная модель Vertex AI не позволит работать со статическими IP-адресами в шорт-листе и т. д.
✔️Наконец, фреймворк пока еще имеет мало реальных внедрений, а потому его небольшое сообщество еще не накопило список лучших практик, операторов и кейсов. Вместе с «сырой» документацией это сильно повышает порог входа в технологию, что противоречит идее MLOps, которая стремится устранить разрывы между ML-разработкой и программной инженерией.

Таким образом, новый продукт от Google AI пока нельзя назвать успешным инструментом современной дата-инженерии для решения MLOps-задач, в отличие от Apache AirFlow, который мы рассмотрим далее.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/airflow-vs-vertex-ai-pipelines-in-mlops.html

#BigData #DataLake #статьи
🩻Чтение данных из AWS S3 с Apache Spark и boto3

Data Lake часто организуется на базе облачного объектного хранилища AWS S3. Чтобы использовать эти данные в задачах прогнозирования с помощью ML-моделей или анализировать их, необходимо сперва считать эту информацию. Это можно сделать с помощью заданий PySpark и учетных записей в IAM (Identity and Access Management) – службе Amazon, которая позволяет получить доступ к другим сервисам AWS.
IAM дает возможность указать, кто или что может получить доступ к сервисам и ресурсам AWS, централизованно управлять мелкими разрешениями и анализировать доступ для уточнения разрешений.

Роли IAM позволяют предоставить права доступа пользователям или сервисам, у которых обычно нет доступа к корпоративным AWS-ресурсам. Пользователям IAM или сервисам AWS можно присвоить роли для получения временных данных для доступа к данным и вызовов API. Это исключает необходимость предоставления долгосрочных данных для доступа или назначения разрешений для каждого объекта, которому требуется доступ к определенному ресурсу.

Разрешения предоставляют доступ к ресурсам AWS и предоставляются объектам IAM (пользователям, группам и ролям), которые не могут выполнять никаких действий на платформе AWS без необходимых разрешений. Чтобы предоставить объектам разрешения, можно назначить правило, определяющее тип доступа, допустимые действия и ресурсы для их выполнения. Также можно указать любые условия, которые должны выполняться для разрешения или запрещения доступа.

Чтобы считать данные из AWS S3 средствами Apache Spark, далее напишем небольшой PySpark-скрипт в интерактивной веб-среде Google Colab или Jupyter Notebook.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/reading-data-from-s3-with-spark-and-boto3-with-masking-and-aes.html

#BigData #Kafka #статьи
🎰Apache Kafka 3.3.2: главные новинки и изменения.

Минорный выпуск 3.3.2 носит технический характер: в нем всего 3 улучшения и чуть более 20 исправленных ошибок.

Рассмотрим 3 улучшения выпуска 3.3.2.
1️⃣Получение ответа об ошибке при обращении к публичному провайдеру аутентификации OAuth/OIDC. Класс org.apache.kafka.common.security.oauthbearer.secured.HttpAccessTokenRetriever используется для отправки учетных данных клиента публичному провайдеру OAuth/OIDC и получения ответа, включая токен доступа.
2️⃣Улучшением стало ограничение времени ожидания heartbeat-сигнала брокера KRaft не более значения конфигурации broker.session.timeout.ms.
3️⃣Наконец, согласованы порты для чтения системных метрик. Ранее, при наличии брэндмауэра или работы внутри контейнера, раскрытие только com.sun.management.jmxremote.port не позволяло получить метрики, а без указания порта RMI он генерировался случайным образом по умолчанию. В Apache Kafka 3.3.2 оба порта стали согласованными для чтения указанных метрик.

Из исправленных ошибок наиболее важными можно назвать следующие:
✔️обновление тайм-аута перебалансировки при повторном присоединении статического потребителя в группе
✔️задержка отключения, управляемого брокером KRaft, на неопределенный срок
✔️бесконечный цикл psend без ключа записи и batch.size=0
✔️невозможность удалить топики, в названии которых есть точка (.)
✔️проблемы с выбором реплики для чтения при обновлении метаданных при перебалансировке
✔️некорректный кодировщик Base64 в OAuthBearerLoginCallbackHandler при OIDC-аутентификации
✔️обработка неудачной выборки при не назначенных разделах.

Далее посмотрим, как перейти на новый релиз.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/kafka-3-3-2-release-overview.html

#AirFlow #ETL #статьи
✳️7 полезных практик работы с Apache AirFlow для дата-инженера

Эти рекомендации помогут дата-инженеру более эффективно эксплуатировать Apache AirFlow при проектировании конвейеров обработки данных:
✅использование словаря defaultargs позволяет указать аргументы по умолчанию для DAG, включая дату начала и частоту запуска, чтобы избежать жесткого кодирования этих значений и упростить их изменение в будущем
✅шаблонизация DAG может сделать их разработку более гибкой, позволяя избежать повторного написания одинакового кода
✅встроенные операторы AirFlow отлично подходят для выполнения общих задач, таких как выполнение SQL-запроса или передача данных между системами. Это позволяет избежать написания пользовательского кода и сделать DAG более удобными в сопровождении
✅функции ветвления и запуска AirFlow упрощают создание сложных рабочих процессов, позволяя создавать DAG с несколькими ветвями и зависимостями без усложнения управления этим конвейером
✅встроенная интеграция AirFlow с Git помогает отслеживать изменения в DAG и реализует совместную работу дата-инженеров в разных командах
✅встроенные функции ведения журналов и мониторинга AirFlow пригодятся, чтобы отслеживать DAG, устранять возникающие проблемы с конвейером обработки данных и быстро их исправлять.
Отдельно стоит сказать про некоторые операторы AirFlow, которые также пригодятся дата-инженеру.
Это рассмотрим далее.

@BigDataSchool_ru
https://www.bigdataschool.ru/blog/best-practices-for-dag-design-and-airflow-operators.html

#DataScience #NoSQL #SQL #статьи
5 популярных языков запросов к графам.
❇️GraphQL очень гибкий и экономичный с точки зрения сетевой передачи. Он поддерживается многими языками программирования (JavaScript, Java, Python, Ruby и PHP), позволяет настраивать структуру передаваемых и принимаемых данных, а также включать поля из нескольких ресурсов в один запрос. Однако, он не очень прост в реализации, имеет статичную схему данных, не поддерживает кэширование на клиенте и загрузку файлов. GraphQL работает только с JSON-форматом. Этот язык запросов подходит для приложений с большим количеством клиентов и/или источников данных, когда нужно унифицировать выполнение запросов, снизить число конечных точек и нагрузку на сеть.
❇️Gremlin — это язык обхода графов Apache TinkerPop, принятый во многих графовых базах данных. В свою очередь, Apache TinkerPop — это среда вычислений на основе графов для транзакционных и аналитических графовых СУБД. Gremlin — это функциональный язык потока данных, который позволяет пользователям лаконично выражать сложные обходы (или запросы) графа свойств своего приложения. Разработчики могут писать запросы Gremlin на любом языке программирования, который поддерживает композицию функций и вложенность функций, например, Python, Java, Javascript, Scala и Groovy, чтобы выполнить императивные (процедурные) и декларативные (описательные) обходы в графе. Однако, это достаточно низкоуровневый язык обхода графа, который не очень легко читать.
❇️Cypher — это язык запросов популярной графовой базы данных Neo4j, который немного похож на SQL. Однако, он основан на шаблонах и предоставляет визуальный способ сопоставления отношений и шаблонов. Cypher позволяет использовать средства отображения графов объектов (OGM) для сопоставления отношений и узлов в графах со ссылками и объектами в модели предметной области. OGM, встроенный в Neo4j, использует операторы запроса Cypher вместе с драйвером Java и сопоставляет существующие объекты домена с объектами этой графовой СУБД (узлами и ребрами графа). Neo4j-OGM поддерживает быстрое сканирование метаданных класса и оптимизированное управление загрузкой данных.
❇️SPARQL (SPARQL Protocol and RDF Query Language) — это язык запросов, который позволяет пользователям запрашивать информацию из баз данных, которые могут быть сопоставлены с RDF (Resource Description Framework). SPARQL немного похож на стандартный SQL, но данные в запросе SPARQL внутренне выражаются в виде троек из субъекта, предиката и объекта. SPARQL может объединять запросы из разных репозиториев, обращаясь как RDF, так и к реляционным СУБД, а также интегрировать данные в пересекающихся доменах. Однако, SPARQL нелегко читать и понимать.
❇️AQL (ArangoDB Query Language) — это язык запросов для извлечения и изменения данных, хранящихся в ArangoDB — мультимодельной БД, поддерживающей графовую и документную модели, а также ключ-значение. AQL поддерживает различные функции, такие как ANALYZER(), BOOST(), EXISTS() и пр., позволяющие выполнять сложные вычисления. Он помогает разработчикам разрабатывать надежные приложения и напрямую отображать данные в базу данных. Это достаточно гибкий язык, который упрощает масштабирование и адаптацию архитектуры ИС к изменениям.

Более подробно: что общего у GraphQL, Gremlin, Cypher, SPARQL и AOL, а также чем они отличаются.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/graph-languages-overview.html

#BigData #Greenplum #PostgreSQL #статьи
🧑🏻‍💻Управление разделами в Greenplum и PostgreSQL

Основными дополнениями в Greenplum 7 являются следующие новые DDL-команды для разделов, как в PostgreSQL:
☑️CREATE TABLE PARTITION OF — для создания новой таблицы и добавления ее в качестве нового дочернего раздела
☑️ALTER TABLE ATTACH PARTITION – для добавления существующей таблицы в качестве нового дочернего раздела
☑️ALTER TABLE DETACH PARTITION – для удаления таблицы из иерархии партиционирования без удаления самой таблицы.

Далее разберем другие изменения в Greenplum 7
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/greenplum-7-new-ddl-for-partitions.html

#DataScience #DevOps #ML #статьи
🪤Скрытый технический долг в ML-системах.

Технический долг - дополнительные затраты, возникающие в долгосрочной перспективе, с которыми сталкивается команда, в результате выбора простых и быстрых вариантов вместо принятия решений, более правильных в долгосрочной перспективе.
Для систем Machine Learning технический долг существует на системном уровне, а не на уровне кода. Поэтому традиционного подхода к техническому долгу, как и в разработке ПО, недостаточно для его устранения: нужны подходы, специфичные для ML.
Технический долг растет при использовании данных не по назначению, что в классической разработке ПО решается ограничением видимости. В Machine Learning также помогает предоставление доступа к данным и моделям только определенным пользователям и командам, а также тщательное управление этими разрешениями.

Далее читайте подробно про техдолг в проектах Machine Learning.
@BigDataSchool_ru
https://www.bigdataschool.ru/blog/mlops-to-eliminate-technical-debt-in-ml-projects.html