hadoop文件存儲格式

❶ 大數據常用文件格式介紹

圖片看不見的話可以看我CSDN上的文章：
https://blog.csdn.net/u013332124/article/details/86423952

最近在做hdfs小文件合並的項目，涉及了一些文件格式的讀寫，比如avro、orc、parquet等。期間閱讀了一些資料，因此打算寫篇文章做個記錄。

這篇文章不會介紹如何對這些格式的文件進行讀寫，只會介紹一下它們各自的特點以及底層存儲的編碼格式 。

[圖片上傳失敗...(image-a5104a-1547368703623)]

使用sequencefile還可以將多個小文件合並到一個大文件中，通過key-value的形式組織起來，此時該sequencefile可以看做是一個小文件容器。

[圖片上傳失敗...(image-4d03a2-1547368703623)]

Parquet是一個基於列式存儲的文件格式，它將數據按列劃分進行存儲。Parquet官網上的文件格式介紹圖：

[圖片上傳失敗...(image-92770e-1547368703623)]

我們可以看出，parquet由幾個部分構成：

[圖片上傳失敗...(image-391e57-1547368703623)]

Orc也是一個列式存儲格式，產生自Apache Hive，用於降低Hadoop數據存儲空間和加速Hive查詢速度。

[圖片上傳失敗...(image-ba6160-1547368703623)]

目前列式存儲是大數據領域基本的優化項，無論是存儲還是查詢，列式存儲能做的優化都很多，看完上面對orc和parquet的文件結構介紹後，我們列式存儲的優化點做一個總結：

在壓縮方面 ：

在查詢方面 ：

就網上找到的一些數據來看，Orc的壓縮比會比Parquet的高一些，至於查詢性能，兩個應該不會差距太大。本人之前做過一個測試，在多數場景，hive on mr下，orc的查詢性能會更好一些。換成hive on spark後，parquet的性能更好一些

本文介紹的4種大數據存儲格式，2個是行式存儲，2個是列式存儲，但我們可以看到一個共同點：它們都是支持分割的。這是大數據文件結構體系中一個非常重要的特點， 因為可分割使一個文件可以被多個節點並發處理，提高數據的處理速度 。

另外，當前大數據的主要趨勢應該是使用列式存儲，目前我們公司已經逐步推進列式存儲的使用，本人也在hive上做過一些測試，在多個查詢場景下，無論是orc還是parquet的查詢速度都完爆text格式的， 差不多有4-8倍的性能提升 。另外，orc和parquet的壓縮比都能達到10比1的程度。因此，無論從節約資源和查詢性能考慮，在大多數情況下，選擇orc或者parquet作為文件存儲格式是更好的選擇。另外，spark sql的默認讀寫格式也是parquet。

當然，並不是說列式存儲已經一統天下了，大多時候我們還是要根據自己的使用場景來決定使用哪種存儲格式。

Sequencefile

https://blog.csdn.net/en_joker/article/details/79648861

https://stackoverflow.com/questions/11778681/advantages-of-sequence-file-over-hdfs-textfile

Avro和Sequencefile區別

https://stackoverflow.com/questions/24236803/difference-between-avrodata-file-and-sequence-file-with-respect-to-apache-sqoop

parquet

https://www.cnblogs.com/ITtangtang/p/7681019.html

Orc

https://www.cnblogs.com/ITtangtang/p/7677912.html

https://www.cnblogs.com/cxzdy/p/5910760.html

Orc和parquet的一些對比

https://blog.csdn.net/colorant/article/details/53699822

https://blog.csdn.net/yu616568/article/details/51188479

❷ Hbase與HDFS是個什麼關系

他們的關系是：hbase是一個內存資料庫，而hdfs是一個存儲空間；是物品和房子的關系。

hdfs只是一個存儲空間，他的完整名字是分布式文件系統。從名字可知他的作用了。
hbase是一個內存資料庫，簡單點說hbase把表啊什麼的存在hdfs上。

❸ 如何讓Hadoop讀取以gz結尾的文本格式的文件

分析過程：

通過上面的異常，立馬猜想到是由於我的文件是gz結尾，所以hadoop把它當作了壓縮文件，然後嘗試解壓縮後讀取，所以解壓失敗了。於是去問google，沒有搜到能夠直接解決我問題的答案，但是搜到了此處相關的源代碼：LineRecordReader.java;於是嘗試著去閱讀代碼來解決問題，這個類很簡單，繼承自RecordReader，沒有看到next函數和readLine函數，那就應該是基類實現的。很快發現了看名字是跟壓縮解碼相關的代碼：

private CompressionCodecFactory compressionCodecs = null;
...
compressionCodecs = new CompressionCodecFactory(job);
final CompressionCodec codec = compressionCodecs.getCodec(file);
...
if (codec != null) {
in = new LineReader(codec.createInputStream(fileIn), job);
}
else{
...
in = new LineReader(fileIn, job);
}

此處file就是拿到的文件路徑，可以看到，應該就是通過CompressionCode.getCode(file)函數，拿到的codec類，然後讀取的時候出異常了。那怎麼讓MapRece程序把這個.gz文件當作普通的文本文件呢？再點進去看CompressionCodeFactory.java的代碼。getCodec函數的代碼如下：

/**
* Find the relevant compression codec for the given file based on its
* filename suffix.
* @param file the filename to check
* @return the codec object
*/
public CompressionCodec getCodec(Path file) {
CompressionCodec result = null;
if (codecs != null) {
String filename = file.getName();
String reversedFilename = new StringBuffer(filename).reverse().toString();
SortedMap<String, CompressionCodec> subMap = codecs.headMap(reversedFilename);
if (!subMap.isEmpty()) {
String potentialSuffix = subMap.lastKey();
if (reversedFilename.startsWith(potentialSuffix)) {
result = codecs.get(potentialSuffix);
}
}
}
return result;
}

❹ Hbase與HDFS是什麼關系

HDFS是GFS的一種實現，他的完整名字是分布式文件系統，類似於FAT32，NTFS，是一種文件格式，是底層的，Hadoop HDFS為HBase提供了高可靠性的底層存儲支持。

HBase是Google Bigtable的開源實現，類似Google Bigtable利用GFS作為其文件存儲系統，HBase利用Hadoop HDFS作為其文件存儲系統。

(4)hadoop文件存儲格式擴展閱讀：

Hadoop 中各模塊的作用：

1、Hadoop HDFS為HBase提供了高可靠性的底層存儲支持。

2、Hadoop MapRece為HBase提供了高性能的計算能力。

3、Zookeeper為HBase提供了穩定服務和failover機制。

4、Pig和Hive還為HBase提供了高層語言支持，使得在HBase上進行數據統計處理變得非常簡單。

5、Sqoop則為HBase提供了方便的RDBMS（關系型資料庫）數據導入功能，使得傳統資料庫數據向HBase中遷移變得非常方便。