Какие технологии Big Data стоит изучать в 2025 году?

Новый год уже наступил, какие же технологии изучать, чтобы оставаться востребованным специалистом и модным-молодежным? Давайте же разберемся!

Основная тройка для Big Data остается также неизменной:
⚡️ Apache Spark
Spark остается одним из главных инструментов для распределенной обработки данных. Конечно, появляются и другие фреймворки для похожих задач, но Spark уже проверен временем, поддерживается и регулярно дорабатывается такими крупными компаниями, как Databricks и Snowflake, так что в ближайшее время он никуда не уйдет.
🐘 Hadoop
Хотя я и слышал мнение, что Hadoop "умирает", он продолжает использоваться практически во всех крупных компаниях в различных сборках, и ему трудно предложить замену благодаря его надежности и стабильности, в обозримой перспективе вряд ли его что-то заменит.
💠Apache Airflow
Airflow является основным инструментом для оркестрации процессов, отслеживания их выполнения, он активно развивается, и в него активно добавляются новые фичи, так что он скорее всего так и останется самым популярным решением благодаря своей простоте, нативности и удобству.
А теперь перейдем к технологиям поновее. Начнем с двух СУБД, которые на данный момент чаще всего встречаются на российском рынке: Greenplum и Clickhouse.
🔎 ClickHouse
Стал популярным благодаря открытости кода и скорости своей работы. Он активно развивается нашими друзьями из Яндекса, сообщество очень живое и сам Clickhouse активно внедряется и используется во многих компаниях.
🍃 Greenplum
Также стал популярным благодаря открытости кода, но в этот раз был подхвачен ребятами из Arenadata и Т-Банка. Greenplum является распределенной СУБД, которая может хранить и обрабатывать огромные объемы данных, работает стабильно, и сейчас кластер Greenplum стоит в любом банке.
🌐 Trino
Довольно новый инструмент, который начали внедрять компании, решившие сделать у себя Data Lakehouse. Trino позволяет обрабатывать данные из различных источников, включая S3, HDFS и базы данных, не перенося их в единое хранилище, и делает это очень быстро.
💾 S3 и объектные хранилища
Хотя Amazon и ушел из России, S3 и облачные решения остаются стандартом для хранения больших объемов данных благодаря своей надежности, низкой стоимости и интеграции с инструментами Big Data, и сейчас S3 предоставляют такие компании, как Яндекс, ВК, Cбер. В сочетании с такими технологиями, как Trino, S3 становится одним из решений для замены Hadoop.
Кроме того, облачные решения часто используют небольшие компании, поскольку это является более дешевым и оптимизированным решением, чем покупать себе сервера и ставить все самим.

Это лишь часть всего того, что может использовать Data Engineer, и я буду продолжать рассказывать вам об этом зоопарке в следующих постах, а пока ставьте огонечки и делитесь вашим мнением в комментариях😎

@bigdata_postupashki

Задача с секции Аналитики Яндекс
Дана таблица с сообщениями пользователей messages, где колонками являются:
message_id — айдишник сообщения
sender_id — айдишник отправителя
receiver_id — айдишник получается
reply_message_id — айдишник того сообщения, для которого данное является ответом (может быть null, если это первое сообщение)
Нужно найти наибольшую длину треда (последовательноти сообщений, которые отвечают последовательно друг на друга) для каждого пользователя.
Пример:
message_id, sender_id, receiver_id, reply_message_id
7 3 4 null
17 4 3 7
В этом случае для пользователей 3 и 4 максимальной длиной треда будет 2, т.к. в треде всего 2 сообщения (7 -> 17)
Решение:
Подобные задачи на поиск глубины чего-либо лучше решать с помощью рекурсивной cte. В ней отбираем в начале первое сообщение (reply_message_id = NULL) и после этого производим JOIN c самой собой по ключам message_id и reply_message _id (т.к. все NULL случаи мы отобрали, то переджоинятся только сообщения, которые являются ответами друг на друга). В результате получим таблицу с последовательной длиной тредов для каждой пары sender_id, receiver_id и останется только объединить повторяющиеся пары и сгруппировать, чтобы отобрать максимальную длину треда.
Код решения с собеседования в комментариях.


А еще больше задач сможете увидеть и научиться решать на курсе по инженерии данных. Всех ждем и всем рады, товарищи 😎 А еще поставьте огоньки, если интересно еще больше таких задач с собеседований

@bigdata_postupashki

SQL на стажировку в Т-банк

Дедлайн 30 января. Ответы на тест по SQL, условие, а ответы ниже:

1. LEFT, RIGHT, FULL (1,2,4)
2. SELECT(1), FROM(2),WHERE(3),GROUP BY(4), HAVING(5), ORDER BY(6)
3. 2
4. 5
5. 2
6. 3
7. 3
8. 3
9.
3 — SELECT emp_id FROM staffinfo WHERE emp_nm = “Petrov” AND end_dt is null
7 — SELECT emp_id FROM staffinfo WHERE emp_nm = “Petrov” INTERSECT SELECT emp_id FROM staffinfo WHERE end_dt is null
10. 4

А разбор задач уже на нашем курсе дата инженер.

@bigdata_postupashki

⚡️ Почему тебе нужно изучать Spark?! 😎

Когда речь заходит о Apache Spark, у многих до сих пор ощущение, что это что-то исключительно для дата-инженеров, но это далеко не так! Spark — это инструмент, который аналитики и дата-саентисты могут легко использовать в своей работе, чтобы ворочать сотни гигабайт данных, абсолютно разных форматов и структур. И это я не говорю уже про возможности подключения к обычным бд, а также встроенных библиотек для машинного обучения! Но сегодня я вам расскажу про то, как обрабатывать и ворочать уже терабайты данных в Spark, а также не расстраивать дата-инженеров вашей платформы:

Полезные статьи:
Apache Spark… Это база – как понятно из названия, это самая база для понимания с примерами взаимодействия
Big Data: Анализ данных с помощью Apache Spark – практическое руководство по Spark SQL, включая агрегатные функции и работу с DataFrame.
Как отслеживать и анализировать задания Spark — руководство по тому, как работать со Spark UI, анализировать выполнение вашего запроса и прочие очень полезные штуки.
Как работает Join в Apache Spark SQL — база по развенчанию магии внутренней работы Spark c Join
A Comprehensive Guide to Optimizing Spark Queries – хорошая статья для того, чтобы понять, какие могут быть проблемы при обработке больших данных и как их избегать.
Практика использования Spark SQL – очень полезная статья из практики, в которой рассказаны стратегии ускорения аналитических запросов и избегания ошибок.
Руководство по Apache Spark не для начинающих — продвинутым методы оптимизации производительности Spark, включая управление схемой данных, кэширование, управление партициями и выбор эффективных операций.

Если хотите больше материалов о технологиях для работы с большими данными, ставьте огоньки 🔥
Также про это все и больше будет на нашем курсе по дата инженерии

@bigdata_postupashki

Курс по аналитике стартует уже в это воскресение (еще можно записаться)! Как материал для подготовки записаны вот такие вводные уроки, где разбираем всю необходимую теорию на конкретных примерах, задачах из тех же самых собесов и рабочих кейсов. Такие вводные уроки дополняют и расширяют материал каждого занятия в 2 раза. Ведь Поступашки реально хотят научить ребят, дать им качественное образование, а не просто взять деньги и послать куда подальше!!

💠 Почему тебе нужно изучать Apache Airflow?
Apache Airflow давно стал стандартом в мире Big Data и MLOps. Его используют дата-инженеры, ML-инженеры, аналитики и дата-сайентисты как для построения ETL-пайплайнов, так и для сборки отчетов, и обучения моделей машинного обучения, и мониторинга за этими процессами.
Поэтому каждому будет полезно узнать про него, и для этого решил подготовить пост с подборкой материалов для безболезненного знакомства 😎

Что же классного в Airflow?
Простота — написан на Python, легко интегрируется с другими инструментами
Наглядность — удобный UI для мониторинга и отладки DAG'ов.
Гибкость — поддержка множества плагинов, которых написали огромное количество для всех ситуаций, и возможность легко сделать свой, если не нашел подходящий

Статьи:
Все, что нужно знать об Airflow (Часть 1, Часть 2, Часть 3) – Целая серия статей, посвященная Airflow, и затрагивающая практически все темы: введение в архитектуру, ключевые компоненты и концепции, создание и настройка DAGs, операторы, сенсоры и много всего еще, довольно исчерпывающий гайд.
Лучшие практики дата-инженера по работе с Airflow – Как писать DAG’и правильно, оптимизировать их исполнение и избегать типичных ошибок.
Как и любую технологию, Airflow хорошо бы самому пощупать, поэтому следующие две статьи как раз про это: Быстрый старт с Apache Airflow – Настройка и запуск Airflow с нуля с примерами кода.
Написание первого DAG – Подробное руководство по созданию DAG
Что такое Airflow Executor и Executors in Apache-Airflow — хорошие статьи для тех, кто хочет чуть побольше узнать о том, как работает Airflow внутри
Также факультативно рекомендую разобраться с такой интересной темой, как написание своих операторов, для этого могу порекомендовать сразу несколько статей: раз, два, три, четыре

Курсец
Курсов по этой технологии не так много, еще меньше бесплатных, поэтому могу порекомендовать один хороший Apache Airflow 2.2, где подробно разбираются ключевые концепции Airflow, принципы работы DAGs, взаимодействие с API, сенсоры и т.д. на довольно свежей версии.

А если хотите еще больше материалов, то ставьте огоньки и реакции под этим постом!
Также про Airflow, и не только про него, будет рассказываться на нашем курсе по дата инженерии

@bigdata_postupashki

Мой путь вката в Биг Дату

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

На третьем курсе ВМК я начал задумываться о том, чтобы начать уже получать реальные практические навыки, потому что одним обучением в вузе я вряд ли смогу этим добиться. Я пробовался на различные стажировки: всем известные Тинькофф, Яндекс, Сбер и менее известные компании на самые хайповые направления: аналитика, дата саенс и в целом все, что связано с данными, потому что это мне нравилось и чувствовал, что это мое.
И в один момент прошел на стажировку Spark-разработчика, иначе говоря — Дата Инженера, в одной консалтинговой компании, где вначале шло обучение, а после, в случае успешной сдачи экзамена и дополнительных собеседований — прием в штат.
Конечно же поначалу всё казалось сложным: распределённые вычисления, кластеры, партиции, обучение Scala, Hadoop, Spark с нуля. Но, пройдя все эти этапы, успешно справился со всем, и после этого начал работать на проекте ВТБ, где набрался опыта реальной разработки ETL, занимался сборкой витрин и работой с продуктовыми большими данными.
С тех пор дата-инженерия и биг дата стали моими родными сферами. После этого уже я спокойно переходил на работу непосредственно в банки — тот же ВТБ и Сбер, и ритейлы — Ozon и текущее место работы

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

Если у вас остались вопросы задавайте их в комментариях и ставьте реакции!
Ну а если хочешь получить помощь в подготовке к собеседованиям и обучению, то рекомендую записываться на наши консультации!

@bigdata_postupashki

ETL vs ELT

Друзья, после небольшого перерывчика начинаем новую серию постов, в которых мы будем рассматривать всякие теоретические аспекты, которые помогут вам как просто лучше разобраться, так и круто отвечать на собесах 😎
Сегодня у нас на разборе самая база в Больших данных, шесть крутых букв — ETL и ELT. Куда бы вы не попали, везде работа с данными и хранилища будут устроены в одной из этих парадигм. Ну давайте же разбираться!

ETL
Происходит от трех слов(Extract, Transform, Load) – это классический подход к обработке данных, когда данные извлекаются из источников (из различных БД, CRM систем и прочих 1С-ов), затем обрабатываются на промежуточном уровне (Informatica, Debezium, SAP DS) и только после этого загружаются в основное хранилище данных, например, Greenplum, Clickhouse или Postgres.
Такой подход удобен для сценариев, где важны контроль качества данных, строгие схемы и подготовленные агрегированные данные.
Звучит круто, но очевидно, у данного метода есть недостатки, и они довольно очевидны: возникает узкое место в трансформации данных, т.к. приходится сразу чистить от дубликатов, приводить к одной схеме и т.д. И кроме этого эта промежуточная зона должна успевать обрабатывать огромное количество данных!
Поэтому возник другой подход к выстраиванию процессов.

ELT
Как можно понять — это перестановка предыдущих слов: Extract, Load, Transform.
ELT более гибкий метод, при котором сырые данные сначала загружаются в хранилище, а потом уже обрабатываются внутри него и загружаются в целевое хранилище. Такой подход характерен для облачных решений и аналитических платформ, например, в Yandex Cloud/Snowflake/Amazon S3, а также наш любимый Hadoop, где данные можно загружать без предварительной очистки, преобразовывать их внутри, а после этого загружать в тот же Greenplum, Clickhouse(но бывает и без загрузки, мы позже поговорим про подход Data Lakehouse). Плюсы тут понятны: данные у нас всегда доступны, особенно при отслеживании истории(этому помогает SCD, или же Slow Changing Dimensions, тоже очень интересная тема, которую мы рассмотрим в дальнейшем), их можно переиспользовать в будущем без дополнительной нагрузки на источники.

На собеседованиях часто спрашивают, какой подход чаще используется и тут можно смело отвечать, что это ELT: в большинстве компаний используются классическую схему с загрузкой данных в Data Lake, а после этого загрузкой в Data Warehouse.
Также могут спросить минусы у ELT подхода и их два основных: нужно держать целых два хранилища, одно из которых может начать бесконтрольно расти и хранить в себе кучу бесполезных данных, если должным образом не подходить к их хранению.
Из инструментов для ELT чаще всего используют связку Airflow + Spark, Flink и похожие фреймворки для оркестрации и загрузки

Пишите ваши вопросы в комменты, а если хотите продолжения постов про архитектуру построения хранилищ, ставьте реакции и записывайтесь на наши курсы по дата инженерии
Есть еще куча тем, которые мы рассмотрим 😎

@bigdata_postupashki

Интересная задачка с собеседования
Вы работаете со Spark, делаете преобразования над таблицами, но задача валится по OutOfMemory, как решить эту проблему без увеличения общего количества памяти?
Решение
1. Отрегулировать количество партиций
Делается это несколькими способами:
- spark.sql.shuffle.partitions: <количество партиций>
За что отвечает данный параметр: перед запуском shuffle операции Spark все данные распределит в количество партиций, равное числу в этом параметр(по дефолту оно 200). Поэтому, если данных у вас ну уж очень много, то партиции могут стать очень жирными и не влезать в память => надо их количество увеличить
- repartition(<количество партиций>)
Происходит тоже самое, но нужно это делать вручную перед shuffle(например, перед join-ом)
2. Использование Broadcast Join
Broadcast Join работает по очень просто принципу: перемещает меньший датасет(его размер можно установить до 8 Gb) к партициям большого и соединяте, что позволяет избежать shuffle операции.
Но если один из датасетов > 8 гигов, лучше его отключить с помощью параметра
spark.sql.autoBroadcastJoinThreshold: -1
3. Уменьшение количества executor
Допустим, у нас 10 экзекьюторов по 8 гигов и 5 ядер каждый, и при выполнении на них спарк задачи происходит OOM, тогда, можно сделать вместо 10 — 5, но выделить на каждый не по 8 гигов памяти, а 16, и 10 ядер. Общая параллельность не изменится, но партиции начнут влезать в память.
А как бы вы решали данную задачку пишите в комменты 😎
Чтобы узнать больше о работе Spark подписывайтесь на канал, ставьте реакции, а также записывайтесь на наши курсы

@bigdata_postupashki

Ребятаа, там открылся донабор на стажировку в Т-банк, поэтому выкладываем сюда разбор SQL задач 😎
Обратите внимание также на то, что формулировки задач могут несильно отличаться, например, могут попросить не имя товара, а айдишник и подобное, поэтому будьте внимательны!
Решения
Задача 1:

SELECT t1.name 
 FROM (
    SELECT b.buyer_id, b.name, SUM(o.quantity * pr.price) as total_sum
    from buyers b
    JOIN orders o on b.buyer_id = o.buyer_id
    JOIN products pr on o.product_id = pr.product_id
    GROUP by b.buyer_id, b.name
    ORDER BY total_sum DESC
    LIMIT 1
  )t1

Задача 2:

SELECT p.product_name 
FROM products p 
LEFT JOIN orders o ON p.product_id = o.product_id AND o.order_date BETWEEN '2023-01-01' AND '2023-12-31'
WHERE o.product_id IS NULL;

Задача 3:

SELECT SUM(o.quantity * p.price) AS total_sum 
FROM orders o 
JOIN buyers b ON o.buyer_id = b.buyer_id 
JOIN products p ON o.product_id = p.product_id 
WHERE b.city = 'Москва' AND o.order_date BETWEEN '2024-01-01' AND '2024-12-31';

@bigdata_postupashki

Задача с собеседования.
Вы могли заметить, что довольно давно не было постов тут, а дело тут вот в чем — я уволился и искал новую работу, поэтому много свободного времени уделял на подготовку к собеседованиям. Сейчас, наконец, все устаканилось, может быть, я позже расскажу подробнее как это было, но пока, благодаря этому я смог вернуться к вам с разными задачами и темами собесов, которые сейчас актуальны 😎
Поэтому первый пост про задачку, которую мне дали на первом этапе собеседования, довольно простая задачка на алгоритмы и знание питона. Кроме решения необходимо было, как и везде оценить сложность и предложить, как его улучшить.
От себя могу сказать, что задача совершенно несложная (уровень изи на литкоде), проверяет просто то, что вы умеет что-то писать на питоне. Собственно, если вы не собеситесь в Яндекс, то и вряд ли на DE у вас будут жестить по алгоритмам.
Итак, что нужно:
Даны два массива и число target. Нужно найти такие пары чисел (по одному из каждого массива), сумма которых даёт target. Вернуть надо их индексы.
Пример:

a = [1, 3, 5]
b = [2, 4, 6]
target = 7

Ответ:

(0, 1)
(1, 0)
(2, 2)

Решение:
Вариант 1: В лоб, через перебор
for i in range(len(a)):
for j in range(len(b)):
if a[i] + b[j] == target:
print (i, j)
Просто, понятно, но O(n²)

Вариант 2: Добавим хеш-таблицу, т.к. поиск в ней по ключу — О(1)
b_map = {value: j for j, value in enumerate(b)}
for i, value in enumerate(a):
needed = target - value
if needed in b_map:
print (i, b_map[needed])
Уже гораздо лучше, сложность уже О(n). Но самые внимательные из вас могли подумать и заметить: а что, если для одного числа из первого массива подходит несколько вариантов из второго. Вот тут пригодится такая очень удобная тема, как defaultdict.

Вариант 3: Через defaultdict
b_map = defaultdict(list)
for j, value in enumerate(b):
b_map[value].append(j)
for i, value in enumerate(a):
needed = target - value
if needed in b_map:
result.append((i, b_map[needed]))
print(result)
Этот вариант тоже работает за O(n + m), но позволяет найти все индексы b, подходящие к каждому a[i]

Оставляйте ваши решения в комментарии 😎 👇
Вернусь с другими задачами и вопросами с собесов

@bigdata_postupashki

Как Spark оптимизирует запросы

Spark вроде бы понятный — прочитал parquet, отфильтровал по статусу, посчитал count — всё просто. Но иногда одну и ту же команду можно написать так, что отработает за секунду, а в другом случае будет работать часы.
Почему? Давайте разберемся
Spark не магическая коробка, которая непонятно как молотит сотни гигабайт данных, а использует конкретные хорошо известные нам техники.
Я бы хотел остановиться на трех из них и показать, как не сломать их

1. Predicate pushdown
Spark может передавать фильтры (WHERE) сразу в источник — parquet, ORC, JDBC. То есть не грузить весь файл, а сразу читать только нужные строки.
Пример:

df = spark.read.parquet("s3://...").filter("status = 'active'")

Когда работает:
— фильтр простой (=, >, <)
— источник поддерживает pushdown (паркет, ORC, JDBC)
— фильтр указан явно, а не через UDF

Когда не работает:
—фильтр через UDF
—фильтр через выражение (df["a"] + df["b"] > 5)
—JSON и CSV (там pushdown нет вообще)
Проверить можно через план запроса df.explain(True). Ищите PushedFilters.

2. Column pruning
Если тебе нужны только user_id и amount, Spark может прочитать только эти поля. Особенно важно, если таблица на 300+ колонок.
Пример:

df = df.select("user_id", "amount")

Когда работает:
— n.select(...), без *
— формат — parquet, ORC, JDBC
Когда не работает:
— select("*")
— ты передал df в .rdd.map(...), .apply(...) или UDF
Поэтому, когда работаете с большими данными, рекомендую первое время вообще не использовать SELECT *, потому что в таблице может быть 100/200/100500 колонок, и тянуть их все влечет проблемы с производительностью. Вряд ли вам нужны все сто колонок
В explain будет Scan parquet [user_id, amount], если всё хорошо.

3. Partition pruning
Последнее по списку, но не по значимости
Если данные разложены по папкам (event_date=...), Spark может читать только нужные партиции, а не все подряд.
Пример:

df = spark.read.parquet("s3://events/").filter("event_date = '2025-07-30'")

аналогично через Spark SQL

spark.sql("SELECT id, date FROM table WHERE date = '20250801'")

Когда работает:
Очевидно ,когда таблица партицированна
Когда не работает:
— Фильтр через UDF или через функцию, например: year(event_time)
— Spark (да и не только) не умеет применять оптимизации к колонкам внутри функций
— JSON/CSV без схемы и partition discovery
Проверяется через PartitionFilters в explain(True).

Итак, точно ломают Spark-оптимизации:
— select("*"). Всегда.
— отсутствие фильтра по колонке партицирования
— функции на колонках, по которым идет фильтр
— UDF. В целом их можно использовать, но очень аккуратно и желательно стараться обходиться стандартными средствами
— использование формата вроде csv, json и т.д.

Так что следуйте этим простым правилам, и Spark будет у вас летать 😎
Ну и конечно всегда открывайте и читайте план запроса!

Подписывайтесь на канал, ставьте огонечки, будем и дальше разбираться с технологиями в Big Data! ⚡️
Также записывайтесь на наш курс по инженерии данных, чтобы стать крутым DE 🔥

@bigdata_postupashki

Как устроен Trino — разбор для дата-инженеров

Наверняка многие из вас слышали про эту технологию в последнее время, её часто видно на митапах, поэтому давайте разберемся, почему же Trino сейчас становится таким популярным?
Trino (раньше назывался PrestoSQL) — федеративный SQL-движок для запросов к разным источникам: S3, Iceberg, Hive, PostgreSQL, Kafka и др. Он не хранит данные, а исполняет запросы напрямую — туда, где данные лежат. Сейчас часто используют его именно в Lakehouse архитектуре, как основной инструмент взаимодействия с данными.

Давайте же разберемся, из чего он состоит.

Coordinator — планирует запросы
Главный процесс в Trino: принимает SQL-запрос, строит логический и физический план, применяет оптимизации (pushdown, partition pruning, join-стратегии), разбивает план на фрагменты и распределяет их воркерам
Coordinator чем-то похож на Spark Driver — но проще: не участвует в shuffle, не управляет состоянием, не держит данные. Его задача — распланировать и отдать.

Workers — исполняют задачи
Воркеры получают части плана и исполняют их: читают данные, фильтруют, джойнят, считают. Stateless — не кэшируют и не сохраняют контекст между запросами. Просто получили задачу, сделали, отдали результат.
В отличие от executors в Spark, Trino workers не привязаны к приложению или сессии. Один запрос — одна жизнь.

Catalogs — подключение к источникам
Trino сам по себе ничего не знает про таблицы. Всё взаимодействие с данными идёт через каталоги. Каталог — это конфигурация, в которой описано, где лежат данные, как их читать и какие метаданные использовать (HMS, Iceberg REST, JDBC и т. д.).
Это одно из ключевых отличий от Spark. В Spark чаще всего используется один Hive Metastore как основной каталог, а подключения к внешним базам делаются отдельно — через JDBC внутри SparkSession. В Trino — наоборот: всё подключается через каталоги. Хочешь работать с PostgreSQL? Подключаешь каталог postgres.properties. Нужно S3 с Iceberg? Заводишь каталог iceberg.properties. Trino обрабатывает всё единообразно.

Пример:

SELECT o.user_id, o.order_id, u.region
FROM postgres.sales.orders o
JOIN iceberg.analytics.users u 
  ON o.user_id = u.user_id
WHERE u.region = 'eu-west'

Здесь Trino:
1. читает таблицу orders из PostgreSQL
2. читает таблицу users в формате iceberg в S3
3. применяет фильтр (Trino умеет передавать фильтры в источники данных)
5. делает join
6. возвращает результат
Это одна из главных причин использовать Trino. В Spark такое возможно, но требует ручного объединения DataFrame’ов, подключения JDBC, прописывания схем и довольно много обвязки.
Кроме того, он прекрасно интегрирован с Iceberg(как и Spark): умеет не только читать данные, но и модифицировать их — в связке с Iceberg доступны DELETE, MERGE, UPDATE.
Поэтому Trino стоит использовать как единую точку входа в ваш lakehouse, а также инструмент для построения BI-отчетов и дашбордов (он хорошо работает с Superset, Metabase и другими)

Тrino + Iceberg это сейчас довольно модная связка, которую обкатывают многие компании, и сами по себе технологии активно развиваются (можно хотя бы по активности на GitHub удостовериться). Поэтому рекомендую поизучать, ведь она все чаще встречается в архитектуре и всплывает на собеседованиях.
Полезно и в теории, и в проде 🤓

А также рекомендую подписаться на наш канал, чтобы первыми узнавать про всё самое интересное в Big Data 😎

Ставьте ❤️ если хотите еще разборов технологий
Ставьте 🔥 если уже работали с Trino

Также записывайтесь на наш курс по инженерии данных, чтобы стать крутым DE 🔥

@bigdata_postupashki

Задача с собеседования в Спортмастер
В ней проверяют не столько умение решать задачи на sql, сколько ваше умение использовать df api в Spark — по тому, как вы решаете, сразу можно понять, сколько вы знаете про Spark.

Условие:
Даны таблицы:
sales(datetime, shop, art, quantity) — продажи товаров (quantity может быть отрицательным — возвраты).
prices(art, price) — цены товаров.

Задача:
Найти выручку магазина 100 за 2013-01-01.
Выручка = quantity * price.
Возвраты учитывать.

Пример данных:
Sales
datetime | shop|art| quantity
01-01-13 12:12:12 | 100 |A1 | -2
01-01-13 12:12:13 | 100 |A1 | 3
Prices
art|price
A1 |10
Собственно, решение тут совсем несложное, как на SQL, так и на Spark DF, поэтому рекомендую сначала самому решить быстро, а потом проверить 🤓

Решение:
SQL (Spark SQL)
SELECT SUM(s.quantity * p.price) AS revenue
FROM sales s
JOIN prices p USING (art)
WHERE s.shop = 100
AND to_date(s.datetime) = '2013-01-01';

PySpark DataFrame API
from pyspark.sql.functions import col, to_date, lit, sum as sum_
# сначала не забываем делать фильтры и селекты, а только после джоины и агрегации
sales = spark.read.table("sales")\
.withColumn("date", to_date("datetime"))\
.filter((col("shop") == 100) & (col("date") == lit("2013-01-01")))\
.select("art", "quantity")

prices = spark.read.table("prices").select("art", "price")

df = sales.join(prices, "art", "inner")\
.withColumn("amount", col("quantity") * col("price"))\
.agg(sum_("amount").alias("revenue"))

А чтобы с легкостью решать такие задачи рекомендую записывать на наш курс по дата инженерии 😎

@bigdata_postupashki

SQL на стажировку в Т-банк

Дедлайн 26 августа. Ответы на тест по SQL, условие, а ответы ниже:

1. FROM/JOIN, WHERE, GROUP BY, HAVING, WINDOW, SELECT, ORDER BY, LIMIT/OFFSET
2. LEFT JOIN
3. COUNT, SUM, AVG
4. Возвращает первое ненулевое значение из списка
5. Не допускает NULL и определяет уникальность строк
6. DROP TABLE
7. NULL
8. LIKE "__X%" (два подчеркивания)
9. Нельзя использовать sum агрегат в where -> нужно перенести в Having
10. Подзапрос возвращает тысячи строк

А разбор задач по SQL уже на нашем курсе дата инженер и аналитика хард, на которые скидка 50% только до 26 августа.

@bigdata_postupashki