《Hadoop应用架构》是Orilley旗下精品系列的图书
Hadoop序列化
-
Thrift 不支持内部压缩 不能分片 缺少MapReduce的原生支持
-
Protocol Buffers
-
Avro 与语言无关 将模式存储在每个文件的头部 提供原生支持 可压缩可分片 支持模式演进（读取文件的模式不需要与写入文件的模式严格匹配） 通常以JSON格式定义（可以用Avro IDL定义） 文件头部还要同步标志 （用于隔开文件的数据块，从而使Avro文件支持分片）
列式存储的优势
-
对于查询内容之外的列，不必执行I/O和解压操作（减少查找）
-
适合小部分列的查询
-
相较于多行构成的数据块，列内的信息熵更低，所以压缩高效
-
适合对大数据集对某些指定的列的聚合操作
列式存储格式
-
RCFile 一般作为Hive存储格式 - 快速加载和查询数据 - 高效存储 - 按行分片； 分片按列存储 // 缺点：阻碍优化查询时间和压缩空间 -> ORC和Parquet
-
ORC
-
轻量级在线压缩 支持多种优秀压缩算法
-
仅返回查询所需要的数据
-
支持Hive类型的模型
-
支持分片
-
-
Parquet
-
返回仅查询的字段，减少磁盘IO
-
高效压缩（可以在每一列上指定压缩算法）
-
支持复杂的嵌套数据结构
-
文件尾部有完整的元数据信息存储（所以Parquet文件是字描述的）
-
支持通过Avro和Thrift API写入和读取
-
可扩展的编码模式（按位封装、游程编码）
-
-
压缩
-
多大多数情况下，I/O的节省大于增加的CPU负载
-
Hadoop的压缩算法
-
Snappy 平衡压缩速度和大小 不可分片（需要与容器格式联合使用SeqenceFile和Avro）
-
LZO 可分片 要求建立索引 不允许分发 需要独立安装
-
Gzip 不可分片 压缩性能最好 写入速度较慢
-
bzip2 可分片 不是理想的编解码格式
-
-
压缩算法推荐
-
一般来说，与容器文件格式（Avro、SequenceFile）一起使用时，任何压缩格式都是可以分片的
-
Hadoop中进行压缩的一些建议
-
开启MR中间数据的输出压缩 减少读取和写入磁盘的中间数据进而提高性能
-
注意数据的排序方式 通过把相似的数据放在一起（压缩效率高） Hadoop文件格式中的数据以块为单位压缩（块的熵决定最后的压缩）
-
考虑使用可分片压缩算法的紧凑文件格式
-
-
-
HDFS模式设计
-
创建数据库时的几点建议
-
标准化的目录结构让团队更加轻松地使用同一个数据集共享数据
-
支持实施访问控制和配额控制，可以防止意外删除或损坏
-
在所有数据都准备好之前，使用者常会将数据放在一个独立的区域，存放数据的约定有助于确保部分加载数据不会被当作加载完成的数据，从而被意外处理
-
对数据进行标准化的组织，使得某些数据处理代码可以复用
-
-
设计模式时的几点建议
-
要创建实践标准并遵守标准，特别是当多个小组共同使用数据时
-
确保你的设计能与计划使用的工具配合使用
-
设计模式时要记住使用模式，不同的数据处理与查询模式要配合不同的模式设计。
-
-
文件在HDFS中的位置
-
推荐的HDFS目录结构
-
/user/<username>
只属于特定用户的数据、JAR包和配置文件。
-
/etl
ETL工作流正在处理的、处于不同阶段的数据 /etl/<group>/<application>/<process>/{input/processing/output/bad}
-
/tmp
工具生成或者用户共享的临时数据。该目录通常通过程序自动删除，不会存储生命周期长的数据。通常每个人都能读取或者写入该目录
-
/data
经过处理并且在整个组织内共享的数据集。这些通常是待分析数据的重要来源，通常，用户只能读取数据，数据由自动化的 ETL 过程写入，而且要受到审计。
-
/app
几乎囊括 Hadoop 应用运行所需要的一切，但不包括数据。
-
/metadata
存储元数据
-
-
-
高级HDFS模式设计
-
分区
-
减少处理数据的I/O HDFS不会将索引存储到数据中（全表扫描）
-
分区目录格式样例：medication_orders/date_20191104/{order1.csv,order2.csv}
-
-
-
Hadoop常用数据来源
-
传统数据管理系统（关系型数据库与主机）
-
日志、及其生成的数据，以及其他类型的事件数据
-
从现有的企业数据存储系统中输入的文件
-
-
时间戳
-
时间戳决定了在put请求修改记录时哪些记录更新
-
时间戳决定了一条记录的多个版本在返回时的排序
-
时间戳还用于大合并(Major Compaction)过程，决定是否移除与时间戳相比已超过存活时间的的过期记录
-
-
分桶
-
与哈希分区类似
-
分区可能带来“小文件”问题 （会导致NameNode的过度使用）（处理的任务越多 -> 数据处理的压力变大）
-
反向序列化
-
用磁盘空间换取查询性能
-
在关系型数据库中，数据通常以第三范式存储。
-
-
该模式将数据分片成更小的表，每个表都含有一个特定的实体，从而将冗余减到最小并且提供数据完整性
-
关联通常是最慢的操作，且消耗的集群资源最多
-
-
HDFS模式设计总结
-
通过有选择地读写特定分区的数据，使用分区技术减少数据数据的I/O
-
反向序列化在加快Hadoop任务处理速度方面有重要作用
-
-
在Hadoop中存储大量小文件会导致NameNode内存的过量使
-
对于经常进行关联操作的大表，最好对数据进行排序和分桶，而且按照关联字段分桶
-
使用磁盘空间换取查询性能的两种方式
-
关联
-
数据集反向规范化（削减关联数据集的需求）
-
-
-
HBase模式设计
-
HBase是非关系型数据库
-
把HBase当成一个巨大的哈希表，与哈希表相同之处：HBase允许用户将指定的键和特定值进行关联（这样带来的好处是基于给定的键就能快速查找到相应的值）
-
-
HBase行键
-
行键是在HBase中检索记所使用的键
-
记录含有的列在数量上没有限制，但只能有一个行键
-
HBase中所有的行键都进行了排序，经过排序的行键按照范围存储在不同的Region中。每个Region都固定在一个Region服务器(集群中的一个节点)上。
-
行键的著名反模式设计 —> 时间戳的使用
-
选择合适的行键能够使相关的记录落于同一个Region
-
-
行键的大小决定工作负载的性能，通常来说，行键越短越好(降低存储消耗，提高读写性能)。在行键较长的时候，get和scan的性能更好。因此，在选择时，需要权衡行键的长短。
-
元数据
元数据的分类：
-
与逻辑数据集有关的元数据
-
数据集的位置(比如 HDFS 中的目录或者 HBase 中表的名称)、与数据集有关的模式 、数据集的分区与排序特性(如果有的话)，以及适用的数据集格式(比如 CSV、TSV、SequenceFile等等)。此类元数据通常存储于独立的元数据仓库中
-
-
与HDFS文件有关的元数据
-
该类文件的权限与属主，以及数据节点上不同数据块的位置。此类信息 通常通过 Hadoop NameNode 进行存储和管理
-
-
与HBase表相关的元数据
-
表的名称、相关名称空间、相关属性(如 MAX_FILESIZE、READONLY，等 等)，以及列簇的名称。此类信息由 HBase 存储和管理
-
-
与数据输入和转化有关的元数据
-
创建指定数据集的特定用户、数据集的来源、创建数据集花费的时间， 以及存在多少条记录，或者加载的数据大小是多少
-
-
与数据集统计相关的元数据
-
数据集中行的数量、每列中特定值的数量、数据分布的直方图以及最大 值和最小值。此类元数据用于不同的工具，这些工具能够利用元数据优化执行计划。它
-
-
说明：Hadoop为Schema-On-Read。引入该模式不代表失去该特性，只是表明这是对数据集中数据的一种解析方式，同一份数据可以拥有多份模式
-
2019-07-12
There's no losing only learning
There's no falture only opportunities
There's no problem only solutions
