Современный LakeHouse

Тренд последних лет у больших ребят - соединить объектное хранилище с основным аналитическим. Ибо ну сколько можно туда-сюда копировать, нет сил больше терпеть :) И именно тут врывается presto, trino, а теперь и doris с starrocks. И не будем здесь вспоминать про готовые движки в clickhouse и greenplum, которые вполне себе быстро читают, но не могут записать.

За что же выбрать StarRocks

Он предлагает на выбор 2 варианта:
1. Работа с внешними каталогами и открытыми форматами хранения. То есть просто подключаешь HMS своего любимого хадупчика (или другую дичь всяких айсбергов) и можешь читать, считать и записывать данные обратно. Причем доступ к данным настраивается дополнительно на уровне самой базы данных с гранулярностью в таблицу. Почитать больше можно здесь. И вокруг будет еще огромная куча внешних каталогов вплоть до JDBC.
2. Работа внутреннего формата данных поверх объектного хранилища. Как раз для ребят с большим количеством данных или перекосом горячих/холодных - когда количество вычислительных ресурсов разбалансированно относительно ресурсов хранения данных. Для хранения можно использовать только S3-like с версии 3.1 S3 как вендоров, так и открытые реализации типа minio, либо HDFS. Тут все должны понимать, что скорость будет равна количеству хаков в обработке и размеру горячего хранилища для кешей. Почитать больше можно здесь.

При всем этом в кластере StarRocks используется 2 типа инстансов для хранения и вычислений над данными: backend nodes and compute nodes. Отличаются они тем, что BE хранят данные локально на себе, а CN используются только для расчетов. В варианте один можно использовать оба типа нод, в варианте 2 так как локального хранения нет используются только CN.

Минутка практики

Для себя мы выбрали вариант 1. Скорость работы с хадупом через HMS позволяет отказаться от использования spark в ad-hoc запросах и сильно упрощает требования на клиентской стороне: mysql драйвер или собрать какой-нибудь pyhive в питоне - две больших разницы.