2019年3月18日“数据中台已成下一风口，它会颠覆数据工程师的工作吗？”一文火爆数据人的朋友圈，虽然此后关于数据中台有各种正、负向的文章，并没影响各家公进行中台实践的进程，有的专门把大数据平台部改名数据中台部。近期看到数据产品群里有人说“现在很多人很反感数据中台”，作为数据中台产品经理不禁虎躯一震。数据中台从众人追捧到“阿里彻底拆中台了”的唱衰反感，历时不到2年，难道数据中台真的凉凉了吗？

大数据的应用场景在前期文章“大数据除了”杀熟“还能干点啥？”有比较详细的介绍，在此不作赘述，对于重度依赖数据进行管理和决策的公司，相信很多人都经历过以下问题

1.指标口径不统一

运营部门和财务部门一起开会给老板汇报，微信消费用户数运营1021W，财务1000W，运营说我的数据是数据中心出的，财务说我的也是，那数据为什么不一致呢？原因数据开发A给运营出的报表，按照业务的口径以UnionID(微信唯一id)去重，数据开发B，给财务出的报表是按照memberID（注册会员id）统计，存在一个unionid绑定多个memberid的情况

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.开发平台百花齐放

很多公司缺少统一的数据开发平台，数据开发人员自己基于开源工具如azkabn、airflow、quartz自己搭建任务调度平台，甚至有的一个公司不同部门采用独立的调度工具，造成人力和资源的重复投入。

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

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

每个公司都在实践中寻找解决上述问题的方法，例如构建指标体系解决指标口径不一致的问题建设自助取数工具，业务自助取数不求人，开发人力释放专注于数仓模型建设开发配置化的BI可视化产品，减少可视化报表对接口开发、前端开发人力的依赖建设精准营销（DMP）平台，业务自助圈选目标用户进行精准触达，提升运营活动频率等。所以，个人理解，数据中台概念的出现，只是提供了一套完整的解决方案和思想，把原来的不成体系的“野路子“，扣上”中台“的帽子后，成了有方法论、战略的指引和支撑正规军了。

数据中台是一种大数据生态架构，不是单一的具体产品，而是产品体系。在数据的“存”、“管”、“用”环节，提供“高复用、提效率、降成本”的解决方案。每家公司在产品落地上会有个性化差别，但各个板块基本大同小异。

数据中台产品架构

以产品化的方式降低数据获取、数据分析、数据应用的成本，解决数据响应周期长、开发成本高、运营效率低问题

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

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

API服务统一管理，建立完善的应用血缘关系，提供通用接口的配置化生成能力，降低对Java开发的依赖。

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

没有资产的沉淀的数据中台只能叫数据平台，因为中台目标是数据的应用价值。因此，数据中台架构中，数据资产占据非常重要的地位。

数据流向

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

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

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

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

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

提供统一的数据开发平台，数据开发只需要关注数据处理逻辑，无需关注集群资源、任务调度，通过配置化的方式进行依赖关系配置，及任务运行周期，快速进行数据回溯、任务重启、停止

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

流数据处理，以FlinkSQL、StreamSQL为主要计算处理框架，实时处理消息队列等各种流式数据，输出实时报表、实时接口推荐等服务

提供异构数据源数据同步可视化工具，通过源和目标参数配置实现数据入湖、入仓，以及存储介质的转换，降低人肉脚本处理带来的风险和维护成本。

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

大数据集群上云，组件管理平台化，通过管理平台实现对HDFS、Kafka、Hbase等服务的在线运维管理。

Hbase管理、Kakfa管理、HDFS管理、ES管理等

从以上几个案例看，数据中台下的产品框架，为了解决面临的问题和调整提供方向指引，同样，在解决问题的实践过程所涉及的方案，也可以不断丰富数据中台产品体系，相辅相成，螺旋上升。

后续的文章将以单个产品切入，深入剖析数据中台架构下的产品解决问题的思路以及如何规划设计。

三、总结

数据中台没有“凉不凉”之说，可能未来会出现新的名称取代中台，但无论如何，当企业在数据化管理或数智化转型过程遇到对应的问题时，都可以基于中台的思想和架构去解决，围绕“业务数据化，数据资产化，资产价值化”，让数据高效率、低成本地赋能业务。数据人，低调沉稳，不管中台火不火，不追求浮华的概念的炒作，从解决问题的实际出发，建设自己的产品生态才是最重要的。

-END-