• 大数据技术框架
• 1. 简介
• 2. Hadoop框架
  • 2.1. Hadoop-MapReduce
    • 2.1.1. 简介：
    • 2.1.2. 特点
    • 2.1.3. 架构
    • 2.1.4. 执行流程：
    • 2.1.5. Wordcount例子
    • 2.1.6. 缺点：
  • 2.2. Yarn
    • 2.2.1. 简介
    • 2.2.2. 架构
    • 2.2.3. 工作流程
    • 2.2.4. 设计目标
  • 2.3. Hadoop-hdfs
    • 2.3.1. 简介：
    • 2.3.2. 设计目标
    • 2.3.3. 不使用场景
    • 2.3.4. 架构设计
    • 2.3.5. Api
• 3. 分布式协调****zookeeper
  • 3.1. 简介
  • 3.2. 特性
  • 3.3. 使用场景
    • 3.3.1. 数据发布****与****订阅
    • 3.3.2. 命名服务
    • 3.3.3. 分布通知/协调
    • 3.3.4. 分布式锁
    • 3.3.5. 集群管理
    • 3.3.6. 分布式队列
  • 3.4. 架构
  • 3.5. 使用
• 4. 数据存储HBASE
  • 4.1. 简介
  • 4.2. HBASE视图
  • 4.3. 特性
  • 4.4. 使用场景
  • 4.5. 架构
• 5. 数据仓库hive
  • 5.1. 简介
  • 5.2. 特性
  • 5.3. 使用场景
  • 5.4. 架构
  • 5.5. 开发常用命令
• 6. 数据处理
  • 6.1. Spark
    • 6.1.1. 简介
    • 6.1.2. 特性
    • 6.1.3. 使用场景
    • 6.1.4. 架构
  • 6.2. Storm
    • 6.2.1. 简介
    • 6.2.2. 特性
    • 6.2.3. 使用场景
    • 6.2.4. 架构
    • 6.2.5. 与****hadoop比较
    • 6.2.6. 与spark比较
• 7. 消息系统kafka
  • 7.1. 简介
  • 7.2. 特性
  • 7.3. 使用场景
  • 7.4. 架构
  • 7.5. Kafka中名词解释
• 8. 数据采集
  • 8.1. Etl介绍
  • 8.2. Elk
    • 8.2.1. 简介
      • 8.2.1.1. Elasticsearch
      • 8.2.1.2. Logstash
      • 8.2.1.3. Kibala
    • 8.2.2. 架构
    • 8.2.3. 使用场景
  • 8.3. Flume
    • 8.3.1. 简介
    • 8.3.2. 特性
    • 8.3.3. 使用场景
    • 8.3.4. 架构
    • 8.3.5. Flume优点

大数据技术框架

1. 简介

大数据技术体系主要涉及方面：数据采集，数据处理，数据存储以及分布式协调服务；

数据采集：etl，kettle，flume

数据处理：离线处理hadoop，实时处理spark、storm、flink

数据存储：HBASE、hdfs。

数据仓库；hive

分布式协调服务：zookeeper

2. Hadoop框架

Hadoop是Apache软件基金会所开发的并行计算框架与分布式文件系统。最核心的模块包括Hadoop Common、HDFS与MapReduce。

2.1. Hadoop-MapReduce

2.1.1. 简介：

MapReduce是由Google在一篇论文中提出并广为流传的。它最早是Google提出的一个软件架构，用于大规模数据集群分布式运算。任务的分解（Map）与结果的汇总（Reduce）是其主要思想。Map就是将一个任务分解成多个任务，Reduce就是将分解后多任务分别处理，并将结果汇总为最终结果。

MapReduce 编程模型：

MapReduce将整个并行计算过程抽象到两个函数：

map（映射）：对一些独立元素组成的列表的每一个元素进行指定的操作，可以高度并行

Reduce（化简）：队一个列表的元素进行合并

一个简单的MapReduce程序只需要指定map()、reduce()、input和output，剩下的事由框架来执行。

2.1.2. 特点

高容错

• 高扩展

• 编程简单

• 适合大数据离线批量处理

2.1.3. 架构

image.png

它主要有以下4个部分组成：

1）Client

2）JobTracker

JobTracke负责资源监控和作业调度。JobTracker 监控所有TaskTracker 与job的健康状况，一旦发现失败，就将相应的任务转移到其他节点；同时，JobTracker 会跟踪任务的执行进度、资源使用量等信息，并将这些信息告诉任务调度器，而调度器会在资源出现空闲时，选择合适的任务使用这些资源。在Hadoop 中，任务调度器是一个可插拔的模块，用户可以根据自己的需要设计相应的调度器。

3）TaskTracker

TaskTracker 会周期性地通过Heartbeat 将本节点上资源的使用情况和任务的运行进度汇报给JobTracker，同时接收JobTracker 发送过来的命令并执行相应的操作（如启动新任务、杀死任务等）。TaskTracker 使用“slot”等量划分本节点上的资源量。“slot”代表计算资源（CPU、内存等）。一个Task 获取到一个slot 后才有机会运行，而Hadoop 调度器的作用就是将各个TaskTracker 上的空闲slot 分配给Task 使用。slot 分为Map slot 和Reduce slot 两种，分别供MapTask 和Reduce Task 使用。TaskTracker 通过slot 数目（可配置参数）限定Task 的并发度。

4）Task

Task 分为Map Task 和Reduce Task 两种，均由TaskTracker 启动。HDFS 以固定大小的block 为基本单位存储数据，而对于MapReduce 而言，其处理单位是split。split 是一个逻辑概念，它只包含一些元数据信息，比如数据起始位置、数据长度、数据所在节点等。它的划分方法完全由用户自己决定。但需要注意的是，split 的多少决定了Map Task 的数目，因为每个split 只会交给一个Map Task 处理。

2.1.4. 执行流程：

Map Task 执行过程如下图 所示。由该图可知，Map Task 先将对应的split 迭代解析成一个个key/value 对，依次调用用户自定义的map() 函数进行处理，最终将临时结果存放到本地磁盘上，其中临时数据被分成若干个partition，每个partition 将被一个Reduce Task 处理。

image.png

Reduce Task 执行过程下图所示。该过程分为三个阶段：

①从远程节点上读取MapTask 中间结果（称为“Shuffle 阶段”）；

②按照key 对key/value 对进行排序（称为“Sort 阶段”）；

③依次读取<key, value list>，调用用户自定义的reduce() 函数处理，并将最终结果存到HDFS 上（称为“Reduce 阶段”）。

image.png

2.1.5. Wordcount例子

image.png

2.1.6. 缺点：

1.JobTracker是MapReduce的集中处理点，存在单点故障。

2.JobTracker完成了太多的任务，造成了过多的资源消耗，当MapReduce Job非常多的时候，会造成很大的内存开销，潜在来说，也增加了JobTracker fail的风险。

3.在TaskTracker端，以MapReduce task的数目作为资源的表示过于简单，没有考虑到CPU内存的占用情况，如果两个大内存消耗的task被调度到了一块，很容易出现OOM。

4.在TaskTracker端，把资源强制划分为Map task slot和reduce task slot，如果当系统中只有map task或者只有reduce task的时候，会造成资源的浪费。

2.2. Yarn

2.2.1. 简介

MapReduce的JobTracker和TaskTracker机制需要大规模的调整来修复它在可扩展性，内存消耗，线程模型，可靠性和性能上的缺陷。

为从根本上解决旧MapReduce框架的性能瓶颈，促进Hadoop框架更长远发展，从0.23.0版本开始，Hadoop的MapReduce框架完全重构，发生了根本的变化。新的Hadoop MapReduce框架命名为MapReduceV2或者叫Yarn。

Yarn中我们把job的概念换成了application，因为在新的Hadoop2.x中，运行的应用不只是MapReduce了，还有可能是其它应用如一个DAG（有向无环图Directed Acyclic Graph，例如storm应用）。Yarn的另一个目标就是拓展Hadoop，使得它不仅仅可以支持MapReduce计算，还能很方便的管理诸如Hive、Hbase、Pig、Spark/Shark等应用。这种新的架构设计能够使得各种类型的应用运行在Hadoop上面，并通过Yarn从系统层面进行统一的管理，也就是说，有了Yarn，各种应用就可以互不干扰的运行在同一个Hadoop系统中，共享整个集群资源

2.2.2. 架构

image.png

从上面的结构图来看，YARN主要的组件包括ResourceManager、NodeManager、ApplicationMaster和Container。

（1）Client向ResourceManager发送请求 （2）ResourceManager指定一个NodeManager启动起ApplicationMaster （3）ApplicationMaster将计算任务反馈给ResourceManager （4）ApplicationMaster将任务分割分发到不同的NodeManager （5）NodeManager启动Task执行work

YARN Client

YARN Client提交Application到RM，它会首先创建一个Application上下文件对象，并设置AM必需的资源请求信息，然后提交到RM。YARN Client也可以与RM通信，获取到一个已经提交并运行的Application的状态信息等，具体详见后面ApplicationClientProtocol协议的分析说明。

ResourceManager（RM）

RM是YARN集群的Master，负责管理整个集群的资源和资源分配。RM作为集群资源的管理和调度的角色，如果存在单点故障，则整个集群的资源都无法使用。在2.4.0版本才新增了RM HA的特性，这样就增加了RM的可用性。

NodeManager（NM）

NM是YARN集群的Slave，是集群中实际拥有实际资源的工作节点。我们提交Job以后，会将组成Job的多个Task调度到对应的NM上进行执行。Hadoop集群中，为了获得分布式计算中的Locality特性，会将DN和NM在同一个节点上运行，这样对应的HDFS上的Block可能就在本地，而无需在网络间进行数据的传输。

Container

Container是YARN集群中资源的抽象，将NM上的资源进行量化，根据需要组装成一个个Container，然后服务于已授权资源的计算任务。计算任务在完成计算后，系统会回收资源，以供后续计算任务申请使用。Container包含两种资源：内存和CPU，后续Hadoop版本可能会增加硬盘、网络等资源。

ApplicationMaster（AM）

AM主要管理和监控部署在YARN集群上的Application，以MapReduce为例，MapReduce Application是一个用来处理MapReduce计算的服务框架程序，为用户编写的MapReduce程序提供运行时支持。通常我们在编写的一个MapReduce程序可能包含多个Map Task或Reduce Task，而各个Task的运行管理与监控都是由这个MapReduce Application来负责，比如运行Task的资源申请，由AM向RM申请；启动/停止NM上某Task的对应的Container，由AM向NM请求来完成。

2.2.3. 工作流程

image.png

客户端向ResourceManager提交应用程序，其中包括ApplicationMaster、启动ApplicationMaster的命令、用户程序等；

ResourceManager为该应用程序分配第一个Container，并与对应NodeManager通信，要求它在这个Container中启动应用程序的ApplicationMaster；

ApplicationMaster向ResourceManager注册自己，启动成功后与ResourceManager保持心跳；

ApplicationMaster向ResourceManager申请资源；

申请资源成功后，由ApplicationMaster进行初始化，然后与NodeManager通信，要求NodeManager启动Container。然后ApplicationMaster与NodeManager保持心跳，从而对NodeManager上运行的任务进行监控和管理；

Container运行期间，向ApplicationMaster汇报自己的进度和状态信息，以便ApplicationMaster掌握任务运行状态，从而在任务失败是可以重新启动；

应用运行结束后，ApplicationMaster向ResourceManager注销自己，允许其所属的Container回收。

2.2.4. 设计目标

Yarn是通用的统一资源管理系统，同时运行长应用程序和短应用程序。长应用程序通常情况下，指永不停止运行的程序service,http server等，短应用程序指短时间（秒级，分钟级，小时级）内会运行结束的程序MR job,Spark Job等。 以Yarn为核心的生态系统也越来越多了：

image.png

2.3. Hadoop-hdfs

2.3.1. 简介：

HDFS即Hadoop Distributed File System分布式文件系统，它的设计目标是把超大数据集存储到分布在网络中的多台普通商用计算机上，并且能够提供高可靠性和高吞吐量的服务。分布式文件系统要比普通磁盘文件系统复杂，因为它要引入网络编程，分布式文件系统要容忍节点故障也是一个很大的挑战。

2.3.2. 设计目标

1. 专为存储超大文件而设计：hdfs应该能够支持GB级别大小的文件；它应该能够提供很大的数据带宽并且能够在集群中拓展到成百上千个节点；它的一个实例应该能够支持千万数量级别的文件。

2. 适用于流式的数据访问：hdfs适用于批处理的情况而不是交互式处理；它的重点是保证高吞吐量而不是低延迟的用户响应

3. 容错性：完善的冗余备份机制

4. 支持简单的一致性模型：HDFS需要支持一次写入多次读取的模型，而且写入过程文件不会经常变化

5. 移动计算优于移动数据：HDFS提供了使应用计算移动到离它最近数据位置的接口

6. 兼容各种硬件和软件平台

2.3.3. 不使用场景

1. 大量小文件：文件的元数据都存储在NameNode内存中，大量小文件会占用大量内存。

2. 低延迟数据访问：hdfs是专门针对高数据吞吐量而设计的

3. 多用户写入，任意修改文件

2.3.4. 架构设计

HDFS中关键组件有两个，一个是NameNode，一个是DataNode。

NameNode负责整个分布式文件系统的元数据（MetaData）管理，也就是文件路径名，数据block的ID以及存储位置等信息，承担着操作系统中文件分配表（FAT）的角色。HDFS为了保证数据的高可用，会将一个block复制为多份（缺省情况为3份），并将三份相同的block存储在不同的服务器上。这样当有磁盘损坏或者某个DataNode服务器宕机导致其存储的block不能访问的时候，Client会查找其备份的block进行访问。

DataNode负责文件数据的存储和读写操作，HDFS将文件数据分割成若干块（block），每个DataNode存储一部分block，这样文件就分布存储在整个HDFS服务器集群中。应用程序客户端（Client）可以并行对这些数据块进行访问，从而使得HDFS可以在服务器集群规模上实现数据并行访问，极大地提高访问速度。实践中HDFS集群的DataNode服务器会有很多台，一般在几百台到几千台这样的规模，每台服务器配有数块磁盘，整个集群的存储容量大概在几PB到数百PB。

image.png

2.3.5. Api

命令：

image.png

查看目录结构及信息：

image.png

Web页面展示

image

3. 分布式协调****zookeeper

3.1. 简介

zookeeper它是一个针对大型应用提供高可用的数据管理、应用程序协调服务的分布式服务框架，基于对Paxos算法的实现，使该框架保证了分布式环境中数据的强一致性，提供的功能包括：配置维护、统一命名服务、状态同步服务、集群管理等。

在分布式应用中，由于工程师不能很好地使用锁机制，以及基于消息的协调机制不适合在某些应用中使用，因此需要有一种可靠的、可扩展的、分布式的、可配置的协调机制来统一系统的状态。Zookeeper的目的就在于此。

3.2. 特性

1 最终一致性：为客户端展示同一视图，这是zookeeper最重要的功能。 2 可靠性：如果消息被到一台服务器接受，那么它将被所有的服务器接受。 3 实时性：Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。 4 等待无关（wait-free）：慢的或者失效的client不干预快速的client的请求。 5 原子性：更新只能成功或者失败，没有中间状态。 6 顺序性：所有Server，同一消息发布顺序一致。

3.3. 使用场景

3.3.1. 数据发布****与****订阅

发布与订阅即所谓的配置管理，顾名思义就是将数据发布到zk节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。例如：全局的配置信息、地址列表等。

3.3.2. 命名服务

这个主要是作为分布式命名服务，通过调用zk的create node api，能够很容易创建一个全局唯一的path，可以将这个path作为一个名称。

3.3.3. 分布通知/协调

ZooKeeper中特有的watcher注册于异步通知机制，能够很好的实现分布式环境下不同系统之间的通知与协调，实现对数据变更的实时处理。使用方法通常是不同系统都对zk上同一个znode进行注册，监听znode的变化（包括znode本身内容及子节点内容），其中一个系统update了znode，那么另一个系统能够收到通知，并做出相应处理。

3.3.4. 分布式锁

分布式锁，主要得益于ZooKeeper保证数据的强一致性，即zk集群中任意节点（一个zk server）上系统znoe的数据一定相同。

锁服务可以分为两类：

保持独占锁：所有试图来获取这个锁的客户端，最终只有一个可以成功获得这把锁。通常的做法是把zk上的一个znode看做是一把锁，通过create znode的方式来实现。所有客户端都去创建/distribute_lock节点，最终成功创建的那个客户端也即拥有了这把锁。

控制时序锁：所有试图来获取这个锁的客户端，最终都是会被安排执行，只是有个全局时序了。与保持独占锁的做法类似，不同点是/distribute_lock已经预先存在，客户端在它下面创建临时有序节点（可以通过节点控制属性控制：CreateMode.EPHEMERAL_SEQUENTIAL来指定）。zk的父节点(/distribute_lock)维持一份sequence，保证子节点创建的时序性，从而形成每个客户端的全局时序。

3.3.5. 集群管理

集群机器监控：这通常用于那种对集群中机器状态、机器在线率有较高要求的场景，能够快速对集群中机器变化做出响应。这样的场景中，往往有一个监控系统，实时监测集群机器是否存活。过去的做法通常是：监控系统通过某种手段（比如ping）定时检测每个机器、或每个机器定时向监控系统发送心跳信息。这种做法存在两个弊端：1.集群中机器有变动的时候，牵连修改的东西比较多。2.有一定的延迟。利用ZooKeeper，可以实现另一种集群机器存活性监控系统：a.客户端在节点x上注册watcher，如果x的子节点发生变化，会通知该客户端。b.创建EPHEMERAL类型的节点，一旦客户端和服务器的会话结束或过期，该节点就会消失。例如：监控系统在/clusterServers节点上注册一个watcher，以后每动态加机器，就往/culsterServer下创建一个EPHEMERAL类型的节点：/clusterServer/{hostname}。这样，监控系统就能实时知道机器的增减情况，至于后续处理就是监控系统的业务了。

Master选举：在分布式环境中，相同的业务应用分布在不同的机器上，有些业务逻辑（例如一些耗时的计算、网络I/O处理），往往需要让整个集群中的某一台机器进行执行，其余机器可以共享这个结果，这样可以减少重复劳动、提高性能。利用ZooKeeper的强一致性，能够保证在分布式高并发情况下节点创建的全局唯一性，即：同时有多个客户端请求创建/currentMaster节点，最终一定只有一个客户端请求能够创建成功。利用这个特性，就能很轻易的在分布式环境中进行集群选取了。另外，这种场景演化一下，就是动态Master选举。这就要用到 EPHEMERAL_SEQUENTIAL类型节点的特性了。上文中提到，所有客户端创建请求，最终只有一个能够创建成功。在这里稍微变化下，就是允许所有请求都能够创建成功，但是得有个创建顺序，于是所有的请求最终在zk上创建结果的一种可能情况是这样： /currentMaster/{sessionId}-1、/currentMaster/{sessionId}-2、/currentMaster/{sessionId}-3……。每次选取序列号最小的那个机器作为Master，如果这个机器挂了，由于他创建的节点会马上消失，那么之后最小的那个机器就是Master了。

3.3.6. 分布式队列

队列方面，有两种方式：一种是常规的先进先出队列，另一种是要等到队列成员聚齐之后的才统一按序执行。

对于先进先出队列，和分布式锁服务中的控制时序场景基本原理一致，这里不再赘述。

第二种队列其实是在FIFO队列的基础上作了一个增强。通常可以在/queue这个znode下预先建立一个/queue/num节点，并且赋值为n（或者直接给/queue赋值n），表示队列大小，之后每次有队列成员加入后，就判断下是否已经到达队列大小，决定是否可以开始执行了。这种用法的典型场景是，分布式环境中，一个大任务Task A，需要在很多子任务完成（或条件就绪）情况下才能进行。这个时候，凡是其中一个子任务完成（就绪），那么就去/taskList下建立自己的临时时序节点（CreateMode.EPHEMERAL_SEQUENTIAL），当/taskList发现自己下面的子节点满足指定个数，就可以进行下一步按序进行处理了。

3.4. 架构

image.png

1 每个Server在内存中存储了一份数据； 2 Zookeeper启动时，将从实例中选举一个leader（Paxos协议）； 3 Leader负责处理数据更新等操作（Zab协议）； 4 一个更新操作成功，当且仅当大多数Server在内存中成功修改数据。

image.png

3.5. 使用

ZooKeeper -server host:port cmd args

stat path [watch]

set path data [version]

ls path [watch]

delquota [-n|-b] path

ls2 path [watch]

setAcl path acl

setquota -n|-b val path

history

redo cmdno

printwatches on|off

delete path [version]

sync path

listquota path

rmr path

get path [watch]

create [-s] [-e] path data acl

addauth scheme auth

quit

getAcl path

close

connect host:port

4. 数据存储HBASE

4.1. 简介

HBASE是建立在hdfs之上，提供高可靠性、高性能、列存储、可伸缩、实时读写的数据库系统。

它介于nosql和RDBMS之间，仅能通过主键(row key)和主键的range来检索数据，仅支持单行事务(可通过hive支持来实现多表join等复杂操作)。主要用来存储非结构化和半结构化的松散数据。

与hadoop一样，Hbase目标主要依靠横向扩展，通过不断增加廉价的商用服务器，来增加计算和存储能力。

4.2. HBASE视图

image.png

4.3. 特性

1、大表：一个表可以有数十亿行，上百万列；

2、无模式：每行都有一个可排序的主键和任意多的列，列可以根据需要动态的增加，同一张表中不同的行可以有截然不同的列；

3、面向列：面向列（族）的存储和权限控制，列（族）独立检索；

4、稀疏：对于空（null）的列，并不占用存储空间，表可以设计的非常稀疏；

5、数据多版本：每个单元中的数据可以有多个版本，默认情况下版本号自动分配，是单元格插入时的时间戳；

6、数据类型单一：Hbase中的数据都是字符串，没有类型。

4.4. 使用场景

HBASE适用场景

1、存在高并发读写

2、表结构的列族经常需要调整

3、存储结构化或半结构化数据

4、高并发的key-value存储

5、key随机写入，有序存储

6、针对每个key保存一个固定大小的集合 多版本

HBASE****数据也存在不适用的场景

1、由于hbase只能提供行锁，它对分布式事务支持不好

2、对于查询操作中的join、group by 性能很差

3、查询如果不使用row-key查询，性能会很差，因为此时会进行全表扫描，建立二级索引或多级索引需要同时维护一张索引表

4、高并发的随机读支持有限

4.5. 架构

image.png

由上图可知，hbase包括Clinet、HMaster、HRegionServer、ZooKeeper组件

各组件功能介绍：

1、Client

Client主要通过ZooKeeper与Hbaser和HRegionServer通信，对于管理操作：client向master发起请求，对于数据读写操作：client向regionserver发起请求

2、ZooKeeper

zk负责存储meta表的地址，也负责存储当前服务的master地址,region server也会将自身的信息注册到zk中，以便master能够感知region server的状态，zk也会协调active master，也就是可以提供一个选举master leader,也会协调各个region server的容灾流程

3、HMaster

master可以启动多个master，master主要负责table和region的管理工作，响应用户对表的CRUD操作，管理region server的负载均衡，调整region 的分布和分配，当region server停机后，负责对失效的regionn进行迁移操作

4、HRegionServer

region server主要负责响应用户的IO请求，并把IO请求转换为读写HDFS的操作

5. 数据仓库hive

5.1. 简介

Hive 是一个基于 Hadoop 文件系统之上的数据仓库架构。它为数据仓库的管理提供了许多功能：数据 ETL （抽取、转换和加载）工具、数据存储管理和大型数据集的查询和分析能力。同时 Hive 还定义了类 SQL的语言 – Hive QL. Hive QL 允许用户进行和 SQL 相似的操作，它可以将结构化的数据文件映射为一张数据库表，并提供简单的 SQL 查询功能。还允许开发人员方便地使用 Mapper 和 Reducer 操作，可以将 SQL 语句转换为 MapReduce 任务运行，这对 MapReduce 框架来说是一个强有力的支持。

5.2. 特性

优点： 1.Hive 使用类SQL 查询语法, 最大限度的实现了和SQL标准的兼容，大大降低了传统数据分析人员学习的曲线； 2.使用JDBC 接口/ODBC接口，开发人员更易开发应用； 3.以MR 作为计算引擎、HDFS 作为存储系统，为超大数据集设计的计算/ 扩展能力； 4.统一的元数据管理（Derby、MySql等），并可与Pig 、Presto 等共享； 缺点： 1.Hive 的HQL 表达的能力有限，有些复杂运算用HQL 不易表达； 2.由于Hive自动生成MapReduce 作业， HQL 调优困难； 3.粒度较粗，可控性差

5.3. 使用场景

Hive 构建在基于静态批处理的 Hadoop 之上，Hadoop 通常都有较高的延迟并且在作业提交和调度的时候需要大量的开销。因此，Hive 不适合在大规模数据集上实现低延迟快速的查询。

Hive 并不适合那些需要低延迟的应用，例如，联机事务处理（OLTP）。Hive 查询操作过程严格遵守 Hadoop MapReduce 的作业执行模型，Hive 将用户的 HiveQL 语句通过解释器转换为 MapReduce 作业提交到 Hadoop 集群上，Hadoop 监控作业执行过程，然后返回作业执行结果给用户。Hive 并非为联机事务处理而设计，Hive 并不提供实时的查询和基于行级的数据更新操作。

Hive 的最佳使用场合是大数据集的批处理作业，例如，网络日志分析。

5.4. 架构

image.png

从图中我们可以看出 Hive 其基本组成可以分为：

1用户接口，包括 CLI, JDBC/ODBC, WebUI

2元数据存储，通常是存储在关系数据库如 MySQL, Derby 中

3解释器、编译器、优化器、执行器

4用 HDFS 进行存储，利用 MapReduce 进行计算

5.5. 开发常用命令

查看所有的数据库：

hive> show databases ;

使用数据库：

hive> use default;

创建表：

image.png

加载数据：

image.png

查看表数据：

image.png

等等

6. 数据处理

6.1. Spark

6.1.1. 简介

1. 什么是Spark？Spark作为Apache顶级的开源项目，是一个快速、通用的大规模数据处理引擎，和Hadoop的MapReduce计算框架类似，但是相对于MapReduce，Spark凭借其可伸缩、基于内存计算等特点，以及可以直接读写Hadoop上任何格式数据的优势，进行批处理时更加高效，并有更低的延迟。相对于“one stack to rule them all”的目标，实际上，Spark已经成为轻量级大数据快速处理的统一平台，各种不同的应用，如实时流处理、机器学习、交互式查询等，都可以通过Spark建立在不同的存储和运行系统上。

2. Spark是基于内存计算的大数据并行计算框架。Spark基于内存计算，提高了在大数据环境下数据处理的实时性，同时保证了高容错性和高可伸缩性，允许用户将Spark部署在大量廉价硬件之上，形成集群。

3. Spark目前，已经成为Apache软件基金会旗下的顶级开源项目。相对于MapReduce上的批量计算、迭代型计算以及基于Hive的SQL查询，Spark可以带来上百倍的性能提升。目前Spark的生态系统日趋完善，Spark SQL的发布、Hive on Spark项目的启动以及大量大数据公司对Spark全栈的支持，让Spark的数据分析范式更加丰富

6.1.2. 特性

基于Hadoop的资源管理器YARN实际上是一个弹性计算平台，作为统一的计算资源管理框架，不仅仅服务于MapReduce计算框架，而且已经实现了多种计算框架进行统一管理。这种共享集群资源的模式带来了很多好处。

1. 快速

Spark有先进的DAG执行引擎，支持循环数据流和内存计算；Spark程序在内存中的运行速度是Hadoop MapReduce运行速度的100倍，在磁盘上的运行速度是Hadoop MapReduce运行速度的10倍。

2. 易用

Spark支持使用Java、Scala、Python语言快速编写应用，提供超过80个高级运算符，使得编写并行应用程序变得容易。

3. 通用

Spark可以与SQL、Streaming以及复杂的分析良好结合。基于Spark，有一系列高级工具，包括Spark SQL、MLlib（机器学习库）、GraphX和Spark Streaming，支持在一个应用中同时使用这些架构。 4. 有效集成Hadoop

Spark可以指定Hadoop，YARN的版本来编译出合适的发行版本，Spark也能够很容易地运行在EC2、Mesos上，或以Standalone模式运行，并从HDFS、HBase、Cassandra和其他Hadoop数据源读取数据。

5.资源利用率高

多种框架共享资源的模式有效解决了由于应用程序数量的不均衡性导致的高峰时段任务比较拥挤，空闲时段任务比较空闲的问题；同时均衡了内存和CPU等资源的利用。

6.实现了数据共享

随着数据量的增加，数据移动成本越来越高，网络带宽、磁盘空间、磁盘IO都会成为瓶颈，在分散数据的情况下，会造成任务执行的成本提高，获得结果的周期变长，而数据共享模式可以让多种框架共享数据和硬件资源，大幅度减少数据分散带来的成本。

7.有效降低运维和管理成本

相比较一种计算框架需要一批维护人员，而运维人员较多又会带来的管理成本的上升；共享模式只需要少数的运维人员和管理人员即可完成多个框架的统一运维管理，便于运维优化和运维管理策略统一执行。

6.1.3. 使用场景

1. 快速查询系统基于日志数据的快速查询系统业务构建于Spark之上，利用其快速查询以及内存表等优势，能够承担大部分日志数据的即时查询工作；在性能方面，普遍比Hive快2～10倍，如果使用内存表的功能，性能将会比Hive快百倍。

2. 实时日志采集处理 通过Spark Streaming实时进行业务日志采集，快速迭代处理，并进行综合分析，能够满足线上系统分析要求。

3. 业务推荐系统 使用Spark将业务推荐系统的小时和天级别的模型训练转变为分钟级别的模型训练，有效优化相关排名、个性化推荐以及热点点击分析等。

4. 定制广告系统 在定制广告业务方面需要大数据做应用分析、效果分析、定向优化等，借助Spark快速迭代的优势，实现了在“数据实时采集、算法实时训练、系统实时预测”的全流程实时并行高维算法，支持上亿的请求量处理；模拟广告投放计算效率高、延迟小，同MapReduce相比延迟至少降低一个数量级。

5. 用户图计算 利用GraphX解决了许多生产问题，包括以下计算场景：基于度分布的中枢节点发现、基于最大连通图的社区发现、基于三角形计数的关系衡量、基于随机游走的用户属性传播等。

6.1.4. 架构

image.png

· Spark Core：包含Spark的基本功能；尤其是定义RDD的API、操作以及这两者上的动作。其他Spark的库都是构建在RDD和Spark Core之上的

· Spark SQL：提供通过Apache Hive的SQL变体Hive查询语言（HiveQL）与Spark进行交互的API。每个数据库表被当做一个RDD，Spark SQL查询被转换为Spark操作。

· Spark Streaming：对实时数据流进行处理和控制。Spark Streaming允许程序能够像普通RDD一样处理实时数据

· MLlib：一个常用机器学习算法库，算法被实现为对RDD的Spark操作。这个库包含可扩展的学习算法，比如分类、回归等需要对大量数据集进行迭代的操作。

· GraphX：控制图、并行图操作和计算的一组算法和工具的集合。GraphX扩展了RDD API，包含控制图、创建子图、访问路径上所有顶点的操作。

6.2. Storm

6.2.1. 简介

Storm是一个免费并开源的分布式实时计算系统。利用Storm可以很容易做到可靠地处理无限的数据流，像Hadoop批量处理大数据一样，Storm可以实时处理数据。Storm简单，可以使用任何编程语言。

在Storm之前，进行实时处理是非常痛苦的事情: 需要维护一堆消息队列和消费者，他们构成了非常复杂的图结构。消费者进程从队列里取消息，处理完成后，去更新数据库，或者给其他队列发新消息。

这样进行实时处理是非常痛苦的。我们主要的时间都花在关注往哪里发消息，从哪里接收消息，消息如何序列化，真正的业务逻辑只占了源代码的一小部分。一个应用程序的逻辑运行在很多worker上，但这些worker需要各自单独部署，还需要部署消息队列。最大问题是系统很脆弱，而且不是容错的：需要自己保证消息队列和worker进程工作正常。

Storm完整地解决了这些问题。它是为分布式场景而生的，抽象了消息传递，会自动地在集群机器上并发地处理流式计算，让你专注于实时处理的业务逻辑。

6.2.2. 特性

1. 编程简单：开发人员只需要关注应用逻辑，而且跟Hadoop类似，Storm提供的编程原语也很简单

2. 高性能，低延迟：可以应用于广告搜索引擎这种要求对广告主的操作进行实时响应的场景。

3. 分布式：可以轻松应对数据量大，单机搞不定的场景

4. 可扩展： 随着业务发展，数据量和计算量越来越大，系统可水平扩展

5. 容错：单个节点挂了不影响应用

6. 消息不丢失：保证消息处理

6.2.3. 使用场景

Storm有很多应用：实时分析，在线机器学习(online machine learning)，连续计算(continuous computation)，分布式远程过程调用(RPC)、ETL等。Storm处理速度很快：每个节点每秒钟可以处理超过百万的数据组。它是可扩展(scalable)，容错(fault-tolerant)，保证你的数据会被处理，并且很容易搭建和操作。

例如Nathan Marz提供的例子，产生Twitter的趋势信息。Twitter从海量推文中抽取趋势信息，并在本地区域和国家层级进行维护。这意味者一旦一个案例开始出现，Twitter的话题趋势算法就能实时的鉴别出这个话题。这个实时的算法就是通过在Storm上连续分析Twitter数据来实现的。

6.2.4. 架构

image.png

Nimbus Storm集群的Master节点，负责分发用户代码，指派给具体的Supervisor节点上的Worker节点，去运行Topology对应的组件（Spout/Bolt）的Task。 Supervisor Storm集群的从节点，负责管理运行在Supervisor节点上的每一个Worker进程的启动和终止。通过Storm的配置文件中的supervisor.slots.ports配置项，可以指定在一个Supervisor上最大允许多少个Slot，每个Slot通过端口号来唯一标识，一个端口号对应一个Worker进程（如果该Worker进程被启动）。

Worker

运行具体处理组件逻辑的进程。Worker运行的任务类型只有两种，一种是Spout任务，一种是Bolt任务。

Task

worker中每一个spout/bolt的线程称为一个task. 在storm0.8之后，task不再与物理线程对应，不同spout/bolt的task可能会共享一个物理线程，该线程称为executor。

ZooKeeper 用来协调Nimbus和Supervisor，如果Supervisor因故障出现问题而无法运行Topology，Nimbus会第一时间感知到，并重新分配Topology到其它可用的Supervisor上运行

6.2.5. 与****hadoop比较

1.Storm用于实时计算，Hadoop用于离线计算。

2. Storm处理的数据保存在内存中，源源不断；Hadoop处理的数据保存在文件系统中，一批一批。

3. Storm的数据通过网络传输进来；Hadoop的数据保存在磁盘中。

4. Storm与Hadoop的编程模型相似

6.2.6. 与spark比较

image.png

7. 消息系统kafka

7.1. 简介

Kafka是最初由Linkedin公司开发，是一个分布式、支持分区的（partition）、多副本的（replica），基于zookeeper协调的分布式消息系统，它的最大的特性就是可以实时的处理大量数据以满足各种需求场景：比如基于hadoop的批处理系统、低延迟的实时系统、storm/Spark流式处理引擎，web/nginx日志、访问日志，消息服务等等，用scala语言编写，Linkedin于2010年贡献给了Apache基金会并成为顶级开源 项目。

7.2. 特性

• 高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒，每个topic可以分多个partition, consumer group 对partition进行consume操作。

• 可扩展性：kafka集群支持热扩展

• 持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失

• 容错性：允许集群中节点失败（若副本数量为n,则允许n-1个节点失败）

• 高并发：支持数千个客户端同时读写

7.3. 使用场景

• 日志收集：一个公司可以用Kafka可以收集各种服务的log，通过kafka以统一接口服务的方式开放给各种consumer，例如hadoop、Hbase、Solr等。

• 消息系统：解耦和生产者和消费者、缓存消息等。

• 用户活动跟踪：Kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到hadoop、数据仓库中做离线分析和挖掘。

• 运营指标：Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告。

• 流式处理：比如spark streaming和storm

• 事件源

7.4. 架构

image.png

一个典型的Kafka集群中包含若干Producer（可以是web前端FET，或者是服务器日志等），若干broker（Kafka支持水平扩展，一般broker数量越多，集群吞吐率越高），若干ConsumerGroup，以及一个Zookeeper集群。Kafka通过Zookeeper管理Kafka集群配置：选举Kafka broker的leader，以及在Consumer Group发生变化时进行rebalance，因为consumer消费kafka topic的partition的offsite信息是存在Zookeeper的。Producer使用push模式将消息发布到broker，Consumer使用pull模式从broker订阅并消费消息。

7.5. Kafka中名词解释

Kafka中发布订阅的对象是topic。我们可以为每类数据创建一个topic，把向topic发布消息的客户端称作producer，从topic订阅消息的客户端称作consumer。Producers和consumers可以同时从多个topic读写数据。一个kafka集群由一个或多个broker服务器组成，它负责持久化和备份具体的kafka消息。

· Broker：Kafka节点，一个Kafka节点就是一个broker，多个broker可以组成一个Kafka集群。

· Topic：一类消息，消息存放的目录即主题，例如page view日志、click日志等都可以以topic的形式存在，Kafka集群能够同时负责多个topic的分发。

· Partition：topic物理上的分组，一个topic可以分为多个partition，每个partition是一个有序的队列

· Segment：partition物理上由多个segment组成，每个Segment存着message信息

· **Producer **: 生产message发送到topic

· **Consumer **: 订阅topic消费message, consumer作为一个线程来消费

· Consumer Group：一个Consumer Group包含多个consumer, 这个是预先在配置文件中配置好的。各个consumer（consumer 线程）可以组成一个组（Consumer group ），partition中的每个message只能被组（Consumer group ） 中的一个consumer（consumer 线程 ）消费，如果一个message可以被多个consumer（consumer 线程 ） 消费的话，那么这些consumer必须在不同的组。Kafka不支持一个partition中的message由两个或两个以上的consumer thread来处理，即便是来自不同的consumer group的也不行。它不能像AMQ那样可以多个BET作为consumer去处理message，这是因为多个BET去消费一个Queue中的数据的时候，由于要保证不能多个线程拿同一条message，所以就需要行级别悲观所（for update）,这就导致了consume的性能下降，吞吐量不够。而kafka为了保证吞吐量，只允许一个consumer线程去访问一个partition。如果觉得效率不高的时候，可以加partition的数量来横向扩展，那么再加新的consumer thread去消费。这样没有锁竞争，充分发挥了横向的扩展性，吞吐量极高。这也就形成了分布式消费的概念。

8. 数据采集

8.1. Etl介绍

ETL是数据抽取（Extract）、清洗（Cleaning）、转换（Transform）、装载（Load）的过程。是构建数据仓库的重要一环，用户从数据源抽取出所需的数据，经过数据清洗,最终按照预先定义好的数据仓库模型，将数据加载到数据仓库中去。

8.2. Elk

8.2.1. 简介

ELK 其实并不是一款软件，而是一整套解决方案，是三个软件产品的首字母缩写，Elasticsearch，Logstash 和 Kibana。这三款软件都是开源软件，通常是配合使用，而且又先后归于 Elastic.co 公司名下，故被简称为 ELK 协议栈，见图 。

image.png

8.2.1.1. Elasticsearch

Elasticsearch 是一个实时的分布式搜索和分析引擎，它可以用于全文搜索，结构化搜索以及分析。它是一个建立在全文搜索引擎 Apache Lucene 基础上的搜索引擎，使用 Java 语言编写。目前，最新的版本是 2.1.0。

主要特点

实时分析

分布式实时文件存储，并将每一个字段都编入索引

文档导向，所有的对象全部是文档

高可用性，易扩展，支持集群（Cluster）、分片和复制（Shards 和 Replicas）。见图 2 和图 3

接口友好，支持 JSON

8.2.1.2. Logstash

Logstash 是一个具有实时渠道能力的数据收集引擎。使用 JRuby 语言编写。其作者是世界著名的运维工程师乔丹西塞 (JordanSissel)。

主要特点:

几乎可以访问任何数据

可以和多种外部应用结合

支持弹性扩展

它由三个主要部分组成，见图：

Shipper－发送日志数据

Broker－收集数据，缺省内置 Redis

Indexer－数据写入

image.png

8.2.1.3. Kibala

Kibana 是一款基于 Apache 开源协议，使用 JavaScript 语言编写，为 Elasticsearch 提供分析和可视化的 Web 平台。它可以在 Elasticsearch 的索引中查找，交互数据，并生成各种维度的表图。

8.2.2. 架构

image.png

8.2.3. 使用场景

1、日志查询，问题排查，上线检查。

2、服务器监控，应用监控，错误报警，bug管理。

3、性能分析，用户行为分析，安全漏洞分析，时间管理。

8.3. Flume

8.3.1. 简介

apache Flume 是一个从可以收集例如日志，事件等数据资源，并将这些数量庞大的数据从各项数据资源中集中起来存储的工具/服务，或者数集中机制。flume具有高可用，分布式，配置工具，其设计的原理也是基于将数据流，如日志数据从各种网站服务器上汇集起来存储到HDFS，HBase等集中存储器中

8.3.2. 特性

1. Flume可以高效率的将多个网站服务器中收集的日志信息存入HDFS/HBase中

2. 使用Flume，我们可以将从多个服务器中获取的数据迅速的移交给Hadoop中

3. 除了日志信息，Flume同时也可以用来接入收集规模宏大的社交网络节点事件数据，比如facebook,twitter,电商网站如亚马逊，flipkart等

4. 支持各种接入资源数据的类型以及接出数据类型

5. 支持多路径流量，多管道接入流量，多管道接出流量，上下文路由等

6. 可以被水平扩展

8.3.3. 使用场景

比如我们在做一个电子商务网站，然后我们想从消费用户中访问点特定的节点区域来分析消费者的行为或者购买意图. 这样我们就可以更加快速的将他想要的推送到界面上，实现这一点，我们需要将获取到的她访问的页面以及点击的产品数据等日志数据信息收集并移交给Hadoop平台上去分析.而Flume正是帮我们做到这一点。现在流行的内容推送，比如广告定点投放以及新闻私人定制也是基于次，不过不一定是使用FLume,毕竟优秀的产品很多，比如facebook的Scribe，还有Apache新出的另一个明星项目chukwa，还有淘宝Time Tunnel。

8.3.4. 架构

image.png

flume之所这么神奇，是源于它自身的一个设计，这个设计就是agent，agent本身是一个java进程，运行在日志收集节点—所谓日志收集节点就是服务器节点。

agent里面包含3个核心的组件：source—->channel—–>sink,类似生产者、仓库、消费者的架构。

source：source组件是专门用来收集数据的，可以处理各种类型、各种格式的日志数据,包括avro、thrift、exec、jms、spooling directory、netcat、sequence generator、syslog、http、legacy、自定义。

channel：source组件把数据收集来以后，临时存放在channel中，即channel组件在agent中是专门用来存放临时数据的——对采集到的数据进行简单的缓存，可以存放在memory、jdbc、file等等。

sink：sink组件是用于把数据发送到目的地的组件，目的地包括hdfs、logger、avro、thrift、ipc、file、null、hbase、solr、自定义。

8.3.5. Flume优点

1. Flume可以将应用产生的数据存储到任何集中存储器中，比如HDFS,HBase

2. 当收集数据的速度超过将写入数据的时候，也就是当收集信息遇到峰值时，这时候收集的信息非常大，甚至超过了系统的写入数据能力，这时候，Flume会在数据生产者和数据收容器间做出调整，保证其能够在两者之间提供一共平稳的数据.

3. 提供上下文路由特征

4. Flume的管道是基于事务，保证了数据在传送和接收时的一致性.

5. Flume是可靠的，容错性高的，可升级的，易管理的,并且可定制的。