Когда твое резюме никто не смотрит на HH и…
____________
Записывайся на BootCamp для дата инженера тут - @bootcampych_bot

Короче вот, что я подумал.

Создадим везде каналы и чаты. В RoamdapDE и в телеге на главной будут ссылки.

Вот кто куда захочет, тот туда и перейдет. Если на какой-то площадке будет мертво, то она и умрет сама своей смертью.

📊 Мне друг подкинул интересную задачу

Объединение ДАМПОВ ДАННЫХ Discogs (Releases + Labels)

В чем сложность?
Есть два датасета: релизы и лейблы (Оба в формате XML).

Один весит 60Гб. Другой 400Мб.
Локально обработать 400Мб не проблема — это изи. А вот распарсить 60Гб и вытянуть оттуда только нужны период — хард задача.

Что нужно сделать:
1. Взять данные по релизам за последние 1.5–2 года
2. Сделать JOIN двух таблиц по названию лейбла (или по id)

В чем смысл?
В таблице releases (60Гб) надо взять названия лейблов, которые делали релизы за последние 2 года. Склеить их со справочной информацией из labels. Джойнить по id или по названию (выбрать ключ самостоятельно).

Датасеты (XML):
• Labels: https://data.discogs.com/?download=data%2F2026%2Fdiscogs_20260301_labels.xml.gz
• Releases: https://data.discogs.com/?download=data%2F2026%2Fdiscogs_20260301_releases.xml.gz

(Также есть семпл релизов во вложении — можно использовать для первичной проверки)

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

Пример чтения XML через PySpark:

import os
from pyspark.sql import SparkSession

spark = SparkSession.builder \
    .appName("SparkExample") \
    .config(
        "spark.jars.packages",
        "com.databricks:spark-xml_2.12:0.18.0"
    ) \
    .getOrCreate()

from pyspark.sql.functions import max

df = (
    spark.read
        .format("xml")
        .option("rowTag", "label")
        .load("discogs_20260301_labels.xml")
)

df.show()

Кто че думает? Какими инструментами бы обработали?

✅Update: витрину построили! Добавлю эту задачу в BootCamp!

Data Science и Data Engineering: какое направление выбрать в 2026 году?

🎧 1 апреля пройдет День открытых дверей онлайн-магистратуры НИЯУ МИФИ «Специалист по работе с данными и ИИ» в партнёрстве с Яндекс Практикумом.

На встрече обсудят:

💙 как рост ИИ трансформируют рынок труда
💙 4 трека для развития: ML, CV, NLP и Data Engineering
💙 какие задачи усложняются и где усиливается конкуренция

И расскажут, как за 2 года освоить фундаментальную базу, собрать портфолио из проектов и получить диплом магистра без отрыва от работы.

Подключайтесь онлайн 1 апреля в 19:00 мск.

🏃‍♀️ Записаться на ДОД

Как вывести себя в ТОП?

Все очень тупо.
1. В резюме в должностях пишем Data Engineer | Инженер Данных

В описании опыта больше слов с Data
Data WareHouse, Data Lake, Data Quality и так далее

В о себе тоже пишем какую-нибудь чушь со словами Data

2. Ставим Активно ищет работу

3. Образование ставим Высшее (не бакалавр или магистр), лучшее общую формулировку поставить

4. Подтвержденные навыки тоже будут вас выкидывать наверх. Я попробовал пройти sql и python с чатом гпт. В плане просто телефоном показывал экран. Даже не читал задания. В итоге чат гпт дает половину правильных ответов. Что равно тупо кликать наугад. Лучше проходить с невидимым ассистентом для собесов. Но в целом вас по ключевым словам и так выводит в топ.

ВСЕ. ЗАНАВЕС

БИГ ДАТА ВСЁ! СПАРК ВСЁ!

В ЛинкеДЫНЕ увидел интересный пост. Решил тут его запостить с указанием автора.
А ведь реально, зачем иногда запускать спарк, когда можно все крутить другими инструментами, менее требовательными к настройке и железу.

Начало поста:

⚡️ Data Engineer 2026: Хватит использовать кувалду для гвоздей. Почему Spark часто избыточен.

"Spark или Polars?".
Решил провести тест на реальных данных — 1 ТБ логов (соединения, аггрегации, фильтры).

Условия:

Spark: Кластер EMR (3 ноды, суммарно 48 ядер, 128 ГБ RAM). Время включает поднятие сессий и настройку.

Polars + DuckDB: Ноутбук с 64 ГБ RAM. Никакого кластера.

Результаты меня самого удивили:

Spark (кластер): ~20 минут чистой обработки + 5 минут на инициализацию. Итог: 25 минут.

Polars + DuckDB (на компе):

Обработка пачками по 100 ГБ: 7 минут (и можно параллелить).

Однопроходная обработка всего 1 ТБ: 11 минут.

Почему так? Данные не врут, и они совпадают с последними исследованиями :

Скорость: На данных до 1-2 ТБ современные векторизованные движки (Polars, DuckDB) просто быстрее JVM-стека Spark из-за отсутствия накладных расходов на сериализацию и shuffle .

Память: Polars в ленивом режиме реально жрет на 60-70% меньше памяти, чем Spark на аналогичных операциях. Это доказано в тестах MDPI . Данные не хранятся в памяти, а текут через процесс (streaming).

Удобство: Не надо настраивать кластер. Просто pip install.

Но давайте без хайпа. Где правда?

✅ Polars + DuckDB идеальны, когда:

Ваши данные "помещаются" на один хороший сервер (до 5-10 ТБ).

Вы ненавидите возню с конфигами Spark.

У вас 80% ETL-задач — фильтрация, аггрегация, джойны (но не 100-столовые монстры).

❌ Spark все еще рулит, если:

У вас петабайты и тысячи ядер.

Нужна единая платформа с глобальным каталогом данных (Unity Catalog и т.п.).

Требуется сложный стриминг exactly-once, который уже обкатан годами .

Мой вывод: Для 90% дата-инженеров, работающих с "терабайтами", Spark — это оверкилл. Мы платим за сложность инфраструктуры там, где можно обойтись одним мощным инстансом и умным кодом.

Конец поста
Источник

Мое мнение: Вообще согласен. Но до реальности это может так и не дойти, либо дойдет очень и очень не скоро. Сколько кода уже написано и переписывать его на новые инструменты не целесообразно - это ведь деньги. И очень непонятно, как объяснить бизнесу, что надо сейчас АСТАНАВИТЬСЯ! и все переделывать под поларс и duckDB. Но с другой стороны запуск спарка, когда у тебя есть кластера - не проблема. Ну да.. крутим этими кластерами не ТБ, а даже меньше. А что если в какой-то момент надо будет крутить больше.. Будем срочно перекатываться?

Да и на запуск спарка я бы не сказал, что это проблема. Да, инициализация бывает долгая, пока спарк стартанет. Ну подождать 5 минут можно.. Хотя если ресурсы есть, то за 10 секунд все собирает.

Короче это холиварная тема. Согласен, что некоторые инструменты просто не нужны в компании, но кто даст время не пересборку всех кубер операторов, переписывание и переделку инфры?

В мелких компаниях я бы рассмотрел polars + duckDB точно.. Там еще и рядом starrocks же есть. Вообще всеми руками за!

Roadmap обновляется быстрее, чем вы успеваете проходить!

Закинули свежие задачи по SQL и Python — всё с реальных собесов.

Плюс добавили песочницу для SQL прямо в браузере:
никаких установок, просто заходишь и решаешь.

Раздел: «Вопросы с собеседований → SQL задачи»

Получить Roadmap —> @bootcampych_bot

🚀 Data Engineer за 2 месяца

Не кликбейт. Мы реально сделали супер интенсив за 2 месяца в DE.
Это буквально копия вашей будущей работы.

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

Так вот именно эту идею мы и вложили в Bootcamp!
За короткое время вы погружаетесь в работу инженера данных, осваиваете современный стек и получаете навыки прохождения собеседований и составления резюме.

Мы реально вычеркнули большую часть бесполезной теории. Упор исключительно на практику.
Чтобы вы пришли на работу и сказали: "Мы это уже делали"

Что внутри буткемпа

Вы получаете доступ к инфраструктуре, максимально приближенной к продакшену:
• Postgres
• ClickHouse (распределённый, 2 шарда)
• GreenPlum (8 сегментов)
• Spark
• S3
• AirFlow
• Kafka
• DBT
• GitHub
• Jira
• Confluence

Как часто занятия?
• 3 раза в неделю (Живые лекции, на которых можно задать вопрос и сразу получить ответ)
• Вечером (после работы) в 20:00 по МСК
• Все лекции записываются и доступны навсегда

Поддержка и практика
• Чат с ответами почти 24/7
• Можно задать любой вопрос
• Можно попросить задачу сложнее
• Разбор ваших решений на созвонах

Подготовка к работе
• Mock собеседования
• Прожарка резюме
• Разбор реальных кейсов

После буткемпа все выпускники приглашаются в чат, где мы делимся ситуацией на рынке, вопросами с собесов, а также поддерживаем друг друга!

Кстати, мы добавили классную фишку — доступ к лекциям из новых потоков. Даже после окончания буткемпа вы остаетесь в обучении и можете следить за обновлениями.

А если не успеваете?
У нас есть InfraSharing. Это тот же самый буткемп, но без лекций. Просто готовая инфраструктура. Даже если не успеваете сделать все задачи в Bootcamp, можете продолжить в InfraSharing. Тем более для всех выпускников мы даем огромную скидку!

Ближайший старт потока — 1 мая
Переходите в наш бот @bootcampych_bot и жми Хочу на BootCamp

ТРИНАААА!

Начал читать про Trino. У меня в голове были несостыковки, типа зачем еще один очередной инструмент в этом Дата Инжиниринге?

АСТАНАВИТЕСЬ!

Рассказываю на пальцах и только самое основное.
Вот есть Spark. С ним мы можем подключиться к PG, CH, S3, GP и другим хранилкам данных.

Пишем там df_pg = spark.read.format("jdbc") Потом отдельно df_ch = spark.read.format("jdbc")
Короче говоря, каждый раз надо подключаться и читать отдельно каждую таблицу.

А я хочу просто написать ОДИН SQL запрос и сразу так:

SELECT u.name, o.order_id
FROM postgres.public.users u
JOIN clickhouse.sales.orders o
  ON u.id = o.user_id;

Чтобы в самом запросе у меня уже указывались разные БД и мне не надо было ничего отдельно читать.
Так вот спарк так не умеет, А ТРИНО УМЕЕТ!

Фишка Трино — это куча коннекторов. Т.е. установили Трино и дальше просто читаем из разных источников. Ничего больше делать не надо. Буквально вы в Dbeaver пишете запрос и все работает. ИЗИ. Кстати к Kafka тоже можно подключиться, но имейте в виду, что в Кафку данные постоянно добавляются и с каждым новым запросом, данные могут меняться.

Короче говоря, супер для AD HOC аналитики!
Называется все это ФЕДЕРАТИВНЫЕ ЗАПРОСЫ

А что еще?
Когда в спарке мы в лоб читаем данные через JDBC, то на все создается одно подключение и 1 партиция. А спарк же распределенный, у нас много executors, на которые надо раскидать данные. И поэтому нужно дописывать еще кода, который читает определенный столбец, создает несколько jdbc подключений и раскидывает все по executors. Короче тут без бутылки водки не разберешься

В трино же просто пишешь один SQL запрос и он сам параллельно читает и раскидывает на свои воркеры. Никаких танцев с бубном. Кстати, внутри Трино и Спарк реально похожи. Такие же координаторы и и воркеры наряду с драйвером и executor.

Какие еще фишки?
Можно создать view и перенести часть вычислений на уровне БД. Например пишем запрос на Trino, но вся нагрузка идет сначала в PG. Типа необязательно тянуть к себе в память. Ну и по факту кол-во фишек еще больше, но думаю и так достаточно инфы.

В чем минусы?
В трино Нет стриминга, MLlib, как в спарке. Также нельзя контролировать кол-во создаваемых файлов, как в спарке через coalesce и repartition. Там есть некоторые общие настройки, которые позволяют компактить, но все же это не совсем то, как это делает спарк во время записи здесь и сейчас.

Короче, Трино идеально подходит для ad hoc запросов. Возможно не всегда его стоит использовать для ETL, потому что нет такой гибкой настройки и контроля прямо, как в спарк. Хотя на мой взгляд, если данных меньше Тб, то почему бы не обойтись только им. Тем более на SQL умеет писать даже собака из соседнего подъезда. А на вашем спарк апи еще пойди найди человека..

P.S.Если есть замечания или еще чего-то знаете, делитесь.