SAP支持帮助我回答

打开"计算视图">"语义">"视图属性">"高级">在下拉菜单中将"执行位置："选项更改为" SQL引擎"。

这加快了我Lumira文档加载和FIlter 20x的性能，使我无需升级硬件即可打开更大的数据集。

最后，经过3年的寻找答案，我找到了想要的东西。 希望这对您的Lumira工作流程有帮助，并且您的客户感到满意。

-马特

下面是KBA大师对Lumira表演问题的摘录，请您仔细阅读一次，然后检查是否有任何步骤可以改善性能：

2541042 -SAP Lumira 2.x的性能和大小-资源和故障排除 ***大师KBA **

对我有帮助的HANA Live Data连接属性可以为您提供帮助：

用于BI平台的SAP Lumira SERVER

• HANA在线-HTTP（S）INA连接器

与先前版本的Lumira Desktop和Server 1.X相比，Lumira Discovery 2.0使用的HANA Online连接器有所不同-以前的OLAP JDBC连接器现在与Design Studio技术和HANA HTTP（S）INA连接器保持一致。

在HANA Live中，当您的应用程序首次尝试连接到SAP HANA数据库服务器时，它将检查池中是否存在使用您指定的相同连接参数的现有连接。 如果找到匹配的连接，则使用该连接。 否则，将使用新的连接。 断开连接时，连接将返回到池中，以便可以重新使用它。 在Lumira Server属性中，当在用户会话和/或Lumira故事中使用相同的HANA视图时，可以调整参数 -Dhanaview.connection.pool.size = 100 以提高性能。 但是请注意，这是一个吞吐量参数-增加它可能会消耗更多资源，因此只会影响受此非常特定的连接相关问题影响的环境-最常见的情况是随着并发用户会话数的增加，性能下降。

已确定可以提高HANA Live数据连接性能的另一个配置项是修改 Execute in：参数（ View Properties 选项卡中的HANA View的高级选项） ）在以下位置执行：SQL Engine 。 对于某些HANA Live工作流程来说，这可能值得一试-但是，在进行此类更改之前，务必先了解瓶颈

Las Breddemann 当仅200 GB RAM实例时，HANA实例如何分配456 GB？

我面临的问题是我希望用户可以访问Lumira中数据集的所有属性。 数据非常深，只有180 M行和40列宽。 其他用户正在做什么以处理Lumira中的BIG数据？ HANA如何在与Lumira的Live-Hana数据连接中发挥很大作用？

我将在HANA sql中执行查询（而不是数据集的Lumira链接），并向您显示PlanViz。

嗨，马特-请查看这些SAP注释，看看它们是否对您有帮助 ：

2442161-通过OpenDocument URL打开Lumira会导致...

https://apps.support.sap.com/sap/support/knowledge/preview/zh/2442161 通过特定的HANA视图通过OpenDocument URL打开Lumira文档，并包含参数会导致错误RCI_CE_00042。

2208172-SAP Lumira系列支持的版本列表| SAP ...

https：//apps。 support.sap.com/sap/support/knowledge/preview/zh/2208172 不兼容的Lumira版本以及组件或应用程序可能会导致错误或无法预期的行为。 错误示例：错误：[RCI_CE_00042] ...

感谢Lars的客气话，我想我现在就去和BO专家谈一下...

这些是 确实是HANA错误消息，它们确实表明查询优化器组件试图分配34930163513字节= 32 GB的内存。 分配失败。 该错误消息还指出，当前已分配的内存大小为465737341133字节= 456 GB。

虽然您的查询似乎可以在相对较大的数据集上运行（10 mio：180 mio join），但我们不这样做 知道这一点在内存方面有多大。 在这里了解错误原因并找到可能的解决方案的下一件事是确定发送给HANA的查询，并查看应如何执行（通过EXPLAIN PLAN和PlanViz）。

一个典型的错误是尝试在没有适当的聚合和过滤的情况下，回读大数据量操作（如大表的联接）的结果集。 这导致结果集的实现，而结果集又需要大量的内存和CPU资源。

问与答平台不允许线程化 评论或讨论。 因此，我现在发布一个新答案，并参考您的问题。

当运行服务器HANA的服务器上有更多可用内存并且尚未配置全局分配限制时，可能会发生"大于许可的"分配。

关于报告设计，其处理方法基本上始终相同："首先进行概述，缩放并过滤，然后按需提供详细信息"，著名的口头禅（ http://www.cs.umd.edu/~ben/papers/Shneiderman1996eyes.pdf ），来自 Ben Shneiderman 。

因此，请勿尝试提供返回单个记录的数据库表过滤工具。 而是提供有意义的聚合和过滤器选项。

寻找见解的任何用户都无法处理1.8亿条记录。 只有将其卷入某种形式的自动化分析后，该卷才有意义。 那就是报告，HANA应该分别做的事情。

就像您所说的那样，处理大数据并不是要返回数百万条记录。 它是关于能够分析大量数据以产生信息和见解的能力。

基于我的经验-我并不是说这里就是这种情况-经常将有问题的"大数据"模型设计为适合所有人的一切，并尝试在单个模型中进行各种分析。 这种方法使得很难为人类正确理解和构建模型，并且通常不会为机器优化留出很多空间。

Hi Lars，

我的情况是：我想从大量人口中找到一个非常特定的人，可以说全世界有70亿人。

我的第一步是查看他们的姓名，出生日期，出生时间，位置和ID。 为简单起见，这是一个包含5列和70亿行的表。 接下来，我想从一个表中找到此人的7年级老师，该表包括他们1至12年级的小学老师的姓名，关键是他们的ID。 第二个表是13列乘70亿行。

在第一个表中找到该人的ID后，这是一个简单的查询，只需两列即可从Teacher中找到ID ='<人的id>';的7TH_TEACHER；

但是，接下来，我想找到第二个人和他们的八年级老师。 我的属性列已更改，而先前的子查询也已更改。

因此，要灵活地在所有人和所有老师中进行搜索，必须将两个完整的表都通过连接两个表的"计算"视图加载到Lumira中。 我错了吗？

我们认为Lumira将成为无需技术管理的简单工具，可以通过即时关系来探索和呈现数据。 问题是用户确定哪些属性有意义，而不是数据提供者。 似乎我要使用的工具错误吗？

我认为是建议我们向客户提供报告，而不是让他们有机会通过Lumira故事板创建自己的报告吗？

感谢您的回应，我将在我们未来的路线图中考虑您的智慧之词。 我完全同意您的最后一段，在尝试支持所有用例时似乎失去了优化。

-马特