[Перевод] Инженерия данных: паттерны проектирования
Приветствуем вас, Хабр. В течение минувшего года мы серьёзно прорабатывали тему инженерии данных (Data Engineering), поскольку остались очень довольны читательским интересом к вышедшей у нас книге "
https://habr.com/ru/companies/bhv_publishing/articles/1003452/
#книги #паттерны_проектирования #data_engineering #apache_spark #apache_kafka #publishsubscribe
Как мы строили хранилище на 70 ПБ данных и не планируем останавливаться
Привет, сегодня я расскажу о том, как наша команда строила платформу обработки и хранения данных для обучения GenAI-моделей в Сбере, и как мы выросли до 70 ПБ сырых данных. Меня зовут Александр, я работаю в Сбере и два года занимался развитием этой платформы.
Добавляем MapReduce в этот наш SQL: генераторы на основе курсоров
Вот уже который год я потихоньку разрабатываю SQL-ный движок на основе Apache Spark, специализированный под задачи ETL. И хотя диалект языка изначально называется «Transform Definition Language», писать трансформации данных непосредственно на нём самом было до сих пор невозможно. Вместо этого на фазе Transform предполагалось использовать подключаемые модули, которые рантайм интерпретатора предоставляет из Java classpath. Это очень эффективный с точки зрения производительности, но довольно долгий с точки зрения внедрения, и дорогой в разработке способ. Сначала трансформацию надо описать формально в виде статьи-whitepaper'а (это делает data scientist), потом написать прототип на Python (ответственность data analyst), отладиться на сэмпле реальных данных (тоже аналитик), и тогда уже делать и оптимизировать финальную имплементацию на Java с использованием низкоуровневого API Spark (собственно, задача разработчика). Неудобно. Нельзя ли его как-нибудь сократить? Например, дать аналитикам инструмент для написания трансформаций непосредственно в самом SQL, вынеся некоторую часть функциональности MapReduce как разновидность итерирующих функций? Можно, конечно! Давайте узнаем, как именно
https://habr.com/ru/articles/958362/
#sql #etl #apache_spark #java #hadoop #big_data #big_data_solutions #big_data_tools #интерпретатор
Продвинутый анализ на PySpark: учимся работать с рекуррентными соотношениями
Обработка и анализ временных последовательностей (временных рядов) достаточно часто встречающаяся задача. Обычно она решается с помощью идентичных подходов и методов. Однако когда анализ временного ряда предполагает выражение каждого последующего элемента через предыдущие, возникают проблемы с эффективностью реализации такого анализа. Это особенно актуально в контексте больших данных. В данной статье я продемонстрирую подход к анализу и вычислению рекуррентных соотношений. В качестве примера будет представлена реализация на базе Apache Spark и Python метода экспоненциальной скользящей средней с использованием DataFrame API. Мы рассмотрим метод агрегации данных, совместимый со Spark Connect, который был добавлен в версию 3.1 (для Scala - начиная с версии фреймворка 3.0), а именно – функцию aggregate.
https://habr.com/ru/companies/axenix/articles/952278/
#apache_spark #pyspark #python #рекуррентные_соотношения #временные_ряды #анализ_данных #spark_connect
RocksDB-стейт в стриминге: как ловить потерянные события и дубликаты
В стриминговых пайплайнах всё чаще приходится иметь дело не только с бесконечным потоком данных, но и с состоянием, которое нужно хранить и восстанавливать без потерь. С выходом Spark 3.2 у разработчиков появилась возможность подключать RocksDB в качестве state store — и это открывает новые горизонты для работы с большими объёмами данных. В статье разбираем, как использовать этот подход на практике: от борьбы с дубликатами и пропущенными событиями до тонкостей конфигурации и устойчивости стриминга.
https://habr.com/ru/companies/otus/articles/941412/
#apache_spark #стриминговая_обработка #дубликаты_событий #потерянные_события #Kafka #обработка_данных_в_реальном_времени
[Перевод] Оптимизация поисковых систем: баланс между скоростью, релевантностью и масштабируемостью
Будучи разработчиками, мы постоянно стремимся создавать системы, которые не просто работают, но и отличаются эффективностью и масштабируемостью. В мире, где пользователи ожидают всё более быстрые и точные результаты, оптимизация производительности поиска становится ключевым приоритетом в современной разработке приложений. Эта статья основана на нашем выступлении на конференции QCon San Francisco 2024, где мы рассмотрели эволюцию подходов к индексированию данных, их извлечению и ранжированию. Для платформ вроде Uber Eats, обрабатывающих сложные запросы на больших объёмах данных, оптимизация поиска — это серьёзный вызов, требующий продвинутых стратегий: индексирования, шардинга и параллельной обработки запросов. Сложность поисковых систем продолжает расти, и необходимость соблюдения баланса между скоростью, релевантностью и масштабируемостью становится как никогда актуальной. В этой статье мы рассматриваем ключевые техники таких оптимизаций и их влияние на пользовательский опыт и производительность системы.
https://habr.com/ru/companies/otus/articles/934186/
#шардинг #Индексирование #поиск #Масштабируемость #производительность #apache_kafka #apache_spark #big_data #ранжирование
Пишем движок SQL на Spark. Часть 8: CREATE FUNCTION
В предыдущих сериях ( 1 • 2 • 3 • 4 • 5 • 6 • 7 • Ы ) рассмотрели, как написать на Java собственный интерпретатор объектно-ориентированного диалекта SQL, заточенный на задачи подготовки и трансформации наборов данных, и работающий как тонкая прослойка поверх Spark RDD API. Штука получилась довольно продвинутая, с поддержкой императивщины типа циклов/ветвлений/переменных, и даже с поддержкой пользовательских процедур. И в плане этой самой императивщины расширяемая: может импортировать функции из Java classpath, равно как и операторы выражений. То есть, если необходимо, можно написать функцию на Java, или определить новый оператор, и использовать потом в любом выражении на SQL. Круто? Ещё как круто. Но как-то однобоко. Если в языке у нас поддерживаются функции, то почему бы не дать нашим пользователям определять их самостоятельно? Вот прямо через CREATE FUNCTION ? Тем более, что вся необходимая для этого инфраструктура уже вовсю присутствует. Да и процедуры на уровне интерпретатора у нас уже поддерживаются ведь… Функция для затравки.
https://habr.com/ru/articles/915964/
#etl #apache_spark #java #hadoop_stack #big_data #big_data_tools #big_data_solutions #sql #никто_не_прочитает_эту_статью #написанную_для_отчётности_по_гранту
バックアップからリストアしたDynamoDB テーブルに格納されているデータをAWS Glueを用いて元のテーブルに複製する
https://dev.classmethod.jp/articles/transfer-dynamodb-data-from-restored-table-using-aws-glue/
#dev_classmethod #AWS_Glue #Amazon_DynamoDB #Apache_Spark #AWS
【AWS Glue】Glueジョブでdynamic_frameをソースに利用したらキャストエラーで困った話
https://dev.classmethod.jp/articles/aws-glue-glue-dynamic-frame-cast-error/
#dev_classmethod #AWS_Glue #Apache_Spark #PySpark #Apache_Iceberg
Иногда приходится¹ копаться² в кишках³ Apache Spark
¹ …просто потому, что другого варианта добиться необходимого результата тупо не существует. ² и да, довольно-таки глубоко. ³ нет, серьёзно! Давайте рассмотрим следующий бизнесовый кейс. Дано: реально большие данные. Очень много датасетов по много терабайтов каждый, — в сумме объём тянет на петабайты. Лежат в облаке, но это не важно. Важно, что мы эти данные покупаем в «сыром» виде, каким-то образом «готовим», а потом перепродаём конечному потребителю. Требуется: при подготовке каждого из датасетов разделить его согласно значениям одного или нескольких полей, составляющих его записи, на несколько. И это одна из особенно часто встречающихся в нашем процессе операций. Довольно-таки сложный, продвинутый ETL у нас. Поясню на типичном примере.
https://habr.com/ru/articles/913244/
#кейс #etl #apache_spark #java #pipeline_automation #hadoop_stack #big_data #big_data_tools #big_data_solutions #sql #никто_не_прочитает_эту_статью #написанную_для_отчётности_по_гранту
Habr
DevelopersIO
