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


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

文章插图
本篇文章里 , 作者就数据服务的痛点、如何搭建好数据服务管理平台等方面做了总结 , 不妨来看一下 。
数据的价值一个是数据驱动决策 , 主要通过数据可视化平台、自助BI分析工具提升决策分析效率 。另一个是数据在业务端的创新应用 , 主要是API接口服务的方式 , 即DAAS(dataAPI as aservice) 。
数据化运营时代 , 对API接口的需求与日俱增 。例如APP首页的千人千面的个性化推荐接口 , 根据用户历史消费订单数实时弹屏新客大礼包 , 根据访问用户所处的生命周期 , 制定差异化的用户激励运营策略等 。
你们公司 , 目前是如何构建和管理数据API服务的呢?
一、数据服务的痛点1. 接口开发流程长通常一个普通API接口的开发 , 需要数据开发工程师将数据按照业务逻辑进行清洗加工 , 再由Java开发人员进行接口变现 , 即可以让业务端通过接口调用数据 , 例如实时查询当前访问用户的历史累计订单数 , 以判断用户是新客 , 进而派发新客大礼包 。
对于个性化推荐接口 , 算法人员基于数仓模型进行特征数据分析处理 , 模型开发、训练调优 , 然后将模型提供给接口开发人员进行实时的推理服务 。
不管是哪种形式的接口 , 都会涉及多个工种 , 经过N个环节 , 一个接口的上线周期至少以周为单位 , 这个时效对于业务端创新应用的支撑是远远不够的 。
2. 开发人员稳定性差对于普通的API接口 , Java开发可能只需要按照接口文档约定的出入参格式进行SQL查询语句的封装再做一些性能调优就可以了 , 考虑接口性能问题多数逻辑都会在数据模型层处理好 。
这种需求对于开发人员来说个人成就感是比较低的 , 看似每天都在忙 , 忙碌但缺少成功的输出 。有更追求的开发不会愿意长期做接口变现 , 接口开发团队的人员稳定性是个问题 。
3. 数据服务管理困难对外输出的API接口太多 , 随着人员的离职更替 , 历史接口的逻辑、业务端的应用情况管理成了老大难的问题 , 因为找不到接口调用方 , 难以判断接口的应用场景 , 接口数量只增不减 。
长期以来 , 需要维护的接口数量越来越多 , 服务器成本、运维成本都居高不下 。
4. 接口问题权责不明“不知道接口有谁在用” , 这是经常听到接口开发讲的一句话 , 他们也很委屈 , 因为接口是四五年前开发的 , 前任并没有交接的那么详细 。
即使通过接口可用性监控发现了服务异常 , 也没办法逐一地找到并通知应用方 。只能被动地等着业务来反馈 。甚至连监控都没有 , 时不时收到业务反馈说 , 这个接口是不是你们负责的 , 出了XX问题 , 你们排查一下 。
因为服务以接口输出 , 接口出问题一般会直接找接口开发 , 接口开发通过翻代码发现是数据问题 , 又找到数据开发进行逻辑确认 , “数据问题 , 我没法排查” , 会出现相互推诿的情况 。
二、数据服务管理平台的解决思路数据中台的核心思想是能力复用和数据应用效率的提升 , 资产是数据中台的核心 , 没有资产的数据中台只能叫数据平台或工具 。


以上关于本文的内容,仅作参考!温馨提示:如遇健康、疾病相关的问题,请您及时就医或请专业人士给予相关指导!

「四川龙网」www.sichuanlong.com小编还为您精选了以下内容,希望对您有所帮助: