Стратегии эволюции схемы паркета - PullRequest
0 голосов
/ 19 сентября 2019

У нас есть вложенная (на нескольких уровнях) json в качестве схемы паркета.Схема используется для чтения паркета из S3 с использованием внешней таблицы в Hive.

Теперь схема эволюционировала:

  1. мы удалили и добавили несколько столбцов.
  2. Изменено значение некоторых столбцов (пример -> кг в фунтах)

Обновления выполняются для атрибутов, которые глубоко вложены в дерево схемы.

Какие параметры мыНужно ли поддерживать эту эволюцию?

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

Добавление / удаление новых столбцов довольно просто, иэто можно сделать, просто обновив определение таблицы улья.

Мы испробовали подход № 1 (перенос данных) для подмножества данных и рассчитали стоимость полной миграции.Мы ищем способы выяснить, сможем ли мы избежать этих затрат, поскольку наши данные за один день составляют около 100 ГБ, а у нас есть данные за 3-4 года.

Создание представлений Hive кажется сложным, потому что мы должнысмоделируйте вложение схемы и в представление, чтобы избежать сглаживания данных.

Примером схемы может быть:

A
|
|-> B
|  |
|  |-> C
|  |-> D
|  |   |-> E          (Say this is changed from KG to POUND)
|  |   |-> F          
|  |   |-> G          (Removed)
|  |   |-> H          (Added)
|  |   |   |-> H1
|  |   |   |-> H2
|  |
|  |-> I
|  |   |-> J
|  |   |-> K
|
|-> L
...