Поддержание схемы архивных данных в актуальном состоянии с работающим хранилищем данных

Question

недавно наше 5-летнее хранилище данных MySQL (используемое в основном для бизнес-отчетности) стало достаточно полным, и нам нужно найти способ архивировать старые данные, к которым редко обращаются, чтобы очистить пространство.

Я создал процесс, который выгружает старые данные из DW в файлы .parquet в Amazon S3, которые затем сопоставляются с таблицей Athena.Это работает довольно хорошо.

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

есть ли «канон»способ обеспечить структурную совместимость между живым хранилищем данных и его архивными данными на основе файлов?Я погуглил соответствующую литературу и ничего не нашел.

Должен ли я просто принять тот факт, что если мне нужно активно поддерживать схемы, то данные на самом деле не архивируются ?

Answer 1

План A:

Слишком поздно делать это, но PARTITIONing - отличный инструмент для получения данных из таблицы.

Я говорю «слишком поздно», потому что для добавления разбиения потребуется достаточно места для создания копии уже большой таблицы.И у вас не так много места на диске?

Если таблица была разбита на год, квартал или месяц, вы могли бы

• Каждый период "Экспортировать табличное пространство", чтобы удалитьсамый старый из схемы секционирования.
• Это табличное пространство будет отдельной таблицей;Вы можете скопировать / dump / что угодно, затем сбросить его.

Примерно в то же время вы создадите новый раздел для получения новых данных.

(я бы оставил двапроцессы разделяются так, что вы можете растянуть больше 5 лет или сократить меньше 5 с минимальными дополнительными усилиями.)

Преимущество этого метода заключается в том, что при обработке практически не происходит воздействия на большой стол.

Дополнительное преимущество разбиения: вы действительно можете вернуть место в ОС (при условии, что у вас есть innodb_file_per_table=ON).

План B:

Посмотрите на то, что выделать с oooold данными.Только несколько вещей?Возможно, с участием суммирования?Итак ...

• Не архивировать старые данные.
• Суммируйте подлежащие удалению данные в новые таблицы.Поскольку они будут, вероятно, одной десятой размера, вы можете держать их онлайн «навсегда».

Answer 2

В Интернете есть тонны материалов, если вы ищите термин "эволюция схемы" в пространстве больших данных.

В документации Athena есть глава, посвященная обновлениям схем для каждого конкретного примера здесь .

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

Поскольку у вас есть файлы паркета, и по умолчанию Athena parquet разрешает столбец по имени столбца, а не по индексу, вы в безопасности почти во всех случаях, то есть добавляете новые столбцы, удаляете столбцы и т. Д., Кроме переименования столбцов. Чтобы обрабатывать переименованные столбцы (и обрабатывать добавление / удаление столбцов), самый быстрый способ - использовать представление. В определении представления вы можете использовать псевдоним переименованного столбца. Кроме того, если переименование столбца является в основном случаем эволюции вашей схемы и если вы делаете это много, вы также можете рассмотреть AVRO, чтобы изящно справиться с этим.