大数据平台架构设计

 

大数据架构

大数据架构，如下图：

1、通过ETL工具将数据源抽取到HDFS存储；

2、通过Hive清洗、处理和计算原始数据；

3、Hive清洗处理后的结果，如果是面向海量数据随机查询场景的可存入Hbase;

4、数据应用从HBase查询数据；

      

       大数据架构实例1，如下图：

大数据架构实例2，如下图：

大数据架构实例3，如下图：

大数据架构实例4，如下图：

大数据架构实例5：

大数据架构实例6：

一、场景

1.数据源主要为 Mysql，希望实时同步 Mysql 数据到大数据集群中（肯定是越快越好）。

2目前每日 20 亿数据，可预见的一段时间后的规模是 100 亿每日以上。

3.能快速地查到最新的数据，这里包含两部分含义：从 Mysql 到大数据集群的速度快、从大数据集群中查询的速度要快。

二、方案选型

遇到这个场景的时候，根据经验我们主要考虑下面两个点：数据抽取引擎和存储引擎。

数据抽取引擎

这里我们主要考虑两种方案：

1.Sqoop 定时抽取 Mysql 数据到 HDFS 中，可以每天全量抽取一份，也可以隔段时间就抽取一份变更的数据。

2.Canal 监听 Mysql 的 binlog 日志，相当于是 Mysql 有一条数据久变动，我们就抽取一条数据过来。

优缺点的对比也很明显：

1.Sqoop 相对比较通用一些，不管是 Mysql 还是 PostgreSql都可以用，而且很成熟。但是实时性较差，每次相当于是启动一个 MR 的任务。

2.Canal 速度很快，但是只能监听 Mysql 的日志。

存储引擎

存储引擎主要考虑 HDFS、Hbase 和 ES。

一般情况下，HDFS 我们尽量都会保存一份。主要纠结的就是 Hbase 和 ES。本来最初是想用 Hbase 来作为实时查询的，但是由于考虑到会有实时检索的需求，就暂定为ES

三、方案设计

最终，我们使用了下面的方案。

1.使用 Canal 来实时监听 Mysql 的数据变动

2.使用 Kafka 作为消息中间件，主要是为了屏蔽数据源的各种变动。比如以后即使用 Flume 了，我们架构也不用大变

3.数据落地，有一份都会落地 HDFS，这里使用 Spark Streaming，算是准实时落地，而且方便加入处理逻辑。在 落地 ES 的时候可以使用 Spark Streaming，也可以使用 Logstach，这个影响不大

 

Hive和Hbase

Hive主要解决海量数据的清洗、处理和计算的问题。严格来说Hive不是数据库，它通过元数据来描述Hdfs上的结构化文本数据，就是定义一张表来描述HDFS上的结构化文本，包括各列数据名称、数据类型等，方便处理数据。当前很多SQL ON Hadoop的计算引擎均用的是hive元数据，如Spark SQL、Impala。

Hive会将SQL翻译为Mapreduce来处理数据，适用于离线的批量数据计算，但仅限于查找和分析，而不是更新、增加和删除。它的底层是MapReduce，MapReduce在实时计算上性能很差。它的做法是把数据文件加载进来作为一个hive内部表或者外部表，让你觉得你的sql操作的是传统的表。但Hive使用load data操作的时候，不管是外部表还是内部表，如果源数据存在于HDFS层，都是数据的移动，即源数据从HDFS存储路径移动到Hive数据仓库默认路径。

Hadoop是hive和hbase的基础，hive依赖hadoop，而hbase仅依赖hadoop的hdfs模块。

Hive适用于离线数据的分析，操作的是通用格式的（如通用的日志文件）、被hadoop管理的数据文件，它支持类sql，比编写MapReduce的java代码来的更加方便，它的定位是数据仓库，存储和分析历史数据
hbase适用于实时计算，采用列式结构的nosql，操作的是自己生成的特殊格式的HFile、被hadoop管理的数据文件，它的定位是数据库，或者叫DBMS

Hive可以直接操作hdfs中的文件作为它的表的数据，也可以使用hbase数据库作为它的表.

 

Hbase主要用于海量明细数据（十亿、百亿）的随机实时查询的问题，如日志明细、交易清单、轨迹行为等。

Hbase基于hdfs实现对分布式数据文件的管理，比如增删改查。也就是说，hbase只是利用hadoop的hdfs帮助其管理数据的持久化文件（HFile），它跟MapReduce没任何关系。hbase的优势在于实时计算，所有实时数据都直接存入hbase中，客户端通过API直接访问hbase，实现实时计算。由于它使用的是nosql，或者说是列式结构，从而提高了查找性能，使其能运用于大数据场景，这是它跟MapReduce的区别。

在Hbase中日志即数据，数据就是日志，他们是一体化的。为什么这么说了，因为Hbase的更新时插入一行，删除也是插入一行，然后打上删除标记，则不就是日志吗？

     在Hbase中，有Memory Store,还有Store File，其实每个Memory Store和每个Store File就是对每个列族附加上一个B+树(有点像Oracle的索引组织表，数据和索引是一体化的)， 也就是图的下面是列族，上面是B+树，当进行数据的查询时，首先会在内存中memory store的B+树中查找，如果找不到，再到Store File中去找。

     如果找的行的数据分散在好几个列族中，那怎么把行的数据找全呢？那就需要找好几个B+树，这样效率就比较低了。所以尽量让每次insert的一行的列族都是稀疏的，只在某一个列族上有值，其他列族没有值，

一，索引不同造成行为的差异。Hbase只能建立一个主键索引，而且之后的数据查询也只能基于该索引进行简单的key-value查询；但是Oracle可以