В 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). И понять, как устроить мониторинги и алерты работающих или сломавшихся пайплайнов.

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

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

WB Track - уже видели?

Теперь можно отправить посылку через логистику Wildberries. Адресат заберет ее из своего пункта ПВЗ.

https://track.wildberries.ru/

Вполне логичный шаг, когда есть логистика такого масштаба. Заодно WB окучивает селлеров, которые не работают через маркетплейс, но которым нужна доставка товара до клиентов с развитой сетью и сервисом. Плюс к тому, у маркетплейсов теперь будет большая проблема в содержании сети ПВЗ из-за повышения налоговой нагрузки на малый бизнес. ПВЗ - армия на марше, которую надо кормить, любая дополнительная копеечка сгодится.

Молодцы, что сказать.

Ну а мы можем оценить - какой объем данных генерирует доставка 1 млрд посылок за год
💾💾💾💾💾

Философское - облако и разделение труда (2)

Переложим эту мысль на наш мир ИТ.

Если мы переложим часть задач разработки на аутсорс, мы успеем больше. Риски от этого повысятся: вдруг заказчик обанкротится, профакапит, сорвет сроки, сделает не так как надо?

Можем взять на администрирование СУБД или кубернетисов внешнюю команду. Можем часть функционала закрыть SaaS.

Рост кооперации, рост производительности, но и рост рисков.

Чтобы заняться ростом кооперации, нужно чтобы удовлетворялось ряд требований.

1️⃣ Члены кооперации должны уметь считать выгоду и главное, риски. Часто бывает, когда критический функционал аутсорсится, а внутренняя команда занимается всякой ерундой.

2️⃣ Должно быть доверие между участниками. Доверие создается годами и успешными проектами. Часто просто должно пройти время.

3️⃣Рост производительности должен конвертироваться в рост благосостояния. Телеги должны продаваться и растить маржу, а не оседать на складе.

4️⃣ Риски должны быть разумными и не расти со временем. Не должно быть риска роста рисков - например введения смертельных штрафов в случае если что-то идет не так.

Хотя как известно, нет такого преступления, на которое капитал не пойдет ради 500% прибыли. Люди идут на риск даже при угрозе физического вывоза себя в лес.

Философское - облако и разделение труда (3)

Верх кооперации в ИТ - Платформы и облака.

Сегодня у большой ИТ компании может быть 0 собственных серверов, а продукт базируется на IaaS, PaaS, SaaS сервисах.

В то же время многие либо сидят на своей инфраструктуре, либо даже мигрируют в другую сторону: с облака на землю.

Если спросить, почему они так делают, то мы по сути получим какой-то недостаток из 4 пунктов выше.

Часто приходится слышать о таких вещах как

🔤 Мы поехали в облако, а оно нас подвело вследствие багов и аварий. Разрушение доверия, реализовавшиеся риски.

🔤 У нас регуляторные ограничения. Прямой запрет на этот тип кооперации от государства. Так как государство считает, что рост рисков конкретно в этой области неприемлем.

🔤 У нас и так все хорошо. Нет рынка для сбыта новой продукции. Нет воли к расширению. Экономика расширения не сходится.

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

Не получите. Не потому что фичи плохие, а потому что доверия к вам нет. Sad but true.