Комментарии 31
В Hive, чтобы изменить схему таблицы, нужно пересоздать ее целиком
Неверно, есть команда ALTER TABLE.
Фрагментация файлов — еще один кошмар. Когда ваш Data Lake состоит из миллионов файлов по 10 МБ, даже простой SELECT COUNT(*) превращается в многочасовой квест. Виной всему ручное управление партициями.
Видимо, имелась в виду фрагментация таблиц по файлам, а не фрагментация файлов.И как заячий прыжок в сторону - переход на ручное управление партициями. Во-первых, избыточное количество файлов вредит независимо от способа управления партициями и даже независимо от их наличия вообще. Во вторых, для Hive+parquet-таблиц существует автоматическое управление партициями и оно используется значительно чаще ручного.
Гибкость схемы — больное место Parquet и ORC. Добавить новый столбец в таблицу? Легко. Но если вы попытаетесь прочитать старые данные, где этого столбца нет, получите NullPointerException.
Неверно. При прочтении файлов, где этого столбца нет, получаем обычный NULL.
Дальше читать не осилил. Какие-то лозунги вперемешку с неверными данными.
Да, в Hive есть ALTER TABLE, но он далеко не панацея. Попробуйте, например, сменить тип столбца с STRING на INT без пересоздания таблицы — получите веселье с несовместимостью данных. Или удалите колонку и посмотрите, как отреагируют старые файлы. В Iceberg эта история куда гибче.
Фрагментация файлов это реально боль, особенно в системах с высокой частотой инсертов. Даже если у вас автоуправление партициями, это не спасает от того, что движок должен продираться через кучу мелких файлов. Iceberg эту проблему решает через компакшн и манифест-файлы, которые позволяют оптимизировать работу с метаданными.
По поводу NullPointerException — согласен, скорее всего, утрировал, но в любом случае проблемы со схемой в Parquet и ORC — вещь реальная. Опять же, Iceberg явно удобнее в этом плане, особенно при эволюции схемы.
Короче, понятно, что каждая технология со своими нюансами, но Iceberg закрывает кучу старых болячек, которые в Hive/Parquet до сих пор решаются костылями..
Чтобы бахать альтером таблицы нужно знать кто их у вас читать может и использовать, если пользователей много искать придётся долго, не?😭
Если таблица только ваша то да👍
Тоже понравился Iceberg, но на деле оказалось, что многие инструменты умеют только читать данные в таком формате, с записью мало кто разобрался.
Да, это боль многих. Читают все, а вот с записью местами как в старом анекдоте: «сначала надо постучать, потом попрыгать».
Но движуху в сторону нормальной поддержки видно — тот же Spark, Flink, Trino уже умеют писать, а Iceberg-REST вообще открывает игру на новом уровне.. Так что вопрос не «если», а «когда» это станет стандартом. А те, кто застрянет на старых форматах, потом будут мигрировать с болью и слезами.
Понятно почему: при чтении разницы с обычным Data Lake практически нет, Iceberg просто добавляет слой метаданных поверх. Инструменты созданные под Data Lake было легко адаптировать. А вот писать уже сложнее.
Возьмем дублирование — бич всех Data Lake. Представьте: три команды загружают один и тот же датасет с метриками в S3, но разными путями. В итоге вы платите за хранение трех копий, а аналитики тратят часы, чтобы найти «ту самую» версию. Проблема в отсутствии ACID-транзакций.
что это за бред?? Никакие ACID транзакции в жизни не помогут если одни и те же данные загружаются в S3 разными путями. Так как это обычно делается разными командами, лежит в разных местах и еще и называется по разному. Это чисто управленческая задача. Никакой формат хранения на нее не вляет. Если есть Chief Data Officer - он своим волевым решением и ставит точку: "хватит опять в 10-й раз, заново парсить весь facebook, давай те сделаем это один раз, но правильно и так чтобы результат могли использовать все 10 команд". Вот и всё. Причет тут Iceberg !!???
ну и так вся статья
Например, при запросе продаж за 2024 год система сначала обращается к каталогу, чтобы определить релевантные файлы, и только затем читает их. Второй уровень — манифесты, которые хранят статистики: минимум и максимум значений, количество строк. Эти данные позволяют отсечь до 90% ненужных файлов на этапе планирования запроса. Третий уровень — сами файлы данных (Parquet, ORC), но с гарантией согласованности и атомарности.
каталог метаданных, сбор статистики и acid - это подается как прорыв в 2024?? Вы про snowflake например слышали что-нить?
Ну Snowflake — это вообще другой зверь, управляемый сервис со своим стеком. Iceberg же тащит ACID, каталог и оптимизации прямо в открытый формат, который можно юзать хоть в S3, хоть в HDFS, хоть где угодно, без привязки к вендору.
Если бы всё уже идеально решалось в Snowflake, то зачем тогда Netflix, Apple и прочие перешли на Iceberg? Видимо, им нужна была гибкость и контроль над своими данными, а не очередной закрытый сервис с удобным, но дорогим чекбоксом.
Вы немного смешиваете две задачи.. Да, управленческий контроль никто не отменял, но когда речь идёт о консистентности внутри одного хранилища, ACID-транзакции реально решают часть проблем. Iceberg тут как раз и нужен, чтобы не получать “данные в разных местах и с разными именами” из-за рваных записей, конфликтов версий или забытого мусора.
Он, конечно, не заменит Chief Data Officer, но сделает так, чтобы даже при идеальном управлении у вас не образовывался хаос на уровне самого хранилища.
ну не я начал это смешивать, расскажите мне еще раз что подразумевается под:
три команды загружают один и тот же датасет с метриками в S3, но разными путями.
Особенно с упором на "разными путями". Это разные ingestion tools? Причем тогда тут acid??
«Разные пути» это и разные ingestion tools, и разные схемы именования, и разный контроль версий. ACID тут при том, что даже если хаос в Data Lake неизбежен, он хотя бы не будет усиливаться за счёт несогласованных обновлений и дубликатов в одной таблице.
Без транзакций поддерживать консистентность внутри хранилища становится задачей с неопределённым успехом.
.
хаос в Data Lake неизбежен
ну хоть тут определились, хаос от разных команд загружабщих одно и тоже никуда не денется без управленческих решений. А транзакции отвечают за 0.00001% ошибок данных в хранилище.
Ибо вот в том же Snowflake с которым я уже 4-й год работаю имеет все ACID транзакции и кучу всего еще. Однако при неправильном дата менеджменте превратить его в свалку и болото данных - легко!
Статью писал либо дилетант, либо "эффективный менеджер". Часть проблем надумана, другая часть - легко решаема, если голова хоть чуть-чуть варит. Жили и работали без Айсберга/дельты прекрасно десятилетие как-то. И многие и сейчас продолжают и даже и не подозревают, что должны испытывать какие то проблемы.
Ну, жить можно и без Airflow, и без Kubernetes, и без CI/CD — тоже десятилетиями работали как-то. Вопрос в том, сколько времени и сил уходит на поддержку всего этого вручную.
Iceberg не решает все проблемы, но если у вас терабайты данных и сложные сценарии работы с ними, он заметно снижает боль. А если текущий стек вас устраивает — это тоже вполне нормально , никто не принуждает мигрировать) Мы скорее ищем наиболее эффективные и удобные решения для конкретных задач.
Я бы был аккуратнее с терминами, может тогда статью поняли бы больше читателей, и меньше флейма было бы в комментариях. Скажем,
появляется Apache Iceberg — файловый формат
Все его называют табличным форматом, а не файловым. Низкоуровневый файловый формат как раз не изменился, данные лежат в тех же самых Parquet. Вот над этими файлами появился формат таблиц, описывающий метаданные, схему, версии, и так далее.
Ну ещё немного стоило бы разобраться в деталях того о чем пишете, чтобы не было чуши вроде
применение Z-Order, особенно для колонок с высокой кардинальностью
Z-order применяется для многомерных данных, когда надо отфильтровать либо сразу по нескольким признакам, либо то по одному, то по другому. Что включает упомянутые географические данные, но делает бессмысленным приведенный пример - он будет гарантированно медленнее распределения только по user_id.
Z-Order действительно эффективнее для многомерных данных и сценариев с комбинированной фильтрацией, но его используют и для колонок с высокой кардинальностью, когда важно оптимизировать чтение по нескольким ключам.
Согласен, что для выборки строго по user_id лучше просто кластеризация, но если user_id комбинируется с другими фильтрами, Z-Order может дать выигрыш.
Ну и ещё, вам не надо делать заявленный выбор между BigQuery или Iceberg, можно использовать Iceberg таблицы из BigQuery, оно умеет с ними работать напрямую.
Вы правы, BigQuery поддерживает Iceberg напрямую. Но в статье я как раз хотел подчеркнуть, что если вы уже используете open-source инструменты, например, Spark, и хотите снизить зависимость от облачных провайдеров, то выбор в пользу Iceberg будет более чем оправдан.
Так что, на самом деле, выбирать между BigQuery и Iceberg не нужно — можно использовать их вместе и получить все плюсы!
Судя по комментариями и тексту автор не понимает разницы
Спасибо за фидбек! Возможно, формулировка вышла неидеальной, но идея была в том, что Iceberg кардинально меняет работу с файлами на уровне метаданных.
Да, данные по-прежнему хранятся в Parquet, но Iceberg добавляет слой управления, который делает их действительно табличными: версионирование, транзакции, манифесты. Без этого Parquet-файлы остаются просто наборами файлов, а не цельной таблицей
Что люди только не придумывают чтобы Кликхаус не использовать :)
Да, Кликхаус — это круто, но когда нужны гибкость и управление версиями, Iceberg как раз тот инструмент, который не застрянет на своих индексов и запросах. Иногда нужно не только «сжать» данные, но и аккуратно их хранить!
Если интересно можно и материал на эту тему подготовить, как такие сочетания технологий могут улучшить обработку данных)
Почитал статью и что-то так грустно стало. Половина всего что было выдано за супер плюсы oracle умел ещё в 00-ые годы. Эх зумеры.....
Согласен, многие идеи не новые, но раньше они работали в рамках монолитных СУБД. Iceberg тащит ACID и каталогизацию в дата-лейки, где данные в S3 и HDFS, а не в одном централизованном хранилище.
Это не просто «то же самое, но в другом месте» — тут и версионирование, и оптимизация сканирования, и эволюция схемы без боли. Так что это скорее «эх, батя, мир уже не тот, SQL на дискетах больше не носят» :)
А вы точно пробовали и мели опыт сами о чем тут написали? Или просто насобирали материала и получилось "сало, мед, глина, гвозди и люди с конями"
Данные на льду: как Apache Iceberg перевернул мир аналитических систем