数据中台最后一公里：数据服务管理产品设计思路

本篇文章里，作者就数据服务的痛点、如何搭建好数据服务管理平台等方面做了总结，不妨来看一下。

数据的价值一个是数据驱动决策，主要通过数据可视化平台、自助bi分析工具提升决策分析效率。另一个是数据在业务端的创新应用，主要是api接口服务的方式，即daas（dataapi as aservice）。

数据化运营时代，对api接口的需求与日俱增。例如app首页的千人千面的个性化推荐接口，根据用户历史消费订单数实时弹屏新客大礼包，根据访问用户所处的生命周期，制定差异化的用户激励运营策略等。

你们公司，目前是如何构建和管理数据api服务的呢？

 

一、数据服务的痛点

1. 接口开发流程长

通常一个普通api接口的开发，需要数据开发工程师将数据按照业务逻辑进行清洗加工，再由java开发人员进行接口变现，即可以让业务端通过接口调用数据，例如实时查询当前访问用户的历史累计订单数，以判断用户是新客，进而派发新客大礼包。

对于个性化推荐接口，算法人员基于数仓模型进行特征数据分析处理，模型开发、训练调优，然后将模型提供给接口开发人员进行实时的推理服务。

不管是哪种形式的接口，都会涉及多个工种，经过n个环节，一个接口的上线周期至少以周为单位，这个时效对于业务端创新应用的支撑是远远不够的。

 

2. 开发人员稳定性差

对于普通的api接口，java开发可能只需要按照接口文档约定的出入参格式进行sql查询语句的封装再做一些性能调优就可以了，考虑接口性能问题多数逻辑都会在数据模型层处理好。

这种需求对于开发人员来说个人成就感是比较低的，看似每天都在忙，忙碌但缺少成功的输出。有更追求的开发不会愿意长期做接口变现，接口开发团队的人员稳定性是个问题。

 

3. 数据服务管理困难

对外输出的api接口太多，随着人员的离职更替，历史接口的逻辑、业务端的应用情况管理成了老大难的问题，因为找不到接口调用方，难以判断接口的应用场景，接口数量只增不减。

长期以来，需要维护的接口数量越来越多，服务器成本、运维成本都居高不下。

 

4. 接口问题权责不明

“不知道接口有谁在用”，这是经常听到接口开发讲的一句话，他们也很委屈，因为接口是四五年前开发的，前任并没有交接的那么详细。

即使通过接口可用性监控发现了服务异常，也没办法逐一地找到并通知应用方。只能被动地等着业务来反馈。甚至连监控都没有，时不时收到业务反馈说，这个接口是不是你们负责的，出了xx问题，你们排查一下。

因为服务以接口输出，接口出问题一般会直接找接口开发，接口开发通过翻代码发现是数据问题，又找到数据开发进行逻辑确认，“数据问题，我没法排查”，会出现相互推诿的情况。

 

二、数据服务管理平台的解决思路

数据中台的核心思想是能力复用和数据应用效率的提升，资产是数据中台的核心，没有资产的数据中台只能叫数据平台或工具。

因此，数据服务管理必须建立在数据资产层之上。数据资产层以onedata为方法论基础进行模型、指标的建设，构建分级分类清晰的数据资产管理与治理体系。

数据服务层作为数据中台价值输出的最后一公里，数据服务管理效率的高低，直接影响数据中台价值的体现，它提供的核心解决思路是复用资产层的数据能力，通过平台化、配置化的方式，快速生成api服务，减少定制化开发对不同工种的依赖。数据服务管理平台需要具备以下核心的能力：

 

1. 接口服务配置化

1）指标类接口

一般输出给定制化开发的可视化报表平台或业务端后台进行数据效果分析，指标类基本都可以抽象出来指标+维度+限定条件的方式，即：指标和数据模型绑定，从哪个表中取哪个字段，字段的聚合逻辑是什么，指标支持的分析维度有哪些？

前端页面调用时，传入指标id、限制条件参数，即可返回数值。指标管理平台处理管理统一指标外，还需要支持指标接口的服务化输出，这样针对定制化程度高、bi工具无法配置的可视化需求，如大屏可视化，只需要数据开发人员清洗好指标数据后，进行配置即可输出，无需接口开发介入。

2）用户或商品维度的接口

归根到底也可以归为指标类接口，但是由于数据的维度聚焦于单个用户或者商品，应用场景主要是精细化运营或产品智能，因此在场景配置方面需要一定的差异化。

承接的载体主要是cdp（客户数据平台）、画像平台等。在资产建设部分，讲用户画像、商品画像体系标签化，通过丰富的标签构建用户、商品的精细化分层能力。

例如北京环球度假区开业业务想借热点拉新（首次消费），于是通过用户标签和商品资源标签，找到了需要找到近期有旅游计划，目的是北京，曾经购买过迪士尼乐园等主题的景点的年轻用户，当符合条件的用户进入app首页，进行促销红包弹屏，刺激用户下单。

这类需求以运营场景为载体，最终输出的是用户id维度的接口服务或者批量数据输出，接口结构也非常容易标准化。

可以构建的配置流程是：多标签条件筛选目标人群或商品，构建运营场景（get接口调用方式还是post数据推送），生成输出接口对接业务端触达通道（站内实时访问时调用接口，或批量的短信推送服务）。

3）模型输出类接口

此类接口是最容易标准化的，就是直接将模型中的字段接口化输出，比如模型是团购订单明细宽表，业务端需要判断用户是否有待消费的订单，订单的业务类别、下单时间、消费时间等，以判断用户是否可以参与抽奖活动。只需要选择输入字段、输出字段、状态码以及应用信息即可。

这样，数据开发既是数据逻辑加工者，也是接口配置者，对结果负责，可以减少对java人员的依赖，提升业务赋能效率。

图片来源：阿里dataworks官网公开资料

4）个性化推荐类接口

大数据的出口是ai，数据赋能很大程度依赖ai赋能。产品千人千面个性化推荐、算法挖掘预测类用户画像标签，数据服务管理平台把标签管理、机器学习平台模型文件、在线推理接口服务整合起来，解决推荐接口caseby case开发效率低的问题。

图片来源：腾讯dmp modellab功能

总体来说，接口服务配置化是数据服务管理平台最最核心的能力，将接口生产流程产品化，数据开发、算法开发、甚至业务同学就可以自助完成接口配置上线，供应用端使用。

此时就不需要接口类的数据产品经理每天去和业务对需求，你的出参、入参是什么，统计逻辑是个啥，再转化成prd文档协调数据开发、接口开发排期了。

接口的响应周期主要取决于数据资产建设完善度以及新增模型（标签）的开发周期。java开发可以更聚焦于通用接口生产能力建设、接口性能调优工作，更具挑战性也更有成就感。

 

2. 数据血缘可视化

api接口平台化配置后，平台内接口与模型、字段的血缘关系以及接口与下游应用的关系数据可以很容易获取到。将这部分数据与模型加工产品的血缘链路进行关联补充，就可以形成从源端数据到api以及下游产品应用的全链路数据血缘，通过可视化展示方式，可以方便地知道接口生成链路。

上游数据异常时，也很方便排查影响范围，做好及时通知。

 

3. 性能监控实时化

数据服务接口一般面向toc的产品应用，接口稳定性和性能需要做到实时监控。

谷歌有一个著名的10x理论，即技术的相关指标要至少保证10x于当前业务，例如正常情况下业务接口流量qps为1000，那只要保证接口能够抗住10000的流量，这样才能更加稳妥的应对一些节假日高峰、爆款现象级产品或外部异常流量攻击。

因此，数据服务管理平台要具备接口实时流量、超时率、平均耗时、日均请求次数、错误率等服务指标，并且做到异常报警通知，电话、短信、邮件多渠道，以出现问题时可以第一时间跟进修复。

 

4. 接口管理线上化

过去接口管理方式是在线文档，文档传阅靠口口相传，严重影响接口的复用，且不同开发文档标准不统一。

通过线上化的方式把所有接口当做一种数据资产进行管理，接口的需求元数据（需求工单）、技术元数据、业务元数据等信息完善，并且可以查看接口文档、性能指标、流量控制、一键上下线处理，可以更加方便地管理线上接口。

 

5. 需求申请工单化

有了平台化的工具，是不是人人都可以直接配置接口使用数据了呢？

出于数据安全以及业务对数据的理解程度等方面，接口的配置权限还是要管控在数据开发、数据产品或者具备开发能力的业务开发角色中，相应的，就需要有配套的接口需求申请流程、已有接口申请token复用流程，并且和内部im结合，形成需求提交、工单流转、处理反馈的数据服务需求流程闭环。

 

三、总结

数据服务（api）是数据中台的最后一公里，是数据价值输出的重要形式之一，api生产效率的高低直接影响了数据对业务赋能的效率。

因此，作为数据产品经理，要多调研多分析服务流程现状、耗时最长的步骤或环节，寻求产品化的解决方案并不断优化，提升api服务与管理效率。