一、数字化转型面临的痛点问题
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，能解决业务痛点的，才是王道，说不定，几年之后又出现了新的名词，现有的产品体系是否可以更快的升级适应呢。
