天天看點
傳回

Impala 表使用 Parquet 檔案格式Impala 表使用 Parquet 檔案格式

目錄[-]

  • Impala 表使用 Parquet 檔案格式
  • 在 Impala 中建立 Parquet 表
  • 加載資料到 Parquet 表
  • Impala Parquet 表的查詢性能
  • Parquet 表的分區
  • Parquet 資料檔案的 Snappy 和 GZip 壓縮
  • 使用 Snappy 壓縮的 Parquet 表
  • 使用 GZip 壓縮的 Parquet 表
  • 未壓縮的 Parquet 表
  • 壓縮 Parquet 表的大小和速度
  • 複制 Parquet 資料檔案
  • 與其他 Hadoop 元件交流 Parquet 資料檔案
  • Parquet 資料檔案如何組織
  • Parquet 資料檔案的行程編碼(RLE)和字典編碼

Impala 表使用 Parquet 檔案格式

Impala 幫助你建立、管理、和查詢 Parquet 表。Parquet 是一種面向列的二進制檔案格式，設計目标是為 Impala 最擅長的大規模查詢類型提供支援(Parquet is a column-oriented binary file format intended to be highly efficient for the types of large-scale queries that Impala is best at)。Parquet 對于查詢掃描表中特定的列特别有效，例如查詢一個包含許多列的"寬"表，或執行需要處理列中絕大部分或全部的值的如 SUM(),AVG() 等聚合操作(Parquet is especially good for queries scanning particular columns within a table, for example to query "wide" tables with many columns, or to perform aggregation operations such as SUM() and AVG()that need to process most or all of the values from a column)。每個資料檔案包含行集(行組)的值(Each data file contains the values for a set of rows (the "row group"))。在資料檔案裡，每一列的值都被重組，以便他們相鄰，進而對這些列的值進行良好的壓縮(the values from each column are organized so that they are all adjacent, enabling good compression for the values from that column)。針對 Parquet 表的查詢可以快速并最小 I/O 的從任意列擷取并分析這些資料(table can retrieve and analyze these values from any column quickly and with minimal I/O)。

參考以下章節，以了解關于 Impala 表如何使用 Parquet 資料檔案的詳細資訊：

  • Creating Parquet Tables in Impala
  • Loading Data into Parquet Tables
  • Query Performance for Impala Parquet Tables
  • Snappy and GZip Compression for Parquet Data Files
  • Exchanging Parquet Data Files with Other Hadoop Components
  • How Parquet Data Files Are Organized

在 Impala 中建立 Parquet 表

請使用類似下面的指令，建立名為 PARQUET_TABLE_NAME 并使用 Parquet 格式的表，請替換為你自己的表名、列名和資料類型：

[impala-host:21000] > create table parquet_table_name(x INT, y STRING) STORED AS PARQUET;
Impala 表使用 Parquet 檔案格式Impala 表使用 Parquet 檔案格式

  Note: 之前，STORED AS 子句需要使用 PARQUETFILE 關鍵字。在 Impala 1.2.2 及以上版本，可以使用 STORED AS PARQUET。建議新的代碼使用 PARQUET 關鍵字。

或者，克隆現有表的列名和資料類型：

[impala-host:21000] > create table parquet_table_name LIKE other_table_name STORED AS PARQUET;

當建立了表之後，請使用類似下面的指令插入資料到表中，請再次使用你自己的表名：

[impala-host:21000] > insert overwrite table parquet_table_name select * from other_table_name;

假如 Parquet 表具有與其他表不同數量的列或不同的列名，請在對其他表的 SELECT 語句中指定列名而不是使用 * 來代替。

加載資料到 Parquet 表

根據原始資料是否已經在 Impala 表中，或者在 Impala 之外存在原始資料檔案，來選擇下面的技術加載資料到 Parquet 表裡。

假如你的資料已經在 Impala 或 Hive 表裡，可能是在不同的檔案格式或分區模式下，你可以直接使用 Impala INSERT...SELECT 文法傳輸這些資料到 Parquet 表。你可以在同一個 INSERT 語句中，對資料執行轉換、過濾、重新分區，以及其他類似操作。參見 Snappy and GZip Compression for Parquet Data Files 了解一些示範如何插入資料到 Parquet 的例子。

當插入到分區表中，特别是使用 Parquet 檔案格式的，你可以在 INSERT 語句中包含一個提示(hint)以減少同時寫入 HDFS 檔案的數量，以及為不同的分區儲存資料提供的 1GB 記憶體緩存的個數(and the number of 1GB memory buffers holding data for individual partitions)。請将 hint 關鍵字 [SHUFFLE]/[NOSHUFFLE] 放在緊跟表名之後。當 INSERT 語句運作失敗，或當所有節點上試圖構造所有分區的資料而導緻的低效時，使用 [SHUFFLE] 提示。這一提示僅在 Impala 1.2.2 及以上版本可用。

Parquet 表的任意 INSERT 語句需要 HDFS 檔案系統中有足夠寫入一塊的空間。因為 Parquet 資料檔案預設 1GB/塊， 假如你的 HDFS 所剩無幾，那麼 INSERT 可能失敗(即使非常少量的資料)。

避免對 Parquet 表使用 INSERT...VALUES 文法，因為 INSERT...VALUES 為每一個 INSERT...VALUES 語句産生一個包含少量資料的單獨的資料檔案，而 Parquet 的實力在于它以 1GB 塊的方式處理資料(壓縮、并行、等等操作)(and the strength of Parquet is in its handling of data (compressing, parallelizing, and so on) in 1GB chunks)。

假如你具有一個或多個 Impala 之外生成的 Parquet 資料檔案，使用以下某一個方法，你可以快速的使這些資料可以在 Impala 中查詢：

  • 使用 LOAD DATA 語句移動單個資料檔案或某個目錄下所有資料檔案到 Impala 表對應的資料目錄中。這不會驗證或轉換資料。原始的資料檔案必須在 HDFS 中，而不能是在本地檔案系統中。
  • 使用包含 LOCATION 子句的 CREATE TABLE 語句建立一個資料繼續存放在 Impala 資料目錄之外的表。原始的資料檔案必須在 HDFS 中，而不能是在本地檔案系統中。為了加強安全性，假如這些資料是長時間存在并被其他應用重用，你可以使用 CREATE EXTERNAL TABLE 文法，這樣 Impala DROP TABLE 語句不會删除這些資料檔案。
  • 假如 Parquet 表已經存在，你可以直接複制 Parquet 資料檔案到表的目錄中，然後使用 REFRESH 語句使得 Impala 識别到新添加的資料。請記住對 Parquet 資料檔案使用 hdfs distcp -pb 指令而不是 -put/-cp 操作，以保留Parquet 資料檔案的 1GB 塊大小。參見 Example of Copying Parquet Data Files 了解這種操作的例子。

假如資料在 Impala 之外，并且是其他格式，請結合使用之前提到的技術。首先，使用 LOAD DATA 或 CREATE EXTERNAL TABLE ... LOCATION 語句把資料存入使用對應檔案格式的 Impala 表中。然後，使用 INSERT...SELECT 語句複制資料到 Parquet 表中，作為這一處理過程的一部分轉換為 Parquet 格式。

加載資料到 Parquet 表是記憶體密集型操作，因為接受的資料會被緩存一直到達到 1GB 大小，然後這些塊的資料在寫出之前在記憶體中被組織和壓縮。當插入資料到分區 Parquet 表中時，記憶體消耗會更大，因為對每一種分區鍵值的組合都寫入一個單獨的資料檔案，同時可能有幾個 1GB 的塊在操作(potentially requiring several 1GB chunks to be manipulated in memory at once)。

當向分區 Parquet 表插入資料時，Impala 在節點之間重新分布資料以減少記憶體消耗。但當插入操作時，你可能仍然需要臨時增加 Impala 專用的記憶體量，或者把加載操作拆分到幾個 INSERT 語句中，或者兩種方式都采用(You might still need to temporarily increase the memory dedicated to Impala during the insert operation, or break up the load operation into several INSERT statements, or both)。

Impala 表使用 Parquet 檔案格式Impala 表使用 Parquet 檔案格式

  Note: 之前所有的技術都假定你所加載的資料與你的目标表的結構比對，包括列的順序，列的名稱，以及分區布局(layout)。為了轉換或重組資料，開始先加載資料到與底層資料比對的 Parquet 表中，然後使用如 CREATE TABLE AS SELECT 或 INSERT ... SELECT 之一的表複制技術來重新排序或重命名列，拆分資料到多個分區等等。例如加載單個包含所有資料的 Parquet 檔案到分區表中，你應當使用包含動态分區的 INSERT ... SELECT 語句來讓 Impala 以對應的分區值建立單獨的資料檔案；例子參見   INSERT Statement。

Impala Parquet 表的查詢性能

Parquet 表的資料是劃分成一個個的 1GB 的資料檔案的("行組(row groups)")，查詢時讀取以壓縮格式存儲的每一列的資料，并消耗 CPU 解壓資料。是以 Parquet 表的查詢性能依賴于查詢中 SELECT 清單和 WHERE 子句中需要處理的列的個數，以及是否可以跳過較多的資料檔案(分區表)，降低 I/O 并減少 CPU 負載(Query performance for Parquet tables depends on the number of columns needed to process the SELECT list and WHERE clauses of the query, the way data is divided into 1GB data files ("row groups"), the reduction in I/O by reading the data for each column in compressed format, which data files can be skipped (for partitioned tables), and the CPU overhead of decompressing the data for each column)。

例如，下面對 Parquet 表的查詢是高效的：

select avg(income) from census_data where state = 'CA';

這個查詢隻處理一大堆列中的兩個列。假如表是根據 STATE 分區的，它甚至更有效率，因為查詢僅僅需要對每個資料檔案讀取和解碼 1 列，并且它可以隻讀取 state 'CA' 分區目錄下的資料檔案，跳過其他 states 的、實體上的位于其他目錄的所有資料檔案。

以下查詢相當低效：

select * from census_data;

Impala 将不得不讀取每一個 1GB 資料檔案的整個内容，并解壓每一個行組中每一列的内容，浪費了面向列格式的 I/O 優化。對于 Parquet 表，這一查詢可能比其他格式的表更快，但是它沒有從 Parquet 資料檔案格式獨有的優勢中受益。

Parquet 表的分區

就如 Partitioning 中的描述一樣，對 Impala 來說，分區是一項重要而通用的性能技術。本章節介紹一些關于分區 Parquet 表的性能考慮。

Parquet 檔案格式非常适合包含許多列，并且絕大部分查詢隻設計表的少量清單。就如在 How Parquet Data Files Are Organized 中描述的那樣，Parquet 資料檔案的實體分布使得對于許多查詢 Impala 隻需要讀取資料的一小部分。當你結合使用 Parquet 表和分區時，這一性能受益會更加擴大。基于 WHERE 子句中引用的分區鍵的比較值，Impala 可以跳過特定分區實體的資料檔案。例如，分區表上的查詢通常基于年、月、日、或者地理位置的列進行時間段的分析(queries on partitioned tables often analyze data for time intervals based on columns such as YEAR, MONTH, and/or DAY, or for geographic regions)。請記住 Parquet 資料檔案使用 1GB 的塊大小，是以在确定如何精細的分區資料時，請嘗試找到一個粒度，每一個分區都有 1GB 或更多的資料，而不是建立大量屬于多個分區的的小檔案。

插入到分區 Parquet 表示一個資源密集型(resource-intensive)操作，因為每一個 Impala 節點對于每一個分區鍵的不同組合都可能潛在的寫一個單獨的資料檔案。大量的同時打開的檔案數可能會達到 HDFS "transceivers" 限制。考慮采用以下技術，避免達到這一限制：

  • 使用包含特定值的 PARTITION 子句的單獨的 INSERT 語句加載不同的資料子集，如 PARTITION (year=2010)
  • 增加 HDFS 的 "transceivers" 值，有時候寫作 "xcievers" (sic)。在配置檔案 hdfs-site.xml 中為 dfs.datanode.max.xcievers 屬性。例如，假如你加載 12 年的資料，而分區包含年、月、日，甚至這個值設定為 4096 也可能不夠。這一部落格使用 HBase 例子作為說明，探讨了設定增加或減少這一值大小時的考慮
  • 在資料被複制的源表上采集列統計資訊，這樣 Impala 查詢可以評估分區鍵列中不同值的個數進而分布工作負載

Parquet 資料檔案的 Snappy 和 GZip 壓縮

當 Impala 使用 INSERT 語句寫入 Parquet 資料檔案時，底層的壓縮受 PARQUET_COMPRESSION_CODEC 查詢選項控制。這一查詢選項允許的值包括 snappy (預設值), gzip, 和 none。選項值不區分大小寫。假如選項值設定為一個未确認的值，因為無效的選項值，所有查詢都将失敗，不僅僅是涉及到 Parquet 表的查詢。

使用 Snappy 壓縮的 Parquet 表

預設的，Parquet 表底層的資料檔案采用 Snappy 壓縮。快速壓縮和解壓的組合使得對于許多資料集來說這是一個好選擇。為了確定使用了 Snappy 壓縮，例如試驗了其他壓縮編解碼之後，請在插入資料之前設定 PARQUET_COMPRESSION_CODEC 查詢選項為 snappy：

[localhost:21000] > create database parquet_compression;
[localhost:21000] > use parquet_compression;
[localhost:21000] > create table parquet_snappy like raw_text_data;
[localhost:21000] > set PARQUET_COMPRESSION_CODEC=snappy;
[localhost:21000] > insert into parquet_snappy select * from raw_text_data;
Inserted 1000000000 rows in 181.98s

使用 GZip 壓縮的 Parquet 表

假如你需要更深入的(more intensive)壓縮(當查詢時需要更多的 CPU 周期以進行解壓)，請在插入資料之前設定 PARQUET_COMPRESSION_CODEC 查詢選項為 gzip ：

[localhost:21000] > create table parquet_gzip like raw_text_data;
[localhost:21000] > set PARQUET_COMPRESSION_CODEC=gzip;
[localhost:21000] > insert into parquet_gzip select * from raw_text_data;
Inserted 1000000000 rows in 1418.24s

未壓縮的 Parquet 表

假如你的資料壓縮作用非常有限，或者你想避免壓縮和解壓縮實體的 CPU 負載，請在插入資料前設定 PARQUET_COMPRESSION_CODEC 查詢選項為 none：

[localhost:21000] > create table parquet_none like raw_text_data;
[localhost:21000] > insert into parquet_none select * from raw_text_data;
Inserted 1000000000 rows in 146.90s

壓縮 Parquet 表的大小和速度

下面的例子示範了 10 億條複合資料在資料大小和查詢速度方面的差異，他們分别使用了不同的編解碼器進行壓縮(Here are some examples showing differences in data sizes and query speeds for 1 billion rows of synthetic data, compressed with each kind of codec)。與往常一樣，使用你自己真實的資料集進行類似的測試。實際的壓縮比、對應的插入和查詢速度，将取決于實際資料的特征而有所不同。

在例子中，壓縮方式從 Snappy 換到 GZip 能減少 40% 的大小，而從 Snappy 換到不壓縮将增加 40% 的大小(In this case, switching from Snappy to GZip compression shrinks the data by an additional 40% or so, while switching from Snappy compression to no compression expands the data also by about 40%)：

$ hdfs dfs -du -h /user/hive/warehouse/parquet_compression.db
23.1 G  /user/hive/warehouse/parquet_compression.db/parquet_snappy
13.5 G  /user/hive/warehouse/parquet_compression.db/parquet_gzip
32.8 G  /user/hive/warehouse/parquet_compression.db/parquet_none

因為 Parquet 資料檔案通常大小是 1GB 左右，每一個目錄都包含不同數量的資料檔案并安排不同的行組(each directory will have a different number of data files and the row groups will be arranged differently)。

同時，更小的壓縮比，那麼解壓速度就更快。在上面包含 10 億行記錄的表中，對于評估特定列所有值的查詢，不使用壓縮比使用 Snappy 壓縮的快，使用 Snappy 壓縮的比使用 Gzip 壓縮的快。查詢性能依賴于幾個不同的因素，是以請一如既往的使用你自己的資料進行自己的基準測試，以獲得資料大小、CPU 效率、以及插入和查詢操作的速度等方面理想的平衡。

[localhost:21000] > desc parquet_snappy;
Query finished, fetching results ...
+-----------+---------+---------+
| name      | type    | comment |
+-----------+---------+---------+
| id        | int     |         |
| val       | int     |         |
| zfill     | string  |         |
| name      | string  |         |
| assertion | boolean |         |
+-----------+---------+---------+
Returned 5 row(s) in 0.14s
[localhost:21000] > select avg(val) from parquet_snappy;
Query finished, fetching results ...
+-----------------+
| _c0             |
+-----------------+
| 250000.93577915 |
+-----------------+
Returned 1 row(s) in 4.29s
[localhost:21000] > select avg(val) from parquet_gzip;
Query finished, fetching results ...
+-----------------+
| _c0             |
+-----------------+
| 250000.93577915 |
+-----------------+
Returned 1 row(s) in 6.97s
[localhost:21000] > select avg(val) from parquet_none;
Query finished, fetching results ...
+-----------------+
| _c0             |
+-----------------+
| 250000.93577915 |
+-----------------+
Returned 1 row(s) in 3.67s

複制 Parquet 資料檔案

下面是最後一個例子，示範了使用不同壓縮編解碼器的資料檔案在讀操作上是如何互相相容的。關于壓縮格式的中繼資料會寫入到每個資料檔案中，并且在讀取時不管當時 PARQUET_COMPRESSION_CODEC 設定為什麼值，都可以正常解碼。在這個例子中，我們從之前例子中使用的 PARQUET_SNAPPY,PARQUET_GZIP, PARQUET_NONE 表中複制資料檔案，這幾個表中每一個表都包含 10 億行記錄， 全都複制到新表 PARQUET_EVERYTHING 的資料目錄中。一對簡單的查詢展示了新表現在包含了使用不同壓縮編解碼器的資料檔案的 30 億的記錄。

首先，我們在 Impala 中建立表以便在 HDFS 中有一個存放資料檔案的目标目錄：

[localhost:21000] > create table parquet_everything like parquet_snappy;
Query: create table parquet_everything like parquet_snappy

然後在 shell 中，我們複制對應的資料檔案到新表的資料目錄中。不采用 hdfs dfs -cp 這一通常複制檔案的方式，我們使用 hdfs distcp -pb 指令以確定 Parquet 資料檔案特有的 1GB 塊大小繼續保留。

$ hdfs distcp -pb /user/hive/warehouse/parquet_compression.db/parquet_snappy \
  /user/hive/warehouse/parquet_compression.db/parquet_everything
...MapReduce output...
$ hdfs distcp -pb /user/hive/warehouse/parquet_compression.db/parquet_gzip  \
  /user/hive/warehouse/parquet_compression.db/parquet_everything
...MapReduce output...
$ hdfs distcp -pb /user/hive/warehouse/parquet_compression.db/parquet_none  \
  /user/hive/warehouse/parquet_compression.db/parquet_everything
...MapReduce output...

回到 impala-shell，我們使用 REFRESH 語句讓 Impala 伺服器識别到表中新的資料檔案，然後我們可以運作查詢展示資料檔案包含 30 億條記錄，并且其中一個數值列的值與原來小表的比對：

[localhost:21000] > refresh parquet_everything;
Query finished, fetching results ...

Returned 0 row(s) in 0.32s
[localhost:21000] > select count(*) from parquet_everything;
Query finished, fetching results ...
+------------+
| _c0        |
+------------+
| 3000000000 |
+------------+
Returned 1 row(s) in 8.18s
[localhost:21000] > select avg(val) from parquet_everything;
Query finished, fetching results ...
+-----------------+
| _c0             |
+-----------------+
| 250000.93577915 |
+-----------------+
Returned 1 row(s) in 13.35s

與其他 Hadoop 元件交流 Parquet 資料檔案

自 CDH 4.5 開始，你可以在 Hive、Pig、MapReduce 中讀取和寫入 Parquet 資料檔案。參考 CDH 4 Installation Guide 了解詳細資訊。

之前，不支援在 Impala 中建立 Parquet 資料然後在 Hive 中重用這個表。現在從 CDH 4.5 中的 Hive 開始支援 Parquet，在 Hive 中重用已有的 Impala Parquet 資料檔案需要更新表的中繼資料。假如你已經使用 Impala 1.1.1 或更高版本，請使用下面的指令：

ALTER TABLE table_name SET FILEFORMAT PARQUET;

假如你使用比 Impala 1.1.1 更老的版本，通過 Hive 執行中繼資料的更新：

ALTER TABLE table_name SET SERDE 'parquet.hive.serde.ParquetHiveSerDe';
ALTER TABLE table_name SET FILEFORMAT
  INPUTFORMAT "parquet.hive.DeprecatedParquetInputFormat"
  OUTPUTFORMAT "parquet.hive.DeprecatedParquetOutputFormat";

Impala 1.1.1 及以上版本可以重用 Hive 中建立的 Parquet 資料檔案，不需要執行任何操作。

Impala 支援你可以編碼成 Parquet 資料檔案的标量資料類型，但不支援複合(composite)或嵌套(nested)類型如 maps/arrays。假如表中使用了任意不支援的類型，Impala 将無法通路這個表。

假如你在不同節點、乃至在相同節點的不同目錄複制 Parquet 資料檔案，請使用 hadoop distcp -pb 指令以確定保留原有的塊大小。請執行 hdfs fsck -blocks HDFS_path_of_impala_table_dir 并檢查平均塊大小是否接近 1GB，以驗證是否保留了塊大小(Hadoop distcp 操作通常會生出一些子目錄，名稱為 _distcp_logs_*，你可以從目标目錄中删除這些目錄)。參見 Hadoop DistCP Guide 了解詳細資訊。

Parquet 資料檔案如何組織

盡管 Parquet 是一個面向列的檔案格式，不要期望每列一個資料檔案。Parquet 在同一個資料檔案中儲存一行中的所有資料，以確定在同一個節點上處理時一行的所有列都可用。Parquet 所做的是設定 HDFS 塊大小和最大資料檔案大小為 1GB，以確定 I/O 和網絡傳輸請求适用于大批量資料(What Parquet does is to set an HDFS block size and a maximum data file size of 1GB, to ensure that I/O and network transfer requests apply to large batches of data)。

在成G的空間内，一組行的資料會重新排列，以便第一行所有的值被重組為一個連續的塊，然後是第二行的所有值，依此類推。相同列的值彼此相鄰，進而 Impala 可以對這些列的值使用高效的壓縮技術(Within that gigabyte of space, the data for a set of rows is rearranged so that all the values from the first column are organized in one contiguous block, then all the values from the second column, and so on. Putting the values from the same column next to each other lets Impala use effective compression techniques on the values in that column)。

Impala 表使用 Parquet 檔案格式Impala 表使用 Parquet 檔案格式

  Note:

Parquet 資料檔案的 HDFS 塊大小是 1GB，與 Parquet 資料檔案的最大大小相同，一邊每一個資料檔案對應一個 HDFS 塊，并且整個檔案可以在單個節點上處理，不需要任何遠端讀取。假如在檔案複制時塊大小重設為較低的值，你将發現涉及到這些檔案的查詢性能更低，并且 PROFILE 語句将會揭示一些 I/O 是次優的，會通過遠端讀取。參見 Example of Copying Parquet Data Files 了解當複制 Parquet 資料檔案時如何保留塊大小的例子。

當 Impala 檢索或測試特定列的資料時，它将打開所有的資料檔案，但隻會讀取每一個檔案中這些列的值連續存放的位置(but only reads the portion of each file where the values for that column are stored consecutively)。假如其他的列在 SELECT 清單或 WHERE 子句中列出，在同一個資料檔案中同一行的所有列的資料都可用。

假如一個 INSERT 語句帶來少于 1GB 的資料，結果的資料檔案小于理想大小。是以， 如何你是把一個 ETL 作業拆分成多個 INSERT 語句，請盡量保障每一個 INSERT 語句插入的資料接近 1GB 或 1GB 的倍數。

Parquet 資料檔案的行程編碼(RLE)和字典編碼

Parquet 使用一些自動壓縮技術，例如行程編碼(run-length encoding,RLE) 和字典編碼(dictionary encoding)，基于實際資料值的分析。一當資料值被編碼成緊湊的格式，使用壓縮算法，編碼的資料可能會被進一步壓縮。Impala 建立的 Parquet 資料檔案可以使用 Snappy, GZip, 或不進行壓縮；Parquet 規格還支援 LZO 壓縮，但是目前 Impala 不支援 LZO 壓縮的 Parquet 檔案。

除了應用到整個資料檔案的 Snappy 或 GZip 壓縮之外，RLE 和字段編碼是 Impala 自動應用到 Parquet 資料值群體的壓縮技術。這些自動優化可以節省你的時間和傳統資料倉庫通常需要的規劃。例如，字典編碼減少了建立數字 IDs 作為長字元串的縮寫的需求。

行程編碼(RLE)壓縮了一組重複資料值。例如，假如許多連續的行具有相同的國家編碼，這些重複的值可以表示為值和緊跟其後的值連續出現的次數。

字典編碼取出存在于列中的不同的值，每一個值都表示為一個 2 位元組的組合而不是使用原始的可能有多個位元組的值(對這些壓實的值進行了壓縮，額外節省了空間)。當列的不同值的個數少于 2**16 (16,384)個時，使用這一類型的編碼。他不會對 BOOLEAN 類型的列使用，因為已經足夠短。TIMESTAMP 的列有時每行都有不同的值，這時候可能很快就超過 2**16 個不同值的限制。列的這一 2**16 的限制被重置為每一個資料檔案内的限制，這樣如果幾個不同的資料檔案每個都包含 10,000 個不同的城市名，每一個資料檔案中的城市名列仍然可以使用字典編碼來凝練。

impala
上一篇: impala測試
下一篇: JavaScript的var let const

繼續閱讀