后起SAAS企业如何做数据中台？

在企业数字化转型成为大势所趋，大厂引领数据中台建设并且大包大揽的大背景下，本文就中小SAAS后起企业的数据中台该做什么以及如何做谈谈想法和思路，欢迎交流和斧正。

首先开门见山，定义一下什么叫数据中台？

如上图始于隋，确立于唐的中国古代封建社会的中央官制-三省六部制就已经具备了使用中台模式管理的实践和能力：向下集中六部权力至三省，向上赋能皇帝，不管是刚登基的皇太子，还是垂帘听政的皇太后都可以轻松掌管朝政事务。由于该制度的严密和规范不仅增强了行政决策的效率，同时也减轻皇权的个人影响。该制度的两个核心：集权和赋能。对应到我们数据中台也是这个道理，比如下图所示一种数据中台架构：

注意中间部分的大数据中台通过集中下层的数据存储、传输和计算等能力，向上赋能业务决策和创新应用等。正是由于这种大中台、小前台的架构，使得上层的决策和应用能够高效开展。于是我们可以定义数据中台为基于大数据平台提供数据共享和能力复用的平台，依据企业特有的业务模式和组织架构，通过有形的产品和实施方法论支撑，构建的一套持续不断把数据变成资产并服务于业务的机制。

中台既然如此强大，肯定不止一个数据中台，就像三省六部制中，除了中台还有西台和东台。那除了数据中台还有哪些中台呢？业务中台、技术中台、研发中台和AI中台都是常见的中台形式，各部分功能列举如下：

• 业务中台抽象、包装和整合后台资源，转化为便于前台使用的可重用、可共享的核心能力，实现了后端业务资源到前台易用能力的转化。服务中心是实现业务中台的典型方式，如交易中心，商品中心等。

• 数据中台接入业务中台、后台和其他第三方数，完成海量数据的存储、清洗、计算、汇总等，构成企业的核心数据能力，为前台基于数据的定制化创新和业务中台基于数据反馈的持续演进提供了支撑。

• 技术中台整合和包装了云基础设施，以及在其上建设的各种技术中间件，比如微服务、分布式缓存、消息队列、搜索引擎、分布式数据库等，并在此基础上建设和封装了简单易用的能力接口。

• 研发中台是关注应用开发效率的管理平台，涉及项目管理、团队协作、流程、测试、部署、运营、监控等方面可重用能力的沉淀。

• AI中台借助数据中台的能力，尝试解决模型的训练、发布，智能服务的构建自动化，统一的元数据管理体系，模型的全生命周期管理等问题。

各部分联系可描述为如下图示：

其中数据中台和业务中台紧密结合相互促进，共同赋能前台业务，是企业中台普遍采用的方式，即双中台战略。

在决定数据中台要怎么做之前，需要明确下数据中台的核心能力。这里总结4点：

• 数据整合汇聚（如下图数据采集功能）

• 分析处理（如下图中间两层：数仓建模，分析建模，算法建模）

• 数据应用和服务（如下图最上层）

• 价值变现

其中分析处理是企业数据资产化的过程，价值变现是数据中台的终极目标。

围绕着数据中台的核心功能，还需要一系列配套功能的支持，如存储管理、集群管理、离线数据管理、调度管理和可视化管理等：

其中存储管理、集群管理作为数据平台基础功能，是数据中台建设不可缺少的部分，也是企业做数据平台技术选型很关键的一个环节。结合其他扩展功能一起构成一个最小化内核的数据中台，但是只提供基本的数据处理和数据可视化功能，缺少对数数据资产的管理和对底层平台的维护，这样的数据中台是功能不完备、系统不稳定的。然而如果需要一个相对完善、功能完备的、可靠的数据中台，以下功能是必不可少的：

我们将这些基本功能划分为不同的模块，然后根据是否必需，整理为如下表格：

其中红色的功能是最小化数据中台内核的组成部分。在表格中可以看到，标签管理、指标管理、元数据管理和数据质量管理等都被看做资产管理范畴之内，实际上由生命周期管理、安全管理和数据质量管理构成的数据治理本身也是为数据资产管理服务。因此数据资产管理就成为数据中台建设的核心，数据服务就是数据资产的功能外溢和体现。于是关于数据中台做什么的问题，可以用下图来回答：三个基本面：数据汇聚联通、数据体系化和服务体系建设。

数据中台建设就是围绕数据资产管理在数据整合融汇的基础上进行数据体系化和服务的体系化建设，然后在此基础上通过数据治理实现数据资产的管理，最终落地为以下图中的功能模块：

了解了数据中台是什么以及数据中台要做什么，似乎做数据就是必选项了就可以该快马加鞭去干了。但是回归初心，多去思考下我们为何要上路，终究是有好处的，毕竟这条路不那么好走：

1. 消费互联网到产业互联网过渡

2. 产业互联网数字化转型势在必行

3. 企业数字化领域的营销、管理和生产成为驱动业务提升的重要方向

4. 具备数据处理能力沉淀和业务能力复用的数字化中台成为数字化运营的最佳模式。作为数字化中台的双驱-数据中台和业务中台是业界普遍采用的方式。

可以说正是因为企业不甘落后地数字化的内部驱动力给了SAAS企业机会：

市场永远不缺乏竞争者，后起SAAS企业是时候盘点下自身能力了，下面从以下几个维度帮他们梳理下：

SAAS企业成功的两大因素：产品价值突出，思想先进。产品价值主要体现在能否高标准、超预期解决客户问题，思想主要体现在是否有一套一贯的理论体系和方法论。如果没有，还可以站在巨人的肩膀上，引进吸收：

做好了思想上（方法论）和物质上（技术储备）的准备，接下来探讨下如何实施中台的建设，以下重点从最重要的数据体系方面来介绍。

数据体系建设重在模型的规范，对数据模型的规范实施，通常采用分层的方式，如下：

各层的具体含义介绍如下：

❏操作数据层ODS（Operational Data Store）：对各业务系统数据进行采集、汇聚，尽可能保留原始业务流程数据，与业务系统基本保持一致，仅做简单整合、非结构化数据结构化处理或者增加标识数据日期描述信息，不做深度清洗加工。

❏统一数仓层DW（DataWarehouse）：又细分为明细数据层DWD（Data Warehouse Detail）和汇总数据层DWS （Data WarehouseSummary），与传统数据仓库功能基本一致，对全历史业务过程数据进行建模存储。对来源于业务系统的数据进行重新组织。业务系统是按照业务流程方便操作的方式来组织数据的，而统一数仓层从业务易理解的视角来重新组织，定义一致的指标、维度，各业务板块、业务域按照统一规范独立建设，从而形成统一规范的标准业务数据体系。

❏标签数据层TDM（Tag DataModel）：面向对象建模，对跨业务板块、跨数据域的特定对象数据进行整合，通过ID-Mapping把各个业务板块、各个业务过程中的同一对象的数据打通，形成对象的全域标签体系，方便深度分析、挖掘、应用。

❏应用数据层ADS（Application DataStore）：按照业务的需要从统一数仓层、标签数据层抽取数据，并面向业务的特殊需要加工业务特定数据，以满足业务及性能需求，向特定应用组装应用数据。

对数据进行分层的一个主要原因就是希望在管理数据的时候，能对数据有一个更加清晰的掌控，详细来讲，主要有下面几个原因。

1. 清晰数据结构：每一个数据分层都有它的作用域，这样我们在使用表的时候能更方便地定位和理解。

2. 数据血缘追踪：简单来讲可以这样理解，我们最终给业务呈现的是一张能直接使用的张业务表，但是它的来源有很多，如果有一张来源表出问题了，我们希望能够快速准确地定位到问题，并清楚它的危害范围。

3. 减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算。

把复杂问题简单化：将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。

4. 屏蔽原始数据的异常：屏蔽业务的影响，不必改一次业务就需要重新接入数据。

上述数据分层模型的实现实际上也是统一数仓的建模过程，并且在生成事实表的过程中将指标规范化处理，为了将不同主题域的数据打通，引入了标签数据层。数仓层的整个加工流程如下:

看图示应该能自明，不再展开，只解释下几个相关概念：

• 业务板块：最大粒度的业务属性划分，如金融、地产、医疗等

• 数据域：业务过程的集合，如采购、供应链等

• 业务过程：不可拆分的业务活动，如下单、转账、注册等

• 修饰词：对指标进行限定的业务场景词语，如用PC端，无线端等来界定新用户来源

• 原子指标：针对业务事件行为的度量，是不可拆分的指标，如支付金额等

• 派生指标：对原子指标业务统计范围的圈定，如最近一天（时间修饰词）PC端（修饰词）注册用户数量（原子指标）

标签数据层是面向对象建模，把一个对象各种标识打通归一，把跨业务板块、数据域的对象数据在同一个粒度基础上组织起来打到对象上。

标签数据层建设，一方面让数据变得可阅读、易理解，方便业务使用；另一方面通过标签类目体系将标签组织排布，以一种适用性更好的组织方式来匹配未来变化的业务场景需求。

标签数据层的处理流程如下图：

这里也只列出主要概念：

• 对象：研究目标的抽象，可以具体或者虚拟

• 对象标识：如身份证、手机号等

• 标签：可阅读，易理解，有业务价值的数据

• 标签类目：标签分类组织形式，一般为多级

• 属性标签： 实体区别特征，如年龄，性别等

• 统计标签：维度和度量的组合，如日均登录次数等
  

• 算法标签：复杂逻辑分析推理得出的特征，如品牌偏好，购买力等

• 标签融合表：组合对象的以上标签形成的表，是标签数据层的落地物

对于底层的数据融合，常见的技术方案可以参考下图：

从图上可以看出，数据一般有离线数据和实时数据，前者一般通过datax，sqoop等工具进行全量或者增量同步，而对于实时数据一般需要结合流处理架构如flume，kafka和spark，有些场景则需要flink。这些架构虽然简单易行，但对于大数据场景也会暴露出很多问题，比如数据同步不及时、数据不一致以及存在大量的小文件的合并等问题，于是基于数据湖的方案不失为一种好的趋势，但是技术成熟度需要接受实战的考验。

关于数据中台建设效果评估可以按照前文中的方法论部分提到的3条目标准则：可见、可用和可运营来评估数据中台建设内容的完善度，详细评估细则参见下表：

另外一种评估方法是数据中台建设的成熟度模型，从系统建设、中台驱动力和过程管理三大维度来评估中台建设的目标。

另外，还可以根据以下目标来界定数据中台建设所处的阶段。

通过多个角度来评估数据中台，有助于全面认识数据中台所处的现状和不足，进而有明确的改进方向。

小结

本文围绕SAAS企业如何建设大数据中台，介绍了一些思考的方向和着眼点，尤其关注数据资产管理，但是资产管理本身是个宏大的话题，有关数据治理和服务体系的内容，限于篇幅，不便展开，但并不意味着不重要。数据中台建设本身内容不多，归纳起来就如上图中屈指可数的几大模块，犹如人的脑袋，每个人的脑袋都由五官这几个组件组成，但是做出来的效果千差万别。数据中台的实施本身是一个一把手工程，具体实现带有一定的艺术性，最终达到的效果要形散而神不散，要坚持资产管理为中心，始终把握推动和赋能业务这条主线不动摇。