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

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所示。