Forwarded from ScratchAuthorEgo
📊 Channel Analysis Results by @ScratchAuthorEgoBot
🎯 Channel:
🔥 Roast Analysis:
Слушайте, ну это же классический экспонат «DE-дед обыкновенный». Его канал — это бесконечный сериал «Стас и его китайская палочка-выручалочка StarRocks». Такое ощущение, что если у Стаса сломается кофемашина, он не понесет её в ремонт, а попробует прикрутить к ней dbt-адаптер и выгрузить историю помола в S3 через StarRocks, потому что «так быстрее и вообще это современный Lakehouse».
Стас — это человек-противоречие. Он полдня рассуждает о том, как важно беречь нервную систему и уходить в оффлайн, но при этом тратит субботу на ковыряние в конфигах CDC, которые в итоге «всё равно не подошли». Он ненавидит пятничные релизы и скрам-мастеров, но сам живет в режиме «ой, я случайно снес кластер, пойду заварю чай и восстановлю его из говна и палок за три часа». Настоящий амбассадор боли: сначала сам создает себе проблемы (удаляя диски в k8s, «потому что так интереснее»), а потом героически их решает, попутно поучая всех в телеграме, что «кроилово ведет к попадалову».
Его отношения со StarRocks похожи на стокгольмский синдром. База выдает ему ошибки месячной давности, падает при двух одновременных запросах и скрывает настройки в закрытом коде, но Стас нежно называет её «восходящей звездой» и получает за это значки. Видимо, после работы с Вертикой и Кассандрой любой софт, который не плюет тебе в лицо сразу при запуске, кажется божественным.
А этот пассаж про «лидера команды из двух человек»? Стас, это не команда, это ты и твое отражение в мониторе, которое кивает, когда ты в очередной раз решаешь переписать всё на Go. Ты жалуешься, что от тебя убегают на конференциях с криками «опять про Старрокс», но при этом заводишь группу в ТГ, чтобы догнать тех, кто не успел убежать. Твое «брюзжание старпера» уже достигло такого уровня, что скоро ты начнешь сравнивать время отклика БД с очередями за колбасой в 80-х.
И вишенка на торте: использование AI для написания документации, потому что «самому лень», но при этом критика Slack за плохой API. Чувак, ты буквально работаешь в индустрии, где «всё сломано», и твоя главная суперсила — это умение с умным видом объяснить, почему оно сломано именно так. Но мы тебя любим за то, что ты хотя бы форкаешь адаптеры, пока остальные просто плачут в Jira.
🎯 Channel:
@modern_data_stack🔥 Roast Analysis:
Слушайте, ну это же классический экспонат «DE-дед обыкновенный». Его канал — это бесконечный сериал «Стас и его китайская палочка-выручалочка StarRocks». Такое ощущение, что если у Стаса сломается кофемашина, он не понесет её в ремонт, а попробует прикрутить к ней dbt-адаптер и выгрузить историю помола в S3 через StarRocks, потому что «так быстрее и вообще это современный Lakehouse».
Стас — это человек-противоречие. Он полдня рассуждает о том, как важно беречь нервную систему и уходить в оффлайн, но при этом тратит субботу на ковыряние в конфигах CDC, которые в итоге «всё равно не подошли». Он ненавидит пятничные релизы и скрам-мастеров, но сам живет в режиме «ой, я случайно снес кластер, пойду заварю чай и восстановлю его из говна и палок за три часа». Настоящий амбассадор боли: сначала сам создает себе проблемы (удаляя диски в k8s, «потому что так интереснее»), а потом героически их решает, попутно поучая всех в телеграме, что «кроилово ведет к попадалову».
Его отношения со StarRocks похожи на стокгольмский синдром. База выдает ему ошибки месячной давности, падает при двух одновременных запросах и скрывает настройки в закрытом коде, но Стас нежно называет её «восходящей звездой» и получает за это значки. Видимо, после работы с Вертикой и Кассандрой любой софт, который не плюет тебе в лицо сразу при запуске, кажется божественным.
А этот пассаж про «лидера команды из двух человек»? Стас, это не команда, это ты и твое отражение в мониторе, которое кивает, когда ты в очередной раз решаешь переписать всё на Go. Ты жалуешься, что от тебя убегают на конференциях с криками «опять про Старрокс», но при этом заводишь группу в ТГ, чтобы догнать тех, кто не успел убежать. Твое «брюзжание старпера» уже достигло такого уровня, что скоро ты начнешь сравнивать время отклика БД с очередями за колбасой в 80-х.
И вишенка на торте: использование AI для написания документации, потому что «самому лень», но при этом критика Slack за плохой API. Чувак, ты буквально работаешь в индустрии, где «всё сломано», и твоя главная суперсила — это умение с умным видом объяснить, почему оно сломано именно так. Но мы тебя любим за то, что ты хотя бы форкаешь адаптеры, пока остальные просто плачут в Jira.
🤣9❤5🔥2
Вот и получилось ожидаемо (или релизные истории StarRocks)
Версия 3.5 стала stable, 3.4 пропущена и никому не нужна... Когда практика опровергает слова.
Версия 3.5 стала stable, 3.4 пропущена и никому не нужна... Когда практика опровергает слова.
❤3👍2🤩2
Ехал метастор через метастор, видит метастор в метасторе метастор...
Одни очень большие ребята рассказали, что активно смотрят на Apache Gravitino. Плохого же не посоветуют, вот и я решил посмотреть.
А получается у нас на руках каталог каталогов, через который можно управлять метаданными во всем своем зоопарке. Имея на руках HDFS+Spark, StarRocks, Vertica (jdbc) и MySQL, можно из одного места раскатывать миграшки, управлять доступами и даже работать (если есть коннектор). Интересно как реализован линейдж, но мне кажется, что это не совсем тема каталога.
Идея интересная, наверное для больших ребят напрашивается. У нас сейчас 4 сервиса управления доступами (причем довольно разных), только миграции раскатываются через один сервис и однотипно. Аудит - не уверен что в этой штуке реализован корректно.
Подумал, что можно наконец выкинуть из стека Apache Ranger, но нет - это только прослойка для него.
Очень неоднозначная штука, на мой взгляд, и профит от нее для платформы надо внимательно рассматривать под микроскопом.
Видите пльзу для себя, затеялись бы внедрять? :)
Одни очень большие ребята рассказали, что активно смотрят на Apache Gravitino. Плохого же не посоветуют, вот и я решил посмотреть.
А получается у нас на руках каталог каталогов, через который можно управлять метаданными во всем своем зоопарке. Имея на руках HDFS+Spark, StarRocks, Vertica (jdbc) и MySQL, можно из одного места раскатывать миграшки, управлять доступами и даже работать (если есть коннектор). Интересно как реализован линейдж, но мне кажется, что это не совсем тема каталога.
Идея интересная, наверное для больших ребят напрашивается. У нас сейчас 4 сервиса управления доступами (причем довольно разных), только миграции раскатываются через один сервис и однотипно. Аудит - не уверен что в этой штуке реализован корректно.
Подумал, что можно наконец выкинуть из стека Apache Ranger, но нет - это только прослойка для него.
Очень неоднозначная штука, на мой взгляд, и профит от нее для платформы надо внимательно рассматривать под микроскопом.
Видите пльзу для себя, затеялись бы внедрять? :)
👍6
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
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
Google Docs
Community Evangelist Application
We are looking for technical experts passionate about OLAP technologies to build a stronger developer community together. Selected candidates will receive multiple exclusive benefits!
Application Deadline: January 23
Feedback provided by January 30
Application Deadline: January 23
Feedback provided by January 30
🔥12
Не все JDBC одинаково полезны
Перед Новым годом ребятам захотелось подключить вертику к старроксу, чтобы облегчить миграцию ядра dwh. Сверки делать стало бы легко, часть витрин можно было бы просто проксировать до момента материализации (тем более кажется, что в случае вертики запросы бы работали куда лучше обращений в oltp базки).
Конечно, же - документация всегда устаревает и всегда неполная. То, что выглядело задачкой на пару минут закончилось картинкой выше.
В теории, написать свой адаптер - дело часа, там 150+ строчек жабки для реализации этой абстракции.
Но есть целая пачка против:
* написать быстро, собрать и дебажить долго (уже пара дней)
* ждать момента включения в текущий апстрим около месяца (а это же фича, а не баг, поэтому немаловероятно, что в стейбл может и не попасть)
* это время ждать или жить на форке - смотри пункт первый про свою сборку
* включат ли вообще этот код в апстрим? Я бы не включал - какой смысл тратить время на поддержку БД, которая полутора ногами в могиле
* и самое интересное для меня - а почему я должен тратить свое время и время своей компании на реализацию поддержки какой-то вендорской бд (которая судя по адаптеру дбт близка к наплевательству на своих пользователей)?
С нашим размером вертики проще каждое обновление сливать паркетный дамп в хадуп и оттуда читать напрямую в СР.
А вы бы как поступили? :)
Перед Новым годом ребятам захотелось подключить вертику к старроксу, чтобы облегчить миграцию ядра dwh. Сверки делать стало бы легко, часть витрин можно было бы просто проксировать до момента материализации (тем более кажется, что в случае вертики запросы бы работали куда лучше обращений в oltp базки).
Конечно, же - документация всегда устаревает и всегда неполная. То, что выглядело задачкой на пару минут закончилось картинкой выше.
В теории, написать свой адаптер - дело часа, там 150+ строчек жабки для реализации этой абстракции.
Но есть целая пачка против:
* написать быстро, собрать и дебажить долго (уже пара дней)
* ждать момента включения в текущий апстрим около месяца (а это же фича, а не баг, поэтому немаловероятно, что в стейбл может и не попасть)
* это время ждать или жить на форке - смотри пункт первый про свою сборку
* включат ли вообще этот код в апстрим? Я бы не включал - какой смысл тратить время на поддержку БД, которая полутора ногами в могиле
* и самое интересное для меня - а почему я должен тратить свое время и время своей компании на реализацию поддержки какой-то вендорской бд (которая судя по адаптеру дбт близка к наплевательству на своих пользователей)?
С нашим размером вертики проще каждое обновление сливать паркетный дамп в хадуп и оттуда читать напрямую в СР.
А вы бы как поступили? :)
🔥3
Русскоязычный рынок признан перспективным
1 пост назад я скидывал вакансию на чемпиона от мира StarRocks, и это было признанием, что компания готова вкладывать в развитие своего продукта на нашем рынке. А теперь можно поделиться каналом официального представителя, которого можно будет мучить и спрашивать "почему так?...", да еще немножко управлять ожиданиями - https://news.1rj.ru/str/starrocks_selena
И сразу же хороший пост про роадмап на этот год, который я тоже хотел сделать.
Это что же, можно теперь расслабиться и доставать ведерко с попкорном?.. Мечты, мечты :)
1 пост назад я скидывал вакансию на чемпиона от мира StarRocks, и это было признанием, что компания готова вкладывать в развитие своего продукта на нашем рынке. А теперь можно поделиться каналом официального представителя, которого можно будет мучить и спрашивать "почему так?...", да еще немножко управлять ожиданиями - https://news.1rj.ru/str/starrocks_selena
И сразу же хороший пост про роадмап на этот год, который я тоже хотел сделать.
Это что же, можно теперь расслабиться и доставать ведерко с попкорном?.. Мечты, мечты :)
❤2
Презентация прошла неуспешно - Apache Paimon
Первый блин вышел комом - данные стали занимать в 2 раза больше места, чем в чистом паркете. И запросы стали выполняться в 2-4 раза медленнее, чем на чистом паркете. А запрос на удаление занимает столько же времени, сколько пересоздать партицию целиком. Речь про спарк, если что, до СР еще не дошли.
Похоже так просто его не взять :)
Первый блин вышел комом - данные стали занимать в 2 раза больше места, чем в чистом паркете. И запросы стали выполняться в 2-4 раза медленнее, чем на чистом паркете. А запрос на удаление занимает столько же времени, сколько пересоздать партицию целиком. Речь про спарк, если что, до СР еще не дошли.
Похоже так просто его не взять :)
😱6❤5✍2
Снаряд два раза в одну воронку не падает
Интересно, что у архитектора данных вышел цикл постов о том, почему стоит ехать в облако. А тем временем в нашей вселенной идет все ускоряющийся цикл ухода от облачной инфраструктуры во внутреннюю платформу данных чисто на реализовавшихся рисках (деньги смысла считать даже нет, стоимость рисков с лихвой покрывает всё).
Про что речь? В своем докладе что на смартдате, что в остальных местах я рассказывал про блокировку аккаунта в Google BigQuery в прошлом году на время уточнения данных, и заняло это 3 недели. Что случилось 2 недели назад? Да, аккаунт опять заблокировали, опять уточнение, ну а работа - потерпите, чай не сахарные. И следом уже вчера заблокировали целый пул ip адресов европейских цодов из стран вокруг РФ - запрет на использование api своих сервисов (BQ, GCP). То есть ты находишься не в РФ, платишь не с РФ, но никого не волнует.
Итого последние 3 недели мы перевозим проекты в StarRocks днем и ночью. Но почему-то получилось, что вместо расчета их там все заехало в Spark. Причина достаточно простая - наши эксперименты с бигквери проходили на проектах малого размера, почти все модели в dbt считались на table материализации. Spark такие штуки раскладывает примерно за 10-15 секунд на витринку, нагружать же mpp бд такого рода нагрузкой кажется напрасной затеей. Ведь в чем всегда была притензия к данным в хадупе - медленное чтение, а вот витринки собираются порой быстрее вертики (да что там, кликхауз у меня тоже получалось когда-то в телекоме обогнать). В итоге пользователи, биай и сервисы читают и делают эдхоки через StarRocks, а счет идет в кластере хадупа - все по заветам современных историй лейкхаузов, правда без перекладывания данных в слой доступа.
Ну а какие выводы можно сделать за эти 2 недели? А вот такие:
* перевозить витрины можно очень быстро
* сверять результаты между системами - чудовищная по трудоемкости операция
* витрины начинают разбегаться между системами буквально на следующей недели после переноса - надо или следить, или очень быстро ехать
Даже если функции выглядят в двух системах похоже (именуются одинаково), то совсем не факт что их аргументы или возвращаемые результаты будут идентичными. И поверх накладывается проблема вскрывания ошибок во время написания витрин в исходной системе, когда мы вынуждены или переносить расчет данных и найденную ошибку, либо мы теряем возможность построчной сверки :(
Вообщем печаль, беда и разорение. Если кто знает уже готовый тулсет для сверки таблиц построчно-поколоночно на спарке - напишите в комментарии, пожалуйста. Написать свой вроде несложно, но вдруг древние уже учли все проблемы. Почему spark? Потому что можно в нем внутри сравнивать разные системы без материализации и копирования данных, а еще легко сделать select sha1(*) from...
Интересно, что у архитектора данных вышел цикл постов о том, почему стоит ехать в облако. А тем временем в нашей вселенной идет все ускоряющийся цикл ухода от облачной инфраструктуры во внутреннюю платформу данных чисто на реализовавшихся рисках (деньги смысла считать даже нет, стоимость рисков с лихвой покрывает всё).
Про что речь? В своем докладе что на смартдате, что в остальных местах я рассказывал про блокировку аккаунта в Google BigQuery в прошлом году на время уточнения данных, и заняло это 3 недели. Что случилось 2 недели назад? Да, аккаунт опять заблокировали, опять уточнение, ну а работа - потерпите, чай не сахарные. И следом уже вчера заблокировали целый пул ip адресов европейских цодов из стран вокруг РФ - запрет на использование api своих сервисов (BQ, GCP). То есть ты находишься не в РФ, платишь не с РФ, но никого не волнует.
Итого последние 3 недели мы перевозим проекты в StarRocks днем и ночью. Но почему-то получилось, что вместо расчета их там все заехало в Spark. Причина достаточно простая - наши эксперименты с бигквери проходили на проектах малого размера, почти все модели в dbt считались на table материализации. Spark такие штуки раскладывает примерно за 10-15 секунд на витринку, нагружать же mpp бд такого рода нагрузкой кажется напрасной затеей. Ведь в чем всегда была притензия к данным в хадупе - медленное чтение, а вот витринки собираются порой быстрее вертики (да что там, кликхауз у меня тоже получалось когда-то в телекоме обогнать). В итоге пользователи, биай и сервисы читают и делают эдхоки через StarRocks, а счет идет в кластере хадупа - все по заветам современных историй лейкхаузов, правда без перекладывания данных в слой доступа.
Ну а какие выводы можно сделать за эти 2 недели? А вот такие:
* перевозить витрины можно очень быстро
* сверять результаты между системами - чудовищная по трудоемкости операция
* витрины начинают разбегаться между системами буквально на следующей недели после переноса - надо или следить, или очень быстро ехать
Даже если функции выглядят в двух системах похоже (именуются одинаково), то совсем не факт что их аргументы или возвращаемые результаты будут идентичными. И поверх накладывается проблема вскрывания ошибок во время написания витрин в исходной системе, когда мы вынуждены или переносить расчет данных и найденную ошибку, либо мы теряем возможность построчной сверки :(
Вообщем печаль, беда и разорение. Если кто знает уже готовый тулсет для сверки таблиц построчно-поколоночно на спарке - напишите в комментарии, пожалуйста. Написать свой вроде несложно, но вдруг древние уже учли все проблемы. Почему spark? Потому что можно в нем внутри сравнивать разные системы без материализации и копирования данных, а еще легко сделать select sha1(*) from...
❤10
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 теперь напоминает гошку - и в принципе, я это считаю за комплимент :)
А у вас на прикроватной тумбочке что есть интересного? :)
Перемещаемся в наше время. Мне для какой-то очень простой апишки надо ограничить отправку данных в нее с нашей стороны - то есть добавить этот самый rate limiter. Скучная работа - добавить зависимостей, поменять 1 строчку в коде и накинуть тестов. А что у нас есть для скучной работы? Cursor! Хей, Cursor, добавь rate limiter вот тут для requests.post с ограничением в 100 запросов в секунду и сделай под этот функционал тестов. Было странно видеть, что в этом же файле появился новый класс с своей самописной реализацией лимитера (да еще и бажной). Если кто не знает, то есть обертка requests-ratelimiter, с которой вместо Session из requests просто используем LimiterSession. Поправили и забыли.
Но вот что кажется забавным - в python и правда очень любят писать свои велосипеды. Язык настолько простой, то прямо располагает к этому. Зачем читать чужую библиотеку, когда я и сам могу написать не хуже (вспоминая собес, ну, после 5 итерации наверное). Если llm натренирована на той куче кода в гитхабе, то и выдает она вполне Pythonic решение :)
А к чему это фото, подумаете вы? Просто для прочистки мозгов и улучшения вашего python кода очень советую почитать (а может даже и пописать) код на golang. Мне коллега как-то сказал, что мой код на python теперь напоминает гошку - и в принципе, я это считаю за комплимент :)
А у вас на прикроватной тумбочке что есть интересного? :)
❤4👍4
DE больше не нужны
Последнюю неделю все чаты обсуждают пост Димы Аношина про то, как злые бриксы выпиливают возможности ковыряться в техничке дата инженерам.
Но для меня история с обязанностями де остается не очень понятной, и скорее всего виной всему наши (да и не только наши) бигтехи. На рынке сейчас есть только одна возможность выжить - очень быстро доставлять. Доставлять фичи, доставлять решения, зарезать неверные решения (если мы говорим про аналитику). А теперь смотрим на картинку выше - сколько времени займет доставка из этого классного кружка? :)
Начиная с какого-то уровня люди внутри компании (заказчики, бизнес) становятся более требовательными к качеству продуктов (визуал бордов, скорость и надежность поставки) - и вот появляется история с специализацией. На картинке не хватает еще BI инженера с BI аналитиком :)
Скорость доставки снижается, часть проблем утопает на стыках специалистов, но все становится красиво и качественно.
И вот тут каждая компания начинает ловить баланс - сколько кого им надо, в зависимости от потребностей, баланса, эго руководителей.
Дальше я вижу проблему в триаде аналитик данных - аналитик-инженер - инженер данных. Эти три роли примерно про одно и тоже, но стоят последовательно на спектре задач от технички до бизнеса. И при этом имеют два ограничения - домен данных и отсутствие масштабирования результатов труда. То есть в голову больше ограниченного объема бизнеса не получить, и витринки под каждого заказчика становятся все глубже и детальней. Техничка для инженеров не является никаким ограничением - ну камон, научиться использовать партиции в спарке, джойнить по ключам в постгрессе, использовать файнал в кликхаузе, ну не большая же наука?
Заканчивая мысль, рынок будет стремиться сократить ТТМ аналитических решений за счет сдвига людей в сторону бизнеса, что и приводит к смерти профессии инженера данных.
Ну а если хочется остаться в техничке - это путь в платформенные команды или чистую разработку (как те же мл-ребята).
PS перечитал и увидел, что не раскрыл историю с бигтехами. Быть повелителями yml != инженером данных. Очень странно слышать про то, как угнетающе писать ямлы в Т, озоне и еще где-то, но при этом не мочь сказать ни слова про бизнес домен, в котором работаешь. В чем тогда состоит работа? Быть живым курсором?..
PPS никогда не работал в бигтехах :) и вообще сегодня пятница
Последнюю неделю все чаты обсуждают пост Димы Аношина про то, как злые бриксы выпиливают возможности ковыряться в техничке дата инженерам.
Но для меня история с обязанностями де остается не очень понятной, и скорее всего виной всему наши (да и не только наши) бигтехи. На рынке сейчас есть только одна возможность выжить - очень быстро доставлять. Доставлять фичи, доставлять решения, зарезать неверные решения (если мы говорим про аналитику). А теперь смотрим на картинку выше - сколько времени займет доставка из этого классного кружка? :)
Начиная с какого-то уровня люди внутри компании (заказчики, бизнес) становятся более требовательными к качеству продуктов (визуал бордов, скорость и надежность поставки) - и вот появляется история с специализацией. На картинке не хватает еще BI инженера с BI аналитиком :)
Скорость доставки снижается, часть проблем утопает на стыках специалистов, но все становится красиво и качественно.
И вот тут каждая компания начинает ловить баланс - сколько кого им надо, в зависимости от потребностей, баланса, эго руководителей.
Дальше я вижу проблему в триаде аналитик данных - аналитик-инженер - инженер данных. Эти три роли примерно про одно и тоже, но стоят последовательно на спектре задач от технички до бизнеса. И при этом имеют два ограничения - домен данных и отсутствие масштабирования результатов труда. То есть в голову больше ограниченного объема бизнеса не получить, и витринки под каждого заказчика становятся все глубже и детальней. Техничка для инженеров не является никаким ограничением - ну камон, научиться использовать партиции в спарке, джойнить по ключам в постгрессе, использовать файнал в кликхаузе, ну не большая же наука?
Заканчивая мысль, рынок будет стремиться сократить ТТМ аналитических решений за счет сдвига людей в сторону бизнеса, что и приводит к смерти профессии инженера данных.
Ну а если хочется остаться в техничке - это путь в платформенные команды или чистую разработку (как те же мл-ребята).
PS перечитал и увидел, что не раскрыл историю с бигтехами. Быть повелителями yml != инженером данных. Очень странно слышать про то, как угнетающе писать ямлы в Т, озоне и еще где-то, но при этом не мочь сказать ни слова про бизнес домен, в котором работаешь. В чем тогда состоит работа? Быть живым курсором?..
PPS никогда не работал в бигтехах :) и вообще сегодня пятница
🤔5👍4❤2🔥2
Любовь к переопределению стандартных настроек
Не знаю с чем связано непреодолимое желание определить свои настройки и забивать на стандартные практики в индустрии. Дам два примера:
* Apache Paimon и его ишью. Кратко: ваши желания в hdfs-site.xml - это ваши проблемы, а писать файлы мы всегда будем с фактором репликации 1. Доросли до версии 1.3, но исправление есть только в мастере.
* dbt-starrocks и его настройки адаптера по умолчанию. Что вы там на уровне кластера задали - ваши проблемы, все новые модели мы будем сохранять с фактором репликации 1.
Очень-очень сильно такие вещи вымораживают, когда ты однажды остаешься без данных из-за мигнувшей ноды.
Не знаю с чем связано непреодолимое желание определить свои настройки и забивать на стандартные практики в индустрии. Дам два примера:
* Apache Paimon и его ишью. Кратко: ваши желания в hdfs-site.xml - это ваши проблемы, а писать файлы мы всегда будем с фактором репликации 1. Доросли до версии 1.3, но исправление есть только в мастере.
* dbt-starrocks и его настройки адаптера по умолчанию. Что вы там на уровне кластера задали - ваши проблемы, все новые модели мы будем сохранять с фактором репликации 1.
Очень-очень сильно такие вещи вымораживают, когда ты однажды остаешься без данных из-за мигнувшей ноды.
👍4❤2🌚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 легко мигрировать за счет стандартных 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) и ретрай всегда заканчивается успехом. И затронуты не все прилы.
Нипанятна :(
😁4😱4❤3