第四章、数据中台建设
数字中台通过业务中台提供的共享业务能力为前台提供了强有力的炮火支撑，但想要了解战场情况、指挥炮火打响哪里，就需要数据中台，通过数据分析，产生智能，形成决策。业务与数据不断交融，才能更好地推动企业进行数智化转型。数据中台与业务中台共同承载着业务数据化与数据业务化的职能。与业务中台建设一样，数据中台建设也是一个非常复杂的系统工程。从广义上来讲，数据中台建设包含组织形态上的重工组织搭建与物理形态上的中台系统建设。
首先，站在全局视角谈谈如何定义企业的数据中台，数据中台能为企业带来哪些价值；然后，介绍建设数据中台通常有哪些路径，规划企业的数据中台在策略上需要注意哪些事项；最后，讲述数据中台的规划，建设和持续运营整个生命周期是如何开展的。
4.1 什么是数据中台
4.1.1 数据中台定义
==数据中台是一种将企业沉睡的数据变成数据资产，持续使用数据、产生智能、为业务服务，从而实现数据价值变现的系统和机制。==通过数据中台提供的方法和运行机制，形成汇聚整合、提纯加工、建模处理、算法学习，并以共享服务的方式将数据提供给业务使用，从而与业务联动。再者，结合业务中台的数据生产能力，最终构成数据生产-消费-再生的闭环。位列更好的理解数据中台，我们将其与数据仓库、数据湖、BI、大数据等相关概念进行对比。
数据仓库是一个面向主体的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策。因此，其重点在于数据的集合。数据仓库可使用维度建模方法论从业务过程中抽象出通用维度与度量，组成数据模型，为决策分析提供通用的数据分析能力。
数据中台与数据仓库相比，只是有四大优势。
第一，数据中台强调数据业务化，让数据用起来，满足企业数据分析和应用的需求。
第二，数据中台梳理的流程比数据仓库建设更加复杂和全面。数据中台增加了以企业的全局视角来梳理数据域的环节，这是数据中台建设中很重要的一环。数据域的梳理正好体现了中台化的能力。举个例子，新零售场景下，企业的交易场景有很多，包括自建商城渠道、第三方电商渠道、外面订单渠道、线下门店渠道等。建设数据中台时，就需要规划处一个交易域，此交易域要抽象出各种渠道的业务流程，并能覆盖线上、线下运营部门在运营时需要考核的维度和度量。因此数据中台建设过程要更多从企业全局出发，从人、或、场多维度打通数据，真正做到无论消费者从那个渠道进来，都能洞察其与本企业的接触轨迹。而数据仓库的建设则相对单一，专注于维度模型如何设计，如何拆解指标和维度，却很少关注基于人、货、场这些主体进行实体拉通，然后作出全局的画像数据供前端业务调用。
第三，数据中台建设的范畴远远大于数据仓库的建设，除了完成数据仓库的建模，还需要制定完善的数据治理方案，甚至在建设的过程中需要成立专门的数据治理委员会来促成复杂的数据治理工作。最重要的一点是，在数据中台的规划阶段就需要去主动迎合业务，需要全面梳理哪些业务场景需要利用数据的赋能才能形成业务闭环，因此，在建设数据中台的同时就必须着眼于业务场景的赋能。
第四，对于企业来讲，建设数据中台并不只是搭建一个能力平台。正如我们在《中台战略》一书中提到的，建设中台需要中台文化及相匹配的中台组织。因此，从宏观上来讲，数据中台承担着企业重新搭建数据组织的职能，倒逼企业为了运营好数据中台而建设一套能与之匹配的数据中台组织。数据仓库则纯粹注重于系统解决方案，并不涉及组织形态。
因此，简单来说，数据仓库重在建数据，而数据中台则将建、治、管、服放到同样的高度，数据仓库只是数据中台的一个子集。那我们为什么会从数据仓库发展到数据中台呢？因为传统的数据仓库已不能完全满足企业数据分析的需求。企业已从原来的统计分析转变为预测分析并提供标签、推荐算法，从被动分析转变为主动分析，从非实时分析转变为实时分析，并且从结构化数据转变为结构化、半结构化和非结构化的多元化数据。
与数据中台相关的概念还有数据湖（Data Lake）。数据湖是一种数据存储的概念，作为一个集中的存储库，他可以以自然格式存储任意规模的数据，包括来自关系数据库行和列的结构化数据，xml，json，日志等版结构化数据，电子邮件文档等非结构化数据，以及图像、音视频等二进制数据，从而实现数据的集中式管理。目前Hadoop是最常见的实现数据湖概念的技术。比如HBase可让数据湖保存海量数据，Spark可以使得数据湖批量分析叔叔，而Flink等可让数据湖实时接入和处理IoT数据等。
BI（商业智能）是分析数据并获取洞察，进而帮助企业作出决策的一些列方法、技术和软件。变比数据仓库，BI还包含数据挖掘、数据可视化等工具，并可支持用户在一定范围内任意组合维度与指标，从而上升到支持决策的层面，而不只是作为数据仓储。
数据中台页不等于大数据。数据中台是基于大数据、人工智能等技术构建的数据采、存、通、管、用的平台。数据中台需要以Hadoop、Spark等为代表的大数据处理技术做支撑，但绝不能将数据中台与大数据划等号。数据中台不只有大数据处理技术，还包括智能算法、与业务联动的特性、数据资产、数据工具等。
可以说数据中台是上述概念和技术的集大成者。
首先，大数据丰富的数据计算和存储技术为数据中台提供了强大的数据处理能力。
其次，数据中台作为企业数据的集结地，其底层也当然承载着数据湖的职能。
再次，数据仓库对数据的分域建模是数据中台的重要部分，它承载着将企业数据治理得井井有条的职能。
最后，基于强大的数据能力，结合业务场景提供实时、智能的服务和应用时数据中台的核心价值体现。
4.1.2 数据中台价值
数据中台不等于大数据平台，数据中台的核心工作也并不是将企业的数据全部收集起来做汇总就够了。数据中台的使命是利用大数据技术、通过全局规划来治理好企业的数据资产，让数据使用者能随时随地地获取到可靠的数据。因此，数据中台一旦建成并得以持续运营，其价值将随着时间的推移将呈现指数级增长。数据中台的价值众多，下图详述其中三大价值；
-
帮助企业建立数据标准
- 在有数据中台之前，企业基本不会有全局的数据标准，即使有相关的数据标准，由于没有数据中台这个实体形态，数据标准也无从执行。数据中台的建设天然会帮助企业建设数据标准，包括数据建设规范和数据消费规范。
- 数据建设规范有诸如数据接入规范、数据建模规范、数据存储规范，数据安全规范等
- 数据消费规范包含数据权限规范、数据调用规范以及数据销毁规范等。
- 这些标准都是建设数据中台时必须建立起来并依托数据中台去执行和落地的。
-
促进中台组织形成
- 再宏伟的企业战略规划，都离不开一套科学合理的组织去落地执行。数据中台建设将是企业宏观战略规划的一个重要组成部分，那么在践行数据中台建设的过程中，摆在企业第一位的问题就是如何搭建起一套能稳定护航数据中台建设及运营的数据中台班子。
- 数据中台这种体系化工程将横向拉通企业数据相关方，包括中台建设团队、中台运维团队、数据产品经理团队、数据资产管理团队、数据运营团队等组成标准的企业数据委员会，从而形成企业真正的中台组织。
- 需要说明的是，中台组织还可以是一个横跨各个业务部门的弱矩阵组织，也可以是一个完整的实体组织。这需要因地制宜，因企业不同而已。
-
全面赋能业务，促使降本增效
- 数据中台的终极价值是降本增效，无论是建设数据标准还是形成中华个年头组织，其核心目标都是帮助企业达成战略规划。
- 通过数据中台，可以更加合理的布局团队；
- 数据从加工生产到使用额整个时间周期将大大缩短
- 以中台之力拉通整合企业营销、交易、服务、库存、物流等一方数据，结合二方及三方数据，以全局视角，形成强大的数据资产，滋养各业务板块。
- 同时有目的性的针对场景，设计出赋能场景的数据应用，帮助其从研、产、销等多方面缩短产品研发周期，生成未来一段视角畅销的产品，精准找到愿意购买公司产品的群体，以至于增强用户对企业产品及服务的友好体验，提高用户对企业品牌的忠诚度，降低企业运营过程中的损耗，压缩供应链端的周期等。
4.2 数据中台的架构设计与组成
4.2.1 数据中台功能架构
数据中共建设是一个宏达的工程，涉及整体规划、组织搭建、中台落地与运营等方方面面的工作。
企业的数据中台在物理形态上分为三个层次：工具平台层、数据资产层、数据应用层。
- 工具平台层
- 工具平台层是数据中台的载体，包含大数据处理的基础能力技术，如集数据采集、数据存储、数据计算、数据安全等于一体的大数据平台；还包含建设数据综合体的一系列工具，如离线或实时数据研发工具、数据联通工具、标签计算工具、算法平台工具、数据服务工具集自助分析工具。
- 数据开发平台。
- 大数据的4V特征（Volume-数据量大，Variety-类型繁多，Velocity-速度快且效率高，Value-价值密度低）决定了数据处理是一个复杂的工程，要满足各种结构化、非结构化数据的采集、存储与处理，要根据场景处理离线和实时数据的计算与存储，要将一个个数据处理任务串联起来以保障数据的运转能赋能到业务端。
- 因此首先搭建一个大数据能力平台是非常有必要的。当然，可根据企业实际情况来决定是外采还是自建平台。
- 数据资产管理。
- 数据中台建设的成功与否，与数据资产是否管理有序有直接关系。前文提到，数据中台是需要持续运营的。随着时间的推移，数据不断涌入数据中台，如果没有一套井然有序的数据资产平台来进行管理，后果将不堪设想。数据资产管理工具既能帮助企业合理评估、规范和治理信息资产，又可以发挥数据资产价值并促进数据资产持续增值。对于数据资产管理，我们不推荐事后管理，而要与数据研发的过程联动。
- 也就是说，当数据经过数据开发平台加工链路时，数据资产管理平台就已经无声无息地介入了。
- 数据资产管理的首要任务是管理好进入数据中台的元数据，这里的元数据包括数据源、建设的各种模型、通过模型拆解出来的指标与标签以及调度作业。有序管理这些数据资产的元数据是前提条件，只有做好了这一步，此案继续对数据流向的追溯，才能对指标、标签体系的生命周期进行管理，确定指标的使用频率，决定是否下线。
- 标签工厂。
- 标签工厂又称标签平台，是数据中台体系内的明星工具类产品。
- 标签建设是数据中台走向数据业务化的关键步骤。因此，一个强大的标签工厂石书记中台价值体现的有力保障。严格来说，标签工厂也数据数据开发平台的一部分，为什么我们要把他单独的剥离出来讲呢？这是因为标签的使用场景丰富，标签与业务结合的非常紧密；同时，标签数据的存储与分析型数据的存储有一定的差异。
- 标签工厂致力于屏蔽底层复杂的大数据框架，面向普通开发人员、数据分析师、运营人员提供友好的界面交互配置，完成标签的全生命周期管理；同时，对上层业务系统提供自身API能力，与各业务系统形成数据闭环。
- 标签工厂按功能一般分两部分：底层的标签计算引擎与上层的标签配置与管理门户。标签计算引擎一般会采用MapReduce、Spark、Flink等大数据计算框架，而计算后的标签存储可采用Elasticsearch或者HBase，这样存储的好处是便于快速检索。而标签配置与管理门户则支持通过配置标签规则提交到标签计算引擎，就能定时算出所需要的标签。标签配置和管理门户还提供标准的标签服务申请和调用。通过标签工厂，数据中台团队可以减少大量的数据开发工作。
- ID-Mapping
- ID-Mapping又称ID打通工具，是数据中台建设的可选项。可选不代表不重要，在一些渠道、多触点的新零售企业，离开了这个工具，数据质量将大打折扣。举个例子。消费者在逛街的时候看到一款剃须刀，扫了店内的二维码，正准备下单购买时被朋友的电话中断了。回到家，打开抖音又看到这个剃须刀的广告，便立即打开链接下单购买了。这样的场景在生活中比比皆是，其中隐藏了很多的消费者信息，如果我们不去打通ID，那么可能至少会将同一个用户当做4个用户来处理。实际上可以将扫描二维码记录留下的OpenID，抖音注册留下的微信号、下单提供的订单手机号号码及注册账号等多条信息结合起来，判别是不是同一个人。这样给这个消费者打标签或者推荐商品就会更加精准。
- ID-Mapping功能的建设一般会利用强大的图计算功能，通过两两之间的关系实现互通，自动高效地将关联的身份映射为同一身份即唯一ID的数据工具。它能大幅度降低处理成本，提高效率，挖掘更多用户信息，形成更完整的画像，大大利于数字营销的推进。另外，ID-Mapping工具也可用于企业主数据治理。
- 机器学习平台
- 在整个机器学习的工作流中，模型训练的代码开发只是其中一部分。除此之外，数据准备、数据清洗、数据标注、特征提取、超参数的选择与优化、训练任务的监控、模型的发布与集成、日志的回收等，都是流程中不可或缺的部分。机器学习平台支持训练数据的高质量采集与高效标注，内置预训练模型，封装机器学习算法，通过可视化拖拽实现模型训练，支持从数据处理、模型训练、模型部署为在线预测服务，通过RESTfulAPI的形式与业务应该用集成，实现预测、打通机器学习全链路，帮助企业更好地完成传统机器学习和深度虚心的落地。
- 统一数据服务
- 统一数据服务，旨在为企业搭建统一的数据服务门户，帮助企业提升数据资产价值，同时保证数据的可靠性、安全性和有效性。
- 统一数据服务支持通过界面配置的方式构建API和数据服务接口，以满足不同数据的使用场景，同时降低数据的开发门槛，帮助企业实现数据应用价值最大化。
- 统一数据服务作为唯一的数据服务出口，实现了数据的统一市场化管理，在有效降低数据开放门槛的同时，保重angle数据开放安全。
- 数据资产层
数据资产层是数据中台的核心层，他依托有工具平台层，那么这一层又有什么内容呢？答案是因企业的业务与行业而已，但总体来讲，可以划分为主题域模型区、标签模型区和算法模型区。- 主题域模型
- 主题域模型是指面向业务分析，将业务过程或维度进行抽象的集合。业务过程可以概括为一个个不可拆分的行为事件，如订单、合同、营销等。为了保障整个体系的生命力，主题域即数据域需要抽象提炼，并且长期维护和更新，但是不轻易变变动。
- 在划分数据域时，即要涵盖当前所有业务需求，又要保证新业务能够无影响的被包含进已有的数据域中或者很容易扩展新的数据域
- 数据域划分需要先对业务系统进行充分调研。
- 将业务过程划分到哪个数据域没有绝对的对错，但是会影响报表开发人员定位数据的效率，所以还需要从开发人员定位效率的角度来进行综合划分。
- 标签模型
- 标签模型的设计与主题域模型方法大同小异，同样需要结合业务过程进行设计，需要充分了解业务过程。
- 标签一般会涉及企业经营过程中的实体对象，如会员、商品、门店、经销商当。这些主体一般来说都穿插在各个业务流程中，比如会员一般都穿插在关注、注册、浏览、下单、评价、服务等环节。
- 那么在设计标签的时候就需要充分理解这些业务流程，在流程中发现标签的应用点，结合这些应用点来搭建企业的标签体系。
- 标签模型按计算模式一般分为客观标签和主观标签，客户标签是可量化的，而主观标签是不可量化的。
- 根据实现方式又可以分为事实标签、模型标签、算法标签等，根据业务场景还可将标签分为基础信息标签、偏好标签、价值标签等。
- 设计标签模型时非常关键的也要素是标签模型一定要具有可扩展性。毕竟标签这种数据资产是需要持续运营的，也是有生命周期的，在运营的过程中随时可能增加新的标签。
- 算法模型
- 算法模型更加贴近业务场景。在设计算法模型的时候要反复推演算法模型使用的场景，包括模型的冷启动等问题。
- 整个模型搭建工程包含定场景、数据源准备、特征工程、模型设计、模型训练、正式上线、参数调整7个环节。
- 以新零售企业为例，常用的机器学习算法有决策树、神经网络、关联规则、聚类、贝叶斯、支持向量机等。这些算法已经非常成熟，可以用来实现商品个性化推荐、销量预测、流式预测、商品组货优化等新零售场景的算法模型。
- 主题域模型
- 数据应用层
数据应用层严格来说不属于数据中台的范畴，但数据中台的使用就是为业务赋能，几乎所有企业在建设数据中台的同时都已规划好数据应用。数据应用可按数据使用场景来划分为如下多个使用领域。- 分析与决策应用
- 分析与决策应用主要面向企业的领导、运营人员等角色，基于企业的业务背景和数据分析诉求，针对客户拉新、老客运营、销售能力评估等分析场景，通过主题域模型、标签模型、算法模型，为企业提供可视化分析专题。用户在分析与决策应用中快速获取企业现状和问题，同时可对数据进行数据钻取、联动分析等，深度分析企业问题及其原因，从而辅助企业进行管理和决策，实现精准管理和智慧决策。
- 在分析专题设计的过程中，首先需要根据不同的业务分析场景，采用不同的分析方法进行数据分析的前提规划，搭建清晰的数据分析框架，如在用户行为分析、营销活动等场景下，会采用5W2H分析法和4P营销理论；
- 在复购客户下降、客单价下降等问题诊断分析场景，需要考虑问题与哪些因素有关，则采用逻辑树分析法。在数据分析框架构建完成后，结合用户的分析目的，采用不同的分析思路和呈现方式，包括趋势分析、多维分解、漏斗分析、A/B测试、对比分析和交叉分析等。
- 标签应用
- 标签旨在挖掘实体对象（如客户、商品等）的特征，将数据转化成真正对业务有价值的产物并对外提供标签数据服务，多应用于客户圈选、精准营销和个性化推荐场景，从而实现资产变现，不断扩大资产价值。
- 标签体系的设计立足于标签使用场景，不同使用场景对标签需求是不同的，譬如在客户个性化推荐场景下，需要客户性别、近期关注商品类型、消费能力和消费习惯等标签。
- 因此，在标签体系设计前，需要先基于业务需求分析标签的使用场景，再详细设计标签体系和规则。
- 在标签的使用过程中，可利用A/B测试等数据分析方式，持续分析标签的使用效果，并优化标签体系和规则。
- 智能应用
- 智能应用时数智化的一个典型外在表现。比如在营销领域，不仅可实现千人千面的用户个性化推荐，如猜你喜欢、加购推荐等，还可以借助智能营销工具进行高精准度的用户触达，推动首购转化、二购促进、流式挽留等。
- 在供应链领域，可通过数据中台整合用户数据、销售数据、采购数据等优化库存，实现自动配补货、自动定价。除了传统统计分析、机器学习之外，还可以融入深度学习，实现以图搜图并与商城打通，实现拍立购；
- 实现人脸识别，用于地产行业的案场风控；融入自然语言处理，实现智能客服问答机器人等。
- 总之，以上各层数数据中台的核心内容。需要指出的是，在工具平台层，企业并不需要完全自主建设，可以考虑采用拿来主义，从中台建设厂商采购成熟的产品，而数据资产层与数据应用层是企业数据中台组织修养密切关注的。
- 分析与决策应用
4.2.2 数据中台技术架构
随着大数据与人工智能技术的不断迭代以及商业大数据工具产品的推出，数据中台的架构设计大可不必从零开始，可以采购一站式的研发平台产品，或者基于一些开源产品进行组装。企业可根据自身情况进行权衡考虑，但无论采用那种方案，数据中台的架构设计以满足当前数据处理的全场景为基准。
以开源技术为例，数据中台的技术架构如图所示，总体来看一般包含以下几种功能：数据采集、数据计算、数据存储和数据服务；在研发、运维和公共服务方面包括离线开发、实时开发、数据资产、任务调度、数据安全、集群管理。
-
数据采集层
按数据的实时性，数据采集分为离线采集和实时采集。离线采集使用DataX和Sqoop，实时采集使用Kafka Connect、Flume、Kafka。
DataX：DataX是阿里云DataWorks数据集成的开源版本。
Sqoop：Sqoop(发音：skup)是一款开源的工具，主要用于在Hadoop(Hive)与传统的数据库(mysql、postgresql…)间进行数据的传递，可以将一个关系型数据库*（例如 ： MySQL ,Oracle ,Postgres等）*中的数据导进到Hadoop的HDFS中，也可以将HDFS的数据导进到关系型数据库中。
在离线数据采集中，建议使用DataX和Sqoop相结合。DataX适合用在数据量较小且采用非关系型数据库的场景，部署方式很简单。Sqoop适合用在数据量较大且采用关系型数据库的场景。
在实时数据采集中，对于数据库的变更数据，如MySQL的binlog、Oracle的OGG，使用Kafka Connect进行数据的实时采集。对于其他数据，先将数据实时写成文件，然后采用Flume对文件内容进行实时采集。将实时采集后的数据推送到Kafka，有Flink进行数据处理。
- 数据计算层
数据计算采用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框架。
- 数据存储层
数据存储层所有的存储引擎都基于Hadoop的HDFS分布式存储，从而达到数据多份冗余和充分利用物理层多磁盘的I/O性能。在HDFS上分别搭建Hive、HBase作为存储数据库，在这两个数据库的基础上再搭建Implal、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来统一访问具体存储数据库，从而达到语法统一和数据源统一。
- 数据服务层
数据服务层采用的技术与业务应用类似，主要基于开源Spring Cloud、Spring Boot等构建，使用统一的服务网关，具体可参考第5章。
4.3 数据中台构建策略
构建企业的中台需要站在高屋建瓴的视角，绝不是建设一个应用程序那么简单，或者建设一个报表系统那么直接。构建企业的数据中台也不例外。这是一个系统工程，包括从企业的大数据战略解读、当前所面临的数据痛点及未来几年的业务创新点分析，到技术选项、中台建设模式决策，甚至倒逼不合理的业务系统进行重构等方方面面的工作。
因此，我们建议在构建企业中台时，结合企业当前的组织现状、IT信息化现状、数据潜在应用等多个方面来考虑建设策略。
4.3.1 构建数据中台的挑战
构建数据中台是一个复杂的系统工程，并且数据中台不像有些系统那样，一次建设，一劳永逸。需要做好充分的持久战准备，组织好运营数据中台的中台团队，为数据中台报价护航。
因此，在建设数据中台的过程中，各企业可能都会面临诸多挑战，比如：
- 如何真正体现出数据中台对于企业的核心价值？
- 建设企业的数据中台到底应该组件什么样的团队？
- 到底什么样的建设路径更适合你的企业？
下面将围绕这些问题一一探讨。- 价值挑战
建设数据中台的意义是什么？数据中台预计能为企业的业务开展和拓展带来哪些收益？
数据中台预计能降低多少企业的支出成本？
这些问题都是我没问在决定建设数据中台时首先要考虑的问题。数据中台带来的价值分为三个层面：IT价值、业务价值、和战略价值。
IT价值是企业IT部门最关注的。企业散落在各地的数据无法有序集成与整合，自然就不能有序地对外输出。没有叔叔中台强大的数据整合能力，那么IT部门就很难创造价值。
但是只有IT价值仍然不够，企业的所有IT建设都是为业务服务的。只有满足了各个业务部门业务运营的赋能，才能体现出数据中台的价值。例如，市场推广部门利用数据中台提供的全渠道投放数据进行横向对比，来制定下个月、下个季度、下个年度的推广策略；营销部门利用数据中台收集的消费者画像进行精准营销，是ROI最大化。
真略价值是企业决策者孜孜以求的目标。企业的未来该如何走，要不要拓展新业务，什么时候拓展，数据中台能提供什么样的数据资产，这些都是数据中台建设初期就需要考虑和规划的。
如果没有事先全面考虑这些问题，那么在数据中台建设过程中可能会遇到来自各方面的挑战和阻力。 - 成本挑战
前面讲到数据中台面对价值挑战，那么如何做建设数据中台的成本预算呢？需要配置什么样的团队才能确保数据中台正常运转？是否需要请专业的公司来进行规划和建设？这些都需要进行系统的规划。 - 路径挑战
根据业务开展阶段的不同，企业建设数据中台的路径选择可能也不太一样，总体而言有三种路径：业务中台与数据中台并行：业务中台先行，数据中台跟进；单建数据中台。具体选择那个路径是没有标准答案的，企业需要根据自身当前的信息化建设情况与业务发展阶段来做决定。具体可参考4.3.2。
- 业务中台与数据中台并行：建设的复杂度是第一挑战。由于需要对在建业务中台的业务进行梳理和规划，尤其是需要作出创新，势必会对目前的流程进行改造，甚至会出现多次反复，这就会给数据中台建设带来很大的挑战。而在业务确定之前，无论是数据应用点还是数据源都存在很大的不确定性，这就进一步增加了数据中台建设的难度。
- 业务中台先行，数据中台跟进：很多企业才采取这种模式。这种模式吸取了第一种模式下业务不确定给数据中台建设带来多种不确定性的教训。但是，在数字经济时代，在数字化转型战略大行其道的今天，其实业务与数据早已不能完全分割。业务数据化和数据业务化几乎是同时完成的。比如无论是自建商城还是建设一个会员系统，这些业务早已掺杂了大量的数据应用；比如在建设直播电商的同时，运营团队就提出需要产品上线后通过实时数据来修正业务体验感、运营及时性等能力。
- 单建数据中台：单建数据中台的选择一般是在业务系统已经相对稳定，或者业务中台建设已经对企业的战略转型价值不大时。但是这种模式下也存在挑战。首先，随着业务的野蛮生长，数据散落在各个地方，数据质量已经非常差了，这个时候再进行数据治理，面对的将是一团乱麻，这将是一件非常复杂和耗时的工作。其次，涉及各个领域的数据回收带来组织架构的变革和重组，这是建设数据中台至关重要的环节。如不能有效协调各个领域数据的建设者齐心协力建设数据中台，那么数据中台的建设很难成功。
- 价值挑战
4.3.2 数据中台的构建策略
前文提到数据中台建设是企业的系统工程，一定要站在高屋建瓴的视角来统筹规划。那么在规划的时候需要考虑哪些问题呢？需要整理企业的数据建设现状，已存在哪些数据成果，这可以大致分为三个方面：
1. 估算企业现有数据总量，来推导数据中台底层的硬件配置；
2. 根据数据体量和数据场景需要规划使用什么技术栈；
3. 结合实际情况规划数据中台建设路径；
我们建议将数据中台分为如下三个阶段来建设，
第一阶段：定规范，建平台，小闭环试点。以大平台为主，以某一领域数据应用为切入点，进行小范围试点，快速验证数据中台的价值。
第二阶段：全域建设，夯实数据资产。在第一阶段的基础设施之上全面展开，可覆盖企业主要数据域进行建设，夯实企业全局数据资产，做好数据资产管理工作，并持续围绕业务痛点进行赋能。
第三阶段：运营数据资产，价值变现。以第二阶段的数据资产建设成果为基础，持续运营数据资产，赋能业务。借助资产监控工具及时下线无用的数据资产，深度运营使用率较高的数据资产。
4.3.3 数据中台构建的三大路径
根据业务开展阶段不同，企业建设数据中台的路径可能不太一样，总体而言有以下三种路径，如下图所示。
- 业务中台与数据中台并行
第二章曾提到，在数据经济时代，各行各业追求数字化创新的场景层出不穷，灵活多变的业务场景所依托的信息化建设已根本无法将业务建设和数据建设剥离开。业务数据化和数据业务化的过程就同时完成。从大量的企业数字中台建设经验来看，业务中台与数据中台并行建设是最优实践路径。
可以举一个例子佐证。某高端食品企业已经经营5年了，从最初的线下门店业务为主，到后来顺应新零售大趋势，一方面不断扩充门店，一方面入驻天猫、京东等电商平台，同时大力拓展外卖、自建小程序等零售渠道，但IT建设有点跟不上业务的野蛮增长，企业的会员、交易、供应链仍然没有打通。最近直播带货火了，社区拼团也火了。这个时候想要快速实现直播和拼团功能就出现了问题，没有业务中台，要完成以上创新场景周期很长，恐怕等到平台上线早已被竞争对手占领先机。痛定思痛，拉通全渠道，实现全流程的业务中台建设势在必行。但仅仅建设业务中台就够了吗？很显然不够。该企业运营团队已经摩拳擦掌，准备好了各种针对目标群体的精准定位，去触达最忠实的品牌拥泵，引导他们进入直播平台；找到最喜欢参与活动并分享的KOL，并将其发展成为社区团长。这些场景的运营离不开企业长期沉淀下拉的数据。如果这个时候没有数据中台强大的数据服务支撑，那么很难体会到业务与数据联动的巨大威力。
因此，在创新场景随时可能发生的企业，一定要时刻保持业务、数据双中台待命，建议纳入一体化规划、一体化实现。 - 业务中台先行，数据中台跟进
业务中台先行，数据中台后续跟进。这里的“后续跟进”也仅仅是慢半个身位。新的创业公司，刚刚开始新的业务，这个时候的确没有任何数据沉淀，那么可以考虑优先实现业务中台建设，尽快让业务线运转起来。但是在进行企业信息化建设规划的时候，一定要将数据中台纳入统一规划和设计。半个身位指的是在业务正常运转后，马上基于之前的数据闭环来开始数据中台的建设。 - 单建数据中台
有些企业认为自身业务复杂度高，对现有的改动工作量大、周期长，而如果选择只建设数据中台、不建业务中台，一则相对独立性高，二则不影响现有业务，也是可行的。还有些企业认为自身已建设了基本成型的后台系统，但此前数据却一致被忽略了；或者是按照老旧的系统建设模式，由各业务系统建设各自的数据报表系统或数据仓库，但是数据根本没有在企业的统一平台上有序流转，形成企业的数据资产。那么将企业的数据横向拉通，建设数据中台是企业的第一要务。
然而，跳过业务中台，先从数据中台下手，需要整合不同的数据源以及不一致、不规整的数据，此工作占据了数据中台建设的大部分工作量。而如果配合业务中台，则认为业务中台天生就规整了数据，并提供规范的数据给数据中台，能大大降低数据中台的建设周期，且不用重复投资。当然，在建设数据中台的过程中，尤其是业务调研环节（4.4节），可能会梳理出一些业务系统建设不合理的地方，会倒逼着业务系统进行改造，推动数据更好的赋能业务运营。
4.4 数据中台构建五步法
系统都是为应用而生的，数据中台也不例外。要构建一套数据中台服务于企业内部和外部运营，需要有成熟的数据中台建设方法论作为指导。企业建设数据中台遵循的方法论就像菜谱，初学者根据菜谱按部就班就可以轻松完成一道道菜肴，高阶玩家根据菜谱可以查漏补缺，使厨艺精进。
数据中台建设方法论可分为高阶规划、系统设计、开发实施、试运行和持续运营5个阶段，如下图。
4.4.1 高阶规划
万丈高楼平地起，规划阶段之于数据中台建设，就相当于构建一座水库前的勘察和分析，了解构建水库目标、水源、蓄水、水库下游，为设计图纸提供基础支持。同样建设数据中台也需要对企业的数据源、存储数据的方式、数据服务诉求等信息进行摸查，构建未来的蓝图。对现状和将来了解的越清楚，对数据中台的轮廓就了解的越清楚，数据中台的成功就越有保障。
数据中台规划阶段可细分为业务架构师主导的业务规划和数据架构师主导的数据规划。这两部分内容是相辅相成的，由业务规划进行业务输入，由技术规划对数据现在进行探查，判断业务规划蓝图的可行性，最终形成可行的蓝图规划与应用设计。
1. 业务规划
业务规划分为三个步骤：业务调研、蓝图设计和应用设计。
1. 业务调研
业务调研主要包括以下两个方面。
第一，战略与组织解读。企业战略决定了数据中台的上线，也决定了企业对数据中台的期望和目标。企业战略不仅能折射出企业的数据诉求本质，也能体现出数据中台对企业的价值。因此，通过明确企业战略对企业运营提升的要求，可以抓住企业运营提升的关键环节，对公司管理现状进行诊断，分析数字化能力给企业带来的效率和效益提升，明确企业数字化优化的目标和范围。同时，明确企业的组织架构，熟悉企业的业务模式，了解企业的业务板块，梳理业务部门的业务流程。
第二，调研访谈。调研访谈是通过问卷或针对性访谈的形式，对业务专家进行调研的过程。在调研的过程中可以收集报表、汇报材料、报告、可视化看板、系统建设材料等信息辅助理解业务。调研访谈的目的是通过对业务专家的调用，了解企业于业务，了解业务诉求与痛点，为后续的蓝图设计和应用设计提供业务知识基础和输入。调研前需要对业务背景、行业知识、调研问卷分布做准备，以便达到期望的调研效果。可以将调研问卷提前分发给业务专家，以便业务专家更有针对性的准备问题答复，提高调研效率。调研后需要结合业务场景，对数据进行推导，得出指标需求。推导的过程是现在诉求-》需求推导-》解决手段-》场景推导-》指标推导。详见下图。
2. 蓝图设计
通过业务调研了解企业，结合数据现状与业务痛点，将企业不同实体的数据进行提炼、抽象，形成数据域，将数据资产按照一定的体系进行规整，再结合业务诉求对数据分析场景进行提炼，最终形成一张囊括企业数据现状与未来的蓝图，为后续数据中台的建设提供宏观与发展路线的指导。
蓝图设计可以从以下几个方面进行分析设计：数智化转型的一些考虑和战略、设计方法论、对客户业务的整体解析、数据中台价值化、分析链路梳理、数据域梳理和划分等。数据中台蓝图一般包括三部分：数据源、数据基础能力及数据洞察与智能应用规划。通过数据中台蓝图可以快速了解企业数据中台的范围与价值。
3. 应用设计
衔接蓝图设计，结合数据调研的成果判断数据可行性后，将数据分析场景、智能应用进行系统落地的可视化设计，形成PRD文档和原型进行产品设计与说明，最终促成应用的实现。
2. 技术调研
技术调研是对企业的IT整体现状进行摸查，调研内容包含企业主要业务及核心业务系统、整体网络拓扑现状、信息安全相关要求等。
对企业主要业务和核心业务系统的调研包括业务和技术两个方向。业务上梳理企业的主要业务及核心业务流程，技术上则梳理各业务系统及他们之间的数据流转关系。两者相互印证，输出企业的信息系统现状大图，并基于此确定后续的业务系统调研范围。
整体网络拓扑现状的梳理，有助于厘清企业业务数据的存储分布位置、数据传输的带宽限制等信息，为后续数据集成方案设计提供基础信息输入。
通过信息安全相关的调研了解企业内与信息安全相关的组织部门、规章制度等信息和要求，为后续制定数据处理和使用的流程规范提供依据。
3. 系统和数据调研
系统与数据调研的目的是厘清企业数据资源的种类、分布、存储及管理现状。系统与数据调研是按业务系统进行盘点的。系统盘点的范围来源于技术调研的输出。盘点项包括业务流程、业务动作、数据源、数据表、数据字典。该调研工作一般由技术主导。
业务历程及动作的调研，需要从使用者的角度出发，确认业务系统每个原子操作产生了哪些数据，数据存储在哪些数据表中。这部分的调研需要调研人员通过系统文档资料梳理系统流程，并通过实际操作来验证数据流程，最后结合数据字典将系统流程和数据表进行关联。
数据源盘点需关注数据源种类，如结构化、半结构化和非结构化数据，以及链接地址、账号、密码、可抽取数据的时间段等；数据表级别关注是否为核心表、时间戳字段、数据更新标识、表的总数据量、日增数据量等信息。
系统与数据调研完后，需输出相应的产出物，并与业务系统的相关人员就输出物中的产出项进行沟通和确认。在实际实施中，不同企业的信息系统建设情况也不尽相同，输出物中的内容项可能需要以迭代方式进行补充调研。
4. 总体规划输出
规划阶段包含业务侧和技术侧的调研，两边的调研工作可以并行开展。在业务侧完成调研及需求规划后，技术侧需要结合业务侧的产出进行相关的数据探查事项，主要目的是确认调研产出是否足够支撑业务的数据应用建设。
总体规划在最终定稿后，业务侧需输出指标、标签清单、数据应规划文档等，而技术侧需输出技术和系统调研的相关输出物，以及系统调研阶段的总结性报告。
4.4.2 系统设计
在盘点了企业当前的数据应用需求及数据资产情况，并根据实际情况规划了数据中台的建设路径后，我们就可以进入非常重要的系统设计环节了。系统设计包含总体设计、数据设计及平台设计。
1. 总体设计
第一阶段的规划工作完成后，进入总体的架构设计阶段。此阶段需要回答以下问题：如何构建统一、规范、可共享的数据体系，如何避免数据的冗余和重复建设，如何规避数据烟囱和不一致性等。由阿里巴巴提出的oneData的核心思想是统一数据主体、统一数据建模、统一数据服务以及一系列的数据管理体系。在设计阶段，可以从这几个方面进行考虑与架构。这一阶段由技术架构师与模型设计师主导，规划设计出整体的数据架构、平台架构和研发规范，如下图：
-
1、数据架构
数据中台的数据架构设计是基于需求调研阶段的业务需求、数据情况、完成数据中台概要设计工作。数据架构设计主要包含OneModel数据架构设计、OneID数据架构设计和OneService数据架构设计。
OneModel分一下四部分：- 业务板块：根据业务的特点和需求将相对独立的业务划分成不同的业务板块，不同业务板块之间的指标或业务重叠度较低。
- 数据域：数据域是指面向业务分析，将业务过程或者维度进行抽象的集合。划分数据域前，需要基于数据调研与业务调研，熟悉各业务系统设计文档、数据字典等。归纳与总结出跨源的主题域合并，梳理出整个企业的数据域。数据域划分上，需要从三个方面进行考虑。
- 全局性：站在企业高度上，保障良好的扩展性和稳定性。
- 数量适中：根据业务情况，划分的粒度要粗细合适，通常在5-15个
- 可理解：站在业务角度上，确保划分便于理解，不产生歧义
在划分数据域时，既要涵盖当前所有业务需求，也要考虑有新业务时，能够将其包含到已有的数据域中，或者能够很容易地拓展新的数据域。
- 总线矩阵：在进行了充分的业务调研和需求调研后，就要构建总线矩阵了。总线矩阵由业务处理过程和维度组成一个二维表格。在行为不同的业务处理过程（事实）与维度的交叉点上打上标记，表示该业务处理过程与该维度相关。这就是构建一致性维度与一致性事实的过程。维度表和事实表的模型设计以构建出来的总线矩阵为依据。
- 数据分层：数据模型以维度建模理论为基础，建设数据中台的公共数据层。一般将数据模型划分为操作数据层（Operation Data Store，ODS）、通用数据模型层（Common Data Model，CDM）和应用数据层（Application Data Service，ADS）。
OneID分如下四部分： - OneID配置：主要根据具体的业务需求，完成数据源表、ID映射表、歧义规则表的设置工作。
- OneID数据处理：主要通过数据源表和ID映射表等配置表单完成原始数据的数据拉取和清洗等操作，生成基础数据。
- OneID规则计算：主要利用图计算框架完成关键连接点的搜索和歧义数据的图联通工作，并根据配置的规则对图数据进行切割，从而唯一确定一个实体的身份信息，生成OneID。
- OneID数据存储和展示：主要完成OneID图数据存储和展示，以及最后生成的OneID清单数据存储等。
统一数据服务OneService包括以下功能模块： - 服务单元设计：是指将单个或多个物理表配置成一个试图。
- API设计
- API审核
- API运营
基于配置好的服务单元，通过简单可视化界面或SQL脚本，设计API的请求参数和返回参数，以及对应的API信息。API设计好后，将其发布至服务市场供使用者调用。API在被使用前，需要经过申请审批。被使用的API需要运维及监控，包括平均响应市场、调用次数、错误率、掉线百分比等指标的监控，还可以配置API的告警 及限流措施等。
-
2、平台架构
结合前期调用的业务需求和数据现状，从宏观层面规划出数据中台的各个模块、各个功能部件所用到的技术总体架构图。总体架构由数据采集、数据存储、数据流、网络、部署、安全等组成。
- 采集架构：数据采集打通各种数据来源，为数据中台提供待分析和处理的数据，主要分为实时和离线数据采集方案，具体可参考4.2.2
- 存储架构：整个存储架构包含原始数据源存储技术、数据源接入技术、数据中台数据存储与计算技术、数据服务及数据应用技术。从数据采集、数据加工到最后的数据展示，设计出整个流程中不同数据来源到数据中台的存储。
- 数据流：从业务数据进入数据采集通道，到进入数据中台在各个加工任务中流转，再到数据对外服务的这个过程，需要进行哪些存储、那些技术处理等，这些步骤需要在设计时就以数据流向用流程图的形式画出。
- 网络架构：数据中台涉及与多方的源系统进行数据交换，而网络设计对于后续数据同步、接口调用等有较大的影响，因此需要综合考虑各业务系统与搭建数据中台环境的网络情况。如果设计上云，业务系统有可能在本地，而数据中台的环境在云上，要考虑是否需要设计专线。同时根据每天要同步的数据量，设计出带宽的容量。
- 部署架构：这部分设计主要涉及数据中台的研发平台与应用软件。需要包含整体的部署方案，如Hadoop生态圈中所采用各个组件的部署节点，每个角色的功能部署几个节点，在机器资源上如何分布，还包括数据库的主备方案、后端应用的部署等。
- 安全架构：主要包含研发平台的用户角色权限控制方案、开发与生产环境隔离方案、数据安全方案。考虑在数据抽取、数据加工处理和数据服务的整个数据加工链条中对企业的敏感信息进行加密处理。
3、数据模型设计规范与标准
良好的数据模型可方便、有效地组织数据中台中存储的企业数据资产，所以数据模型的设计工作有必要遵循一定的规范和约束。团队在明确定义模型设计的相关实施规范及要求后，需要向参加数据中台建设的相关人员明确规范和要求，确保团队内统一标准，以保障和提升数据开发与运维管理的效率，并方便后续的知识移交和数据管理工作。规范应清晰的阐述模型定义与代码开发的相关约束。模型规范要明确数据架构中的分层、分层的命名，定义不同接入频率、不同系统表命名方式。代码研发规范层面应定义好各种不同用途、不同脚本类型的命名规范等。
2. 数据设计
数据设计包括数据集成、模型设计和服务详设，如下图。
1、数据集成
数据集成需要解决不同源系统数据异构性问题。源业务系统的数据类型多种多样，有来源于关系型数据库的结构化数据，也有来源于非关系型数据库的非结构化数据即半结构化数据。
结构化数据一般以二维形式存储在关系型数据库中，对于这种数据类型，数据集成有3种方式：
- 直连同步：通过规范的API直接连接业务库。但是业务库直接的方式对源系统的性能影响较大，当执行大批量数据同步时会降低甚至拖垮业务系统的性能。即使业务数据库存在备库，当数据量较大时，此种抽取方式性能也较差，不太建议使用。
- 数据文件同步：通过约定好的文件编码、大小、格式等，直接从源系统生成数据的文件，由专门的文件服务器（FTP）作为中间文件交换，加载到数据中台，还需要上传校验文件，供下游系统校验数据同步的准确性。
- 数据库日志解析同步：这种方式实现了实时与准实时同步，延迟可以控制在毫秒级别，并且对业务系统的性能影响比较小，目前广泛应用于从业务系统到数据中台系统的增量数据同步应用之中。
除了数据读取的方式，还可以按数据量来分解数据集成策略：
- 小数据量同步：数据记录小于10万条的源表建议每日全量更新，写入全量分区表。全量分区表可按天创建。可根据业务需要设置数据的生命周期，并定时清理。
- 大数据量同步：数据记录大于10万条的源表通过时间戳抽取增量数据到增量分区表。增量分区表可设置长周期，根据需要设置冷、温、热数据区。
非结构化数据一般没有固定的结构，各种文档、图片、视频、音频等都属于非结构化数据。对于这类数据，数据集成策略通常是直接整体存储，而且一般存储为二级制的数据格式。
除了结构化数据和非结构化数据，还有半结构化数据。半结构化数据的应用越来越广泛。半结构化数据带有用来分隔语义元素和数据记录的标记，具有自描述特性，常见的数据格式有JSON和XML。对于半结构化数据，数据集成策略同样可以实直接整体存储。但随着数据技术的发展，NoSQL数据库已经开源很好地支持半结构化数据的存储。NoSQL在逻辑表现形式上相当灵活，主要有4种模式：
- 键值模型：键值模型在表现形式上比较单一，但却有很强的扩展性。
- 列式模型：由于每列可以动态扩展，列式模型相比键值模型能够支持的数据更为复杂。
- 文档模型：文档模型对于复杂数据的支持和在扩展性上都有很大优势。
- 图模型：使用场景通常基于图数据结构，如社交网络、推荐等。
半结构化数据集成方面，建议使用NoSQL数据库。
2、模型设计
数据模型可以分主题域模型、标签模型和算法模型。其中主题域模型是基础，似乎对数据标准化、规范化的过程。标签模型基于主题域模型将对象的各种标识打通归一，将跨业务板块、跨数据域的对象组织起来。算法模型基于主题域模型，将各对象的历史行为、属性等数据作为输入，利用算法能力分析和预测对象的行为。下面来详细介绍三种数据模型的设计。
首先看主题域模型设计。主题域模型也就是大家常说的数仓模型。数仓模型的设计方法论已经非常成熟，最权威的数仓模型设计是Kimball的维度建模。阿里巴巴在维度建模基础上进行了升华，沉淀了OneModel方法论，将数据从业务板块到业务域、业务流程、指标和维度，一层层梳理，构建出企业的指标体系并形成数仓模型。OneModel方法论强调从业务过程出发，站在数据应用与分析的角度，梳理出业务过程中涉及的维度及度量，并对业务过程中的度量进行规范定义，统一指标口径，消除指标二义性，形成统一的指标体系；同时，构建一致性维度及事实矩阵，并据此进行维度及事实模型设计。
主题域模型分以下三层：
- 操作数据层（Operational Data Store，ODS）：主要将业务系统、日志等结构化和半结构化数据引入数据中台，保留业务系统原始数据。ODS分为缓冲区和数据服务区。缓冲区设计主要保持与数据源的一致性，保证ODS能原样引入所接入的源数据，不进行任何类型转换和数据加工处理。数据服务区包括全量明细数据，该数据是对缓冲区数据进行类型转换或增量合并处理后得到的，数据服务区为通用数据模型层和应用数据层提供数据服务。引入缓冲区是考虑到数据引入后可能会有一些特殊的处理需求，比如埋点数据采集后一般为JSON格式数据，这类需要在解析后再引入；或者有一部分实时采集的数据需要与当前存量数据进行合并处理，以获取当前最新状态的数据。缓冲区能起到很好的追溯作用，方便后续追查与核对问题，为后续的数据分层建模提供良好的数据基础。
- 通用数据模型层（Common Data Model，CDM）：包含整个数据中台的大部分数据，是数据中台的基础，因此保证该层数据的健壮性是重中之重。CDM主要完成公共数据加工和整合，建立一致性的维度，构建可复用、面向分析和统计的明细事实表及汇总事实表。
- 应用数据层（Application Data Service）：提供直接面向业务或应用的数据，主要对个性化指标数据进行加工处理；同时为方便满足数据应用、数据消费的诉求，进行面向应用逻辑的数据组装，比如大宽表集市、横表转纵表、趋势指标串等。
其次介绍标签模型设计。实体标签模型是数据中台建设中的另一类重要模型，这里模型对于企业数据治理、业务输出都具有举足轻重的作用。企业的重要数据资产，如客户、商品、门店、供应商、员工等实体的标签模型都是数据中台加工的重点。比如，先获取商品的生产、采购、定价、销售、退货等历史行为数据，然后按照业务场景需要来制定商品所涉及的商品标签，形成商品标签模型。
最后讲解算法模型设计。数据中台整合全域的数据，需要通过AI算法将宝贵的数据形成有价值的数据资产。算法模型是数据中台中最难设计的模型，但又是最能将企业的数据资产发挥出几何倍数价值的模型。例如，凭借商品个性化推荐模型，淘宝的“千人千面”场景帮助用户极大提升了体验感，缩短了用户的交易链条，提升了了用户的转化率。算法模型与上两种模型的不同之处在于，在建模的过程中需要充分聚焦算法所服务的场景。比如对于商品推荐算法模型，建模时需要充分理解涉及商品推荐的相关场景。商品个性化推荐一般有首页推荐商品列表、猜你喜欢专栏、购物车推荐专栏等场景。我们要充分梳理这些场景的需求点，然后制定实现推荐模型的场景，如下图。在通过场景梳理编排出算法实现逻辑后再开始设计算法模型及实现逻辑。
3、服务详设
数据服务按数据内容可分为主体分析类数据服务、标签类数据服务和算法类数据服务。
- 主体分析类数据服务可通过整合数据分析场景，分专题设计通用的数据汇总宽表，通过数据宽表拼写不同的SQL，支撑相应的数据报表，避免数据的冗余建设。
- 标签类数据服务的设计却有所不同，切记按照标签使用场景逐个进行数据服务设计。因为运营可能会随时增加标签，迫使在设计标签服务时考虑通用性和扩展性。一般建议以底层的标签宽表为出发点，设计标签通用的增加、修改和查询功能。
- 与业务联动紧密的算法类数据服务则需要注意可能直接面的低延迟、高并发的调用场景，比如推荐场景，包括搜索推荐、猜你喜欢、加购推荐等，一定要做好服务接口的性能压测，以满足业务实时交易级的性能要求。
除了考虑服务的通用性和性能，还需要考虑服务开放的数据安全性。
3. 平台设计
平台设计指的是大数据运行平台在资源规划、技术选型、部署方案等方面的设计，是根据总体架构中的平台架构展开的。平台能力具有通用性、扩展性和前瞻性是数据中台成功建设的基础。平台设计阶段将以客户现有数据体量及可预测的业务增长情况作为考量因素，对平台建设所需的资源进行预估和规划，产出平台及数据应用部署所需的资源清单、部署方案及相关人员在平台上的账号和权限的设计等。
-
资源规划：需要对支撑大数据平台所需的资源进行估算。一般可考虑未来3年企业的数据量，可借鉴的存储空间。资源估算公式如下：
-
技术选型：大数据技术选型的原则是考虑当前及未来一段时间可能使用的场景，根据场景来推导技术的选择。一般会从数据的采集、存储、计算、管理、运维等多方面考虑需要选择的技术或成熟产品来搭建大数据平台。比如，文件采集使用Flume到HDFS，数据库采集使用DataX到HDFS，计算与加工基于Hive存储、离线使用Spark SQL处理、实时采用Flink等。
4.4.3 开发实施
开发实施阶段可分为环境搭建、数据集成、代码研发三个层面。
1. 环境搭建
平台层面的环境搭建，包括大数据集群、数据研发平台、智能数据应用产品等相关工具的部署。平台的搭建按设计阶段数仓的资源规划和平台部署方案实施即可。在平台环境下、工具组件部署后，需要对平台环境进行测试，同时在产品工具层面，需要对企业进行相关产品的使用培训，并通过企业的验收。
2. 数据集成
数据集成方案从宏观上设计和规范了数据源级别的数据集成流程和同步策略。在当前阶段，需要对各数据源制定表级别的集成策略，形成数据同步清单，包括上云数据存量、日增量、分区字段、数据更新频率、存储周期、上云时间等相关信息，供具体实施时使用。数据集成工作实施后，还需要逐一对数据源进行数据监控及验证，以确保集成的数据无问题。
3. 代码研发
代码研发阶段包括数据研发和验证、应用研发和测试、性能测试三部分。数据研发与验证主要包括数据模型的业务代码开发、数据监控代码开发、数据准确性验证。从模型数据开发、数据监控开发到数据验证，再到模型上线，需要一整套开发流程来保障数据的产出。应用研发与测试主要包括数据应用层面的开发和测试工作，如数据服务、数据应用前端开发。性能测试包括数据产出时间、数据接口服务性能、数据应用访问性能等方面的测试。
4.4.4 试运行
数据中台上线之后，分析专题的指标口径、数据应用效果等多方面的数据准确性都需要通过真实的运行数据去验证。在这个时间段还不太适合全面对外发布，也不宜对外开放数据能力。通常我们需要进行一段时间的试运行。
1. 中台试运行
为保障生产环境数据的准确性，需要现在测试环境基于企业的全量数据进行一段时间的试运行，主要包含以下几步。
1.数据迁移：增量模型涉及的存量数据需要进行一次全量的数据迁移，以保证数据的完整性，全量模型则直接按频度进行抽取即可。迁移前，需定制详细的迁移方案及步骤；迁移时，需要记录各个环节的关键数据，如迁移耗时、资源消耗情况等；迁移后，需总结并输出迁移报告。
2.数据跑批：完整运行数据中台的全流程任务，包括数据抽取、加工、服务提供及应用展现，分析各层级模型任务的运行耗时以及对应时间段的资源情况，并不断优化、调整运行任务的启动和依赖关系，以达到最佳的配置。
3.数据验证：是爱心核心关键指标、标签，进行数据准确性的验证，例如存量指标可与系统现有指标进行对比，增量指标则与模型设计内容逐层对比。
4.应用验证：对于对外服务接口类应用，联系应用方进行接口技术局验证，并完成全流程的拉通，优化调用的频次及时间点；对于报表及专题分析类应用，验证报表数据与数据中台侧数据的一致性，以及测试前端页面、展现数据的性能。
2.历史数据重跑和测试
在试运行过程中，数据中台的指标或标签可能会因为业务侧的口径变更而进行历史数据的重刷动作。在这种情况下，要保证数据准确且可逆，有如下几点注意事项。
- 影响评估：评估业务变动设计的模型，并形成清单列表
- 数据备份：数据处理前，先备份当前状态下的数据
- 口径调整：确认业务口径调整涉及的技术口径调整内容，并体现在模型设计文档的版本控制中。
- 数据验证：调整后，严格按照设计内容进行数据的验证和测试，并与业务侧达成一致，在测试环境中进行确认。
4.4.5 持续运营
数据中台不是一锤子买卖，是需要持续经营的。在数据中台正式上线后，随着企业业务的不断发展，会接入更越来越多的数据源，数据的分析也将越来越精细，数据应用场景会更加丰富多样。同时，某些数据应用会因为企业业务方向的调整而废弃，这些已经过时的应用就需要及时清理。作为数据中台的建设者，不仅需要定期与数据使用者沟通，了解数据使用情况，了解这些数据到底带来了什么价值，还要通过系统查看指标、标签、专题、应用API这些资产的被调用情况，一次来判断是否需要优化等。
1. 正式上线
试运行稳定执行一段时间后，可按模块和迭代申请生产环境的正式上线动作，以交付阶段性的工作成果。在正式上线时，分以下两边进行。
- 割接方案。如果数据中台存在替换现有其他系统的情况，就需要制定详细的割接方案，以保障数据中台能够覆盖旧系统的数据能力。
- 上线预演。在正式上线前，需进行割接或上线的演练操作，尽可能多地暴露数据、环境、资源等各方面的问题，并逐步进行优化和调整。
系统上线后，制定相关的检测规则及告警机制，以保障数据中台的正常运行。检测规则可大致分为如下两类。
-
数据规则：数据一致性，主键唯一性，数据完整性
-
资源规则：服务器资源，如CPU、I/O等；存储告警规则。
检查规则执行完成后，根据检查结果制定告警策略，如异常告警阻断、异常告警不阻断。同时，通过短信、邮件等方式将检查结果进行告知，并制定告警升级机制。
2. 运营保障
系统上线后，跟进系统的运行、使用情况，综合分析以提炼新的需求点，创造更大的价值点，持续运营。数据中台的运营策略可从产品、应用、数据三方面进行。
- 产品侧：收集直接使用方的产品体验状况，根据反馈内容进行优化，提高产品的易用性，增强使用方对产品的黏性。
- 应用侧：分析应用对象的重点关注模块，并阶段性地形成分析报告。中台建设者可根据报告内容，对接应用相关人员，持续挖掘新的需求内容，持续耕耘以创造更大的价值。
- 数据侧：通过数据链路跟踪的结果，总结阶段性重点关注的数据内容。结合自上而下和自下而上的两种途径，分析整个系统数据层面的缺口，并制定汇聚、扩建的计划，提高中台数据支撑的力度。
4.5 用数赋智，建设企业数智大脑
数智化可概括为通过链接产生数据，基于数据产生智能，基于智能赋能商业，从而推动企业业务新的增长（参考第一章）
通过数据中台，将在线化数据转化为智能化数据，激活数据商业价值。通过持续的数据完善补充和训练学习，作出更加智能的决策，形成良性学习与反馈闭环，最终帮助企业实现数智升级转型。
4.5.1 营销域智能
智能营销的一般流程是基于运营目标定场景、定商品或服务、找人群、制定具体营销方案，其中最关键的因素是精准的消费者洞察。
- 黄金购买时间：基于大数据算法精准预测顾客购买时间，有效提升活动ROI
- 会员健康模型：基于多维数据，结合大数据算法，精准洞察会员所处生命阶段及流失概率，助益品牌掌握整体会员健康结构的动态变化，并针对不同阶段人群采用对应的运营策略，以最大化会员终生价值。
- DMP精准营销：融合多源外部三方数据进行精准广告策略投放，促进公域向私欲的有效转化。
4.5.2 商品域智能
当下消费者呈现出需求个性化、碎片化的特点，他们在消费商品或服务时更关注内容创新、服务体验，因此，如何让商品在满足消费者需求的同时提升动销、降低库存，成为摆在品牌方前的首要问题。我们可以在选品组货、关联分析、个性化推荐上做一些尝试。
- 选品组货：基于人----货关系匹配辅助门店选品铺货策略，优化门店商品结构，为零售商提供精细化的品类管理能力，有效提升商品动销。
- 关联分析：通过关联分析发现群体购买习惯的内在共性，支持品牌商品促销组合、商品优惠组合搭售策略，提升客单连带率。
- 个性化推荐：基于用户订单交易及行为数据洞察，通过深度学习算法构建用户与商品的“千人千面”个性化推荐，提升用户体验及销售转化。
4.5.3 门店域智能
门店域智能围绕门店运营、销售、管理等业务环节为不同角色提供数据决策能力，从而提升门店的运营管理效率。以下为几个门店域智能应用的例子。
- 门店销量预测：基于门店相关数据，结合销量预测算法模型，对门店未来销量进行预测，从而指导品牌开关店策略及补货策略，提升门店销售管理效能。
- 标杆门店画像：多维度构建门店效能评估指标体系，并进一步通过算法模型建立标杆门店群体，进行针对性运营目标管理，达到系统化优化门店运营管理。
- 门店智能导购：赋能门店运营管理，提供员工赋能、商品运营、社群运营、员工激励、数据运营等能力，实现对门店导购的数据化、智能化管理及赋能，提升门店的运营效率。
4.5.4 渠道域智能
渠道域智能是面向渠道经销商客户的洞察决策。通过数据赋能，为经销商改善生意，从而提升品牌的影响力，同时提升品牌商对经销商的风控识别及合作能力，实现双赢。
- 经销商生意参谋
- 经销商画像
- 经销商生命周期运营
4.5.5 物流供应链域智能
物流供应链域智能主要从成本和效率两大目标出发，优化供应链各环节的响应效率，保障终端渠道的现货供应，降低缺货率。同时，将供应量各环节库存控制在适量水平，进而加快资金周转。
- 智能配调补
- 订单执行监控预警
- 供应链物流能力指标体系
4.5.6 服务域智能
服务域智能主要围绕客户服务中的问答、质检、舆论和预测等业务场景，通过大数据、AI、IoT等先进技术，转变服务方式，实现客户服务的降本增效。
- 问答机器人：基于自然语言处理（NLP）相关技术，机器人可理解用户意图、需求及情感，利用多轮对话及智能化任务处理能力，为用户提供智能化客户服务即创新体验，提升企业客户服务效率，降低客户服务成本。
- 智能质检：根据语音、文本、图片、表情和视频等相关会话数据，通过智能质检模型和算法，可实现全量会话数据质检，检测客服服务质量和水平，提升质检效率，告别2%~5%人工抽检的传统质检模式。
- 服务舆情：通过会话数据、评价数据、服务调研数据和服务互动数据挖掘分析，借助服务舆情模型为企业提供品牌口碑监测、产品质量监测、服务质量监测和新客户需求挖掘，促进企业客户服务水平提升、产品生产调优，并为企业开展相关创新提供决策支持。
- 服务预测：智能客服服务域IoT相关技术和场景融合，帮助企业为客户提供基于产品生命周期的产品性能检测、产品故障预警等智能客服服务预测，并提供服务解决方案，将客户服务由被动变为主动服务，从而提升企业客户服务满意度和品牌美誉度。
方式，实现客户服务的降本增效。
- 问答机器人：基于自然语言处理（NLP）相关技术，机器人可理解用户意图、需求及情感，利用多轮对话及智能化任务处理能力，为用户提供智能化客户服务即创新体验，提升企业客户服务效率，降低客户服务成本。
- 智能质检：根据语音、文本、图片、表情和视频等相关会话数据，通过智能质检模型和算法，可实现全量会话数据质检，检测客服服务质量和水平，提升质检效率，告别2%~5%人工抽检的传统质检模式。
- 服务舆情：通过会话数据、评价数据、服务调研数据和服务互动数据挖掘分析，借助服务舆情模型为企业提供品牌口碑监测、产品质量监测、服务质量监测和新客户需求挖掘，促进企业客户服务水平提升、产品生产调优，并为企业开展相关创新提供决策支持。
- 服务预测：智能客服服务域IoT相关技术和场景融合，帮助企业为客户提供基于产品生命周期的产品性能检测、产品故障预警等智能客服服务预测，并提供服务解决方案，将客户服务由被动变为主动服务，从而提升企业客户服务满意度和品牌美誉度。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
