简单了解 Hadoop、HDFS、Kudu、Parquet
前言
提示:最近简单了解了一些大数据的常用组件,记录一下自己的理解。
一、Hadoop
Hadoop 是由 java 语言编写的,在分布式服务器集群上存储海量数据并运行分布式分析应用的开源框架,其核心部件是 HDFS 与 MapReduce。
HDFS 为海量的数据提供了存储,而 MapReduce 为海量的数据提供了计算:
可以把 HDFS 理解为一个分布式的,有冗余备份的,可以动态扩展的用来存储大规模数据的大硬盘;
把 MapReduce 理解成为一个计算引擎,按照 MapReduce 的规则编写 Map 计算 Reduce 计算的程序,可以完成计算任务。
二、HDFS
HDFS 是 Hadoop 项目的一个子项目,是 Hadoop 应用下的分布式文件系统,引入存放文件元数据信息的服务器 Namenode 和实际存放数据的服务器 Datanode,对数据进行分布式储存和读取。
提示:分布式文件系统(Distributed File System,DFS)是指文件系统管理的物理存储资源不一定直接连接在本地节点上,而是通过计算机网络与节点(可简单的理解为一台计算机)相连;或是若干不同的逻辑磁盘分区或卷标组合在一起而形成的完整的有层次的文件系统。
它提供了文件系统实现的各类接口,使文件系统易于操作。是基于流式的数据访问模式和处理超大文件的需求而开发的,可以运行在廉价的机器上。主要特点如下:
优点:
- 处理超大文件:通常是 GB 级甚至是 TB 级文件,目前以及可以用来管理 TB 级的数据。
- 流式地访问数据:HDFS 设计理念 “一次写入、多次读取”,即当一个数据集生成之后,就会被切分成小文件块,并复制多份分发到不同的存储节点中,然后响应各种数据分析任务请求。
- 能运行在低廉的机器集群上:Hadoop 对机器的硬件要求不高,但廉价的机器通常节点故障的发生概率非常高,所以 Hadoop 在设计时需要充分考虑数据的可靠性和安全性。
缺点:
- 高延迟的数据访问:HDFS 是为高吞吐量而设计的,因此会有较高的延迟。
- 无法高效处理小文件:在 Hadoop 中,需要用到 NodeName来 管理文件系统的元数据(描述数据的数据),以响应客户端的请求并返回文件位置,因此文件数量的多少,决定着 NameNode 存储多少。所以有许多小文件存储时,NameNode 的工作压力会很大,检索元数据的处理时长会极其耗时。
- 文件的元数据(如目录结构,文件 block 的节点列表,block-node mapping)都保存在 NameNode 的内存中, 整个文件系统的文件数量会受限于 NameNode 的内存大小。
- 提示:经验而言,一个文件/目录/文件块一般占有150字节的元数据内存空间。如果有100万个文件,每个文件占用1个文件块,则需要大约300M的内存。因此十亿级别的文件数量在现有商用机器上难以支持。
- HDFS采用追加(append-only)的方式写入数据。不支持文件任意offset的修改。不支持多个写入器(writer)
三、Parquet
Apache Parquet 是 Hadoop 生态圈中一种新型列式存储格式,它可以兼容 Hadoop生态圈中大多数计算框架,被多种查询引擎支持,并且它是语言和平台无关的。
优点:
- 查询的时候不需要扫描全部的数据,而只需要读取每次查询涉及的列,这样可以将 I/O消 耗降低 N 倍,另外可以保存每一列的统计信息 (min、max、sum 等),实现部分的谓词下推。
- 由于每一列的成员都是同构的,可以针对不同的数据类型使用更高效的数据压缩算法,进一步减小 I/O。
- 由于每一列的成员的同构性,可以使用更加适合 CPU pipeline 的编码方式,减小 CPU 的缓存失效。
四、Kudu
对于会被用来进行分析的静态数据集来说,使用 Parquet 或者 ORC 存储是一种明智的选择。但是目前的列式存储技术都不能更新数据,而且随机读写性能感人。而可以进行高效随机读写的 HBase、Cassandra 等数据库,却并不适用于基于 SQL 的数据分析方向。
基于 HDFS 的存储技术,比如 Parquet,具有高吞吐量连续读取数据的能力;而 HBase 和 Cassandra等 技术适用于低延迟的随机读写场景
Kudu 不但提供了行级的插入、更新、删除 API,同时也提供了接近 Parquet 性能的批量扫描操作。使用同一份存储,既可以进行随机读写,也可以满足数据分析的要求。
从用户角度来看,Kudu 是一种存储结构化数据表的存储系统。
由于 Kudu 在硬盘中的数据采用列式存储,所以只扫描需要的列将极大地提高读取性能。
Kudu 的应用场景很广泛,比如可以进行实时的数据分析,用于数据可能会存在变化的时序数据应用等。