大数据平台自建方案

1. 项目概述

1.1 平台意义

在大数据、人工智能快速发展的今天，分析集群逐渐暴露一些问题：

1. 集群的存储的最大容量约为10T，而新采集的数据量会超过这个数据量10倍以上；
2. 数据处理都在单节点上运行，运算能力无法扩展，当复杂查询来临时只能等若干小时；
3. 传统数据架构不支持非结构化数据的存储；
4. 传统数据架构只支持标准的SQL操作，无法支持复杂的批处理和流处理；

为解决以上问题我们决定构建一套新的大数据平台。

1.2 平台建设目标

构建的大数据平台要求：

1. 可以保存百T级的数据
2. 集分布式数据存储和分布式计算于一体
3. 允许横向扩展存储和运算能力
4. 支持复杂的编码或机器学习计算
5. 支持复杂的数据任务调度
6. 安全、可靠

除了在大数据平台本身的硬性需求，我们还希望平台能够支持更优的数据工作流程：

1. 基于推送而不是拉取的数据采集
2. 基于任务调度而非脚本的ETL
3. 易于修改和查询的数据元信息

1.3 平台性能需求

存储

• 可以保存100T的数据
• 可以保存大小为100G的单个文件

运算性能

• 平台最多可以使用不少于350个核进行运算
• 平台最多可以使用不少于2,000G内存进行运算
• 数据查询的所用时间应和数据量呈线性增长

扩展性

• 集群的存储可以较容易的扩展
• 集群的运算资源（CPU核和内存）可以较容易的扩展

稳定性

• 2个节点永久失效不影响数据访问
• 1个机架上的所有节点永久失效不会导致数据丢失

2. 整体架构设计

2.1 整体设计原则

我们选择以Hortonworks公司的HDP开源平台为核心，搭配其他开源组件的整理设计方案。

我们选择开源体系而非商业体系的主要原因是：

• 团队需要理解底层平台，以便于对平台性能有足够的掌控力
• 大数据技术依然处于剧烈变化的年代，我们要保留未来更换一些组件的自由度

架构上我们尽量遵循最简原则，只把最核心最常用的组件包括进“大数据平台”。维持小而稳定的核心组件意味着我们和用户在非核心组件上的选择更自由。

HDP，一个Hadoop为基础的体系，其本身就解决了扩展性和稳定性的许多问题：当我们读写数据时，HDFS本身就有很好的容错机制；当我们调度运算资源时，Yarn本身就解决了任务分布和资源扩展的问题。

2.2 逻辑架构

我们所说的大数据平台不仅包括数据的存储部分，同时也涵盖在其之上的支持数据运算、查询的基础设施，以及对数据、任务、安全、硬件管理的组件。其主要组成部分和实现技术如下图：

3. 平台功能和关键技术

3.1 基于HDP+Ambari的管理平台

HDP是由Hortonworks公司提供的全功能开源Hadoop平台，是一个企业级大数据应用平台。HDP不断更新加入创新技术和产品，同时为整个社区的优秀产品提供接口支持，保证了整个平台产品不被某个开发商或某项技术绑架。

HDP中的Ambari一款开源管理平台，可用于配置、管理、监控和保护HDP。

核心功能

• 系统监控

• 滚动升级

• 配置管理

HDP及核心组件版本

技术选型

业内有多种成熟的大数据平台解决方案，其中最为流行和成熟的包括Cloudera的CDH以及Hortonworks的HDP，而CDH又分为社区版和商业版。

比较几种方案，HDP虽然在商业支持上不及CDH，但是所有组件均为开源，社区活跃。因此，我们选用HDP作为大数据平台的基础解决方案。

3.2 基于HDFS原始数据存储

核心功能

Hadoop分布式文件系统(HDFS)被设计成适合运行在通用硬件上的分布式文件系统。HDFS是一个高度容错性的系统，适合部署在廉价的机器上。HDFS能提供高吞吐量的数据访问，非常适合大规模数据集上的应用。HDFS放宽了一部分POSIX约束，来实现流式读取文件系统数据的目的。

Hive, HBase 大数据存储都基于 HDFS，我们从各种数据源同步至 Hive 中的库表后最终都以文件形式存放在 HDFS 中。

存储规划

集群规划有9个存储节点，其中每个节点除去操作系统盘，分别设置10块3.5T HDD作为数据存储盘，一块3.5T HDD作为日志盘。数据备份选择为3份，因此整个集群的实际数据容量约为100T。

3.3 基于Yarn的资源调度

目前生产系统节点 Spark worker 可用节点为9个，每个节点有48个核，377 GB 内存，累计 432 个核，3,300 GB 内存，这些资源全部通过 Yarn 进行调度。

为了隔离系统风险，我们将计算资源分配到不同的任务队列中：

• dataflow, 35%资源， 数据采集和汇入、ETL
• bi，45%资源，数据查询
• app, 数据应用
• admin, 特殊任务队列
• default, 暂未分类的任务队列

考虑到每日的数据同步任务繁重，通过对历史数据的分析，我们为数据采集分配了35%的资源。平台的重要功能即为事业部提供数据查询服务，查询的数据量多，任务需求紧急，故为其分配至少45%的资源。

3.4 基于Hive的结构化数据存储

核心功能

Hive是建立在 Hadoop 上的数据仓库基础构架。它提供了一系列的工具，可以用来进行数据提取转化加载（ETL），这是一种可以存储、查询和分析存储在 Hadoop 中的大规模数据的机制。Hive 定义了简单的类 SQL查询语言，称为HQL，与标准的SQL语言非常接近。

简单的说，Hive是Hadoop体系中最接近传统数据库存储的组件。

存储格式

平台中的表默认采用ORC（Optimized Row Columnar File）格式的存储方式，这是一种面向大数据场景的列式存储引擎，其具有很高的压缩比例和查询效率。

另外一种常用的存储格式是Parquet，相比之下，ORC在嵌套式数据支持不够完整，但是ORC支持事务，支持ACID操作，因此针对我们常见的使用场景，我们选用了ORC作为默认存储格式。

技术选型

Hive是大数据领域近SQL查询的行业标准，类似的标准还有pig，但Hive的使用更广泛，生态发展也更好。

Hive的执行性能因执行引擎而有很大区别，我们考察了多个流行的查询引擎，包括Impala，Tez，MR，LLAP+Tez。

在综合考虑兼容性、性能和集成难度之后，我们最终选择LLAP+Tez作为新集群的默认查询引擎，测试结果见下文。

查询性能

Hive执行引擎性能测试

3.5 基于NiFi的数据采集体系

核心功能

Apache NiFi的设计目标是自动化系统间的数据流，它的主要功能包括：

• 更加直观的监控和管理数据的流向
• 支持的多种数据源如ftp、kafka、关系型数据库、Hive等，可以适用于大多数接入场景
• 数据自然缓存提高了数据容错性同时易于跟踪和异常定位
• NiFi采用分布式高并发框架，具有很大的数据吞吐量及处理能力
• 为数据自动化接入工作提供安全可靠的处理平台

NiFi可以方便与HDP集成。

物理规划

• 测试节点个：大数据测试环境NiFi节点，为数据流向图的设计提供测试环境

• 生产节点5个：

  • 5个内部节点：为内网数据流提供数据接入平台
  • 1个外部节点：用于公网数据接入
  • 集群的主节点由Zookeeper选举

技术选型

数据工作人员通常会使用Kettle或Sqoop来做汇聚的工作，问题是它们都是基于“脚本拉取数据”的汇聚方式，而不是“数据自动流入”的方式。

NiFi作为一个面向数据流的数据管理平台，相比于kettle面向加载静态数据的缺点，NiFi能够处理实时的数据流，数据的自然缓存能有效的降低数据丢失的风险。NiFi基本涵盖了Sqoop的全部功能，并且提供给了额外的交互界面。我们综合考察了不同ETL工具对数据采集场景的适应性、实时性、并发性等特点，选定了NiFi作为数据采集平台。

3.6 基于Spark大数据运算体系

核心功能

Spark 是一个基于内存的通用分布式计算引擎，通过使用Spark，数据工程师可以快速的写出并发程序并在集群上分布式运行。

选用 Spark 作为我们集群上的分布式计算引擎能够完美地和当前大数据集群进行深度整合并进行复杂而且高效的分析计算，并大大降低研发并行程序的门槛。使用Spark的典型场景如：

• 用户行为数据的清洗及入库
• 智能推荐和文本反垃圾广告
• 客户画像的后端计算引擎

技术选型

• 运算速度快：和 Hadoop 的 MapReduce 相比，Spark 可以让程序在内存中运行时速度提升100倍，或者在磁盘上运行时速度提升10倍
• 开发易用性好：API 同时支持 Java, Scala, Python 和 R 四种编程语言，提供80多种高阶算子构建大规模集群并行计算程序
• 使用通用性强：同时支持 SQL 查询，流数据，机器学习和复杂数据处理，有 Spark Streaming, Spark SQL, Spark MLlib 等附加库支持
• 数据源支持广：可以很好地和 Hadoop 生态系统和数据源（HDFS、Hive、HBase等）进行集成，同时也支持通过 JDBC 读取 SQL Server, MySQL 等传统关系型数据库

比较其他分布式计算引擎，还没有发现能和 Spark 在开发运行效率和生态系统综合指标相媲美的产品。

3.7 基于Rancher的Docker容器集群

核心功能

除了构建大数据的存储与计算平台，我们仍需要开发一些数据产品与应用。我们需要对这一部分服务器硬件资源做有效的管理，否则每个应用和产品都会占用物理机资源。

Rancher是一个开源的企业级全栈化容器部署及管理平台。它提供了网络服务、存储服务、主机管理、负载均衡、防火墙等基础架构服务，并能够使上述服务跨越公有云、私有云、虚拟机、物理机环境运行，真正实现一键式应用部署和管理。此外，Rancher可以与各种CI/CD工具协同工作，可以实现开发、测试、预生产和生产环境的自动部署，提供整体可视化的主机、容器、网络及存储管理，大幅简化开发和运维人员故障排除和生产部署的工作量。

技术选型

docker vs 虚拟化

相比于虚拟化技术，容器化技术拥有更高效的资源利用率，更轻量的部署形式。

而从大数据团队内部考虑，我们没有独立的运维人员但又有各种应用的部署需求，并且需要持续集成的环境支持我们快速迭代，因此，我们选用Docker作为容器化方案。 Rancher vs Kubernetes

除了Rancher之外，Kubernetes也提供了较为完整的容器编排工具和UI，简单比较如下

结合我们的场景，两者功能差距不大，而我们在易用性上更加注重，因此选择Rancher。

3.8 基于Hue的数据访问

核心功能

Hue的核心功能包括

• 提供方便的SQL编辑和执行功能
• 提供简单易用的仪表盘来展示数据
• 提供创建和调度 Oozie 任务的界面

Hue 定位为 Hadoop 平台各组件的 Web UI，可通过浏览器访问大数据集群内部各组件及数据仓库，入口可统一用户认证及鉴权，更容易管理和升级。查询数据时类似于传统数据库的SQL客户端，同时Hue还承担类似于传统架构中Jenkins或Kettle的工作。

尽管大数据集群下其他组件基本都有独立的 Web UI 可用，但使用时难以达到集中鉴权管理和使用上的便利，因此我们最终选用了 Hue 这一目前非常成熟的 Hadoop Web UI.

3.8 其他组件

工作流引擎 Oozie

Apache Oozie是用于调度Apache Hadoop作业的Java应用程序。 Oozie可以将多个作业按顺序组合成一个流程。 它与Hadoop技术栈集成，以YARN为架构中心，并支持查询、ETL等各种作业。 Oozie还可以调度特定于系统的运算作业，如Java程序或shell脚本。

Apache Oozie是一个Hadoop操作工具，它允许集群管理员从多个组件任务中构建复杂的ETL。 这提供了对作业的更好的控制，也使得在预定的时间间隔重复这些作业变得更容易。

Apache Oozie的角色类似于BI工作中常用的Kettle和Talend。典型的使用场景是执行复杂的一系列数据任务，或需要定时/重复执行一些任务。

元数据管理工具 Atlas

Atlas是一套数据治理服务，它帮助企业有效地满足Hadoop中的合规要求，并允许与整个企业数据生态系统进行整合。它的主要功能包括：

• 数据分类，给数据库表标签和注释
• 中心化的数据审计
• 搜索或关联数据，方便用户找到数据

在过去，Atlas所承担的数据管理工作是由一系列的word或excel文档来完成，如数据字典文档。使用Altas，不仅我们可以自动获取数据转移过程信息，也将有统一的地方对元数据进行管理。

因Atlas项目仍处于初级阶段（当前版本0.9)，团队有计划在Atlas之上开发我们急需的功能。

4. 典型平台使用场景

4.1 数据汇聚和采集

一个标准的从数据库采集数据流程如下：

1. 安全部门通知数据部门一个新的数据源的上线或部署
2. 数据部门提供一系列NiFi的处理器（同步、增量、数据结构变更检查等）
3. 启动NiFi处理器

有时数据会以文件方式提供，一个标准的从文件格式采集数据的方案是：

1. 数据提交者将文件放至HDFS指定位置
2. 数据团队提供一系列NiFi的处理器（同步、增量、数据结构变更检查等）
3. 启动NiFi处理器

NiFi的处理器有时会需要数据团队来编写，但是大多数情况下使用早已编好的处理器模板即可。 我们现在已提供的处理器模板包括：

• 全量同步数据
• 增量同步数据
• 检查数据表结构变更
• 解析标准的csv

数据采集的过程在一定时间内仍需要人员参与，而不是完全自动的。比如，NiFi需要源的连接信息，工程师有时也需要设置数据增长方式来高效的同步数据。NiFi有友好的界面来管理数据采集任务，但它主要是面向数据运营人员使用的。我们有计划开发更傻瓜式的界面来启动和监控NiFi的工作。

4.2 ETL批量处理数据

ETL标准的做法是在hue中创建一个ozzie的任务并运行，任何数据工程师或分析师都可以在集群上运行Ozzie任务。

数据处理程序可以连接HDFS、Hbase或Hive。集群内的程序将无法访问集群外的数据源，如果需要使用这种数据，需要先把它们同步到集群中来。

数据处理程序的结果可以写到Hive、HDFS或Hbase中，并不能直接写到集群外的数据地址，如外部的一个mysql。如果有这种需求，你需要在一个独立的程序把数据结果同步到集群外部。

4.3 流处理数据

大数据平台的建设目的不仅限于提供查询和分析，更希望在智能应用、实时计算等方面提供支持，因此大数据平台也设计为包含支持面向实时处理的流处理框架。

我们建议数据工程师创建一个Spark程序，打包后从Oozie提交集群运行。

目前比较使用比较广泛的流处理框架如Storm、Spark和Flink。相较而言，Storm完全针对于流式处理设计，对于延迟需求很高的纯粹的流处理工作负载，其可能是最适合的技术。而Spark和Flink均能同时支持批处理和流式处理，不同之处在于Spark基于短批模型来处理流式数据，Flink则是设计了纯粹的流式模型。

考虑平台目前的使用场景，以同时具有批处理和流处理的混合型工作场景居多，而Spark相较Flink更加成熟和稳定，因此，前期选择Spark作为平台的流式处理框架，但保留之后选用其他框架的扩展性。