Ничего не понятно, но очень интересно.
Что имеем?
Есть PowerBI. Да, это программа для дашбордов. Там можно смотреть метрики, строить графики. PowerBI подключается к вашей БД —> дальше к табличке —> SQL запрос —> график! И также есть S3 (тут храним данные).
Данные у нас грузятся каждый день за 7 дней назад (Каждый день грузим неделю). Почему? Потому, что они могут долетать обновленные + иногда нужно сделать ручной запуск РЕТРО (прогрузить конкретный диапазон дат из прошлого)
Что требуется?
PowerBI должен обращаться к этим данным и строить по ним дашборд.
Как будем решать?
Во-первых мы БИГДАТА, значит мы наверняка данные партицируем (разбиваем по папкам по бизнес дате). Да, это круто. Потом можно удалять конкретные партиции-папки в момент, когда грузим 7 дней назад. Нам же надо обновлять данные за прошлый период. Но PowerBI по какой-то причине не может читать в S3 партиции. Ну вот не получается и все! Только если все лежит в одной ПАПКЕ (Душнилы: это не папки, а объекты..так нельзя говорить...СТАЛИНА НА ВАС НЕТ)
Ну ок, тогда не будем партицировать. Складываем все в одну папку. Но как мы будем обновлять наши данные, мы же получается просто APPEND в одно место и оно начинает дублироваться!
Давайте применим Delta таблицы! Это типа штука, которая позволяется удалять данные в S3. Типа пишешь DELETE и оно прям удаляет. Но у меня не получается, потому что версия Spark Scala и Delta не подходят друг к другу. Короче спарк я обновить сам не могу, а версию Delta мне тоже подходящую не найти.
Давайте применим Iceberg! У меня получилось сделать DELETE! Все четко удалилось из .parquet. Напомню, что из файла формата parquet как бы удалить нельзя ничего. Его можно либо дропнуть полностью и перезаписать, либо дозаписать рядом. А Iceberg — это типа надстройка, которая позволяет DELETE, UPDATE, MERGE + еще можно ходить по разным версиям таблиц, типа как в прошлое!
Вроде все круто! Но теперь PowerBI не умеет читать Iceberg. Короче у нас нет этого коннектора.
Че теперь делать?
⚠️ Делаем 3 таблицы:
source_table - это инкремент (например 7 дней или ретро. Каждый раз overwrite)
tmp_table - это временная таблица (в нее будут стекать финальные данные)
target_table - это таблица витрина, с которой читает PowerBI
Прилетел инкремент в source_table, дальше узнаем в нем min и max бизнес дат. Потому читаем target_table и фильтруем из него все данные, кроме найденных min и max. Дальше делаем source_table.union(filtered_target_table) и записываем в tmp_table.
Последний шаг. Удаляем target_table и переименовываем tmp_table в target_table.
В чем плохо?
Каждый раз мы будем тянуть все больше и больше данных, перетаскивая их из одной таблицы в другую + сама табличка растет и не партицированая. Но пока решение такое и в целом рабочее.
Че думаете?