https://habr.com/ru/articles/942388/#comment_28779546 За 10 лет на GitHub у меня скопилось огромное количество кода. И почему я вдруг, следуя какой-то новой моде, должен разбирать, какой код мне нужен, а какой - нет? Мой GitHub - это история моего пути, он помогает увидеть, как я рос и совершенствовал свои навыки.
А теперь находится какой-то чел, который решил, что я должен навести там порядок по его личным стандартам.
https://habr.com/ru/companies/habr_career/articles/868400/ Однако намного чаще можно увидеть обратную картину: по ссылке на гитхаб из резюме никто не переходит, а если и переходит, то что люди могут там увидеть? HRы не смогут посмотреть код и оценить технические решения, они даже не смогут оценить, в какие проекты человек делал вклад: связаны ли они вообще со стеком текущего проекта в компании? Тимлиды тоже не заходят, потому что для того, чтобы нормально посмотреть проекты, нужно много времени, нужно вчитаться, вдуматься. А времени нет. Обычно все читают резюме прямо перед собеседованием.
В целом на собеседовании будут оценивать совсем другие вещи: алгоритмы, систем дизайн, culture fit.
Или может подумать хотя бы 5 сек и задаться вопросом: а нафига HR-у разработчик который вместо того чтобы пилить полезность своим бывшим работодателям в их закрытые gitlab-ы - тратит уйму времени и внимания на сторонний код?
Ваш github - это минус на рынке и в резюме, а не плюс
С Hive Metastore (HMS) отдельная история: для нас это откровенный legacy. Он делает массу лишней работы. Например, постоянно листит файлы в Ceph, хотя это уже сделал Trino и просто просит у каталога метаданные
Не могли бы вы раскрыть поподробнее этот момент плиз?
С какой целью Trino листит S3, если это уже делает HMS?
Если Trino пролистил файлы S3 - зачем он лезет в HMS?
Зачем HMS листит файлы S3?
По пунктам отвечать не обязательно, вероятно я вообще не понял архитектуру взаимодействия. Непонятно как производится ваше взаимодействие с каталогом. Информация в интернетах очень мутная по каталогам, их видам и тому, что они делают. Нейросетки соответственно тоже шизу выдают
Еще вопрос появился - у вас указана обычная репликация в посте, ни слова не вижу про erasure coding - ключевую фишку S3 и например Minio, в Ceph судя по всему тоже доступна эта опция (хотя ее не было изначально, судя по прочитанным мной материалам).
Да понятно что сейчас почти все (позиционирующие себя как) современные СУБД имеют какие-то интеграции с S3... и это утверждение (про частичную работу StarRocks с S3) упирается в другой упомянутый мною минус: молодость продукта StarRocks. Да и его (StarRocks) развивают в первую очередь какие-то непонятные китайцы (поправите?), а не Амазоны/Гуглы/etc...
Да и в принципе не понятно, если есть S3, на который и движки ориентируются (Impala/Trino/Spark/подобное) и кликхаусы переходят - зачем жечь время+деньги на проработку локального хранилища? Такое распыление ресурсов - явно бонусом к продукту не идет.
Я вот смотрю на тот же кликхаус, он там с 2009 разрабатывается (почти 2026 на дворе, 17 лет!), а столько всего в нем еще не сделано...
Никакого процедурного PL/SQL
на долгом запросе после потери связи с хостом-источников - продолжает выполнять долгий запрос (ну по ошибке в их http/play интерфейсе отправил огромный запрос - если вручную не убить через KILL - запрос будет работать почти до последнего, оборвется только на переходе со стадии подзапроса SELECT на стадию INSERT)
Оптимизатор запросов на уровне детского сада
И много чего еще там нет...
И в качестве «бонуса» - не выкатывают в open-source SharedMergeTree
Я вот уверен что у StarRocks подобных болезней молодой СУБД тоже будет хоть отбавляй. Еще в качестве не блокирующей, но занозы: разработчики-китайцы... Захочешь в код глянуть - привет иероглифы, будут 146%... Движок типа Impala хотя бы c 2013 года развивается, и он не палит ресурсы на развитие своего хранилища-велосипеда. Лично собеседовался пару месяцев назад на проект, где собирались использовать именно StarRocks... Я бы лично не решился сейчас на нем пилить продуктивное хранилище данных.
Критика решения Авито интересная, но все-таки хотелось бы поменьше перехода на личности в их адрес, пожалуйста, а то щас быстро в срач свалится, а мне при проектировании хотелось бы узнать и учесть как можно больше нюансов...
Мы просто сейчас сами выбираем движок, поэтому так докапываюсь. Минусы Java - это не предубеждения, у нее есть масса фундаментальной проблематики которая мешает написанию качественного низкоуровневого движка/СУБД: проблемы интеграции assembler, кривая интеграция SIMD, перегруз ООП-стактрейсом, да и вообще от этого языка не просто так отпочковались Scala/Kotlin, и прочая проблематика связанная с JVM/Heap-memory и пр.
Я вот не так давно анализировал in-memory-databases и на их примерах вижу, что валовая часть хороших продуктов написана на C/C++ и еще Rust набирает популярность сейчас. Садиться на движок который фундаментально сделан на кривом ЯП - ну такое себе.
Если у Impala есть критические минусы над Trino - я бы очень хотел о них знать.
(то что трино быстрее вертики - это скорее камень в сторону вертики, чем бонус в сторону трино)
Ну, минус StarRocks мне понятен - современный подход - это S3 + Engine, а старрокс это СУБД которой года 4 (слишком молодая) да еще и основанный на устаревшем подходе локального хранения, от которого уже и ClickHouse открестился (см ClickHouse Cloud - причем в открытый доступ SharedMergeTree эти «добрые» люди не выкатили)
Но я также спросил у вас, почему вы (например в вашей прошлой статье: https://habr.com/ru/companies/avito/articles/979836/) вообще не анализировали Impala? Без Impala бенчмарк совсем непоказательный выходит (имхо)
Почему именно Trino? Не вижу (Spark вижу, даже StarRocks вижу) в ваших материалАХ обзора Impala (вычислительная часть которой на быстрых сях в отличии от более медленной trino-джавы)?
Что за гиперкубы? У вас не описано, в интернете не гуглится (не вижу)
Для join-ов подходит кликхаус да? Вы на нем еще посоветуйте Anchor Model реализовать Я прочитал сотни различных статей, документации и материалов - и впервые подобную чушь встретил за все время
Резкое пятно на всей статье за такое высказывание.
Потратить 5 минут чтобы почитать хоть что-нибудь по теме?
Или может подумать хотя бы 5 сек и задаться вопросом: а нафига HR-у разработчик который вместо того чтобы пилить полезность своим бывшим работодателям в их закрытые gitlab-ы - тратит уйму времени и внимания на сторонний код?
Ваш github - это минус на рынке и в резюме, а не плюс
Не могли бы вы раскрыть поподробнее этот момент плиз?
С какой целью Trino листит S3, если это уже делает HMS?
Если Trino пролистил файлы S3 - зачем он лезет в HMS?
Зачем HMS листит файлы S3?
По пунктам отвечать не обязательно, вероятно я вообще не понял архитектуру взаимодействия. Непонятно как производится ваше взаимодействие с каталогом. Информация в интернетах очень мутная по каталогам, их видам и тому, что они делают. Нейросетки соответственно тоже шизу выдают
Еще вопрос появился - у вас указана обычная репликация в посте, ни слова не вижу про erasure coding - ключевую фишку S3 и например Minio, в Ceph судя по всему тоже доступна эта опция (хотя ее не было изначально, судя по прочитанным мной материалам).
Вы используете erasure coding в своем Ceph?
В очередной раз обжевывание везде обжеванного трюизма про «все проблемы родом из детства»?
Ну прям открытие грааля, не иначе
Да понятно что сейчас почти все (позиционирующие себя как) современные СУБД имеют какие-то интеграции с S3... и это утверждение (про частичную работу StarRocks с S3) упирается в другой упомянутый мною минус: молодость продукта StarRocks. Да и его (StarRocks) развивают в первую очередь какие-то непонятные китайцы (поправите?), а не Амазоны/Гуглы/etc...
Да и в принципе не понятно, если есть S3, на который и движки ориентируются (Impala/Trino/Spark/подобное) и кликхаусы переходят - зачем жечь время+деньги на проработку локального хранилища? Такое распыление ресурсов - явно бонусом к продукту не идет.
Я вот смотрю на тот же кликхаус, он там с 2009 разрабатывается (почти 2026 на дворе, 17 лет!), а столько всего в нем еще не сделано...
Никакого процедурного PL/SQL
на долгом запросе после потери связи с хостом-источников - продолжает выполнять долгий запрос (ну по ошибке в их http/play интерфейсе отправил огромный запрос - если вручную не убить через KILL - запрос будет работать почти до последнего, оборвется только на переходе со стадии подзапроса SELECT на стадию INSERT)
Оптимизатор запросов на уровне детского сада
И много чего еще там нет...
И в качестве «бонуса» - не выкатывают в open-source SharedMergeTree
Я вот уверен что у StarRocks подобных болезней молодой СУБД тоже будет хоть отбавляй. Еще в качестве не блокирующей, но занозы: разработчики-китайцы... Захочешь в код глянуть - привет иероглифы, будут 146%...
Движок типа Impala хотя бы c 2013 года развивается, и он не палит ресурсы на развитие своего хранилища-велосипеда.
Лично собеседовался пару месяцев назад на проект, где собирались использовать именно StarRocks... Я бы лично не решился сейчас на нем пилить продуктивное хранилище данных.
P.S.: Спасибо за ссылку!
Критика решения Авито интересная, но все-таки хотелось бы поменьше перехода на личности в их адрес, пожалуйста, а то щас быстро в срач свалится, а мне при проектировании хотелось бы узнать и учесть как можно больше нюансов...
Почему Ceph, а не Minio выбран (мб другие on-premise варианты перебирали, SeaweedFS например)? Было бы полезно узнать
Про бенчмарки я согласен, что это не панацея, спору нет, я поэтому сейчас «прикопался» к вам)
Вот очень интересно, чем именно не подошла Impala:
Не современная?
Не активно применяется в мировых бигтехах?
Не можете развивать своими силами? (Почему?)
Может вы просто не подумали об Impala на тот момент - это вполне понятная история. ClickHouse в свое время вот не подумали об HDFS/S3 (https://habr.com/ru/articles/509540/) и собрали свой велосипед-локальное-хранилище с ReplicatedMergeTree (в последствии уперлись в потолок и перешли на S3: https://clickhouse.com/blog/clickhouse-cloud-boosts-performance-with-sharedmergetree-and-lightweight-updates)
Мы просто сейчас сами выбираем движок, поэтому так докапываюсь. Минусы Java - это не предубеждения, у нее есть масса фундаментальной проблематики которая мешает написанию качественного низкоуровневого движка/СУБД: проблемы интеграции assembler, кривая интеграция SIMD, перегруз ООП-стактрейсом, да и вообще от этого языка не просто так отпочковались Scala/Kotlin, и прочая проблематика связанная с JVM/Heap-memory и пр.
Я вот не так давно анализировал in-memory-databases и на их примерах вижу, что валовая часть хороших продуктов написана на C/C++ и еще Rust набирает популярность сейчас. Садиться на движок который фундаментально сделан на кривом ЯП - ну такое себе.
Если у Impala есть критические минусы над Trino - я бы очень хотел о них знать.
Вот примеры статей с бенчмарками: trino (имхо ожидаемо) самый медленный из ряда вариантов включающих StarRocks, Impala, Spark:
https://habr.com/ru/companies/datasapience/articles/959496/
https://habr.com/ru/companies/datasapience/articles/866862/
(то что трино быстрее вертики - это скорее камень в сторону вертики, чем бонус в сторону трино)
Ну, минус StarRocks мне понятен - современный подход - это S3 + Engine, а старрокс это СУБД которой года 4 (слишком молодая) да еще и основанный на устаревшем подходе локального хранения, от которого уже и ClickHouse открестился (см ClickHouse Cloud - причем в открытый доступ SharedMergeTree эти «добрые» люди не выкатили)
Но я также спросил у вас, почему вы (например в вашей прошлой статье: https://habr.com/ru/companies/avito/articles/979836/) вообще не анализировали Impala? Без Impala бенчмарк совсем непоказательный выходит (имхо)
Добрый день, заинтересовало 2 момента:
Почему именно Trino? Не вижу (Spark вижу, даже StarRocks вижу) в ваших материалАХ обзора Impala (вычислительная часть которой на быстрых сях в отличии от более медленной trino-джавы)?
Что за гиперкубы? У вас не описано, в интернете не гуглится (не вижу)
После этой фразы прекратил чтение.
Для join-ов подходит кликхаус да? Вы на нем еще посоветуйте Anchor Model реализовать
Я прочитал сотни различных статей, документации и материалов - и впервые подобную чушь встретил за все время
Резкое пятно на всей статье за такое высказывание.
Можете плиз картинку архитектуры перезалить в нормальном качестве - текста вообще не видно в квадратах, ничего не понятно