Согласен, многие идеи не новые, но раньше они работали в рамках монолитных СУБД. Iceberg тащит ACID и каталогизацию в дата-лейки, где данные в S3 и HDFS, а не в одном централизованном хранилище.
Это не просто «то же самое, но в другом месте» — тут и версионирование, и оптимизация сканирования, и эволюция схемы без боли. Так что это скорее «эх, батя, мир уже не тот, SQL на дискетах больше не носят» :)
«Разные пути» это и разные ingestion tools, и разные схемы именования, и разный контроль версий. ACID тут при том, что даже если хаос в Data Lake неизбежен, он хотя бы не будет усиливаться за счёт несогласованных обновлений и дубликатов в одной таблице.
Без транзакций поддерживать консистентность внутри хранилища становится задачей с неопределённым успехом.
Вы правы, BigQuery поддерживает Iceberg напрямую. Но в статье я как раз хотел подчеркнуть, что если вы уже используете open-source инструменты, например, Spark, и хотите снизить зависимость от облачных провайдеров, то выбор в пользу Iceberg будет более чем оправдан.
Так что, на самом деле, выбирать между BigQuery и Iceberg не нужно — можно использовать их вместе и получить все плюсы!
Да, Кликхаус — это круто, но когда нужны гибкость и управление версиями, Iceberg как раз тот инструмент, который не застрянет на своих индексов и запросах. Иногда нужно не только «сжать» данные, но и аккуратно их хранить!
Если интересно можно и материал на эту тему подготовить, как такие сочетания технологий могут улучшить обработку данных)
Z-Order действительно эффективнее для многомерных данных и сценариев с комбинированной фильтрацией, но его используют и для колонок с высокой кардинальностью, когда важно оптимизировать чтение по нескольким ключам.
Согласен, что для выборки строго по user_id лучше просто кластеризация, но если user_id комбинируется с другими фильтрами, Z-Order может дать выигрыш.
Спасибо за фидбек! Возможно, формулировка вышла неидеальной, но идея была в том, что Iceberg кардинально меняет работу с файлами на уровне метаданных.
Да, данные по-прежнему хранятся в Parquet, но Iceberg добавляет слой управления, который делает их действительно табличными: версионирование, транзакции, манифесты. Без этого Parquet-файлы остаются просто наборами файлов, а не цельной таблицей
Ну, жить можно и без Airflow, и без Kubernetes, и без CI/CD — тоже десятилетиями работали как-то. Вопрос в том, сколько времени и сил уходит на поддержку всего этого вручную.
Iceberg не решает все проблемы, но если у вас терабайты данных и сложные сценарии работы с ними, он заметно снижает боль. А если текущий стек вас устраивает — это тоже вполне нормально , никто не принуждает мигрировать) Мы скорее ищем наиболее эффективные и удобные решения для конкретных задач.
Ну Snowflake — это вообще другой зверь, управляемый сервис со своим стеком. Iceberg же тащит ACID, каталог и оптимизации прямо в открытый формат, который можно юзать хоть в S3, хоть в HDFS, хоть где угодно, без привязки к вендору.
Если бы всё уже идеально решалось в Snowflake, то зачем тогда Netflix, Apple и прочие перешли на Iceberg? Видимо, им нужна была гибкость и контроль над своими данными, а не очередной закрытый сервис с удобным, но дорогим чекбоксом.
Вы немного смешиваете две задачи.. Да, управленческий контроль никто не отменял, но когда речь идёт о консистентности внутри одного хранилища, ACID-транзакции реально решают часть проблем. Iceberg тут как раз и нужен, чтобы не получать “данные в разных местах и с разными именами” из-за рваных записей, конфликтов версий или забытого мусора.
Он, конечно, не заменит Chief Data Officer, но сделает так, чтобы даже при идеальном управлении у вас не образовывался хаос на уровне самого хранилища.
Да, это боль многих. Читают все, а вот с записью местами как в старом анекдоте: «сначала надо постучать, потом попрыгать».
Но движуху в сторону нормальной поддержки видно — тот же Spark, Flink, Trino уже умеют писать, а Iceberg-REST вообще открывает игру на новом уровне.. Так что вопрос не «если», а «когда» это станет стандартом. А те, кто застрянет на старых форматах, потом будут мигрировать с болью и слезами.
Да, в Hive есть ALTER TABLE, но он далеко не панацея. Попробуйте, например, сменить тип столбца с STRING на INT без пересоздания таблицы — получите веселье с несовместимостью данных. Или удалите колонку и посмотрите, как отреагируют старые файлы. В Iceberg эта история куда гибче.
Фрагментация файлов это реально боль, особенно в системах с высокой частотой инсертов. Даже если у вас автоуправление партициями, это не спасает от того, что движок должен продираться через кучу мелких файлов. Iceberg эту проблему решает через компакшн и манифест-файлы, которые позволяют оптимизировать работу с метаданными.
По поводу NullPointerException — согласен, скорее всего, утрировал, но в любом случае проблемы со схемой в Parquet и ORC — вещь реальная. Опять же, Iceberg явно удобнее в этом плане, особенно при эволюции схемы.
Короче, понятно, что каждая технология со своими нюансами, но Iceberg закрывает кучу старых болячек, которые в Hive/Parquet до сих пор решаются костылями..
Тут либо реально нужна отказоустойчивость, либо CTO начитался докладов от FAANG. Главное — понимать, когда ты строишь распределённую систему по нужде, а когда просто потому, что «так делают большие дяди»
Ну смотри, если у тебя сервис на пару сотен RPS и 99.9% аптайма всех устраивает — можешь жить на одном кластере, никто не осудит.
Но когда бизнесу надо 99.99%+ и zero downtime, начинаются вопросы. Один регион отвалился — что дальше? Сказать пользователям «сорян, перезвоните завтра»?)
Пока что Васм с DOM напрямую работать не умеет, тут всё ещё рулит JS. Обычно его юзают для тяжёлых задач, где важна производительность, а весь интерфейс остаётся на JS. Например, в той же Figma Wasm обрабатывает графику, а всё остальное на JS. Но есть подвижки, WebAssembly Component Model обещает упростить эту интеграцию. Если интересно, вот ссылка, можно глянуть.
Да, с передачей данных там весело, согласен. Но главное не только в скорости Васм дает возможность подключить серьёзные инструменты, которые JS просто не вытянет, типо, библиотек для работы с графикой или сложных алгоритмов. Так что, это больше про универсальность, чем про чистую производительность..
Справедливый вопрос. Для большинства сайтов WebAssembly действительно может показаться избыточеным и HTML, CSS и JS вполне справляются. Но если речь про что-то тяжёлое, например, сложные графические редакторы, игры или видеообр. прямо в браузере, тут без Wasm уже не обойтись. Всё зависит от задач, а не от процента :)
Да, проблема реальная не у всех есть “простенькие” 16 ГБ оперативки и оптоволокно. WASM конечно, помогает выжать максимум даже на слабых машинах, но, честно говоря, иногда кажется, что разработчики тестируют свои приложения исключительно на космических станциях.
Я говорил про еще не существующие. С реальными квантовыми компьютерами ситуация сложнее, читайте тут: https://habr.com/ru/companies/selectel/articles/812889/
тест AIDA дает чуть меньше 100 нс это относиться к физической задержке доступа к памяти. Если мы говорим об эффективной задержке, то учитывайте дополнительные системные задержки, такие как время доступа к кэшу и задержки шины, которые могут добавить примерно 100 нс. Так что, эффективная задержка может составлять около 200 .
Согласен, многие идеи не новые, но раньше они работали в рамках монолитных СУБД. Iceberg тащит ACID и каталогизацию в дата-лейки, где данные в S3 и HDFS, а не в одном централизованном хранилище.
Это не просто «то же самое, но в другом месте» — тут и версионирование, и оптимизация сканирования, и эволюция схемы без боли. Так что это скорее «эх, батя, мир уже не тот, SQL на дискетах больше не носят» :)
«Разные пути» это и разные ingestion tools, и разные схемы именования, и разный контроль версий. ACID тут при том, что даже если хаос в Data Lake неизбежен, он хотя бы не будет усиливаться за счёт несогласованных обновлений и дубликатов в одной таблице.
Без транзакций поддерживать консистентность внутри хранилища становится задачей с неопределённым успехом.
Вы правы, BigQuery поддерживает Iceberg напрямую. Но в статье я как раз хотел подчеркнуть, что если вы уже используете open-source инструменты, например, Spark, и хотите снизить зависимость от облачных провайдеров, то выбор в пользу Iceberg будет более чем оправдан.
Так что, на самом деле, выбирать между BigQuery и Iceberg не нужно — можно использовать их вместе и получить все плюсы!
Да, Кликхаус — это круто, но когда нужны гибкость и управление версиями, Iceberg как раз тот инструмент, который не застрянет на своих индексов и запросах. Иногда нужно не только «сжать» данные, но и аккуратно их хранить!
Если интересно можно и материал на эту тему подготовить, как такие сочетания технологий могут улучшить обработку данных)
Z-Order действительно эффективнее для многомерных данных и сценариев с комбинированной фильтрацией, но его используют и для колонок с высокой кардинальностью, когда важно оптимизировать чтение по нескольким ключам.
Согласен, что для выборки строго по user_id лучше просто кластеризация, но если user_id комбинируется с другими фильтрами, Z-Order может дать выигрыш.
Спасибо за фидбек! Возможно, формулировка вышла неидеальной, но идея была в том, что Iceberg кардинально меняет работу с файлами на уровне метаданных.
Да, данные по-прежнему хранятся в Parquet, но Iceberg добавляет слой управления, который делает их действительно табличными: версионирование, транзакции, манифесты. Без этого Parquet-файлы остаются просто наборами файлов, а не цельной таблицей
Ну, жить можно и без Airflow, и без Kubernetes, и без CI/CD — тоже десятилетиями работали как-то. Вопрос в том, сколько времени и сил уходит на поддержку всего этого вручную.
Iceberg не решает все проблемы, но если у вас терабайты данных и сложные сценарии работы с ними, он заметно снижает боль. А если текущий стек вас устраивает — это тоже вполне нормально , никто не принуждает мигрировать) Мы скорее ищем наиболее эффективные и удобные решения для конкретных задач.
Ну Snowflake — это вообще другой зверь, управляемый сервис со своим стеком. Iceberg же тащит ACID, каталог и оптимизации прямо в открытый формат, который можно юзать хоть в S3, хоть в HDFS, хоть где угодно, без привязки к вендору.
Если бы всё уже идеально решалось в Snowflake, то зачем тогда Netflix, Apple и прочие перешли на Iceberg? Видимо, им нужна была гибкость и контроль над своими данными, а не очередной закрытый сервис с удобным, но дорогим чекбоксом.
Вы немного смешиваете две задачи.. Да, управленческий контроль никто не отменял, но когда речь идёт о консистентности внутри одного хранилища, ACID-транзакции реально решают часть проблем. Iceberg тут как раз и нужен, чтобы не получать “данные в разных местах и с разными именами” из-за рваных записей, конфликтов версий или забытого мусора.
Он, конечно, не заменит Chief Data Officer, но сделает так, чтобы даже при идеальном управлении у вас не образовывался хаос на уровне самого хранилища.
Да, это боль многих. Читают все, а вот с записью местами как в старом анекдоте: «сначала надо постучать, потом попрыгать».
Но движуху в сторону нормальной поддержки видно — тот же Spark, Flink, Trino уже умеют писать, а Iceberg-REST вообще открывает игру на новом уровне.. Так что вопрос не «если», а «когда» это станет стандартом. А те, кто застрянет на старых форматах, потом будут мигрировать с болью и слезами.
Да, в Hive есть ALTER TABLE, но он далеко не панацея. Попробуйте, например, сменить тип столбца с STRING на INT без пересоздания таблицы — получите веселье с несовместимостью данных. Или удалите колонку и посмотрите, как отреагируют старые файлы. В Iceberg эта история куда гибче.
Фрагментация файлов это реально боль, особенно в системах с высокой частотой инсертов. Даже если у вас автоуправление партициями, это не спасает от того, что движок должен продираться через кучу мелких файлов. Iceberg эту проблему решает через компакшн и манифест-файлы, которые позволяют оптимизировать работу с метаданными.
По поводу NullPointerException — согласен, скорее всего, утрировал, но в любом случае проблемы со схемой в Parquet и ORC — вещь реальная. Опять же, Iceberg явно удобнее в этом плане, особенно при эволюции схемы.
Короче, понятно, что каждая технология со своими нюансами, но Iceberg закрывает кучу старых болячек, которые в Hive/Parquet до сих пор решаются костылями..
Тут либо реально нужна отказоустойчивость, либо CTO начитался докладов от FAANG. Главное — понимать, когда ты строишь распределённую систему по нужде, а когда просто потому, что «так делают большие дяди»
Ну смотри, если у тебя сервис на пару сотен RPS и 99.9% аптайма всех устраивает — можешь жить на одном кластере, никто не осудит.
Но когда бизнесу надо 99.99%+ и zero downtime, начинаются вопросы. Один регион отвалился — что дальше? Сказать пользователям «сорян, перезвоните завтра»?)
Пока что Васм с DOM напрямую работать не умеет, тут всё ещё рулит JS. Обычно его юзают для тяжёлых задач, где важна производительность, а весь интерфейс остаётся на JS. Например, в той же Figma Wasm обрабатывает графику, а всё остальное на JS. Но есть подвижки, WebAssembly Component Model обещает упростить эту интеграцию. Если интересно, вот ссылка, можно глянуть.
Да, с передачей данных там весело, согласен. Но главное не только в скорости Васм дает возможность подключить серьёзные инструменты, которые JS просто не вытянет, типо, библиотек для работы с графикой или сложных алгоритмов. Так что, это больше про универсальность, чем про чистую производительность..
Справедливый вопрос. Для большинства сайтов WebAssembly действительно может показаться избыточеным и HTML, CSS и JS вполне справляются. Но если речь про что-то тяжёлое, например, сложные графические редакторы, игры или видеообр. прямо в браузере, тут без Wasm уже не обойтись. Всё зависит от задач, а не от процента :)
Да, проблема реальная не у всех есть “простенькие” 16 ГБ оперативки и оптоволокно. WASM конечно, помогает выжать максимум даже на слабых машинах, но, честно говоря, иногда кажется, что разработчики тестируют свои приложения исключительно на космических станциях.
Привет! Давайте разберемся.
Чтобы вычислить C = 20^17 mod 77, нужно правильно следовать шагам.
1. Сначала возьмем 20^2 mod 77 = 400 mod 77 = 15.
2. Затем 20^4 = 15^2 = 225 mod 77 = 71 .
3. После этого 20^8 = 71^2 = 5041 mod 77 = 36 .
4. Далее 20^16 = 36^2 = 1296 mod 77 = 64 .
5. И, наконец, 20^17 = 20^16 times 20 = 64 times 20 = 1280 mod 77 = 48 .
Таким образом, C = 48 .
Видимо, ошибка возникла на одном из промежуточных шагов, когда пытались вычислить 20^17 mod 77. Получается, что ваш результат верный.
Я говорил про еще не существующие. С реальными квантовыми компьютерами ситуация сложнее, читайте тут: https://habr.com/ru/companies/selectel/articles/812889/
тест AIDA дает чуть меньше 100 нс это относиться к физической задержке доступа к памяти. Если мы говорим об эффективной задержке, то учитывайте дополнительные системные задержки, такие как время доступа к кэшу и задержки шины, которые могут добавить примерно 100 нс. Так что, эффективная задержка может составлять около 200 .