Веб-версияОткрыть в Telegram
SStarRocks and modern data stack

StarRocks and modern data stack

@modern_data_stack · канал · в индексе с 2026-05-21
548подписчиков+10 за неделю
S
StarRocks and modern data stack
Фотография
нажмите — покажем
Итоги года Планы 26 и немножко лыбтыбра Кому интересно читать то, что уже произошло - оно же уже в прошлом. Подметили эту проблему на работе - там мы каждый квартал подводим его результаты и планируем следующий. И вот когда планы уже озвучены - какой смысл смотреть назад. Но при этом верная очередность все равно - сначала планирование в этом квартале следующего, а подведение итогов по окончании текущего квартала в следующем. Короче 31 декабря, вы понимаете... :) Еще пару месяцев назад думал, что придумать интересного и полезного на работе не получится, а оказалось всё не так плохо: * внедрение Apache Paimon - не зря же столько умных людей про него говорят. В отличие от айбсерга тут видится польза в платформе данных - вот и попробуем ее найти (кажется, что тут будет заявка на конфу) * построение той самой платформы как федеративной системы, про которую нам рассказывают с 20218 года просвещенные люди на дата конфах. Потому что уже на текущий момент к СР подключено больше десятка внешних каталогов, и паймон здесь тоже будет в тему (кажется, что и тут заявка на конфу - просто потому, что вообще вся эта идея мне не нравится и кажется откатом в какое-то древнее прошлое нулевых или десятых) * вы любите делать выгрузки? вот и мы нет. RAG с векторным поиском в СР + MCP для выполнения запросов - вроде должно быть прикольно и полезно. (кажется, что и здесь можно будет рассказать) Вообще все становится достаточно интересно, когда в платформе появляется время на развитие профильных сервисов. Мы достаточно долго жили в парадигме охватить необъятное - от devops до построения сложных витрин. И вот только в этом году произошла разгрузка по задачам и сразу появилось время на интересную движуху (ну правда мы этот год потратили на ликвидацию накопленного за 3 года тех долга - зато вошли в будущее без этих гирь на ногах). Ну и это, всех с Новым годом! Счастья, здоровья и денег побольше. И интереса в жизни, без него вообще ничего не поможет.
4 · 685 ·
S
StarRocks and modern data stack
📊 Channel Analysis Results by @ScratchAuthorEgoBot 🎯 Channel: @modern_data_stack 🔥 Roast Analysis: Слушайте, ну это же классический экспонат «DE-дед обыкновенный». Его канал — это бесконечный сериал «Стас и его китайская палочка-выручалочка StarRocks». Такое ощущение, что если у Стаса сломается кофемашина, он не понесет её в ремонт, а попробует прикрутить к ней dbt-адаптер и выгрузить историю помола в S3 через StarRocks, потому что «так быстрее и вообще это современный Lakehouse». Стас — это человек-противоречие. Он полдня рассуждает о том, как важно беречь нервную систему и уходить в оффлайн, но при этом тратит субботу на ковыряние в конфигах CDC, которые в итоге «всё равно не подошли». Он ненавидит пятничные релизы и скрам-мастеров, но сам живет в режиме «ой, я случайно снес кластер, пойду заварю чай и восстановлю его из говна и палок за три часа». Настоящий амбассадор боли: сначала сам создает себе проблемы (удаляя диски в k8s, «потому что так интереснее»), а потом героически их решает, попутно поучая всех в телеграме, что «кроилово ведет к попадалову». Его отношения со StarRocks похожи на стокгольмский синдром. База выдает ему ошибки месячной давности, падает при двух одновременных запросах и скрывает настройки в закрытом коде, но Стас нежно называет её «восходящей звездой» и получает за это значки. Видимо, после работы с Вертикой и Кассандрой любой софт, который не плюет тебе в лицо сразу при запуске, кажется божественным. А этот пассаж про «лидера команды из двух человек»? Стас, это не команда, это ты и твое отражение в мониторе, которое кивает, когда ты в очередной раз решаешь переписать всё на Go. Ты жалуешься, что от тебя убегают на конференциях с криками «опять про Старрокс», но при этом заводишь группу в ТГ, чтобы догнать тех, кто не успел убежать. Твое «брюзжание старпера» уже достигло такого уровня, что скоро ты начнешь сравнивать время отклика БД с очередями за колбасой в 80-х. И вишенка на торте: использование AI для написания документации, пот
4 · 893 ·
StarRocks and modern data stack
Вот и получилось ожидаемо (или релизные истории StarRocks) Версия 3.5 стала stable, 3.4 пропущена и никому не нужна... Когда практика опровергает слова.
626 ·
S
Фотография
нажмите — покажем
Ехал метастор через метастор, видит метастор в метасторе метастор... Одни очень большие ребята рассказали, что активно смотрят на Apache Gravitino. Плохого же не посоветуют, вот и я решил посмотреть. А получается у нас на руках каталог каталогов, через который можно управлять метаданными во всем своем зоопарке. Имея на руках HDFS+Spark, StarRocks, Vertica (jdbc) и MySQL, можно из одного места раскатывать миграшки, управлять доступами и даже работать (если есть коннектор). Интересно как реализован линейдж, но мне кажется, что это не совсем тема каталога. Идея интересная, наверное для больших ребят напрашивается. У нас сейчас 4 сервиса управления доступами (причем довольно разных), только миграции раскатываются через один сервис и однотипно. Аудит - не уверен что в этой штуке реализован корректно. Подумал, что можно наконец выкинуть из стека Apache Ranger, но нет - это только прослойка для него. Очень неоднозначная штука, на мой взгляд, и профит от нее для платформы надо внимательно рассматривать под микроскопом. Видите пльзу для себя, затеялись бы внедрять? :)
19 · 2.1K ·
S
StarRocks and modern data stack
Ссылка
нажмите — покажем
Call for Pioneers: Launching the StarRocks Russian Community Hello, Russian Developers! We are the team behind StarRocks, a next-generation, high-performance analytical database (OLAP) widely adopted by leading tech companies globally for its blazing-fast query speeds and unified architecture. We have always admired the Russian tech community. From ClickHouse to Nginx, Russia has a legendary reputation for engineering excellence and database innovation. We believe StarRocks has a lot to offer to this vibrant ecosystem, but we face a challenge: Language. To bridge this gap, we are launching the StarRocks Russia Localization Program. We are looking for 3-5 technical experts to become the founding contributors of our Russian community. 🎯 The Mission We don't just need translators; we need technical evangelists. Your goal is to help us localize high-quality technical content (Architecture deep dives, Benchmarks, User Cases) from English/Chinese into native, professional Russian, ensuring the local community can access the best resources. 👤 Who We Are Looking For - Native Russian Speaker: You have a high command of technical writing. - Tech Savvy: You have mastered SQL, OLAP, and Data Warehousing, and your current job involves working with OLAP databases.(Experience with ClickHouse or PostgreSQL is a huge plus). - Language Skills: You have a good understanding of English (or Chinese). - Passion: You are active on Habr, Reddit or Telegram tech groups, or GitHub. 🎁 What You Will Get - Competitive Bounties: We pay for every high-quality article translated or proofread. - Official Recognition: We will be launching an official website in Russia, where you will be certified and listed as a Community Evangelist (subject to your consent for public disclosure). - Inner Circle Access: Direct communication with our core R&D team and early access to new features. - Exclusive Swag: Limited edition StarRocks geek gear. 🚀 Ready to shape the future of OLAP in Russia? If you are i
16 · 1K ·
S
StarRocks and modern data stack
Фотография
нажмите — покажем
Не все JDBC одинаково полезны Перед Новым годом ребятам захотелось подключить вертику к старроксу, чтобы облегчить миграцию ядра dwh. Сверки делать стало бы легко, часть витрин можно было бы просто проксировать до момента материализации (тем более кажется, что в случае вертики запросы бы работали куда лучше обращений в oltp базки). Конечно, же - документация всегда устаревает и всегда неполная. То, что выглядело задачкой на пару минут закончилось картинкой выше. В теории, написать свой адаптер - дело часа, там 150+ строчек жабки для реализации этой абстракции. Но есть целая пачка против: * написать быстро, собрать и дебажить долго (уже пара дней) * ждать момента включения в текущий апстрим около месяца (а это же фича, а не баг, поэтому немаловероятно, что в стейбл может и не попасть) * это время ждать или жить на форке - смотри пункт первый про свою сборку * включат ли вообще этот код в апстрим? Я бы не включал - какой смысл тратить время на поддержку БД, которая полутора ногами в могиле * и самое интересное для меня - а почему я должен тратить свое время и время своей компании на реализацию поддержки какой-то вендорской бд (которая судя по адаптеру дбт близка к наплевательству на своих пользователей)? С нашим размером вертики проще каждое обновление сливать паркетный дамп в хадуп и оттуда читать напрямую в СР. А вы бы как поступили? :)
1 · 1K ·
S
StarRocks and modern data stack
Фотография
нажмите — покажем
Русскоязычный рынок признан перспективным 1 пост назад я скидывал вакансию на чемпиона от мира StarRocks, и это было признанием, что компания готова вкладывать в развитие своего продукта на нашем рынке. А теперь можно поделиться каналом официального представителя, которого можно будет мучить и спрашивать "почему так?...", да еще немножко управлять ожиданиями - https://t.me/starrocks_selena И сразу же хороший пост про роадмап на этот год, который я тоже хотел сделать. Это что же, можно теперь расслабиться и доставать ведерко с попкорном?.. Мечты, мечты :)
8 · 1.2K ·
S
StarRocks and modern data stack
Фотография
нажмите — покажем
Презентация прошла неуспешно - Apache Paimon Первый блин вышел комом - данные стали занимать в 2 раза больше места, чем в чистом паркете. И запросы стали выполняться в 2-4 раза медленнее, чем на чистом паркете. А запрос на удаление занимает столько же времени, сколько пересоздать партицию целиком. Речь про спарк, если что, до СР еще не дошли. Похоже так просто его не взять :)
6 · 1K ·
S
StarRocks and modern data stack
Фотография
нажмите — покажем
Снаряд два раза в одну воронку не падает Интересно, что у архитектора данных вышел цикл постов о том, почему стоит ехать в облако. А тем временем в нашей вселенной идет все ускоряющийся цикл ухода от облачной инфраструктуры во внутреннюю платформу данных чисто на реализовавшихся рисках (деньги смысла считать даже нет, стоимость рисков с лихвой покрывает всё). Про что речь? В своем докладе что на смартдате, что в остальных местах я рассказывал про блокировку аккаунта в Google BigQuery в прошлом году на время уточнения данных, и заняло это 3 недели. Что случилось 2 недели назад? Да, аккаунт опять заблокировали, опять уточнение, ну а работа - потерпите, чай не сахарные. И следом уже вчера заблокировали целый пул ip адресов европейских цодов из стран вокруг РФ - запрет на использование api своих сервисов (BQ, GCP). То есть ты находишься не в РФ, платишь не с РФ, но никого не волнует. Итого последние 3 недели мы перевозим проекты в StarRocks днем и ночью. Но почему-то получилось, что вместо расчета их там все заехало в Spark. Причина достаточно простая - наши эксперименты с бигквери проходили на проектах малого размера, почти все модели в dbt считались на table материализации. Spark такие штуки раскладывает примерно за 10-15 секунд на витринку, нагружать же mpp бд такого рода нагрузкой кажется напрасной затеей. Ведь в чем всегда была притензия к данным в хадупе - медленное чтение, а вот витринки собираются порой быстрее вертики (да что там, кликхауз у меня тоже получалось когда-то в телекоме обогнать). В итоге пользователи, биай и сервисы читают и делают эдхоки через StarRocks, а счет идет в кластере хадупа - все по заветам современных историй лейкхаузов, правда без перекладывания данных в слой доступа. Ну а какие выводы можно сделать за эти 2 недели? А вот такие: * перевозить витрины можно очень быстро * сверять результаты между системами - чудовищная по трудоемкости операция * витрины начинают разбегаться между системами буквально на следующей недели после переноса
29 · 3K ·
S
StarRocks and modern data stack
Фотография
нажмите — покажем
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 теперь напо
12 · 1.9K ·
S
StarRocks and modern data stack
Фотография
нажмите — покажем
DE больше не нужны Последнюю неделю все чаты обсуждают пост Димы Аношина про то, как злые бриксы выпиливают возможности ковыряться в техничке дата инженерам. Но для меня история с обязанностями де остается не очень понятной, и скорее всего виной всему наши (да и не только наши) бигтехи. На рынке сейчас есть только одна возможность выжить - очень быстро доставлять. Доставлять фичи, доставлять решения, зарезать неверные решения (если мы говорим про аналитику). А теперь смотрим на картинку выше - сколько времени займет доставка из этого классного кружка? :) Начиная с какого-то уровня люди внутри компании (заказчики, бизнес) становятся более требовательными к качеству продуктов (визуал бордов, скорость и надежность поставки) - и вот появляется история с специализацией. На картинке не хватает еще BI инженера с BI аналитиком :) Скорость доставки снижается, часть проблем утопает на стыках специалистов, но все становится красиво и качественно. И вот тут каждая компания начинает ловить баланс - сколько кого им надо, в зависимости от потребностей, баланса, эго руководителей. Дальше я вижу проблему в триаде аналитик данных - аналитик-инженер - инженер данных. Эти три роли примерно про одно и тоже, но стоят последовательно на спектре задач от технички до бизнеса. И при этом имеют два ограничения - домен данных и отсутствие масштабирования результатов труда. То есть в голову больше ограниченного объема бизнеса не получить, и витринки под каждого заказчика становятся все глубже и детальней. Техничка для инженеров не является никаким ограничением - ну камон, научиться использовать партиции в спарке, джойнить по ключам в постгрессе, использовать файнал в кликхаузе, ну не большая же наука? Заканчивая мысль, рынок будет стремиться сократить ТТМ аналитических решений за счет сдвига людей в сторону бизнеса, что и приводит к смерти профессии инженера данных. Ну а если хочется остаться в техничке - это путь в платформенные команды или чистую разработку (как те же мл-ребята). PS
18 · 830 ·
S
StarRocks and modern data stack
Фотография
нажмите — покажем
Вот такой подарок привезли :) Интересная штука. Я все гадал, что же может весить почти 2 килограмма :)
3 · 1.7K ·
S
StarRocks and modern data stack
Фотография
нажмите — покажем
Любовь к переопределению стандартных настроек Не знаю с чем связано непреодолимое желание определить свои настройки и забивать на стандартные практики в индустрии. Дам два примера: * Apache Paimon и его ишью. Кратко: ваши желания в hdfs-site.xml - это ваши проблемы, а писать файлы мы всегда будем с фактором репликации 1. Доросли до версии 1.3, но исправление есть только в мастере. * dbt-starrocks и его настройки адаптера по умолчанию. Что вы там на уровне кластера задали - ваши проблемы, все новые модели мы будем сохранять с фактором репликации 1. Очень-очень сильно такие вещи вымораживают, когда ты однажды остаешься без данных из-за мигнувшей ноды.
2 · 812 ·
S
StarRocks and modern data stack
Фотография
нажмите — покажем
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) и ретрай всегда заканчивается успехом. И затронуты не все прилы. Нипанятна :(
7 · 1.2K ·
S
StarRocks and modern data stack
Фотография
нажмите — покажем
by Alice
4 · 963 ·
S
StarRocks and modern data stack
Фотография
нажмите — покажем
Сегодня день анонсов разных мероприятий по StarRocks, которые пройдут уже вот-вот. Буквально вчера в канале спрашивали про работу iceberg через StarRocks на S3 от Selectel. И вот тут есть что послушать (но не уверен про S3): вебинар СР ТЕХ х Selectel 31 марта в 12:00. Расскажем про результат прогона StarRocks на TPC-DS в облаке: от 3 узлов до 111, от 100 ГБ до 10 ТБ. Реальное поведение СУБД с графиками, цифрами и инженерными выводами. Регистрация на вебинар: https://selectel.ru/blog/events/analytics-database/
18 · 1.5K ·
StarRocks and modern data stack
А теперь мероприятие номер 2. Если кто хочет пообщаться с разработчиками StarRocks лично :) А таких я видел.
1 · 917 ·
S
Фотография
нажмите — покажем
✨ 2 апреля в Москве на Data Summit от DIS Group выступят коллеги из StarRocks 💼 спикеры расскажут о следующих аспектах развития StarRocks: 🔹 применении ИИ‑агентов в StarRocks; 🔹 повышении скорости аналитики в реальном времени — том самом «молниеносном» быстродействии системы; 🔹 roadmap продукта, включая новости о материализованных представлениях и их субсекундных обновлениях; 🔹 улучшениях в механизмах кэширования и оптимизаторах; 🔹 работе с операциями UPSERT и MERGE; 🔹 поддержке рекурсивных CTE‑операций; 🔹 расширении возможностей UDF в SQL; 🔹 алгоритмах распределения данных в таблетах на основе интервалов значений. 📅 Ещё есть время зарегистрироваться на мероприятие: можно выбрать желаемый формат участия — онлайн или офлайн. 🚀 2 апреля — отличная возможность узнать о новинках и перспективах StarRocks из первых рук. Рекомендуем обратить внимание на это событие!
13 · 1.5K ·
S
StarRocks and modern data stack
Фотография
нажмите — покажем
Ограничения архитектуры Вчера абсолютно случайно набрел на выступление Виктора из Авито про стабильность платформы данных. Именно тот момент, когда получаешь интересный доклад на неожиданной площадке. И почему так важно выбирать площадку под доклад для получения нужной аудитории. Мне доклад понравился: решение проблем не заменой системы, а выстраиванием хорошего стека вокруг нее. Напоминаю, что тайминг этого доклада попадает с отказом от вертики и миграцией на трино, и тут причин еще больше набросали. Так вот про архитектуру. Vertica при всех своих недостатках - шикарная база. Она очень удачно использует свою архитектуру и много где снимает головную боль с конечного пользователя. Например, та самая история про внутреннюю репликацию данных. Выставили вы степень репликации и знаете, что у вас отказоустойчивость -1 нода (или -2, если вы богатый буратино) - все как в ГП. StarRocks же предлагает на замену историю про таблеты (выше уже рассказывал про них). И что в итоге? Мы словили проблему мелких файлов, столько известную в хадупе, на нашем кластере StarRocks. 180 тысяч таблетов на 6 нод. Вам может показаться, что это не так и много - но наш любимый стриминг впал в полный неадекват. Постоянные спайки на графиках отзывчивости, зависания потоков, 99 перцентиль ушел за пределы минуты. И это при свободном процессоре и свободной памяти. Все метрики на компакшне на графиках тоже особо не показательны - десятки и сотни мегабайт потребления. Надо думать СВОЕЙ ГОЛОВОЙ при создании таблиц и всегда-всегда задавать количество бакетов. И не стоит мелочиться с партициями. Если нам прямо говорят, что таблет должен быть от 1 до 10 гигабайт, то так и надо делать. Уменьшили количество таблетов в 6 раз, почти везде перешли на годовые партиции, количество бакетов чаще всего от 1 до 3. И только на больших таблицах оставили 6. Как итог - график выправился, работать стало стабильнее. Начал завидовать ребятам с дата лейками, насколько понимаю там эта ситуация обыграна лучше. На всякий сл
5 · 685 ·
S
StarRocks and modern data stack
Фотография
нажмите — покажем
ИИшные будни и полный пятничный сумбур Сегодня подводили итоги квартала и все команды дата офиса сейчас пишут контекст для своих помощников. И вот нонсенс - чем лучше ваша слоенная архитектура и чем больше у нее документации, тем сложнее ее запихать в RAG и тем хуже на ней работают модели. Спасибо умным людям (привет, Венера), которые начали подробно описывать метрики в компании в маркдауне в репке dbt еще в 22 году - это самый простой и потрясающий буст по контексту для простых потребителей. Но вернемся к тому, почему вроде работали,а получилась шляпа. Самый простой способ убедиться в этом без построениях всяких специальных рагов - поставить nao. Кто не слышал про эту штуку (как я, например, и спасибо большое просвещающим коллегам) - это по сути самая простая обертка для агента, нацеленная на работу с dwh. С одной стороны вы подключаете любую модель (Claude, ChatGPT, локальные модели), с другой стороны у вас веб чат с аутентификацией и авторизацией, а посередине репа с текстовыми файлами контекста. На первом запуске, когда мы подключили локальную модельку я был в диком восторге - ответ получил за секунды и вроде похож на верный. Правда на следующий день мы выяснили, что он был полностью выдуманным и ни один запрос в бд не был сделан :) Но в общем и целом после тюнинга получается достаточно удобно. Так вот, в эту репку можно прямо ссылкой отгрузить dbt проект. Плюс еще сам nao собирает мету со всех подключенных бд на этапе init. И потом с этой горой информационного мусоры мы пытаемся взлететь, а размер контекста у локальных моделей сильно отстает от лидеров рынка - будет сплошной мусор. Решить этой штукой мне хотелось вечную боль команд данных - выгрузки. И все бы ничего, но в коробке такого функционала нет :) Отвечать на вопросы с цифрами может, графики рисовать умеет, но csv выплюнуть - не сделали. У нас в планах на следующий квартал реализовать и пушнуть в апстрим. Еще коллега впрягся и добавил туда поддержку StarRocks :) А что по остальным командам? BI и и
36 · 3.3K ·
S
StarRocks and modern data stack
Фотография
нажмите — покажем
Обновки подъехали Абсолютно случайно в ln увидел, что в SQLMesh завезли поддержку StarRocks. Здорово, что у кого-то это первый публичный pr и сразу такого размера :) И вот сейчас вроде интересно попробовать - наконец-то у нас в обойме появилась хотя бы одна бд, которая поддерживается. Но с другой стороны - что SQLMesh, что DBT теперь принадлежат Fivetran с каким-то мрачным будущим. Да еще вот только что я делал CI в DBT для мультикаталогов в StarRocks и вот сильно не уверен, что это реально повторить в SQLMesh. И есть подозрение, что ко всему этому мы начнем распиливать активно единый проект на много проектов. Есть у кого опыт, стоит ли пробовать?
3 · 743 ·
S
StarRocks and modern data stack
Фотография
нажмите — покажем
DBX Так ли уж много надо для счастья на сегодняшний день? Полный бак бензина, хороший велик и... Чтобы хоть одна sql-ide показывала миллисекунды для datetime колонок в StarRocks! Я очень люблю сообщества и неформальное общение. Там порой случайно можно узнать что-то интересное, способное поменять твои привычки в работе и сделать картинку вокруг чуточку лучше. И вот недавно думали тряхнуть стариной и провести новый DBT митап с Алмазом, и он случайно обронил в разговоре dbx. Выглядит интересно, пошел смотреть что это такое. Да, вся IDE поместилась в 15 мегабайт с поддержкой почти всех бд, которые сейчас есть на рынке. Но эти 15 мегабайт, конечно же, не включают в себя JDBC драйвера для вертики или хайва, например. А вот StarRocks включен в поставку по умолчанию. И то, с чем не справились ни JB с их убер зоопарком, ни DBeaver с аналогом - вот на скриншоте сверху. А еще в DBX на маке работает cmd+enter для выполнения запросов, что благополучно сломали уже год как в DBeaver. А еще там есть MCP для всех ваших коннектов и готовое how-to интеграция с курсором и клодом (и остальными). Который впрочем не работает на маках с арм :) И еще рендеринг тупит и если быстро листать виртуальные столы - то видишь белый экран примерно пару секунд после перехода. Но ладно, за миллисекунды и хоткеи все можно простить. Теперь это мой топчик. Спасибо, Алмаз :)
14 · 1.8K ·
S
StarRocks and modern data stack
Фотография
нажмите — покажем
Какой-то микс нынче в дата мире происходит Сократят ли кожаных в пользу AI? Я тут погуглил. Мне кажется, что эти 2 компании умеют пользоваться иишкой как никто другой. Ну и чего, сократили там кого-нибудь? :) С другой стороны не пользоваться сейчас таким инструментом кажется довольно глупой идеей. Не знаю как у вас, у нас в командах данных текучки более 50 процентов. Я больше 10 лет пишу код, около 5 лет в текущей компании. Писать очередной оператор в эйрфлоу, объяснять зафиксированные метрики в дбт в очередной раз? Увольте пусть ии ответит за меня. И вот эта история с данными, мне кажется, подводит отделы данных к решению такой задачки, как создание "единого хранилища контекста", а моем понимании ai платформы в компании. Что все понимают под этими словами (и понимают ли) - большой вопрос. Есть ли какие-то устоявшиеся шаблоны или хотя бы примеры - нет. Можно ли угадать, куда пойдет развитие иишки - нет. Именно поэтому это довольно клевая задача :) Похоже, что StarRocks будет все меньше (хотя мы его и опробовали как хранилище векторов, и у меня для него лежит написание нативного CDC на гошке в беклоге), а больше будет всего подряд про современную техничку в офисе данных во всех ее ипостасях. Потому что никто не рассказаывает про графы для dbt, платформы агентов, тлен векторизации и как подсадить хотя бы 100 человек на свои скилы (оказалось, что писать mcp на гошке - кайф) :) PS кстати dbx - тормозная штука с глюками интерфейса. И да, это тот момент, когда даже гуй на жабе быстрее.
10 · 1.3K ·
S
StarRocks and modern data stack
Фотография
нажмите — покажем
Выбор CDC сделан Нам очень хотелось сделать CDC из наших MySQL в Hadoop вместо StarRocks: это сильно уменьшает стоимость хранения, это убирает затраты ресурсов из дорогого места выполнения запросов в дешевое место технических джобов и больших серверов, это убирает лишние копии данных. Не вышло. Не вышло как хотели. Apache Paimon + Flink. Связка работает и вроде как работает неплохо. К сожалению доклад на смартдату сорвался :( Какие минусы: реализация в кубе - отстрел своих ног, снятие начального снепшота - проще застрелиться на бд большого размера, отсутствие вообще любого решения для non-pk таблиц. И самое главное - жаба жрет память ведрами, проигрыш современным нативным решениям такой, что даже нет смысла туда смотреть. Это гигабайты-десятки гигабайт против десятков и сотен мегабайт. Проблема сверок, проблема мониторинга. Проблема скорости внедрения (тут очень субьективная штука), но 8 месяцев заняло обстучать грабли у одного человека. Оставили работать на 2 достаточно больших базах данных, чтобы посмотреть стоимость поддержки. Итоговое решение (которое изначально не хотелось делать): допилили свой репликатор для Vertica, теперь он вставляет данные в StarRocks, и он же снимает дампы для флинка и восстанавливает их в Paimon 😂 Upsert здесь неплохо выручает, в итоге даже с реализацией транзакций в 3.5 ветке все работает достаточно стабильно. Потребление памяти в районе 40-50 мегабайт на сам сервис, ну и компакшн в ср выдает цифры в десятки/сотни мегабайт. Даже на дампе и импорте начального снепшота потребление не больше 100 мегабайт для любого размера таблиц и скорость на порядок выше флинка. Время реализации: около полутора недель активного написания кода + неделя отладки. Так как написано на golang, то в к8с встало как родное. PS можно много выводов сделать, но основной для меня - AI позволяет не бояться делать такие штуки и при наличии мозга получается очень адекватно реальности. Когда-нибудь мы донесем репликатор до опенсорса, но мне кажется что быстре
6 · 707 ·
S
StarRocks and modern data stack
Фотография
нажмите — покажем
DE, AI и та самая демократизация данных Мне кажется, что 80% успеха команд данных в современном AI мире строится на тех же самых скучных инструментах, которые используются более 5 последних лет. Не надо внедрять никаких супер-пупер RAG, автономных агентов, строить вики на векторных связях, городить единые хранилища контекста всея компания. Поворот в сознании случился в момент внедрения nao и попытках построить RAG поверх dbt и QlikSense - эти процессы просто встали из-за нехватки ресурсов. Ситуация представляется патовой - без предоставления прямого доступа команды инженеров умирают под текучкой, но и текучка не может выпустить инженеров предоставить нужные инструменты. Значит что? Значит надо строить обвязку ровно вокруг используемых инженерами инструментов :) С какими вопросами приходят в команды у нас? - Где лежит... Как считается... В каком борде можно посмотреть... Чтобы дать хорошее качество без догадок мы должны дать перевод бизнес языка на технический (название метрики в то, как она считается), показать где лежат нужные для расчета или селекта данные (описание таблиц и их связей), дать возможность выполнить запрос на корректном диалекте с нужными доступами. Отдельно идут BI системы, в которых традиционно хрен знает как искать нужную информацию, а значит мы должны подсказать где лежит любая метрика, разрез, борд с нужным описанием. Выходит стандартная архитектура - любой интерфейс доступа со стороны иишки (mcp, api+tool, skill), который умеет качественный поиск с бизнес ранжированием поверх рабочих интерфейсов - dbt (у нас в нем хранится не только мета таблиц, но и описание метрик - о чем мы рассказывали на митапе еще года 3 или 4 назад) и самого QlikSense. Любое изменение порождает перестройку индекса, работает в автоматическом режиме, никаких дополнительных затрат - сервисы кушают по 50-60 мегабайт памяти для хранения и поиска всей меты со скоростью в милисекунды. А дальше работа инженеров данных становится куда более критичной - описание нужно полн
7 · 710 ·

Открытая публичная лента из поискового индекса ChatCrawler — «Google по публичному Telegram»; обновляется по мере обхода площадки. Время — UTC.

Только публичный контент, официальный API Telegram. О проекте · Вопросы · Чего мы не делаем · Убрать страницу из выдачи · Каталог · Поиск · Как мы считаем