数据中台_数据中台服务 调度需求与定位

1 引言

随着市场对数据价值的认可，促进了数据在各行各业的爆发式增长，同时带来了数据应用上各种各样的问题，怎么才能发挥更大的数据价值，成为各大企业的重点工作。
数据中台的建设，将数据能力覆盖到公司的任何角落，数据赋能业务，促进业务发展，本文从数据中心的概念、架构、建设理念等角度切入，了解如何通过中台解决问题，帮助业务发掘数据价值。

2 中台概念

2.1 数据中心建设面临的痛点

数据中台主要解决大数据快速发展过程中所遇到的各种棘手问题

• 数据接口不一致
• 数据质量差
• 数据使用效率低，耦合度高
• 资源浪费严重
• 数据资产管理混乱
• 数据接入成本高
• 数据流通性差
• 数据生产链路长
• 数据业务打通难

2.2 数据中台定义

中台是一个企业架构，对数据能力进行抽象，并且把数据的治理以及资产的管理统一抽象出一种通用能力，把这种数据使用的门槛降到一定程序，让更多的用户更容易去利用数据，通过数据去挖掘一些业务价值。
数据中台优势分析：

• 打造一站式数据开发平台：
• 建立统一的元数据中心
• 提供配置化的数据服务托管能力
• 建立一个覆盖全生命周期的数据治理体系
• 制定数据生产和采集标准
• 建立数据湖，数据仓库及周边体系
• 推动数据中心化
• 通过AI建设自动化平台，代替人工大量重复工作

3 数据中台架构

3.1 数据中台定位

数据中台服务于业务中台和业务前台，数据中台主要由数据的生产接入，数据的处理加工，数据资产，数据治理，以及最终对外提供的数据服务组成。

• 数据的生产手收集处理存储和服务等环节进行封装，面向不同层级的用户和业务提供不同的服务。
• 数据标准化建设过程中，避免数据的重复性建设
• 对于数据进行全链路的治理
• 最终目的：屏蔽数据处理的复杂性，让用户更方便更高效的使用自己需要的数据，满足业务快速发展的需求

3.2 数据中台组成

架构最低层是大数据基础设施，结合云技术，提供标准化、可弹性高、可用的统一云服务的能力。

3.3 数据中台特点

• 平台化 以平台形式为用户提供能力，比如数据开发平台、数据服务平台、数据治理平台、以及一些数据接入能力

• 标准化

  • 流程标准化：如何采集，存储
  • 数据资产标准化：数据库表、库、字段命名

• 中心化 数据中台相当与把数据放入中转站，把数据汇总和分发，然后让用户统一管理

• 智能化 AI平台

• 服务化 数据中台的能力通过服务的形式对系统推进、展现给业务，去服务各个业务线

• 价值化 不同场景不同价值

3 数据中台统一服务

3.1 统一服务问题

• 数据和接口复用，耦合度高。传统的数据应用使用场景更多是直接暴露数据，服务直接操作数据表，如果数据表出现改变，直接影响建立在这个表上面的服务，如果服务通过数据接口去访问数据，无论数据表怎么变化，数据接口不会改变，数据接口提供给服务最新版本的数据，相比较于数据表，数据接口对于服务来说更加友好
• 发现和理解数据，通过数据字典来维护元数据，使数据信息逐渐落后于实际情况
• 标准和统一管理，对于数据接口，一直都是服务需要什么数据就开发什么样的数据接口，导致出现各种各样的接口，而且对于一个数据资源，不同人开发的接口是不同的，重复开发，重复利用，造成资源的严重浪费
• 数据接入效率低
• 服务使用审计：数据接口大多都是A传B ，B传C，这样扩散起来了，当我们更新一个数据表之后，考虑不全所有的接口情况会造成对服务的不明确影响，而且有一些私密数据会在扩散过程中出现安全隐患。

3.2 怎么解决统一服务出现的问题-数据服务

• 一站式的开发和运维能力，它可以通过SQL，配置等与元数据打通，自定义数据服务；
• 全链路打通，数据之间存在”血缘关系“，通过数据之间的联系，可以追溯数据的产生-数据加工-数据最终使用，是一个全链路打通的一个状态
• API集市，对于一张数据表，把所有这张表提供的输入输出API展现出来，避免按照服务去开发接口，而是我提供我所有的接口给你，什么服务都可以调用我API集市中的API接口，这样可以避免数据复用。
• PULL和PUSH模式
  • PULL模式：用户通过发送数据访问到数据接口，数据接口对请求进行解析和优化，在秒级或者毫秒级返回数据结果，适用于小数据量
  • PUSH模式：拉取大量数据满足后续业务需求
• 逻辑模型：文字性描述文件支持数据接口来解决数据复用的能力
• 数据网关：提供网关的集成能力

3.3数据服务架构

关于数据服务架构：

自上往下，最上层是最终对外提供的API集市，大家可以通过REST API的形式去访问，查询数据以及获取数据。下一层是查询引擎，产品群里基本上是API的接口，更多的是以一种协议的形式存在，所以在查询引擎的最上层是有一个解析的过程。根据协议标准将数据请求进行解析，获取将要查询的数据源，根据数据源信息获取对应的数据模型，数据模型会通过底层元数据信息映射出对应的数据表；根据请求中的字段列表以及filter条件，最终将请求解析成一个逻辑执行计划，并进一步产生一个物理执行计划，计算出最终结果封装成响应返回。这种调用形式其实分为两种，一种是同步的接口形式，也就是接口API，另外一种就是异步。异步就是说定义一个异步的时候，可能要比同步的方案要定义的信息更多一些，比如说给业务方提供的一个数据接口，数据的业务方需要去定制自己的回调接口，以及制定适合自己业务后续去处理的数据存储地址，然后填写到数据服务的定制化接口配置界面上。当数据请求过来之后，数据服务会把整个的接口请求转换成一种DAG工作流的形式。因为这个数据量比较大，靠一个本地的计算已经难以满足，或者说是内存上可能会存在一些瓶颈，所以把它翻译成一种离线的DAE形式来去计算，或者是判断其他的覆盖能力,计算完的数据，会存到用户指定的地方，并且调用户指定的回调接口来告知用户，数据已经准备好，可以去某某地方拉取。这个数据存储的最终形式就是按照用户定义的那种结果形式去存储，这样供业务前台可以快速的去拿到数据去进行后续的处理，这些产品其实都是通过统一的查询能力去完成。

查询引擎的下一层是API的配置层。对API配置功能的拆解，首先是接口定义,接口的名字是什么，接口的描述以及传入的参数,输出的结果，包括filter的条件。其次是协议的管理，不仅支持AGP的协议，还可以支持RPC的各种协议。还有异步的形势下，需要用户填写自己的回调地址，或者说指定一下数据存储的位置。

再往下是对于整个数据服务的管理模块，主要分为数据源管理、版本管理、资源管理、流量管理等。数据源管理是对数据接口的数据服务自身的一个管理。对于资源的管理能力，体现在数据服务常常会消耗服务器资源，然后对接公司的QAE的这套体系，就是说一套虚拟化的一个容器。流量管理就是对于每一个服务，可能都需要有一定的流量的管理措施去衡量以及动态调整服务的副本数。

左边就是网关，一个数据服务或者是一个服务接口所具备的能力，比如说一些安全认证及权限访问的问题，包括数据服务本身运行的稳定性的监控，还有数据接口调用分析，包括当接口并发量突然有激增的情况发生时，需要有限流的能力。

最底层是数据源，为了后续对数据服务做一个更深层次分析，我们需要对日志进行统一采集，统一管理。

最右边是整个数据中台里面很重要的一块——元数据中心，因为现在看无论是任何一个模块，任何一个数据的分层，对元数据的依赖都是相当重的。

3.4元数据服务组成

元数据的概念比较难理解，其实元数据就是数据的数据。对于元数据服务，现在提供了两种服务形式。一种是搜索服务，就是大家可以通过已知的一些信息去进行搜索，拿到数据资产的一些更详细的说明。比如可以通过搜表名、搜维度，搜业务线的名称、搜指标，就可以拿到跟搜索词相关的数据资产，并且进一步查看它的详细信息。另外一种形式可能比较偏向导性的或者结构化的一种展现形式，也就是业务图谱。我们可以从业务的角度出发，一层一层地圈定更细的范围来查找我们想要看到的数据资产。

元数据中心给用户展现的信息主要是包括几种，一种是基础信息，也就是说数据的定义，包括任务的定义、数据的生产者、安全责任人、数据的样例以及变更的历史。另一种是数据资产本身的特点，首先是数据资产等级，我们需要对不同的资产做分级，以保证不同等级的资产有不同的保障机制，然后更多的精力放到重要资产上。其次是对数据的健康度和质量的体现，我们会对于所有的数据资产分级地检测质量，包括它的产出时间来对数据资产进行定级。最后是数据流行度,主要是为了体现数据在下游使用当中的使用次数，以此来表明数据的重要程度。我们也会把数据的流行度作为数据价值的一个重要衡量指标。

除了这些元信息之外，我们可能也需要对于整个数据生态的一数据标准，通过元数据中心去对外去体现。比如业务的信息，包括业务的所属部门、负责人的信息，以及业务相关的一些指标维度和数据模型，把元信息以这两种服务形式对外提供，其实是为了可以让使用方可以更快速更高效地去找数据，把数据能理解和使用起来，并且可以指导用户去快速地开发自己的数据需求。

3.5 元数据服务架构

关于元数据的服务架构，左侧是相当于元数据的采集员,血缘采集其实是把数据资产由血缘形式体现出来，让每一个数据知道其的上下游是谁，然后在一些变更的时候能及时通知，并且如果数据上有一些变化，也可以及时的通过数据血缘的能力去找到自己的上游来排查数据变化的原因。血缘采集主要是分以下几部分：

一是通过HiveHook采集，Hive表之间的血缘，然后sparkhook采集spark的生产数据，就是发个任务生产的数据，以及它的数据源之间的关系。接下来是数据集成，是对数据异构数据源的同步能力，我们把这种导入导出的一种血缘管控起来。最后是pingback，因为pingback是很多数据产生的一个源头，所以这一块是说我们从数据产生最源头到最终数据的使用，全链路渲染的采集的方式。

下边是对于非关系型数据的元数据采集，比如说Hive、Kafka、MySQL,pingback，还有数据报表。这些更多的是对于数据资产的原始信息的采集方式。然后通过消息队列和API的这两种形式实现离线或者是实时的元数据采集流程。元数据中心可以通过JanusGraph去对血缘进行一个整体的管理。我们现在的血缘其实支持pingback到Hive,Hive到Hive,Hive到MySQL，然后MySQL到报表的整体的血缘关系。这样我们所有的数据资产，正常的来说应该都在这整个的血缘网当中，而且通过JanusGraph我们可以通过这种图结构的数据库去快速查找一些数据资产，包括它的上下游关系以及相互依赖关系。

然后技术元数据和业务元数据，主要是包括一些字段信息、存储信息、分区信息、资产信息、数据模型、数据流行度等等。为了快速查找，把索引信息存到了ES里，用于实现快速的搜索能力，并且这种详细信息我们可以通过JanusGraph或者其他的这种数据库存储形式去获取。

最后，元数据中心对外的体验形式主要有两种，一种叫查询API，它可以对接到各种的业务系统上。另一种叫搜索API，搜索API就是现在平台的展现形式，后面展现数据库的搜索APIDE 能力。

4 应用场景

数据服务平台其实是数据平台和业务前台以及数据源之间的关系，可以说是管理各种数据源发布同步数据的接口，然后提供给Client。Client其实很多时候是业务前台来提供同步的调用法。右侧的异步的交流能力是通过发布一个异步的数据接口来把数据源做一些DAG的管理和处理，把最终的数据发布到消息队列上，同时去回调业务前台的回调接口，再通知业务前台去消息队列获取结果数据。
云数据服务就是数据源和数据使用方进行打通。上游的数据生产、数据采集和数仓建设来对元数据进行生产，然后通过元数据服务，把元数据的输出到比如数据图谱报表系、自助查询系统以及后续的数据治理体系当中。