1. Вычисление в Hive в первую очередь основано на операциях со списками. Создание списка в хранилище объектов — очень медленная операция.
2. Запись данных Hive основана на переименовании. Но эта же операция выполняется особенно медленно в хранилище объектов.

Эти две проблемы напрямую приводят к невозможности снижения затрат. С этой точки зрения,Iceberg поддерживает собственный набор метаданных.,Этот сайт очень обширен,Я больше не буду вдаваться в подробности.,googleИскать наiceberg file layoutМного。 У Hive есть и другие проблемы, такие как:

1. Проблема с узким местом в Metastore.
2. Гарантий ACID нет.
3. Поле раздела должно отображаться в запросе.
4. Возможность опускания ограничена. Hive может фильтровать файлы, которые необходимо сканировать, только по разделам и сегментам, но не может предоставить более подробную информацию. Хотя значения max и min сохраняются в файле паркета и могут быть использованы для дальнейшей фильтрации, они бесполезны.

Айсберг решает все это. Реализация транзакций и обновлений на основе снимков. Снимки также позволяют пропускать операции чтения для возврата во времени. В то же время собираемая статистическая информация также является более детальной не только на уровне раздела файла, но также на уровне файла (например, минимальные и максимальные значения в файле) и информации на уровне содержимого файла. мин в файле, макс и так далее. Все звучит хорошо. Единственным недостатком является то, что Iceberg плохо поддерживает сценарии реального времени:

• Запись Flink в Iceberg вызовет проблемы с небольшими файлами.
• Iceberg не поддерживает CDC (немного возмутительно, что OLAP поддерживает CDC, но спрос действительно есть).
• Таблицы первичных ключей Iceberg не поддерживают частичные обновления полей. Это немного возмутительно в сценарии хранилища данных в реальном времени.

Какие проблемы может решить Пеймон? В настоящее время кажется, что Пеймон основана на сцене Айсберга.,Для поддержки потокового чтения и записи（Это будет сделано позже Анализ кода）,Поддерживаются даже перечисление и предварительная агрегация. Суть в том, что LSM устанавливается на распределенную файловую систему.,Таким образом, все данные записываются по порядку — несколько оптимизаций записи превращаются в одну последовательную запись.,Он относительно дружелюбен к системе хранилища. В то же время LSM можно использовать как простой кэш.,А упорядоченное написание также может снизить стоимость последующих запросов.,Это может снизить стоимость запросов. С точки зрения сценария он может решить некоторые бизнес-сценарии в квазиреальном времени. Потому что базовое хранилище основано на объектном хранилище, особенно на столбчатом. В любом случае, реализовать сценарии в реальном времени непросто:

• CDC Paimon на основе разных моделей,Будут разные уровни свежести. Чтобы отправить полный режим CDC, выберите «Поиск». В общем, это интервал КПП + более 10 секунд свежести.,Это лучший фактор производительности。Зависит от спецификиданныеколичество、Количество ковшей、Влияние небольшого количества файлов.
• Сценарий в реальном времени требует ответа на запрос на уровне миллисекунд. Paimon поддерживает запросы второго уровня.

Но скольким предприятиям на самом деле требуются сценарии реального времени? Потому что актуальность данных часто связана с циклом принятия бизнес-решений. С этой точки зрения требования к свежести данных от высоких до низких должны иметь форму пирамиды для общего количества бизнес-сценариев. мы упоминали ранееданные Озера, как правило, не привязаны к какой-либо вычислительной машине.。Поэтому в отрасли существует еще один метод, называемый строительством склада на озере.,Вычислительная мощность OLAP,данные поступают из данных озера. Это очень образно,Поэтому некоторые сцены реального времени и офлайн-сцены теперь используют разные движки хранилища.,Затем данные сделают несколько копий. Если данные размещены в одном и том же механизме данных,Это может сократить множествохранилищерасходы。（Для дизайна универсального типа Это будет сделано позже Анализ кода） Конкретная реализация по-прежнему зависит от требований к производительности:

• Если требования низкие, просто выполните простую оптимизацию и получите данные напрямую.
• Если оно выше, оно будет кэшироваться в OLAP.
• На более высоком уровне в OLAP кэшируются не только данные, но и материализованные представления.

Компромисс Обслуживание, Трасканция, Аналитика Согласно здравому смыслу в отрасли, мы найдем:

• Для онлайн-приложений с высоким уровнем параллелизма, быстро и просто, например: HBase, Redis
• ориентированный на аналитику,Масштабное сканирование, фильтрация, обобщение данных,Такие как: Улей, Престо
• Транзакционно-ориентированное случайное чтение и запись, например: MySQL, PostgreSQL.

Озеро данных — это типичный продукт OLAP. Но в сочетании со всем вышесказанным Пеймон обладает определенными случайными способностями к чтению и письму. Буферный, Изменяемый, Упорядоченный Есть три общие переменные для структур хранения: использовать ли буферизацию, использовать ли неизменяемые или изменяемые файлы и хранить ли значения последовательно (упорядочение). Потому что базовая RocksDB TiDB использует LSM. Отсюда использование буферизации, неизменяемости и последовательности. РОМ Существует популярная модель накладных расходов структуры хранения, которая учитывает следующие три фактора: накладные расходы на чтение (Read), обновление (Update) и память (Memory). Это называется гипотезой РОМА. Гипотеза РУМ утверждает, что сокращение двух издержек неизбежно приведет к ухудшению третьей стоимости, а оптимизация может происходить только за счет одного из трех параметров. Мы можем сравнить различные механизмы хранения на основе этих трех параметров, чтобы понять, под какие параметры они оптимизированы и какие возможные компромиссы неявны. Идеальное решение должно иметь минимальные накладные расходы на чтение, сохраняя при этом низкие накладные расходы на память и запись. Но на самом деле это недостижимо, поэтому нам нужно идти на компромиссы. Paimon позволяет свободно устанавливать высоту LSM в конфигурации, чтобы обеспечить компромисс между чтением и записью. Взгляд изнутри Как упоминалось ранее, вычислительная часть опирается на вычислительный механизм, а сам Paimon не обеспечивает вычислительную мощность. Хранилище основано на тонком слое LSM, основанном на части файловой системы. С точки зрения структуры файла Partition эквивалентен индексу первого уровня, такому же, как Hive. Бакет — это вторичный индекс, и в каждом сегменте есть файл данных и файл журнала изменений. Это означает, что при выполнении условий Parition и Bucket запрос с некоторыми дополнительными условиями не будет слишком медленным — обычно будет собираться статистика на уровне файла и выполняться некоторая оптимизация фильтрации в Reader файла. Общая компоновка очень похожа на Айсберг, поэтому я не буду здесь вдаваться в подробности. краткое содержание В этой статье я кратко представляю проблемы, которые должен решить Paimon, а также сильные и слабые стороны его предшественника Iceberg. В настоящее время проект все еще находится в стадии разработки, и я буду продолжать уделять внимание деталям его реализации в будущем, так что следите за обновлениями.