Hadoop *

Trino — высокопроизводительный распределённый SQL-движок, с возможностью объединения данных из разнородных источников, таких как: реляционные БД, файловые хранилища, шины данных, inmemory-хранилища, облачные сервисы и тд. Архитектура ориентирована на выполнение аналитических запросов с минимальной задержкой. Т.е. с его помощью можно отправлять SQL-запросы в MongoDB и Kafka, например. Благодаря скорости, развитию, и удобству захватывает популярность у инженеров и аналитиков, работающих с bigdata.

Я познакомился с Trino 1 год назад, за это время настроил с нуля кластер на baremetal и помог с проблемами в нескольких других. В этой статье делюсь краткой выжимкой опыта эксплуатации, накопленным за это время. Большая часть информации будет актуальна и для российского форка Trino: CedrusData.

Успешные тестирование производительности и нагрузочные испытания – важнейшие условия для выбора аналитической системы массивной обработки больших данных. В этой публикации я хочу поделиться подходами к тестированию, которые используются нашей командой как в проектной работе, так и при разработке Lakehouse-платформы данных Data Ocean Nova, и познакомить вас с результатами сравнения различных движков и систем. Вы узнаете, как правильно ставить цели, выбирать методику и из каких сценариев ее нужно составлять, как протоколировать результаты и делать выводы. И самое главное – получите ответ на вопросы: кто быстрее: заяц Trino или антилопа Impala?

Привет. Меня зовут Евгений Вилков. Я занимаюсь системами управления и интеграции данных с 2002 г., а конкретно системами анализа и обработки данных — с 2007 г. Технологии, с которыми я имел дело на протяжении моего профессионального пути, стремительно развивались. Начиная с решений, основанных на стеке традиционных СУБД, таких как Oracle, MS SQL Server, Postgres, постепенно эволюционируя в ставшие уже классическими (а некоторые даже и закрытыми) MPP-системы, такие как Teradata, GreenPlum, Netezza, Vertica, IQ, HANA, Exadata, ClickHouse, в различные решения на базе экосистемы Hadoop, облачные сервисы и платформы. Меняется мир, меняются технологии, меняются подходы к проектированию, меняются и требования к задачам аналитического ландшафта данных.

Уверен, что многие, кто уже знаком с терминами Data Mesh и Data Lakehouse, задаются вопросом: что может предложить рынок аналитических систем в этих методологиях проектирования и архитектурных подходах. Я хочу рассказать об аналитической платформе данных Data Ocean Nova, владельцем и технологическим идеологом которой я являюсь.

Привет, Хабр! Мы продолжаем серию статей о проведённой миграции аналитического хранилища данных с платформы Teradata на GreenPlum. В предыдущей статье мы рассказали о нашем опыте и результатах автоматизированного переписывания SQL-скриптов из диалекта Teradata в диалект GreenPlum с помощью реализованного сервиса миграции кода. В этой статье мы расскажем вам о полученном нами опыте и результатах переноса архива данных объёмом более 400 Тб из Teradata в GreenPlum, а также о трудностях и решениях, связанных с этим процессом.

Руководство по Apache Spark не для начинающих.

В прошлой статье я писал о возможностях и функциях Apache Spark для обработки данных. Мы сосредоточились на ключевых функциях чтения, обработки и сохранения данных, не забывая о примерах кода, которые помогут новичкам быстро включиться в работу.

В этой статье мы пойдём глубже и рассмотрим оптимизацию. Сосредоточимся на базовых концепциях, оптимизации запросов и соединениях. Конечно же, с примерами.

Всем привет! Я Ваня Ахлестин, занимаюсь поддержкой и развитием аналитической платформы кластера Search&Recommendations на базе Spark и Hadoop в Авито. Сегодня расскажу, как начать использовать ваш код из Python или PySpark и не тратить много времени дорогих разработчиков.

В предыдущей своей статье Почему стоит начать писать собственные Spark Native Functions? (Часть 1), которая является переводом и которая вдохновила меня на собственные изыскания, был разобран пример, как написать свою Spark Native Function по генерации UID. Это, конечно, здорово, но вот только данная функция не принимает аргументы на вход, в то время как в реальной практике нам требуются обычно функции, которым надо передать на вход 1, 2 или 3 аргумента. Такие случаи не рассматриваются в упомянутой выше переводной статье - ну что ж, попробуем восполнить этот пробел!

Ниже я предлагаю вашему вниманию результаты своих изысканий по созданию собственных Spark Native Functions, которые бы принимали на вход несколько аргументов.

Представим некое перепутье, где с одной стороны — мощные возможности PostgreSQL, а с другой — необъятные просторы Hadoop. Выбор кажется сложным, но зачем выбирать одно, если можно соединить их и получить лучшее из обоих?

Объединяя их можно создать мощную систему, способную обрабатывать и анализировать огромные объемы данных.

Airflow в Lamoda Tech играет роль оркестратора процессов обработки данных. Ежедневно с его помощью мы запускаем 1 800+ тасок на проде, примерно половина из которых являются Spark-приложениями.

Все Spark-приложения сабмитятся из Docker-контейнеров. И здесь сталкиваемся с проблемой: в нашем случае не существует готовых решений для запуска Spark-приложений, позволяющих легко править конфигурацию и следить за количеством потребляемых ресурсов.

Меня зовут Андрей Булгаков, я лид команды разработчиков Big Data в Lamoda Tech. Вместе с разработчиком Иваном Васенковым в этой статье мы поделимся историей создания Airflow-оператора для запуска Spark-приложений.

Это мой вольный перевод статьи "Why You Should Start Writing Spark Custom Native Functions", которая вдохновила меня на некоторые собстенные изыскания по данной теме. Их результат я планирую опубликовать позже, а пока выношу на ваш суд этот перевод.

Статья на примере реализации функции по генератации UUID рассматривает, как писать Spark native функции, которые были бы "прозрачны" для Catalyst (в отличии от UDF, которые являются "черными ящиками" для него). Сравнение производительности ожидаемо показывает, что Catalyst Expressions значительно превосходят UDF при увеличении размера данных.

Кому интересно узнать, как писать Spark native функции - прошу под кат.

Примеры кода на Python для работы с Apache Spark для «самых маленьких» (и немного «картинок»).

Данная статья представляет собой обзор основных функций Apache Spark и рассматривает способы их применения в реальных задачах обработки данных. Apache Spark — это мощная и гибкая система для обработки больших объёмов данных, предлагающая широкий спектр возможностей для аналитики и машинного обучения. В нашем обзоре мы сфокусируемся на ключевых функциях чтения, обработки и сохранения данных, демонстрируя примеры кода, которые помогут новичкам быстро включиться в работу и начать использовать эти возможности в своих проектах.

Для запуска и эксплуатации высоконагруженных ИТ-решений с петабайтами данных в активе, нужно проработанное решение, позволяющее гибко управлять ресурсами. Одним из критичных аспектов этого решения, является разделение Compute & Storage — разделение ресурсов инфраструктуры под вычисление и хранение соответственно. Если не реализовать такое разделение в крупном проекте, инфраструктура рискует превратиться в «чемодан без ручки» — эффективность использования ресурсов будет низкой, а сложность управления ресурсами и средами будет высока. На примере команды SberData и их корпоративной аналитической платформы я расскажу, когда требуется разделение Compute & Storage и как это реализовать максимально нативно.

Статья подготовлена по мотивам доклада на VK Data Meetup «Как разделить Compute & Storage в Hadoop и не утонуть в лавине миграций».

Как не грабить память, не пытать диск, не мучать кластер. Или делать все это всего одним запросом на Impala к Hadoop.

Среди задач аналитиков данных, в рамках которых необходимо иметь дело с большими объемами однотипных данных, выделяются задачи построения витрин данных, автоматизации процессов сбора и обработки данных. Многие аналитики используют различные реляционные базы данных, в таблицах которых хранятся огромные объемы информации, агрегация и доступ к которым может занимать долгое время, поэтому правильное составление и оптимизация запросов к этим таблицам становится критически необходимым фактором для работы аналитиков, инженеров данных и data scientist.

Привет, Habr !

Я работаю инженером по машинному обучению в Мегафоне. Занимаюсь аналитикой данных и являюсь частью команды разработки MLOps платформы. Задача нашей команды состоит в том, чтобы выстраивать и оптимизировать процессы разработки и продуктивизации моделей машинного обучения, предоставлять функционал для основных этапов (сбор данных, MQ/DQ, продуктивизация).

Сегодня поговорим о том, какие сложности могут возникать при работе с кластером Hadoop и какие есть методы для их решения.

Видеозапись по мотивам статьи можно посмотреть здесь.

Эта статья будет интересна аналитикам и инженерам, которые работают с BigData и регулярно сталкиваются с необходимостью продуктивизировать модели на Hadoop.

Как и было обещано, в завершение серии ( 1 • 2 • 3 • 4 • 5 ) статей о разработке инструмента для ETL больших данных, я выкладываю выжимку ответов на вопросы.

А то статьи были в формате туториала для разработчиков таких инструментов (длинные и с высоким уровнем сложности), так что стоит рассказать более кратко и понятно для каждого.

Q. Что это такое?

A. Специализированный инструмент для а) быстрого создания ETL процессов и б) эффективного по стоимости их выполнения.

Промка: https://dcetl.ru
Исходники: https://github.com/PastorGL/datacooker-etl
Официальная группа в телеге: https://t.me/data_cooker_etl

В данной серии статей я подробно рассказываю о том, как написать на Java собственный интерпретатор объектно-ориентированного диалекта SQL с использованием Spark RDD API, заточенный на задачи подготовки и трансформации наборов данных.

Краткое содержание предыдущей серии, посвящённой API расширения и разного рода технической обвязке:

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

Теперь можно поговорить о последних штрихах, делающих инструмент — инструментом, а именно, об интерактивно-отладочном режиме, то есть, REPL, клиенте и сервере, а также о генераторе документации.

В данной серии статей я подробно рассказываю о том, как написать на Java собственный интерпретатор объектно-ориентированного диалекта SQL с использованием Spark RDD API, заточенный на задачи подготовки и трансформации наборов данных.

Краткое содержание предыдущей серии, посвящённой имплементации спеки языка в коде:
Заметка об использовании prior art
Наборы данных в контексте исполнения
Переменные, настройки контекста исполнения, и метаданные параметров подключаемых функций
Интерпретатор, контекст исполнения, операторы выражений

Разобравшись со всеми контекстами и устройством ядра интерпретатора, можно перейти к описанию API точек расширения, режимов запуска, и технической обвязки сборки исполняемых артефактов.

В данной серии статей я подробно рассказываю о том, как написать на Java собственный интерпретатор объектно-ориентированного диалекта SQL с использованием Spark RDD API, заточенный на задачи подготовки и трансформации наборов данных.

Краткое содержание предыдущей серии, последней, посвящённой проектированию спецификации языка:
Операторы жизненного цикла наборов данных (продолжение)
Операторы контроля потока выполнения
Операторы управления контекстом исполнения
Операторы выражений

В данном эпизоде мы наконец-то перейдём к самому интересному — имплементации. Хорошо, когда есть развёрнутая постановка задачи, можно просто брать спеку, и писать код согласно плану.

В данной серии статей я подробно расскажу о том, как написать на Java собственный интерпретатор объектно-ориентированного диалекта SQL с использованием Spark RDD API, заточенный на задачи подготовки и трансформации наборов данных.

Краткое содержание предыдущей серии:
Вступление
Постановка задачи
Проектирование языка. Операторы жизненного цикла наборов данных
Проектирование системы типов

В данной серии статей я подробно расскажу о том, как написать на Java собственный интерпретатор объектно-ориентированного диалекта SQL с использованием Spark RDD API, заточенный на задачи подготовки и трансформации наборов данных.

— Евдокимов, ты что, совсем уже там кукухой поехал?! При живом-то Spark SQL! Опять ты ненормальным программированием маешься, нет бы что-то полезное делал…
— Ну-ну-ну, спокойно, спокойно. Я ещё настолько не уехал, чтобы потратить целый год на страдание полной ерундой. Речь на сей раз пойдёт не о развлекухе, а о диалекте языка, специализированном для решения целого класса задач, для которых любой существующий SQL был бы, в теории, хорошим решением, если бы не несколько серьёзных «но».

Короче, у нас будет немного не такой SQL, который вы все так хорошо знаете, но и этот вариант вы полюбите, я обещаю. Тут лучше другой вопрос задать:
— Разве кому-то нужен голый SQL-ный движок?

Нет, голый — не нужен. Так рассказывать я буду о разработке настоящего production ready инструмента, с интерактивным шеллом с подсветкой синтаксиса и автодополнением, который сможет работать в клиент-серверном режиме, и не только на кластере, но и локально. Да не монолитный, а расширяемый при помощи подключаемых функций. И с автогенератором документации впридачу. Короче, всё будет совсем по-взрослому, с рейтингом M for Mature.