Если я хочу иметь возможность работать с Trino, Impala и Spark одновременно, то я свой паркет (в котором и двухуровневые индексы и возможонсть сортровать данные и общепринятые табличные расширения вроде iceberg\hudi тоже давно есть) на карбон не променяю.
В целом, когда выбираете формат данных нужно смотреть не на его фичи А понимать каким движком и для каких задач вы собираетесь его использовать. И какие возможности движок поддерживает на конкретном формате. А то потом выяснится что заявленная эволюция данных доступна не для всех dml операции
Мне кажется у автора очень слабое представление о возможностях паркет.
В Паркете есть storage индексы, страничные индексы, поддержка z standard compression. Acid расширение вам даёт худы, айсберг, или дельта-лейк над паркетом.
Из моей реальной практики флинк в паркет + айсберг удавалось добиться 40.000 изменений в секунду при онлайн вставке данных.
Да когда вы уже закончите то носиться с этим технологическим трупом по имени GreenPlum?
Тупикоя ветвь эволюции.
GP это: Дорогое хранение со специфическими требованиями к железу, медленный движок сам по себе (ни одной join оптимизации современной нет и не будет), технологические ограничения на масштабирование (и даже не изза мастера который тоже сам по себе тот еще ботлнек), не самое лучшее сжатие данных даже в колоночном формате, фиксированный паралелеризм обработки.
Самая дорогая операция с OLAP системах - физическое чтение или запись. Сжатие дает буст производительности как раз за счет того что кол-во физических чтений и записи уменьшается
Больше двух лет являюсь владельцем Lenovo Chrome book duet. Это планшет с подсоединяемой клавиатурой на ARM проце. Более выгодной покупки в своей жизни ещё ни разу не делал!
Причины я опписал вышел - другие движки процессить данные могут лучше. Лучше - значит тратят времени и ресурсов меньше на решение точно такой же задачи. Кейс и объемы которые вы описываете - это сворее всего телеком, предположу что старая версия hortonworks даже. Чего вам хотеть и что ждать - ваш выбор исходя из вашей накопленной экспертизы конечно. Каждый кулик хвалит свое болото. Но, если предположить, что вы начинаете анлогичный проект в 2024г, то стали ли бы вы смотреть другие движки и фреймворки и сразу бы на Hive стали делать?
Ну тут сейчас можно уйти в длительную дискуссию на равномерность распределения данных по партициям, размер и кол-во файлов в каждой партиции или может даже использование равномерного bucket партицирования с применением формата iceberg. На деле все просто читают документацию и делают ctrl+c , ctrl+v, а по хорошему в HDFS ключ и гранулярность партицирования надо выбирать под минимальную перезапись при загрузке инкремента и это не всегда дата :)
В постгре скорее умрет словарь данных если там создать те самые thousands of partitions. Да и вообще, зачем там столько данных то иметь?
По поводу рекмендаций кстати интересный момент. Все просто цитируют рекомендацию с доки клаудеры, но редко кто проверял на деле. А на деле выясняется что не надо делать больше 3-5 тыс партиций.
Ну у вас не в Hive 30 Птб, а в HDFS 30 Птб (под Hive тут конечно имею ввиду не HMS, без которого не обойтись, а Hive как фреймворк обработки). Вопрос use case использования этих 30 Птб. Что с ними делают? Хранят как архив или как то процессят? Какой объем надо процессить и с каким SLA? Hive сам по себе очень медленный же, даже на Tez в тех сценариях где надо решить задачи конкурентно. Вполне может оказаться что Impala, Trino или SparkSQL с задачей справятся гораздо лучше.
олды помнят что изначально DV разрабатывали не для "гибкости", а потому что в те годы СУБД и аппаратное обеспечение с трудом переваривали изменения. Идея DV была в том, чтобы атрибуты измерений разбивать по сателитам в зависимости от временной гранулярности изменений. Те, условно, те что загружаются\обновляются раз в час в одном сателите, те что раз в 4 часа в другом, раз в сутки в третьем. В теории это позволяло не обновлять длинную строку очень часто. С приходом эры MPP необходимость в таком подходе просто отпала.
К минусам якорной модели я бы добавил еще - очень выскую нагрузку на словарь данных. Посчитайте сколько у вас будет объектов если вы загрузите 10тыс таблиц источника по 30 атрибутов в каждом. Ведь ваш фреймворк загрузки будет работать со словарем данных очень интенсивно при таком подходе.
Есть две стадии DV. Первая - сделал и потом написал статью на хабре, добавил в резюме и рассказал на конференции. Вторая - охренел от и начал лепить витрины в обход DV. Правда "забыл" всем рассказать что ты забил на DV.
Плохо переводить то в чем сам не разбираешься. Разбирался\лась бы в предмете оригинальнйо статьи цитривать ее бы не стал\ла
Зазчем использовать AOnly если есть AOptimized? Сжатие от этого лучше не будет, а вот позможность обновления появится.
Если я хочу иметь возможность работать с Trino, Impala и Spark одновременно, то я свой паркет (в котором и двухуровневые индексы и возможонсть сортровать данные и общепринятые табличные расширения вроде iceberg\hudi тоже давно есть) на карбон не променяю.
В целом, когда выбираете формат данных нужно смотреть не на его фичи А понимать каким движком и для каких задач вы собираетесь его использовать. И какие возможности движок поддерживает на конкретном формате. А то потом выяснится что заявленная эволюция данных доступна не для всех dml операции
Мне кажется у автора очень слабое представление о возможностях паркет.
В Паркете есть storage индексы, страничные индексы, поддержка z standard compression. Acid расширение вам даёт худы, айсберг, или дельта-лейк над паркетом.
Из моей реальной практики флинк в паркет + айсберг удавалось добиться 40.000 изменений в секунду при онлайн вставке данных.
Да когда вы уже закончите то носиться с этим технологическим трупом по имени GreenPlum?
Тупикоя ветвь эволюции.
GP это: Дорогое хранение со специфическими требованиями к железу, медленный движок сам по себе (ни одной join оптимизации современной нет и не будет), технологические ограничения на масштабирование (и даже не изза мастера который тоже сам по себе тот еще ботлнек), не самое лучшее сжатие данных даже в колоночном формате, фиксированный паралелеризм обработки.
На сотни Тб он у них масштабируется. Ну-ну :)
Я вот написал много кода для советского аналога 8080 - КР580. Код писал на бумажке, переводил в нех а потом программатором вводил.
Так CH вообще штука сугубо специфическая не про join ни разу :)
а некоторые еще быстрее сделать в Impala чем в спарке и вертике :) причем местами на порядок
дешево? Вы просто платите за операции обновления тройную цену чтобы потом быстро выполнять операции join.
Самая дорогая операция с OLAP системах - физическое чтение или запись. Сжатие дает буст производительности как раз за счет того что кол-во физических чтений и записи уменьшается
Больше двух лет являюсь владельцем Lenovo Chrome book duet. Это планшет с подсоединяемой клавиатурой на ARM проце. Более выгодной покупки в своей жизни ещё ни разу не делал!
Причины я опписал вышел - другие движки процессить данные могут лучше. Лучше - значит тратят времени и ресурсов меньше на решение точно такой же задачи. Кейс и объемы которые вы описываете - это сворее всего телеком, предположу что старая версия hortonworks даже. Чего вам хотеть и что ждать - ваш выбор исходя из вашей накопленной экспертизы конечно. Каждый кулик хвалит свое болото. Но, если предположить, что вы начинаете анлогичный проект в 2024г, то стали ли бы вы смотреть другие движки и фреймворки и сразу бы на Hive стали делать?
Ну тут сейчас можно уйти в длительную дискуссию на равномерность распределения данных по партициям, размер и кол-во файлов в каждой партиции или может даже использование равномерного bucket партицирования с применением формата iceberg. На деле все просто читают документацию и делают ctrl+c , ctrl+v, а по хорошему в HDFS ключ и гранулярность партицирования надо выбирать под минимальную перезапись при загрузке инкремента и это не всегда дата :)
В постгре скорее умрет словарь данных если там создать те самые thousands of partitions. Да и вообще, зачем там столько данных то иметь?
По поводу рекмендаций кстати интересный момент. Все просто цитируют рекомендацию с доки клаудеры, но редко кто проверял на деле. А на деле выясняется что не надо делать больше 3-5 тыс партиций.
Ну у вас не в Hive 30 Птб, а в HDFS 30 Птб (под Hive тут конечно имею ввиду не HMS, без которого не обойтись, а Hive как фреймворк обработки). Вопрос use case использования этих 30 Птб. Что с ними делают? Хранят как архив или как то процессят? Какой объем надо процессить и с каким SLA? Hive сам по себе очень медленный же, даже на Tez в тех сценариях где надо решить задачи конкурентно. Вполне может оказаться что Impala, Trino или SparkSQL с задачей справятся гораздо лучше.
актуально! Убежал мигрировать на Hive и ORC...
олды помнят что изначально DV разрабатывали не для "гибкости", а потому что в те годы СУБД и аппаратное обеспечение с трудом переваривали изменения. Идея DV была в том, чтобы атрибуты измерений разбивать по сателитам в зависимости от временной гранулярности изменений. Те, условно, те что загружаются\обновляются раз в час в одном сателите, те что раз в 4 часа в другом, раз в сутки в третьем. В теории это позволяло не обновлять длинную строку очень часто. С приходом эры MPP необходимость в таком подходе просто отпала.
К минусам якорной модели я бы добавил еще - очень выскую нагрузку на словарь данных. Посчитайте сколько у вас будет объектов если вы загрузите 10тыс таблиц источника по 30 атрибутов в каждом. Ведь ваш фреймворк загрузки будет работать со словарем данных очень интенсивно при таком подходе.
Аплодирую стоя, коллега!
Есть две стадии DV. Первая - сделал и потом написал статью на хабре, добавил в резюме и рассказал на конференции. Вторая - охренел от и начал лепить витрины в обход DV. Правда "забыл" всем рассказать что ты забил на DV.