描述
开 本: 16开纸 张: 胶版纸包 装: 平装-胶订是否套装: 否国际标准书号ISBN: 9787121390449
★ 数据中台建设工程实战 首著
★ 大数据平台建设脚手架 首著
★ 涵盖建设一个企业数据平台所需各个重要环节
★ 不仅有架构方案、技术选型，还有实现细节
★ 更有作者14年相关从业经验的总结
★ 以及长达3年的对本书内容的雕琢
★ 书中的知识和见解可以复用于很多企业
★ 丰富翔实的原型系统代码是一份宝贵的“礼物”
★ 这是一本多年大数据平台建设的总结之作
★ 也是一本数据中台工程建设实践指导之作
★ 可以说是整个数据行业的“宝贵财富”
★ 不同的读者都将从本书中获益匪浅
★ 架构师：可提升对大数据平台的整体把控力
★ 中高级开发人员：可深入学习原型项目代码
★ CIO或数据团队的负责人：可参考数据中台战略、规划数据平台蓝图及组建数据团队
目前，在基于大数据技术的数据中台建设过程中，由于缺乏完备的架构参考和类似于“脚手架”的原型项目，很多IT团队会在工程技术层面上感到无从下手。开发人员迫切地需要设计良好的架构参考和简单易用的原型项目帮助他们快速启动自己的数据中台建设，本书就是为这一目标而写作的。
《大数据平台架构与原型实现：数据中台建设实战》以大数据平台的架构设计为主题，围绕一个2万行源代码的原型项目讲解和演示如何在工程技术层面构建当下流行的数据中台。全书涵盖建设一个企业数据平台所需的各个重要环节，包括基础设施建设、数据采集、主数据管理、实时计算、批处理与数据仓库、数据存储及作业调度，每个环节独立成章，每一章介绍对应主题的架构方案和技术选型，然后结合原型项目讲解具体的实现细节。
如果你是一位架构师，本书可以帮助你提升对大数据平台的整体把控力；如果你是中高级开发人员，建议你选择自己感兴趣的章节深入学习原型项目的代码；如果你是企业的CIO或数据团队的负责人，本书的第1、2、4章对于你定制企业数据中台战略、规划数据平台蓝图及组建数据团队都有重要的参考价值。
第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
2008年，Hadoop成为Apache的顶级项目，以此为开端，大数据技术迎来了十多年的持续发展，其间随着Spark的异军突起，整个大数据生态圈又经历了一次“装备升级”，变得更加完善和强大。在这一进程中，企业数据平台的设计理念也在不断进化，从最初的“数据仓库”到后来的“数据湖”，再到今天的“数据中台”，方法论革新的背后是大数据技术的强力支撑。今天，很多企业已经完成了早期对大数据技术的尝试和探索转而进入应用阶段，在实际的工程建设中，IT团队遇到了很多问题和挑战，有的团队在摸索中积累了一些有价值的经验，有的则走了一些弯路，付出了或大或小的代价。
总的来说，大数据的整体架构和工程方案在业界还没有锤炼到像Java社区的企业级应用那样成熟，在Java社区不但有完备的架构理论和模型，更有基于这些理论沉淀下来的标准工程模板，以前有Appfuse，后来有Spring Boot，这些被称为“脚手架”的原型工具极大地方便了Java的企业级应用开发，促进了行业技术架构和工程标准的统一。在大数据领域，开发者们也在迫切地寻求成熟的架构方案和类似于“脚手架”的原型项目帮助他们快速构建自己的企业数据平台，本书就是为这一目标而写作的。
作为本书的作者，我曾经参与过多个大数据平台的设计和开发工作，在长期的工作中积累了一些值得分享的宝贵经验。同时，作为一名坚持在一线编写代码的架构师，我还会在项目初期为团队搭建工程原型，在经过多个项目的优化和提炼之后积累了一套成熟通用的原型方案，本书讲解的原型系统正是由此而来的。它不仅仅是这本书的示例代码，更是一个能应用于实际项目中的“脚手架”，其源代码具有很高的参考性和可移植性，将虚拟的业务逻辑抽离之后能很容易地应用到实际项目中，以帮助团队快速启动开发工作。在本书中我会把大数据平台的架构设计和原型系统的具体实现结合在一起讲解，希望能帮助读者有效地学习大数据平台的设计方法和各项技术。
本书涵盖大数据平台建设的各个重要环节，包括基础设施建设、数据采集、主数据管理、实时计算、批处理与数据仓库、数据存储和作业调度等，每个环节独立成章，每一章会介绍相应主题的架构方案和技术选型，然后结合原型项目讲解具体的实现细节。由于大数据涉及的技术众多，而本书讨论的又是平台级的架构和实现，无法就每一项技术都深入展开，所以本书的读者需要具备一定的大数据知识和技术背景。如果你是一位架构师，这本书可以帮助你提升对大数据平台的整体把控力；如果你是中高级开发人员，建议你选择自己感兴趣的章节深入学习原型项目代码；如果你是企业的CIO或数据团队的负责人，本书的第1、2、4章对于你定制企业数据战略、规划数据平台蓝图及组建数据团队都有重要的参考价值。
本书讲解使用的原型项目已经在GitHub上开源（购买本书后可查看）。它是一个基于Maven构建的多模块项目，每个模块对应大数据平台上的一个重要环节，同时对应本书的一个具体章节，但与很多计算机图书不同的是，这些模块不是琐碎示例代码的集合，而是在一个统一业务背景下分工协作的标准项目，是一个完备的大数据平台原型系统。
最后，给购买本书的读者一条诚恳的建议：“Get your hands dirty！代码先行！”这是能学到本书精髓最好的方法。
这本书的架构理论、方案和一些重要建议都经过了实践检验，并取得了良好的效果，我相信书中的知识和见解可以复用于很多企业，帮助他们打破信息孤岛，将线上与线下渠道连接在一起，为消费者提供更佳的用户体验，并帮助企业在激烈的市场竞争中迅速而敏捷地捕捉商机。
——欧莱雅集团亚太区首席信息官 Rita Lau
本书涵盖了大数据平台建设的全部环节，通读下来，整体上实操性很强，架构原理融于了工程原型的搭建过程，对于希望自己动手实践的读者会很有帮助，同时在操作步骤中介绍了相应的逻辑及设计，有利于读者更好地领会背后的原理。在今天这个时代，我们不见得要自己搭建整个平台，但是了解原理可以让自己工作起来事半功倍，不管是自己搭建，还是利用成熟平台，懂得理论，明白实践，再开始在企业中搭建数据驱动内部经营的完善体系就会胸有成竹、游刃有余。
——彩食鲜CTO、鲲鹏会荣誉导师、苏宁科技集团原副总裁 乔新亮
这本书的理论基础扎实，架构方案完备，更难能可贵的是它还有丰富翔实的原型系统代码供读者参考和学习，这对很多读者来说是一份宝贵的“礼物”，而作为企业的CTO，这本书给我的惊喜除技术外，它还对企业的数据战略和中台架构做了精彩的论述，对很多企业构建数据中台都有指导意义。这是一本很有诚意、干货满满的书，不仅对程序员、架构师有帮助，也适合CIO、CTO参考。
——华住集团技术副总裁及盟广CTO 王晓光
数据中台的概念满天飞，但是数据中台的落地始终是一个难点，很难统一。将数据中台的核心通用组件抽象出来，一步步地指导企业如何去构建，这会是数据中台领域的下一个课题。这本书率先在这一方向上进行了系统阐述，它从数据中台的概念出发，快速落地到实践指导层面，讲解如何从零开始构建数据中台的核心组件。这是一本靠“坚实的”实践积累出来的好书！
——精益数据体系创始人、ThoughtWorks数据智能总经理 史凯
在进行各类数据分析时，都离不开强大而完善的大数据平台。然而常规的IT数据团队对于业务方的需求及数据应用不甚了解，这本书对数据工程师有很大的参考价值，可以帮助他们对大数据平台有一个全面的认识，了解数据从获取到产出为分析结果这一过程中发生的事情，以便更好地与业务部门协作，实现大数据赋能。
——欧莱雅（中国）有限公司大众化妆品部大数据总监 唐雯
本书作者曾经分享过很多在中台系统落地过程中遇到的问题及解决方案，这些在我们搭建营销相关的业务中台过程中很有启示作用。在每日千万级交易数据的中台建设过程中，我们深刻地体会到数据中台在数据驱动创新方面的价值。本书详细介绍了数据中台的技术选型和架构方案，以及落地过程中的一些关键要素。希望本书能够帮助读者快速搭建自己企业的数据中台，为业务发展助力。
——饿了么营销中台架构师 宋艳飞
本书作者是一位深耕于大数据领域，并一直奋战在一线编写代码的架构师，作者凭借自身十多年的设计和研发经验，归纳总结出了这本通俗易懂的大数据架构和技术书籍。内容从企业数据战略规划到架构方案设计与技术选型，并从开发人员的实际需要出发给出了详细的工程代码，可以说，从理论到实战都进行了专业而细致的讲解。
——埃森哲（中国）有限公司技术架构经理 张俊
这是一本富有实战色彩的大数据新作，汇聚了作者宝贵的经验与独到的观点。本书涵盖的知识与内容非常丰富，并呈纵深化结构，除技术内容外，还包括与大数据平台配套的人才能力、组织架构与管理方法论，适合不同级别的读者。
——希尔顿酒店集团亚太区数据保护官、国际信息隐私专家协会上海分会前主席 李宵声
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模型对数据进行建模，提供多维度、实时的分析能力，在大数据平台上也有相对成熟的OLAP产品，如Kylin。对于实时处理来说，处理结果一般会写入一个NoSQL数据库，目前能够存储大体量数据的主流NoSQL数据库有HBase、Cassandra和MongoDB，我们的原型项目选择的是HBase。NoSQL数据库相较于Hive或Spark SQL具备完全的时实访问能力，但不一定有面向应用的成熟的API接口，所以可以基于Web应用技术搭建一个数据访问服务，这个服务通过NoSQL提供的客户端类库访问数据库，然后对外暴露Restful API。
7. 数据展示
数据展示有很多技术可以实现，BI报表可以使用Tableau或Qlik Sense，Web页面上可以使用D3.js、Echarts等JavaScript图形库，但这已经不是我们原型项目的重点了，本书不做过多讨论。
综上所述，基于前面的系统架构，本书推荐的技术堆栈如图4-6所示。
限于本书的篇幅和定位，我们不对数据服务和数据展示做深入探讨，原型项目也没有配套的实现模块，我们将集中精力处理数据采集、主数据管理、流处理、批处理和作业调度这几个环节。另外，考虑到有的系统可能只会建设批处理这一条管道，并且企业内部绝大多数的数据源以关系型数据库为主，原型项目也为批处理单独配备了一个基于Sqoop的采集模块，从而便于全面介绍数据导入技术，并尽可能地让原型项目便于拆分和组合。所以，本书的原型项目最终呈现的架构如图4-7所示。
评论
还没有评论。