Комментарии 10
Добрый день. Не могли бы вы раскрыть, какие проблемы решаются использованием S3 Storage взамен классической архитектуры? (Если сформулировать вопрос совсем просто - зачем это надо?).
Бесконечное и прозрачное масштабирование? Ок, принимается. Но это же размен легкости разовых mantainance-tasks на постоянные real-time проблемы?
Облачное хранение? Но если это не Amazon, то облачные провайдеры вполне себе предоставляют блочные устройства.
Хочется понять point статьи - это про замену GreenPlumb и Arenadata DB на Data Ocean Nova или про использование S3 и HDFS как универсального хранилища систем класса DataLake?
Добрый день. Про сравнение классических архитектурных решений и систем класса лейкхаус со всеми мотивациями, преимуществами, сильными и слабыми сторонами, можно ознакомиться в другом материале, например тут. В данной публикации ставится под сомнение утверждение, о том, что HDFS и GP более толерантны к работе с маленькими файлами чем S3 решение minIO.
Мой практический проектный опыт построения подобных систем на обеих технологиях не совпадает с утверждениями коллег, к сожалению. О том как real-time организуется в окружении Hadoop вы можете почитать тут.
Коллеги, а в чем Ваши тайные знания настройки? Взять в два раза больший по ресурсам экземпляр Minio и получить границу деградации в другом диапазоне? Настройка Minio для подобных тестов очень подробно описана в расширенной статье сравнения Minio vs HDFS самими инженерами Minio (Minio vs HDFS), это не искусство. Достаточно только повторить, со своими параметрами.
Важно, а где пример c HDFS, Ozone, на сколько они деградировали на подобном оборудовании? Правильно, они возможно с этим оборудованием вообще не дошли бы до границы деградации. И главное, Вы не очень поняли суть статьи, на деградацию влияет не сам по себе размер файлов. Процессинговый движок «выедает» ресурс (rps) s3 при обработке этих маленьких файлов и начинается интенсивная деградация. Вы получили деградацию в 2,5! раза на границы 140 тыс. файлов за 1000 сек. Прекрасно! Увеличите взятое количество файлов (так как ресурсов выделено значительно больше) и когда получите 8-10, то дальше, сравните это с HDFS (Ozone) и может мы сойдемся в результатах.)) В целом, считаю это подтверждением выводов, которые я представил в своей статье. Спасибо!
Добрый день.
Для эксперимента выбрана минимально достаточная конфигурация кластера minio для промышленной эксплуатации. Даже на самом минимальном пилотном проекте или эксперименте никто не собирает minio меньше, чем на 4 узла с характеристиками в 8 vCPU и 32Gb RAM и 4-мя выделенными дисками на каждый узел. Именно такой нижний порог рекомендован и самой minio (раздел hardware-документации). Уж если и тестировать, то тестировать рабочую минимально достаточную конфигурацию, а не "калькуляторы".
Мы не ограничиваемся документацией сообщества minio относительно настроек и конфигурации. У нас имеются свои наработки и изменения относительно oss. Кроме настроек самой файловой системы, настраиваться должны абсолютно все компоненты: начиная от операционной системы, заканчивая процессинговых движком и\или приложением, работающим с S3.
Помимо большего в 10 раз количества файлов, напомню, что нагрузка создается в нашем эксперименте в 4 раза выше, тк тест выполняется в 4-е параллельные сессии. И, согласно методике TPC-DS, эти сессии не пересекаются по запросам. Именно поэтому в нашем тесте нагрузка создается в 40 раз выше, хоть и ресурсов в два раза больше.
Также мы всегда пользуемся правом не доверять любой документации в открытом доступе, потому что:
— Опубликованные материалы очень быстро теряют свою актуальность. Статья, выпущенная 3-4 года назад, очень быстро становится неактуальной;
— Авторы могут ошибаться, даже если они аффилированы с вендором и выступают от его лица.
Данная публикация преследовала следующие цели:
показать что вывод оригинальной статьи в части s3 minio не верен, а значит ставит под сомнение содержание всей статьи
рассказать о деталях архитектуры HDFS и GP в части маленьких файлов, показав что by design файлов быть много там не может. 3)
Дать ответ на вопросы коллег, возникающие при общении в нашем дружном дата сообществе
Я не призываю никого безапелляционно верить кому либо . Наоборот, прошу читателей засомневаться в любых утверждениях и пригласить и нас, и вас на тестирования и сделать выводы и выбор самостоятельно.
В Greenplum файл - это партиция/таблица (для AOCO колонка таблицы/партиции), если записать в таблицу Greenplum 1000 раз по 1 записи и 1 раз по 1000 записей количество файлов не изменится (для AO будет не полностью заполнен блок, но мы же про файлы). В Iceberg - файл отдельный факт модификации таблицы - записать 1 раз 1000 строк - 1 файл, а 1000 раз по 1 строке - 1000 файлов.
Т.е. в Greenplum количество файлов - это элемент планирования и проектирования структуры, а в Iceberg - зависит от нагрузки и политики компекшен.
Мне кажется это уже не техническая статья, а элемент маркетнинга/рекламы своего продукта, отсюда притянутое за уши сравнение с Greenplum, а также комментария про "недостаточный технический опыт" в начале статьи, что на мой взгляд не очень корректно по отношению к автору первоначальной статьи.
Добрый день.
Автор утверждает, что Greenplum является лучшим выбором для задачи реал-тайм загрузки и репликации данных. Даже лучше, чем HDFS и minIO. По нашему мнению, данное утверждение не соответствует практическим реалиям. Не то чтобы реал-тайм, а даже обычная батч-обработка имеет свои технические архитектурные ограничения, которые мы приводим. Получены они практическим путем на реальном сценарии и клиенте, и, замечу, на серьёзном промышленном оборудовании. Нет ни одной инсталляции в мире, где в Greenplum бы бы реализован хоть какой-то серьезный онлайн. И не просто так.
Посыл нашего материала, как и материала компании Аренадата, направлен на презентацию преимуществ собственных решений относительно альтернативных, но это не преуменьшает техническую ценность статей. Однако, согласны ли вы адресовать свой вопрос о маркетинге\рекламе и к компании Аренадата?
Проблема с распуханием каталога в GP при увеличении количества объектов есть. Но количество файлов можно увеличить не только увеличением количества метаданных, а самими данными. Чтобы в диск не упираться, можно было перекомпилить GP с меньшим размером файлов (<1ГБ) и нагенерить файлов вставкой в таблицы. Тогда бы было честнее. А так - сравнение тёплого с мягким, бессмсленное.
Вы правы, но есть один нюанс - вакуумирование избавит от мелких файлов, вызванных мелкими вставками. А вот с каталогом так не получится.
Как же он избавит, если все данные будут живыми? Мне кажется, вам просто следовало для чистоты эксперимента сделать меньше метаданных и большее количество файлов под этими метаданными, вот и всё.
Ваш подход - "нужно N файлов; давай нагенерим таблиц столько, чтобы метаданные по ним дали N файлов". А есть ещё другой - "нужно N файлов; давай нагенерим разумное число таблиц и сгенерим для них реальные данные, чтобы получилось N файлов". Вы в случае с GP даже не дошли до тестирования как он работает с множеством файлов ДАННЫХ, упёршись в методы работы с каталогом.
Кстати, откуда в случае с SQL движком над HDFS и S3 берутся медатанные и в чём отличие методов работы с ними от GP? Что там происходит при выполнении DDL?
Цель практического эксперимента коллег с GP была - найти границу до которой можно масштабировать каталог, показать почему так происходит и позволить читателю сделать самим вывод ждут ли их с GreenPlum в "экзабайтном клубе" с загрузкой в реальном режиме времени
Отвечаю на вопрос "что там в объектных хранилищах". Буквально заслуживает отдельной очень большой статьи. Если коротко то, есть метаданных хранилища (разные подходы, оти хранения файлов на диске, до отдельной БД на управляющем узле, или кластере БД типа rocks на каждом узле); есть метаданные табличного формата хранения iceberg (файлы в хранилище), есть каталог движка исполнения который иногда может кэшировать мету айсберга, может быть общий мета каталог на всю систему который как правило имеет под ногами свою бд. Очень упрощенно, при выполнении DDL движком, он вносит изменения в общий метакаталог, создает новый снапшот айсберга который пишет свою мету в хранилище ну и движок эту мету кэширует сразу к себе. Казалось бы сложно, но на практике задача поддержания 1+млн объектов (таблицы и секции) решается
Проблема маленьких файлов. Оценка замедления S3 и проблем HDFS и Greenplum при работе c ними