Продолжение разбора задачи сайзинга многоуровневого КХД.
Первая часть: "ч.1 Что сайзим"

ШАГ 0. Перед началом сайзинга специалистами IT выполняется анализ текущих систем (баз данных) и оцениваются отправные критерии сайзинга (годовой объем данных, прирост, объем исторических данных)

ШАГ 1. Общий объем исторических (начальных) данных

На данном шаге указывается объем исторических данных
На данном шаге указывается объем исторических данных

ШАГ 2. Объем ежедневной загрузки "сырых" данных в рабочий день
Важно! Размер КХД критически зависит от объема исходных данных.

Оценочная величина прироста данных в день (исходя из 247 рабочих дней в году)
Оценочная величина прироста данных в день (исходя из 247 рабочих дней в году)

ШАГ 3. Атрибуты КХД

Атрибуты, определяющие характеристики КХД
Атрибуты, определяющие характеристики КХД

Данный шаг является наиболее сложным и требует отдельного объяснения.
Допущения:

Столбец "Слой" - переключение 1 или 0 позволяет указать, будет ли данный слой участвовать в расчете общего объема КХД.
Столбец "Хранение истории трансформации и данных" - переключатель 1 или 0 определяет, потребуется ли хранение всей истории перетока данных между шагами алгоритмов и слоями хранилица в материализованном виде
Столбец "Коэффициент сжатия" - процент, определяемый блоком допущений и устанавливающий процент уменьшения объема данных при перемещении между слоями КХД. Процент применяется к результату полученному на предыдущем шаге с учетом процента заданного для слоя "8. Слой хранения истории трансформации данных".

Из приведенного примера следует, что при исходном притоке данных равным 80Gb в день, с использованием всех восьми слоев КХД включая 10% на логи трансормации и перетоков данных, на уровне материализованного хранения результатов потребуется 242Gb пространства.

ШАГ 4. Коэффициенты КХД
Прогнозирование КХД основывается еще на нескольких вспомогательных коэффициентах представленных ниже

Характеристики прогноза роста КХД
Характеристики прогноза роста КХД

Число месяцев детальных данных - это число месяцев для которых хранится детальная информация по всем слоям; остальные периоды хранятся только в части данных на слое "Слой витрин для формирования отчетности"

ШАГ 5. Итого (без учета ресурсов для системы BackUp'a)

Расчет итоговых величин роста КХД
Расчет итоговых величин роста КХД

Итого, вариант при хранении всех данных в перспективе 3-х лет без очистки КХД от неиспользуемой информации:

315Tb Однако
315Tb Однако

Вариант хранения только заданного числа месяцев в детализации (метрика 14); история только в виде данных слоя формирования отчетности

Отрезание истории изменений и высокой детализации дает практически шестикратное уменьшение объема КХД
Отрезание истории изменений и высокой детализации дает практически шестикратное уменьшение объема КХД

ИТОГО:
Представленный материал - это не мантра, это подход.
Понятно, что КХД может быть очень сложным, более того, часть слоев для разных блоков КХД может просто отсутствовать и в этом случае применить общее мерило не получится, НО!
Ничто не мешает делать сайзинги для разных блоков КХД формируя для них свой набор процентных значений сжатия данных включая или выключая слои, меняя параметры ретроспективного хранения данных или управляя уровнем детализации и историей для анализа получения агрегированных данных в отчете до уровня первичных документов.

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

Комментарии (5)


  1. Mapar
    12.09.2024 14:05

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


    1. Nucl Автор
      12.09.2024 14:05

      Коэффициенты в данном примере выведены из практического опыта. Конечно они могут отличаться в каждом конкретном случае, но как среднее по больнице ИМХО актуальны.


      1. Mapar
        12.09.2024 14:05

        Для какой модели данных? Камбал, Инмон, DataVault?


        1. Nucl Автор
          12.09.2024 14:05

          Модель Инмона конечно же.


    1. Nucl Автор
      12.09.2024 14:05

      Вы ошибаетесь касательно числа показателей: ничто так не влияет на объемы данных, как аналитичность показателей.