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

文章插图
一、数字化转型面临的痛点问题
文章插图
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. 数据中台与数据平台、数据仓库的关系
文章插图
在数据中台概念清晰之前，各个互联网公司其实也都做了很多的基础建设工作，只是没有明确地定义为数据中台而已。

稿源：(人人都是产品经理)

【傻大方】网址：http://www.shadafang.com/c/110594554H021.html

标题：可视化|搞了三年，再看数据中台的价值与解决方案