有人认为，多维的数据分类体系曾经够用了，标签就是一个“鸡肋”；也有人认为标签体系有有利于大数据的萃取和剖析，提供画像能力，实现精准举荐，必须是数据中台的标配。
如果“标签体系”确有争议的话，那么明天介绍的这个性能肯定没有争议，它相对是数据中台的真正标配，它就是——数据服务。
01 什么是数据服务？
数据服务的类别相当宽泛，有提供数据传输能力的叫做数据传输服务，有提供数据存储能力的叫做数据存储服务，有执行各种类型剖析的叫做数据分析服务，还有提供数据安全治理的叫做数据安全服务等等。
这些都叫数据服务，但这些数据服务强调的是能力，更精确的定义是“Data as a Service——数据即服务”，但这不是咱们明天要讲的数据中台的数据服务！
数据中台的数据服务到底是什么？
我的了解：不同零碎之间应用服务的形式进行交互，数据服务为数据和利用之间建设了一座“沟通的桥梁”，这座桥梁的存在模式是 API。
能够把它设想成一个电源插座，例如，只须要你的吹风机有一个匹配的插头，并将其插入，电流就会流向你的吹风机，就像数据流向你的数据利用一样。
02 数据中台为什么须要数据服务？
网上的很多文章中，喜爱将数据中台用“厨师做菜”来形象比喻。厨师做菜个别有几个步骤：买菜、洗菜择菜、制订菜单、炒菜。这几个步骤在数据中台的数据加工流程中被称为：数据采集、数据荡涤、数据建模、数据分析 / 数据利用。
数据采集
跟厨师做菜一样，巧妇难为无米之炊，须要做几道好菜，首先得有原材料，那么数据采集 / 数据接入就是买菜的过程。
数据荡涤
买回来菜须要摘洗洁净，能力下锅，数据荡涤就是摘菜洗菜的过程，是须要把脏数据荡涤掉。
数据建模
菜摘洗好了，但炒什么菜要须要依据客人下的菜单来做。数据建模就像对为客人制订菜单一样，例如：客人喜爱什么菜？鱼香肉丝还是宫保鸡丁，口味是甜一点，辣一点还是油腻一点等问题都要形容分明并传递给“厨师”。数据建模就是将数据消费者的需要转化为计算机可能了解的语言。
数据分析 / 数据利用
依据客人的“菜单”要求，炒菜装盘。
好了，看到这里有人不禁要问：说了这么多，数据服务在哪里？数据中台到底为什么须要数据服务？
在这个“厨师做菜”的过程中，有一个不能疏忽的角色，不晓得你有没有发现，这个角色就是“服务员”。他的工作是帮忙客户点菜，并将炒好的菜端到客人的桌上。而数据中台的“服务员”就是数据服务，英文名字：OneService。
设想一下，你正坐在餐厅的一张桌子旁，那里有可供选择的菜单。但如果没有服务员，就会短少的是将你的菜单传播给厨房并将你的食物送回餐桌的关键环节。这就是“服务员”（数据服务）的用武之地，承受数据消费者的申请，并通知零碎做什么，将做好的数据服务以 API 的形式提供给数据消费者。
另外，在整个过程中，数据服务还有一个作用，它屏蔽了底层数据的技术细节，数据消费者不须要关怀“这些数据来自哪里，哪个库，哪张表，数据库类型是什么等”问题，只须要关怀“这些数据是否满足我的须要”就行了。
就如同你去餐厅吃饭，不必关怀菜是从哪买回来的，谁是配菜的，谁是炒菜的等这些问题一样，只须要关怀这个菜合不合你的口味就行了。
03 数据服务能解决哪些问题？
在传统的数据集成计划中，往往须要将数据从一个零碎导出 / 导入，或复制到另一个零碎当中。随着企业数据利用规模的不断扩大，须要在几十个甚至上百个零碎中进行数据集成，传统的数据集成形式难度越来越大，裸露的问题也越来越多。
1、数据“搬家”造成的数据不统一问题
传统数据集成须要将数据从一个零碎复制到另一个零碎中，过程中因为网络、接口、程序、工作以及其余的一些不确定因素都会导致数据在“搬家”的过程中“失落”，从而造成数据不统一问题。
而通过数据中台提供的数据 API 交付数据，大部分状况下不须要数据“落地”，强调使用权而不是拥有权，这样就大大减少了数据在流向上游零碎过程中造成不统一问题。
2、数据接入多样，集成效率低
数据中台会依据企业数据的类型、数据量大小、数据的利用需要等，设计相应的不同数据接入和存储计划。例如：通过 MySQL、Oracle 接入数据量绝对较小的数据，通过 Greenplum 接入数据量大且须要多维分析的数据，通过 Hbase 接入大量的 keyValue 数据，以及通过 ES 建设数据索引晋升数据的查问效率等等。这种状况下，如果按每种数据接入形式裸露数据的话，无疑是一个非常复杂事件。
而通过数据中台将各类型数据封装为对立的数据 API，对外提供接口，可能屏蔽数据接入多样性带来的数据集成简单、效率低下等问题。
3、数据被哪些利用拜访了无奈监控
传统的数据我的项目中，即应用了元数据这样的工具，也无奈实现数据的采集、汇总、荡涤、解决、利用的全链路血统剖析。尤其是数据平台到数据利用的链路简直全副是割裂的，数据平台通过导出 / 导入或数据复制的形式为数据利用提供数据，数据一旦进入到上游零碎中，数据平台就无奈监控其应用状况了。
而数据中台提供的对立数据服务 API，为数据利用和数据中台搭建了一座桥梁。数据 API 只有通过受权能力被拜访，在给数据利用受权以及应用程序拜访数据 API 的时候，能够“标签”的模式，将数据拜访链路告诉给元数据中心，从而买通了数据中台到数据利用的链路，造成了数据的全生命周期血统。
4、上游数据变更，影响上游数据利用
在很多数据我的项目中，还有一种状况比拟常见：数据利用间接调用数据平台的数据库来拜访数据。这就会导致，一旦上游数据产生变更就会对上游的数据利用造成较大影响。
而数据中台提供对立的数据 API 供数据利用调用，实现了数据中台与数据利用的解耦。在数据服务外部建设与与各数据源建设映射，上游数据产生变更，只须要调整数据服务的映射即可，不会对数据利用的应用造成影响。
04 数据服务应具备哪些性能？
在数据中台架构中数据服务层位于数据中台下层，连贯数据消费层，将已整合的数据以服务的模式提供给数据消费者，以取得更好的性能和体验。数据服务层具备的性能如下：
跨源数据服务
数据中台接入数据的多样性，决定了数据中台的技术架构须要由多个大数据组件组成，例如：Hive、HBASE、GP、ES、Redis、MySQL、Oracle 等等，而业务上对数据的应用可能是跨多个数据库的。数据服务层提供的跨源数据服务，屏蔽了底层数据源的技术差别，能够从不同数据源提取数据，并依照业务须要进行编排，造成对立 API 进行对外共享。
主题数据服务
依照不同的业务主题，组织造成对立的数据 API。数据中台继承了数据仓库面向主题的思维，将位于不同数据两头存储的同一业务主题的数据整合到一起，屏蔽多数据源与多物理表，造成规范的数据服务供内部应用。例如：销售主题，须要将企业的零售、批发、线上、线下、代理等等各个渠道的销售数据会集起来。
一站式查问
数据服务最终将用户拜访的 API 转化为底层对各种数据源的拜访，实现对数据中台数据的一站式查问，提供数据检索、联机剖析、实时查问等，晋升数据查问的效率。
全链路买通
数据和利用的拆散会导致数据血统无奈残缺追溯，数据服务不仅提供了连贯数据和利用能力，还通过服务受权以及拜访监控等性能，将数据 API 的拜访状况实时写入元数据中心，造成残缺的数据血统。
订阅交付能力
订阅交付能力：数据 API 构建实现，并不需要数据消费者反复构建集成通道，而是通过受权“订阅”的形式，让数据消费者通过接口疾速应用数据。
API 网关服务
API 网关服务应用云原生技术提供了服务 API 的对立治理和监控能力，包含：服务注册、服务主动发现、认证受权、流量管制、超时熔断、安全控制、监控剖析等。
05 数据中台的数据服务该如何构建？
颗粒度问题
服务拆分的越细则复用性越好，但如果只思考服务重用，大量的细颗粒度服务将很难治理并且势必会对整体性能带来影响。服务的设计须要从业务需要、治理难以水平、性能个性等方面综合考量。
标准化问题
服务的开发采纳 Restful API 技术，该技术具备构造清晰、易于了解、不便扩大等特点，且接口标准规范，不管前端利用是 java、.net、C# 还是 PHP 都可能调用。就像设计一个插座，肯定要具备普适性，这样不管你的吹风机插头是美标的、欧标的还是国标均的都可能适配。
DataOps
DataOps 是将 DevOps 的理念延长到数据世界，提供了一种数据服务的继续经营形式。通过 API 网关进行服务的注册和治理，实现数据服务的动静发现、主动部署、自动化监控。依据服务的运行监控数据对数据服务的进行无效治理，包含数据服务的迭代优化、服务编排、自动测试、服务下架等。
写在最初
数据服务层（OneService）扭转了传统的数据集成和交付形式，所有整合到数据中台的数据都通过数据服务提供，数据服务对外裸露的不是数据而是接口，数据消费者不必间接获取数据，而是通过接口服务获取。
数据服务不是简略的对外裸露一个 API 就行了，
从性能层面
数据服务还包含了跨数据源服务、主题数据服务、一站式查问服务、订阅式交付、全链路买通等能力；
在技术层面
数据服务采纳了云原生技术，具备了服务的动静发现、主动部署、主动监控、服务治理等能力。