Инфраструктура для изучения основ машинного обучения на локальном компьютере с помощью Apache Spark

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

https://habr.com/ru/articles/1034338/

#apache_spark #machine_learning #machinelearning #postgresql #sql

Код как документация: как мы строим самодокументируемые витрины данных в Почте Mail

В аналитике больших данных есть старая проблема: код ETL-витрин живет своей жизнью, а документация — своей. Изменяешь логику, забываешь обновить описание колонки — и через месяц никто не помнит, что означает wallet_cards_category_hits. В Почте Mail (VK) мы решили эту проблему системно, разработав внутренний фреймворк, который делает код витрины и ее документацию неразрывными. На связи Дима Швеенков. Я все так же руковожу направлением аналитики в команде и отвечаю за данные в Почте Mail , а теперь еще и отвечаю за DWH в VK Tech . В предыдущих статьях я подробно рассказывал о нашем Data Driven-подходе к работе с данными, а также, в частности, как мы работаем со Spark и какие ключевые проблемы с данными мы решили, чтобы построить свое хранилище данных. Сегодня хотел бы остановиться на более узкой теме — как держать в порядке документацию, если у вас такое же огромное хранилище, как и у нас. Материал короткий, но, надеюсь, будет для вас полезным.

https://habr.com/ru/companies/vktech/articles/1032686/

#big_data #apache_spark #airflow #clickhouse #sql #документация #dwh #metadata #dbt #vk_tech

[Перевод] Инженерия данных: паттерны проектирования

Приветствуем вас, Хабр. В течение минувшего года мы серьёзно прорабатывали тему инженерии данных (Data Engineering), поскольку остались очень довольны читательским интересом к вышедшей у нас книге "

https://habr.com/ru/companies/bhv_publishing/articles/1003452/

#книги #паттерны_проектирования #data_engineering #apache_spark #apache_kafka #publishsubscribe

Как мы строили хранилище на 70 ПБ данных и не планируем останавливаться

Привет, сегодня я расскажу о том, как наша команда строила платформу обработки и хранения данных для обучения GenAI-моделей в Сбере, и как мы выросли до 70 ПБ сырых данных. Меня зовут Александр, я работаю в Сбере и два года занимался развитием этой платформы.

https://habr.com/ru/companies/sberbank/articles/972078/

#Apache_Spark #apache_iceberg #parquet #s3 #big_data

Добавляем 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