大数据平台架构与原型实现 数据中台建设实战

2008年，Hadoop成为Apache的项目，以此为开端，大数据技术迎来了十多年的持续发展，其间随着Spark的异军突起，整个大数据生态圈又经历了一次“装备升级”，变得更加完善和强大。在这一进程中，企业数据平台的设计理念也在不断进化，从初的“数据仓库”到后来的“数据湖”，再到今天的“数据中台”，方法论革新的背后是大数据技术的强力支撑。今天，很多企业已经完成了早期对大数据技术的尝试和探索转而进入应用阶段，在实际的工程建设中，IT团队遇到了很多问题和挑战，有的团队在摸索中积累了一些有价值的经验，有的则走了一些弯路，付出了或大或小的代价。

总的来说，大数据的整体架构和工程方案在业界还没有锤炼到像Java社区的企业级应用那样成熟，在Java社区不但有完备的架构理论和模型，更有基于这些理论沉淀下来的标准工程模板，以前有Appfuse，后来有Spring Boot，这些被称为“脚手架”的原型工具极大地方便了Java的企业级应用开发，促进了行业技术架构和工程标准的统一。在大数据领域，开发者们也在迫切地寻求成熟的架构方案和类似于“脚手架”的原型项目帮助他们快速构建自己的企业数据平台，本书就是为这一目标而写作的。

作为本书的作者，我曾经参与过多个大数据平台的设计和开发工作，在长期的工作中积累了一些值得分享的宝贵经验。同时，作为一名坚持在一线编写代码的架构师，我还会在项目初期为团队搭建工程原型，在经过多个项目的优化和提炼之后积累了一套成熟通用的原型方案，本书讲解的原型系统正是由此而来的。它不仅仅是这本书的示例代码，更是一个能应用于实际项目中的“脚手架”，其源代码具有很高的参考性和可移植性，将虚拟的业务逻辑抽离之后能很容易地应用到实际项目中，以帮助团队快速启动开发工作。在本书中我会把大数据平台的架构设计和原型系统的具体实现结合在一起讲解，希望能帮助读者有效地学习大数据平台的设计方法和各项技术。

本书涵盖大数据平台建设的各个重要环节，包括基础设施建设、数据采集、主数据管理、实时计算、批处理与数据仓库、数据存储和作业调度等，每个环节独立成章，每一章会介绍相应主题的架构方案和技术选型，然后结合原型项目讲解具体的实现细节。由于大数据涉及的技术众多，而本书讨论的又是平台级的架构和实现，无法就每一项技术都深入展开，所以本书的读者需要具备一定的大数据知识和技术背景。如果你是一位架构师，这本书可以帮助你提升对大数据平台的整体把控力；如果你是中高级开发人员，建议你选择自己感兴趣的章节深入学习原型项目代码；如果你是企业的CIO或数据团队的负责人，本书的第1、2、4章对于你定制企业数据战略、规划数据平台蓝图及组建数据团队都有重要的参考价值。

本书讲解使用的原型项目已经在GitHub上开源（购买本书后可查看）。它是一个基于Maven构建的多模块项目，每个模块对应大数据平台上的一个重要环节，同时对应本书的一个具体章节，但与很多计算机图书不同的是，这些模块不是琐碎示例代码的集合，而是在一个统一业务背景下分工协作的标准项目，是一个完备的大数据平台原型系统。

后，给购买本书的读者一条诚恳的建议：“Get your hands dirty！代码先行！”这是能学到本书精髓好的方法。

目前，在基于大数据技术的数据中台建设过程中，由于缺乏完备的架构参考和类似于“脚手架”的原型项目，很多IT团队会在工程技术层面上感到无从下手。开发人员迫切地需要设计良好的架构参考和简单易用的原型项目帮助他们快速启动自己的数据中台建设，本书就是为这一目标而写作的。

《大数据平台架构与原型实现：数据中台建设实战》以大数据平台的架构设计为主题，围绕一个2万行源代码的原型项目讲解和演示如何在工程技术层面构建当下流行的数据中台。全书涵盖建设一个企业数据平台所需的各个重要环节，包括基础设施建设、数据采集、主数据管理、实时计算、批处理与数据仓库、数据存储及作业调度，每个环节独立成章，每一章介绍对应主题的架构方案和技术选型，然后结合原型项目讲解具体的实现细节。

如果你是一位架构师，本书可以帮助你提升对大数据平台的整体把控力；如果你是中高级开发人员，建议你选择自己感兴趣的章节深入学习原型项目的代码；如果你是企业的CIO或数据团队的负责人，本书的第1、2、4章对于你定制企业数据中台战略、规划数据平台蓝图及组建数据团队都有重要的参考价值。

耿立超，架构师，14年IT系统开发和架构经验，对大数据、企业级应用架构、SaaS、分布式存储和领域驱动设计有丰富的实践经验，热衷函数式编程。目前负责企业数据中台的架构设计和开发工作，对Hadoop/Spark 生态系统有深入和广泛的了解，参与过Hadoop商业发行版的开发，曾带领团队开发过多个基于大数据技术的企业数据平台，完成包含数据采集、数据仓库、实时处理和数据服务的完整平台建设。

第1章 企业与数据 1 
1.1 数据的价值 3 
1.2 企业的数据应用能力 6 
1.3 企业的数据技术成熟度 12 
1.4 数据团队建设 14 
1.4.1 大数据人才类型 14 
1.4.2 数据团队的组织与管理 20 
1.5 建设数据文化 25 
第2章 聚焦中台 27 
2.1 中台简介 27 
2.2 企业信息系统现状 28 
2.2.1 点对点式的系统集成 29 
2.2.2 重复建设 30 
2.2.3 阻碍业务沉淀与发展 31 
2.3 烟囱架构案例：会员管理 31 
2.4 曾经的“救赎”——SOA 38 
2.5 中台详解 41 
2.5.1 中台架构 42 
2.5.2 中台的技术体系 46 
2.5.3 中台的组织架构 48 
2.5.4 中台不是“银弹” 51 
2.6 数据中台 52 
2.6.1 企业数据资产的现状 53 
2.6.2 数据中台具备的能力 54 
2.6.3 数据中台建设策略 56 
第3章 基础设施 60 
3.1 集群规划 61 
3.1.1 集群规模与节点配置 61 
3.1.2 节点角色分配 63 
3.2 创建实例与组网 65 
3.2.1 登录云控制台 65 
3.2.2 创建专有网络 67 
3.2.3 创建安全组 67 
3.2.4 创建实例 72 
3.2.5 申请弹性公网IP地址 78 
3.3 安装集群 79 
3.3.1 软件清单 79 
3.3.2 环境预配置 80 
3.3.3 安装Redis 86 
3.3.4 安装Galera（MySQL集群） 87 
3.3.5 搭建本地CDH Repository 100 
3.3.6 安装Cloudera Manager Server 103 
3.3.7 安装CDH 110 
3.3.8 高可用配置 114 
3.3.9 安装Spark 2 117 
3.3.10 启用Spark SQL 118 
3.4 安装单节点集群 121 
第4章 架构与原型 122 
4.1 大数据平台架构设计 123 
4.2 原型项目业务背景 127 
4.3 原型项目架构方案 132 
4.4 原型项目工程结构 139 
4.5 部署原型项目 142 
4.5.1 配置服务器 142 
4.5.2 构建与部署 151 
4.5.3 小化增量部署 165 
第5章 数据采集 167 
5.1 技术堆栈与选型 168 
5.2 需求与概要设计 171 
5.3 原型项目设计 173 
5.4 生成dummy数据 174 
5.5 基于Sqoop的批量导入 177 
5.5.1 项目原型 177 
5.5.2 使用Sqoop 180 
5.5.3 增量导入与全量导入 184 
5.6 基于Camel的实时采集 185 
5.6.1 项目原型 186 
5.6.2 基本的数据采集 188 
5.6.3 应对采集作业超时 193 
5.6.4 应对数据延迟就绪 197 
第6章 主数据管理 202 
6.1 主数管理据系统的建设策略 202 
6.2 原型设计 204 
6.3 项目构建与运行 205 
6.4 使用主数据 209 
6.5 围绕主数据进行领域建模 209 
6.6 主数据在内存数据库中的组织粒度 219 
第7章 实时计算 221 
7.1 ETL已死，流计算永存 221 
7.2 技术堆栈与选型 223 
7.2.1 Storm 223 
7.2.2 Spark Streaming 225 
7.2.3 Flink 235 
7.2.4 Kafka Stream 237 
7.2.5 关于选型的考量 238 
7.3 实时计算需求分析 239 
7.4 原型项目介绍与构建 241 
7.5 流计算工程结构 243 
7.6 集成Kafka 245 
7.7 集成HBase 246 
7.8 基于时间窗口的聚合运算 252 
7.9 自定义状态的流 255 
7.10 自定义状态的设计 260 
7.11 Structured Streaming性能相关的参数 263 
第8章 批处理与数据仓库 266 
8.1 大数据与数据仓库 266 
8.2 数据仓库的基本理论 267 
8.2.1 维度和度量 268 
8.2.2 事实表和维度表 268 
8.2.3 维度的基数 269 
8.2.4 Cube和Cuboid 269 
8.2.5 星型模型与雪花模型 269 
8.3 批处理需求分析 271 
8.4 数据仓库架构 272 
8.5 原型项目介绍与构建 277 
8.6 数据仓库工程结构 283 
8.7 临时数据层的设计与构建 285 
8.8 源数据层的设计与构建 286 
8.8.1 数据模型 287 
8.8.2 建表并处理数据 288 
8.8.3 SQL黏合与作业提交 293 
8.8.4 增量导入与全量导入 298 
8.8.5 源数据层的表分区 300 
8.8.6 SRC层数据归档 300 
8.9 明细数据层的设计与构建 301 
8.9.1 数据模型 301 
8.9.2 建表并处理数据 302 
8.9.3 合并增量数据 305 
8.9.4 SQL参数替换 307 
8.10 汇总数据层的设计与构建 309 
8.10.1 数据模型 309 
8.10.2 建表并处理数据 312 
8.10.3 构建维度模型 314 
8.10.4 缓慢变化维度 318 
8.10.5 2型SCD表 320 
8.10.6 生成代理主键 328 
8.10.7 运行示例 329 
8.11 实现UDF 332 
第9章 数据存储 335 
9.1 批处理的数据存储 335 
9.2 NoSQL数据库概览 341 
9.3 HBase与Cassandra 343 
9.4 HBase的Rowkey设计 349 
9.4.1 “热点”问题与应对策略 349 
9.4.2 定长处理 352 
9.4.3 实践 352 
9.5 探索HBase二级索引 356 
第10章 作业调度 364 
10.1 技术堆栈与选型 364 
10.2 需求与概要设计 365 
10.3 工作流的组织策略 366 
10.4 工程结构 370 
10.5 项目构建 372 
10.6 实现工作流 375 
10.7 实现coordinator 381 
10.8 部署与提交工作流 385 
10.9 作业依赖管理 389 
10.9.1 Oozie的作业依赖管理 391 
10.9.2 原型项目中的作业依赖 394

目前，在基于大数据技术的数据中台建设过程中，由于缺乏完备的架构参考和类似于“脚手架”的原型项目，很多IT团队会在工程技术层面上感到无从下手。开发人员迫切地需要设计良好的架构参考和简单易用的原型项目帮助他们快速启动自己的数据中台建设，本书就是为这一目标而写作的。

《大数据平台架构与原型实现：数据中台建设实战》以大数据平台的架构设计为主题，围绕一个2万行源代码的原型项目讲解和演示如何在工程技术层面构建当下流行的数据中台。全书涵盖建设一个企业数据平台所需的各个重要环节，包括基础设施建设、数据采集、主数据管理、实时计算、批处理与数据仓库、数据存储及作业调度，每个环节独立成章，每一章介绍对应主题的架构方案和技术选型，然后结合原型项目讲解具体的实现细节。

如果你是一位架构师，本书可以帮助你提升对大数据平台的整体把控力；如果你是中高级开发人员，建议你选择自己感兴趣的章节深入学习原型项目的代码；如果你是企业的CIO或数据团队的负责人，本书的第1、2、4章对于你定制企业数据中台战略、规划数据平台蓝图及组建数据团队都有重要的参考价值。

耿立超，架构师，14年IT系统开发和架构经验，对大数据、企业级应用架构、SaaS、分布式存储和领域驱动设计有丰富的实践经验，热衷函数式编程。目前负责企业数据中台的架构设计和开发工作，对Hadoop/Spark 生态系统有深入和广泛的了解，参与过Hadoop商业发行版的开发，曾带领团队开发过多个基于大数据技术的企业数据平台，完成包含数据采集、数据仓库、实时处理和数据服务的完整平台建设。

4.3 原型项目架构方案

介绍完原型项目的业务场景之后，接下来就该考虑如何设计原型项目了。尽管原型项目的业务场景可以被设计得足够简单（如果作为一个单纯的系统去开发，只需要非常简单的架构就可以支撑了），但是如前所述，我们设计原型项目的目的并不是实现具体的业务功能，而是在原型项目的开发过程中带领读者广泛和深入地接触大数据平台上的各种技术并进行工程实践，所以我们要构建一个尽可能完善的大数据平台。一个完备的全堆栈大数据平台涵盖数据采集、主数据管理、实时处理、批处理、数据服务和数据展示等若干个重要环节。完备而通用的大数据平台架构参考如图4-5所示。

首先，外部数据需要被数据采集组件采集到大数据平台，然后针对实时处理和批处理分别写入消息队列和分布式文件系统两类不同的存储介质上，因此从一开始，原始数据就冗余了两份，然后在实时处理和批处理两条通道上同时对数据进行一系列的验证、清洗、转换和计算。实时处理的计算结果通常会写入一个NoSQL数据库，以便后续实时查询，批处理的计算结果往往写回分布式文件系统。实时处理和批处理在计算过程中都会用到主数据，批处理可以将主数据系统视为一个数据源，将全部主数据导入大数据平台上使用，这样处理主数据就与处理普通数据无异，架构上无须做改动。但是对于流处理而言，在处理原始数据时需要实时获取主数据，必须要有增强的主数据系统为其提供服务。数据经过处理之后，就需要为外部提供服务了。通俗地说，数据服务就是将处理后的数据提供给请求方，不同的数据供给方式将服务于不同的数据应用。常规的数据服务有：

——将体量较小的结果集同步到传统关系型数据库，供报表工具或各种应用系统随时查询；

——通过构建前端API向前端应用直接提供数据查询服务；

——通过OLAP引擎构建Cube，支持实时的、多维度的即时查询。

后，在数据服务的支撑下，会有一系列的数据可视化工具将数据展示给终端用户。数据可视化工具一般分为两大类：一类是传统的报表工具，另一类是基于Web的页面或移动端App。前者定制灵活，开发效率高，但是实时性较差，后者需要针对性地开发，定制性较差，成本较高，但是实时性好。

总之，一个完整的大数据平台都要有数据采集、数据处理（实时处理和批处理）、数据服务和数据展示环节，而这些环节上都有多种实现技术做支撑。每一种产品或工具又各有差异，所以我们接下来要讨论一下技术选型。不过要事先说明的是，我们以下对于平台各个环节上的技术选型只是简单地给出了终结果，对于更多候选技术的对比和分析会在后续章节中专门展开。

1. 数据采集

数据采集的技术选型主要的考量点是看其支持的数据源种类和协议是否丰富，对接与开发是否便捷。目前业界较为主流的数据采集工具有Flume、Logstash及Kafka Connect等。其实有一个一直被人忽视但却是非常理想的数据采集组件——Apache Camel，它主要应用于企业应用集成领域，也被一些系统作为ESB（企业服务总线）使用，其作用是在应用系统林立的企业IT环境中扮演“万向接头”的角色，让数据和信息在各种不同的系统间平滑地交换和流转。经过多年的积累，Camel已经支持近200种协议或数据源，并且可以完全基于配置实现。我们希望原型项目未来能够对接非常多的数据源，同时尽可能地通过配置去集成数据源并采集数据，避免编写大量的代码，Camel很好地满足了这些需求，所以，看上去选择Camel有一些“非主流”，但实际上这个选型是非常明智的，它特别适合企业平台。当然，作为一个非大数据组件，对于Camel的性能和吞吐量我们要有清醒的认识，这个问题可以通过对数据源进行分组、使用多个Camel实例分区采集数据来解决。

2. 消息队列

消息队列的选型是明朗的，Kafka几乎是的选择，原型项目也不例外。

3. 流处理

流处理和批处理都是业务逻辑集中的地方，也是系统的核心。目前用于流处理的主流技术是Storm和Spark Streaming，对两者进行比较的文章很多，通常认为Storm具有更高的实时性，可以做到亚秒级的延迟，相比之下Spark Streaming的实时性要差一些，因为它以“micro batch”的方式进行流处理，但是依托Spark这个大平台，使用Spark Streaming既统一了技术堆栈，又能与其他Spark组件无缝交互，这使得它越来越流行。鉴于在业务上秒级延迟已经可以满足需求，我们在原型项目上终选择了后者。另外，在写作本书时，Flink在社区的呼声越来越高，在未来有望成为流计算领域的“新王者”。

4. 批处理

传统大数据的离线处理多选择Hive，这在很多项目上被证明是可靠的解决方案。后来随着Spark的不断壮大，Spark SQL的使用越来越广泛，并且Spark SQL完全兼容Hive，这使得迁移工作几乎没有任何障碍。对于复杂的业务逻辑或非结构化数据，在Hadoop平台上一般通过MR编程处理，而在Spark平台上则是通过Spark Core的RDD编程实现的。如今Spark在大数据处理的很多方面已经取代Hadoop成为大数据的技术平台，所以在批处理的技术选型上我们选择了“Spark Core Spark SQL”。

5. 主数据管理

为什么我们要单独把主数据管理列出来讨论呢？实际上在批处理的场景下，主数据和其他数据并没有质的区别，只是经常会被关联查询。但是，对于实时处理情况就完全不同了，实时处理也需要频繁地用到主数据，但却不能长期驻留在流计算节点上，因为流计算只能处理当前流经系统的数据，为此，我们必须构建一个统一的主数据管理模块来为流计算提供主数据服务。当然，如果企业内部已经存在主数据管理系统，也可以在原有系统的基础上进行改造，改造的重点是提供一种高性能、低延时的数据读取能力。一般来说，为常见的做法是将主数据加载到内存数据库Redis中，同时考虑到主数据日常的增删查改等日常维护工作，将高性能、低延时的主数据并入主数据管理系统一起维护是常见的做法。所以主数据管理模块本质上是一个传统的Web应用，可以选择基于Spring-Boot构建，使用MySQL作为后台数据库，使用Redis同步主数据，对外通过Restful API提供主数据供给服务。

6. 数据服务

企业对于数据的需求是非常多样化的，尽管大数据平台提供了一致的、功能强大的数据处理体系，但当数据处理完毕供用户使用时，根据时效性、数据展示方式、用户使用习惯等诸多方面的需求，数据需要能以不同的方式和方法提供出去，这就要求企业的数据服务必须多样化。图4-5中的数据服务部分，给出了三种代表性的服务形态：面向结果集的关系型数据库（报表数据库）、数据API和OLAP引擎。对于批处理而言，虽然外部系统可以通过Hive或Spark SQL提供的JDBC或ODBC驱动获取数据，但是这种数据请求需要被转换为批处理作业去执行，无法满足在线的用户请求，所以批处理的结果一般都会同步到一个关系型数据库上，我们可以称之为报表数据库，通过这个数据库对外提供数据。同时，为了能够让分析人员迅速、一致、交互地从各个方面观察信息，很多企业还会建立自己的OLAP引擎，也就是以Cube