asapBI: импортозамещение SAP Calculation View

23 сен 2025

Любите ли вы SQL так же, как и я? Недавно, собирая огромный SQL-запрос, я понял, что надо что-то менять.

Логическим блоком в SQL является подзапрос или CTE и вроде бы можно разбивать запрос по блокам и работать с ними отдельно, как строится по кирпичикам любое приложение.

Однако когда весь текст запроса идет сплошняком на несколько десятков экранов, сложно и разрабатывать, и через длительное время понимать алгоритм запроса.

А что, если не надо писать SQL?

В SAP мы не писали запросы, мы создавали Calculation View, и работать с ними было на порядок быстрее и приятнее.

Перефразируя диалог из Матрицы:

— Когда я стану избранным, я смогу писать длинный SQL?
— Тебе не надо будет писать SQL.

После добавления в asapBI возможности создания моделей Data Vault (вот статья на эту тему), я переключился на реализацию Calculation View. За основу я взял логику, реализованную в SAP Hana Calculation View (анализировал также и другие построители) с добавлением новых возможностей:

• визуальное построение выборки данных;
• использование параметров CV при выборе данных;
• использование различных баз данных (ADB, Greenplum, PostgreSQL, Clickhouse);
• на выходе как вся CV, так и ее промежуточные блоки представляют собой функции (UDF) базы данных — их можно вызвать из других инструментов;
• возможность выполнения CV как внутри базы, так и на внешних кластерах (например, Trino или CedrusData). Это значит, что трансформация данных и закрытие периода будет идти не 4 часа, нагружая продуктовую базу данных, а 10 минут на внешнем кластере. Или не потребуется материализация данных для отчетов — за ней ведь еще и следить надо;
• для олд скул тру программистов — полная прозрачность, возможность проверить, какой SQL нагенерил инструмент и, при необходимости, добавить ручной SQL код;
• возможность отказаться от asapBI IDE и вести дальнейшую разработку общепринятыми инструментами без потери наработанного — т. е. без вендор-лока;
• использование AI.

Создать CV, как и объекты модели данных, можно в любой папке, пример созданного CV:

Кто-то скажет, что запросы можно вручную написать — это так, но TTM будет уже не таким.

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

Роль языка SQL, на мой взгляд, в дальнейшем должна свестись к роли Ассемблера — все знают, что он есть, что он быстрый, но давно ли вы использовали его в разработке? Полагаю, что SQL станет нишевым языком для того, чтобы вручную написать очень оптимизированный запрос.

Вишенка на тортик

Коллеги, а зачем нам инструмент, который не сам будет работать? Весь этот выбор и создание таблиц, протягивание соединений, join по полям — разве в конце концов нам это нужно?

Нам надо, чтобы инструмент работал сам, строил запросы, модели данных, а мы проверяли решение и допиливали по мелочи неучтенные вопросы.

В этом, конечно же, нам поможет встроенный в asapBI локальный или облачный AI. А вот как именно поможет — это уже тема отдельной публикации...