ТРИНАААА!

Начал читать про 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.Если есть замечания или еще чего-то знаете, делитесь.