点击关注上方“知了小巷”，
设为“置顶或星标”，第一时间送达干货。
前文回顾：
从《元数据中心的关键目标和技术实现方案》开始，到《交付速度和质量问题解决了，老板说还得“省”》之成本管理，已经涵盖了元数据以及在它基础上的五⼤应⽤场景：数据发现（数据地图）、指标管理、模型设计、数据质量、成本优化。这些内容对应的就是数据中台OneData⽅法论，是能够实实在在落地的。
下面是数据中台另外⼀个核⼼⽅法论，OneService的实现：数据服务。
服务化在业务系统中提的⽐较多，它是业务系统化繁为简，实现业务拆分的必经之路（特别是这⼏年微服务的概念深⼊⼈⼼）。对于数据中台，服务化意味着什么呢？数据服务到底解决了什么题？ 相信很多⼈都会有这样的疑问。
服务化：不同系统之间通过服务⽅式交互，服务通常以API接⼝形式存在。
先从问题⼊⼿，看⼀看数据服务解决了什么问题，打消“为什么要有数据服务”这样的疑问。
要想搞清楚数据服务解决了什么问题，就要先知道，没有数据服务，在⽇常数据建设中存在哪些痛点。
</> 数据接⼊⽅式多样，接⼊效率低
数据中台加⼯好的数据，通常会以Hive表的形式存储在HDFS上。如果想直接通过数据报表或者数据产品前端展现，为了保证查询的速度，会把数据导出到⼀个中间存储上：
1. 数据量少的可以⽤MySQL , Oracle等DB，因为部署维护⽅便、数据量⼩、查询性能强。⽐如数据量⼩于500W条记录，建议使⽤DB作为中间存储；
2. 涉及⼤数据量、多维度查询的可以⽤GreenPlum，它在海量数据的OLAP（在线分析处理）场景中有优异的性能表现。⽐如数据量超过500W记录，要进⾏多个条件的过滤查询；
3. 涉及⼤数据量的单Key查询，可以⽤HBase。在⼤数据量下，HBase拥有不错的读写性能。⽐如超过500W记录，根据Key查询Value的场景。如果需要⽤到⼆级索引，由于HBase原⽣不⽀持⼆级索引，所以 可以引⼊ES，基于ES构建⼆级索引和RowKey（HBase中的Key）映射关系，查询时先根据⼆级索引在ES中找到RowKey，然后再根据RowKey获取HBase中的Value值。
因为不同的中间存储，涉及的访问API 也不⼀样，所以对数据应⽤开发来说，每个数据应⽤都要根据不同的中间存储，开发对应的代码，如果涉及多个中间存储，还需要开发多套代码，数据接⼊效率很低。
⽽数据服务为数据开发屏蔽了不同的中间存储，应⽤开发使⽤统⼀的API接⼝访问数据，⼤幅度提⾼了数据应⽤的研发效率。
当然了，数据接⼊效率低，除了跟对接不同的中间存储有关，还因为数据和接⼝不能复⽤。这⼜是怎么回事呢？
</> 数据和接⼝没有办法复⽤
举个例⼦。
在上图中，在开发“数据应⽤-经营分析”时，数据开发会基于a表加⼯c表，然后数据应⽤开发会把a和b的数据导出到“数据应⽤-经营分析的数据库db1”中，然后开发经营分析的服务端代码，通过接⼝1对web提供服务。
当我们⼜接到任务开发“数据应⽤-⽑利分析”时，同样需要⽤到b表的数据，虽然b的数据已经存在于db1中，但db1是“数据应⽤-经营分析”的数据库，⽆法共享给“数据应⽤-⽑利分析”（因为不同应⽤之间共享数据库，会存在相互影响）。
同时，经营分析的服务端接⼝也⽆法直接给⽑利分析⽤，因为接⼝归属在经营分析应⽤中，已经根据应⽤需求⾼度定制化。
所以会看到这样的现象：即使数据重复，不同数据应⽤之间，在中间存储和服务端接⼝上，也是⽆法复⽤的。这种烟囱式的开发模式，导致了数据应⽤的研发效率⾮常低。
⽽数据服务，使数据中台暴露的不再是数据，⽽是接⼝，接⼝不再归属于某个数据应⽤，⽽是在统⼀的数据服务上。这就使接⼝可以在不同的数据应⽤之间共享，同时因为数据服务具备限流的功能，使接⼝背后的数据共享成为可能，解决了不同应⽤共享数据相互影响的问题。
那么当数据应⽤上线之后，就进⼊了运维阶段，如果这个阶段没有数据服务的话，会出现什么问题呢？
</> 不知道数据被哪些应⽤访问
案例
张好看（化名）是⼀名数据开发，某⼀天的凌晨，她突然接到了⼀堆电话报警：有⼤量的任务出现异常（对应上图中红⾊表的产出任务）。经过紧张的定位后，她确认问题来源于业务系统的源数据库，也就是说，因为⼀次数据库的表结构变更，导致数据中台中，原始数据清洗出现异常，从⽽影响了下游的多个任务。
这时，摆在她⾯前的，是⼀堆需要恢复重跑的任务。可是队列资源有限，到底先恢复哪⼀个呢？ 哪个任务最终会影响到⽼板第⼆天要看的报表呢？
虽然数据⾎缘建⽴了表与表之间的链路关系，但是在表的末端，我们却不知道这个表被哪些应⽤访问，所以应⽤到表的链路关系是断的。当某个任务异常时，我们⽆法快速判断出这个任务影响了哪些数据应⽤，从⽽也⽆法根据影响范围决定恢复的优先级，最终可能导致重要的报表没有恢复，不重要的报表却被优先恢复了。
同样，在成本治理中，也提到，因为没有应⽤和数据的链路关系，我们不敢贸然下线数据。
⽽数据服务打通了数据和应⽤的访问链路，建⽴了从数据应⽤到数据中台数据的全链路数据⾎缘关系，这就等于我们在迷宫中拿到了⼀个地图，当任何⼀个任务出现问题，我们都可以顺着地图，找到这个故障影响了哪些应⽤，从⽽针对重要应⽤加速恢复速度。同样，我们也可以放⼼的下线数据中台中任意⼀张表。
除了不知道数据被哪些下游应⽤使⽤，在运维阶段，我们还经常⾯临着数据表频繁重构，⽽这也许是数据应⽤开发最可怕的噩梦了。
</> 数据部⻔字段变更导致应⽤变更
数据中台底层模型的字段变更是⽐较频繁的⼀个事情，因为本⾝汇总层的模型也在随着需求不断优化。
“数据应⽤-经营分析”使⽤了数据中台的ads_mamager_1d这张表的c字段，如果我们对这张表进⾏了重构，访问字段需要替换成e字段，此时需要数据应⽤修改代码。这种因为数据中台的数据变更导致应⽤需要重新上线的事情，是⾮常不合理的，不但会增加应⽤开发额外的⼯作量，也会拖累数据变更的进度。
有了数据服务，就会把数据应⽤和中台数据进⾏解耦，当中台数据表结构变更时，我们只需要修改⼀下数据服务上接⼝参数和数据字段的映射关系就可以了。不需要再修改代码，重新上线数据应⽤。
总结
本文列举了在数据接⼊和运维过程中，遇到的4个典型的问题，也简要分析了数据服务为什么能够帮我们解决这些问题。⽽这些问题会让数据应⽤使⽤中台数据效率低下，同时也带来了中台数据维护的烦恼。
思考
听到最多的⼀种说法是，数据服务解决了数据的安全性的问题，这个说法有道理吗？
统⼀的数据服务，可以统⼀管理数据的权限，规范统⼀的数据格式，对外暴露的是服务接⼝，应⽤层不关⼼底层是MySQL还是oracle。
数据服务可以通过鉴权和数据分级分类实现数据访问时的安全控制。但数据接⼊，存储，备份恢复，乃⾄治理过程中的安全则需要其它⽅⾯的技术配合。⽐如加密传输，透明加密存储，集群访问认证控制，数据脱敏，开发环境和线上环境分离等。
“如果云计算还剩下最后⼀个属性，那就是安全”。
数据服务并不是解决了数据的安全，数据的安全不仅仅是考服务就能解决的；它对于上下的依赖其实很明 显，我们可以去看到云计算⽬前的框架就可以看到现在都是称为数据存储，⼀旦问题到数据服务了-说明已经到了接近最后⼀层了。
往期推荐：
