《数据中台：让数据用起来 》读书笔记
数据中台核心认知
- 数据中台需要提升到企业下一代基础设施的高度,进行规模化投入
- 数据中台需要全新的数据价值观和方法论,并在其指引下形成平台级
能力 - 数据中台围绕业务、数据、分析会衍生出全新人才素养要求,需要尽
快启动人才储备
数据中台发展三个阶段
- 数据中台探索阶段
这个阶段会将数据生命周期各个阶段的技术与现有业务场景或创新业务
场景结合,迅速形成可见、可展示的业务成果。特点是项目短小精悍,
容易见效果,缺点是由于缺乏数据中台整体规划及让数据用起来的完整
流程设计,无法对众多单个数据应用沉淀的数据形成通用数据资产,每
个项目都需要从头到尾走一遍,当应用需求爆发式增长时,底层数据支
撑的效率会大幅度下降,甚至影响最终的业务效果。 - 数据中台整合数据应用提升效率
这一阶段的特点是构建数据中台的技术、理念、方法论是可复制的,市
场上已有成熟的支撑数据中台高效运转的平台级产品。企业通过规划、
建设、实施数据中台能够具备三方面的基础能力:
数据的多样性、多态性、多云连接能力(汇聚/交换能力)。交换的能
力用来解决企业有哪些数据、数据在哪里等问题。
数据资产化的能力是数据中台建设的关键,包括清洗、加工、治理、
安全、质量等工具模块及实施方法论。(说明:能直接作用于业务领
域,业务能阅读、能理解的数据才叫数据资产。)
数据服务化的能力,用数据技术来使用数据的方法。 - 数据中台重构数据空间和业务空间
到了这一阶段,数据中台已经成为企业数据资产的核心能力和基础,通
过快速构建数据资产体系,帮助企业真正实现对其全量数据的有效管
理。业务和业务流程本身都可以通过适当的颗粒度进行数字化解耦和标
准化,企业能够以自我为中心构建更加宏大的产业、行业价值链范围的
数据空间和业务空间,以数据编排的方式响应业务需求,彻底颠覆传统
的软件工程方式,业务实现自流程化,数据实现自我管理能力。
数据中台建设模式
image.png
数据中台定位
image.png
数据中台定义
数据中台是一套可持续“让企业的数据用起来”的机制,是一种战略选择和组织形式,是依据企业特有的业务模式和组织架构,通过有形的产品和实施方法论支撑,构建的一套持续不断把数据变成资产并服务于业务的机制。数据来自于业务,并反哺业务,不断循环迭代,实现数据可见、可用、可运营。
image.png
image.png
数据中台的实施不仅需要一整套技术产品,更需要针对不同业务、数据、应用场景的体系化的实施方法和经验,过程中涉及企业战略、组织、技术、人才等全面的保障和配合。
数据中台必备的四个核心能力
-
汇聚整合
数据中台需要对数据进行整合和完善,提供适用、适配、成熟、完善的一站式大数据平台工具,在简便有效的基础上,实现数据采集、交换等任务配置以及监控管理。
数据中台必须具备数据集成与运营方面的能力,能够接入、转换、写入或缓存企业内外部多种来源的数据,协助不同部门和团队的数据使用者更好地定位数据、理解数据。同时数据安全、灵活可用也是绝大多数企业看重的,他们期望数据中台能协助企业提升数据可用性和易用性,且在系统部署上能支持多种模式。
image.png
-
提纯加工
数据中台必须连通全域数据，通过统一的数据标准和质量体系，建设提纯加工后的标准数据资产体系，以满足企业业务对数据的需求
image.png
-
服务可视化
为了尽快让数据用起来，数据中台必须提供便捷、快速的数据服务能力，让相关人员能够迅速开发数据应用，支持数据资产场景化能力的快速输出，以响应客户的动态需求。
多数企业还期待数据中台可以提供数据化运营平台，帮助企业快速实现数据资产的可视化分析，提供包括实时流数据分析、预测分析、机器学习等更为高级的服务，为企业数据化运营赋能。
AI的能力也被多数企业期待能应用到数据中台上，实现自然语言处理等方面的服务。数据洞察来源于分析，数据中台必须提供丰富的分析功能，数据资产必须服务于业务分析才能解决企业在数据洞察方面的短板，实现与业务的紧密结合。 -
价值变现
数据中台通过打通企业数据，提供以前单个部门或者单个业务单元无法提供的数据服务能力，以实现数据的更大价值变现。
image.png
image.png
image.png
数据中台和业务中台区别
业务中台更多偏向于业务流程管控，将业务流程中共性的服务抽象出来，形成通用的服务能力。
业务中台是抽象业务流程的共性形成通用业务服务能力，而数据中台则
是抽象数据能力的共性形成通用数据服务能力。
image.png
数据仓库 VS 数据中台
数据仓库的主要场景是支持管理决策和业务分析，而数据中台则是将数
据服务化之后提供给业务系统，目标是将数据能力渗透到各个业务环
节，不限于决策分析类场景
数据中台建设包含数据体系建设，也就是数据中台包含数据仓库的完整
内容，数据中台将企业数据仓库建设的投入价值进行最大化，以加快数
据赋能业务的速度，为业务提供速度更快、更多样的数据服务。数据中
台也可以将已建好的数据仓库当成数据源，对接已有数据建设成果，避
免重复建设。当然也可以基于数据中台提供的能力，通过汇聚、加工、
治理各类数据源，构建全新的离线或实时数据仓库。
image.png
中台组织架构
image.png
image.png
数据中台建设内容
1.技术体系
技术体系分两个层面：大数据存储计算技术和数据中台工具技术组件，
技术体系主要关注点是工具技术组件。大数据存储计算技术，比如
Hadoop、Spark、Flink、Greenplum、Elasticsearch、Redis、Phoenix等，
相对标准，企业只需要进行合理选型即可，并不需要自己建设，而且技
术难度很大，企业也不太可能自己建设。数据中台工具技术组件包括数
据汇聚、数据开发、数据资产管理、数据服务管控等。数据中台是企业
制定和实施数据汇聚、建模和加工规范的场所，也是企业数据体系存储
管理的工具平台。通过工具化、产品化、可视化降低技术门槛，让数据
能够被更方便地加工使用。
2.数据体系
数据体系是数据中台建设、管理、使用的核心要素， 全企业的数据通
过各种方式汇聚到数据中台，在数据中台按照一定的建模方式进行加
工，形成企业的数据资产体系。数据中台始终围绕着数据体系的建设和
使用，让数据体系尽可能完整、准确、使用广泛。不同企业的业务不
同、数据不同，数据体系的内容不同，但是建设的方法和对工具的要求
是相似的，需要在中台工具和建设方法的基础上针对不同的企业建设不
同的数据体系。
-
服务体系
数据中台与大数据平台的最主要区别是数据能更方便地以服务化的方式
支撑业务，而这是通过数据中台服务体系实现的。服务体系是通过数据
中台的服务组件能力， 把数据变为一种服务能力，比如客户微观画像
服务、信用评估服务、风险预警服务等，让数据能够方便地参与到业务
中并为业务带去价值。笔者经常听到的数字化转型、数据化经营，就是
让业务决策通过数据而不是仅凭经验，需要的正是数据服务能力。每家
企业的业务不同，对数据服务的诉求也不同，数据中台无法产品化地提
供企业所需的所有数据服务能力。数据中台通过提供数据服务生成、发
布、监控、管理功能，帮助企业逐个建立属于自己的每一个数据服务，
逐步完成企业数据服务体系的构建。
4.运营体系
运营体系是数据中台得以健康、持续运转的基础。 运营体系包括平台
流程规范执行监督、平台资源占用的监管及优化推动、数据质量的监督
及改进推动、数据价值的评估、数据服务的推广、稽查排名等。其目标
是让平台可以持续健康运转，产生持续价值。数据中台是个复杂工程，
数据的汇聚、开发、管理、服务都是要持续进行的工作，如果没有运营
体系的保障，可能会导致后期的参与者无从下手，随着时间的推移，数
据的质量、服务的效率也会持续下降，进而导致中台无法使用。数据中
台是一个持续的过程，一旦启动，就不能暂停，更不能停止，而保障数
据中台持续高效运转的就是这套运营体系。
关键步骤
数据中台总体架构
数据中台建设的四个阶段
不同行业的数据中台需求特征
金融行业需求特征
image.png
image.png
image.png
数据埋点
用户行为采集
- 客户端埋点
常见的客户端埋点方式有三种：全埋点、可视化埋点和代码埋点。这三
种方式的应用场景企业可根据自身需求进行选择。
全埋点：将终端设备上用户的所有操作和内容都记录并保存下来，只
需要对内嵌SDK做一些初始配置就可以实现收集全部行为的目的。这也
经常被称为无痕埋点、无埋点等。
可视化埋点：将终端设备上用户的一部分操作，通过服务端配置的方
式有选择性地记录并保存。
代码埋点：根据需求来定制每次的收集内容，需要对相应的终端模块
进行升级。
全埋点适合于终端设计标准化且有统一系统接口的情形，用户在终端上
的操作，通过系统提供的事件捕获机制，在对象事件发生时调用埋点工
具中的指定处理逻辑，对该事件相关的信息进行记录。这种方法的优点
是不用频繁升级，一次性验证并发布后，就可以获取终端的全量行为数
据。当突然发现需要对某个对象做分析时，可以直接从历史数据中找到
所需的数据，不需要再次进行数据收集。缺点是数据存储、传输的成本
会高一些，有些当前不用的数据也需要保留。
可视化埋点适合于需要考虑存储和带宽成本的情形，可通过后端配置来
降低对象事件行为采集数量，实现机制和全埋点类似。其优点是发布后
不需要频繁升级，成本比全埋点低，并且能够灵活配置；缺点是当需要
对某一个对象进行分析，但发现其数据没有被采集时，需要重新配置并
等数据采集完成再进行后续工作，容易影响业务进度。
代码埋点主要适合于终端设计非标准化、事件行为需要通过代码来控制
的情形。其优点是灵活性强，针对复杂场景可以单独设计方案，对存
储、带宽等可以做较多的优化；缺点是成本高，维护难度大，升级周期
较长。
数据汇集工具
- canal
Canal Server模拟MySQL Slave的交互协议，伪装自己为MySQL的Slave
向Master发送dump协议，Master收到请求后开始推送binary log，Canal
解析byte流产出解析后的增量数据。主要优点是流程架构非常清晰，部
署和配置等相对简单，同时可以额外做一些配置管理、开发改造的工
作。Canal的主要缺点是Server中的Instance和Client之间是一对一的消
费，不太适用于多消费和数据分发的场景 - Sqoop
Sqoop是目前市面上相对通用的一种解决方案，是在结构化数据和HDFS之间进行批量数据迁移的工具。整体框架以Hadoop为核心，底层使用MapReduce程序实现，MapReduce天生的特性保证了并行化和高容错率，任务运行在Hadoop集群上，减少了服务器资源的使用情况。其主要优势是，在特定场景下，数据交换过程会有很大的性能提升。主要缺点是，处理过程定制程度较高，目前主要通过在命令行中配置参数来调整数据同步操作行为，在用户的一些自定义逻辑和数据同步链路监控方面比较薄弱。除此之外，任务运行完全依赖于MapReduce，功能扩展性方面受到比较明显的约束和限制。
3 Datax
DataX是阿里巴巴开源的一套插件式离线数据交换工具，以实现各种异构数据源之间的高效数据交换为目标而设计，提供数据交换作业全链路的流量监控，将作业本身的状态、数据流量、数据速度、执行进度等信息进行展示，提供脏数据探测功能，支持传输过程中对传输报错（如类型转换错误）进行策略化处理。由于它是基于进程内读写直连的方式，高并发数据交换场景下对机器内存要求比较高。除此之外，DataX不支持非结构化数据的同步，目前支持结构化数据源、半结构化数据源、非结构化数据源，但是非结构化数据源中需要存储的是一张逻辑意义上的二维表，例如CSV格式的文本信息，本质上还是结构化数据。
数据交换产品
企业信息化建设的多种数据源类型，可以通过同步模块的数据源进行统一管理，方便用户快速通过可视化页面执行数据汇聚工作。
在构建数据交换中心的实践过程中，基于异构数据源、异构厂商集群、数据应用时效性和相关技术栈等因素考虑，采取了不同的同步策略：离线数据同步和实时数据同步。同时，在两种同步服务的产品形态上，可以采用相同的可视化同步配置策略，以降低用户操作成本
数据交换产品
- 数据源管理
数据源分类:
关系型数据库：如Oracle、MySQL、SQL Server、Greenplum等。
NoSQL存储：如HBase、Redis、Elasticsearch、Cassandra、MongoDB、
Neo4J等。
网络及MQ：如Kafka、HTTP等。
文件系统：如HDFS、FTP、OSS、CSV、TXT、Excel等。
大数据相关：如Hive、Impala、Kudu、MaxCompute、ADB、LibrA、
ELK等。 -
离线数据交换
离线数据交换是针对数据时效要求低、吞吐量大的场景，解决大规模数
据的批量迁移问题，其实现原理是将不同数据源的交换抽象为从源头数
据源读取数据的读取插件，以及向目标端写入数据的写入插件，理论上
可以支持任意类型数据源的数据交换工作。采用插件化方式构建，将数
据源读取和写入抽象成读取插件、写入插件。
非结构化的数据也可以通过扩展插件方式进行交换，其场景主要是以文
件或数据块的方式进行交换，因此只需要适配源或目的存储的相应插件
及数据处理的机制，如文件传输，数据块保存为特定格式的文件，即可
以满足相应的需求。
·读取插件：数据采集模块，负责采集数据源的数据，将数据发送给数
据交换核心模块。
·写入插件：数据写入模块，不断从数据交换核心模块取数据，并将数
据写入到目的端
数据交换核心模块：用于连接读取插件和写入插件，作为两者的数据
传输通道，并处理缓冲、流控、并发、数据转换等核心技术问题。
离线数据同步技术具有以下亮点：
（1）前置稽核
在源端数据同步开始前，可以进行数据质量规则校验，根据配置规则的
阻塞、告警等策略控制数据同步是否运行。
（2）数据转换
数据转换是指将各类非标准数据转换成标准数据格式，并且将转换后的
数据推送到大数据平台指定的位置或库表。在数据同步、传输过程中，
存在用户对于数据传输进行定制化的场景，包括字段截取、替换、编码
转换等操作，可以借助ETL的T过程（Transform）实现。
在配置数据同步作业的字段映射关系时，可以对每个字段定义转换
（Transform）函数，例如字符串截取dx_substr、字符串替换
dx_replace、字符串过滤dx_filter，还支持用户用Groovy自定义转换逻
辑。
（3）跨集群数据同步
由于采用插件化的设计思路，数据同步模块可支持不同集群间的数据同
步。例如，从A集群上把数据同步到B集群上，只需要开发A集群的
Reader和B集群的Writer，便可以新建数据同步作业对数据进行跨集群迁
移。
（4）全量同步
全量数据同步分为表全量同步和库全量同步（整库同步）两种方式。表全量同步每次读取表中全量数据并写入；库全量同步策略是把库中所有表进行数据同步，要求源端和目的端的表名称、结构相同，允许目标表不存在，不存在时自动创建目标表。
（5）增量同步
增量同步分为新增、覆盖和更新三种策略。新增策略主要通过在目的端创建新分区或者直接追加写数据实现。覆盖和更新策略在同步配置时选择唯一键，根据唯一键对比同步中的数据和目的端数据，结合增量策略来判断数据是覆盖还是更新。
3.实时数据交换
实时数据交换主要负责把数据库、日志、爬虫等数据实时接入Kafka、Hive、Oracle等存储中，便于后续进行实时计算或供业务查询分析使用，整体技术架构如图5-2所示。
实时同步有两个核心服务：数据订阅服务（Client Server）、数据消费服务（Consumer Server）。
数据订阅服务主要包含数据的订阅和读取、任务实例的启停控制等功能，Client Server采用插件式设计思路，可以支持扩展不同类型的数据订阅读取。数据消费服务主要包含任务状态控制、数据解析、数据过滤、数据转换、数据写入等功能，通过TCP通信方式和数据订阅方式进行数据读取和传输，经过任务配置的过滤、转换等功能写入到目的端数据源中。数据消费服务也采用插件式设计思路，可以支持目的端扩展不同类型的数据源写入。
5.3 数据存储的选择
将各类数据汇聚后，首先面临的是存储压力，不同类型的数据内容、不同的数据汇聚方式及未来可能的使用场景，对存储的选择也会有较多的考虑。常见的问题有：存储是选择关系型数据库还是大数据相关的技术（Hadoop等）？
现有的存储与新存储之间的关系是什么？
抛开技术指标的维度对比，选择存储时还需要考虑以下几个方面：
数据交换架构
（1）数据规模
当前的数据规模以及未来的数据规模，这取决于对中台的定位及未来的
发展预期，DT时代企业的数据生产方式越来越丰富，数据量越来越
大，选择成本可控且容易扩展的存储是当前比较常见的选择。
（2）数据生产方式
有些数据生产端没有存储，因此会通过实时推送的方式将生产数据按特
定协议和方式进行推送，这类场景要求数据采集时的存储能够满足数据
实时落地的需求。有些目标存储不具备这种高性能落地的能力，因此需
要考虑在数据生产端和目标存储端中间加一个写性能较好的存储。
（3）数据应用方式
数据使用场景决定了数据存储的选型，如离线的数据分析适合非人机交
互的场景，搜索则需要能够快速检查并支持一些关键字和权重处理。这
些能力也需要有特定的存储来支撑。
针对这些复杂的场景，在大规模的数据处理下，任何一个以前认为可以
忽视的小问题都可以被无限放大，因此像以前一样靠一种存储能力解决
所有问题是不太可能的。在建设中台时，需要根据企业自身情况选择合
适的存储组合来满足企业的数据战略和数据应用需求。
1.在线与离线
在线存储是指存储设备和所存储的数据时刻保持“在线”状态，可供用户
随意读取，满足计算平台对数据访问的速度要求，就像PC机中常用的
磁盘存储模式一样。在线存储设备一般为磁盘、磁盘阵列、云存储等。
离线存储是为了对在线存储的数据进行备份，以防范可能发生的数据灾
难。离线存储的数据不会经常被调用，一般也远离系统应用，“离线”生
动地描述了这种存储方式。离线存储介质上的数据在读写时是顺序进行
的。当需要读取数据时，需要把磁带卷到头，再进行定位。当需要对已
写入的数据进行修改时，所有的数据都需要全部进行改写。因此，离线
存储的访问速度慢、效率低。离线存储的典型产品是硬盘、磁带和光盘
等。
2.OLTP与OLAP
OLTP和OLAP是相对传统的术语，但是在大数据时代，它们又有新的使
命。需要强调的是，OLTP和OLAP并不是竞争或者互斥的关系，相反，
它们相互协作，互利共赢，OLTP用于存储和管理日常操作的数据，
OLAP用于分析这些数据
OLAP和OLTP关系
OLTP（On-Line Transaction Processing，联机事务处理）是专注于面向
事务的任务的一类数据处理，通常涉及在数据库中插入、更新或删除少
量数据，主要处理大量用户下的大量事务。一般都是高可用的在线系
统，以小的事务以及小的查询为主，评估其系统的时候，一般看其每秒
执行的事务及查询的数量。在这样的系统中，单个数据库每秒处理的事
务往往超过几百甚至几千个，Select语句的执行量每秒几千甚至几万
个。典型的OLTP系统有电子商务系统、银行、证券等，如美国eBay的
业务数据库就是很典型的OLTP数据库。
OLAP，也叫联机分析处理（On-Line Analytical Processing）系统，有的
时候也叫DSS（决策支持系统），就是我们说的数据仓库。常用于报表
分析场景，相对于OLTP，对准确性（如id-mapping）、事务性和实时性
要求较低。1993年，E.F.Codd认为OLTP已不能满足终端用户对数据库
查询分析的需要，SQL对大型数据库进行的简单查询也不能满足终端用
户分析的要求。用户的决策分析需要对关系数据库进行大量计算才能得
到结果，而查询的结果并不能满足决策者提出的需求。因此，他提出了
多维数据库和多维分析的概念，即OLAP。
OLAP技术主要通过多维的方式来对数据进行分析、查询并生成报表，
它不同于传统的OLTP处理应用。OLTP应用主要是用来完成用户的事务
处理，如民航订票系统和银行的储蓄系统等，通常要进行大量的更新操
作，同时对响应的时间要求比较高。而OLAP系统的应用主要是对用户
当前的数据和历史数据进行分析，帮助市场做决策，制定营销策略，主
要用来执行大量的查询操作，对实时性要求低。表5-1对OLTP与OLAP
进行了比较
OLAP和OLTP对比
- 存储技术
为了应对数据处理的压力，过去十年间，数据处理技术领域有了很多的
创新和发展。除了面向高并发、短事务的OLTP内存数据库外
（Altibase、Timesten），其他的技术创新和产品都是面向数据分析的，
而且是大规模数据分析，也可以说是大数据分析。有的采用
MPP（Massive Parallel Processing，大规模并行处理）架构的数据库集
群，重点面向行业大数据，如Greenplum、LibrA等；有的采用Shared
Nothing架构，通过列存储、粗粒度索引等多项大数据处理技术，再结
合MPP架构高效的分布式计算模式，完成对分析类应用的支撑，运行环
境多为低成本的PC Server，具有高性能和高扩展性的特点；也有采用从
Hadoop技术生态圈中衍生的相关的大数据技术，如HBase等。
第六章 数据开发：数据价值提炼工厂
数据开发产品能力: 离线开发、实时开发、算法开发
数据开发
离线开发主要包括离线数据的加工、发布、运维管理，以及数据分析、数据探索、在线查询和即席分析相关的工作。
实时开发主要涉及数据的实时接入和实时处理，简化流数据的加工处理过程。
算法开发主要提供简单易用的可视化拖曳方式和Notebook方式来实现
数据价值的深度挖掘。
常见的加工场景有离线和实时数仓建设、算法模型训练、数据化运营分析、数据探索等。在这个过程中，通过数据开发套件对大数据的存储和计算能力进行封装，通过产品化的方式让用户更容易地使用大数据。计算能力与上一章提到的存储能力是紧密联系的，数据规模不断增加，除了存储能力需要细分，计算能力也一样需要细分，因此在建设过程中，也需要对不同场景下的计算能力有一定了解
数据计算能力
image.png
（1）批计算
主要用于批量数据的高延时处理场景，如离线数仓的加工、大规模数据
的清洗和挖掘等。目前大多是利用MapReduce、Hive、Spark等计算框架
进行处理，其特点是数据吞吐量大、延时高，适合人机交互少的场景。
（2）流计算
也叫实时流计算，对于数据的加工处理和应用有较强的实效性要求，常
见于监控告警场景，例如实时分析网络事件，当有异常事件发生时能够
及时介入处理。例如，阿里巴巴“双11”的可视化大屏上的数据展现是根
据浏览、交易数据经过实时计算后展现在可视化大屏上的一种应用。这
类场景目前应用较多的计算框架主要有Flink、Spark Streaming和Storm
等。
（3）在线查询
主要用于数据结果的在线查询、条件过滤和筛选等，如数据检索、条件
过滤等。根据不同的场景也会有多种选择，如营销场景对响应延时要求
高的，一般会采集缓存型的存储计算，如Redis、Tair等；对响应延时要
求正常的，可以选择HBase和MySQL等；需要进行条件过滤、检索的，
可以选择Elasticsearch等。企业一般对在线查询的需求比较旺盛，因此
可能会有多套在线计算的能力提供服务。
