数据价值平台化输出:数据服务平台
在数据中台的框架下,数据服务平台是整个数据中台的价值化输出,也就是经过了数据的接入、加工处理之后,这些数据是需要满足实际的业务应用需要,也就是说,数据服务平台是要解决从数据中台到数据应用的最后一公里。
那这最后一公里路上有哪些坑,或者说有哪些业务痛点呢?
数据服务平台要解决的问题
数据接口开发效率低
先来看下最常见的几种数据需求场景。
数据化运营场景:比如根据用户某种历史行为特征来动态的执行某种业务动作,这个是很常见的业务运营操作。
个性化推荐场景:算法人员基于数仓模型进行特征数据分析处理,模型开发、训练调优,然后将模型提供给接口开发人员进行实时的推理服务。
需求对接场景:比如在公司之间的数据买卖之间,往往需要针对需求去梳理数据。这就需要去找关于数据的各种文档去梳理,如果数据没有现成的,还需要走数据开发路径。
还有很多场景,通常情况下都需要多个角色,比如数据产品,数据开发,Java 接口开发等。再加上测试,一般需求的相应周期得以周为单位。特别是对于业务活动策划来讲,远远不能满足失效诉求。
服务的运维管理复杂
从服务的管理方面看:对外输出的 API 接口不断增多,随着人员的离职更替,历史接口的逻辑、业务端的应用情况管理成了老大难的问题,因为找不到接口调用方,难以判断接口的应用场景,接口数量只增不减。长期以来,需要维护的接口数量越来越多,服务器成本、运维成本都居高不下。
从服务的运维方面看:接口都谁在调用,调用情况是怎样的,出现数据异常要找谁来排错等等,这些都是日常管理中经常遇到的痛点。
以上这些痛点往往以来人力以及人力之间的协作,处理起来是相当复杂。所以就要对以上的问题进行抽象,把线下的无序管理转为线上的标准操作,那么这个平台需要考虑那些内容呢?
数据服务平台内容(面向业务)
本质上讲,数据服务是以接口化的方式满足业务实际需要。所以我们可以从接口的生命周期角度来切入,讨论下要包含哪些?
服务的构建
首先是服务的创建,这里要考虑的是接口的基础内容、运维、管理两个方面。
基础内容:接口自身的内容,如接口的输入输出,适用的业务场景说明等。
服务的运维:包括了接口的运行情况,调用情况,报错情况等内容的监控和维护,比如常见的运维指标有:接口实时流量、超时率、平均耗时、日均请求次数、错误率等服务指标。
管理方面:接口的技术维护,业务维护,所属部门等。其中技术维护需要在接口出现问题的时候,能够及时的告警并通知到相关人跟进修复。
一般情况下,服务的构建都是有平台专门指定的人来进行操作的,这个角色一般是通过平台的工单系统,或者线下沟通的方式,获取到业务的数据需求,然后会发起就接口的响应流程:通过开发,最后把服务注册到平台上。
还有一种情况是,平台自身提供从表到接口的线上化功能。也就是以自动化的方式,提供接口的定制化的创建和生成。
服务的应用
从服务的应用角度来看,基本主要是四个方面:
指标类接口:一般输出给定制化开发的可视化报表平台或业务端后台进行数据效果分析,指标类基本都可以抽象出来指标+维度+限定条件的方式,即:指标和数据模型绑定,从哪个表中取哪个字段,字段的聚合逻辑是什么,指标支持的分析维度有哪些?前端页面调用时,传入指标 ID、限制条件参数,即可返回数值。
用户/商品维度的接口:严格上此类接口也属于指标类,只不过使用这类接口的场景,往往不是直接用数,而是需要再这些数的基础上做二次的加工,所以一般对接到系统平台,比如 CDP 平台。
模型(表)类接口:直接将表以接口化的方式对外提供访问。
算法模型接口:这种是最容易标准化的一类接口,算法人员经过一通取数,建模,调优等操作后,将模型以接口的方式对外提供访问。
此外,在数据排错场景下,需要知道接口的数据的来源,和一个接口的下游使用方都有哪些,往往也需要有关于数据链路的可视化展示功能。
以上,本文尝试以平台化的视角,从数据使用过程中需求对接、管理、运维等视角下的痛点出发,以接口生命周期的角度切入,介绍了平台包含的主要模块及模块中具体的内容。
了解平台需要包含的内容之后,那么从产品设计视角,这个数据服务平台怎么搭建呢?
数据服务平台如何设计(面向人)
产品角度看,数据服务的核心在于数据表到数据 API 的能力,提供对 API 进行统一管理和发布(可支持一键创建数据抽取任务),并通过授权访问的方式供外部应用系统调用 API 获取数据。所以从产品设计上也围绕这一核心思路展开。
服务的浏览与查询
浏览与查询可能是这个平台最基础的功能,主要面向平台使用方,比如各 BU 的业务人员,业务系统开发等。这块包含的内容有:
提供数据服务的概览、查询、服务详情等(当然要考虑的权限因素,这里就不展开讨论)。
图:数据服务概览示意图
提供数据的血缘关系:主要是面向业务分析场景,数据质量异常时,辅助寻找出现问题的节点。
服务的创建
面向平台的内容创建者:比如产品经理,业务运营等人员提供的功能有:
服务的创建:包括服务(来自本地的,云端,第三方等)的注册,服务文档的撰写,接口调用示例等。
服务目录:提供目录的维护与更新。这个往往会按照部门,或者业务线的方式进行划分。
服务的管理:如上下线、限流(有些限流可以运维的基础上加入规则以实现问题的自动发现和自动化处理)、版本更新等。
服务文档的编辑:随着业务的发展,接口的功能也会不断地变化,需要有比较好用的文档编辑器,去维护、接口版本、版本的内容、变更的背景、维护人等信息。
平台的管理
这块主要是站在平台管理者的视角,需要具备的功能:
接口服务的生产与调用情况监控。
平台数据化运营的需要,比如平台纳管的服务总数,按服务使用量角度的情况分析,各种状态下的服务占比情况等。
最后参考下某中台厂商的数据服务平台设计
图:数据服务平台示意图
OK 到这里,本文尝试从问题出发,拆解下数据服务平台应该包含哪些方面,最后从产品设计角度,从不同角色角度看平台的模块功能设计。
参考:
题图来自 Unsplash,基于 CC0 协议
版权声明: 本文为 InfoQ 作者【Taylor】的原创文章。
原文链接:【http://xie.infoq.cn/article/2db9b1d86764d7f1b406e980a】。文章转载请联系作者。
评论