深谈御膳房架构演进

御膳房-由来

为什么要有御膳房这个产品呢？

 

在DT时代，阿里集团战略中关键一环就是让商家通过使用数据来提升业务，也就是常说的数据赋能。初期，阿里通过官方数据产品的形式来满足商家的需求，让商家感知店铺的运营状况，利用数据驱动运营；但随着商家规模的变化以及对数据的认知发展到一定程度，官方数据产品很难满足商家定制化的需求。这时，需要一种更加灵活的方式让数据赋能商家，御膳房就是在这个战略下应运而生，让商家自主使用数据的地方。御膳房的产品形态是希望通过赋能商家及其合作伙伴，让其安全的利用阿里与自身的数据进行业务优化，从而驱动阿里电商生态向DT转型。

御膳房面临的挑战

御膳房需要是一个全新的产品模式，既要合作伙伴用到阿里和其它来源的数据，又要求合作伙伴在处理的整个环节保证安全，数据资产不泄漏。要完成上述这些工作，御膳房面临着多方面的挑战。安全方面：首先阿里作为平台方提供的数据的商业价值不能泄露：其次阿里平台上消费者的隐私不能泄露。同时，多个商家使用御膳房时，相互之间不能干扰，这就要求数据、资源、运行时环境等相互隔离，并可独立计量。

御膳房的模式探索

在御膳房模式探索中，发现了两类接近的产品模式：一是OpenAPI架构，该架构是数据导出型架构，也可以理解成插管式数据开放，如开放平台、数据市场。数据资产一旦通过API调用之后，调用方很容易对这部分数据进行缓存或存储，进而把这部分数据占为己有，这样就严重损害了阿里的商业利益，同时该架构并不能很好地解决商家及其合作伙伴后续面临的大数据加工处理的难题。

另一种思路是偏学术界的密码学体系，如同态加密或多方安全计算，前者是在加密的数据上进行任意计算，计算完的结果解密和正常计算结果一致，相当于用密码给数据资产加了一把锁，这需要消耗大量的计算资源；多方安全计算是指在缺乏可信平台的情况下，双方或多方需要知道共同的计算结果，但彼此的数据内容保密，这其中涉及复杂的加密、通信协议和交互，从而导致信息的交换效率较低。

也就是说我们当时同时面临了商业和学术上，两个看上去无法解决的问题。

御膳房架构模式

御膳房结合阿里巴巴的云计算和大数据的技术布局，以及阿里的商业生态布局，提出了“数据容器”的设想。御膳房架构的思想在于放弃了传统的数据导出模式，将数据加工成数据任务，同时数据加工的结果对接可信应用环境，做到数据可用不可漏。

该架构的核心流程包括伙伴开发、受控容器、授信对接、安全加固四部分。首先合作伙伴在平台上基于样本数据进行开发，所开发的代码提交给平台，平台提供一个不被商家及其合作伙伴接触的受控数据容器，用于提供真实数据计算和处理的场所；此后平台将计算结果对接可信的应用环境，包括集团内部的业务系统和可控应用容器如聚石塔，从根本上解决数据侧漏的问题；此外，该架构还提供数据安全体系用于安全加固，包括代码审核和出口控制，构建多层次的安全保护。

御膳房内部分为两个隔离的系统环境，一个是合作伙伴可以接触的数据开发环境，一个是由平台接管完全封闭的数据生产环境。在御膳房中，用户之间相互隔离。如上图所示，在开发环境中提供了用户可触及的样本数据，用户可以基于这些数据开发业务逻辑；生产环境提供的是真实数据，完全由平台控制，开发者是接触不到生产环境的。

御膳房的定位

基于上述的探索和架构模式的分析，可以对御膳房平台给出清晰的定位：它的核心价值在于数据赋能，目标是打造集团对外安全的数据加工容器。御膳房的核心抓手是：

• 数据闭环，安全可控；
• 商业闭环，互惠互利。

御膳房的基础数据加工能力

上图是御膳房提供基础数据加工能力的简单架构图。整个架构分为上下两层，下层是IAAS层，用于提供基础的云设施，如ODPS、RDS；上层是PAAS层，PAAS又分为开发环境和生产环境，该层提供了核心的数据开发工作平台，供商家或者合作伙伴灵活地加工、使用数据。阿里的数据经过抽样、脱敏之后放到IAAS环境中，IAAS环境又分为样本空间和生产空间，用户在PAAS层的开发环境中可以触及样本空间，因此可以完成基于样本数据进行业务逻辑的开发；业务逻辑开发完成后，需要将代码提交给生产环境，数据开发工作台通过工作流调度访问真实数据环境，执行的结果放在生产环境中，数据结果有几种出口，初期的出口是通过导出服务将ODPS的计算结果导入RDS中，RDS通过查询服务，以TOP接口的方式对接聚石塔，完成整个数据消费的可控闭环。

在该过程中，还涉及其他一些模块，如用于提供可视化操作的运维管理、横跨开发环境和生产环境的权限管理和元数据管理等。

除了基础数据加工能力外，御膳房还提供了简单的安全控制。例如，数据放到IAAS层前需要进行抽样、脱敏，分离出样本集和生产集；其次当合作伙伴或商家开发业务逻辑时，会有一些基于阿里商业的约束，例如当合作伙伴操作授权店铺数据时，要杜绝两种情况的发生：

1. 能跨卖家进行操作数据；
2. 不能进行类目或行业的聚合操作。

因此，御膳房的代码审核模块需要自动地对用户的SQL代码进行语义分析，与安全的语义规则进行匹配，进而完成商业规则的审核，如果自动代码审核不通过，则需要人工介入。对于出口控制，御膳房第一期的出口只能对接聚石塔。

御膳房在发展过程中也面临着新的需求：DT类的应用与IT类的应用最大的不同是它把数据当做资产，需要对数据进行复杂的探索、剖析和模型试验后，才能决定使用哪些数据，如何使用数据。数据探索、挖掘的实验工具和方法太多，如Python、R studio等，官方很难提供适合所有用户的数据探索产品，因此在御膳房上如何给客户提供数据探索的能力是一个必须要解决的问题；

高阶数据加工，仅仅使用SQL和MR操作数据是远远不够的，需要引入更多数据挖掘的算法包，以帮助用户进行深层次的数据价值挖掘。

御膳房的高阶数据加工能力

为了给用户提供数据探索能力，在御膳房中提出了虚拟桌面的架构，在虚拟机上安装常用的数据挖掘工具，如Python、R studio等，让开发者可以进行多种方式的探索工作，同时还获得了安全加固的能力。我们使用Guacamole在VNC Server和浏览器之间建立了一个代理，Guacamole与VNC Server进行通信，就像VNC Viewer和Server之间的通信一样，然后Guacamole再将需要显示的数据传给浏览器用Canvas绘制出来。选择Guacamole的原因是支持定制化（如登陆认证的扩展），与御膳房的租户模型进行对接；

在精准营销场景，很多围绕人的分析都依赖于底层消费者信息的数据，对于这类数据的访问和处理极易引发信息泄露风险；

御膳房提供了人群数据服务，通过数据服务的方式将核心逻辑和底层数据都封装在其中，同时通过前期的脱敏和后期的风控来避免开发者直接接触数据以及推导个体行为的可能。人群数据服务可以简单理解成一个函数，开发者可以指定输入参数，核心逻辑在函数中黑盒完成，同时结果会在风控之后给到开发者，确保敏感数据的安全。在御膳房中，提供了行为/属性圈人、IDMapping、人群放大、人群透视等数据服务。

人群数据服务能够根据用户的设定，进行圈人、透视等操作，但是无法用算法模型进行预测，为了实现人群的建模和预测操作，御膳房推出了海王星（即人群建模预测平台），

底层封装了阿里的海量数据，同时提供了灵活的特征构建和数据挖掘的高阶算法，让用户可视化的完成人群建模、训练、预测的工作流平台，轻松产出用户所关注的个性化定制人群。

 

上图是御膳房补充高阶数据加工能力后的架构图。与之前的架构相比，主要的差异包括：开发环境中增加了算法、探索环境；其次，在数据出口，增加了授信业务环境，例如阿里妈妈的DMP、阿里的短信通道、支付宝红包通道等。

御膳房的安全加固

随着御膳房平台上链路和提供的能力增加，因此数据风险性也随着增加，我们需要确保在每条链路的各环节的数据安全。在数据安全加固过程中有两个关键点：第一，需要对数据进行严格的隐式脱敏与安全分级；第二，对数据的处理全过程进行严格的监控和审计。

上图是御膳房的数据安全加固模型，该模型主要包括输入安全、处理过程安全、输出安全三个模块，输入安全又包括数据安全分级、合理授权和数据脱敏，确保隐私数据和商业秘密不泄露，同时也能规避一些法律风险：

• 数据安全分级是对数据进行简单打标，不同安全级别的数据在平台的可透出能力不同；
• 合理授权是当合作伙伴需要使用商家数据，可以通过订购的方式进行授权；
• 数据脱敏主要分为两类，第一类是对个人隐私敏感数据进行脱敏或模糊化，第二类是对可能泄露商业秘密的指标进行指数化或离散化。

处理过程安全主要关注代码行为、开发者行为：

• 代码行为是指开发者提交的代码中的逻辑操作，判断该操作是否有安全风险；
• 开发者行为是指开发者在平台上的具体操作，这些具体的操作是否合规；
• 此外，各个组件需要进行针对性的数据安全加固，确保能够感知开发者触发的安全风险。

输出安全包括出口控制和行为监控，输出安全是安全加固的最后一道闸口，需要确保敏感数据的不泄露。

在上图所示的架构中，标红的模块覆盖了所有的关键链路，如PAAS访问IAAS链路、开发和生产交互过、数据出口到授信环境的链路。

在PAAS访问数据时，首先数据需要经过脱敏模块和数据安全定级打标，才能送至PAAS环境中；其次PAAS环境访问时，探索环节提供的是远程图形桌面，避免客户低成本地获取页面上展现的数据。开发环境和生产环境交互过程的核心是自动代码审核，用户的代码逻辑需要和安全规则匹配，此外，还有行为监控，用户在生产环境和开发环境的所有行为都会通过行为监控采集关键信息，自动分析后，对于异常行为告警。

最后，通过出口控制限定数据最终的消费在授信环境中进行。

御膳房精准营销案例

上图是御膳房精准营销案例，用户是广告ISV，首先会上传种子用户，将种子用户当做正样本，通过御膳房提供的ID Mapping 服务和阿里数据进行关联，用户数据匹配之后通过人群画像功能对所关心的标签或属性进行画像；在具体营销前，需要对样本人群进行放大，对于低阶用户，直接使用人群放大服务；对于高阶用户，可以使用海王星人群建模预测平台构建模型进行训练，对更大范围的人群进行预测；放大后的人群营销触达后的效果数据可以回传到御膳房平台上，进行后续的效果分析和进一步迭代优化模型。

御膳房的整体安全闭环核心要解决的问题有两个：一是数据不被导出，避免造成潜在商业价值的损失，御膳房的对应策略是给予客户数据弹性加工能力的同时构建数据闭环；第二是消费者的隐私不被侵犯，御膳房与之对应的策略是开发过程中增加严格的数据脱敏工具集。

因此，御膳房的安全闭环由沙箱安全平台和业务安全策略两部分组成，其中业务安全策略是运行在沙箱安全平台中。沙箱安全平台如上图所示，主要包括数据合规工具、代码审核工具、出口控制和智能审计四部分。

业务安全策略包括生态内闭环、阿里内闭环和战略协议闭环。

展望与总结

展望未来：

• 在高阶处理阿里数据方面，现在比较局限在使用海王星（即人群建模服务）来满足营销的场景，支持更加广泛的高阶处理数据场景，是未来的一个挑战和方向；
• 需要解决基于明细数据的灵活分析洞察的安全问题，有可能面临PII（Personally identifiable information）攻击，即通过指向性标签或标签结合背景知识定位到个人，从而泄露用户的隐私，通过目前的脱敏工具不能解决问题，需要探索匿名化技术方向（如K匿名、L-多样性）；
• 整个处理平台支持实时流数据的采集、加工和消费也是一个方向；
• 通过paas层深度加工数据是有很高门槛的，因此我们希望可以抽象平台的使用场景，封装成业务用，提升用户在特定场景的使用效率，同时降低使用的门槛。

对于商家、ISV来说，御膳房像一个厨房，开发者就像厨师，可以在厨房中用自带和平台提供的数据原材料，加工完成数据大餐。

御膳房的愿景是：通过提供的数据安全容器能够帮助商家及其合作伙伴驾驭数据、驱动未来。