linux hadoop相关

hadoop笔记: hadoop家族概念整理

Posted by Yuna on March 10, 2018

(该笔记创建于16年5月，创建之初仅仅是为了记录，并非博文形式)

Hadoop

  1. hadoop的三种运行模式
    • 单机模式：是Hadoop的默认模式。在这种默认模式下所有3个XML文件均为空。当配置文件为空时，Hadoop会完全运行在本地。因为不需要与其他节点交互，单机模式就不使用HDFS，也不加载任何Hadoop的守护进程。该模式主要用于开发调试MapReduce程序的应用逻辑。
    • 伪分布式模式：也是在单机上运行，但是用不同的java进程模仿分布式运行中的各类节点。
    • 完全分布式模式：Hadoop守护进程运行在一个集群上。

HDFS

  1. HDFS：分布式文件系统
  2. 数据块（block）：文件存储和处理的最小逻辑单元。在HDFS中，块的默认大小是64MB，这是根据磁盘传输速率和寻址时间决定的。文件被拆分成块大小的多个分块进行存储，但是在HDFS中，小于块大小的文件并不会占据整个块的空间。通常每个块会复制多份（默认为3个）到几个独立的机器上存储。
  3. 两类节点：namenode和datanode
    • Namenode：是管理节点，用于存放文件的元数据，如：文件包含哪些数据块，数据块分布在哪些数据节点。
    • Datanode：是工作节点，用于存放真正的数据块
    • secondary namenode：定期同步元数据和日志信息，一旦namenode失效，备用namenode转正，并快速接管它的任务处理客户端请求。在实际中namenode失效的可能性非常低。 hdfs体系结构
  4. 事务日志与映像文件与检查点：hadoop将元数据信息保存在内存中，而映像文件则是内存中元数据在本地磁盘上的副本。当文件系统执行写入操作时，首先会将操作记录在事务日志中，然后更新内存中的元数据。每隔一段时间，从元数据节点会帮助元数据节点将元数据信息更新到硬盘的映像文件中，并刷新事务日志，称为检查点，具体过程如下：
    1. 从元数据节点从元数据节点获取映像文件及旧的日志文件，同时通知元数据节点生成新的日志文件（之后的日志都记录在新文件中，旧文件弃用）
    2. 从数据节点将映像文件加载到内存中，并执行日志文件中的操作，生成新的映像文件
    3. 从数据节点将新的映像文件传回给元数据节点
    4. 元数据节点将旧的映像文件换成新的，日志文件也重新记录（就第一步生成的），使得事务日志大小始终控制在一定范围内。 NameNode启动时的过程类似，只不过是由元数据节点来完成合并操作。
  5. 数据管理策略：每个数据块都存放三份，通常由两份在同一机架的不同节点，另一份在另一机架上。保证当某节点或者某机架发生故障时，都能从其他地方获取到数据库。
  6. 心跳检测：datanode定期向namenode发送状态信息，使得namenode能随时知道各节点的工作状态。
  7. 文件读取过程：通过请求namenode得到文件的元数据，即知道有哪些数据块，存放在哪些节点。再向各个节点请求数据，下载下来后最后组装起来。
  8. 文件写入过程：将文件拆分成块，通知namenode，namenode返回可供写入块的datanode。客户端写入一个块后，通过流水线复制到其他节点，然后向namenode更新元数据，之后再写入下一个块。
  9. HDFS的文件在被删除时，会先被移动到/trash目录里。只要文件还在这个目录里就可以被迅速恢复。超过了时间会被彻底清除。/trash目录里只保存被删除文件的最后副本。
  10. 在HDFS中，没有当前工作目录的概念，也没有cd命令。未带参数的“-ls”命令会默认返回HDFS的“home”目录下的内容（即/user/[用户名]）
  11. HDFS特点：
    • 通过数据备份实现硬件容错
    • 流式的数据访问：一次写入多次读取
    • 高数据吞吐量，不适合存储大量小文件，否则对namenode存储元数据的负荷大。
    • 不适合低延迟的数据访问，若要求低延迟访问，应选择HBase。
    • 不支持多用户写入相同文件，而且写操作通常都是添加在文件末尾，而非任意位置。

MapReduce

  1. MapReduce：并行计算框架。将一个大任务拆分成多个小任务（map），并行执行后，再合并结果（reduce）。 案例分析：找出1000套扑克牌中缺少的一张牌

    扑克牌案例 将1000套牌分成若干份进行map操作，每个map操作统计出每种牌出现的次数。然后按照一定的规则进行交换归约（如：相同牌的点数汇总到同一个reduce中），在reduce中统计出每种牌出现次数的结果。 这其中最重要的是交换规则。

  2. mapreduce框架将输入数据分割成固定大小的片段，并会为每个split（切片）创建一个mapper。通常split的大小应该小于等于HDFS数据块的大小，从而实现本地运算。而reducer的数量则是由用户在mapred-site.xml文件中配置决定。
  3. partition接口：用来根据map的键值对结果及reducer的数量来决定该输出数据要被送往那个reducer处理。默认方法是对key进行hash后取reducer数量的模值。也可以自己定制partitioner。
  4. shuffle过程：数据从map结果输出到reduce输出的过程被称作shuffle。 map输出键值对结果后，先经过partition，确定此键值对应该被送往哪个reducer处理。随后将键值对及partition的结果写入缓冲区中。 当缓冲区的数据达到80%（默认）时，会触发溢写（spill）线程，将缓冲区的数据写入到磁盘当中（每次溢写产生一个溢写文件）。在此过程中会对溢写的数据进行排序（sort）和合并（combine），如果有多个键值对将被送往同一个reducer，则会对他们进行拼接从而减小跟partition相关的索引。此时如果有设置过combiner也会被使用。 当mapper执行完成后，会将所有的溢写文件merge成一个文件。此时对于有相同key值的键值对会merge成一个group。如果有设置combiner，也会用combiner来合并相同的key。到此所有map端工作全部完成 reducer通过RPC向JobTracker获知map task执行完成后，就会向该map节点copy数据到reducer的内存缓冲区中。同时进行merge操作。 merge的形式有三种：内存到内存/内存到磁盘/磁盘到磁盘。默认第一种方式不启用。当内存中的数据量达到一定阈值时，就会启动内存到磁盘的溢写工作。该过程与map端一致，如果有设置combiner也会被使用。 当所有map数据获取完毕后，会启用磁盘到磁盘的合并，即生成最终的一个reducer输入文件。此时整个shuffle过程才结束。
  5. shuffle过程中combiner会被多次执行，并且它的输出是reducer的输入。因此开发人员必须保证combine无论重复执行多少次，结果都一样。一般只应用于combiner输入输出类型完全一致，且不影响reducer最终结果的场景。如累加，求极值。如果用得好，能够提高job的执行效率。
    详细见：http://www.aboutyun.com/thread-7078-1-1.html
  6. Job&Task：一个作业（Job）会被拆分成多个任务（task），每个任务又分为MapTask阶段和ReduceTask阶段。 mapreduce体系结构
    • JobTracker：是管理节点，负责将客户端提交的job任务放到候选队列中，将一个job拆分成多个map任务和reduce任务，分发给下面的TaskTracker，同时监控任务的执行情况和TaskTracker的状态。
    • TaskTracker：做任务的节点，定期向JobTracker汇报任务情况。tasktracker必须运行在datanode上。当要读取的数据就存储在本机节点时，读取数据的开销达到最小（用移动计算代替移动数据的思想）。 mapreduce作业流程 其中对于一个复杂作业可能有多轮的MapReduce任务。
  7. 容错机制：
    • 尝试重复执行
    • 对于检测到计算特别慢的节点，会再找多一台TaskTracker去做同样的计算，最后哪个节点先算完就会中止另外的节点的计算。
  8. java编程中，默认情况下，mapper的输出结果的key和value的类型，与reducer最终结果的类型一致。
  9. slot在mapreduce中是类似资源池的作用。每个任务执行时必须占用一个slot。slot分为mapper slots和reducer slots，由用户根据机器内存及处理器情况进行设置，默认值为2。在集群中，reducer的数目通常略小于集群所有节点的reducer slots总数，且一般不大于mapper的数量（mapreduce默认将每个文件作为一个split）。否则即便reducer没有分配到任何数据，也会被执行。

Hive

  1. 关于HIVE：HIVE是基于hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供类SQL的查询功能。其本质是将SQL转换为MapReduce程序。
  2. 数据库与数据仓库的区别：数据库是面向业务存储，追求的是业务处理中的数据一致性和完整性；而数据仓库是面向分析存储，追求查询性能的优化和复杂分析的效率。数据库遵循范式模型，通常使用行式存储。而数据仓库为反范式，常采用多维模型，使用列式存储。
  3. 读时模式与写时模式
    • 写时模式：数据在写入数据库时对照表的模式进行检查，如发现不符合模式则拒绝加载数据。
    • 读时模式：hive对数据的验证并不在加载数据时进行，而是在查询时进行。 读时模式可以使数据加载非常迅速，因为不需要读取数据进行“解析”。而写时模式有利于提升查询性能。
  4. HIVE与HADOOP的关系： hive与hadoop的关系

  5. hive与传统数据库对比：

      hive RDBMS
    查询语言 HQL SQL
    数据存储 HDFS Raw Device or Local FS
    执行 MapReduce Excutor
    执行延迟 高 低
    处理数据规模 大 小
    索引 位图索引/紧凑索引 复杂的索引
  6. 托管表与外部表：托管表是将数据移入hive仓库中，删除表时数据会彻底消失。而外部表则不会移动数据，删除表时仅仅是删除hive中的表元数据。 通常如果系统中所有的数据处理都由hive完成，则使用托管表。如果由hive和其他工具共同处理数据集，则采用外部表。普遍是将存放在hdfs中的初始数据作为外部表使用，然后用hive变换功能移到托管的表中。
  7. 分区:通过为需要频繁搜索的列建立分区，使得在查找分区列的数据时不需要扫描全表，从而提高查找效率（相当于起到了索引的作用）。分区采用的存储方式是在表目录下嵌套子目录，其目录结构可能如下所示： |-dt=2001-01-01/ | |-country=GB/ | | |-file1 | | |-file2 | |-country=US/ | | |-file3 |-dt=2001-01-02 |-country=GB/ | |-file4 |-country=US/ |-file5 |-file6 分区列也是表中正式的列，但是数据文件中并不包含这些列的值，读取时是直接从目录名读取的。
  8. 桶：表或分区可以组织成桶，桶是按行分开组织的。hive中采取对分桶所采用的(列）值进行hash，并用hash结果对桶的个数取余来分桶。这样保证每个桶中有数据，但数据条数不一定相同。分桶可以提高查询效率（甚至比分区高），同时也方便对数据做采样处理。
  9. 连接：用于将两个表中在共同数据项上相互匹配的行合并搜索。分为内连接（两边都有）/左向外连接（左表包含全部）/右向外连接/全外连接/半连接（用于替代sql中的in操作，只能出现在on子句）
  10. 视图：可以为需要频繁查找的部分数据建立视图，从而减少子句嵌套。视图实际上是逻辑表，并非真实存在的物理表。
  11. 面向行与面向列的存储：面向行的存储是先将一行数据的所有列都存储完，再存储下一行的数据;面向列的存储是先将多行数据总同一列的数据都存储完，再存储下一列。面向行的存储适合用来同时处理一行中好几列的情况，面向列的存储适合用来访问小部分行的查询。
  12. HIVE不支持在导入时以文字给出一组记录的形式，只支持从文件或其他表中导入。其中最常用的为CTAS语句（create table … as select …）。它可以将已有表中的部分数据（即select子句所检索出的列）存放到一个新表中。而且CTAS操作是原子的，只要select查询出现失败，新表就不会被创建。
  13. 如果只是删除表的全部数据，但是保留表的定义，只需删除表目录下的数据文件即可。

HBASE

  1. HBASE是面向列的分布式非关系型数据库。它依赖于zookeeper。由一个master和多个regionserver进行管理。
  2. 逻辑模型：HBase以表的形式存储数据，每个表由行和列组成，每个列属于一个特定的列族(Column Family)。由行和列确定的存储单元称为一个元素(Cell)，每个元素保存了同一份数据的多个版本，由时间戳来标识。数据版本可以是存储指定个数的最新版本，也可以是存储最近一段时间内的版本。元素由行键、列（<列簇>:<限定符>）和时间戳唯一确定，元素中的数据以字节码形式存储，没有类型之分。
  3. 物理模型：HBase是按照列存储的系数行/列矩阵，即将一个行进行分割，并按照列族存储。其中空值不会被存储（访问时返回null）。如果查询时不指明时间戳，则返回指定列所存储的最新数据值。在表格中，最新的数据是最先被找到的。
  4. 无论对行的访问事务牵涉到多少列，对行的更新都是原子的。
  5. Region（区域）：HBASE在行的方向上把表划分成Region（区域），当Region超出设定的阈值大小后，会自动重新分割。通常一个表格会有多个Region，存储在不同的Region服务器上，但一个Region内的数据只会存储在一个服务器上。
  6. HRegionServer（Region服务器程序）：通常一个计算机只运行一个HRegionServer，每个HRegionServer管理多个HRegion（Region的实例）和一个HLog。HLog只有一个，采用预写式日志（WAL, Write-Ahead-Log）。因此来自不同表的日志是混合在一起的。当Region服务器下线，为了恢复其上的Region，就需要对日志进行拆分，然后分发到其他的Region上。
  7. Store：每个Region由多个Store组成，每个Store保存一个列族的数据。每个Store又由一个memStore和多个StoreFile组成。客户端进行更新操作时，提交的数据会先写入HLog和memStore中，当memStore中的数据累计到某个阈值时，就会生成一个StoreFile文件保存到HDFS上。随着StoreFile的增多，HBase会对StoreFiles进行合并和版本删除，直至单个StoreFile超过一定阈值后，将当前的Region分割成两个。
  8. HMaster：HBASE每个时刻只有一个HMaster在运行，它负责分配和协调管理Region服务器，但并不直接负责读写请求和操作（由Regions负责）。HMaster只负责维护表和Region元数据，因此失效后仅会导致元数据无法更新，并不影响表的数据读写。 HBASE内部保留名为-ROOT-和.META.的特殊目录表。其中.META.表的数据会随着增大而分裂为多个Regions，而-ROOT-永远只有一个Region。-ROOT-包含了.META.的所有Region列表，.META.则保存所有Region所在的存储位置。客户端先从-ROOT-获取请求行所在的区域，再访问.META.获取该区域所在的节点位置。然后与管理该区域的regionserver进行交互。
  9. HBASE的特性：
    • 没有真正的索引。
    • 自动分区
    • 普通商用硬件支持
    • 容错
    • 批处理
  10. 当mapreduce的HBASE表使用TableInputFormat作为数据源格式时，它的splitter会给这个table的每个region分配一个map，而不管需要scan多少个列族。
FEATURED TAGS
博客 linux hadoop相关 安装笔记 数据挖掘 算法竞赛 挖掘笔记