上篇和中篇，我们已经介绍了数据中台的元数据中心、指标字典与指标体系、数据模型设计、数据质量评估、中台成本管控，这些都是One Data理念下数据中台架构的重要部分。

在介绍下一个模块之前，我们需要再次明确数据中台架构的关注核心与视角。

在写文章时，我搜索了很多资料，网上搜索推荐的数据中台架构图五花八门、五颜六色，让人眼花缭乱，但你仔细去看，其架构部署似乎出自同一模板，核心模块几乎相同。想要说明的是：不要被架构结果或方案迷惑，关键视角是从真正的需求出发，找到切入点，而不是从结果模板反推。

从商业需求角度，One Data理念下架构的数据中台，其关注的核心就是两个模块：元数据中心和数据模型。“好”的数据模型，像一颗颗珍珠，完整、圆滑；“好”的元数据中心，像一条坚固的丝线，将一颗颗珍珠高效地串起，两者相辅相成，构建出璀璨的项链。

需要注意的是，指标字典（平台）是元数据中心应用之一，单独拿出来讲述是因为在众多的企业需求中，企业几乎都强调需要快速且准确的业务分析，而指标是业务分析的数据基础，除了指标平台外，还可以搭建标签平台等。

此外，还需要明确以下几个概念：

第一，数据服务是One Service领域，例如OLAP分析、BI可视化等，与One Data领域相辅相成，之前讲述的所有模块均属于One Data领域。

第二，数据产品、数据分析、数据开发、数据资产管理，这些本质上是数据中台的管理与协助流程，严格意义上不属于数据中台的架构范围（这些在后续文章中会依次介绍）。

第三，大数据采集、传输、集成、存储、协同、建模、分析、可视化是客观存在的数据流转的过程节点，只要企业存在一定规模的数据，或多或少都存在上述环节，而数据中台的架构目的是通过改造原有的数据流节点，使得整个数据流流得速度更快、更准确，但并不能替代这其中的任何一个环节。

在正确厘清这些概念后，接下来，我们走进数据中台的另一个维度——One Service。

One Service

数据服务的类别非常广泛，有提供数据传输能力的称为数据传输服务，有提供数据存储能力的叫做数据存储服务，有执行各种类型分析的称为数据分析服务，还有提供数据安全管理的叫做数据安全服务等，这些都叫数据服务，但这些数据服务强调的是能力，还不是数据中台的数据服务。

那么，数据中台的数据服务是什么？

在阿里巴巴数据中台全景图中，由数据中台提供统一的数据接入和数据查询服务，简称统一数据服务，它提供了三项数据服务：

• 主题式数据服务：基于元数据和规范定义和建模，构建主题逻辑表，屏蔽复杂物理表，提供业务视角下的查询。
• 统一且多样化数据服务：一站式提供一般查询、OLAP分析、在线接口服务等查询和应用服务，便于数据跟踪管理。
• 跨源数据服务：统一数据接入层，屏蔽多种异构数据源的读写差异，减少数据访问和应用成本。

数据服务为数据和应用之间建立了一座“沟通的桥梁”，这座桥梁的存在形式是API。可以把它想象成一个电源插座：只需要你的吹风机有一个匹配的插头，并将其插入，电流就会流向你的吹风机，就像数据流向你的数据应用一样。

数据服务类型

首先，我们需要了解数据服务都有哪些类型。

业界常用的数据服务包括五种类型， API、事件中心、数据库、文件、终端 & APP。在数据中台领域，主要应用的是API，所以我们重点介绍API类型。

API

API（Application Programming Interface）是最常用的一种数据服务的形式，是两个不同的计算机程序之间的接口或通信协议，目的是为了简化软件的开发和维护用户通过请求或响应来访问数据。目前，最通用、使用最广泛的API标准称为REST API。

API可以是Web系统，操作系统，数据系统，计算机硬件或者是软件类库，可以以多种形式存在，但是通常会包括特殊的路由规则，数据结构，对象，变量或者远程调用。POSIX，Windows和ASPI是不同的API形式。API通常会提供文档和实现形式。

通过API数据访问有两种形式：Push和Pull

Push（推）

数据供应端主动推送数据到数据消费端，典型的代表有事件订阅和数据库同步。例如，当物料主数据变化的时候，将最新的数据推送给所有的数据消费者系统。

这样的形式是从供应方的视角来处理的，因此不论数据消费者是否需要这些数据，也不论消费者对于这些数据的使用场景是怎样的，对于数据供应方，都是无差别推送过去，尽管消费者使用频率很低。

其优势是实时性很强，只要数据在源头发生了变化，都会第一时间推送给数据消费方。但是劣势也很明显，主要体现在：

• 无差别的推送，数据产生了很多资源浪费；
• 往往数据消费方需要二次加工这些推送来的数据，才能使用；
• 消费者是否使用，如何使用，不好管理，无法跟踪。

Pull（拉）

数据消费方根据自己的需要，从数据供应端拉数据回来，这样的典型服务类型包括：Data API，文件下载和Terminal & APP。

Pull是典型的精益形式，按需使用数据，用什么获取什么，什么时候用什么时候获取，用哪部分数据获取那部分数据。

从数据消费者的视角来看（如图），只有当数据应用方能够直接使用这个数据消息的时候，应用开发团队才不需要二次开发这个数据，否则应用开发团队需要在本地的存储中再次存储一遍这个数据，并且构建后端AP，进一步加工这个数据。这样带来了前端应用利用数据的复杂性，也带来了一致性的问题。

由此，在数据处理和加工方与数据应用方之间加入一层——数据服务层（如图），可以提高灵活性和复用性，这样让数据应用放可以直接使用数据服务而不再做任何加工处理，也能够保证不同数据应用使用同一个数据服务，提高数据的一致性。

常见API包括三种类型，数据中台提供的API以数据API和智能API为主。在这里，我们介绍数据API。

• 业务命令API。以Command (命令)为主，实际上就是一个业务行为，包括Request/Response，也可以没有Response的内容，是为了执行一个业务指令。例如，创建订单，创建用户等。
• 智能计算API。对数据进行计算，是对于输入参数的加工，返回计算的结果。例如，计算最优路径，计算推荐价格等。
• 数据查询API。数据API是对于已有数据的查询，可以扩充各种条件。例如查询用户信息，获取用户画像，获取产品清单等。

数据API是提供数据的应用程序接口，本质上是一个远传调用。这类数据接口服务一般包括参数，返回值，接口样本，接口地址等。

数据API的执行过程可以归纳为三步：请求，执行和返回结果。这与数据库层操作一致，参数散落在SQL关键字中。

一个好用的数据API主要具备三个要素：快速灵活、准确一致、安全合规。

其他数据服务类型

事件中心

Event Hub是微软云服务Azure的一个产品，是分布式大数据流平台。属于PaaS

本质上，Event Hub是一个暂放数据的地方。当数据从终端产生，发送数据给一个Event Hub的时候，Event Hub将数据收集然后写入内部储存里，通过消息队列（MQ)方式，提供事件消息的数据服务。

数据库

数据库是最早的提供数据的服务形式，例如当下的数据湖层，当用户需要数据的时候，直接提供一个数据库访问链接给到用户，从而直接访问这个数据库里的数据。

典型的场景是业务部门在开发业务应用的时候需要数据，直接向数据部门申请数据库的访问权限，然后自己基于这个数据库去做数据开发。

这样的数据库服务形式的具有灵活性，但是缺点也很明显：没有权限划分，安全难以保障，数据使用过程无法追踪，同时需要业务部门有专业的数据开发能力，更重要的是，当多个业务部门都利用这种方式访问和使用数据的时候，会产生很多份数据拷贝，造成资源浪费。

文件

当数据量比较大，或者没有比较好的访问通道的时候，数据文件也是一种提供服务的形式。例如，通过FTP文件服务器等。

终端& APP

以上四种数据服务形式的本质都是提供某一种形式的数据集，而终端& APP的形式，不仅包括数据集，还包括使用，访问数据的方法和流程。例如，大智慧、同花顺等证券交易APP。

综上，我们梳理了常见的数据服务类型。当前普遍公司或多或少都涉及到以上的数据服务类型，那么，针对这些数据服务，普遍存在哪些问题？

需要说明的是，以下的数据服务都指的是数据API服务。

数据服务问题

普遍的数据服务存在四类问题：

• 数据接入方式多样，接入效率低
• 数据和接口无法复用
• 不清楚数据被哪些应用访问
• 底层数据变更，影响数据应用

数据接入方式多样，接入效率低

数据中台加工好的数据，通常会以Hive表的形式存储在HDFS 上。如果想直接通过数据报表或者数据产品前端展现，为了保证查询的速度，会把数据导出到一个中间存储上：

• 数据量少的可以用MySQL , Oracle 等DB，具有部署维护方便、数据量小、查询性能强等优势。例如，数据量小于500W条记录，建议使用DB作为中间存储；
• 涉及大数据量、多维度查询的可以用GreenPlum，它在海量数据的OLAP（在线分析处理）场景中有优异的性能表现。例如，数据量超过 500W 记录，要进行多个条件的过滤查询；
• 涉及大数据量的单Key查询，可以用HBase。在大数据量下，HBase拥有不错的读写性能。例如，超过500W记录，根据Key查询Value的场景。

由于不同的中间存储，涉及的访问API也不一样，因此对数据应用开发，每个数据应用都要根据不同的中间存储，开发对应的代码。如果涉及多个中间存储，还需要开发多套代码，数据接入效率很低。

此时，数据服务为数据开发屏蔽了不同的中间存储，通过使用统一的API接口访问数据，可以大幅度提高数据应用的研发效率。

数据和接口无法复用

在上图中，当我们开发“数据应用-经营分析”时，数据开发会基于a表加工c表，然后数据应用开发会把a和b的数据导出到“数据应用-经营分析的数据库db1”中，然后开发经营分析的服务端代码，通过接口1对web提供服务。

当我们又接到任务开发“数据应用-毛利分析”时，我们同样需要用到b表的数据，虽然b的数据已经存在于db1中，但db1是“数据应用-经营分析”的数据库，无法共享给“数据应用-毛利分析”。同时，经营分析的服务端接口也无法直接给毛利分析用，因为接口归属在经营分析应用中，已经根据应用需求高度定制化。

以上，我们看到这样的现象：即使数据重复，不同数据应用之间，在中间存储和服务端接口上，也是无法复用的。这种烟囱式的开发模式，导致了数据应用的研发效率非常低。

此时，数据服务，使数据中台暴露的不再是数据，而是接口，接口不再归属于某个数据应用，而是在统一的数据服务上。这就使接口可以在不同的数据应用之间共享，同时因为数据服务具备限流的功能，使接口背后的数据共享成为可能，解决了不同应用共享数据相互影响的问题。

不清楚数据被哪些应用访问

传统的数据项目中，由于数据平台通过导出/导入或数据复制的方式为数据应用提供数据，数据一旦进入到下游系统中，数据平台就无法监控其使用情况了，即使用了元数据中心，也无法实现数据全链路血缘分析。

想象一个真实的场景：某技术人员突然接到了一堆电话报警：有大量的任务出现异常。经过紧张的定位后，他确认问题来源于业务系统的源数据库：因为一次数据库的表结构变更，导致数据中台的原始数据清洗出现异常，从而影响了下游的多个任务。这时，摆在他面前的是一堆需要恢复重跑的任务。可是队列资源有限，到底先恢复哪一个呢？哪个任务最终会影响到老板第二天要看的报表？

虽然数据血缘建立了表与表之间的链路关系，但是在表的末端，我们却不知道这个表被哪些应用访问，所以应用到表的链路关系是割裂的。当某个任务异常时，我们无法快速判断出这个任务影响了哪些数据应用，也无法根据影响范围决定恢复的优先级，最终可能导致重要的报表没有恢复，不重要的报表却被优先恢复了。

此时，数据服务打通了数据和应用的访问链路，建立了从数据应用到数据中台数据的全链路数据血缘关系，这就相当于我们在迷宫中拿到了一个地图，当任何一个任务出现问题，我们都可以顺着地图，找到这个故障影响了哪些应用，从而针对重要应用加速恢复速度。

数据部门字段变更导致应用变更

数据中台底层模型的字段变更是比较频繁的场景。当“数据应用-经营分析”使用了数据中台的ads_mamager_1d这张表的 c 字段，如果我们对这张表重构，访问字段需要替换成e字段，此时需要数据应用修改代码。这种因为数据中台的数据变更导致应用需要重新上线，是非常不合理的，不但会增加应用开发额外的工作量，也会拖累数据变更的进度。

此时，通过数据服务把数据应用和中台数据进行解耦，当中台数据表结构变更时，我们只需要修改一下数据服务上接口参数和数据字段的映射关系就可以了。不需要再修改代码，重新上线数据应用。

以上，我们了解数据服务的诸多优势，那么，标准的数据服务应该具备哪些功能？

数据服务的核心功能

第一，接口规范化定义。对各个数据应用屏蔽了不同的中间存储，提供的是统一的API。

第二，数据网关部署。作为网关服务，数据服务必须要具备认证、授权、限流、监控四大功能，这是数据和接口复用的前提。

• 认证。为了解决接口安全的问题，数据服务首先会为每个注册的应用分配一对accesskey和secretkey，应用每次调用API接口，都必须携带。
• 授权。对于每个已发布的 API，API 负责人可以对应用进行授权，只有权限的应用才可以调用该接口。
• 限流。API 接口的负责人可以对应用进行限流（例如限制每秒QPS不超过 200），如果超过设定的阈值，就会触发熔断，限制接口的访问频率。需要注意的是，对于接口复用来说，限流功能非常必要，否则会造成不同应用之间的相互影响。
• 监控。例如，接口的 90% 的请求响应时间、接口调用次数、失败次数等相关的监控。同时，对于长时间没有调用的API ，应该予以下线。

第三，数据全链路打通。服务很难避免出现问题或者故障，一旦出现问题，及早发现及早介入是非常重要的，因此，数据服务必须负责维护数据模型到数据应用的链路关系，构建服务平台的全链路监控，包括：

• 数据同步：对数据资产同步至高速存储的过程进行监控，包括数据质量检测（过滤脏数据）、同步超时或者失败检测等；
• 服务稳定性：构建一个独立的哨兵服务，来监测每个API的运行指标（如延迟、可用性等），客观的评估健康度；
• 业务正确性：数据服务需要确保用户访问的数据内容和数据资产表内容是一致的，因此，哨兵服务会从数据一致性层面去探查，确保每个API的数据一致性。

第四，确立推和拉的数据交付方式。可参考上面提到的API数据访问的两种模式。

第五，利用中间存储，加速数据查询。数据中台中数据以Hive表的形式存在，基于Hive或者是Spark计算引擎，并不能满足数据产品低延迟，高并发的访问要求，因此，一般做法是将数据从 Hive 表导出到一个中间存储，由中间存储提供实时查询的能力。

第六，基于逻辑模型发布API，实现数据的复用。逻辑模型是解决数据复用的一个策略，在相同的物理模型之上，应用可以根据自己的需求，构建出不同的逻辑模型。我们可以在数据服务中定义逻辑模型，然后基于逻辑模型发布API。逻辑模型实际是多个物理表，从用户的视角，一个接口可以访问多张不同的物理表。逻辑模型类似数据库中的视图，相比于物理模型，逻辑模型只定义了表和字段的映射关系，数据是在查询时动态计算的，因此，不占用大量的物理存储空间。

第七，构建API集市，实现接口复用。为了实现接口的复用，我们需要构建API 集市，应用开发者可以直接在API集市发现已有的数据接口，直接申请该接口的 API权限，即可访问该数据，不需要重复开发。数据服务通过元数据中心，可以获得接口访问的表关联了哪些指标。使用者可以基于指标的组合，筛选接口，这样就可以根据想要的数据，查找可以提供这些数据的接口，形成闭环。

此外，需要关注的是，在当前最新的应用中，API已超越了技术范畴，从对技术的要求转变为商业战略和商业模式的需求，许多企业开始启动API战略，构建API生命周期管理。由于本篇不是重点介绍API内容，因此先抛出这样的观察。

数据服务的关键技术

为了使数据中台具备快速响应前端业务需求的能力，主流的数据中台均采用了云原生技术来构建数据服务层，实现数据服务的快速开发、有序落地。

云原生是一种构建和运行应用程序的方法，是一套技术体系和方法论，因此在这里先不展开云原生的具体架构。我们重点关注在数据中台领域，基于云原生的关键技术应用。

在数据中台领域，应用云原生的核心优势在于每个服务至少有两个副本，实现了服务的高可用。同时，根据访问量大小，服务的副本数量可以动态调整，可以实现对客户端透明的弹性伸缩。服务之间基于容器实现了资源隔离，避免了服务之间的相互影响。这些特性非常适用于提供高并发、低延迟，在线数据查询的数据服务。

以下是具体技术应用场景。

第一，配置即开发。平台用户分为两类角色：数据服务生产方、数据服务调用方。数据服务生产方只需要配置，实现“配置即开发”。配置内容包括：

• 数据源
• 数据加速到何处
• 接口形态，访问方式
• 测试环境，访问隔离的测试数据

当配置完毕后，数据服务平台便会根据配置清单，完成接口的自动化生产和部署。生产和部署完毕后，调用方在平台申请服务权限调用。通过自动化生产，达到配置即开发的目的，从而极大的提升效率。

第二，多模式服务形态。

数据服务有多种服务形态，包括：

• KV API：简单点查，可以支撑百万QPS、毫秒延迟。这类API是通过模板自动化创建，支持单查、批量查询等接口，返回的结果是 Protobuf (PB) 结构体，从而将结果自动做了ORM，对于主调方更加友好。典型场景包括：根据IP查询GEO位置信息、根据用户ID查询用户标签画像信息等。
• SQL API：复杂灵活查询，底层基于OLAP/OLTP 存储引擎。通过Fluent API接口，用户可自由组合搭配一种或若干种嵌套查询条件，可查询若干简单字段或者聚合字段，可分页或者全量取回数据。典型场景包括：用户圈选（组合若干用户标签筛选出一批用户）。
• Union API：融合API，可自由组合多个原子API，组合方式包括串行和并行方式。调用方不再需要调用多个原子API，而是调用融合API，通过服务端代理访问多个子查询，可以极大降低访问延迟。

第三，高效数据加速。企业的数据资产，通常是存在于低速的存储引擎中，无法支撑线上业务高访问流量。因此需要以系统化的方式进行数据加速。目前有两种加速方式：

• 全量数据加速。从多个数据源摄入原始数据（如Kafka，MySQL、线上访问日志等），进行加工建模后，得到数据资产。数据资产经由独立的数据同步服务，同步至其他更高速的存储引擎，如redis、hbase、druid等。数据同步支持一次性或者周期性（小时、天、周等）将数据从Hive同步至其他存储中，数据同步本身是基于分布式的调度系统，内核是基于datax 进行数据同步。大数据服务化平台单日同步的数据量达到1200亿条，数据size达到20TB。

• 多级缓存（部分数据加速）。大数据服务化平台会使用Redis、Hbase、Druid、Clickhouse等方式存储所有数据，但是部分存储如Hbase速度可能较慢，针对热点数据需要使用额外的热点缓存来Cache数据。热点缓存是多级缓存，针对每个API接口，用户可自由搭配组合多级缓存、灵活设置缓存策略。此外，针对数据较大的API，还可配置数据压缩，通过多种压缩方式（如 ZSTD, SNAPPY, GZIP 等），可将数据量显著减少（部分API 甚至能减少90%的数据存储量）。

第四，资源隔离。资源隔离是可用性保障的常见手段之一，通过隔离将意外故障等情况的影响面降低。不管是微服务，还是存储，需要按照业务+优先级（高、中、低）粒度隔离部署，独立保障，业务之间互不影响、业务内不同级别也互不影响。同一业务线内可能有多个不同数据服务，通过混合部署，提高资源使用率。

综上，我们可以架构数据服务的核心框架。

图中，每个已经发布上线的API接口都对应了一个Kubernates的Service，每个 Service 有多个副本的Pod组成，每个API接口访问后端存储引擎的代码运行在Pod对应的容器中，随着 API 接口调用量的变化，Pod可以动态的创建和销毁。

Envoy是服务网关，可以将Http请求负载均衡到Service的多个Pod上。Ingress Controller可以查看Kubernates中每个Service的Pod变化，动态地将Pod IP写回到Envoy，从而实现动态的服务发现。前端的APP，Web或者是业务系统的 Server端，通过一个4层的负载均衡LB接入到Envoy。

基于云原生的设计，解决了数据服务不同接口之间资源隔离的问题，同时可以基于请求量实现动态的水平扩展，同时借助Envoy实现了限流、熔断的功能。

最后，我们总结数据服务架构的关键，主要有以下三点：

• 支持丰富的数据源：包括大宽表、文本文件、机器学习模型（模型也是一种数据资产），来构建完善的数据服务。
• 支持多样取数方式：除了支持同步快速取数之外，还支持异步查询取数、推送结果、定时任务等多样化方式，以满足业务多种场景需求。
• 建设统一的API网关：集成权限管控、限流降级、流量管理等于一体，不仅平台创建的服务可以注册进API网关，用户自己开发的API也可注册进API网关，从而享受已有的基础网关能力，为业务提供数据服务能力。

下一篇，我们将介绍数据中台的管理与协作流程。