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

2021-11-04 18:21 浏览量:607

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

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等

智能营销平台(DMP):基于大数据计算和数据挖掘技术,构建用户画像标签体系,用户圈选、精细化分层,进行差异化运营和营销触达,提升运营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,能解决业务痛点的,才是王道,说不定,几年之后又出现了新的名词,现有的产品体系是否可以更快的升级适应呢。

 

 

来源:数据干饭人

作者:千冰仪

上一篇:数据中台:怎样评价数据资产的健康度?

下一篇:企业数据治理方法论,4000字都在这里了(建议收藏)

  • 分享:
龙石数据
咨询电话: 0512-87811036,18013092598
联系我们
商务联系微信

商务联系微信

0512-87811036,

18013092598

咨询电话