前言

　　云计算、大数据和人工智能的融合成为市场追逐的技术热点。云计算作为底层为上层大数据处理提供支撑，加速应用开发与服务创新;另一方面，应用的丰富激发数据体量增长，人工智能技术落地实现，构成Artificial Intelligence + Big Data + Cloud的大数据行业发展趋势。

　　该趋势下，各个厂商都在寻求更好的ABC技术共建方式，以解决传统大数据平台的一些常见问题：

　　1. 数据孤岛问题

　　传统方式建设企业系统时，不同部门或团队通常会构建独立的数据库，导致的问题有：同一份数据存在于多个业务系统内且内容不一致，缺少统一的数据标准、数据管理流程及可靠的管理工具，出现质量问题时往往无法有效追溯并修正。

　　2. 烟囱开发问题

　　“烟囱”式架构是传统企业系统开发的弊病，不同团队独立建设、独立开发服务和应用，带来安全、运维、升级、部署等通用功能的重复开发和投入问题，这种开发的低复用率带来了巨大资源的浪费，难以形成技术合力，也不利于团队间的研发管控和质量提升。

　　3. 技术门槛问题

　　大数据和AI的应用与运维十分昂贵，无论是对于平台建设、团队建设还是业务探索而言都会带来不小的开销。将数据服务化、资产化、在线化，以方便客户、技术开发人员和数据科学家使用，降低技术门槛是当务之急。

　　以上问题得到市场的广泛关注，许多企业(特别是跨地域多级别的大规模组织)都希望引入好用有效的数据管理与应用开发一体化平台，实现高质量数据交换共享服务。近日，星环科技高级研发工程师李光跃分享了他利用星环大数据云TDC搭建数据共享平台的探索过程，本文将具体解读如何借助大数据和云计算技术直指以上痛点，满足用户多元化、复杂的需求，降低数据开发、管理的难度。

　　TDC(全称Transwarp Data Cloud)是星环科技新一代智能大数据云平台，可以根据不同行业用户的需求，提供各种云上的数据服务解决方案。

　　数据交换共享平台需求

　　首先来看一下某真实企业对数据交换共享平台的现实需求。

　　需求主体：

　　某省大型银行服务类机构

　　需求背景：

• 　　该服务机构下有一百多家二级法人机构，需要为二级法人构建统一的基础设施，进行数据托管;

• 　　该服务机构只具备数据管理权，不具备所有权，需要为二级法人进行数据下发操作;

• 　　该服务机构已经部署星环数据仓库产品TDH，并在上面介入了十几个系统，每日任务量繁重。

　　需求痛点：

• 　　原有数据下发流程需要较多的人工辅助，时效性低，且缺乏灵活性，无法自助自定义下放数据内容;

• 　　二级法人的数据需要足够的隔离，不同法人之间不能看到对方的数据;

• 　　缺乏有效的权限管控，审计流程;

• 　　二级法人机构对数据的运用还停留在早期阶段，没有大数据平台辅助分析和决策。

　　在该场景中，随着数据量的日益膨胀，在缺乏统一平台管控的情况下，数据共享交换将保持在一个低效、低安全性的状态，不利于数据的使用和管理。针对该现实场景，我们对需求进行了进一步的剖析，具体转化为以下数据共享平台应具备的功能：

• 　　需要能够支持多租户，且租户之间完全隔离;

• 　　需要提供统一的数据中台，提供数据目录;

• 　　需要提供租户自助申请，管理员审批，自动化数据交换过程;

• 　　需要打通数据中台和租户的双向连接，且保证权限管控;

• 　　需要提供审计功能。

　　大数据云应对多用户场景

　　TDC兼具云应用特性和海量数据处理能力，同时提供方便的容器应用部署，对于数据共享的实现有极强的友好性，所以只需要进行逻辑上的梳理和相应的组件开发，就可以实现数据共享服务。

　　多租户模型构建

　　第一步，进行多租户模型设计，注意把握两个关键特性：隔离和共享。TDC提供原生的多租户属性，可以把每个二级法人映射为云平台上的每个租户。租户之间完全隔离，默认只能访问到各自所属数据。租户权限管控和数据管理分别由统一的权限与管理服务以及统一的数据服务提供。数据共享过程通过租户主动发出共享申请以及申请订阅实现。

　　数据共享交换架构初探

　　有了多租户模型，还需要针对企业需求，从共享过程出发，打磨数据共享交换架构的细节。

　　该企业的数据交换共享过程是：从原来的数据中心TDH集群，流转到每个法人租户，过程中保证数据对租户可见度的管控，同时允许租户主动参与数据共享。

　　因此我们将数据交换共享架构分为三大块(见上图)。左下角是该企业原有的TDH集群，存储了所有二级法人的全部数据，右下角是云平台层的系统租户，负责共享平台的数据服务和任务调度，上面一块代表各二级法人租户。

　　上述三部分分别具有一个安全管控组件，用于提供集群或者租户内部用户权限管控系统。每个安全组件间可通过配置互信，实现用户的认证互通。

　　前面的需求分析提到，二级法人(租户)必须能够自助地进行数据申请，因此要让租户可以感知TDH集群中的数据信息。为此我们在平台租户中部署了一套元数据管理组件，它将从TDH集群的消息队列中获取数据仓库中所有数据元信息。同时在每个租户内，内置一个数据目录组件，它通过连接到平台层的元数据管理组件，获得TDH平台上的数据信息，从而进行数据申请。

　　上面是数据共享架构的基本形态，现在来看一下数据从TDH流转到TDC的具体流程：

　　该过程涉及三个角色：租户内普通用户、租户管理员、平台管理员。首先普通用户登陆TCC，进入数据目录找到目标数据，进入数据目录组件搜索到目标数据后，选定需要申请的具体内容以及同步周期，生成数据申请工单到工单系统，由租户管理员进行审批。租户管理员同意后，系统会把申请传递给平台管理员，由他在TDC管理运维系统中处理这条工单。平台管理员审批通过，平台层数据共享任务组件将解析这条工单，生成数据流和工作流，负责从TDH集群上去抽取数据，然后写入租户内的分布式数据库，这样就完成了从数据中心TDH到二级法人租户内的数据流转。

　　架构优化

　　当前的架构设计已经基本满足了数据共享功能的需求，但是有没有值得提升的方面呢?是有的——数据的传输速度。这套原始方案的数据流转是数据流组件通过JDBC连接数据库实现的，数据传输的速度大约只能达到每秒5000条，对于动辄上亿条数据的数据流转，该速度会造成漫长的等待，极其不适合投入生产。

　　于是，下一步我们将优化重点放在数据的流转方式上。如何将数据流从上层逻辑转移到下层实现，充分利用平台分布式架构特性提升速度?我们开始寻找改进的突破点。

　　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. 全云化的平台

　　以上架构针对的是客户已经累积了数据并存放在物理集群的情况。特别地，如果是从无到有直接开始搭建云平台，相比之下就简单得多，此时可以直接使用平台层的数据平台作为数据中心。于是架构图简化为如下所示。

　　认证和权限

　　前面我们介绍了共享平台架构的演进历程，下面来讲一下租户对于的数据访问控制以及该过程中的身份认证是如何实现的。

　　Guardian基本功能

　　TDC的安全性由星环的产品安全管家Guardian统一提供保障，它的主要任务是用户认证和权限管理。Guardian支持多种安全特性，在该共享平台起重要作用的包括支持Kerberos协议、多粒度的权限控制、域互信。

　　首先，平台内的所有服务都开启Kerberos安全，保证数据加密和服务认证。

　　其次，Guardian实现插件式的权限管理。每个服务可以定义自己的权限管控，以插件形式和Guardian进行交互，比如可对数据库Inceptor进行表级、行级、列级的权限控制，并且所有的操作可审计。这对于数据共享平台十分重要，因为权限控制决定了数据的可访问性，决定了允许哪些数据从TDH流转到哪些租户。

　　然后是互信功能。互信提供了跨集群的服务认证，突破了此前无法进行集群间Kerberos认证的限制，是实现多集群数据共享的关键。注意，Guardian的互信功能只做身份认证，过程会并不会附带各集群内的权限信息。在涉及部署多个集群的情况下，两个服务间支持的互信关系有TWO_WAY trust(服务双方互信)、OUTGOING trust(单向信任外部服务)和INCOMING trust(单向允许外部服务信任)，从而灵活控制多集群之间的数据流动方向。

　　共享平台中的安全和权限管控

　　这里具体介绍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做资源限制等方式进行合理的资源控制。同时，由于星环自有服务均支持高可用，且系统中的任务可无限重跑，因此使平台具有高可用性。

　　当然，该数据交换共享平台还有很多方面可以优化，譬如更好的资源调度设计、添加更多类型数据的支持等。

　　大数据云让数据的运用更灵活，让数据共享交换变得随时随地、按需和便捷，充分调度计算设施、存储设备、应用程序等资源，满足用户多元化、复杂的需求，降低了开发、管理的难度。