朴朴基于AWS EMR的数据沙盒平台演变

前言

伴随我司业务快速发展，相应的数据类需求大幅度增多，在数据开发人员有限的前提下，为满足业务部门数据分析、提取数据需求，需有个受控数据开放出口来缓解，这一数据开放出口即为数据沙盒平台原型。

数据沙盒平台主要服务于业务(非技术)+技术(非大数据)部门数据分析人员，缩短取数流程，提高数据分析效率，有效支持业务部门便捷地使用数据资产。数据沙盒平台建设的整个周期，安全一直是被重点关注的一环，在我司，数据平台主要构建在 AWS 云上，平台本身的安全性已通过 AWS 云层面的 VPC 网络和安全组隔离得到一定保证，那么平台建设过程中，还有哪些安全方面需要考虑？

数据隔离：数据使用人员应当只需关注自己相关业务域的数据，也只能访问这一单元数据。从数据本身角度，为降低被误操作的风险，应缩小被接触面；从数据使用者角度，只允许访问自己相关业务域的数据，可在数据使用过程中降低干扰提高效率。

数据脱敏：公司业务所生产的敏感数据，即使是内部员工(数据直接使用者)，也需要限制其访问权限和范围。

数据沙盒平台的目标是赋能数据分析人员，提高数据使用效率，但权限管控加强势必会降低整体使用便利性，如何把握安全与便利之间的平衡很考究功夫。建设过程是不断演进的，迄今为止，概括起来可以分为三个阶段：

一、数据沙盒 1.0

最初规划是构建一个单独 EMR 集群，功能简单只提供必需业务数据对外服务，数据同步基于 AWS S3 复制功能或 spark ETL 到 pupumall-sandbox 数据桶实现，定期清理这部分数据和一定程度访问控制。

1.1 集群架构

集群服务单元简述：

1. 沙盒数据主存储单元：S3 pupumall-sandbox 数据桶

2. 计算单元：单 master 架构 EMR 集群，提供服务组件列表 ZK、HDFS、YARN、Spark、Hive、Zeppelin(数据分析 web 操作台)、JupyterHub、Livy、Hue(数据下载)

3. 数据传输单元：

• EMR 集群直接访问 S3 pupumall-sandbox 数据桶进行查询计算
• Hue 提供 s3 目录文件查看及下载

1.2 存在的问题

基于 S3 作为沙盒底层数据存储，一种权限管控方案是依托于 AWS 提供的 IAM Role 服务，权限控制流程：

沙盒平台需按用户粒度管控其访问的具体数据对象，以 100 个用户映射 500 张表的授权场景为例，权限策略模型数量将膨胀至上千以上，若以 IAM Role 作为权限管控设施，数量繁多的用户策略和频繁权限变更操作会带来极高维护成本，因此，从运维角度考虑，基于 IAM Role 实现 S3 对象权限控制更适用于面向组件服务，而非个人用户。

其它缺陷：

• 未按数据单元进行隔离，沙盒用户不清楚自己需要对哪些数据进行分析，存在干扰和困扰现象；
• 数据同步、生命周期管理过程效率低下，使用数据及时率得不到保证，可能一个数据同步需求需要排期很久才完成；
• 对于敏感类数据，未做统一脱敏处理，一经泄露，造成数据安全事件负面影响极大
• 不支持按用户粒度进行管控，沙盒用户创建后，能访问沙盒平台所有数据

因此，数据沙盒 1.0 方案经过技术层面评估和相关业务方商讨后不予上线。

二、数据沙盒 2.0

数据沙盒 1.0 上线搁浅后继续调研数据管控方案，因 S3 存在管控措施缺陷决定基于 HDFS 作为数据沙盒平台底层数据存储，引入 Apache Ranger 组件进行权限管控，HDFS 与 Ranger 集成后可实现按用户级别管控其访问具体数据对象(文件级别)，支持频繁权限策略变更操作，且 Ranger 所拥有的丰富大数据管控插件也便于之后大数据平台安全建设工作推进。方案调研完成后定义为数据沙盒 2.0，EMR Zeppelin 集成 Ranger 可参考笔者另一篇文章：Zeppelin集成Ranger实现用户权限管控。

2.1 集群架构

集群服务单元简述：

1. 沙盒数据主存储单元：HDFS，Data Lake 图中背景淡黄部分

2. 计算任务单元：用户登录 zeppelin 编写 spark 代码(SQL 居多、Scala 少许)并提交运行

3. 主链路数据操作：spark 调用 HadoopFS 接口，操作前通过 HDFS Plugin 连接 Ranger Server 进行鉴权，权限校验通过即可对沙盒主存储 HDFS 进行文件 IO 操作，计算完毕后沙盒用户可根据自身需要，将取数结果写到 HDFS 个人目录空间

4. 次链路数据操作：spark 通过 EMRFS 对 S3 sandbox 桶(存储低敏感度数据)进行数据读写

5. 取数单元：沙盒用户通过 Hue 组件对 HDFS 个人空间存储的数据文件进行 Download File 操作

2.2 数据管理

相比数据沙盒 1.0，数据沙盒 2.0 在数据管理层一举解决掉数据同步、数据脱敏、数据管控和数据生命周期管理问题。

数据同步：自动化管理数据同步任务，支持按用户自定义同步方式、数据类型、同步周期等，同步信息固化在 mysql 和 redis 中，避免重复运行同步任务，造成资源浪费

数据脱敏：在数据同步过程中按脱敏规则对数据内容脱敏处理，支持自定义脱敏规则

数据生命周期管理：定期自动老化沙盒数据，支持全部、局部老化等多种操作类型

2.2.1 数据同步

同步链路简述：

• 数据表：按普通表、hudi 表、分区表、非分区表四个属性划分，根据条件有选择性进行过滤和脱敏处理。
• 数据目录：递归判断是否有子目录，按目录粒度根据条件有选择性进行过滤和脱敏处理。
• 待数据同步到沙盒集群 HDFS 目标路径完成后，将元数据信息刷成 hive 表提供给沙盒用户访问使用。

2.2.2 数据脱敏

启动 spark 同步作业，构建 DataFrame 或 RDD 从 S3 抽取原始数据集前连接脱敏策略配置中心读取任务配置，判断是否需要进行脱敏处理，最后将数据集写入沙盒集群 HDFS。

2.2.3 生命周期管理

数据生命周期管理链路说明：

• 当 is_enable 标识为 0，表明此数据单位(表或数据路径)为过期状态，执行销毁处理流程，若有存在表 schema 信息同步清除。
• 当 is_enable 标识为 1，表明此数据单位(表或数据路径)需执行数据生命周期判断逻辑，会按运行时间、执行时间和同步时间进行比对检查，决定对该数据单位做销毁还是同步处理。

2.3 方案实践

数据沙盒 2.0 方案在 2020 年 8 月中旬调研开发完成，因在数据管理部分尚存一些 bug 和功能性缺失，为之后沙盒平台更加稳定、高效地对外服务输出，内部另行规划 2.1 增强版，针对性做了若干优化：

• 支持 ranger + hive 集成管控
• 数据同步性能优化、bug 修复、触发机制完善、增加同步类型
• FSUtils 目录读写操作优化
• 数据生命周期管理任务支持多并发运行
• 表 schema 生成逻辑优化

以上优化项全部完成后，于 2020 年 9 月初正式上线对外提供服务。

那么，数据沙盒 2.0 是个优秀的解决方案吗？

理想是美好的，现实是骨感的，很明显它并不是，数据沙盒 2.0 只是在当时阶段内能实现的一个有效数据管控解决方案。从数据沙盒 2.0 架构中能明显察觉整套架构很臃肿且有瓶颈点，在上线后运行的半年间，随着沙盒用户使用群体的扩大(市场、采销、法务、技术支持、产品、服务端等)，果不其然地陆续暴露了一些问题。

2.3.1 数据存储

方案设计之初即已知存储在未来会成为一大瓶颈，但因为 S3 在当时阶段无法实现有效的管控措施，迫不得已只能采取此方案。

存储成本极高：沙盒用户进行较大规模数据分析时，计算过程中会带来很高的磁盘 IO 操作，因此沙盒平台 HDFS on EBS 采取 ssd gp2(¥ 0.746/每 GB 每月，PS:EMR 不支持 gp3)作为存储介质，成本约为 S3 的 3 倍。什么概念呢？以现阶段沙盒存储 9TB 数据计算，算上副本和冗余部分：9TB x 1024 x 2(副本) x 1.2(20%冗余) x 12 月 x 0.746(存储单价) ≈ 19.8w / 年，但实际上沙盒用户的数据使用需求远不止 9TB 空间能满足的，经评估至少为现有的存储空间的 3 倍，那意味着单存储成本将膨胀到近 60w/年。沙盒 2.0 平台运营期间，基于昂贵的存储成本考虑，有过压缩业务部门数据扫描范围需求达到降低成本目的(如用户行为相关数据仅提供 14 天数据分析支持)，很明显此行为是不可取的，相比于存储成本的增加，如何让数据有效地流动起来为业务赋能才是明智之选。

存储空间扩展性受限：HDFS 支持无感知水平扩展，但扩展操作需要一定时间来达成，无法像 S3 一样实现存储空间弹性使用。

存储服务可用性：若 EMR 集群主控/存储节点崩溃(我司多次出现)，会对数据完整性和沙盒平台服务可用性造成明显影响。

2.3.2 数据同步

同步逻辑复杂：从上文数据同步流程图可知，为支持数据安全落地到沙盒集群存储，数据同步实现复杂度极高，而复杂度的提升与(运维难度 &出错概率)是成正比关系。事实亦如此，在整个数据沙盒 2.0 平台运营期间，数据同步直接 &间接所引发的使用问题平均 1~2 次/月，再加上 2021 年年中开发此同步功能的同学离职，其复杂的代码逻辑实现、深层嵌套的臃肿代码结构给接手的同学造成极大困扰，不易维护。

同步任务资源开销大：每日维持沙盒数据同步任务运行资源开销约：CPU 500 核+、内存 1000GB+

同步延迟高：数据沙盒同步任务运行时间集中在早上 6 点~早上 9 点，原因在于需错开数仓 ETL 和报表任务计算高峰，减少任务间争抢资源现象，因此，沙盒用户能使用到的最新数据永远都是延迟 6 小时后的。

2.3.3 数据管控

沙盒 2.0 体系中管控对象为 HDFS 文件，给沙盒用户配置的权限策略为数据路径，这直接导致原始数据源(路径、表)与沙盒不是一一匹配对应关系，需有专人核对这些信息再整理成权限策略刷到沙盒 Ranger 中，因此，日常数据管控审核、配置、调整工作量多且繁琐。

另外，在导数环节也缺乏有效的管控措施，沙盒用户只要拥有 hue 和堡垒机账号，即可将沙盒上业务数据直接导出到个人主机，更有甚者，某些业务部门人员直接在社交平台工具上进行数据文件分发传阅，数据安全泄露风险极高。

2.3.4 数据一致性

因沙盒平台存储数据是经过再同步和清洗脱敏的，同步过程中可能存在部分数据内容与数据平台生产环境不一致问题，这就给沙盒用户使用数据时造成困扰，遇到此问题时往往需要数据侧开发人员介入排查，双方人员费时费力。一般数据分析场景下，可能表象不太明显，当涉及业务部门数据报表开发时，将给报表开发整个周期带来多重影响，拉长整个开发周期。

三、数据沙盒 3.0

自数据沙盒 2.0 上线以来存在多方面痛点：存储、同步、管控、一致性等，为更好地服务沙盒用户，提升整体数据使用体验，于 21 年 Q2 季度再度启动沙盒架构优化相关研究，方向为 AWS EMR 集成 Ranger 实现对 S3 数据访问管控。基于 AWS 官方提供的解决方案进行实践，因技术方案描述晦涩难懂，实践过程踩了很多坑，不由感叹 AWS 所提供的技术方案忒不靠谱。

该方案引入的安全方面组件：

用户认证：Kerberos 组件，用于数据服务访问是否允许认证

用户鉴权：Ranger 套件，提供细粒度访问权限控制

SSL 安全通信协议：对组件间通信进行加密，例如 ranger admin <--> plugin、emr<-->ranger、emr<-->s3 等

SecreteManager：AWS 证书托管服务，如 EMR 上的 Ranger Plugin 与 Ranger Admin 要做双向 TLS 认证，此证书可依托于 SecretManager 管理并直接被 Ranger 引用

IAM Role：AWS 服务，提供服务级别访问权限管控

RecordServer：SparkSQL 运行时所有元数据和数据请求都会经过该服务，提供细粒度访问控制

参照 AWS 所提供的解决方案逐一实现，调研结论是限制太多，方案暂无法上线使用，具体为：

支持：

• select/insert 操作，如 SHOW DATABASES、SHOW TABLES、SHOW COLUMNS、INSERT OVERWRITE 等

不支持：

• CREATE TABLE、UPDATE TABLE、ALTER TABLE(有限)、DELETE FROM
• Hudi 表(我司数仓全部是 hudi 表)
• 行/列筛选器或数据掩码

受 AWS sparksql plugin 实现思想启发，结合沙盒平台用户 95%的使用需求都是 sparksql 实现，转为调研 sparksql 层开源管控解决方案：spark-ranger，该项目专注于提供 sparksql 层细粒度权限访问控制，权限控制实现代码逻辑清晰，经深入源码走读和实践后，sparksql 层数据访问管控基本满足沙盒平台使用场景需求，不存在像 AWS 所提供的技术方案中有大量权限管控实现缺失，比较遗憾的是该项目 2020 年捐赠给 apache submarine 项目并重命名为 spark-security，相关 issue 解决不勤，若采取此方案，今后使用过程中二次开发改造无法避免。

通过对 spark-security 改造适配沙盒平台使用场景，较彻底地解决沙盒平台用户访问 S3 数据权限管控问题，即沙盒平台可直接复用生产环境数据平台数据，那相匹配的数据管理方案自然也要有所改变，相比数据沙盒 2.0 架构，新沙盒平台虽然对外提供的服务出口不变，但底层数据存储和数据安全管控方案已完全蜕变，因此将其命名为数据沙盒 3.0。

3.1 集群架构

集群服务单元简述：

1. 沙盒数据主存储单元：我司 AWS S3 正式数据桶(Data Lake 图中背景淡黄部分)，HDFS 用于存储计算任务日志和个人结果数据

2. 计算任务单元：用户登录 zeppelin 编写 spark 代码(SQL 居多、Scala 少许)并提交运行

3. 主数据操作链路：spark 启动计算任务前会对用户提交过来的 SQL 进行解析，通过 Ranger SparkSQL Plugin 连接 Ranger Server 进行鉴权(库、表、字段等)，权限校验通过后 Spark 再使用 EMRFS 连接 S3 进行数据扫描(集群设定 AK/SK 策略为只读)

4. 次数据操作链路：与数据沙盒 2.0 方案不同的是，新沙盒不再使用 HDFS 作为主存储，HDFS 仅服务于 EMR 组件和用户个人空间使用需求，数据使用过程中用户可根据自身业务需要，将分析结果写到 HDFS 个人空间，读写时会连接 Ranger Server 进行鉴权

5. 取数单元：沙盒用户通过 Hue 组件对 HDFS 个人空间存储的数据文件进行 Download File 操作

3.2 S3 数据管控实现

某种意义上说，数据存储是推动沙盒平台架构演变最重要的因素，没有之一。那么在数据沙盒 3.0 架构中，想要将数据存储切换到 S3 并有效地管控访问权限，如何实现呢？原理说开了很简单，控制 spark 入口即可，大致分如下几个方面实现：

3.2.1 沙盒 emr 集群访问策略调整

第一步：创建专属 IAM Role 赋予沙盒 emr 集群，Role 策略中设定对 S3 正式数据桶仅有只读权限，对沙盒 sandbox 桶有读写权限

第二步：emr 集群所有组件服务和节点全部引用此 IAM Role，直接从源头杜绝沙盒 emr 集群服务对 S3 正式数据桶的写操作可能

3.2.2 spark-security 改造

第一步：当前 spark-security 项目还嵌套在 apache submarine 中，对 spark、ranger 版本支持较低，后期数据沙盒平台计划升级至 emr6 和 spark3，因此第一件事就是将其从 submarine 项目中剥离，兼容性适配 spark-3.1、ranger-2.1 版本后重新构建打包。

第二步：原生 spark-security 项目中不支持 insert 操作管控，而沙盒用户广泛使用 insert overwrite 语义取数，因此需修改 authorization 实现增加 insert 操作鉴权。

第三步：在我司 sparksql createTempView 这一操作被数据分析人员中广泛使用，不比其他 DQL、DML、DDL 类型 sql 语句，createTempView 所生成的执行计划比较特殊，不会生成查询对象实体，因此该语义执行时会绕过 spark-security 鉴权体系。换而言之，只要沙盒用户知道 S3 正式桶数据路径，即可通过 createTempView 语义直接查非授权访问的生产数据，使沙盒鉴权管控形同虚设，这也是迟迟不能突破的一个环节，期间一度萌生将 createTempView 语义禁止执行的策略来规避，可现实情况不允许如此骚操作，这将给沙盒用户日常使用带来极大的不便。所幸的是，在不久之后的一次例常研究 sparksql 执行过程中发现 createTempView 操作会携带 path 信息，通过改写执行计划可实现 s3 桶路径信息再一步处理，如禁止 createTempView 操作指向 S3 正式数据桶，即可符合要求。

第四步：脱敏策略失效处理。

研究 spark-security 过程中在 github 上有看到关于脱敏失效的 issue，详细研究验证后，确实如其所言，在以下两个场景会出现 data mask 失效：

场景一：对某字段配置 mask 策略后，当对该字段使用 UDF 时，查询结果会出现 data mask 失效问题

解法：升级 spark-security 到最新版本，该项目维护者在最新版本中已解决此问题

场景二：多表 union 时，data mask 只对第一个 SQL 代码段脱敏字段有效，其他语句字段脱敏策略会有失效问题

一开始以 join 使用场景验证也出现 data mask 失效问题，排查多天无果，对 spark-security 项目 data mask 部分代码实现深入研究和 debug 验证，最终发现是脱敏策略执行问题，虚惊一场。但多表 union 场景时确实会如此，原因是 union 语句提交后会生成多个查询执行计划，而 spark build/explain plan 时只会生成一个执行计划，导致脱敏策略只应用在第一个执行计划中，此问题与数据开发侧同学研究后判定改造幅度极大，评估后暂不做改造

解法：底层基础数据脱敏+上层 ranger 侧对需脱敏字段列添加访问限制 policy

3.2.3 访问对象抽象

基于 spark-security 管控对象为表的前提，加上今后将规范化对外提供数据服务(以表形式不再以数据路径提供)，因此新沙盒平台从数据平台生产环境按需同步表 schema 信息，沙盒用户能感知的基础对象为：库-表-字段，通过对库-表-字段访问权限管控限制用户扫描数据范围；

3.2.4 apache zeppelin 改造

第一步：沙盒 emr 集群集成 spark-security 后，当发生鉴权不通过时，使用 emr 自带的 zeppelin-0.9 会存在异常栈信息捕获时报空指针错误，排查相应代码实现 SparkSqlInterpreter.java，原因是未做异常捕获处理，查看 release 信息和比对 zeppelin 版本可通过升级至 zeppelin-0.10 解决。

第二步：修改 zeppelin 源码，屏蔽特定解释器

前文所提 spark-security 仅支持管控 sparksql 层，沙盒平台上还有 spark scala、pyspark 之类的使用需求(搜索组人员)，该类代码执行机制与 sparksql 有所不同，只需构建 RDD 或 DataFrame 调用 FS 接口即可直接对 S3 生产正式桶进行数据扫描操作，因此，非 sparksql 的计算任务不能跟 spark-security 走同一提交入口。

解法是改造 zeppelin notebook-paragraph 实现，通过修改解释器 spark Interpreter 入口屏蔽掉非 sparksql 的代码执行，诸如：spark.scala、pyspark、sparkr。

第三步：新沙盒平台支持 spark scala 编码需求

上述 zeppelin 改源码操作后也不可避免地带来一个问题，即搜索组人员非 sparksql 的数据使用需求无法在新沙盒平台上运行，起初想法是摒弃这部分使用需求，毕竟占比不大(1~3%)。最后，另辟蹊径找到解法：单独构建 EC2 实例部署 zeppelin，该实例引用有限制的 IAM Role，修改 zeppelin spark interpreter 在启动 spark application 时携带专属 S3 AK/SK，即可限制此 zeppelin 上用户所提交的 spark 任务读取 S3 正式桶数据。

3.3 数据管理优化

3.3.1 数据同步

沙盒 3.0 架构中已消除沙盒 2.0 架构中真实数据再同步这一环节，收敛掉同步中间过程和组件后可明显提高沙盒平台整体运维效率，而沙盒集群要访问 s3 正式桶数据，还需实现 hive 表元数据同步，因此我们针对性开发了一套 hive 元数据跨集群同步工具：

3.3.2 数据脱敏

由沙盒 2.0 架构中数据同步过程进行数据内容脱敏处理，变更为在数据展示过程中进行数据脱敏操作，ranger 自带的五种脱敏策略基本能满足业务需求，后期可根据需要自定义脱敏策略并集成到 ranger 上。

3.3.3 数据生命周期管理

沙盒 3.0 架构中数据同步过程演变为 hive 表 schema 信息同步，因此这里的数据生命周期管理对象泛指 hive 表 schema，分为以下几个方面阐述：

管理对象：表 schema

表同步机制：将生产环境表 schema 同步至沙盒集群，确保双边表 schema 信息一致

数据扫描范围限制：使用分区表方式限制沙盒用户扫描数据范围(例：用户行为表需限制沙盒用户访问 1 个月内数据，那么只需同步用户行为表一个月的分区 schema 至沙盒 emr 集群即可)，非分区表全量同步不做限制

生命周期滚动：按需配置表留存周期规则，自动化实现相应滚动操作，如创建/删除表、表 schema 信息保留(一周、一月、一年、全量等)

3.4 方案实践

沙盒用户侧收益

1. 查询计算效率提升(通过升级 spark3)

• 自动优化倾斜 join 操作，如 sql 中存在多 join 查询场景有明显改善
• 自适应调整 stage 分区，提升 shuffle 过程效率，加快数据扫描速度

2. 数据同步及时性提升

• 加速业务数据接入沙盒平台流程，减少对数据侧开发人员依赖，提高数据使用效率
• 消除当前沙盒数据二次同步延时(小时级)，即数据沙盒用户可以最快速度查询到数据平台 ETL 处理结果数据集
• 未来数据平台实时数仓推进上线后，只要配置好相关库-表权限，沙盒用户即可进行近实时数据分析和业务决策

3. 数据查询范围提升

• 支持周期更长的表数据查询(＞2 周)，典型如：用户行为、日志等数据

4. 表 schema 与数据平台生产环境一致保持

• 数据报表类需求：避免在沙盒环境开发完，上线到数据平台生产环境后出现元数据不一致问题，影响开发周期
• 其余正常数据分析需求操作，保证库、表、字段等元数据信息与数据平台生产环境无差别，消除数据异常排查环节

沙盒平台管理侧收益

1. 权限管理优化

• 支持按细粒度数据对象级别(库、表、字段)进行授权和管控
• 支持按组、用户粒度授权
• 脱敏策略集中化管理

2. 沙盒平台整体运维提效

• 消除旧沙盒平台数据同步过程臃肿链路，降低数据同步出错概率，简化运维复杂度，方便问题定位
• 简化沙盒平台数据同步配置工作，减少人为配置误操作的同时提高配置操作效率

3. 成本优化

• 存储成本减少 90%，＞ 60w/年
• 计算成本减少 30%~40%，约 500 核+CPU、1TB+内存

自沙盒 3.0 平台上线以来收到很多正面使用反馈，也确实有效地解决了旧沙盒平台存在的诟病问题，数据沙盒 3.0 平台在权限管控和便利性之间算是达到一个平衡，在成本缩减的同时能明显提升数据平台下游用户的数据使用服务质量，算是我司数据沙盒平台演变的最终版本，之后不再进行大规模架构方面调整优化。依现状看，未来一段时间以内(朴数开发平台上线前)，可将其作为支撑业务部门在权限受控的前提下，还能最大范围地灵活使用数据平台资产的一个通用数据服务出口，助力提高业务部门自助化使用数据效率。

四、结语

自 2020 年数据沙盒平台上线以来经历了三个版本演变过程，至数据沙盒 3.0 算是阶段性画上一个句号。一言以蔽之，在这个过程中我们逐渐从控制数据文件转为控制数据对象（表/分区/字段），控制实体转为控制视图，最终无需复制 AWS S3 实体对象即可实现对用户访问权限施加管控，以极轻量的方式支撑大量需要个性化权限控制的用户数据隔离需求。

数据平台的安全建设工作是紧随平台支撑业务量和业务种类的增多而不断演变，并不是一项具备独立性质的间歇性工作项，随着我司接下来实时数仓、朴数开发平台访问安全管控和平台服务对接大 UC(用户中心)的推进，仍有很长的路要走，不过也许不再以数据沙盒的形态示人。

作者简介：

吴建阳，就职于福建朴朴信息科技有限公司，担任大数据运维负责人，主要负责朴朴大数据(云上/自建 IDC)离线计算、实时计算、数据湖、OLAP 等基础平台设施维护。