Схема данных для хранения разнородных данных в файлах паркета в HDFS - PullRequest
Новая
       6

Схема данных для хранения разнородных данных в файлах паркета в HDFS

0 голосов
/ 21 сентября 2018

Мы хотим хранить данные вроде: 

{"event":"click", "click_url":..., ...},
{"event":"view","view_item":...., ...}

Каждое событие (щелчок / просмотр / загрузка / попадание ....) имеет разные поля.

В настоящее время мы группируем все видысобытий в одних и тех же файлах паркета, в итоге получается 90 полей, чаще всего нулевое время (редкие данные, потому что для события представления все поля click_ * равны нулю).

Поскольку мы планируем добавлять все больше и больше событий, это не масштабируется (я не могу изобразить файл паркета с более чем 128 столбцами!).

Мы уже используем раздел: year=2018/month=8/day=20, одну таблицу Hive и Apache Spark для запроса.

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

1 Ответ

0 голосов
/ 21 сентября 2018

Вы можете принять объединение различных схем, как вы уже делаете.Хранение «разреженных» или «широких» данных (большое количество столбцов в таблице, но небольшое количество столбцов в отдельных записях) фактически является одной из областей, в которых Parquet превосходит все остальные.Вот несколько выдержек из статей, в которых упоминается это:

С Dremel упрощен с помощью Parquet :

Разреженный столбец с большим количеством нулевых значений сжимается почти доНичего

От Паркет: хранилище столбцов для данных Hadoop :

Паркет действительно работает, когда запрос на разреженных данных или низкой мощности при выборе столбцов.

и

Это особенно хорошо для запросов, которые читают определенные столбцы из «широкой» (с множеством столбцов) таблицы, поскольку считываются только нужные столбцы и ввод-вывод.сведено к минимуму. "

Возможно, вы захотите упомянуть конкретные столбцы в ваших запросах вместо того, чтобы использовать SELECT *, чтобы воспользоваться этим.

...