Одна таблица, основанная на большом событии, или несколько таблиц? Рассмотрение дизайна таблицы улья

Question

Я работаю над проблемой, когда у нас есть много разных событий, поступающих из разных источников, и эти события имеют 60% полей. Итак, с учетом сказанного, я изначально начал с создания отдельных таблиц для каждого события и теперь вижу, что между этими событиями может быть много событий и почти 60% полей данных. Я думаю о создании одной таблицы событий, которая будет иметь столбцы для всех события, и я собираюсь добавить столбец типа в этой таблице, который позволит моим искровым заданиям выбирать события, имеющие отношение к ним. Эта таблица является внешней таблицей Улья, а искровые задания будут загружать в нее данные, обрабатывая промежуточную таблицу json.

Я ищу информацию от экспертов, чтобы увидеть, возможна ли эта конструкция стола?

1. Мой раздел будет как раздел (строка даты, тип клиента, типСобытия строка)
2. я мог бы иметь дополнительный раздел региона, но еще не решили, что еще
3. Данные хранятся в виде формат Паркет
4. преимущество я вижу в том, когда новое событие вводится я просто добавить столбцы, относящиеся к нему и расширить свою искру рамки против добавления новой таблицы и прочее

Мой кластер имеет 6 DNs с 32Gig RA M на каждом и 5 ТБ дискового пространства каждый. Поскольку искра - наша основная инфраструктура обработки, меня беспокоит потребление ресурсов для всех заданий, которые будут выполняться? Что делать, если перегородки становятся слишком большими? Я тоже рассматриваю производительность и скорость?

Любые входы оцениваются.

Answer 1

Перед тем, как решить, как хранить данные, необходимо рассмотреть некоторые вещи.

• Зачем использовать паркет вместо avro? есть некоторые ограничения в Hive вокруг схемы эволюции, используя паркет вместо avro.
• Какие операции вы будете выполнять над своими данными? если вы будете использовать несколько столбцов, я бы рекомендовал использовать паркет вместо avro, но если это не так и не будет делать скопления, и вы будете в основном работать на уровне строк, я бы предложил avro
• Что вы ожидая слияния таблиц? будете ли вы выполнять операции, используя не общие поля между разными таблицами? это общий случай? С точки зрения юзабилити, может быть, это хорошая идея, чтобы все ваши таблицы были независимыми друг от друга и создавали таблицу с общими полями, это позволит вам работать с неосновными столбцами, если это необходимо для этих записей без этих столбцов, а также с общие поля из «объединенной» таблицы. , это хорошо для внешних таблиц.

• сколько будет расти ваши данные ежедневно? это очень важный момент, вы будете генерировать множество небольших файлов? Если это так, вы должны рассмотреть процесс промежуточных процессов для создания новых файлов и сделать ваши файлы более крупными, по крайней мере, соответствующими размеру блока, это важный момент, учитывая небольшой размер вашего кластера.

• Позаботьтесь о том, как вы разбиваете данные, очень мелкозернистые могут закончиться множеством небольших файлов, которые будут влиять на производительность. вам действительно нужны разделы по клиенту и событиям?

• Я не уверен, что о деталях вокруг ваших искровых рамок, но ввести новые столбцы непосредственно, кажется, очень трудно поддерживать, внимательное использование genericrecord, если вы решите использовать Avro

Я надеюсь, что это помогает с некоторыми решениями.

EDIT: ответить на некоторые вопросы

улей, кажется, есть некоторые ограничения при изменении структуры столбца для паркетных таблиц. Например, чтобы изменить имя столбцов в определении таблицы, вы должны использовать флаг parquet.column.index.access, чтобы сделать эту работу, это означает, что все ваши данные будут содержать одну и ту же схему. Замена столбцов в Hive для добавления совершенно нового определения не работает в версии Hive версии 1.3, по какой-то причине я не могу читать новые столбцы, не уверен, что это исправление в других версиях.

Кроме того, эволюция схемы в искры была отключена, поскольку она дороже, по сути, вы должны прочитать все файлы и консолидировать схему для работы таким образом и в зависимости от количества файлов, это может повлиять на производительность

http://spark.apache.org/docs/latest/sql-programming-guide.html#schema-merging