数据中台实战(09)-数据服务：保障数据安全、提升数据价值的利器

你的名字 2024-03-22 21:50 69阅读 0赞

04-08把元数据以及在它基础上的五大应用场景：数据发现（数据地图）、指标管理、模型设计、数据质量、成本优化，全部讲完。这部分内容对应的就是数据中台OneData 方法论。学完这部分内容，你已了解OneData方法论在企业内部落地的方法。

数据中台另外一个核心方法论，OneService的实现：数据服务。

服务化在业务系统较多，业务系统化繁为简，实现业务拆分的必经之路（特别微服务概念）。数据中台，服务化意味啥？数据服务到底解决啥问题？

> 服务化：不同系统之间通过服务方式交互，服务通常以API接口形式存在。

要搞清数据服务解决啥问题，要先知道，没有数据服务，日常数据建设中存在的痛点。

![df12bfcae1e14e5287ea1d191c9b1e25.png][]

### 1 数据接入方式多，接入效率低 ###

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

*  数据量少的MySQL , Oracle等DB，部署维护方便、数据量小、查询性能强。如数据量小于500W条记录，建议使用DB中间存储
 *  涉及大数据量、多维度查询的可用GreenPlum，海量数据OLAP有优异性能表现。如数据量超过500W记录，要进行多个条件的过滤查询
 *  涉及大数据量单Key查询，可用HBase。大数据量下，HBase拥有不错读写性能。如超过500W记录，根据K查询V场景。如需要用到二级索引，由于HBase原生不支持二级索引，可引入ES，基于ES构建二级索引和RowKey（HBase中的Key）映射关系，查询时先根据二级索引在ES中找到RowKey，再根据RowKey获取HBase中的Value值。

因为不同的中间存储，涉及的访问API 也不一，所以对数据应用开发来说，每个数据应用都要根据不同中间存储，开发对应代码，如涉及多个中间存储，还要开发多套代码，数据接入效率很低。

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

数据接入效率低，除了跟对接不同的中间存储有关，还因数据和接口不能复用。

### 2 数据和接口没有办法复用 ###

数据和接口无法复用示意图

![ccaea5cfc78a48169fe8e53301184906.png][]

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

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

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

即使数据重复，不同数据应用之间，在中间存储和服务端接口上，也无法复用。这种烟囱式开发导致数据应用研发效率低。

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

当数据应用上线后，进入运维阶段，如这阶段没有数据服务，会咋样？

### 3 不知道数据被哪些应用访问 ###

故障恢复示意图

![7ed35bd1b1714d15b65af5c257f649c7.png][]

张好看是数据开发，某天凌晨接到电话报警：有大量任务异常（对应上图红色表的产出任务）。定位确认问题来源业务系统的源数据库，因一次数据库表结构变更，导致数据中台中，原始数据清洗出现异常，从而影响下游的多个任务。

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

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

成本治理中，没有应用和数据的链路关系，也不敢贸然下线数据。

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

除不知道数据被哪些下游应用使用，运维阶段，还经常面临数据表频繁重构，也许是数据应用开发最可怕噩梦。

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

数据中台底层模型的字段变更是比较频繁的一个事情，因为本身汇总层的模型也在随需求优化。

![f50294e6df5840aba9cb94258a6d96d2.png][]

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

有了数据服务，就会把数据应用和中台数据解耦，当中台数据表结构变更，只需修改数据服务上接口参数和数据字段的映射关系。无需再修改代码，重新上线数据应用。

### 5 总结 ###

数据接入和运维过程中，遇到的典型问题，简要分析数据服务为什么能够帮我们解决这些问题。而这些问题会让数据应用使用中台数据效率低下，同时也带来中台数据维护的烦恼。

下讲聊数据服务具备哪些功能，你正准备设计一个数据服务或正做数据服务的产品选型，一定要留意。最后会提供给你一个数据服务实现方案，告诉你数据服务实现的关键设计。

![ae5be734e13244569583c870f4f326d7.png][]

### 6 FAQ ###

数据服务解决了数据的安全性的问题，有道理吗？

是的，数据服务可通过许多安全措施来确保数据的安全性。例如，数据服务可以使用加密技术来保护数据，以确保只有授权用户才能访问数据。此外，数据服务还可以实施访问控制和身份验证措施，以确保只有授权用户才能访问数据。因此，数据服务可有效解决数据的安全性问题。

[df12bfcae1e14e5287ea1d191c9b1e25.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/8a60798ad90a4b689dc7790a07beae52.png
[ccaea5cfc78a48169fe8e53301184906.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/094cdf1a8eb24acd9e5acf0f82a42a03.png
[7ed35bd1b1714d15b65af5c257f649c7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/ff32fb117ab64a428cd3aa4fc57910f1.png
[f50294e6df5840aba9cb94258a6d96d2.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/908d2f5e773b42e3b697dc20d1b65d46.png
[ae5be734e13244569583c870f4f326d7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/dd4a3021d3ca41a293699bf898dbde0c.png