Зачем?

01 января 2025 г.

Авторы за долгие годы накопили большой опыт в построении DWH на основе low-code платформы SAP BI. В связи с уходом SAP возникла необходимость в освоении других, актуальных для России, подобных инструментов. В процессе анализа было выявлено, что на рынке существует пробел в части low-code платформ для моделирования и трансформации данных.

SQL как Ассемблер

Конечно, можно построить DWH, используя только SQL, DBT, Spark или другие инструменты для трансформации данных. Можно вручную собирать и поддерживать изменения таблиц, работать с Dbeaver, писать фреймворки на Python, Java, PL/SQL...

Однако, не является ли это шагом назад, когда вместо использования low-code платформы приходится вручную реализовывать множество рутинных задач?

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

Ответ: DWH-платформы

Как и в случае с языками программирования, где ответом на ассемблер стали языки высокого уровня, ответом на прямую работу с SQL стали DWH-платформы. Эти платформы позволяют решать рутинные задачи моделирования и трансформации данных без необходимости писать большой объем кода вручную.

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

От какой даты у вас на работе самая старая DWH-задача? А на какое время вперед такие задачи уже расписаны? ;)

Требования к DWH-инструменту

В процессе работы даже к SAP BI накопились вопросы и пожелания. В идеале, такая DWH-платформа для моделирования должна обладать следующими свойствами:

1. Простота установки и использования:
   
   • лучший процесс установки - это без установки. Скачал образ в Docker и через минуту его запустил. Все.
   • возможность работать как на десктопе, так и в браузере/облаке;
   • нетребовательность к ресурсам.
2. Поддержка различных баз данных:
   
   • Greenplum/PostreSQL;
   • Clickhouse;
   • MySQL/MariaDB;
   • ... модульная расширяемая структура для подлючения разных БД.
3. Поддержка ландшафта и переносов изменений по нему:
   
   • Разработка -> Тест -> Продуктив;
   • автоматический сбор изменений модели для переноса в тест и прод, выполненных как вручную из консоли, так и в рамках DWH-платформы.
4. Контроль версий:
   
   • возможность просмотреть и, при необходимости, восстановить состояние модели данных и UDF-функций на любой момент времени;
   • поддержка GIT.
5. Моделирование DWH с автогенерацией SQL:
   
   • поддержка Data Vault;
   • поддержка моделирования таблиц, а также их сателлитов;
   • поддержка Star-схемы;
   • поддержка генерации витрин данных;
   • поддержка механизма быстрого мэппинга в трансформациях.
6. Проверка и корректировка SQL-генерации:
   
   • проверка сгенерированного SQL;
   • корректировка сгенерированного SQL.
   • на критических участках должна быть возможность самостоятельно написать SQL, а не использовать сгенерированный. Это как возможность вставки ассемблера в программу на языке высокого уровня.
7. Цепочки загрузки:
   
   • возможность продолжения упавших цепочек с повтором аварийного шага без повтора успешных шагов загрузки. Т.е. уже выполненные независимые дальнейшие шаги в цепочке повторно не выполняются;
   • в случае блокировки целевой таблицы загрузка не должна падать;
   • один независимый шаг в цепочке загрузки в случае падения не должен блокировать другой независимый шаг. Например, падение загрузки Контрагентов не должно блокировать загрузку Продуктов;
   • запуск цепочек из любимого оркестратора.
8. Готовый контент:
   
   • бизнес-модели данных для установки в систему;
   • примеры моделирования.
9. Трансформации:
   
   • автотесты трансформаций - задать входные данные для трансформации, запустить трансформацию, автоматически сравнить результат с эталоном. Создание цепочек таких автотестов;
   • выполнение трансформаций внутри БД в несколько потоков;
   • для простых трансформаций данные не должны покидать БД в целях высокой скорости обработки;
   • в случае сложных трансформаций возможность выполнять их на внешнем кластере - например, кластере Trino или Spark.
10. Качество данных:
    
    • возможность задать правила проверки данных на любом этапе потока данных;
    • удобный интерфейс управления и добавления правил проверки;
    • разделение массива данных по результатам проверки: красный, желтый, зеленый флаг;
    • разбор и управление такими массивами данных;
    • проверки должны работать после ELT-процессов в фоне и формировать Error Data Mart.
11. Песочница:
    
    • разработка в отдельной создаваемой под задачу песочнице;
    • если разработка успешна - применять изменения к серверу разработки.
12. Поддержка "неразрушающей" доработки:
    
    • разработка в стиле Agile;
    • инкрементальная разработка, без разрушения уже имеющейся модели данных;
    • возможность закрыть изменения определенных объектов без закрытия возможности их расширения. И так как разработка возможна напрямую через DDL, то ограничения должны накладываться с использованием стандартных механизмов раздачи прав на объекты самой базы данных, чтобы их нельзя было обойти через консоль.
13. Снижение сложности разработки:
    
    • разделение областей разработки - видеть только те объекты, над которыми работаешь;
    • быстрое переключение между такими областями, создание своих локальных областей видимости;
    • использование мастеров для создания объектов, особенно выборок из Data Vault.
14. Гибкая разработка:
    
    • импорт существующих объектов БД в модель на DWH-платфоме;
    • возможность корректировки объектов как по-старому, вручную (ddl-запросы), так и с помощью DWH-платформы. При этом все эти изменения должны отлавливаться для переноса по ландшафту.
15. Процесс разработки:
    
    • дебаг (выполнение по шагам) создаваемых функций базы данных;
    • симуляция выполнения, когда выполнение происходит, результаты можно посмотреть, но данные в БД не меняются.
16. Расширяемость:
    
    • возможность создавать свои дополнения;
    • возможность использовать готовые дополнения сторонних разработчиков;
    • API для взаимодействия с внешним миром.
17. Документация:
    
    • автоматическое построение документации;
    • автопостроение data lineage;
    • удобная навигация между разделами и из документации к объектам.
18. Гибкая загрузка с минимальными телодвижениями:
    
    • full;
    • delta;
    • snapshot;
    • batch;
    • stream.
19. Self service модели данных - передача части возможностей по трансформации бизнес-пользователям:
    
    • корректировка данных для мэппинга;
    • корректировка трансформации (видимо, на Питоне или PL/SQL).
20. Использование AI (локально или онлайн):
    
    • анализ RAW-таблиц на предмет выделения мастер- и транзакционных данных;
    • предложение нормализованной модели данных из денормализованных RAW-таблиц;
    • предложение построения модели Data Vault;
    • предложение построения Data Mart витрин;
    • анализ SQL запросов;
    • реализация предложенного с учетом уточнений.

Не стесняемся, добавляем желаемые возможности программы на форуме.

Цели проекта

Основной целью создания этой программы (пет-проекта) является освоение новых и актуализация старых знаний для работы в текущих реалиях:

• Greenplum
• Clickhouse
• SQL различных модификаций
• Typescript
• JavaScript
• PHP
• NodeJS
• Vue
• HTML, CSS и прочие чебурашки...

Ну что ж, поехали:

- ChatGPT, напиши мне программу, как у SAP, только лучше.
- В работе...