我们最近完成了一项业务，其中我们使用HANA连接了80多个源表，京淘客，并向上游系统提供了70多个列的数据馈送，以便进一步处理。出于客户保密的原因，我不允许进入项目的功能方面。我们的方法是对源系统表使用一系列的计算视图，并得出最终的格式。

上游流程对数据质量问题非常敏感，有错误的记录需要事先过滤掉。因此，在将feed发送到上游系统之前，需要对feed进行数据质量检查，并满足以下要求

客户对格式/值有特定的规则，这些规则对70+个字段中的每个字段都有效。数据质量过程应该检查每个字段和a、 如果任何字段未通过数据质量检查，请将记录标记为"错误"，并且不要将其发送到上游系统。b、 将记录标识符与违反数据质量规则的信息一起移动到单独的表中。c、 如果后续相关记录与步骤a中找到的记录相关，开心返利，则将其标记为"相关错误"。存在一个特定字段，如"Customer\u Id"，超级返利，该字段链接了多个记录。因此，对于Customer\u id X43Y，如果2017年1月1日输入的记录有错误，那么对于Customer\u id X43Y，在2017年2月1日输入的所有后续记录，即使这些记录中没有质量错误，搭建大数据平台，也应使用"相关DQ错误"保留。d、 通过SAP BI创建分析来报告。

我们通过设计数据质量框架和使用动态SQL和HANA阵列来实现这一点。我们的解决方案包括

1。数据质量规则表2包含错误状态代码的状态代码表6–数据质量错误7–由于先前的数据质量错误而保留记录三。一种错误输出表，其中包含记录标识符、错误字段详细信息以及与数据质量规则表的链接4一个使用动态SQL来运行规则和促进输出的过程

表结构：1数据质量规则表

在规则表中插入70+个的数据质量规则。一些检查可以使用数据库约束来实现。但这会导致我们的端到端流程失败。我们希望避免这种情况。

插入样本：

2。状态代码表

状态代码、说明、激活标志6，数据质量错误，17，相关DQ误差，1

3。表1错误DQERR\u ID、、、、、ERROR\u FIELD

（运行DQ检查的表的记录标识符）

4。程序代码：仅供参考；尚未经过生产测试，使用时应自行承担风险。

了解HANA动态SQL的以下缺点并将其传递给组织安全方面非常重要。

动态SQL允许您在过程执行期间构造SQL语句。虽然dynamic在创建SQL语句时提供了更大的灵活性，但它的缺点是在运行时需要额外的成本：

优化的机会是有限的。每次执行语句时都可能重新编译该语句。不能在SQL语句中使用SQLScript变量。不能将动态SQL语句的结果绑定到SQLScript变量。您必须非常小心地避免可能损害数据库完整性或安全性的SQL注入错误

ARRAY\u AGG:将表的列转换为数组

APPLY\u FILTER:APPLY\u FILTER函数对表或表变量应用动态筛选器。从逻辑上讲，它可以被看作是一个部分动态sql语句。该函数的优点是，您可以将它赋给一个表变量

Execution:

使用普通调用执行过程

调用"SCHEMA\u Q"QPACKAGE.程序：DQ_CHECKS"（'20161214'）

过程将在规则表中循环并执行所有活动规则。

性能注意事项和缺点：

1。除非用GUI扩展解决方案，否则必须手动维护规则。2一般来说，动态SQL有一个性能缺点。性能需求应该通过动态SQL的实现来衡量

在我们的例子中，处理大约40000条记录并对70多个字段中的每一个进行检查—假设每条记录都有错误，在单节点系统上的常规负载下，该过程平均只需不到一分钟（50-70秒）就可以完成。处理3M+行，物联网专用卡，每行有多个错误，处理时间为5+分钟。