本文的主要介绍大数据原理与技术, 对大数据的基本概念, 大数据处理架构, Hadoop平台及其生态系统进行概要性的介绍. 本文的主要内容都基于中国大学MOOC上的<<大数据技术原理与应用>>课程, 并且结合Hadoop官网上的文档进行适当补充.

概述

数据产生的三个阶段

  1. 运营式系统阶段: 通过各种运营系统产生数据
  2. 用户原创内容阶段: 博客,微博等各种用户可以发布数据的平台产生数据
  3. 感知式阶段: 物联网设备的大量普及,各种传感器产生数据

大数据的特征

大数据的特征可以使用5V来概括

特征 含义
大量化(Volume) 数据流跃升, 数据量大
多样化(Variety) 种类繁多, 来源各异
快速化(Velocity) 实时响应要求
价值密度低(Value) 大数据的价值往往呈现稀疏性的特点
可信性(Veracity) 数据可信性和可用性

大数据的思维方式

  1. 全样而非抽样
  2. 效率而非精度
  3. 相关而非因果

在以往的数据处理过程中, 由于使用抽样, 因此对计算过程要求有一定的精度, 否则可能随着计算过程不断的放大误差. 在大数据中, 由于对全体数据进行处理, 因此往往不再要求算法精度, 反而对算法的执行效率有更高的要求.

云计算

云计算是指通过网络以服务的方式向用户提供非常廉价的IT资源. 云计算的主要内容就是解决分布式存储和分布式处理的问题. 大数据时代的海量数据只能通过集群来进行存储和处理.云计算的典型特征是虚拟化和多租户. 用户不需要自己购买机房, 而是直接购买相关的服务.

大数据处理架构介绍

Hadoop是Apache基金会下的一个开源的分布式计算平台. Hadoop实际上包含了一系列的组件.

Hadoop架构

Hadoop大致有如下的几大部分组成:
Hadoop架构

每个部分的基本功能如下所示, 具体的细节和使用在后续各章节分别介绍.

名称 作用 名称 作用
HDFS 分布式文件存储 TeZ 分析优化工具
YARN 资源调度 Pig 类SQL的脚本语言
MapReduce 基于磁盘的分布式计算 Oozie 作业流调度系统
Spark 基于内存的分布式计算 Zookeeper 分布式协调服务
Hive 数据仓库 Flume 日志收集分析框架
HBase 非关系型的分布式数据库 Ambari 集群部署和监控工具
Sqoop 与传统数据库传递数据

Hadoop安装与配置

Hadoop平台上有很多项目, 这些项目基本都是独立的, 需要到各个项目的官网上下载相关的代码.

在学习Hadoop的过程中, 由于国内的文档多数比较陈旧, 存在很多兼容性问题, 因此安装时推荐安装官网教程操作. 官方的文档比起各种转述或者翻译的文章, 更具有权威性, 内容的正确性更有保证.

HDFS简介

Hadoop分布式文件系统(Hadoop Distributed File System, HDFS), 是Hadoop平台下的分布式文件系统, 主要以分布式集群的方式来实现海量数据的存储. HDFS是Google文件系统(Google File System, GFS)的开源实现, 关于GFS的有关内容参考阅读笔记.

核心概念

名称 作用
块 与普通的文件系统的块含义类似,是数据存储的基本单位
名称节点 整个集群的主节点, 管理了所有文件的位置信息
数据节点 实际存放数据的节点
FsImage 保存系统文件树和文件的属性信息, 包括访问与修改时间, 访问权限等
EditLog 记录了对数据的操作记录

几点补充

  1. 与普通的文件系统相比, 一个默认的HDFS块大小为64MB
  2. 较大的块大小有助于减少索引空间., 但由于MapReduce使用块作为基本处理单位, 因此如果块过大, 又会导致并行性降低
  3. HDFS是基于文件的系统, 数据保存在磁盘上, 但名称节点的元数据由于频繁访问, 因此保存在内存之中

EditLog的作用

HDFS文件的元数据保存在内存之中, 同时有关的信息也同时存储到FsImage之中. 如果每次修改文件信息后, 都同步的将修改写到FsImage之中, 就会导致大量的磁盘读写, 限制了程序的性能.

因此因此在HDFS中, 所有的操作都是记录到EditLog之中, 而FsImage不发生改变.

第二名称节点

在名称节点中, 虽然FsImage不发生改变, 但EditLog依然会不断增大. 在HDFS的设计中, 每次启动时会将EditLog与FsImage合并, 但如果长时间运行, 当EditLog增大到一定程度以后, 会同样的影响程序性能. 因此HDFS引入第二名称节点.

第二名称节点定期的与名称节点通信, 请求名称节点停止项EditLog写入. 名称节点受到请求后, 创建一个edits.new的文件, 将后续更新写入此文件之中. 第二名称节点将原来的EditLog文件和FsImage文件下载dao本地进行合并. 第二名称节点将合并的FsImage文件返回给名称节点. 名称节点将原有的FsImage文件替换并且将edits.new更名为EditLog

通过上述操作, 第二名称节点实现了FsImage和EditLog的合并, 而保存在第二名称节点上的FsImage又可以作为备份文件, 在名称节点出现故障时用来恢复状态.

HDFS 1.0的局限性

  1. 命名空间限制: 名称节点保存在内存中,因而存储规模受单机内存大小限制
  2. 性能瓶颈: 整个系统的吞吐量受单个节点的性能限制
  3. 隔离性: 只有一个名称节点, 各个应用之间不能隔离
  4. 集群可用性: 名称节点出现故障整个集群失效

HDFS存储机制

  1. 冗余存储机制
    由于底层架构在廉价的设备上, 因此设备出现故障是常态, HDFS引入冗余机制, 将数据以块为单位进行冗余保存.此外, 由于有多个副本, 因此还可以加快传输速度.

  2. 数据存储策略

第一个副本存放在发起请求的节点上, 从而减少网络传输. 后续副本存放在不同机架和不同节点的设备上, 从而在减少网络传输和提高数据安全性之间取得一个平衡

MapReduce编程

MapReduce的基本策略是分而治之, 把庞大的数据切分为多个独立的小分片, 然后为每个分片启动一个单独的map任务, 最终通过多个map任务, 并行的在多个机器上处理.

MapReduce过程中有一个重要的理念, 即 计算向数据靠拢而不是数据向计算靠拢. 在需要一个计算时, 将应用程序分发到数据所在的机器, 从而绕过网络带宽对数据传输的限制, 极大的提高总体的处理效率.

更多关于MapReduce概念性的内容, 可以参考关于Google的论文《MapReduce：Simplified Data Proessing on Large Clusters》的阅读记录. 本文接下来介绍MapReduce在架构方面的内容.

体系结构

Client

  • 提交用户编写的程序
  • 查看作业运行状态

JobTracker

  • 负责资源的监控和作业调度
  • 监控底层其他的TaskTracjer以及当前Job的状态
  • 探测到失败时进行任务转移
  • 跟踪任务进度和资源使用量

TaskTracker

  • 接收JobTracker发送的任务, 执行具体的任务
  • 监控自身的资源使用情况, 使用心跳方式发送给JobTracker
  • 把资源分成若干个slot,, 即map类型的slot和reduce类型的slot
  • 统计slot占用使用量衡量资源占用率

Task

  • 分为map任务和reduce任务
  • 一台物理设备可以同时运行两种类型的任务

工作流程

分片大小

分片大小和HDFS的块大小并没有直接联系, 但是为了减少不必要的数据传输, 通常使分片大小和块大小相等.

map任务数量确定

由于每个分片都需要分配一个map任务, 因此map任务数量等于分配数量

reduce任务数量确定

通常依据系统可以提供的reduce的slot数量决定reduce任务数量,且实际数量略小于最大可用数量.

Shuffle过程

数据流动过程

  1. 数据首先通过HDFS系统提取出来,进行map任务
  2. map任务执行结果写入缓存
  3. 缓存慢后进行溢写操作,溢写过程执行分区,排序和合并操作
  4. 多个磁盘文件进行归并
  5. reduce机器取走相应分区的数据
  6. reduce函数进行处理,并最终输出到HDFS

Map端的Shuffle过程

  1. 数据输入和执行任务
  2. 转换的键值对写入缓存
  3. 溢写过程
    • 达到溢写比后启动溢写操作
    • 分区: 按照不同的reduce任务分到不同的区
    • 排序: 对分区的数据按照字典序排序
    • 合并: 多个键值对合并成一个键值对(不是必须的,由用户定义)
  4. 文件归并: 将多个溢写文件归并成一个大的文件(最终文件时分区且排序的)

Reduce端Shuffle过程

  1. 从Map机器领取需要的数据
  2. 归并(生成key-valuelist)后合并(合并value值)
  3. 将数据输入给Reduce任务

MapReduce程序执行过程

  1. 程序部署: 将程序分发到不同的机器
  2. 不同的机器分别执行map任务和reduce任务
  3. 读数据,生成键值对
  4. 本地写数据, 将缓存的数据写入磁盘
  5. 远程读数据, 执行reduce任务机器获取相关数据
  6. 写数据, 写入输出结果

HBase简介

HBase是BigTable的开源实现. HBase是一个 高可靠, 高性能, 面向列的可伸缩的分布式数据库. HBase主要用于存储非结构化和半结构化的数据, 是对HDFS和MapReduce在实时性上的扩展, 同时弥补了传统数据库在大量数据上无法应对的问题.

HBase不保存数据类型, 全部都是原始数据, 由应用程序去解释数据类型. 不同于关系数据库, Hbase是基于列的存储. HBase不存在替换操作, 定时的清理无效数据. HBase构建在HDFS之上, 使用集群保存数据, 因此很容易扩展设备.

传统数据库的问题

传统的数据库在面临大量数据时, 有两个主要问题

  1. 数据库不便于分布式扩展, 难以面对海量的数据读写请求
  2. 数据库模式无法轻易改变, 无法满足数据类型快速变化的需求

实际上, HBase的产生, 也就是对上述两个问题的解决方案.

HBase访问接口

HBase本身使用Java开发, 因此可以通过JavaAPI进行访问. 此外HBase还提供基于shell的命令行工具, 和基于网络的API. 最后还可以通过构建在HBase之上的类SQL脚本语言Pig或者数据仓库产品Hive进行访问.

HBase数据模型

HBase中的数据需要通过行键, 列族, 列限定符和时间戳四个元素来唯一确定.

HBase的概念视图如下所示:
概念视图

一行可以有一个行键(RowKey)和若干列族, 每个列族可以包含若干列, 使用列族:列限定符来指定具体的一列,通过时间戳区分新旧版本的数据. 必须使用行键, 列族, 列限定符和时间戳才能唯一的确定一个数据.

从概念视图来看, 由于每次更新并不是更新一行的所有数据, 因此存储是稀疏的.

HBase的物理视图如下所示:
物理视图

HBase采用以列族为单元的存储方式, 从而避免了概念视图过于稀疏的问题.

效率与规范化

根据关系数据理论, 如果不准守规范化的要求, 可能会导致数据冗余, 更新异常, 插入异常, 以及删除异常. HBase中存储的数据并没有任何的规范化的要求, 主要有两个原因：

  1. 存储空间价格快速降低, 可以接受一定程度的数据冗余, 相反此时查询时间更加重要, 遵守规范化理论导致在查询时通常需要进行多表连结操作, 在面对海量数据时, 连接操作低效且耗时
  2. HBase构建在HDFS上, 本质上只插入新数据, 处理的海量数据也往往也不会再被修改, 从而可以一定程度上容忍更新异常, 插入异常和删除异常

HBase系统结构

HBase系统结构

组件 功能
客户端 为客户提供访问接口
ZooKeeper服务器 提供协同管理, 保证任意时刻只有一个Master服务器运行
Master服务器 维护分区信息、维护Region服务器列表和状态、负载均衡
Region服务器 实际维护和管理数据, 与客户端直接通信

HBase三级访问结构

三级访问结构

HBase最初有一个.META表, 用于存放Region ID和服务器ID的映射关系..META表本身也保存于Region中, 因此一定容量以后也会无法被一个Region保存, 这个时候使用类似二级页表的方法, 使用-ROOT-表保存.META表的位置. HBase设计时规定只能有一个-ROOOT-文件, 使用Zookeeper文件保存-ROOT-表的位置.

与页表的缓冲机制类似, 客户端也会对位置信息进行缓存, 从而减少寻址的时间.

存储过程

  • 在HBase中每个族列对应一个Store, 保存在磁盘上的Store称为StoreFile文件.
  • 写入数据是先写入MemStore,并且将记录写入HLog.
  • 读取数据时先访问MemStore(因为其中可能包含更新后的数据), 如果没有找到,再去访问磁盘.
  • 服务器周期性的将MemStore中的数据刷写到磁盘中,然后清空MemStore并且对Hlog进行标记. 每次刷写都产生新的StoreFile文件.
  • 多个StoreFile可以合并成一个更大的StoreFile,进一步增大,达到Region上限后又会触发分裂操作. 这也是唯一的Region分裂操作.

HBase的Shell指令

操作 指令 含义
创建表 create 'tempTable','f1', 'f2', 'f3' 创建表tempTable,其中包含列族f1,f2和f3
显示表 list 显示所有的表
浏览记录 scan 'tempTable' 浏览表中所有的数据
添加记录 put 'tempTable','r1','f1:c1','hello dblab' 向tempTable的r1行,f1族c1列放入数据’hello dblab’
查询记录 get 'tempTable','r1', {COLUMN=>'f1:c1'} 获得tempTable的r1行,f1族c1列的数据
删除表 disable 'tempTable' drop 'tempTable' 先令表失效之后才能删除表格

注意:

  • 不需要事先声明列的名称,可以直接添加新的列
  • 每次只能为一个表的一行的某一列添加数据

NoSQL简介

NoSQL最初是表示反对SQL, 后来发现关系数据库和非关系数据库各有优势, 因此NoSQL现在是Not Only SQL的缩写.

NoSQL数据库与传统数据库

NoSQL特点

  • 具有灵活的可扩展性, 可以对多个节点扩增
  • 灵活的数据模型, 可以动态变换,甚至没有模式
  • 与云计算紧密结合, 可以充分利用底层硬件的伸缩性

传统数据库的缺陷

  • 无法满足海量数据管理需求
  • 无法满足高并发需求(用户数据必须实时生成)
  • 无法满足高可扩展性和高可用性的需求

NoSQL兴起的原因

  • 关系数据库无法满足Web2.0的需求
  • 数据模型局限性
  • Web2.0关系型数据库许多特性没有被发挥(例如事务机制)

Web2.0的特点

  • 不需要严格的事务机制
  • 不需要严格的实时性
  • 不需要复杂的SQL查询(去规范化)

NoSQL数据库分类

NoSQL数据库现在有4大类, 各类基本特征如下所示

数据库类型 特点 常见产品
键值数据库 存储数据是一堆键值对 Redis,Memcached,SimpleDB等
列族数据库 数据按照列存储 BigTable,HBase, Cassandra等
文档数据库 存储键值对且值是文档 MongoDB, CouchDB等
图数据库 基于图结构的数据库 Neo4j

键值数据库

  • 键是字符串对象, 值是任意类型数据
  • 扩增性好, 读写性能高
  • 适合简单存储, 高性能读写的场景, 如配置文件,购物车等
  • 适合作为Web数据的缓冲层
  • 无法存储结构化信息, 条件查询效率低
  • 不适合按值查询或者关系查询, 可能无法回滚

列族数据库

  • 适合分布式存储和管理
  • 适合需要动态字段的以及可以运行短期不一致的应用
  • 查找速度块,可扩展性强

文档数据库

  • 本质是键值数据库,且值是一个文档
  • 文档可以根据数据库内容自描述, 通常使用JSON格式
  • 更好的并发性, 修改属性通常只用修改一个文件
  • 不支持事务机制

图数据库

  • 专门用于具有高度相关的数据,如社交网络,模式识别,推荐系统等
  • 支持图论的各种复杂算法
  • 使用场景有限

NoSQL三大基石

CAP理论

  • 一致性(Consistency): 任何一个读操作总能读到之前完成的写操作的结果
  • 可用性(Availability): 可以快速的获得数据
  • 分区容忍性(Partition tolerance): 当某一部分节点出现错误是,分离的系统依然可以正常工作

理论和实践证明CAP不可能同时满足, 三者只能取其二
CA: 所有事务都放在同一机器,避免分区问题
CP: 使用网络分区, 数据一致后再取数据
AP: 立即获得数据, 忽略一致性

传统数据库一般采用CA, HBase采用CP

Base理论

Basically Avaible Soft state和Eventual consistency的简写, 缩写是BASE,即”碱” 与关系型数据库中的ACID(酸)对应

  • 基本可用: 部分出错不影响其他分区
  • 软状态: 状态可以有一定的滞后性
  • 最终一致性: 数据最终能到达一致

NewSQL

原有SQL无法满足各种新的业务场景的需求, 因此在不同的领域对SQL产生了一些分化. NewSQL是同时具备OldSQL和NoSQL数据库的优点. 既保证了事务一致性有保证了非常好的可扩展性.

MonogoDB数据库

MongoDB是文档数据库, 其中的值部分是二进制的JSON格式,称为BSON.
可以针对任何属性建立索引,从而可以依据值进行查询

传统数据库术语与mongoDB数据库术语对应关系入下表所示

传统数据库 MongoDB
database database
table collection
row document
column field
index index

注意:在MongoDB同一个集合的文档结构不需要相同,同名字段也不需要内容相同

数据仓库

数据仓库是一个面向主题的, 集成的, 相对稳定的, 反应历史变化的数据集合, 用于支持管理决策.

Hive

  • 不提供存储
  • 只提供编程接口
  • 借助于HDFS和MadReduce完成数据存储和计算
  • 使用HiveQL语言完成分析任务

应用场景

  • Pig 主要用于数据的源的转换操作
  • Hive 主要用于数据的批处理分析

与传统数据的区别

  • Hive只支持数据的批量导入
  • Hive不支持数据更新
  • Hive执行延迟高,扩展性较好

Hive对外接口

  • CLI: 命令行工具
  • HWI: Hive Web Interface, Hive的Web接口
  • JDBC/ODBC: 开放数据库接口
  • Thrift Server: 基于Thrift的接口

Impala

  • 提供类似Hive的功能
  • 性能比Hive高3~30倍
  • 支持SQL查询
  • 不能独立运行,依赖Hive的元数据
  • 使用分布式查询引擎直接对HDFS或者HBase查询,而不需要进行转化

Impala系统架构

  • Impalad: 查询任务
    • Query Planner
    • Query Coorddinator
    • Query Exec Engine
  • State Store 元数据管理状态信息维护
  • CLI 用户访问接口

Hadoop再探讨

最初版本Hadoop的缺陷

  • 抽象层次低, 需要人工编码
  • Map/Reduce表达能力有限
  • 需要开发者管理作业之间的关系
  • 无法看到整体的逻辑
  • 迭代执行效率低
  • 实时性差

Hadoop2.0的改进

  • 设计HDFS HA, 提供名称节点的热备份机制
  • 设计HDFS Federation管理多个命名空间
  • 设计新的资源管理框架Yarn(Yet Another Resource Negotiator)
  • 使用Pig解决抽象层次低的问题
  • 使用Spark解决实时性差,迭代效率低的问题
  • 使用Ooize解决不同的作业协同问题
  • 使用Tez支持有向无环图的问题,减少重复操作
  • 使用Kafka进行分布式发布订阅消息,实现对各种组件的数据交换

HDFS HA

  • 同时运行两个名称节点,一个处于活跃状态,一个处于待命状态
  • 使用Zookeeper协同两个节点的运行
  • 使用共享存储系统保持两个名称节点的数据(Editlog)同步
  • 底层的数据节点需要同时向两个名称节点同时汇报状态, 从而保证映射表信息的同步

HDFS Federation

  • 支持同时运行多个名称节点,各名称节点独立工作
  • 通过挂载方式访问不同的命名空间
  • 解决了HDFS名称接待的扩展问题
  • 使用多个名称节点同时服务, 提高了系统的吞吐量
  • 多个名称节点为系统提供了良好的隔离性
  • 注意: 各名称节点是联盟关系, 因此不能解决单点故障的问题

Yarn

原有架构的缺陷

  • 使用JobTracker进行管理, 存在单点故障
  • 由于JobTracker管理过多, 导致任务繁忙
  • 任务分配只考虑数量,容易内存溢出
  • 资源划分不合理, Map任务和Reduce任务的slot不可通用

Yarn设计思路

对原有JobTracker功能拆分, Yarn作为纯粹的资源调度框架

ResourceManager功能

  • 处理客户端请求
  • 监控NodeManager
  • 启动/监控ApplicationMaster
  • 资源分配与调度

ApplicationMaster

  • 为资源申请资源,分配内部任务
  • 任务调度,监控和容错

NodeManager

  • 管理单个节点
  • 处理ResourceManager指令
  • 处理ApplicationMaster指令

参考资料

本文内容主要是基于中国大学MOOC上厦门大学开设的<<大数据技术原理与应用>>课程. 该课程整合了很多资源, 因此相比于在网络查阅各种资料, 更加适合初学者学习.

最后更新： 2024年04月24日 15:50

版权声明：本文为原创文章，转载请注明出处

原始链接： https://lizec.top/2018/04/28/%E5%A4%A7%E6%95%B0%E6%8D%AE%E6%8A%80%E6%9C%AF%E5%8E%9F%E7%90%86/