Не все JDBC одинаково полезны

Перед Новым годом ребятам захотелось подключить вертику к старроксу, чтобы облегчить миграцию ядра dwh. Сверки делать стало бы легко, часть витрин можно было бы просто проксировать до момента материализации (тем более кажется, что в случае вертики запросы бы работали куда лучше обращений в oltp базки).

Конечно, же - документация всегда устаревает и всегда неполная. То, что выглядело задачкой на пару минут закончилось картинкой выше.

В теории, написать свой адаптер - дело часа, там 150+ строчек жабки для реализации этой абстракции.

Но есть целая пачка против:

* написать быстро, собрать и дебажить долго (уже пара дней)
* ждать момента включения в текущий апстрим около месяца (а это же фича, а не баг, поэтому немаловероятно, что в стейбл может и не попасть)
* это время ждать или жить на форке - смотри пункт первый про свою сборку
* включат ли вообще этот код в апстрим? Я бы не включал - какой смысл тратить время на поддержку БД, которая полутора ногами в могиле
* и самое интересное для меня - а почему я должен тратить свое время и время своей компании на реализацию поддержки какой-то вендорской бд (которая судя по адаптеру дбт близка к наплевательству на своих пользователей)?

С нашим размером вертики проще каждое обновление сливать паркетный дамп в хадуп и оттуда читать напрямую в СР.
А вы бы как поступили? :)

Русскоязычный рынок признан перспективным

1 пост назад я скидывал вакансию на чемпиона от мира StarRocks, и это было признанием, что компания готова вкладывать в развитие своего продукта на нашем рынке. А теперь можно поделиться каналом официального представителя, которого можно будет мучить и спрашивать "почему так?...", да еще немножко управлять ожиданиями - https://t.me/starrocks_selena

И сразу же хороший пост про роадмап на этот год, который я тоже хотел сделать.
Это что же, можно теперь расслабиться и доставать ведерко с попкорном?.. Мечты, мечты :)

Презентация прошла неуспешно - Apache Paimon

Первый блин вышел комом - данные стали занимать в 2 раза больше места, чем в чистом паркете. И запросы стали выполняться в 2-4 раза медленнее, чем на чистом паркете. А запрос на удаление занимает столько же времени, сколько пересоздать партицию целиком. Речь про спарк, если что, до СР еще не дошли.

Похоже так просто его не взять :)

Снаряд два раза в одну воронку не падает

Интересно, что у архитектора данных вышел цикл постов о том, почему стоит ехать в облако. А тем временем в нашей вселенной идет все ускоряющийся цикл ухода от облачной инфраструктуры во внутреннюю платформу данных чисто на реализовавшихся рисках (деньги смысла считать даже нет, стоимость рисков с лихвой покрывает всё).

Про что речь? В своем докладе что на смартдате, что в остальных местах я рассказывал про блокировку аккаунта в Google BigQuery в прошлом году на время уточнения данных, и заняло это 3 недели. Что случилось 2 недели назад? Да, аккаунт опять заблокировали, опять уточнение, ну а работа - потерпите, чай не сахарные. И следом уже вчера заблокировали целый пул ip адресов европейских цодов из стран вокруг РФ - запрет на использование api своих сервисов (BQ, GCP). То есть ты находишься не в РФ, платишь не с РФ, но никого не волнует.

Итого последние 3 недели мы перевозим проекты в StarRocks днем и ночью. Но почему-то получилось, что вместо расчета их там все заехало в Spark. Причина достаточно простая - наши эксперименты с бигквери проходили на проектах малого размера, почти все модели в dbt считались на table материализации. Spark такие штуки раскладывает примерно за 10-15 секунд на витринку, нагружать же mpp бд такого рода нагрузкой кажется напрасной затеей. Ведь в чем всегда была притензия к данным в хадупе - медленное чтение, а вот витринки собираются порой быстрее вертики (да что там, кликхауз у меня тоже получалось когда-то в телекоме обогнать). В итоге пользователи, биай и сервисы читают и делают эдхоки через StarRocks, а счет идет в кластере хадупа - все по заветам современных историй лейкхаузов, правда без перекладывания данных в слой доступа.

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

Даже если функции выглядят в двух системах похоже (именуются одинаково), то совсем не факт что их аргументы или возвращаемые результаты будут идентичными. И поверх накладывается проблема вскрывания ошибок во время написания витрин в исходной системе, когда мы вынуждены или переносить расчет данных и найденную ошибку, либо мы теряем возможность построчной сверки :(

Вообщем печаль, беда и разорение. Если кто знает уже готовый тулсет для сверки таблиц построчно-поколоночно на спарке - напишите в комментарии, пожалуйста. Написать свой вроде несложно, но вдруг древние уже учли все проблемы. Почему spark? Потому что можно в нем внутри сравнивать разные системы без материализации и копирования данных, а еще легко сделать select sha1(*) from...

Pythonic Cursor и литература

Когда-то в очень далекой галакти.. просто очень давно (лет 6-7 назад) я попал на собеседование на инженера данных в VK. Это было время, когда у них внутри никто и подумать не мог про яндекс балалайки, все мучали... рассказывали про свою самописную бд и свой PHP. И буквально за пару недель до собеса вышла статья про то, как они написали свой rate limiter для вставки данных в Clickhouse. И вот весь час собеседования мой интервьювер пытался выжать из меня идеальную реализацию лимитера на python (сразу скажу, что безуспешно :). И вот именно с тех пор я понял, что, во-первых, такие штуки не так просты, и ,во-вторых, не надо изобретать велосипеды и стоит брать уже готовые библиотеки для вашего языка.

Перемещаемся в наше время. Мне для какой-то очень простой апишки надо ограничить отправку данных в нее с нашей стороны - то есть добавить этот самый rate limiter. Скучная работа - добавить зависимостей, поменять 1 строчку в коде и накинуть тестов. А что у нас есть для скучной работы? Cursor! Хей, Cursor, добавь rate limiter вот тут для requests.post с ограничением в 100 запросов в секунду и сделай под этот функционал тестов. Было странно видеть, что в этом же файле появился новый класс с своей самописной реализацией лимитера (да еще и бажной). Если кто не знает, то есть обертка requests-ratelimiter, с которой вместо Session из requests просто используем LimiterSession. Поправили и забыли.

Но вот что кажется забавным - в python и правда очень любят писать свои велосипеды. Язык настолько простой, то прямо располагает к этому. Зачем читать чужую библиотеку, когда я и сам могу написать не хуже (вспоминая собес, ну, после 5 итерации наверное). Если llm натренирована на той куче кода в гитхабе, то и выдает она вполне Pythonic решение :)

А к чему это фото, подумаете вы? Просто для прочистки мозгов и улучшения вашего python кода очень советую почитать (а может даже и пописать) код на golang. Мне коллега как-то сказал, что мой код на python теперь напоминает гошку - и в принципе, я это считаю за комплимент :)

А у вас на прикроватной тумбочке что есть интересного? :)

DE больше не нужны

Последнюю неделю все чаты обсуждают пост Димы Аношина про то, как злые бриксы выпиливают возможности ковыряться в техничке дата инженерам.

Но для меня история с обязанностями де остается не очень понятной, и скорее всего виной всему наши (да и не только наши) бигтехи. На рынке сейчас есть только одна возможность выжить - очень быстро доставлять. Доставлять фичи, доставлять решения, зарезать неверные решения (если мы говорим про аналитику). А теперь смотрим на картинку выше - сколько времени займет доставка из этого классного кружка? :)

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

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

И вот тут каждая компания начинает ловить баланс - сколько кого им надо, в зависимости от потребностей, баланса, эго руководителей.

Дальше я вижу проблему в триаде аналитик данных - аналитик-инженер - инженер данных. Эти три роли примерно про одно и тоже, но стоят последовательно на спектре задач от технички до бизнеса. И при этом имеют два ограничения - домен данных и отсутствие масштабирования результатов труда. То есть в голову больше ограниченного объема бизнеса не получить, и витринки под каждого заказчика становятся все глубже и детальней. Техничка для инженеров не является никаким ограничением - ну камон, научиться использовать партиции в спарке, джойнить по ключам в постгрессе, использовать файнал в кликхаузе, ну не большая же наука?

Заканчивая мысль, рынок будет стремиться сократить ТТМ аналитических решений за счет сдвига людей в сторону бизнеса, что и приводит к смерти профессии инженера данных.

Ну а если хочется остаться в техничке - это путь в платформенные команды или чистую разработку (как те же мл-ребята).

PS перечитал и увидел, что не раскрыл историю с бигтехами. Быть повелителями yml != инженером данных. Очень странно слышать про то, как угнетающе писать ямлы в Т, озоне и еще где-то, но при этом не мочь сказать ни слова про бизнес домен, в котором работаешь. В чем тогда состоит работа? Быть живым курсором?..

PPS никогда не работал в бигтехах :) и вообще сегодня пятница

Вот такой подарок привезли :)

Интересная штука. Я все гадал, что же может весить почти 2 килограмма :)

Любовь к переопределению стандартных настроек

Не знаю с чем связано непреодолимое желание определить свои настройки и забивать на стандартные практики в индустрии. Дам два примера:

* Apache Paimon и его ишью. Кратко: ваши желания в hdfs-site.xml - это ваши проблемы, а писать файлы мы всегда будем с фактором репликации 1. Доросли до версии 1.3, но исправление есть только в мастере.
* dbt-starrocks и его настройки адаптера по умолчанию. Что вы там на уровне кластера задали - ваши проблемы, все новые модели мы будем сохранять с фактором репликации 1.

Очень-очень сильно такие вещи вымораживают, когда ты однажды остаешься без данных из-за мигнувшей ноды.

ODBC и Qlik Sense

Почти во всех своих выступлениях я топил за то, что на StarRocks легко мигрировать за счет стандартных MySQL драйверов. Все системы подключили, формально все работало хорошо с хорошими размерами данных. Но мы начали массово переносить приложения в клике на данные из ср и получили непонятные проблемы :(

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

* попали на обновление данные через спарк (нет, не попали)
* не обновилась мета файлов в StarRocks и запросы падают по причине несуществующих файлов (нет, обновилась. вплоть до того что пробовали втыкать перед загрузкой refresh external table и select limit 1 - данные есть и читаются)
* косяк с ODBC драйвером: начали с самого последнего 9+, потом нашел статью от CelerData по подключению PowerBI и там указана 8.0.23 (нет, не помогло)
* попытка перейти на Mysql Enterprise Edition драйвер, который предоставляет сам Qlik Sense (нет, StarRocks с ним не совместим)

Бродил по ишью в гитхабе и наткнулся на мнение интерна, что StarRocks вообще не очень хорошо поддерживает именно ODBC драйвер.

И самое интересное, что в нашем случае проблемы как таковой нет - у нас обновление приложений запускается через сторонний оркестратор (airflow) и ретрай всегда заканчивается успехом. И затронуты не все прилы.

Нипанятна :(

Сегодня день анонсов разных мероприятий по StarRocks, которые пройдут уже вот-вот.

Буквально вчера в канале спрашивали про работу iceberg через StarRocks на S3 от Selectel.

И вот тут есть что послушать (но не уверен про S3):

вебинар СР ТЕХ х Selectel 31 марта в 12:00.
Расскажем про результат прогона StarRocks на TPC-DS в облаке: от 3 узлов до 111, от 100 ГБ до 10 ТБ. Реальное поведение СУБД с графиками, цифрами и инженерными выводами.
Регистрация на вебинар: https://selectel.ru/blog/events/analytics-database/

А теперь мероприятие номер 2. Если кто хочет пообщаться с разработчиками StarRocks лично :) А таких я видел.

✨ 2 апреля в Москве на Data Summit от DIS Group выступят коллеги из StarRocks

💼 спикеры расскажут о следующих аспектах развития StarRocks:
🔹 применении ИИ‑агентов в StarRocks;
🔹 повышении скорости аналитики в реальном времени — том самом «молниеносном» быстродействии системы;
🔹 roadmap продукта, включая новости о материализованных представлениях и их субсекундных обновлениях;
🔹 улучшениях в механизмах кэширования и оптимизаторах;
🔹 работе с операциями UPSERT и MERGE;
🔹 поддержке рекурсивных CTE‑операций;
🔹 расширении возможностей UDF в SQL;
🔹 алгоритмах распределения данных в таблетах на основе интервалов значений.

📅 Ещё есть время зарегистрироваться на мероприятие: можно выбрать желаемый формат участия — онлайн или офлайн.

🚀 2 апреля — отличная возможность узнать о новинках и перспективах StarRocks из первых рук. Рекомендуем обратить внимание на это событие!