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