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