В статье 5 Things in Data Engineering That Have Changed In The Last 10 Years автор поделился как поменялась индустрия (западная) за последние 10 лет.

1) Компании хотят только сеньоров
Команды сильно сократились, и бизнес требует быстрых результатов → поэтому нанимают в основном опытных инженеров + AI-копилоты усилили продуктивность сеньоров. Джуниорам сложнее входить.

Это произошло в последние 2-3 года. Никому не нужны малыши без опыта. Все хотят опытных людей, чтобы пришли и сразу решали конкретные задачи. В больших компаниях еще сохранилась возможность пройти стажировку и прийти сразу с универа. Но надо, чтобы универ был топчик. Все кто ходят на курсы - мимо. Поэтому мой подход прийти seniorом без опыта выглядит особенно привлекательно в текущих реалиях. Улучшений в будущем для данной ситуации не видно. Специалисты и эксперты в ИТ появляются как грибы. Доступность образования и реклама успешных айтишников в Дубаях и на Патриках делает свое дело. 🚶‍♀️ Все хотят хорошую зарплату и удаленную работу, но места на всех не хватит.😞

2) Cloud стал дефолтом
Раньше облако было опцией, сейчас — стандарт. Все мигрируют: Snowflake, BigQuery, Databricks. Почти никто не строит аналитику он-прем.

Полностью согласен. Я могу открыть любую вакансию в Северной Америке, Южной Америке, Европе, Австралии и тп, и там будет облако и MPP облачное хранилище с вероятностью 95%. Хотя недавно познакомился с инженером, кто пришел к нам из Comcast. Он рассказал, что у них был свой дата центр и он ставил Kafka на bare metal. Ну красавчик, только получает в несколько раз меньше. 🏆

3) Перестали писать кастомные пайплайны
10 лет назад везде были самописные ETL на cron/SSIS/python скриптах. Сейчас сразу используют готовые инструменты: Airflow, dbt, EventBridge, Coalesce, etc. Нужно быстрее приносить ценность, а не строить платформу с нуля.

Доступность инструментов low-code/no-code очень сильно упрощают работу. Можно фокусироваться на бизнес проблемах и ценностях, а не трабалшуить legacy/technical debt код. Хотя уже с развитием AI IDE уже все превращается в no-code/low code. Главное базу знать и понимать основу и свою ценность для бизнеса.

4) SQL победил
Споры между SQL vs что-то ещё закончились — SQL стал универсальным стандартом. Job-market требует SQL практически везде. dbt усилил этот тренд.

Если ваш продукт не поддерживает SQL, то у вас плохой продукт. SQL наше все. Хотя некоторые аналитики обожают Pandas, и пишут что-то в своих ноутбуках. А потом инженерам нужно все это разгребать.🙅‍♂️

5) AI изменил рабочие процессы
AI ускоряет работу, но создаёт риск «движения вместо прогресса»: люди меньше понимают код, больше копипастят из LLM. Выигрывают те, кто умеет совмещать AI + инженерное мышление.

100% все поменялось. Я общаюсь со многими командами и вижу, что люди на самом деле не очень сильно используют все возможности. Большинство не любят перемен и не умеют учиться быстро и эффективно. Когда говорят, что AI заменит людей, чаще всего имеют в виду тех, кто не хочет или не умеет учиться. Сейчас настоящий FOMO в AI и очень важно смотреть куда дует ветер и стараться использовать в работе AI и собирать полезные use cases для вашей индустрии и вашей специализации.

Самое главное, что произошло за 10 лет, то это обесценивание денег, повышение налогов, снижение покупательной способности, отмена job security, и отсутствие стабильности.

В чем устройство LakeHouse и отличие от баз данных?

В этом году чаще слышу о LakeHouse и мыслях его внедрить.
В чем основная суть:
1. Слой хранения выносим отдельно от слоя вычисления -> в s3
2. Формат хранения - универсальный (parquet например)
3. Поверх одного хранилища запускаем разные табличные движки

Похожее произошло с вычислениями пару лет назад с приходом связки kubernetes/s3. Компании смогли динамически аллоцировать ресурсы и за счет этого снизить требования к индивидуальным серверам (правда потом LLM все опять перевернули с ног на голову из-за требований к nvlink и infiniband)

Решил написать пост, наткнувшись на видео от сооснователя DuckLake (для нас интересно до 24 минуты, дальше про DuckLake).

Об естественных особенностях такого решения:

➕Удобно и гибко
1. Много движков, да и свой обработчик легко написать
2. Если движок поддерживает s3/parquet - не нужно писать коннекторы
3. Вычислительные ресурсы можно переиспользовать в рамках кластера (serverless для вычислений)
4. Наверное, будет устаревать плавнее, за счет модульности. То есть заменили движок/инструмент и вроде снова в тренде, не выкидывая всю систему целиком.

➕Дешевле
1. Не нужно закупать вычислительные сервера под хранение
2. Ниже цена ошибки. Можно заранее думать только о серверах хранения, а для вычислений переиспользовать общие пулы ресурсов
3. Если движок поддерживает s3/parquet - не нужно перекладывать и дублировать данные между инструментами команд

➖Сильно медленнее чем классические базы данных
Да, именно так, а что вы хотели?
1. Ходите всегда по сети за данными*, у вас буквально абстракция s3 и нет возможностей выполнить условный map локально на сервере хранения. А значит всегда ограничены 10-20Gbit/s сети.
2. Вынуждены каждый раз парсить файл заново. А обычная база может хранить на диске layout как в памяти и просто делать memmap.

➖Тяжело
Раньше вы поднимали один продукт и настраивали. Тут продукт растащили на несколько независимых инструментов. На масштабе выгодно, для старта - тяжело (тут ситуация на kubernetes похожа)

*Да, вы можете оптимизировать формат хранения (parquet -> Vortex, F3, FastLanes, Nimble) и минимизировать s3 чтения.
Да, вы можете придумать кэши, но тогда появится база под метаданные. Туда в итоге и движемся. Но, повторю, это не то же самое, что прочитать с локального диска и пройтись по файлу. Джордан в видео заявляет х2-10 замедление от баз.

В Spark 4.1 появлся ... Airflow

В документации версии Spark 4.1-Preview появились так называемые Spark Declarative Pipelines (SDP)

На борту:

1️⃣ Несколько видов датасетов: Материализованные, Стриминговые, Временные
2️⃣ Пайплайн как объект. Описывается через YAML файл с SQL, Python кодом и необходимыми конфигами Спарка. Также объявляется каталог (Hive, Iceberg), с которым можно взаимодействовать и в который складывать результаты.
3️⃣ Команда spark-pipelines init с интерфейлом и аргементами как у Spark Submit. Отдельная команда spark-pipelines run.


Удобство

Пример нового кода на PySpark, который читает Kafka топик и складывает данные в таблицу в каталоге. По сути это декларативное описание (не как-сделать, а что-сделать) а-ля DAG.

from pyspark import pipelines as sdp

@sdp.table
def ingestion_st():
return (
spark.readStream.format("kafka")
.option("kafka.bootstrap.servers", "localhost:9092")
.option("subscribe", "orders")
.load()
)

К объявленной таким способом таблице можно обращаться дальше по пайплайну.

На SQL и того проще

CREATE STREAMING TABLE basic_st
AS SELECT * FROM STREAM samples.nyctaxi.trips;

Или пример с несколькими синками

-- create a streaming table
CREATE STREAMING TABLE customers_us;

-- add the first append flow
CREATE FLOW append1
AS INSERT INTO customers_us
SELECT * FROM STREAM(customers_us_west);

-- add the second append flow
CREATE FLOW append2
AS INSERT INTO customers_us
SELECT * FROM STREAM(customers_us_east);

Осталось разобраться, как в этом всем провязаны семантики доставки (exactly-once, at-least-once), и куда это все полетит при смене схемы источника (Dead Letter). И понять, как устроить мониторинги и алерты работающих или сломавшихся пайплайнов.

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

Насладиться примерами можно в офф доке превью версии