数据中台为什么需要数据服务？

摘要：最近在做一个数据中台项目，设计到和业务系统数据中台和业务系统数据打通，目前遇到一个问题，业务系统希望数据中台按照业务系统的字段格式进去数据推送数据，而这存在问题，面临了按照业务系统提供的字段格式推送数据就存在个性化的问题，数据推送服务无法通用和复用，但是如果不提供按照业务系统的格式推送数据的服务，则业务系统需要开发新的通道或者后端代码进行访问中台的数据服务，这里涉及到业务系统的改造。后期中台还要面临和其它业务系统的对接，如果全部按照业务系统提供的格式进行对接，会出现什么情况，以及为什么当初中台诞生的时候，会加一层微服务层，即数据服务API给业务系统调用，而不是直接访问中台的数据层了？带着这个问题，我们来一探“为什么数据中台需要数据服务？”这个问题。

• 数据服务诞生的背景是什么？

• 数据服务是什么？‍‍‍‍‍‍

• 为什么中台提供数据服务，而不是按照业务系统的要求和格式各自开发数据服务了？‍‍‍‍‍‍‍‍

01

—

数据服务诞生的背景‍‍

在数字化转型的背景下，企业面临着快速增长的新需求和不断迭代的新技术，因此提升企业的数据开放共享能力变得至关重要。传统的方式，如使用后端开发语言编写API接口，开发周期长，运维成本高，并且业务系统之间的服务调用错综复杂，缺乏复用性，导致整个企业的IT开发和运维成本增加。为了解决这个问题，很多企业引入了一层服务层作为中台，为标准化企业数据服务，打通中台和业务系统的数据访问和数据交互。

这一服务层的作用是将各种服务进行标准化，提供统一的接口和规范，从而降低开发和运维的成本，并增加服务的复用性。通过服务层，企业可以更快速地开发和部署新的API接口，满足业务需求。此外，服务层还可以提供安全认证、性能监控、访问控制等功能，保证数据的安全性和可靠性。

为了更多的解决这些问题，我们在企业开放、共享数据过程中需要确定以下目标：

1、快速构建 API

2、系统稳定、数据安全

3、易于集成使用，兼顾业务需求和访问通用性。

4、授权交付

5、低成本运维 

通过建立数据中台和标准化的服务层，企业可以更好地满足数字化转型的需求，提升数据开放共享能力，实现更高效、灵活和可扩展的业务系统。

02

—

数据服务是什么‍‍

从 数据服务本身来说，主要是解决异构数据源、重复建设、审计运维困难、理解困难这 4 个问题。通过数据 服务，实现主题式数据服务、统一且多样化数据服务、跨源数据服务的服务目标。

构建一个完整的数据服务平台需要具备以下要素：

1、便捷开发能力：平台应该提供低代码开发能力，让开发人员能够更快速地创建数据服务，减少繁琐的编码工作。

2、简化管理：平台应该提供可视化的API管理功能，使用户能够方便地查询和管理已创建的API。这样可以有效降低运维成本。

3、规范化文档：平台应该提供规范化的文档描述信息，使用户能够轻松理解和使用数据服务。

4、安全稳定：平台应该提供服务调用追踪监控、服务使用审计和鉴权等安全机制，以保证数据服务的安全性和稳定性。

5、简化运维：平台应该提供简化的测试、故障排查和问题规则配置等功能，方便运维人员进行系统维护和管理。

6、高性能：平台应该具备负载均衡和高并发处理能力，以满足大量并发访问和高性能的需求。

基于以上的数据服务平台的要素，那么如何构建服务了？

● 第一步：API 定义

API 的定义包括：选择需要发布的服务的主题表一张或者多张，快速配置参数、选择排序字段、自定义查询条件、访问入参和出参的定义、返回数据格式等方面。 

● 第二步：API 发布 

API 的发布包括测试、提交至 API 网关、发布至 API 市场、版本管理这几个方面。

● 第三步：API 调用 

API 调用包括数据预览、API 申请、审批、下载接口文档、正式调用这几个方面。 

● 第四步：调用监控 

技术上：通过 API 调用的统计图表进行分析可以发现，哪些 API 最受欢迎；而哪些几乎无人问津，应该被淘汰；

安全上：对调用 IP、调用次数进行监控，对调用者进行溯源。

● 第五步：数据安全

数据安全包括：统一认证鉴权、传输加密、安全组、角色分配、行级权限、调用审批等。

企业服务中心产品应该具备以下特点：

快速构建：支持0代码或低代码快速构建API，通过配置即开发的方式实现快速构建。

高安全性：提供用户认证、监控、传输加密、API级别安全策略、行级权限、角色分配、调用申请审批、调用周期次数的限制、黑白名单等安全措施，确保数据的安全性。

高灵活度：支持服务编排，可以对不同的API进行组合，并且支持集成Python进行数据处理。还可以通过条件判断节点选择符合条件的分支，提供更灵活的数据服务。

配置灵活：支持横向拓展API网关和缓存，使得服务中心的能力可以按需扩展。

低成本运维：采用Serverless架构，减少运维成本。用户只需关注API本身的业务逻辑，无需过多考虑运行环境等基础设施。

以上特点可以帮助企业构建完整的数据服务平台，提高数据开放共享能力，并与业务系统实现有效的集成

03

—

为什么中台提供标准的数据服务？‍‍‍‍‍‍‍

企业服务中心诞生的背景前面已经介绍了，本节就想重点对比一下无企业服务中心和有企业服务中心的区别以及开发成本的对比。

如下图是传统的后端开发API直接访问中台表的情况，假设中台有4张表是通用的表，需要给到应用层的OA\HR\ERP\CRM\SCM\WMS六个系统调用，那么每个业务系统后端必须自己开发服务，则会总共出现24个服务。而且这些服务没有任何复用性，新的业务逻辑，则需要开发新的数据服务，导致随着业务量的变化，数据服务的总体数量呈几何增长，而这些服务都直接挂在数据库上，或者是olap的数据库上，对数据库访问造成极大的压力，可能会出现性能瓶颈。另外开发成本也会很高。

那么新的企业服务中心的服务模型是怎样的？

从这张图可以看出，各业务系统没有直接访问中台的表，而是访问的是4张表的服务，

第一个方面：带来业务系统开发成本的降低、对于业务系统来说，可以直接使用前端进行访问服务，则业务系统不需要开发后端代码，这个是一方面的成本降低。

第二个方面：带来中台的开发成本的降低。另外就是当新增别的业务系统的时候，对于中台来说，不需要再重新开发数据服务，这个也是在中台侧带来的开发成本的降低。‍‍‍‍

当然这个里面的数据服务一般是通用性的，对提供的数据格式是标准的，无各种嵌套等格式，便于其它的系统也可以使用数据服务，因此对于个别业务系统如果需要特别的格式，则可以重新发布一个特定格式的数据服务（企业服务中台提供可视化配置方法，开发数据服务的成本较低）。‍‍

通过以上情况可以分析，数据中台这一层服务除了提高服务的安全性、简化运维，提供高性能的服务以外，可以降低成本，从如上图所示，对于业务开发来说，因为每个业务系统独自维护自己的服务，到演变成中台抽离出一层来说，每个业务系统维护的服务个数没有变化，业务系统维护的前端或者后端服务只处理和业务逻辑有关系以及前端展示有关系的逻辑（例如格式）。而中台只提供标准的数据服务，未来增加新的业务系统，也不需要再来开发一遍数据服务，那么新增业务系统的开发，不会带来中台服务开发人员的增加。这个是另外一个层面的成本降低，一般情况下，一个企业里面业务开发人员和中台开发人员的比例是1:10的比例。中台开发人员相对较少。‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

再提到前文说到的一些矛盾，对于老的系统，本来已经存在的系统，如果需要访问中台的数据，则需要对业务系统进行改造，因为原来业务系统是直接访问中台的数据库表，但是现在加了一层数据服务，则存在说业务系统原始的后代代码的改动，但是这个改动是从长远的规划以及企业发展来说，现在做一些改动可以为未来带来较大的成本降低，因为本质上老的系统对于数据中台的数据访问需求比较少，因为本来原来系统所需要的数据本身是来自系统自己本身的业务数据，现存的各业务系统，例如OA,HR,ERP,SCM,WMS都有自己各自的业务数据库，那么在什么场景下是需要数据中台的服务，一般是产生新的业务需求，例如例如ERP需要SCM的数据，也就是说，原始老的系统业务对中台的数据需求并不多，中台的数据服务主要是应对数字化转型下各业务系统新增的业务需求，或者新的创新应用，而这些新的业务则会是重新开发前后端代码，所以使用中台的服务的场景会比较多。面对新的业务需求，在降本增效的前提条件下，使用企业服务中心，可以降低中台的开发成本、运维成本、简化管理、同时也可以降低业务开发的成本，中台的服务可以直接作为业务应用的后端服务（业务的前端调用中台的服务）。‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

以上是我对数据中台的数据服务的理解，希望对您有所帮助。‍‍

欢迎加入【数据行业交流群】社群，长按以下二维码加入专业微信群，商务合作加微信备注商务合作，AIGC应用开发交流入群备注AIGC应用

往期历史热门文章：