Comments 22
Добрый день! Это равнозначные термины. На практике в части PostgreSQL чаще используют понятие секционирование, а в части Apache Hive – партиционирование. В статье указано, что партиционирование еще может называться секционированием.
Слова не было, а люди взяли и придумали и добавили и в чем они не правы?
да индеферентно. главное чтобы смысл был понятен. Ведь все же понимаю что в русском язызке слово лог - это овраг, но применяют его повсеместно, забывая про слово журнал.
Хорошо бы указать источник картики со сравнением размера - она кочует последние года 3 из статьи в статью у кучи авторов
Да, хотелось бы уже понимать кто такую ерунду на картинку вынес, а все вставляют, не проверяя :)
В русскоязычном интернете это пошло по-моему отсюда https://bigdataschool.ru/blog/row-vs-column-file-format-big-data.html
А вообще вроде это вроде из блога Клаудеры от 2013(!!!) года - https://blog.cloudera.com/orcfile-in-hdp-2-better-compression-better-performance/
Минусы:
Ограничение по количеству партиций: не рекомендуется использовать более 10 тысяч партиций, что может привести к сильному замедлению работы кластера;
А вы попробуйте создать более 10 тыс партиций в постгресе. Вот когда вы это сделаете, и померяете, тогда будет реально ясно, что лучше.
А пока... вы ведь понимаете, что партиция в Hive хранится по сути в памяти namenode? Потому что это просто папка, и у нее нет никаких других свойств при выполнении запроса (на самом деле они есть в метасторе, но с точки зрения where есть только имя). А значит большое число партиций - это большой объем памяти namenode, с понятными последствиями.
P.S. Вот, кстати:
Before PostgreSQL 12, performance could be affected by too many table partitions, and it was recommended to have 100 or less partitions. But as of version 12, partitioning performance has been greatly improved, so that even thousands of partitions can be processed efficiently.
Т.е. до версии 12, у постгреса тоже было 100 и менее партиций. А теперь тысячи могут быть эффективно обработаны. Так что если если 10 тыс партиций в Hive просто не рекомендуется - так это понятно, но в сравнении с это далеко не недостаток, и скорее всего постгресу на таком же количестве тоже будет плоховато без тюнинга.
Мы уже много раз упирались в такие ограничения хадупа, как миллион файлов в папке (можно обойти). На реально больших данных во что только не упираешься. Так что я бы сказал, что некое ограничение на уровне где-то миллиона партиций должно существовать, но наткнутся на него очень и очень немногие.
Вечная проблема с этим: или спарк надо кормить ресами или куча мелких файлов 🤷♂️ и неймнода будет тупить...
По поводу рекмендаций кстати интересный момент. Все просто цитируют рекомендацию с доки клаудеры, но редко кто проверял на деле. А на деле выясняется что не надо делать больше 3-5 тыс партиций.
Я вообще писал не совсем про это. Автор сравнивает два продукта, приводя как недостаток Hive, что не рекомендуется делать больше 10000 партиций. При этом не делается никакого сравнения, а как будет себя вести постгрес, если создать столько же.
Даже если заменить 10 на 3-5 - мало что изменится. Все равно это тот же порядок. Все равно чтобы реально сравнить - надо померять на своем количестве данных.
Ну тут сейчас можно уйти в длительную дискуссию на равномерность распределения данных по партициям, размер и кол-во файлов в каждой партиции или может даже использование равномерного bucket партицирования с применением формата iceberg. На деле все просто читают документацию и делают ctrl+c , ctrl+v, а по хорошему в HDFS ключ и гранулярность партицирования надо выбирать под минимальную перезапись при загрузке инкремента и это не всегда дата :)
В постгре скорее умрет словарь данных если там создать те самые thousands of partitions. Да и вообще, зачем там столько данных то иметь?
Да, и еще... в моем понимании Hive уже достаточно давно не использует MapReduce. Там TEZ, а это все-таки не совсем тоже самое, потому что выполняем мы не просто Map или Reduce задачи, а DAG.
а в моем понимании писать про Hive что бы он там не использовал в 2024г уже не стоит :)
У нас в нем примерно 30 петабайт данных. Почему нет?
Ну у вас не в Hive 30 Птб, а в HDFS 30 Птб (под Hive тут конечно имею ввиду не HMS, без которого не обойтись, а Hive как фреймворк обработки). Вопрос use case использования этих 30 Птб. Что с ними делают? Хранят как архив или как то процессят? Какой объем надо процессить и с каким SLA? Hive сам по себе очень медленный же, даже на Tez в тех сценариях где надо решить задачи конкурентно. Вполне может оказаться что Impala, Trino или SparkSQL с задачей справятся гораздо лучше.
Спарк там конечно занимает не последнее место, и да, конечно данные в HDFS (Hive уже очень давно умеет использовать спарк движок). В Hive только метаданные, грубо говоря, десятки тысяч схем, по моим оценкам. Отчеты строят. Для клиентов и регулятора. Не вижу никакой причины, почему Hive не может продолжать применяться для части задач. Ее все еще допиливают, и скажем нам бы очень бы хотелось иметь 4 версию - а приходится пока жить на 3.1.
Причины я опписал вышел - другие движки процессить данные могут лучше. Лучше - значит тратят времени и ресурсов меньше на решение точно такой же задачи. Кейс и объемы которые вы описываете - это сворее всего телеком, предположу что старая версия hortonworks даже. Чего вам хотеть и что ждать - ваш выбор исходя из вашей накопленной экспертизы конечно. Каждый кулик хвалит свое болото. Но, если предположить, что вы начинаете анлогичный проект в 2024г, то стали ли бы вы смотреть другие движки и фреймворки и сразу бы на Hive стали делать?
Мне одному глаза режет, когда Постгрес Postgre обзывают?
Формат хранения в HDFS надо выбирать не потому как данные сжимаются, следуя картинки непонятно кем опубликованной, а по тому как вы эти данные собираетесь использовать и каким движком или фреймворком будете пользоваться. Как собственно и кодек компрессии к этому формату.
Особенности партиционирования в PostgreSQL и Apache Hive