Request clarification before answering.
Hi albertosimeoni,
This is actually intended. It's expected to perform and condense all operations in the same operator.
Therefore there will be a single operator per object/flow.
See SAP Datasphere documentation Creating a Graphical View:
"You can only create one each of the Filter, Projection, Calculated Columns, and Aggregation operators per source or join in your diagram. Operators can be created in any order."
BR.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I know that for optimizations (hana column search for example https://help.sap.com/docs/SAP_HANA_PLATFORM/9de0171a6027400bb3b9bee385222eff/bbe10438eac040db853849b... ) it is better if there is an ordering of the operations.
but trying with this example: if you add 2 consecutive aggregation nodes, you can actually add another step of calculation even if it is used before.
(First step: add this sequence of nodes)

(Second step: Remove aggregations)

This is legit and it activates as it is managed in the database with a SQL View.
This is Necessary in every real wold example, is totally not possible to avoid insert multiple logic inside a view, otherwise reporting needs of a customer will explode from hundreds to thousands of graphical views.
Please consider these:
https://influence.sap.com/sap/ino/#/idea/311725
https://influence.sap.com/sap/ino/#/idea/311847
Another point of view if we look at the Optimization is to flag the functions that lead to Row engine execution and cause OOM issues instead of limiting the modeling features.
Another example is the use of LPAD (a function available in graphical view modeling), to fix a column used in a join.
LPAD in latest hana cloud release create problems with the join cardinality (in explain plan), sometimes the cardinality is not correct leading to overestimate of the memory needed to perform the select operation and causing OOM issues.
To me it seems that the way of solving database issues through modeling limitations should be reverted:
modeling features need database optimization,
more modeling feature => better product.
Regards
Hi albertosimeoni
I do not recommend the trick to have two FX in a row, I used it some time ago and it did not give me good results because it was not stable. I don't know if it will be now, but ...
In our case, we use multiple views for complex cases instead of concentrating it in a single one. We have more objects than in HANA and we "control" it with the nomenclature while we are still waiting to have folders in the business builder to be able to organize it better (it will really arrive in 2023Q4?).
It is true and curious that DSP's control over views is so poor compared to HANA, and even more so considering that DSP runs on top of HANA.
It is a subject that still has room for improvement.
Regards,
guys,
we had 1 customer with over 350 objects just for a Sales reporting as we put together 4 different source systems.
If I need to split even more, I will have over 1000 objects to serve 1 report, If I need to do maintenance, I will have to activate chains of 20 to 30 objects? just to add some fields to a dimension for example?
The real world complexity, outside business content is high as companies have multiple ERPs with different logics.
Probably Datasphere isn't the right product for today's complexity,
Probably a better product should he an HANA Cloud + an external ETL tool ?
or other "third party" products, who knows.
To stay focused on topic, is not the SQL Written by Datasphere that do the optimization,
the optimization is the way the SQL is interpreted by RDBMS engines. If I do twice a step of calculation, 90% of the columns are projected => so column search absorption is applied with columnar engines => no performance hit.
Alberto, at this time if you want to do it using graphical views there is no other option.
As I said, when we discover this "trick" we tested it but it was not stable, when you added another step sometimes it gave errors or you opened the view after a while and things disappeared because the process that is done when the source is updated. That's why we decided not to use it, but that was a long time ago, I don't know if it is now a safe and stable "alternative".
About optimization, I'm not an expert in DB plans, but I also think that the optimization is fully managed by HANA, but if you work with remote sources the SQL is not send as is to remote source. I'm not sure WHO is the responsible of manage pushdown filters, etc. In theory it is HANA SDI/SDA who knows the capabilities of the data source, whether it supports such a condition or not, semijoins, etc. but I'm starting to think that something is being decided from DSP side.
Regards,
| User | Count |
|---|---|
| 5 | |
| 4 | |
| 4 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.