html企业网站怎么做,今天重大新闻头条,产品开发是做什么的,最新热搜榜1、数据存储格式#xff1a; ①TEXTFILE HIVE 中默认的存储格式#xff1b; 一般使用在数据贴源层(ODS 或 STG) #xff0c;针对需要使用脚本 LOAD 加载数据到 HIVE 数仓表中的情况#xff1b;需要把表里数据导出或直接可以查看等场景#xff0c;作为BI供数 易读性…1、数据存储格式 ①TEXTFILE HIVE 中默认的存储格式 一般使用在数据贴源层(ODS 或 STG) 针对需要使用脚本 LOAD 加载数据到 HIVE 数仓表中的情况需要把表里数据导出或直接可以查看等场景作为BI供数 易读性要比 ORC 高很多 数据存储时不压缩因此磁盘的开销和数据解析开销比较大 TEXTFILE 可以结合 Gzip、Bzip2 等压缩算法使用(系统自动检查执行查询时自动解压)但使用这种方式HIVE 不会对数据进行切分从而无法对数据进行并行操作 在反序列化过程中必须逐个字符判断是不是分隔符和行结束符因此反序列化开销会比 SequenceFile 高几十倍 可以直接通过 LOAD 的方式从文件中加载数据到 HIVE 表中
当用户的数据文件格式不能被当前 HIVE 所识别的时候可以自定义文件格式 通过实现 inputformat 和 outputformat 来自定义输入输出格式 ②SEQUENCE FILE HADOOP API 提供的一种二进制文件以 key-value 的形式序列化到文件中 支持切片 数据加载导入方式可以通过INSERT方式加载数据 ③PARQUET 面向列的二进制文件格式所以是不可以直接读取的 文件中包括该文件的数据和元数据因此 Parquet 格式文件是自解析的 使用场景在 Impala 和 Hive 共享数据和元数据的场景 ④ORCFILE 运用 ORC 可以提高 HIVE 的读、写、计算的性能主要使用在 DWD、DWB、DWS 层 数据按行分块每块按照列存储 压缩快、快速列存取 效率比 rcfile 高是 rcfile 的改良版本 不考虑 ORC 的场景需要通过 LOAD 方式加载数据到表里需要把表里数据导出或直接可以查看等场景这两种场景更适合使用 TEXTFILE 易读性要比 ORC 高很多 ORC 文件格式可以使用 HIVE 自带的命令 concatenate 快速合并小文件 在 Hive 中使用 ORC 文件格式时是自动实现文件的分割splitting。这是因为 ORC 文件格式是为优化大规模数据处理而设计的其中包括了有效的数据分割机制以支持并行处理。以下是一些关于 ORC 文件分割的关键点
1. 块与条带Stripes
ORC 文件将数据分成多个条带Stripes每个条带都是自包含的数据集合包括其自己的索引、数据和行索引。这些条带是分割数据的物理单位可以独立于其他条带处理支持并行读取和查询。
2. 文件的索引
每个 ORC 文件包含一个轻量级的文件尾部索引其中包含有关文件中数据的统计信息和条带位置的详细信息。这使得查询引擎能够有效地确定哪些条带需要读取以满足特定的查询条件从而实现快速的数据访问。
3. 分割与并行处理
当 Hive 执行查询时它会根据数据的存储位置和条带信息自动对 ORC 文件进行分割。每个数据分割可以分配给不同的处理节点进行并行处理。这种分割机制允许 Hive 在多个处理节点上有效地分配工作从而优化查询性能和减少数据处理时间。
4. 设置条带大小和行索引间隔
虽然分割机制自动运作但你可以通过设置条带大小和行索引间隔来优化性能。例如可以在创建表时通过以下方式设置条带大小和行索引间隔
CREATE TABLE my_table (column1 INT,column2 STRING
)
STORED AS ORC
TBLPROPERTIES (orc.stripe.size67108864, -- 设置条带大小为64MBorc.row.index.stride10000, -- 设置行索引间隔orc.compressSNAPPY -- 设置压缩算法为SNAPPY
); HIVE 中常用的存储格式对比 存储格式是否默认存储方式支持压缩算法TextFile是行式存储Gzip、Bzip2SequenceFile否行式存储NONE、RECORD、BLOCKParquet否列式存储Uncompress(默认)、Snappy、Gzip、LzoRCFile否数据按行分块每块按列存储-(RCFile的优化)ORCFile否数据按行分块每块按列存储NONE、ZLIB(默认)、SNAPPY 2、压缩算法
文件存储格式不同对应不同的压缩算法从而带来不同的性能我们根据实际使用考虑压缩算法的性能 主要通过以下 3 个指标
① 压缩比 压缩比越高压缩后文件越小所以压缩比越高越好 压缩比越高存储磁盘空间占用越小可以降低单节点的磁盘IO同时可以减少占用的带宽
② 压缩时间 越快越好加快数据在Hadoop集群流动的速度和磁盘 IO 的速度
③ 压缩后的文件是否可以再分割 可以分割的格式允许单一文件由多个Mapper程序处理可以更好的 并行化
压缩算法对比 压缩方式压缩比压缩速度解压缩速度是否可分割gzip13.4%21 MB/s118 MB/s否无法并行处理bzip213.2%2.4MB/s9.5MB/s是并行处理LZO20.5%135 MB/s410 MB/s是并行处理snappy22.2%172 MB/s409 MB/s否无法并行处理
3、使用场景
ODS 贴源层 TextFile Gzip DWD ORC SNAPPY DWS ORC SNAPPY
① 数据量较大 如果单个文件比较大可以使用 Parquet 存储LZO压缩可以避免由于读取不可分割大文件引发的数据倾斜。 Parquet 的特性
更高效的压缩和编码策略Parquet 对于数据的编码和压缩有着高度优化特别是对于重复数据的处理。 它使用多种压缩技术和编码策略如字典编码、RLERun-Length Encoding和Delta 编码这些都有助于减少数据存储量并提升读取性能。 这种优化使得即使是大文件数据的物理存储尺寸也可能相对更小且读取效率更高。
更细粒度的索引Parquet 文件提供了详尽的元数据和索引例如 min/max 索引这可以极大地加速查询性能因为它允许在读取数据前快速跳过不符合查询条件的数据块。 这对于大文件尤为重要因为它减少了需要处理的数据量从而提高了处理速度。
更灵活的列裁剪和数据访问由于 Parquet 是列式存储它允许只加载查询所需的列这称为列裁剪。 这种能力在处理含有大量列的大文件时非常有用因为它可以显著减少I/O负载和提升查询响应时间。
更好的集成和优化支持Parquet 在现代数据处理框架中如 Apache Spark 和 Databricks 等获得了广泛的支持和优化。 这些框架针对 Parquet 进行了大量优化使其在这些环境中处理大型数据文件时表现更佳。
效率与性能的平衡虽然 Parquet 的写操作可能比 ORC 慢它在读取操作上通常更高效特别是在需要高度优化查询的分析型工作负载中。 这种读取性能上的优势在处理大数据文件时尤为重要因为它可以显著减少查询时间和计算资源的消耗。
因此尽管 ORC 和 Parquet 都有各自的优势和使用场景但在处理单个大文件方面Parquet 在很多情况下因其更精细的数据访问控制、更有效的数据压缩和编码以及更好的读取性能而更受青睐。这使得它在数据分析和大规模数据处理中尤其是在需要频繁读取的场景中成为更合适的选择。
② 计算逻辑比较少 使用 ORC 存储 ZLIB 压缩可以尽量减少占用存储空间
③ 计算逻辑比较多 使用 ORC 存储 SNAPPY 压缩可以提高读写速度从而提高整体计算性能
在 Hive 中对于计算逻辑比较多且要求计算速度达到最佳状态的场景选择 ORC 存储格式是明智的因为 ORC 格式具备高效的列存储和强大的压缩功能能够显著提高查询性能。 然而在压缩算法的选择上虽然 SNAPPY 和 LZO 各有优劣但选择的依据需要综合考虑多个因素。
3.1 ORC SNAPPY 的优势
快速压缩和解压缩 SNAPPY 以其快速的压缩和解压缩速度著称。对于频繁的读写操作快速的解压缩可以减少查询延迟从而提高整体计算性能。
低 CPU 开销 SNAPPY 的压缩和解压缩操作对 CPU 资源的消耗较低。对于计算密集型任务低 CPU 开销有助于将更多的 CPU 资源用于计算本身而不是浪费在压缩和解压缩过程中。
适合查询优化 ORC 文件格式支持谓词下推predicate pushdown、列裁剪column pruning和其他查询优化技术。SNAPPY 的低延迟特性使得这些优化技术能够更快地生效从而提高查询性能。 在 ORC 文件格式中使用 SNAPPY 压缩时压缩是在分割条带创建之后进行的。
下面是 ORC 文件结构处理数据的一般流程 数据组织与条带创建首先数据被组织成多个条带Stripes。每个条带包含一部分数据通常是几千到几万行具体取决于配置的条带大小和数据的实际特性。 列式存储在 ORC 文件中数据按列而非按行存储。这意味着每个条带中的数据会按列组织这有助于提高数据访问的效率并优化查询性能。 压缩数据在条带级别被组织好之后每个条带的数据会根据配置的压缩算法进行压缩。如果选择了 SNAPPY 压缩每个条带的数据会被 SNAPPY 压缩算法压缩。压缩是独立于每个条带进行的这允许在读取数据时可以并行解压缩不同的条带。 索引和元数据写入ORC 文件还会包含每个条带的索引信息和整个文件的元数据包括每个列的统计信息如最大值、最小值等。这些信息也存储在文件的尾部并可以用来优化读取操作因为它们可以帮助快速确定是否需要读取某个条带来满足查询条件。
因此SNAPPY 压缩在 ORC 文件的条带创建之后执行这样做的好处是可以保持压缩数据的独立性支持高效的并行处理。每个条带压缩后仍可独立解压这有利于分布式处理和快速数据访问。
3.2 ORC LZO 的情况
并行处理 LZO 支持并行处理和分片splitting这在写入大规模数据时是一个优势因为它能够充分利用多核 CPU 进行并行压缩缩短写入时间。
压缩率 LZO 的压缩率可能会比 SNAPPY 高一些这意味着在相同的数据量下LZO 压缩后的文件会更小可以节省存储空间和 I/O 开销。 综合考虑 尽管 LZO 支持并行处理和分片适合大规模数据的写入但在大多数计算密集型场景下查询性能的提升往往比写入性能更为重要。 SNAPPY 在读取时的快速解压缩和低 CPU 开销使得它在读取和计算过程中表现更优。这些优势在以下方面尤为明显
查询性能SNAPPY 的快速解压缩速度有助于加快数据加载和处理特别是对于复杂查询和计算逻辑多的场景。 CPU 利用率低 CPU 开销意味着更多的计算资源可以用于执行实际的查询和分析任务而不是消耗在解压缩过程中。 实际表现实际测试和基准测试往往显示对于计算密集型任务SNAPPY 的整体表现包括读取和计算阶段优于 LZO。 因此在大多数需要高计算性能的 Hive 使用场景中推荐使用 ORC SNAPPY 作为存储和压缩组合尽管 SNAPPY 不支持并行处理但当与 ORC 文件格式配合使用时实际情况可能有所不同。 有几个关键因素说明为什么在某些情况下使用 ORC 存储格式配合 SNAPPY 压缩依然能实现高效的计算速度
1. ORC 文件的结构特性 ORC 文件是一种高效的列式存储格式它自带索引和分区数据的功能。即使在使用 SNAPPY 压缩时ORC 文件格式还是可以支持有效的数据拆分split和并行处理。ORC 文件将数据存储在多个块中每个块可以独立压缩和解压缩。这意味着在处理时每个数据块可以被独立加载和解码允许并行处理。
2. SNAPPY 压缩的性能优势 SNAPPY 压缩提供了快速的压缩和解压速度这是其设计的主要目标。虽然它不支持压缩数据的拆分但其快速的解压速度对于计算密集型任务来说非常重要因为它可以快速地将数据送入处理流程。对于需要频繁读取的应用这种快速的解压速度可以显著提高数据处理的效率。
3. 计算和 I/O 开销的平衡 在使用 ORC 和 SNAPPY 的组合时可以实现对计算资源和 I/O 开销的良好平衡。由于 SNAPPY 提供了快速的解压缩它可以减少从磁盘读取数据所需的时间从而允许更多的资源被用于执行计算逻辑。这种快速的数据流转对于计算密集型任务尤其重要。
4. 总体系统性能 在选择压缩算法时还需要考虑到整个数据平台的架构和性能。虽然 LZO 提供了并行压缩的能力但其解压速度通常不如 SNAPPY 快。此外如果大部分时间都在进行数据读取和计算而不是写入那么解压缩性能将更为关键。
结论 因此尽管 SNAPPY 不支持拆分压缩数据但由于 ORC 的结构使得数据可以在块级别进行并行处理再加上 SNAPPY 的高解压速度使得这种组合在很多场景下仍然可以实现非常高效的查询和计算性能。当然这种选择也应基于具体的使用场景和性能测试来确定以确保满足特定的性能和成本效益需求。
