Руководство по 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.
Уровень сложности данной серии статей — высокий. Базовые понятия по ходу текста вообще не объясняются, да и продвинутые далеко не все. Поэтому, если вы не разработчик, уже знакомый с терминологией из области бигдаты и жаргоном из дата инжиниринга, данные статьи будут сложно читаться, и ещё хуже пониматься. Я предупредил.
Привет, Хабр, меня зовут Дима. В последние пару лет занимаюсь аналитикой, отвечаю за данные в Почте Mail.ru. Развиваю аналитическое хранилище данных и инструменты для работы с ними. Мы плотно работаем со стеком Hadoop, Hive, Spark, Clickhouse и Kafka. Я хочу остановиться на некоторых аспектах работы с данными в Spark: как мы храним петабайты информации и как выполняем запросы к ним?
Прежде всего поделюсь своими практическими наблюдениями. Расскажу как в нашем хранилище мы превратили 7 петабайт в 0,5 петабайт, что позволило сэкономить годовой бюджет по закупке серверов. И также расскажу о ключевых проблемах с данными, знание о которых помогло бы вам построить своё классное хранилище без последующей переделки.
Всем привет! Меня зовут Антон и я руковожу Big Data платформой в Детском Мире.
На Хабре проходит сезон Больший данных, и я решил что это отличная возможность поделиться нашим опытом внедрения Dbt (инструмент для оркестрации Sql витрины). На хабре уже статьи по инструменту, в моей статье, покажу как пришли от запуска ноутбука в Zeppelin к промышленному решению запуска большого количества витрин написанных на SparkSql в OnPrem Hadoop.
Всем привет! Я выпускник данной Академии и победитель в конкурсе проектов. Я получил уникальный опыт, который будет полезен начинающим специалистам
Этот обзор подойдет в первую очередь тем, кто еще учится в вузе или школе, а также тем у кого есть дети данного возраста - Интенсивы рассчитаны на молодых людей до 19 лет.
Предвкушаю вопросы, поэтому я сразу говорю - обзор не реклама. Не путайте Практикум и Академию, академия - некоммерческая организация, а интенсивы - бесплатные курсы, которые (внезапно) просто дают знания.
Минусы и результаты собеседований после курсов - перед началом секции "проект" - эти 3 модуля покажут реальный уровень выпускников академии. Все что будет дальше является сугубо личным мнением. Приступим!
Пример задачи.
Хотим автоматизировать огромный фруктовый рынок. На каждое событие будем писать строчку в структурированный лог. Этот лог не является частью runtime функционирования рынка, но может быть полезен для изучения статистики и аналитики.
Например, на основании лога продавец может сделать вывод, что свежие яблоки выгоднее привозить к 13:00.
