Титаник не умеет читать Iceberg Ничего не понятно, но очень интересно. Что имеем? Есть 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. В чем плохо? Каждый раз мы будем тянуть все больше и больше данных, перетаскивая их из одной таблицы в другую + сама табличка растет и не партицированая. Но пока решение такое и в целом рабочее. Че думаете?