数据共享交换架构优化
1、一级进阶
Inceptor数据库通常以HDFS为底层存储，所以既然走上层JDBC太慢，我们是否可以走底层数据拷贝以提高速度，只要从存储层转移数据，完成后按照表的schema再建一张表就可以了。
根据这种思路，我们在右下角新增了两个namespace：tdc-jobs负责执行抽取数据，dataplatform作为平台层的数据中转区。如下图所示：
元数据管理组件记录了表的schema信息，租户在提交数据申请的时候，任务的描述中就包含了所申请数据所对应的schema。
而数据流转的过程从简单的用JDBC实现，改变为：
第一步，工作流借助数据连接器连接到TDH的数据库，在TDH内执行一条insert overwrite 的sql语句，将数据导出到HDFS集群的某个具体位置；
第二步，工作流引擎会在tdc-job namespace下建立一个任务pod，pod负责将数据从TDH集群get下来，并put到租户内的HDFS中；
第三步，工作流引擎在租户内的数据库中，根据已获得的schema，对来自TDH的共享数据建立一张外表，最后整个任务完成，发出通知。
这种架构的确比第一种快了很多，但是传输跨集群的大文件时速度明显受限于网络和IO，能不能再快一点呢？
2、二级进阶
答案是可以的。
Hadoop提供了一套非常快速的拷贝方式——distcp，它充分运用集群的分布式能力，通过datanode之间直接通信读写，在HDFS集群之间并行的拷贝大量数据。
于是我们利用distcp生成了第三种方案：分别在平台层的YARN和租户内的YARN启动distcp任务（YARN负责管理distcp任务的生命周期），通过两阶段拉取的方式将数据拉入租户内的HDFS中。
两阶段拉取，是指数据从TDH到二级法人租户的过程分为两个阶段：首先数据从TDH被拉取到中转区，然后再从中转区拉取到租户。
为什么采用两阶段拉取？原因在于，TDH集群和租户开启Kerberos验证后，它们之间本身是不能互相访问的，而目前distcp只支持底层的Kerberos互信，因此必须在容器内做相应配置实现平台层到TDH以及租户到平台层的互信（后面会详细讲），否则datanode之间的通信将无法通过认证，所以拉取过程需伴随互信分为两个阶段。
3、全云化的平台
以上架构针对的是客户已经累积了数据并存放在物理集群的情况。特别地，如果是从无到有直接开始搭建云平台，相比之下就简单得多，此时可以直接使用平台层的数据平台作为数据中心。于是架构图简化为如下所示。
认证和权限
前面我们介绍了共享平台架构的演进历程，下面来讲一下租户对于的数据访问控制以及该过程中的身份认证是如何实现的。
1、Guardian基本功能
TDC的安全性由星环的产品安全管家Guardian统一提供保障，它的主要任务是用户认证和权限管理。Guardian支持多种安全特性，在该共享平台起重要作用的包括支持Kerberos协议、多粒度的权限控制、域互信。
首先，平台内的所有服务都开启Kerberos安全，保证数据加密和服务认证。
其次，Guardian实现插件式的权限管理。每个服务可以定义自己的权限管控，以插件形式和Guardian进行交互，比如可对数据库Inceptor进行表级、行级、列级的权限控制，并且所有的操作可审计。这对于数据共享平台十分重要，因为权限控制决定了数据的可访问性，决定了允许哪些数据从TDH流转到哪些租户。
然后是互信功能。互信提供了跨集群的服务认证，突破了此前无法进行集群间Kerberos认证的限制，是实现多集群数据共享的关键。注意，Guardian的互信功能只做身份认证，过程会并不会附带各集群内的权限信息。在涉及部署多个集群的情况下，两个服务间的互信关系有TWO_WAY trust（服务双方互信）、OUTGOING trust（单向信任外部服务）和INCOMING trust（单向允许外部服务信任），从而灵活控制多集群之间的数据流动方向。
2、共享平台中的安全和权限管控
下面具体介绍Guardian的安全功能如何在数据流转过程中发挥作用。
我们已经介绍过，数据共享平台架构的三大块位于不同域的三个集群，每块内置安全管控组件Guardian。集群间能够彼此通信，是因为进行了Kerberos跨域互信设置。
三个集群中的Guardian组件都有一个预置用户dataadmin，该用户并不对应真实的实体，但扮演三个重要角色：一是作为跨域认证的主体；二是代理租户访问TDH，保证Inceptor到HDFS只写入租户可见的数据；三是启动任务实现HDFS集群之间的数据复制。这三个任务保证TDH只把租户可见的数据写入对应租户。
假设当前租户1中有一个普通用户u1，u1登陆共享平台后，可以访问租户数据目录组件查看TDH集群中包含的数据。u1进行数据采样时，是租户集群以租户管理员A的身份去访问平台端元数据管理组件的。元数据管理组件默认以dataadmin用户登陆，当它向TDH集群的Inceptor数据库进行数据采样时，是以dataadmin身份进行认证，代理管理员A进行数据访问的，而TDH集群端会有一个和租户管理员同名的用户，该用户受到行级权限的管控，因此管理员A在TDH中的权限决定了整个租户的数据可见度，使每个租户只能看到属于自己的数据。
平台层的dataadmin能够登录TDH内的服务的原因在于互信。当TDH端的Guardian对来自平台层的登录请求进行解析，并发现请求并不源于自己所在域时，会查询该域是否属于互信域，如果互信就转到对应的Guardian中进行认证，决定是否通过认证。
在数据流转过程中，平台端的dataadmin负责读写数据或者在平台端和租户端启动distcp任务，而TDH内的dataadmin和租户内的dataadmin只是服务于跨集群的权限中继。dataadmin用户的存在简化了域之间用户身份认证的管理和配置复杂度，可预想如果没有dataadmin，容器内管理的用户和安全配置文件数量将大幅增加。
总结
以上内容（及上篇文章）主要介绍了数据共享交换架构的关键设计。此外我们还通过设定Inceptor数据库和YARN的执行队列、对Namespace和Pod做资源限制等方式进行合理的资源控制。同时，由于星环自有服务均支持高可用，且系统中的任务可无限重跑，因此使平台具有高可用性。
当然，该数据交换共享平台还有很多方面可以优化，譬如更好的资源调度设计、添加更多类型数据的支持等。
大数据云让数据的运用更灵活，让数据共享交换变得随时随地、按需和便捷，充分调度计算设施、存储设备、应用程序等资源，满足用户多元化、复杂的需求，降低了开发、管理的难度。
相关阅读：
热门专题
