目录

数据平台架构草案... 1

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

 

1 文档说明

    记得很久以前画过一个架构图，但那个架构图是以实时处理为核心的数据处理架构，并且那个架构图也比较简单，事实上那个架构正是数据平台架构的一个部分。现在所提供的是整个数据平台的数据处理架构草图。

 

2 数据平台概要

    该文档以数据平台架构草案为核心，围绕数据的处理流程，设计的一套数据处理方案，结合了部分实际处理架构，当然部分比较详细，部分鉴于水平问题写的比较概略，欢迎指正。

    整体架构分为四个部分，数据源产生子系统、数据加载子系统、数据存储子系统、离线数据处理子系统。

    数据源产生子系统负责整个系统源数据的产生。数据源的生产可能有多钟途径，也可能是不同格式，这就是需要这个子系统对离散的源数据进行初步的整合，数据格式的初步统一。

    数据加载子系统负责数据后期处理的预处理操作。核心部分是实时处理部分，包含的其他部分例如数据的接入、数据的实时处理、数据的落地接口。该部分是数据的预处理部分，对于后续的业务处理，不同的数据可能有不同的需求，因此可以对数据进行提前处理，避免后期业务系统的数据冗杂。并且很多情况下，事实处理的结果就是业务输出所需要的数据。

    数据存储子系统顾名思义，主要用于数据的存储。一是源数据的备份，二是预处理结果的备份，三是离线数据在使用完时备份转存在专门的存储系统中(通用分布式文件系统挂载接口)，四是作为检索引擎的数据以及索引存储的系统。因此该部分最核心的部分就是以分布式文件系统为核心的通用存储集群，当然也包括传统的关系型数据库。

    离线数据处理子系统负责离线数据的处理，包括了数据分析挖掘、机器学习以及数据检索部分等等。该部分是最重要也是最复杂的部分，以hadoop集群为依托，以hadoop组件为工具进行相应的数据处理，也是最有价值的部分。

 

3 数据平台架构分析

3.1 数据平台架构草图

http://s4/mw690/002z7kLVgy6KXCk9YUHa3&690

图2.1 数据平台架构草图

    该图为数据平台整体系统架构的草图，包含了数据源生产子系统的构成，数据加载子系统的构成，数据存储子系统的构成以及离线数据处理子系统的构成。

 

3.2 数据源生产子系统

    通常前端业务系统产生的源数据有以下几个特点：数据离散分布在集群中、数据格式多样化、数据产生方式固定化。

    要是单纯以数据接入的效率而言，针对后端提供专门的数据输出接口是最高效的做法。但是目前大多数前端业务系统都是现成的，而数据平台的处理则是后面的数据处理架构，所以大部分的情况下都是针对现有数据进行后续处理，这就是为什么说数据产生方式固定化的原因。所以需要其他方式进行数据的初步处理。

    一种很常见并且很实用的数据收集方式就是通过Flume集群进行数据收集，之前也说过大部分前端业务系统的数据都是离散的分布在多台机器上，并且很多都是以数据log的形式存在，而作为Hadoop生态集群中的重要组成部分Flume则非常适应这种情况。它提供多种数据接入接口框架，把分散的数据集中起来，统一往后端发布。

    还有一种数据的处理方式就是HTTP服务代理，这种方式适合数据跨度比较大的情况，通过HTTP进行数据传输，通常不会单独存在。业务前端将数据写入HTTP服务端，而后端则是HTTP客户端，通常后端不会直接直接与加载系统相接，而是会接入消息中间件，用于缓冲数据。

    若数据量不大的情况下，可以直接使用Socket通信的方式进行数据传输，前端业务系统只需要将数据写入Socket端口，而后端只需要随时将端口监控起来就可以了。

    数据源的部分还包括了传统的关系型数据库，因为很多业务原型数据本身就是放在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值计算等。

    时间窗口内排序模板，对于这一类笔者也不是很熟悉，但数据后端输出通常情况下也是直接作为业务输出，同上。

 

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的方式将统一命名空间共享出去，提供一个超大容量的存储空间，满足大批量数据备份存储的需求。

 

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等相关略微粗糙。

    申明笔者水平有限，可能多有纰漏之处，欢迎指正说明。