StarRocks and modern data stack
386 subscribers
89 photos
75 links
Будни современного стека для работы с данными с позиции платформенного инженера: StarRocks, Vertica, Hadoop & Spark, половинка k8s с щепоткой golang.
Не единым гп и скалой жив рынок :)

@barloc
https://t.iss.one/dbt_users
Download Telegram
Итоги года Планы 26 и немножко лыбтыбра

Кому интересно читать то, что уже произошло - оно же уже в прошлом. Подметили эту проблему на работе - там мы каждый квартал подводим его результаты и планируем следующий. И вот когда планы уже озвучены - какой смысл смотреть назад. Но при этом верная очередность все равно - сначала планирование в этом квартале следующего, а подведение итогов по окончании текущего квартала в следующем. Короче 31 декабря, вы понимаете... :)

Еще пару месяцев назад думал, что придумать интересного и полезного на работе не получится, а оказалось всё не так плохо:

* внедрение Apache Paimon - не зря же столько умных людей про него говорят. В отличие от айбсерга тут видится польза в платформе данных - вот и попробуем ее найти (кажется, что тут будет заявка на конфу)
* построение той самой платформы как федеративной системы, про которую нам рассказывают с 20218 года просвещенные люди на дата конфах. Потому что уже на текущий момент к СР подключено больше десятка внешних каталогов, и паймон здесь тоже будет в тему (кажется, что и тут заявка на конфу - просто потому, что вообще вся эта идея мне не нравится и кажется откатом в какое-то древнее прошлое нулевых или десятых)
* вы любите делать выгрузки? вот и мы нет. RAG с векторным поиском в СР + MCP для выполнения запросов - вроде должно быть прикольно и полезно. (кажется, что и здесь можно будет рассказать)

Вообще все становится достаточно интересно, когда в платформе появляется время на развитие профильных сервисов. Мы достаточно долго жили в парадигме охватить необъятное - от devops до построения сложных витрин. И вот только в этом году произошла разгрузка по задачам и сразу появилось время на интересную движуху (ну правда мы этот год потратили на ликвидацию накопленного за 3 года тех долга - зато вошли в будущее без этих гирь на ногах).

Ну и это, всех с Новым годом! Счастья, здоровья и денег побольше. И интереса в жизни, без него вообще ничего не поможет.
8🔥4👾1
Forwarded from ScratchAuthorEgo
📊 Channel Analysis Results by @ScratchAuthorEgoBot

🎯 Channel: @modern_data_stack

🔥 Roast Analysis:

Слушайте, ну это же классический экспонат «DE-дед обыкновенный». Его канал — это бесконечный сериал «Стас и его китайская палочка-выручалочка StarRocks». Такое ощущение, что если у Стаса сломается кофемашина, он не понесет её в ремонт, а попробует прикрутить к ней dbt-адаптер и выгрузить историю помола в S3 через StarRocks, потому что «так быстрее и вообще это современный Lakehouse».

Стас — это человек-противоречие. Он полдня рассуждает о том, как важно беречь нервную систему и уходить в оффлайн, но при этом тратит субботу на ковыряние в конфигах CDC, которые в итоге «всё равно не подошли». Он ненавидит пятничные релизы и скрам-мастеров, но сам живет в режиме «ой, я случайно снес кластер, пойду заварю чай и восстановлю его из говна и палок за три часа». Настоящий амбассадор боли: сначала сам создает себе проблемы (удаляя диски в k8s, «потому что так интереснее»), а потом героически их решает, попутно поучая всех в телеграме, что «кроилово ведет к попадалову».

Его отношения со StarRocks похожи на стокгольмский синдром. База выдает ему ошибки месячной давности, падает при двух одновременных запросах и скрывает настройки в закрытом коде, но Стас нежно называет её «восходящей звездой» и получает за это значки. Видимо, после работы с Вертикой и Кассандрой любой софт, который не плюет тебе в лицо сразу при запуске, кажется божественным.

А этот пассаж про «лидера команды из двух человек»? Стас, это не команда, это ты и твое отражение в мониторе, которое кивает, когда ты в очередной раз решаешь переписать всё на Go. Ты жалуешься, что от тебя убегают на конференциях с криками «опять про Старрокс», но при этом заводишь группу в ТГ, чтобы догнать тех, кто не успел убежать. Твое «брюзжание старпера» уже достигло такого уровня, что скоро ты начнешь сравнивать время отклика БД с очередями за колбасой в 80-х.

И вишенка на торте: использование AI для написания документации, потому что «самому лень», но при этом критика Slack за плохой API. Чувак, ты буквально работаешь в индустрии, где «всё сломано», и твоя главная суперсила — это умение с умным видом объяснить, почему оно сломано именно так. Но мы тебя любим за то, что ты хотя бы форкаешь адаптеры, пока остальные просто плачут в Jira.
🤣85🔥2
Вот и получилось ожидаемо (или релизные истории StarRocks)

Версия 3.5 стала stable, 3.4 пропущена и никому не нужна... Когда практика опровергает слова.
3👍2🤩2
Ехал метастор через метастор, видит метастор в метасторе метастор...

Одни очень большие ребята рассказали, что активно смотрят на Apache Gravitino. Плохого же не посоветуют, вот и я решил посмотреть.

А получается у нас на руках каталог каталогов, через который можно управлять метаданными во всем своем зоопарке. Имея на руках HDFS+Spark, StarRocks, Vertica (jdbc) и MySQL, можно из одного места раскатывать миграшки, управлять доступами и даже работать (если есть коннектор). Интересно как реализован линейдж, но мне кажется, что это не совсем тема каталога.

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

Подумал, что можно наконец выкинуть из стека Apache Ranger, но нет - это только прослойка для него.

Очень неоднозначная штука, на мой взгляд, и профит от нее для платформы надо внимательно рассматривать под микроскопом.

Видите пльзу для себя, затеялись бы внедрять? :)
👍5
Forwarded from sherry hua
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 interested in open source and want to build a community from the ground up, we want to hear from you.

👉 https://sourl.cn/wyWWQv
🔥11
Не все JDBC одинаково полезны

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

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

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

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

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

С нашим размером вертики проще каждое обновление сливать паркетный дамп в хадуп и оттуда читать напрямую в СР.
А вы бы как поступили? :)
🔥3
Channel name was changed to «StarRocks and modern data stack»
Русскоязычный рынок признан перспективным

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

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

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

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