阿里推出“数据中台”时，点明其两个核心概念，一个是One Data，一个是One Service。

阿里One data 数据中台建设过程
很多人都只注意到了One Data，元数据中心、指标字典、数据模型设计等等都属于One Data理念下数据中台架构的重要部分。

但其实One Service——数据服务也是数据中台的核心，目前市面上的数据中台没有好用的产品很大的原因就是数据服务没做好。

数据服务平台架构
反而国内外专门做数据服务的产品好评不断，今天展开介绍数据服务是如何提高企业数据开发效、降低数据开发成本、让企业快速挖掘数据价值的。

01

屏蔽中间存储，提高数据开发效率

数据平台加工好的数据，通常会以Hive表的形式存储在HDFS 上。

如果想直接通过数据报表或者数据产品前端展现，为了保证查询的速度，会把数据导出到一个中间存储上：

数据量少的可以用MySQL , Oracle 等数据库，具有部署维护方便、数据量小、查询性能强等优势。例如，数据量小于500W条记录，建议使用数据库作为中间存储；
涉及大数据量、多维度查询的可以用GreenPlum，它在海量数据的在线分析处理场景中有优异的性能表现。例如，数据量超过 500W 记录，要进行多个条件的过滤查询；
涉及大数据量的单Key查询，可以用HBase。在大数据量下，HBase拥有不错的读写性能。例如，超过500W记录，根据Key查询Value的场景。
由于不同的中间存储，涉及的访问API也不一样，因此对数据应用开发，每个数据应用都要根据不同的中间存储，开发对应的代码。

如果涉及多个中间存储，还需要开发多套代码，数据接入效率很低。

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

02

完成数据接口复用，降低数据开发成本

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

 
当我们又接到任务开发“数据应用-毛利分析”时，我们同样需要用到b表的数据，虽然b的数据已经存在于db1中，但db1是“数据应用-经营分析”的数据库，无法共享给“数据应用-毛利分析”。

同时，经营分析的服务端接口也无法直接给毛利分析用，因为接口归属在经营分析应用中，已经根据应用需求高度定制化。

以上，我们看到这样的现象：即使数据重复，不同数据应用之间，在中间存储和服务端接口上，也是无法复用的。

这种烟囱式的开发模式，导致了数据应用的研发效率非常低。

此时，数据服务使得暴露的不再是数据，而是接口，接口不再归属于某个数据应用，而是在统一的数据服务上。

这就使接口可以在不同的数据应用之间共享，同时因为数据服务具备限流的功能，使接口背后的数据共享成为可能，解决了不同应用共享数据相互影响的问题。

03

建立从数据到应用全链路血缘

传统的数据项目中，由于数据平台通过导出/导入或数据复制的方式为数据应用提供数据，数据一旦进入到下游系统中，数据平台就无法监控其使用情况了。

即使用了元数据中心，也无法实现数据全链路血缘分析。

想象一个真实的场景：某技术人员突然接到了一堆电话报警：有大量的任务出现异常。经过紧张的定位后，他确认问题来源于业务系统的源数据库：因为一次数据库的表结构变更，导致数据中台的原始数据清洗出现异常，从而影响了下游的多个任务。

这时，摆在他面前的是一堆需要恢复重跑的任务。可是队列资源有限，到底先恢复哪一个呢？哪个任务最终会影响到老板第二天要看的报表？

虽然数据血缘建立了表与表之间的链路关系，但是在表的末端，我们却不知道这个表被哪些应用访问，所以应用到表的链路关系是割裂的。

当某个任务异常时，我们无法快速判断出这个任务影响了哪些数据应用，也无法根据影响范围决定恢复的优先级，最终可能导致重要的报表没有恢复，不重要的报表却被优先恢复了。

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