博客虫网站原创博文系列整理--http://blogchong.com 专注于前沿 IT 技术 大数据处理平台架构 作者：博客虫 时间：2014/11/22 文档摘要： 该文档围绕数据平台的架构草图框架进行相关的分析说明，部分写的详细，部分鉴于能力写 的概略点 相关描述： 其他相关文档请参考博客虫网站 http://www.blogchong.com/ 有任何其他想法或者，可以到博客虫留言或者邮件 blogchong@163.com 部分源码文档参考博客虫原创博文，代码获取：https://code.csdn.net/blogchong PDF 文档获取：百度网盘 http://pan.baidu.com/s/1hqePCqw PDF 文档及相关资料下载请到百度文库、新浪微盘搜索 欢迎加入 storm-分布式-IT 技术交流群（191321336，群中有详细的资料），一起讨论技 术，一起分享代码，一起分享设计； 博客虫网站原创博文系列整理--http://blogchong.com 专注于前沿 IT 技术 0 目录 数据平台架构草案 ......................................................................................... 错误！未定义书签。 1 文档说明....................................................................................................................................... 1 2 数据平台概要 ............................................................................................................................... 1 3 数据平台架构分析 ....................................................................................................................... 2 3.1 数据平台架构草图 ............................................................................................................ 2 3.2 数据源生产子系统 ............................................................................................................ 2 3.3 数据加载子系统 ................................................................................................................ 3 3.3.1 数据接入层 ............................................................................................................. 3 3.3.2 实时处理层 ............................................................................................................. 3 3.3.3 数据落地层 ............................................................................................................. 4 3.3.4 系统升级方向 ......................................................................................................... 4 3.4 数据存储子系统 ................................................................................................................ 4 3.5 离线数据处理子系统 ........................................................................................................ 5 3.6 平台元数据管理 ................................................................................................................ 5 4 文档补充....................................................................................................................................... 5 博客虫网站原创博文系列整理--http://blogchong.com 专注于前沿 IT 技术 1 1 文档说明 记得很久以前画过一个架构图，但那个架构图是以实时处理为核心的数据处理架构，并 且那个架构图也比较简单，事实上那个架构正是数据平台架构的一个部分。现在所提供的是 整个数据平台的数据处理架构草图。 2 数据平台概要 该文档以数据平台架构草案为核心，围绕数据的处理流程，设计的一套数据处理方案， 结合了部分实际处理架构，当然部分比较详细，部分鉴于水平问题写的比较概略，欢迎指正。 整体架构分为四个部分，数据源产生子系统、数据加载子系统、数据存储子系统、离线 数据处理子系统。 数据源产生子系统负责整个系统源数据的产生。数据源的生产可能有多钟途径，也可能 是不同格式，这就是需要这个子系统对离散的源数据进行初步的整合，数据格式的初步统一。 数据加载子系统负责数据后期处理的预处理操作。核心部分是实时处理部分，包含的其 他部分例如数据的接入、数据的实时处理、数据的落地接口。该部分是数据的预处理部分， 对于后续的业务处理，不同的数据可能有不同的需求，因此可以对数据进行提前处理，避免 后期业务系统的数据冗杂。并且很多情况下，事实处理的结果就是业务输出所需要的数据。 数据存储子系统顾名思义，主要用于数据的存储。一是源数据的备份，二是预处理结果 的备份，三是离线数据在使用完时备份转存在专门的存储系统中(通用分布式文件系统挂载 接口)，四是作为检索引擎的数据以及索引存储的系统。因此该部分最核心的部分就是以分 布式文件系统为核心的通用存储集群，当然也包括传统的关系型数据库。 离线数据处理子系统负责离线数据的处理，包括了数据分析挖掘、机器学习以及数据检 索部分等等。该部分是最重要也是最复杂的部分，以 hadoop 集群为依托，以 hadoop 组件 为工具进行相应的数据处理，也是最有价值的部分。 博客虫网站原创博文系列整理--http://blogchong.com 专注于前沿 IT 技术 2 3 数据平台架构分析 3.1 数据平台架构草图 元数据 管理(Mysql) Flume集群收集log日志 数据源生产子系统 数据加载子系统 MetaQ 前端业务数据获取API Socket 业务系统数据输出接口 数据写入Socket 数据接入层 数据判别过滤 Storm系统(实时处理层) 数据简约拆分 数据添加合并 时间窗口统计 时间窗口排序 数据分流处理 H D F S / H i v e 数 据 落 地 层 L u c e n e / S o l r R D B M S ( M y s q l ) D F S 数据存储子系统 RDBMS(mysql) 数据存储备份系统 GlusterFS分布式文件系统 Zabbix集群 Puppet集群 CTDB高可用集群 标准共享协议 (SMB/NFS/FTP) ZK集群 离线数据处理子系统 RDBMS HDFS YARN(MR) Hive/i mpala 离线分析挖掘/机器学习 H B a s e Mahout Lucene/Solr全文检索 Sqoop 源数据备份 存储索引 数据类型转换 Z o o k e e p e r 加载数据备份/入库 其 他 业 务 系 统 数据平台架构草图 HTTP服务端 数 据 回 写 业务输出 -- ChongyuanHuang 2014/08/02 图 2.1 数据平台架构草图 该图为数据平台整体系统架构的草图，包含了数据源生产子系统的构成，数据加载子系 统的构成，数据存储子系统的构成以及离线数据处理子系统的构成。 3.2 数据源生产子系统 通常前端业务系统产生的源数据有以下几个特点：数据离散分布在集群中、数据格式多 样化、数据产生方式固定化。 要是单纯以数据接入的效率而言，针对后端提供专门的数据输出接口是最高效的做法。 但是目前大多数前端业务系统都是现成的，而数据平台的处理则是后面的数据处理架构，所 以大部分的情况下都是针对现有数据进行后续处理，这就是为什么说数据产生方式固定化的 原因。所以需要其他方式进行数据的初步处理。 一种很常见并且很实用的数据收集方式就是通过 Flume 集群进行数据收集，之前也说过 大部分前端业务系统的数据都是离散的分布在多台机器上，并且很多都是以数据 log 的形式 存在，而作为 Hadoop 生态集群中的重要组成部分 Flume 则非常适应这种情况。它提供多种 数据接入接口框架，把分散的数据集中起来，统一往后端发布。 还有一种数据的处理方式就是 HTTP 服务代理，这种方式适合数据跨度比较大的情况， 通过 HTTP 进行数据传输，通常不会单独存在。业务前端将数据写入 HTTP 服务端，而后端 则是 HTTP 客户端，通常后端不会直接直接与加载系统相接，而是会接入消息中间件，用于 缓冲数据。 若数据量不大的情况下，可以直接使用 Socket 通信的方式进行数据传输，前端业务系 统只需要将数据写入 Socket 端口，而后端只需要随时将端口监控起来就可以了。 博客虫网站原创博文系列整理--http://blogchong.com 专注于前沿 IT 技术 3 数据源的部分还包括了传统的关系型数据库，因为很多业务原型数据本身就是放在 RDBMS 中，很多情况下都是直接从 RDBMS 中转存到 Hive 中。Hadoop 提供了 Sqoop 进行数 据类型的转换。 3.3 数据加载子系统 数据加载子系统以 Storm 实时处理系统为核心构建。核心功能是从前端业务系统获取数 据源，再经过相应的内存处理之后，向后端业务系统输出。 3.3.1 数据接入层 数据接入层对应数据源生产子系统的几种数据生产方式，例如前端业务系统数据获取 API，针对的是前端业务系统的数据输出接口；从 Socket 端口获取数据，从消息中间件中获 取数据等。 其实针对不同的数据接入方式，就是不同 spout 接口的实现。其中最常见的方式是消息 中间件的接入接口，在这为 MetaqSpout 体现。其实正真来说 Metaq 并不是数据源产生组件， 只是作为数据临时缓冲组件而存在。 引入 Meatq 的原因在 Storm 架构那一章已经解释过了，即简单的说就是提供数据缓冲、 解除数据耦合、增加系统扩展性以及提供各个组件异步运行的机制。其中 Metaq 所需要的 Zookeeper 集群可以与 Storm 集群共用。 3.3.2 实时处理层 这部分是数据的真正实时处理的部分，由 Spout 接入数据之后发布出去，由具体的功能 bolt 订阅，进行相应的处理。 这部分最重要的是各种处理规则的定义，设计各种实时处理模板。如图所示最常见的数 据判断过滤模板，包含单条件、多条件逻辑过滤。条件包含了正则匹配(正则匹配引擎的选 择)、常规匹配，包含范围匹配，多字段匹配等等。这就是考虑到过滤模板的设计。 数据拆分简约模板虽然可能简单，但是实际用处很大，对于前端业务系统接入的数据大 多比较完善，但是针对后端业务处理系统可能不需要这么多属性，简单的来说就是字段。为 了提升后端 HDFS 的数据载入效率，以及节省集群空间，通过数据的简约，保留有效字段是 必须的。 数据的添加合并模板的作用在于流式数据和外部数据的合并，如图 2.1 所示 RDBMS 与 Storm 的虚线反箭头就是一种常见的模式。部分数据需要进一步处理，例如某些字段添加前 缀，方便后端业务系统处理，起前缀之类的合并信息从 RDBMS 中获取。又比如某些数据是 直接入库操作，但字段中并没有主键，为了方便数据入库，需要为数据记录添加一个全局唯 一 ID，那么这部分操作便交由数据添加合并模块来实现。当然，除了上述两种方式还有其 他的一些方式，就不一一叙述了。 时间窗口内统计输出模板，这一处理过程一般很少接 Hadoop 的后端，一般都是直接存 入 mysql( 输出的数据量很小)，更多的是直接作为一种业务输出。典型应用，如网站的 PV/UV 值计算等。 时间窗口内排序模板，对于这一类笔者也不是很熟悉，但数据后端输出通常情况下也是 直接作为业务输出，同上。 博客虫网站原创博文系列整理--http://blogchong.com 专注于前沿 IT 技术 4 3.3.3 数据落地层 在数据经过实时处理之后，进行数据落地处理。而数据落地层的本质是各种数据写入接 口的实现，当然依然属于 bolt 范畴。 很常规的一种是直接入库(RDBMS)，这种处理方式是通常数据量不大，类似统计结果， 排序结果以及过滤结果比较少的情况下，并且后续处理需要通过数据库操作等等。 当数据在预处理之后需要进行常规备份，以便今后查询时，这种情况下需要将数据以文 件的方式保存下来，这就是为何提供 DFS 接口的原因。DFS 接口后端是分布式文件系统提供 的统一命名空间。部分分布式文件系统(排除 HDFS)需要专门的数据接入接口，这种情况下通 过分布式文件系统提供的 API，集成这部分的 bolt 接口即可，例如 TFS、FastDFS 等等；还有 一些分布式文件系统提供了标准的 posix 接口，例如 Lustre、MooseFS 以及当前架构中使用 的 GlusterFS 等，只需要将数据以正常的文件写入方式保存到挂载目录即可。 通过 HDFS 文件系统提供的 API 将数据写入 HDFS 中，这种方式是目前很常见的一种方 式，也是数据分析数据加载到 Hadoop 的一种通用方式。此外在数据导入的同时可能还会涉 及到 Hive 的建表，数据 load 之类的操作。 通过 Lucene 以及 Solr 提供的 API，生成检索的索引文件以及组织好数据格式，若数据量 不是很大可以直接保存到本地，若数据量非常大则可以存入 DFS 提供的挂载目录中。 3.3.4 系统升级方向 首先是解除模块的耦合性，即明确好通用的输入输出，这样能够使模块独立性增强，这 样做的好处就是模块间可以随意的组合，提升了事务处理的复杂度，减少了后续功能开发的 成本。 因为通常情况下业务数据处理可能在大多数情况下都需要几种不同的处理方案，因此我 们只需要将不同的 Spout 模块，实时处理 Bolt 模块，数据落地 Bolt 模块实现，根据不同的 业务需求进行模块组合即可。这种情况下可以将多个模块一起打包到 JAR 中，通过配置文件 来实现不同功能的组合，减少了重复打包的过程。 系统在线更新，即在维持任务不停止的状态下，更新系统配置，例如过滤条件变更等。 这结合前端类 SQL 语言的实现，将 SQL 语句转换成底层模块功能组合，并且综合在线更新 的能力将任务变更。 3.4 数据存储子系统 数据存储子系统负责相关数据的存储，该部分 RDBMS 部分略过不讲，重点在于数据备 份系统的实现架构。 存储子系统的设计一是对于源数据的备份，二是预处理之后的数据备份，离线数据在使 用完之后的备份，检索引擎的数据以及索引存储。 存储备份系统最低层支持为 GlusterFS 分布式文件系统，上层辅 Zabbix 监控集群、Puppet 集群配置管理集群、再上层则是 CTDB 高可用集群，以标准共享协议 SMB、NFS 以及 FTP 的 方式将统一命名空间共享出去，提供一个超大容量的存储空间，满足大批量数据备份存储的 需求。 博客虫网站原创博文系列整理--http://blogchong.com 专注于前沿 IT 技术 5 3.5 离线数据处理子系统 该部分以数据的分析挖掘为目的，以 Hadoop 生态环境的部分组件为核心构建。 好吧，这部分个人除了对基础平台(HDFS、YARN、ZK)以及 Hive 比较熟悉，其他只是停 留在原理层。 这部分的数据来源一部分是从 storm 接入，一部分是 RDBMS 的转换数据。通过 sqoop 直接将数据库中的数据导入 Hive 中。 Hive 的数据实际存储在 HDFS 中，只是通过关系型数据库(通常是 mysql)来组织数据的格 式，即 Hive 的元数据组成部分。Hive 提供类 SQL 查询语句，查询的过程由 Hive 本身转化为 MapReduce 任务，大大的减少了开发量，开发成本比较低。 特色在于支持海量数据的查询以及 ETL 操作，并且在扩展性，数据安全性方面与 HDFS 同步(本身数据就存储在 HDFS 中)。是目前数据统计分析的最常见的工具。 至于 Hadoop 生态环境中的其他组件笔者就不献丑了，也希望有高手能够指点一二。 3.6 平台元数据管理 数据平台元数据管理器的设计是整个数据平台的重要组成部分。如图 2.3 所示，元数据 管理器关系着每一个子系统。 元数据管理器的本质是一个 mysql 数据库，其存储了整个数据平台中流通的数据的描述 信息，可以称之为元数据。 我们可以将某一时刻，某一种加载到生产源的数据看成一张表，直观的来说就是元数据 管理器中保存着数据表的表名(数据的多样化，不止一张表)，字段属性，甚至是操作流程。 我们从数据的产生开始来讲述一下元数据管理器的重要性。 数据在决定接入数据平台的时候就决定了他的处理流程，所以我们很方便的在元数据中 定义其执行流程。 一类数据在使用某种方式产生之前，就生成初始状态的元数据表信息，主要包括表名(一 类数据的判别)，字段数，每个字段属性，甚至包括实时处理需求。数据生产依据元数据中 的信息，指导数据的生产方式。 加载子系统从元数据中获取实时处理任务，随即根据任务组合功能模块，包括定义数据 接入方式(Socket、Metaq、API 等)，组合实时处理模块(功能叠加)，定义数据不同处理方式 对应不同的数据落地方式。 往细一步描述即例如，实时处理时，需要针对某个模块进行过滤，简约以及统计(包括 时间窗口初始化)；Hive 建表需要的表名，以及实时处理过后的字段类型及个数；Lucene/Solr 创建索引时所需要的字段信息；存储到分布式文件系统时数据的划分，文件大小等等，都需 要通过元数据管理器来协调统一。 这是一个相当繁琐又及其重要的组成部分。如图所示，该架构中元数据管理器存储的元 数据量不大，所以使用常见的关系型数据库 Mysql 来构建元数据管理器。 4 文档补充 该文档的主旨在于讲述整个数据平台的架构构建，部分地方例如 Mahout、Sqoop、HBase 等相关略微粗糙。 申明笔者水平有限，可能多有纰漏之处，欢迎指正说明。