搞了三年,再看数据中台的价值与解决方案

4 评论 16918 浏览 47 收藏 18 分钟

编辑导语:数据中台能够为企业收集数据信息,企业根据信息而制定方案。但是如何将数据中台的价值发挥最高,想必这是一个头疼的问题。本篇文章,作者搞了多年的数据中台,为大家提供一些思路。

一、数字化转型面临的痛点问题

1. 指标口径不统一

产品部门和财务部门一起开会给老板汇报,APP下单用户数产品1021W,财务1000W,产品说我的数据是数据团队出的,财务说我的也是,那数据为什么不一致呢?原因数据开发A给运营出的报表,按照业务的口径以设备ID去重,数据开发B,给财务出的报表是按照userID(注册会员id)统计,存多设备登录的情况。

2. 数据质量差

指标表现异常,业务第一反应就是“是不是数据不准啊”,这时作为数据部门如何能够有底气来反驳这种DISS呢?数据业务系统同步到数仓,ETL加工,再输出到报表应用,会经过多个步骤,每一个步骤都有可能会出现任务的异常、延迟以及人为的bug,监控覆盖足够健全,业务反馈问题时,数据开发就可以自信的说,今天数据无异常(没有收到报警),而不是我先确认下。

3. 数据重复建设

缺少统一的数仓建设和管理规范,CaseByCase地响应业务需求,往往会导致数据的重复建设,例如,数据开发A接到产品的大盘流量报表需求,直接基于ODS的明细数据进行ETL,加工出自己的为了满足这一报表需求的APP层表,数据开发B,接到会员营销的需求,报表指标不尽相同,小A的APP层表无法直接使用,于是自己又加工了新的数据表,由此,导致相同指标多个模型出现,但又无法复用,造成重复建设。

4. 数据找不到

业务发展加上数据的重复建设,数据表的数量在10W+,缺少工具的指引,尤其是新用户很难找到需要的数据在哪个表里,处理逻辑是不是自己需要的。

5. 数据成本增长快

随着业务需求发展,数据处理所需要的存储和计算成本也线性或指数增长,对于DAU千万级的互联网公司,每个月大数据集群的资源成本可能也在百万~千万级,是真正的成本中心了。往往一线数据开发很多只关注新增业务,不去梳理历史任务,或者一些低效的SQL任务占据了大量的资源。

6. 数据报表开发周期长

定制化的数据可视化报表开发需要数据开发、接口开发、前端开发、产品迭代、活动上线节奏非常快,都需要对应的报表监控支持,单个报表的开发周期往往在1~2周,对开发资源的依赖导致需求响应周期长,很多时候报表上线了,活动结束了。

7. 数据需求响应慢

对于无SQL的业务人员很多探索性的数据分析依赖于数据开发的SQL取数,一般SQL取数都是由数仓兼职进行,时间排期就有限,只能按照提需时间或者紧急需求的申请通道进行处理,临时取数的时效性要求更高,经常出现数据输出了,业务意见拍脑袋做完决策了。可能有人问可不可以安排全职取数,对于有个人追求的程序员,一直做SQL取数,估计很快就要离职了。

8. 数据服务难追踪

数据部门会输出很多的API接口,由于历史久远文档不完善加上业务不断调整变化,导致接口和应用链路断层,接口出问题只能由业务反馈后处理。梳理出流量小的接口要做下线,却找不到应用端的人确认,只能先下线看下,有人反馈再处理。

9. 数据输出效率影响运营频率

精细化运营背景下,用户运营每个营销场景需要最精准的确定目标人群,比如会员生日关怀、迪士尼目标用户群体投放等,业务需要先找数据部门获取目标用户的id信息,再进行投放,数据部门的响应周期和效率制约了运营活动的投放频次,即数据每周可以处理3~7次人群调取,那运营活动肯定不能超过这个频率。

二、数据中台为什么成为企业推崇的“新思路”

1. 数据中台的核心思想

关于数据中台的定义和概念,已经被讲烂了,结合近三年的数据中台实践,总结一下就是“让数据更快、更省地用起来”的一种思想、架构。也就是,数据中台所做的一切,最终的目标都是数据价值的挖掘和应用输出,为了达到这一目标,涉及数据的采、存、管、治、用各个环节和流程,可以用来“降本增效”的产品,都归属于数据中台产品体系。

2. 数据中台与数据平台、数据仓库的关系

在数据中台概念清晰之前,各个互联网公司其实也都做了很多的基础建设工作,只是没有明确地定义为数据中台而已。

每个公司都在实践中寻找解决数据应用实践方法,例如构建指标体系解决指标口径不一致的问题;建设自助取数工具,业务自助取数不求人,开发人力释放专注于数仓模型建设;开发配置化的BI可视化产品,减少可视化报表对接口开发、前端开发人力的依赖;建设精准营销(DMP)平台,业务自助圈选目标用户进行精准触达,提升运营活动频率等。

所以,个人理解,数据中台概念的出现,只是提供了一套完整的解决方案和思想,把原来的不成体系的“野路子”,扣上“中台”的帽子后,成了有方法论、战略的指引和支撑正规军了。

可以把数据中台类比成汽车工厂,如果发动机、轮胎等零配件已经生产完毕,可以很快组装出一辆汽车。而Hadoop生态,集群建设,就像水电煤等基础设施,提供工厂运行所需能源支持,大数据平台,数据开发工具就像是机床设备,提供制造零配件的工具能力,而数据仓库的建设,则像是用机床加工好各自零配件,并且提供快捷的仓库索引目录,能够最短时间找到所需配件。

三、数据中台需要具备的核心能力与产品架构

1. 数据中台的核心能力

数据汇聚:将异构数据源通过源和目标参数配置实现数据入湖、入仓、以及存储介质的转换、降低人肉脚本处理带来的风险和维护成本。构建统一的数据集散中心,打破数据孤岛。

资产沉淀:将数据提纯加工,形成可快速使用的数据模型,建立完善的数据共享机制与安全管控流程,构建数据复用能力。同时需要对资产进行常态化、周期性的质量管控与治理。

产品化能力:数据采集、资产管理、数据应用流程的平台化、配置化,基于工具实现数据的快速流转,提升数据输出的效率。

业务赋能:数据驱动决策、为产品智能化、运营精细化赋能。一是赋能效率的提升,二是赋能过程的数据资产管控。

2. 数据中台产品架构

(1)数据应用效率问题

自助BI与可视化分析:以产品化的方式降低数据获取、数据分析、数据应用的成本,解决数据响应周期长、开发成本高、运营效率低问题。

能力要求:集成数据建模、自助分析、数据可视化、数据治理、智能分析的一站式数智化决策分析平台,数据开发专注数仓模型建设,提供健全的模型、完善的资产元数据信息后,业务拖拽式、可视化的数据查询和分析,不需要数据开发介入。针对需要周期性使用的数据,可以保存成可视化Dashboard,自助进行可视化报表减少,释放接口和前端开发人力。比如:QuickBI、观远、帆软BI、tableau等。

智能营销平台(CDP):基于大数据计算和数据挖掘技术,构建用户画像标签体系,用户圈选、精细化分层,进行差异化运营和营销触达,提升运营ROI。业务同学可基于平台实现从人群圈选、场景构建、触达投放、效果回收的闭环,同时,基于算法挖掘标签及模型推荐的人群组合,从基于人的经验运营,到基于大数据算法推荐的智能运营。

(2)数据资产建设与治理问题

21年云栖大会,阿里云数据中台负责人强调,要在场景的驱动下,把数据中台的资产模块做的更厚实。

目标:提供数据资产建设、资产管理与治理的完整产品方案,通过数据资产化管理和共享流程提高数据复用性,减少重复开发成本,基于完善的监控覆盖保障数据质量,并周期性的盘点、治理资产,达到降本的目标。

数据地图:通过业务域、主题、标签、字段元数据等信息,帮助用户快速检索到目标数据,基于条件过滤或自助搜索,“逛数据”,“用数据”。

数据质量监控:围绕“准确性、一致性、及时性、唯一性、完整性”等标准维度,提供配置化的质量监控规则,对数据表数据量、字段值进行监控覆盖,从源头及时发现数据问题并加以干预,保障数据质量。

数据血缘:数据入湖到输出应用经过多个环节,上游数据问题如何快速通知下游,下游数据逻辑排查如何向上追溯,以及数据治理表或路径下线,如何评估下游的影响并通知,都依赖于全链路数据血缘的建设。可以说,完善的血缘功能,可以极大提高数据开发的工作效率。

成本优化:数据有自己的生命周期,比如活动期间的数据监控报表,活动下线后,报表可以下线释放资源。成本优化提供高耗任务、小文件、冷数据等不同治理维度的指标,及治理目标,从资产健康度评估维度,指导数据开发人员主动进行成本优化、数据治理,系统层面具备治理目标检测、一键治理、数据回收、彻底删除等治理功能,并且可以基于固化的治理规则,进行系统自动化治理。

(3)数据开发流程的效率问题

目标:提供异构数据源数据同步可视化工具,通过源和目标参数配置实现数据入湖、入仓,以及存储介质的转换,降低人肉脚本处理带来的风险和维护成本。建设统一的数据开发平台,数据开发只需要关注数据处理逻辑,无需关注集群资源、任务调度,通过配置化的方式进行依赖关系配置,及任务运行周期,快速进行数据回溯、任务重启、停止。

数据集成:业务数据库、操作日志、状态变更消息等数据源接入数据中心,如Biglog同步、MySQL库表订阅、Kakfa数据落HDFS等。数据经过实时或离线ETL后,数据集成再将数据输入CK、Hbase、ES等供业务端应用。

离线开发平台:批数据处理,一般为T+1或小时级的准实时数据,包括任务逻辑处理、依赖配置、调度配置、任务运维等功能。

实时开发平台:流数据处理,以FlinkSQL、StreamSQL为主要计算处理框架,实时处理消息队列等各种流式数据,输出实时报表、实时接口推荐等服务随着批流技术组件的发展,批流一体化开发平台的建设也陆续在实践中。

(4) 数据服务快速输出

有人也把数据中台称之为DAAS,即数据即服务,数据如何快速输出业务端,赋能产品创新。API服务统一管理,建立完善的应用血缘关系,提供通用接口的配置化生成能力,降低对Java开发的依赖。

数据服务管理平台:数据中台思想下,数据服务输出是应用输出的最主要形式,数据服务管理平台一方面要具备将数据资产自助配置化输出的能力,即数仓清洗好的数据模型,数据开发或业务人员可以通过入参、出参的可视化配置生成API接口,不需要接口开发介入。同时也要把API资产化管理,API接口文档、应用调用情况做到可追踪、可监控。

四、数据中台的成熟度评估

如何评价数据中台建设的怎么样了呢?可以数据战略、数据平台与架构、数据资产管理、数据治理、数据产品化、数据服务化、中台产品运营等7个维度,进行量化打分。

五、总结

数据中台不是产品,而是为了让数据更快、更省用起来的一些列产品组件而成的数据产品矩阵与解决方案。企业在数据中台解决方案规划时,要基于目前数据在采、存、管、治、用各个环节的痛点,进行针对性的降本提效建设。数据中台是不是YYDS,能解决业务痛点的,才是王道,说不定,几年之后又出现了新的名词,现有的产品体系是否可以更快的升级适应呢。

#专栏作家#

数据干饭人,微信号公众号:数据干饭人,人人都是产品经理专栏作家。专注数据中台产品领域,覆盖开发套件,数据资产与数据治理,BI与数据可视化,精准营销平台等数据产品。擅长大数据解决方案规划与产品方案设计。

本文原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 少有的精彩

    来自北京 回复
  2. 特别棒的文章,谢谢分享!受益颇多!

    来自浙江 回复
    1. 谢谢,欢迎沟通交流

      来自江苏 回复
  3. 希望日后多些案例分享,干货多就是趣味性不高。

    来自广东 回复
专题
31295人已学习19篇文章
2018年过去了,你都收获了什么?新的一年,你需要如何前行?
专题
32396人已学习10篇文章
社交产品是大坑?没get到这些知识点,可能你才是个大坑。
专题
34271人已学习16篇文章
信息流背后有着怎样的逻辑和策略?
专题
36232人已学习14篇文章
原型对于产品经理来说是一门必修课。
专题
44013人已学习16篇文章
设计库存、财务、退换货流程时不用一个头两个大了。