Пофантазируем?

Ответить
admin_asapbi
Администратор
Сообщения: 1
Зарегистрирован: 12 янв 2025, 07:40

Пофантазируем?

Сообщение admin_asapbi »

В процессе работы даже к 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 запросов;
  • реализация предложенного с уточнениями от разработчика.


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

...
Ответить