大数据

大数据计算模式、大数据处理类型、大数据产业、Hadoop项目结构

大数据

大数据计算模式

批处理计算：针对大规模数据的批处理

MapReduce、Spark

流计算：针对流数据的实时计算

Storm、S4、Stream、Dstream、Puma

图计算：针对大规模图结构数据的处理

Pregel、GraphX、Giraph、Hama

查询分析计算：大规模数据的存储管理和查询分析

Dremel、Hie、Cassandra、Impala

大数据处理类型

复杂的批量数据处理：时间跨度数十分钟到数小时

如MapReduce

基于历史数据的交互式查询：数十秒到数分钟

如Impala

基于实时数据流的数据处理：数百毫秒到数秒之间

如Storm

大数据产业

IT技术设施层

数据源层

数据管理层

数据抽取、转换、存储和管理等服务

数据分析层

提供分布式计算、数据挖掘、统计分析等服务

数据平台层

提供数据分享平台、数据分析平台、数据租售平台等服务

数据应用层

智能交通、医疗、物流、电网等

Hadoop项目结构

HDFS：分布式文件系统

MaoReduce：分布式并行编程模型

YARN：资源管理和调度器

Tez：运行在YARN之上的下一代Hadoop查询处理框架

将Map和Reduce两个操作进一步拆分

Map拆分为Input、Processor、Sort、Merge、Output

Reduce拆分为Input、Shuffle、Sort、Merge、Processor、Output

DAG 作业计算框架

Hive：Hadoop上的数据仓库

HBase：Hadoop上的非关系型的分布式数据库

Pig：一个基于Hadoop的大规模数据分析平台，提供类似于SQL的查询语言Pig Latin

通过编写简单的脚本实现复杂的数据分析，不需要编写复杂的MapReduce应用程序

用户脚本自动转换为MapReduce作业

Sqoop：用于在Hadoop与传统数据库之间进行数据传递

Oozie：Hadoop上的工作流管理系统

Zookeeper：提供分布式协调一致性服务

Storm：流计算框架

Flume：一个高可用，高可靠，分布式的海量日志采集、聚合和传输系统

Ambari：Hadoop快速部署工具，支持Apache Hadoop集群的供应、管理和监控

Spark：类似于Hadoop MapReduce的通用并行框架

Kafka：高吞吐量的分布式发布订阅消息系统，满足在线实时处理和批量离线处理

Spark

Spark vs Hadoop Hadoop 缺点 表达能力有限 磁盘IO开销大 延迟高

概述

基于内存计算的大数据并行计算框架，构建大型、低延迟的数据分析应用程序

使用DAG执行引擎以支持循环数据流与内存计算

支持Scala、Java、Python和R语言进行编程

完整的技术栈：SQL查询、流式计算、机器学习和图算

独立集群、云上环境可读取Cassandra、HBase、Hive等数据源

生态

一个软件爱你栈满足不同应用场景 提供内存计算框架，也可以支持SQL即席查询、实时流式计算、机器学习和图计算

复杂的批量数据处理

基于历史数据的交互式查询

基于实时数据流的数据处理

基于历史数据的数据挖掘

图结构数据处理

运行架构

基本概念

RDD

Resillient Distributed Dataset ，分布式内存，高度受限的共享内存模型

DAG

Directed Acyclic Graph（有向无环图），反应RDD之间的依赖关系

Exceutor

运行在WorkNode的一个进程，复杂运行Task

Application

用户编写的Spark应用程序

Task

运行在Executor上的工作单元

Job

一个Job包含多个RDD级作用于RDD上的操作

Stage

Job的基本调度单位，一个Job会分为多组Task，每组Task被称为Stage

架构设计

集群管理器（ClusterManager）

可以自带Mesos或YARN

运行作业任务的工作节点（Worker Node）

每个应用的任务控制节点（Driver）

每个工作节点上负责具体任务的执行进程（Executor）

利用多线程执行具体的任务，减少任务的启动开销

BlockManager存储模块，将内存和磁盘共同作为存储设备，有效减少IO开销

流计算

数据的价值随着时间的流逝而降低 流计算系统特点 1.高性能——每秒处理几十万条数据； 2.海量式——TB/PB级别； 3.实时性——低延迟，秒级/毫秒级别 4.分布式——平滑扩展 5.易用性——快速开发和部署 6.可靠性——可靠地处理流数据

流数据特征

数据快速持续到达，潜在大小也许无穷无尽

数据来源众多，格式复杂

数据量大，但是不十分关注存储，一旦经过处理，要么被丢弃，要么被归档存储

注重数据整体价值，不过分关注个别数据

数据顺序颠倒，或者不完整，系统午发控制将要处理的新到达的数据元素的顺序

数据处理流程

实时采集

Agent：主动采集数据，并把数据推送到Collector

Collector：接受Agent数据，并实现有序、可靠、高性能转发

Store：存储Collector转发过来的数据

实时计算

实时查询

实时查询服务可以主动将实时结果推送给客户

应用场景

Web服务/机器翻译/广告投放/自然语言处理/气候模拟

实时交通

Storm

设计思想

Streams:Storm将流数据Stream描述成一个无序的Tuple序列，这些Tuple序列会以分布式的方式并行地常见和处理

Spout：Storm认为每个Stream都有一个源头，并把这个源头抽象为Spout ，通常Spout会从外部数据源（队列、数据库等）读取数据，然后封装成Tuple形式，发送到Stream中。Spout是一个主动的角色，在接口内部有个nextTuple函数，Storm框架会不停的调用该函数

Bolt：Storm将Streams的状态转换过程抽象为Bolt。Bolt即可以处理Tuple，也可以将处理后的Tuple作为新的Streams发送给其他Bolt

Topology：Storm将Spouts和Bolts组成的网络抽象成Topology，它可以被提交到Storm集群执行。Topology可视为流转换图，图中节点是一个Spout或Bolt，边则表示Bolt订阅了哪个Stream。当Spout或者Bolt发送元组时，它会把元组发送到每个订阅了该Stream的Bolt上进行处理

Stream Groupings：：Storm中的Stream Groupings用于告知Topology如何在两个组件间（如Spout和Bolt之间，或者不同的Bolt之间）进行Tuple的传送。每一个Spout和Bolt都可以有多个分布式任务，一个任务在什么时候、以什么方式发送Tuple就是由Stream Groupings来决定的

框架设计

MapReduce作业最终会完成计算并结束运行，而Topology将持续处理消息（直到人为终止）

对应关系

Master--worker

Master :Nimbus ,负责在集群范围内分发代码、为Worker分配任务和检测故障

Worker :Supervisor”的后台程序，负责监听分配给它所在机器的工作，即根据Nimbus分配的任务来决定启动或停止Worker进程，一个Worker节点上同时运行若干个Worker进程

工作流程

图计算

图结构数据

表达数据之间的关联性

关联性计算时大数据计算的核心——通过获得数据的关联性，可以从噪音海量数据中抽取有用的信息

大型图计算软件

基于遍历算法的、实时的图数据库，如Neo4j、OrientDB、DEX和Infinite Graph

以图顶点为中心的、基于消息传递处理的并行引擎，如GoldenOrb、Giraph、Pregel和Hama，基于BSP模型实现

BSP（Bulk Synchronousparallel Computing Model ）,计算过程包括一系列全局超步（计算中的一次迭代）

局部计算：每个参与的处理器都有自身的计算任务，只读取存储在本地内存中值，不同处理器的计算任务都是异步并且独立的

通讯：处理器群相互间交换数据，一方发起推送和获取操作

栅栏同步：当一个处理器遇到栅栏，会等到其他所有处理器完成它们所有计算步骤；每一次同步都是一个超步的完成和下一个超步的开始

Pregel

数据可视化

什么是可视化

指将大型数据集中的数据以图形图像形式表示，并利用数据分析和开发工具发现其中未知信息处理过程

每一个数据项作为单个图元素表示，大量的数据集构成数据图像，同时将数据的各个属性值以多维数据的形式表示，可以从不同的维度观察数据，从而对数据进行更深入的观察和分析

历程

霍乱地图

南丁格尔——鸡冠花图

工具

Excel

信息图表

Google Chart

D3

Visual.ly

Tableau

大数据魔镜

地图工具

Google FusionTables

Modest Maps

Leaflet

时间线工具

Timetoast

Xtimeline

分析工具

Weka

R

Gephi

典型分享

全球黑客活动

互联网地图

编程语言影响力关系图

3D可视化

应用场景

日常生活

个性化服务

政府领域

选举

安全领域

国家安全

防御网络攻击

预防犯罪

体育娱乐

训练球队

投拍影视作品

预测比赛结果

能源行业

智能电网

电信行业

客户离网分析

餐饮行业

餐饮O2O

互联网

推荐系统

用户建模模块

推荐对象建模模块

推荐算法模块

UserCF:基于用户

ItemCF：基于物品

生物医学

流行病预测

智慧医疗

生物信息学

物流

智能物流

菜鸟（智能物流骨干网）

城市管理

智能交通

环保检测

城市规划

安防领域

金融行业

高频交易

市场情绪分析

信贷风险分析

汽车行业

无人驾驶

零售行业

发现关联购买行为

客户群体细分

供应链管理

HDFS

场景局限性

不适合低延迟数据访问

无法高效存储大量小文件

不支持多用户写入及任意修改文件

block是核心；采用主从结构模型，

分布式文件系统

计算集群架构：NameNode&&DataNode /网络互联/Rack机架

DataNode

数据节点是分布式文件系统HDFS的工作节点，负责数据的存储和读取，会根据客户端或者是名称节点的调度来进行数据的存储和检索，并且向名称节点定期发送自己所存储的块的列表 每个数据节点中的数据会被保存在各自节点的本地Linux文件系统中

NameNode

名称节点（NameNode）负责管理分布式文件系统的命名空间（Namespace），保存了两个核心的数据结构，即FsImage和EditLog FsImage文件包含文件系统中所有目录和文件inode的序列化形式。每个inode是一个文件或目录的元数据的内部表示，并包含此类信息：文件的复制等级、修改和访问时间、访问权限、块大小以及组成文件的块。对于目录，则存储修改时间、权限和配额元数据 FsImage文件没有记录文件包含哪些块以及每个块存储在哪个数据节点。而是由名称节点把这些映射信息保留在内存中，当数据节点加入HDFS集群时，数据节点会把自己所包含的块列表告知给名称节点，此后会定期执行这种告知操作，以确保名称节点的块映射是最新的。

HBase

1.源自于google BigTable ，开源实现； 2.用于在线护具分析处理系统

传统DB的对比

数据类型

数据操作

存储模式

数据索引

数据维护

可伸缩性

访问接口

Native JavaAPI

Hbase Shell

Pig

Hive

Thrift Gateway

REST Gateway

数据模型

模型概述

Hase是一个稀疏、多维度、排序的映射表，索引是行健、列族、列限定符和时间戳

每个值是一个未经解释的字符串，没有数据类型

每一行都有一个可排序的行健和任意多列

列族支持动态扩展，所有列均以字符串形式存储，用户需要自行进行数据类型转换

更新操作，并不会删除数据旧的版本，

表：组织数据；行：列族/列限定符/单元格/时间戳

数据坐标

行健、列族、列限定符和时间戳确定单元格

HBase实现

功能组件

库函数

链接到每个客户端

客户端并不是直接从Master主服务器上读取数据，而是在获得Region的存储位置信息后，直接从Region服务器上读取数据 客户端并不依赖Master，而是通过Zookeeper来获得Region位置信息，大多数客户端甚至从来不和Master通信，这种设计方式使得Master负载很小

Master主服务器

负责管理和维护HBase表的分区信息，维护Region服务器列表，分配Region，负载均衡

多个Region 服务器

负责存储和维护分配给自己的region,处理来自client的读写请求

三层架构

Zookeeper文件

记录了-ROOT-表的位置信息

—Root-表

记录了.META。表的Region位置信息，-ROOT-表只能有一个Region

。META.表

加载到内存中

记录了用户数据表的Region位置信息，.META.表有多个Region，保存了HBase中所有用户数据表的Region位置信息

运行机制

系统架构

Region工作原理

用户读写

用户写入数据时，被分配到相应Region服务器去执行 用户数据首先被写入到MemStore和Hlog中 只有当操作写入Hlog之后，commit()调用才会将其返回给客户端 当用户读取数据时，Region服务器会首先访问MemStore缓存，如果找不到，再去磁盘上面的StoreFile中寻找

缓存刷新

系统会周期性地把MemStore缓存里的内容刷写到磁盘的StoreFile文件中，清空缓存，并在Hlog里面写入一个标记 每次刷写都生成一个新的StoreFile文件，因此，每个Store包含多个StoreFile文件 每个Region服务器都有一个自己的HLog 文件，每次启动都检查该文件，确认最近一次执行缓存刷新操作之后是否发生新的写入操作；如果发现更新，则先写入MemStore，再刷写到StoreFile，最后删除旧的Hlog文件，开始为用户提供服务

StoreFile合并

每次刷写都生成一个新的StoreFile，数量太多，影响查找速度 调用Store.compact()把多个合并成一个 合并操作比较耗费资源，只有数量达到一个阈值才启动合并

应用方案

HBase上构建SQlL引擎

Hive+HBase

Phoenix

HBase二级索引

Hindex

HBase+Redis

HBase+solar

Coprocessor

引擎构建在HBase之上，既没有HBase进行任何改动，也不需要对上层应用做任何妥协

每插入一条数据需要向索引表插入数据，耗时双倍，对HBase集群压力双倍

性能监视

Ambari

Master-status

OpenTSDB

Ganglia

性能优化

行健（Row Key）

InMemory

Time To Live

NoSQL

灵活的扩展性 灵活的数据模型 兴起原因 （1）无法满足海量数据的管理需求 （2）无法满足数据高并发的需求 （3）无法满足高可扩展性和高可用性的需求

兴起原因

Web2.0通常不需要严格的数据库事务

Web2.0并不要求严格的读写实时性

Web2.0通常不包含大量复杂的SQL查询（去结构化，存储空间换取更好的查询性能）

关系vs非关系型

RDBMS

以完善的关系代数理论作为基础，有严格的标准，支持事务ACID四性，借助索引机制可以实现高效的查询，技术成熟，有专业公司的技术支持

可扩展性较差，无法较好支持海量数据存储，数据模型过于死板、无法较好支持Web2.0应用，事务机制影响了系统的整体性能等

NoSQL

可以支持超大规模数据存储，灵活的数据模型可以很好地支持Web2.0应用，具有强大的横向扩展能力等

缺乏数学理论基础，复杂查询性能不高，大都不能实现事务强一致性，很难实现数据完整性，技术尚不成熟，缺乏专业团队的技术支持，维护较困难等

四大l类型

键值

理想的缓冲层解决方案

Redis、Riak、SimpleDB、Chordless、Scalaris、Memcached

数据模型：键值对

典型应用

涉及频繁读写、拥有简单的数据模型的应用/内容缓存，比如会话、配置文件、参数、购物车等/存储配置和用户数据信息的移动应用

扩展性。灵活性好，大量写操作时性能高

无法存储结构化信息，条件查询效率低

不支持事务性支持，关联数据的关系

列族

BigTable、HBase、Cassandra、HadoopDB、GreenPlum、PNUTS

数据模型：列族

典型应用

分布式数据存储与管理

数据在地理上分布在多个数据中心的应用

容忍副本在短期不一致情况的应用程序

动态字段的应用程序

查找速度快，可扩展性强，容易进行分布式扩展，复杂性低

功能较少，不支持强事务一致性

文档

XML文档、HTML文档和JSON 文档就属于这一类 必须有schema信息才能理解数据的含义

MongoDB、CouchDB、Terrastore、ThruDB、RavenDB、SisoDB、RaptorDB、CloudKit、Perservere、Jackrabbit

数据模型：键值 值（value）是版本化的文档

典型应用

存储、索引并管理面向文档的数据或类似的半结构化数据（后台有大量读写操作的网站、使用JSON数据结构的应用、使用嵌套结构等非规范化数据的应用程序）

性能好（高并发），灵活性高，复杂度低，数据结构灵活提供嵌入式文档功能，将经常查询的数据存储在同一个文档中即可以根据键来构建索引，也可以根据内容构建索引

缺乏统一的查询语法

图形

Neo4J、OrientDB、InfoGrid、Infinite Graph、GraphDB

图结构：数据模型

专门用于处理具有高度相互关联关系的数据，比较适合于社交网络、模式识别、依赖分析、推荐系统以及路径寻找等问题 题

灵活性高，支持复杂的图形算法，可用于构建复杂的关系图谱

复杂性高，只能支持一定的数据规模

三大基石

CAP

Consistency：一致性，任何一个读操作总是能够读到之前完成的写操作结果

在分布式环境中，多点的数据是一致的，或者说，所有节点在同一时间具有相同的数据

Availablity：可用性，指快速获取数据，在确定的时间内返回操作结果，保证请求有响应

Tolerance of Network Partion:分区容忍性

是指当出现网络分区的情况时（即系统中的一部分节点无法和其他节点进行通信），分离的系统也能够正常运行，也就是说，系统中任意信息的丢失或失败不会影响系统的继续运作。

BASE

A（Atomicity）：原子性，是指事务必须是原子工作单元，对于其数据修改，要么全都执行，要么全都不执行 C（Consistency）：一致性，是指事务在完成时，必须使所有的数据都保持一致状态 I（Isolation）：隔离性，是指由并发事务所做的修改必须与任何其它并发事务所做的修改隔离 D（Durability）：持久性，是指事务完成之后，它对于系统的影响是永久性的，该修改即使出现致命的系统故障也将一直保持

Basically Availble，

基本可用，分布式系统部分发生问题不可用，其他部分仍可使用，允许分区失败

Soft-state

状态可以有一段时间不同步，具有一定滞后性

Eventualconsistency

因果一致性

读己之所写一致性

单调读一致性

会话一致性

单调写一致性

最终一致性

N——数据复制的份数，W——更新数据时需要保证写完成的节点数，R——读取数据的时候需要读取的节点数

W+R>N,强一致性

W+R<N 弱一致性

MongoDB

简介

基于分布式文件存储的开源数据库系统，Web应用提供可扩展的高性能数据存储解决方案

数据结构由键值对组成，类似于JSON对象，字段值可以包含其它文档，数组及文档数组

面向文档存储，操作起来简单和容易；设置任何属性的索引实现快速排序；丰富的查询表达式；

概念解析

MapReduce

1.分而治之的策略，一个存储在分布式文件系统中的大规模数据集。会被切分成独立的分片（split），这些多个Map任务并行处理 2.计算向数据靠拢

框架

Master/Slave 架构，Master运行JobTracker，Slave运行TaskTracker

函数框架

体系结构

1）Client 用户编写的MapReduce程序通过Client提交到JobTracker端 用户可通过Client提供的一些接口查看作业运行状态 2）JobTracker JobTracker负责资源监控和作业调度 JobTracker 监控所有TaskTracker与Job的健康状况，一旦发现失败，就将相应的任务转移到其他节点 JobTracker 会跟踪任务的执行进度、资源使用量等信息，并将这些信息告诉任务调度器（TaskScheduler），而调度器会在资源出现空闲时，选择合适的任务去使用这些资源 3）TaskTracker TaskTracker 会周期性地通过“心跳”将本节点上资源的使用情况和任务的运行进度汇报给JobTracker，同时接收JobTracker 发送过来的命令并执行相应的操作（如启动新任务、杀死任务等） TaskTracker 使用“slot”等量划分本节点上的资源量（CPU、内存等）。一个Task 获取到一个slot 后才有机会运行，而Hadoop调度器的作用就是将各个TaskTracker上的空闲slot分配给Task使用。slot 分为Map slot 和Reduce slot 两种，分别供MapTask 和Reduce Task 使用 4）Task Task 分为Map Task 和Reduce Task 两种，均由TaskTracker 启动

工作流程

Hadoop2.0

1.MapReduce 和HDFS架构设计改进 2.生态系统丰富：Pig、Tez、Spark、Kafka

框架改进

HDFS HA，提供节点热备机制

HDFS Federation，管理多个命名空间

新的资源管理框架YARN

生态系统：Pig、Spark、Oozie、Tez、Kafka

YARN

一个集群多个框架 MapReduce实现离线批处理 使用Impala实现实时交互式查询分析 使用Storm实现流式数据实时分析 使用Spark实现迭代计算

ResourceManager

ResourceManager（RM）是一个全局的资源管理器，负责整个系统的资源管理和分配，主要包括两个组件，即调度器（Scheduler）和应用程序管理器（Applications Manager） 调度器接收来自ApplicationMaster的应用程序资源请求，把集群中的资源以“容器”的形式分配给提出申请的应用程序，容器的选择通常会考虑应用程序所要处理的数据的位置，进行就近选择，从而实现“计算向数据靠拢” 容器（Container）作为动态资源分配单位，每个容器中都封装了一定数量的CPU、内存、磁盘等资源，从而限定每个应用程序可以使用的资源量 调度器被设计成是一个可插拔的组件，YARN不仅自身提供了许多种直接可用的调度器，也允许用户根据自己的需求重新设计调度器 应用程序管理器（Applications Manager）负责系统中所有应用程序的管理工作，主要包括应用程序提交、与调度器协商资源以启动ApplicationMaster、监控ApplicationMaster运行状态并在失败时重新启动等

处理客户端请求

启动/监控ApplicationMaster

监控NodeManager

资源分配与调度

ApplicationMaster

ResourceManager接收用户提交的作业，按照作业的上下文信息以及从NodeManager收集来的容器状态信息，启动调度过程，为用户作业启动一个ApplicationMaster ApplicationMaster的主要功能是： （1）当用户作业提交时，ApplicationMaster与ResourceManager协商获取资源，ResourceManager会以容器的形式为ApplicationMaster分配资源； （2）把获得的资源进一步分配给内部的各个任务（Map任务或Reduce任务），实现资源的“二次分配”； （3）与NodeManager保持交互通信进行应用程序的启动、运行、监控和停止，监控申请到的资源的使用情况，对所有任务的执行进度和状态进行监控，并在任务发生失败时执行失败恢复（即重新申请资源重启任务）； （4）定时向ResourceManager发送“心跳”消息，报告资源的使用情况和应用的进度信息； （5）当作业完成时，ApplicationMaster向ResourceManager注销容器，执行周期完成。

为应用程序申请资源，并分配给内部任务

任务调度、监控与容错

NodeManager

NodeManager是驻留在一个YARN集群中的每个节点上的代理，主要负责： 容器生命周期管理 监控每个容器的资源（CPU、内存等）使用情况 跟踪节点健康状况 以“心跳”的方式与ResourceManager保持通信 向ResourceManager汇报作业的资源使用情况和每个容器的运行状态 接收来自ApplicationMaster的启动/停止容器的各种请求 需要说明的是，NodeManager主要负责管理抽象的容器，只处理与容器相关的事情，而不具体负责每个任务（Map任务或Reduce任务）自身状态的管理，因为这些管理工作是由ApplicationMaster完成的，ApplicationMaster会通过不断与NodeManager通信来掌握各个任务的执行状态

处理来自ResourceManager的命令

处理来自ApplicationMaster的命令

YARN框架体系