Spark 常用文件格式
介紹：
Apache Spark支持許多不同的數據格式，例如無處不在的CSV格式和Web友好的JSON格式。主要用於大數據分析目的的常見格式是Apache Parquet和Apache Avro。
在本文中，我們將使用Apache Spark來介紹這四種格式的特性-CSV，JSON，Parquet和Avro。
CSV
CSV（逗號分隔值）文件通常用於在使用純文本的系統之間交換表格數據。CSV是基於行的文件格式，這意味著文件的每一行都是表中的行。基本上，CSV包含一個標題行，該標題行提供了數據的列名，否則，文件被認為是部分結構化的。
CSV文件最初不能顯示層次結構或關係數據。數據連接通常使用多個CSV文件進行組織。外鍵存儲在一個或多個文件的列中，但是這些文件之間的鏈接不是由格式本身來表示的。另外，CSV格式尚未完全標準化，因此文件可以使用逗號以外的定界符，例如製表符或空格。
CSV文件的其他屬性之一是，僅當它是未壓縮的原始文件或使用可拆分壓縮格式（例如bzip2或lzo）時，它們才可以拆分（注意：lzo需要索引才能可拆分！）。
好處：
·CSV是人類可讀的，並且易於手動編輯。
·CSV提供了簡單明瞭的信息模式。
·幾乎所有現有應用程序都能處理CSV。
·CSV易於實現和解析。
·CSV緊湊。對於XML，您可以為每行中的每一列添加開始標籤和結束標籤。在CSV中，您只需寫入一次列標題。
缺點：
·CSV允許使用平面數據。除了格式外，還需要處理複雜的數據結構。
·不支持列類型。文本列和數字列之間沒有區別。
·沒有表示二進制數據的標準方法。
·導入CSV的問題（NULL和引號之間沒有區別）。
·特殊字符支持差。
·缺乏通用標準。
儘管存在侷限性，但CSV文件還是數據共享的流行選擇，因為它們得到了廣泛的業務應用程序，消費者和科學應用程序的支持。同樣，大多數批處理和流數據處理模塊（例如Spark和Hadoop）最初都支持CSV文件的序列化和反序列化，並提供了在讀取時添加架構的方法。
JSON格式
JSON數據（JavaScript對象表示法）以部分結構化格式表示為鍵值對。JSON通常與XML進行比較，因為它可以按分層格式存儲數據。子數據由父數據顯示。兩種格式都是自描述的，並且可由用戶讀取，但是JSON文檔通常要小得多。因此，它們更常用於網絡通信中，尤其是隨著基於REST的Web服務的出現。
由於許多數據傳輸已經使用JSON格式，因此大多數Web語言最初都支持JSON或使用外部庫對JSON數據進行序列化和反序列化。由於有了這種支持，JSON通過顯示數據結構，熱數據的交換格式和冷數據存儲以邏輯格式使用。
許多批處理和流數據處理模塊本機支持JSON序列化和反序列化。儘管JSON文檔中包含的數據最終可以以性能更優化的格式（例如Parquet或Avro）存儲，但它們提供原始數據，這對於重新處理數據非常重要（如有必要）。
JSON文件具有以下優點：
·JSON支持分層結構，簡化了一個文檔中相關數據的存儲和複雜關係的表示。
·大多數語言都提供簡化的JSON序列化庫或對JSON序列化/反序列化的內置支持。
·JSON支持對象列表，有助於避免列表到關係數據模型的錯誤轉換。
·JSON是NoSQL數據庫（例如MongoDB，Couchbase和Azure Cosmos DB）廣泛使用的文件格式。
·當今大多數工具中的內置支持。
Parquet
Parquet於2013年推出，由Cloudera和Twitter開發，用作基於列的存儲格式，已針對多列數據集進行了優化。由於數據是按列存儲的，因此可以進行高度壓縮（壓縮算法對信息熵較低的數據（通常包含在列中）的性能更好），並且可以拆分。該格式的開發者聲稱，這種存儲格式非常適合大數據問題。
與CSV和JSON不同，Parquet文件是二進制文件，其中包含有關其內容的元數據。因此，無需讀取/解析文件的內容，Spark可以僅依靠元數據來確定列名稱，壓縮/編碼，數據類型，甚至一些基本統計信息。Parquet文件的列元數據存儲在文件的末尾，從而可以進行快速的一次性寫入。
Parquet針對“一次寫入多次讀取”（WORM）範例進行了優化。寫起來很慢，但是讀起來卻快得令人難以置信，尤其是當您僅訪問總列的一個子集時。對於需要大量讀取的工作負載，鑲木地板是一個不錯的選擇。對於需要對整行數據進行操作的用例，應使用CSV或AVRO之類的格式。
Parquet中數據存儲的優點：
·Parquet是一種柱狀格式。僅需要的列將被獲取/讀取，這減少了磁盤I / O。這個概念稱為投影下推。
·模式隨數據一起移動，因此數據是自描述的。
·儘管事實是它是為HDFS創建的，但數據仍可以存儲在其他文件系統中，例如GlusterFs或NFS之上。
·Parquet只是文件，這意味著可以輕鬆使用它們，移動，備份和複製它們。
·開箱即用的Spark內部支持提供了將文件簡單地保存並保存到存儲中的功能。
·即使使用像Snappy這樣的壓縮格式，Parquet也可以提供高達75％的極佳壓縮率。
·如實踐所示，與其他文件格式相比，此格式是讀取工作流最快的格式。
·Parquet非常適用於需要對大量數據的某些列進行聚合的數據倉庫類型的解決方案。
·可以使用Avro API和Avro Schema（可以將所有原始數據存儲為Avro格式，但將所有處理後的數據存儲在Parquet中）來讀取和寫入Parquet。
·它還提供謂詞下推，從而進一步降低了磁盤I / O成本。
謂詞下推/過濾下推（Predicate Pushdown/Filter Pushdown）
謂詞下推的基本思想是可以將查詢的某些部分（謂詞）“推送”到存儲數據的位置。例如，當我們提供一些過濾條件時，數據存儲將在從磁盤讀取數據時嘗試過濾記錄。
謂詞下推的優點是更少的磁盤I / O發生。結果，性能更好。否則，整個數據將被帶入內存，然後進行過濾，這將導致大量的內存需求。
此優化可以通過較早而不是稍後過濾掉數據來大大減少查詢/處理時間。根據處理框架的不同，謂詞下推可以通過執行以下操作來優化查詢，例如在通過網絡傳輸之前過濾數據，在加載到內存之前過濾數據或跳過讀取整個文件或文件塊的操作。
大多數RDBMS都遵循此概念，Parquet和ORC等大數據存儲格式也遵循此概念。
投影下推（Projection Pushdown）
從數據存儲中讀取數據時，根據查詢，僅將讀取那些必需的列；並非所有字段都將被讀取。通常，Parquets和ORC之類的列格式遵循此概念，從而產生更好的I / O性能。
Avro
Apache Avro由Hadoop工作組於2009年發佈。它是一種基於行的格式，可高度拆分。它也被描述為類似於Java序列化的數據序列化系統。模式以JSON格式存儲，而數據以二進制格式存儲，從而最大程度地減小了文件大小並提高了效率。
Avro通過管理添加的字段，缺少的字段和已更改的字段，為模式演變提供了強大的支持。這使舊軟件可以讀取新數據，而新軟件可以讀取舊數據-如果您的數據有可能更改，則這是一項關鍵功能。
藉助Avro的模式架構管理能力，可以在不同時間獨立更新組件，從而降低不兼容風險。這使應用程序不必編寫if-else語句來處理不同的架構版本，並且使開發人員不必查看舊代碼來理解舊架構。
由於架構的所有版本都存儲在人類可讀的JSON標頭中，因此很容易理解所有可用字段。
Avro可以支持許多不同的編程語言。因為架構是在數據以二進制形式存儲時以JSON格式存儲的，所以Avro是持久性數據存儲和電匯的相對緊湊的選擇。由於Avro易於附加新行，因此它通常是繁重的寫工作負載的首選格式。
好處：
·Avro是與語言無關的數據序列化。
·Avro將模式存儲在文件的標題中，以便數據可以自我描述。
·Avro格式的文件可拆分且可壓縮，因此非常適合在Hadoop生態系統中進行數據存儲。
·用於讀取Avro文件的架構不必與用於寫入文件的架構相同。這樣就可以獨立添加新字段。
·與序列文件一樣，Avro文件也包含用於分隔塊的同步標記。這使其高度可拆分。
·可以使用諸如snappy之類的壓縮格式來壓縮這些塊。
總結
格式比較
*當壓縮為CSV時，JSON具有可拆分性相同的問題，但有一個額外的區別。當“ wholeFile”選項設置為true時（例如：SPARK-18352），JSON不可拆分。
1. CSV通常應該是最快寫入的。JSON應該是人類最容易理解的。Parquet應該是最快讀取列的一個子集，而Avro應該是最快讀取一次所有列的。
2. JSON是用於在網絡上進行通信的標準。由於API和網站的可用性屬性（如定義良好的架構），它們一直在使用JSON進行通信。
3. Parquet和Avro絕對針對大數據需求進行了優化，包括可拆分性，壓縮支持，對複雜數據結構的強大支持。不幸的是，可讀性和寫入速度都非常差。
譯自 ：dzone
如果發現任何不正確的地方，或者想分享有關上述主題的更多信息，歡迎反饋。
閱讀更多 數據大視界 的文章
