《终于有人把数据中台讲明白了》一文讲到数据中台的定义和价值，本文将介绍数据中台到底包括什么内容。企业建设数据中台的过程中哪些能力是必选项，哪些是可选的，将在本文一一揭晓。
一、数据中台功能架构
数据中台建设是一个宏大的工程，涉及整体规划、组织搭建、中台落地与运营等方方面面的工作，本节重点从物理形态上讲述企业的数据中台应该如何搭建。一般来讲，企业的数据中台在物理形态上分为三个大层：工具平台层、数据资产层和数据应用层(见图4-2)。
1. 工具平台层
工具平台层是数据中台的载体，包含大数据处理的基础能力技术，如集数据采集、数据存储、数据计算、数据安全等于一体的大数据平台;还包含建设数据中台的一系列工具，如离线或实时数据研发工具、数据联通工具、标签计算工具、算法平台工具、数据服务工具及自助分析工具。
以上工具集基本覆盖了数据中台的数据加工过程。
(1) 数据开发平台
大数据的4V特征[1]决定了数据处理是一个复杂的工程。建设数据中台需要搭建建设数据中台的基建工具，要满足各种结构化、非结构化数据的采集、存储与处理，要根据场景处理离线和实时数据的计算与存储，要将一个个数据处理任务串联起来以保障数据的运转能赋能到业务端。
[1] 大数据的4V 指Volume(数据量大)、Variety(类型繁多)、Velocity(速度快，效率高)、Value(价值密度低)。
因此首先搭建一个大数据能力平台是非常有必要的。当然，可根据企业实际情况来决定是外采还是自建平台。
(2) 数据资产管理
数据中台建设的成功与否，与数据资产是否管理有序有直接关系。前文提到，数据中台是需要持续运营的。随着时间的推移，数据不断涌入数据中台，如果没有一套井然有序的数据资产平台来进行管理，后果将不堪设想。
数据资产管理工具既能帮助企业合理评估、规范和治理信息资产，又可以发挥数据资产价值并促进数据资产持续增值。对于数据资产管理，我们不推荐事后管理，而要与数据研发的过程联动。也就是说，当数据经过数据开发平台加工的链路时，数据资产管理平台就已经无声无息地介入了。
数据资产管理的首要任务是管理好进入数据中台的元数据，这里的元数据包括数据源、建设的各种模型、通过模型拆解出来的指标与标签以及调度作业。有序管理这些数据资产的元数据是前提条件，只有做好了这一步，才能继续对数据流向的追溯，才能对指标、标签体系的生命周期进行管理，确定指标的使用频率，决定是否下线。
(3) 标签工厂
标签工厂又称标签平台，是数据中台体系内的明星工具类产品。标签建设是数据中台走向数据业务化的关键步骤。因此，一个强大的标签工厂是数据中台价值体现的有力保障。
严格来说，标签工厂也属于数据开发平台的一部分，为什么我们要把它单独剥离出来讲呢?这是因为标签的使用场景丰富，标签与业务结合得非常紧密;同时，标签数据的存储与分析型数据的存储有一定的差异。
标签工厂致力于屏蔽底层复杂的大数据框架，面向普通开发人员、数据分析师、运营人员提供友好的界面交互配置，完成标签的全生命周期管理;同时，对上层业务系统提供自身API能力，与各业务系统形成数据闭环。
标签工厂按功能一般分为两部分：底层的标签计算引擎与上层的标签配置与管理门户。标签计算引擎一般会采用MapReduce、Spark、Flink等大数据计算框架，而计算后的标签存储可采用Elasticsearch或者HBase，这样存储的好处是便于快速检索。
而标签配置与管理门户则支持通过配置标签规则提交到标签计算引擎，就能定时算出所需要的标签。标签配置和管理门户还提供标准的标签服务申请与调用。通过标签工厂，数据中台团队可减少大量的数据开发工作。
(4) ID-Mapping
ID-Mapping又称ID打通工具，是数据中台建设的可选项。可选不代表不重要，在一些多渠道、多触点的新零售企业，离开了这个工具，数据质量将大打折扣。
举个例子。消费者在逛街的时候看到一款剃须刀，扫了店内的二维码，正准备下单购买时被朋友的电话中断了。回到家，打开抖音又看到这个剃须刀的广告，便立即打开链接下单购买了。
这样的场景在生活中比比皆是，其中隐藏了很多的消费者信息，如果我们不去打通ID，那么可能至少会将同一个用户当作4个用户来处理。实际上可以将扫描二维码记录留下的OpenID、抖音注册留下的微信号、下单提供的订单手机号码及注册账号等多条信息结合起来，判别是不是同一个人。这样给这个消费者打标签或者推荐商品就会更加精准。
ID-Mapping功能的建设一般会利用强大的图计算功能，通过两两之间的关系实现互通，自动高效地将关联的身份映射为同一身份即唯一ID的数据工具。它能大幅度降低处理成本，提高效率，挖掘更多用户信息，形成更完整的画像，大大利于数字营销的推进。
另外，ID-Mapping工具也可用于企业主数据治理。
(5) 机器学习平台
在整个机器学习的工作流中，模型训练的代码开发只是其中一部分。除此之外，数据准备、数据清洗、数据标注、特征提取、超参数的选择与优化、训练任务的监控、模型的发布与集成、日志的回收等，都是流程中不可或缺的部分。
机器学习平台支持训练数据的高质量采集与高效标注，内置预训练模型，封装机器学习算法，通过可视化拖曳实现模型训练，支持从数据处理、模型训练、模型部署为在线预测服务，通过RESTful API的形式与业务应用集成，实现预测，打通机器学习全链路，帮助企业更好地完成传统机器学习和深度学习的落地。
(6) 统一数据服务
统一数据服务旨在为企业搭建统一的数据服务门户，帮助企业提升数据资产的价值，同时保证数据的可靠性、安全性和有效性。
统一数据服务支持通过界面配置的方式构建API和数据服务接口，以满足不同数据的使用场景，同时降低数据的开发门槛，帮助企业实现数据应用价值最大化。
统一数据服务作为唯一的数据服务出口，实现了数据的统一市场化管理，在有效降低数据开放门槛的同时，保障了数据开放的安全。
2. 数据资产层
数据资产层是数据中台的核心层，它依托于工具平台层，那么这一层又有什么内容呢?答案是因企业的业务与行业而异，但总体来讲，可以划分为主题域模型区、标签模型区和算法模型区。
(1) 主题域模型
主题域模型是指面向业务分析，将业务过程或维度进行抽象的集合。业务过程可以概括为一个个不可拆分的行为事件，如订单、合同、营销等。
为了保障整个体系的生命力，主题域即数据域需要抽象提炼，并且长期维护和更新，但是不轻易变动。在划分数据域时，既要涵盖当前所有业务的需求，又要保证新业务能够无影响地被包含进已有的数据域中或者很容易扩展新的数据域。
数据域划分需要先对业务系统进行充分调研。将业务过程划分到哪个数据域没有绝对的对错，但是会影响报表开发人员定位数据的效率，所以还需要从开发人员定位效率的角度来进行综合划分。
(2) 标签模型
标签模型的设计与主题域模型方法大同小异，同样需要结合业务过程进行设计，需要充分理解业务过程。标签一般会涉及企业经营过程中的实体对象，如会员、商品、门店、经销商等。这些主体一般来说都穿插在各个业务流程中，比如会员一般都穿插在关注、注册、浏览、下单、评价、服务等环节。
那么在设计标签的时候就需要充分理解这些业务流程，在流程中发现标签的应用点，结合这些应用点来搭建企业的标签体系。
标签模型按计算模式一般分为客观标签和主观标签，客观标签是可以量化的，而主观标签是不可量化的。根据实现方式又可以将标签分为事实标签、模型标签、算法标签等，根据业务场景还可将标签分为基础信息标签、偏好标签、价值标签等。
设计标签模型时非常关键的要素是标签模型一定要具有可扩展性。毕竟标签这种数据资产是需要持续运营的，也是有生命周期的，在运营的过程中随时可能增加新的标签。
(3) 算法模型
算法模型更加贴近业务场景。在设计算法模型的时候要反复推演算法模型使用的场景，包括模型的冷启动等问题。整个模型搭建过程包含定场景、数据源准备、特征工程、模型设计、模型训练、正式上线、参数调整7个环节。
以新零售企业为例，常用的机器学习算法有决策树、神经网络、关联规则、聚类、贝叶斯、支持向量机等。这些算法已经非常成熟，可以用来实现商品个性化推荐、销量预测、流失预测、商品组货优化等新零售场景的算法模型。
3. 数据应用层
数据应用层严格来说不属于数据中台的范畴，但数据中台的使命就是为业务赋能，几乎所有企业在建设数据中台的同时都已规划好数据应用。数据应用可按数据使用场景来划分为以下多个使用领域。
(1) 分析与决策应用
分析与决策应用主要面向企业的领导、运营人员等角色，基于企业的业务背景和数据分析诉求，针对客户拉新、老客运营、销售能力评估等分析场景，通过主题域模型、标签模型和算法模型，为企业提供可视化分析专题。
用户在分析与决策应用中快速获取企业现状和问题，同时可对数据进行钻取、联动分析等，深度分析企业问题及其原因，从而辅助企业进行管理和决策，实现精准管理和智能决策。
在分析专题设计的过程中，首先需要根据不同的业务分析场景，采用不同的分析方法进行数据分析的前期规划，搭建清晰的数据分析框架，如在用户行为分析、营销活动等场景下，会采用5W2H分析法和4P营销理论;在复购客户下降、客单价下降等问题诊断分析场景，需要考虑问题与哪些因素有关，则采用逻辑树分析法。
在数据分析框架构建完成后，结合用户的分析目的，采用不同的分析思路和呈现方式，包括趋势分析、多维分解、漏斗分析、A/B测试、对比分析和交叉分析等。
(2) 标签应用
标签旨在挖掘实体对象(如客户、商品等)的特征，将数据转化成真正对业务有价值的产物并对外提供标签数据服务，多应用于客户圈选、精准营销和个性化推荐等场景，从而实现资产变现，不断扩大资产价值。
标签体系的设计立足于标签使用场景，不同使用场景对标签需求是不同的，譬如在客户个性化推荐场景下，需要客户性别、近期关注商品类型、消费能力和消费习惯等标签。
因此，在标签体系设计前，需要先基于业务需求分析标签的使用场景，再详细设计标签体系和规则。在标签的使用过程中，可利用A/B测试等数据分析方式，持续分析标签的使用效果，并优化标签体系和规则。
(3) 智能应用
智能应用是数智化的一个典型外在表现。比如在营销领域，不仅可实现千人千面的用户个性化推荐，如猜你喜欢、加购推荐等，还可借助智能营销工具进行高精准度的用户触达，推动首购转化、二购促进、流失挽留等。
在供应链领域，可通过数据中台整合用户数据、销售数据、采购数据等优化库存，实现自动配补货、自动定价。除了传统统计分析、机器学习之外，还可以融入深度学习，实现以图搜图并与商城打通，实现拍立购;实现人脸识别，用于地产行业的案场风控;融入自然语言处理，实现智能客服问答机器人等。
总之，以上各层是数据中台的核心内容。需要指出的是，在工具平台层，企业并不需要完全自主建设，可以考虑采用拿来主义，从中台建设厂商采购成熟的产品，而数据资产层与数据应用层是企业数据中台组织需要密切关注的。
二、数据中台技术架构
随着大数据与人工智能技术的不断迭代以及商业大数据工具产品的推出，数据中台的架构设计大可不必从零开始，可以采购一站式的研发平台产品，或者基于一些开源产品进行组装。企业可根据自身情况进行权衡考虑，但无论采用哪种方案，数据中台的架构设计以满足当前数据处理的全场景为基准。
以开源技术为例，数据中台的技术架构如图4-3所示，总体来看一般包含以下几种功能：数据采集、数据计算、数据存储和数据服务;在研发、运维和公共服务方面包括离线开发、实时开发、数据资产、任务调度、数据安全、集群管理。
▲图4-3 数据中台技术架构
1. 数据采集层
按数据的实时性，数据采集分为离线采集和实时采集。离线采集使用DataX和Sqoop，实时采集使用Kafka Connect、Flume、Kafka。
在离线数据采集中，建议使用DataX和Sqoop相结合。DataX适合用在数据量较小且采用非关系型数据库的场景，部署方式很简单。Sqoop适合用在数据量较大且采用关系型数据库的场景。
在实时数据采集中，对于数据库的变更数据，如MySQL的binlog、Oracle的OGG，使用Kafka Connect进行数据的实时采集。对于其他数据，先将数据实时写成文件，然后采用Flume对文件内容进行实时采集。将实时采集后的数据推送到Kafka，由Flink进行数据处理。
2. 数据计算层
数据计算采用YARN作为各种计算框架部署的执行调度平台，计算框架有MapReduce、Spark及Spark SQL、Flink、Spark MLlib等。
MapReduce是最早开源的大数据计算框架，虽然现在性能相对较差，但它的资源占用比较小，尤其是内存方面。因此在部分数据量过大，而其他计算框架由于硬件资源的限制(主要是内存限制)而无法执行的场景，可以将MapReduce作为备选框架。
Spark及Spark SQL是在批处理方面拥有出色性能的成熟技术方案，适合大部分的离线处理场景。特别是在离线数据建模方面，建议使用Spark SQL进行数据处理，既能保证易用性，又能保证处理的性能。Flink是实时数据处理方面的首选，在处理的时效性、性能和易用性方面都有很大优势。
而机器学习一般采用Spark家族的Spark MLlib为技术底座。Spark MLlib内置了大量的常规算法包，如随机森林、逻辑回归、决策树等，可以满足大部分数据智能应用场景。
同时，数据中台不断进化，也逐渐融入AI能力。如人脸识别、以图搜图、智能客服等能力的实现就需要AI平台。目前较为成熟的AI平台有TensorFlow及PyTorch。为实现物体的检测和识别，可使用SSD、YOLO和ResNet等深度学习模型，而在人脸检测和识别中则主要使用MTCNN、RetinaNet和ResNet，人脸检索可使用Facebook开源的针对人脸检索的Faiss框架。
3. 数据存储层
数据存储层所有的存储引擎都基于Hadoop的HDFS分布式存储，从而达到数据多份冗余和充分利用物理层多磁盘的I/O性能。在HDFS上分别搭建Hive、HBase作为存储数据库，在这两个数据库的基础上再搭建Impala、Phoenix、Presto引擎。
- Hive为大数据广泛使用的离线数据存储平台，用于存储数据中台的全量数据，在建模阶段可以使用Hive SQL、Spark SQL进行数据处理和建模。
- HBase为主流的大数据NoSQL，适合数据的快速实时读写。在实时数据处理时，可将数据实时保存到HBase中，并且可以从HBase中实时读取数据，从而满足数据的时效性。
- Impala可以对Hive、HBase等大数据数据库进行准实时的数据分析，能满足对分析结果速度有一定要求的场景。
- Phoenix是构建在HBase上的一个SQL层，能让我们用标准的JDBC API而不是HBase客户端API来创建表、插入数据和对HBase数据进行查询。
- Presto是一个开源的分布式SQL查询引擎，适用于交互式分析查询。Presto支持Hive、HBase、MySQL等多种关系型和大数据数据库的查询，并且支持join表。对于对接自助分析和统一数据服务的场景，可以通过Presto来统一访问具体存储的数据库，从而达到语法统一和数据源统一。
4. 数据服务层
数据服务层采用的技术与业务应用类似，主要基于开源Spring Cloud、Spring Boot等构建，使用统一的服务网关。