3月29日，“隐语开源社区开放日”活动顺利举办。当天隐语社区正式开源SCQL引擎，在工业界首次实现了隐私数据从Al到BI分析，是隐语走向易用的重要一步！下文为隐语框架负责人王磊在活动现场的分享内容。
从AI到BI：基于多方安全计算的隐语数据分析引擎SCQL
小程序
公众号后台回复：SCQL数据分析，可下载PDF原文件！
👇下文保留速记稿(未做编辑) 以期为大家带来王磊对该技术更为原汁原味解读^_^。
速记整理稿：
我们知道，在隐私计算目前应用较多的场景中，无论是风控场景的LR、XGB，还是营销场景的DNN等，都是围绕着AI在进行。BI领域其实做的并不多。
这背后是怎样的原因？我个人认为，是因为AI对数据的需求非常强，当头部公司已经将内部数据价值挖掘到一定程度时候，他们非常迫切地需求引入外部数据，共同联合数据进行融合计算。同时，由于隐私计算又是一项门槛较高的技术，头部AI企业其本身技术能力也较强，所以使得隐私计算在初始阶段是于AI领域中应用更广泛。
然而在实际场景中，BI的应用面是更广的，如图是2022年信通院发布的《企业智能化报告》中的一张图，可以看到头部AI企业大概占比16%，其余84%的企业都是正处于数字化转型道路上的企业。这些企业更多是通过一些规则、数据分析、人工分析的方式进行数据处理。同时，国家也在强调，数据要素市场化的本质，是要赋能行业应用和实体经济，是要驱动经济的整体发展。所以，BI数据分析将会逐渐变得越来越重要，隐私计算技术整体也会从顶层的企业逐步向下渗透。
但是，BI的隐私计算面临着巨大的挑战，主要有如下几点：
第一，高应用性。刚步入数字化转型或者正在数字化转型进程中的企业，整体技术能力有限，高应用性对于他们来说就格外重要。SQL是平常使用最多的数据分析语言，使用上手门槛相对较低，但这项技术本身是非常复杂的，MPC（多方安全计算）技术也是非常复杂的。那么，使用SQL语言完成MPC（多方安全计算）并保证正确运行，则无论站在技术难度的角度，还是站在工作量的角度来讲，都是一个巨大的工程。
第二，即时性。SQL数据分析采用交互的方式，与AI建模不同，虽然需要调参，但本身交互没有那么强。但是SQL分析则需要频繁交互，此时对整体的响应速度和时间需求则更高，需要整个分析过程中都能够及时响应，如此对整体性能的要求也会非常高。
第三，安全性。多方安全计算需要保证中间结果没有任何信息泄露，而数据分析又需要看到每次交互的结果，并且需要通过频繁交互的结果调整下一个环节。两者之间天然存在矛盾。同时，SQL的灵活性非常高，如何保证基于多方安全计算的SQL分析整体的安全性也是巨大的挑战。隐语在这些方面提出了一些新思路，进行一些尝试和探索，也取得了一些成果，但是距离真正解决这些问题还有很长的路要走。
如图是隐语SCQL的架构示意，它是一种多方合作语言，大致分成两个部分：上部称之为SCDB，构建了一个SCQL数据库，可以认为部分程度延续了一个传统SQL数据库的样式。对于用户来说，可以直接发起一条传统SQL请求，请求首先会经过Parser，转为抽象的语法树，再通过Planner成为Logical plan。这两个模块我们只做了少量的改动，基本也是基于开源技术。
最大的挑战在Logical plan到Execution Graph的过程，传输过程实际是一个优化的过程，原本他们之间的差异不大，但是在隐私计算场景，他们之间的差异就会变的非常大。Translator实际是进行多约束条件下的最优协议选择，这件事的本质是无论AI还是BI，隐语的整体设计理念是明密文混合，即在保证安全性的前提下，如能明文计算则尽量不进行密文计算，因为密文成本相对较高。在整个计算当中有安全性的约束，同时会有数据类型、数据来源，还有数据状态，数据状态还会随着计算过程不断发生迁移和改变，再加之每一个协议适用的模式是不同的。我们会根据所有这些约束，最终选择一个最优协议出来，这就是Translator的本质。
那么怎样理解最优协议？如上图举例，此处有四种Group By，这四种Group By是为了适应不同场景。第一种是明文Group By，当密态计算时，Group Key以及聚合表达式处于单边，直接调用即可，一个典型的明文计算场景，无需密态计算性能很好；第二种是当Group Key与聚合表达式分散在两边，但聚合函数是求和，此时可以使用同态求和Group By来实现，只需将聚合列进行同态加密后传输至Group Key列，就可以进行聚合计算，性能也相对不错；第三种是Vertical Group By，此时Key处于多方，这件事情变的更复杂，隐语提供了新的、非常高效的、非常巧妙的算法，可以将分布在多方的Group Key进行高效的合并；最后，如果所有以上优化都无法进行，也就是纯密态Group By，此时会以满足安全性为前提，进而选择一个性能最好的协议。
Translator进行优化后，就会下发至下部的计算引擎，如图展示三个party构成，具体情况中两方或三方，则与采用的协议有关。计算引擎会先将DB的数据读出并进行计算，图中右下是SCQL计算引擎的架构，其中包含很多算子实现，也是明密文的混合，明文计算直接使用Arrow进行计算，密文使用隐语已经开源的SPU，如果大家对隐语有了解，就知道两个密态计算引擎完成这个计算。
Translator在进行协议转换时会执行CCL检查，其本质上是数据拥有者可以对数据做约束定义，Translator转换时就根据约束执行检查，如果SCQL不满足安全约束条件，则会被禁止运行。
左侧是目前业内常见的多方安全分析保障模型，如前文所讲SQL是非常灵活的，解决安全性的问题无外乎两种方式，一个是事前审核，二是事后审计，事后审计很好理解，所有的执行都需要存证。事前审核现在更多是通过人工，本质把安全性责任完全抛给了用户。
假设Party1写一段SQL，此时因参与方是三方，所以Party2和Party3用户都需要审核SQL，确认没有问题再执行。这就产生两个问题：第一，对于审核者来说工作量非常大，因为SQL是频繁交互的，且难免在审核中存在疏忽误判；第二，还是与SQL的交互式相关，每一个都需要多方审核，用户的操作体验较差。
而CCL的作用如图右，在事前审核之前，数据拥有方设置一个针对数据的CCL，是一次性的设置动作，此后用户每次提交SQL时，都需先经CCL检查，确认通过才会执行下一步，否则被禁止不能执行。接下来可以进行事前审查，即可运行至多方数据分析引擎中。
既然有CCL的安全性检查，为什么需要事前审核这个模块呢？因为，此处需要强调CCL不等于安全。与ACL相类似，不满足CCL约束一定不安全，但是满足CCL约束也不一定安全，所以CCL只是提供了辅助的工具。
CCL描述是一个三元组，数据拥有者对某一列进行约束，针对某个参与方进行约束。如Alice与Bob进行数据分析合作，有三列数据，设置CCL针对salary一列要求Bob参与者只有使用了聚合函数之后才可以看到。如此，Bob必须对salary列进行聚合之后才可以看到结果且只能看到一个统计结果，不允许看到明晰列数据，这就是CCL约束。
目前，CCL大概分为六种，未来可以继续细化和迭代，具体内容在隐语开发者文档中，此处不详细展开。从最上方没有约束的明文形式，性能优但安全性最低，到下方的全密态计算性能有损失，建议在满足安全需求的范围内，选择最偏明文的CCL约束。
讲到CCL，除了安全性，它还为计算提供一个hint，因为用户CCL本质表明了一个语义，即这一列数据需要在什么样的安全情况下进行保护。虽然在SCQL中没有明确把这一列选出，但是在计算时会根据hint，不会将这一列放到密文中去，因为已经允许别人选择，那么计算的过程当中，即使别人不把明文选出来，计算的时候明文计算肯定是没有问题的，即使对方看到也没有关系，所以CCL提供的hint可以帮助我们去做优化。
简要介绍此次SCQL发布的功能，当前为Preview版本，以目前我们对自己的要求来看，这些能力尚不完备，但Preview版本已经能够满足很多的场景，举了几个例子：
第一是营销场景，提供输出到文件的功能，仔细看即PSI求交。
第二是用户画像，通过使用Group By，我可以对2做统计，同时还支持Y条件，基于Y条件可以做跨表数据比较，以满足用户画像场景需求。
第三是在线策略，此前我们分享过保险的场景应用，这当中就是在线线上实施施略。为什么是在线策略？如图绿色可以看到，其顾虑是某一个ID，即在这一场景当中，要查询某一个人骗保概率以及骗保可能性，类似于风控中判断这个人的风险，只针对这一个人，所以是单独的查询条件。
如图是SCQL大概的Roadmap，根据现在的计划会分别在6月、9月、12月开源更多能力。当然具体发版会与此有些许差异，因为我们将基于大家对Preview版本的反馈建议，来酌情调整优先级。我的分享就到这里，谢谢大家！
