大数据技术原理与应用笔记

参考：
课程教学（林子雨老师）
程序羊大数据学习路线
HDFS入门
Hbase入门
NoSql入门

一、大数据概述

1.1大数据时代

三次信息化浪潮

1.2大数据的概念和影响

• 大数据的4v特征
  volume大量化、velocity快速化、variety多样化、value价值化

  • 数据量大
  • 数据类型繁多 – 大数据是由结构化和非结构化数据组成的
  • 处理速度快
  • 价值密度低，商业价值高 – 连续不间断监控过程中，可能有用的数据仅仅有一两秒，但是具有很高的商业价值
    

• 大数据的影响

  • 思维方式方面：大数据完全颠覆了传统的思维方式（全样而非抽样、效率而非精确、相关而非因果）。
    (因为是全样,所以无需担心误差放大,进而无需关注精确而需关注效率)
  • 社会发展方面：大数据决策逐渐成为一种新的决策方式，大数据应用有力促进了信息技术与各行业的深度融合，大数据开发大大推动了新技术和新应用的不断涌现。
  • 就业市场方面：大数据的兴起使得数据科学家成为热门职业。
  • 人才培养方面：大数据的兴起将在很大程度上改变中国高校信息技术相关专业的现有教学。
    

1.3大数据的应用

(谷歌预测流感,大数据)

1.4大数据的关键技术

1.5大数据,物联网和云计算

1.5.1 云计算

• 解决了两个核心问题,即海量数据的分布式存储和分布式处理问题
• 典型特征是虚拟化和多租户
  
  (老朋友 自来水)

(公有云:例如百度)

1.5.2物联网

• 物联网的关键技术:识别&感知
• 大数据(此时指数据处理技术,非数据本身):如何存储&如何处理

(三者不断融合发展,相辅相成)

检测题

• 单位换算
  1KB (Kilobyte 千字节)=1024B，
  1MB (Megabyte 兆字节 简称“兆”)=1024KB，
  1GB (Gigabyte 吉字节 又称“千兆”)=1024MB，
  　　 1TB (Trillionbyte 万亿字节 太字节)=1024GB，其中1024=2^10 ( 2 的10次方)，
  　　 1PB（Petabyte 千万亿字节 拍字节）=1024TB，
  　　 1EB（Exabyte 百亿亿字节 艾字节）=1024PB，
  　　 1ZB (Zettabyte 十万亿亿字节 泽字节)= 1024 EB,
  　　 1YB (Yottabyte 一亿亿亿字节 尧字节)= 1024 ZB,
  　　 1BB (Brontobyte 一千亿亿亿字节)= 1024 YB.
  (k m g t p e z y b 提屁姨，贼一笔)

二、大数据处理架构Hadoop

2.1hello，Hadoop

2.1.1Hadoop简介

• Hadoop发展历程
  Apache软件基金会旗下的开源分布式平台，基于Java语言开发，具有很好的跨平台性
  核心是分布式文件系统HDFS和MapReduce（分别实现了海量数据的分布式存储&处理）
  

Hadoop源自始于Apache Nutch项目。

• Hadoop的特性
  高可靠性、高效性、高可扩展性、高容错性、成本低、运行在Linux平台、支持多种编程语言。

2.1.2Apache Hadoop版本演变

Hadoop2.0增加了HDFS HA和YARN两个系统。

2.2Hadoop项目结构

• HDFS：负责分布式文件存储

• YARN框架：对计算机资源（例如带宽、内存啥的）进行管理和调度

• MapReduce：离线 批处理计算

• Tez:把作业 分析优化后 构建有向无环图，得出哪些工作先做哪些工作可以后做 以获得最好的工作效率
  

• Spark：类似于Hadoop MapReduce的通用并行框架
  区别 Spark基于内存，因而效率比后者高一个数量级
  MapReduce基于磁盘

• Hive：Hadoop上的数据仓库
  支持SQL语句，可以把SQL语句转化为一堆mapreduce作业
  

• Pig：实现流数据处理
  提供轻量级的数据分析
  （虽说MapReduce已经屏蔽了很多底层的复杂性，但还是很复杂
  所以有了Pig这一轻量级的脚本语言）
  

• Oozie：作业流调度系统

• ZooKeeper：提供分布式协调一致性（例如分布式锁，集群管理啥的）

• HBase列族数据库：支持随机读写，进而支持实时应用（快男）

• Flume:日志收集分析框架(例如淘宝借助其进行流数据的收集)

• Sqoop：数据导入导出
  

• Ambari:安装部署工具
  

2.3Linux和Hadoop的安装

2.3.1安装Linux虚拟机

2.3.2安装Hadoop

2.4Hadoop集群的部署和使用

主要是考虑两大核心组件的底层硬件的需求是啥

（其余感觉比较散，之后看情况补充）

三、分布式文件系统HDFS

3.1 分布式文件系统HDFS简介

HDFS：小弟不才，解决了两大核心问题之一

• 分布式文件系统
  数据量上去了，进而有了分布式
  

集群是个物理形态，分布式是个工作方式。
只要是一堆机器，就可以叫集群，他们是不是一起协作着干活，这个谁也不知道；一个程序或系统，只要运行在不同的机器上，就可以叫分布式，C/S架构也可以叫分布式。集群一般是物理集中、统一管理的，而分布式系统则不强调这一点。所以，集群可能运行着一个或多个分布式系统，也可能根本没有运行分布式系统；分布式系统可能运行在一个集群上，也可能运行在不属于一个集群的多台（2台也算多台）机器上。
作者：Wang Xu
链接：https://www.zhihu.com/question/20004877/answer/13632513
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

• HDFS实现目标：
  • 兼容廉价的硬件设备
    以企业可以承担的成本，可以使用普通的PC机构成集群。设计之初，就要考虑到能够兼容廉价的硬件设备。
  • 实现流数据读写
    区别于传统文件系统（以块数据为单位）之处。满足批量处理数据或海量数据处理的需求。
  • 支持大数据集
  • 支持简单的文件模型
    为支持高效的数据读写，对文件进行了简化。牺牲了相关性能，但获得了批处理特性。只允许追加，不允许修改。
  • 强大的跨平台兼容性
    基于Java实现
    
• HDFS自身的局限性
  • 不适合低延迟数据访问
    是为了面向大规模的流式读写，一次读大批量或者全部数据。所以当想要读某条数据时，需要读大量数据，再筛选出来，故实时性不高（HBase具备随机读写特性，实时性处理需求）。
  • 无法高效储存大量 小文件
    小文件多，索引结构庞大，进而索引效率低
  • 不支持多用户写入及修改文件
    只允许追加，不允许修改
    

3.2HDFS相关概念

块

默认一个块（block）的大小为128MB（HDFS的块这么大主要是为了最小化寻址开销），要在HDFS中存储的文件可以划分为多个分块，每个分块可以成为一个独立的存储单元。
与本地磁盘不同的是，HDFS中小于一个块大小的文件并不会占据整个HDFS数据块。

• 设计目的：
  • 支持面向大规模数据存储
  • 降低分布式节点的寻址开销

块并非一味的大就是好

• 优点：

  • 支持大规模文件存储
    可以把大文件进行切割，各个小块可以分布式的存储在不同机器上，则可以突破单机存储容量上限。

  • 简化系统设计
    使用抽象的块，而不是整个文件作为存储单元，可以简化存储管理，使得文件的元数据可以单独管理。

  • 适合数据备份
    冗余备份。数据块非常适合用于数据备份，进而可以提供数据容错能力和提高可用性。每个块可以有多个备份（默认为三个），分别保存到相互独立的机器上去，这样就可以保证单点故障不会导致数据丢失。

HDFS集群的节点分为两类：namenode和datanode

以管理节点-工作节点的模式运行，即一个namenode和多个datanode.

• namenode管理节点：整个HDFS集群的管家
  （管理文件系统命名空间，管理文件系统树以及树中的所有目录和文件）
  
  
  FsImage不维护文件在具体的哪个节点（是通过数据节点和名称节点运行过程中不断地沟通，来实时维护）
  

保存元信息的种类有：
* 文件名目录名及其之间的层级关系
* 文件目录的所有者及其权限
* 每个文件块的名及文件由哪些块组成

第二名称节点Secondary Namenode：名称节点的冷备份，实现对EditLog的处理

• datanode工作节点：存储实际数据（保存到本地的Linux文件系统中）

3.3 HDFS体系结构

中从架构。

• 机架之间通过光纤高速连接
  
• 缺点（第四点因为Secondary Namenode是冷备份）
  （冷：不能保证一发生故障就能立刻顶上来）
  
  

3.4 HDFS存储原理

底层架构在廉价的集群之上，而廉价的机器们最致命的缺点就是会不断出故障。所以HDFS中的数据都被冗余保存，一般默认为三份（当然也可以自定义其他数值）

• 数据冗余保存的优点
  • 加快数据传输速度
    并行传输
  • 检查数据错误
    互为参照
  • 保证数据可靠性

存放策略：
第一个副本：存放在上传这个文件的节点上（无需再通过网络传到其他机器上），若提交请求不是来自集群内部而是外部的某个数据节点时，存放在一个磁盘不太满，CPU不太忙的节点
第二个副本：存放在另一个机架上（不同于第一个的机架）
第三个副本：存放在第一个机架的不同节点上
（若还有其他副本，可通过随机算法）

数据读取

• 机架内部通信代价很小且较快
  

3.5HDFS数据读写过程

3.5.1 HDFS读数据过程

1. client访问NameNode，查询元数据信息，获得这个文件的数据块位置列表，返回输入流对象。
2. 就近挑选一台datanode服务器，请求建立输入流 。
3. DataNode向输入流中中写数据，以packet为单位来校验。
4. 关闭输入流
   其中，方框内对用户屏蔽，系统自动封装完成。
   

hadoop中设置了通用文件系统 抽象基类FileSystem

• 通常用的方法有
  • open返回的是输入流
    

3.5.2 HDFS写数据过程

• 写入时，采用流水线复制

1. 客户端向NameNode发出写文件请求。
2. 检查是否已存在文件、检查权限。若通过检查，直接先将操作写入EditLog，并返回输出流对象。
   （注：WAL，write ahead log，先写Log，再写内存，因为EditLog记录的是最新的HDFS客户端执行所有的写操作。如果后续真实写操作失败了，由于在真实写操作之前，操作就被写入EditLog中了，故EditLog中仍会有记录，我们不用担心后续client读不到相应的数据块，因为在第5步中DataNode收到块后会有一返回确认信息，若没写成功，发送端没收到确认信息，会一直重试，直到成功）
3. client端按128MB的块切分文件。
4. client将NameNode返回的分配的可写的DataNode列表和Data数据一同发送给最近的第一个DataNode节点，此后client端和NameNode分配的多个DataNode构成pipeline管道，client端向输出流对象中写数据。client每向第一个DataNode写入一个packet，这个packet便会直接在pipeline里传给第二个、第三个…DataNode。
   （注：并不是写好一个块或一整个文件后才向后分发）
5. 每个DataNode写完一个块后，会返回确认信息。
   （注：并不是每写完一个packet后就返回确认信息，个人觉得因为packet中的每个chunk都携带校验信息，没必要每写一个就汇报一下，这样效率太慢。正确的做法是写完一个block块后，对校验信息进行汇总分析，就能得出是否有块写错的情况发生）
6. 写完数据，关闭输输出流。
7. 发送完成信号给NameNode。
   （注：发送完成信号的时机取决于集群是强一致性还是最终一致性，强一致性则需要所有DataNode写完后才向NameNode汇报。最终一致性则其中任意一个DataNode写完后就能单独向NameNode汇报，HDFS一般情况下都是强调强一致性）

3.6HDFS编程实践

(点开本节标题链接，详细展开)

3.6.1HDFS常用命令

启动Hadoop（启动失败的解决之一）

cd /usr/local/hadoop # 到Hadoop安装目录
./sbin/start-dfs.sh #启动hadoop
jps # 看是否三个进程都已启动，则确定hdfs启动成功

3.6.2安装Eclipse

3.6.3 HDFS常用Java API及应用实例

四、 分布式数据库HBase

4.1 HBase简介

HBase是BigTable的开源实现。
BigTable

• 引入目的：解决谷歌公司内部大规模网页搜索问题
  • 网页搜索的两种方式
    
• 实现
  不是直接在底层磁盘上存储，而是架构在谷歌分布式文件系统GFS之上。
  
• 优点
  • 性能好，可支持PB级别的数据
  • 可扩展性好

---

HBase是高可靠，高性能，面向列，可伸缩的分布式数据库。最主要的特点是用来存储半结构化和非结构化的松散数据

• 产生原因：为了满足不断增长的数据存储需求
  

• HBase vs BigTable
  

• HBase vs 关系数据库

  • 数据类型
    HBase对于数据类型不加以区分，都存储为字符数组

  • 数据操作
    没有繁多的数据操作，提高效率

  • 存储模式
    基于列存储

  • 数据索引
    

  • 数据维护
    不存在常规的替换操作，生成新的版本之后，旧版本依然保留。只有当过了设置的参数期限之后，才会在后台清理掉。

  • 可伸缩性
    

• 访问接口
  

---

• what
  Hbase是一种分布式存储的数据库。
  • Hbase是一种NoSQL数据库，即它和传统的RDBMS数据库那种支持SQL作为查询语言 不同
  • 技术上讲，它更像是分布式存储而非分布式数据库，缺少很多RDBMS系统的特点。如列类型，辅助索引，触发器和高级查询语言等待。
• 特点
  • 强读写一致
    但不是“最终一致性”的数据存储，使得它很适合高速的计算聚合
  • 自动分片
    通过Region分散在集群中，当行数增长的时候，Region也会自动的切分和再分配
  • 自动的故障转移
  • Hadoop/HDFS集成，和HDFS开箱即用，不用太麻烦的衔接
  • 丰富的“简洁、高效”API
    Thrift/REST API,Java API
  • 块缓存,布隆过滤器，可以高效的列查询优化
  • 操作管理
    Hbase提供了内置的web界面来操作，还可以监控JMX指标
• when
  • 数据库量要足够多
    数据量小的话，真正能工作的机器量少，剩余的机器都处于空闲的状态。
    因此，当有十亿及百亿行数据，适合Hbase;
    当只有几百万行甚至更少的数据量，适合RDBMS
  • 不需要辅助索引，静态类型的列，事务等特性。
    一个已经用RDBMS的系统想要切换到Hbase,则需要重新设计系统
  • 保证硬件资源足够
    每个HDFS集群在少于5个节点的时候，都不能表现得很好。因为HDFS默认的复制数量是3，再加上一个Name Node（上一章的老朋友）
    Hbase在单机环境也能运行，但在开发环境的时候使用就好。

4.2 HBase数据模型

HBase是一个稀疏的多维度（四个维度（行键，列族，列限定符，时间戳））的排序的映射表。

其中：

• 列限定符也可以称为列
• 一个行可以有一个行键和任意多列
• 每一个值都是未经解释的字符串也就是Bytes数组
• 列族可以支持动态扩展，且保留旧的版本（追加时间戳）。

面向行的存储

• 缺：分析某个特征时都是针对一个列去分析，每次取出一整行代价大
  

4.3 HBase的实现原理

• HBase功能组件
  
  
  

• 表和Region
  所谓“分裂”只是把指向改变，而不改变实际的物理存储
  ⇨从而保证快速拆分
  
  

• Region的定位
  
  类似多级目录的思想，顶级目录只能有一张（408还是有点子用的）
  

三级寻址可采用缓存，加快寻址速度。但是随着数据更新，缓存可能失效。

4.4 HBase运行机制

• HBase的系统架构
  HBase是借助在Hadoop之上的HDFS分布式文件存储系统之上，并非直接和底层磁盘进行数据交互。
  
  他们分别的功能：
  
  主服务器的功能
  

• Region服务器的工作原理
  用户读写数据过程：

  1. 写数据
  • 在分配到的相应Region服务器下执行
  • 写到写缓存之中，写MemStore（不是直接写到磁盘中，考虑到读写开销咯（408好像真的没白学+1））
  • 为了保证数据的安全和可恢复性（联想数据库中的恢复机制是冗余），写日志。其中HLog就是日志功能。只有当HLog的内容写回到磁盘之后，才允许写回的数据返回到客户端。
    
    （该图从写入数据考虑的因素考虑，箭头指示并非数据流向和直接目的）
  2. 读数据
     同样先到分配的Region服务器下，通过MemStore找缓存，缓存中没有再去访问磁盘中的相关数据。
     
  • 缓存的刷新
    • 系统周期性地把MemStore缓存中的内容写到磁盘的StoreFile文件中，清空缓存，并在Hlog里面写入一个标记
    • 每次刷写都生成一个新的StoreFile文件
      ⇨每个Store包含多个StoreFile文件
    • 每个Region服务器都有一个自己的HLog文件，每次启动都检查该文件，确认最近依次执行缓存刷新之后是否发生新的写入操作
      • 若发现更新
        ⇨先写入MemStore,再刷写到StoreFile，最后删除旧的HLog文件，开始为用户提供服务

• Store的工作原理

  • StoreFile的合并和分裂
    每次刷写都会产生一个新的StoreFile，当StoreFile过多的话必然影响查找的速度。所以当达到一定的阈值之后就会合并（合并是需要一定的开销）
    
    当合并所得的StoreFile大于相应阈值后，又会进行分裂
    

• HLog的工作原理

  • 引入：HBase是通过构建一个集群去管理数据，是个典型的分布式环境，且底层是非常廉价的低端机
    ⇨容易出故障（Zookeeper来检测故障，协同管理小能手）
    ⇨借助写日志备份，以实现故障后的恢复
    HBase为每个Region服务器配备了公共的HLog。每个Region服务器之下所有的Region公用这个公共的HLog。（to提高效率，主要是写性能）
    每次用户更新数据时，需要先写入日志后，再写入MemStore缓存，最后当MemStore中的内容刷写到磁盘。
    

4.5 HBase应用方案

• HBase在实际应用中的性能优化方法
  如果想要吧时间靠近的数据都存一起，可以把时间戳作为行键的一部分。
  时间戳通常按升序排序，长整型变量64位
  ⇨越到后时间戳就会越来越大
  ⇨通过把长整型-时间戳作为行键
  ⇨保证了最新的数据很快能够命中加速读取
  

• 实时性要求高，可采取的措施

• HBase怎么检测性能

  • Master-status
    是HBase自带的工具通过Web界的方式，可查询HBase运行状态，直接在浏览器中输入地址就可以查看。
    
  • Ganglia

• HBase之上如何构建SQL引擎和HBase二级索引
  

4.6 HBase的安装和编程实践

五、NoSQL数据库

5.1 NoSQL数据库

• 特点
  • 灵活的可扩展性
    有非常强的水平扩展性，可支持在多个节点上进行水平扩展。therefore,可支持海量的数据存储
  • 灵活的数据模型
    不同于SQL数据库需要满足严格的数据定义，NoSQL可以动态增加相关的列族
  • 和云计算的紧密结合
    云计算的突出优点之一是可根据负载的变化对底层的IT基础设施进行动态地伸缩。NoSQL可充分的利用底层云计算的设施（产生之初就基于云计算背景）。
• 关系数据库vs非关系数据库的比较
  • 传统的关系数据库
    • 优
      
    • 缺

      • 无法满足海量数据的管理需求
        

      • 无法满足高并发的需求
        

      • 无法满足高可扩展性和高可用性的需求
        

• NoSQL
  

5.2 NoSQL与关系数据库的比较

• 不同角度的比较

  • 数据库原理

    • 关系数据库：具有完备的关系代数理论作为基础√
    • NoSQL数据库：NoSQL数据库缺乏理论基础

  • 数据规模

    • 关系数据库：很难实现横向扩展，纵向扩展非常有限
    • NoSQL数据库：具有非常好的水平可扩展性√

  • 数据库模式

    • 关系数据库：要定义严格的数据库模式，且要严格遵守事先定义的数据库模式
    • NoSQL数据库：数据模型非常灵活√

  • 查询效率

    • 关系数据库：适当数量级查询效率高，数量级增大查询效率下降√
    • NoSQL数据库：未构建面向复杂查询的索引查询性能差

  • 事务一致性

    • 关系数据库：遵循ACID事务模型可以保证事务强一致性√
    • NoSQL数据库：只能保证事务的最终执行，而不能保证事务强一致性

  • 数据完整性

    • 关系数据库：具有保证完整性的完备机制
    • NoSQL数据库：不能实现完整性约束

  • 可扩展性

    • 关系数据库：扩展性一般较差
    • NoSQL数据库：水平扩展性非常好

  • 可用性

    • 关系数据库：随着规模增大，为了保证严格的一致性，可用性方面就被削弱了
    • NoSQL数据库：具有非常好的可用性，能够在短时间内迅速返回所需的结果

  • 标准化

    • 关系数据库：遵循SQL标准，标准化较为完善
    • NoSQL数据库：未形成通用的行业标准

  • 技术支持

    • 关系数据库：很多都是商业数据库，可获得强大的技术和后续服务支持
    • NoSQL数据库：很多都是属于开源产品，处于整个发展的初期阶段

  • 可维护

    • 关系数据库：需要管理员维护
    • NoSQL数据库：没有成熟的基础和实践操作规范，维护较为复杂

• 应用不是非此即彼，通常采用混合型架构
  

• NoSQL数据库
  

• 关系数据库

  • 优点
    • 具有非常完备的关系代数理论作为基础
    • 有严格的标准
    • 支持事务一致性
    • 可以借助索引机制实现高效的查询
  • 缺
    

5.3 四大类型NoSQL数据库

5.3.1键值数据库和列族数据库

5.3.1键值数据库和列族数据库

5.4 NoSQL数据库的理论基石

5.5 从NoSQL到NewSQL数据库

5.6 文档数据库MongoDB

本周课程没完成，继续见