『壹』 Spark 處理小文件
不論是Hive還是Spark sql在使用過程中都可能會遇到小文件過多的問題。小文件過多最直接的表現是任務執行時間長，查看Spark log會發現大量的數據移動的日誌。我們可以查看log中展現的日誌信息，去對應的路徑下查看文件的大小和個數。
通過上述命令可以查看文件的個數以及大小。count查看出的文件大小單位是B，需要轉換為MB。
在spark官方的推薦文檔中，parquet格式的文件推薦大小是128MB，小於該大小的均可以稱之為小文件，在實際的工作，往往小文件的大小僅僅為幾KB，表現為，可能文件大小為幾百MB，但是文件個數可能到達了幾十萬個。一般來說，我們可以通過簡單相除獲得文件的平均大小，如果文件數目不多，我們也可以通過下述命令獲得每個文件的大小。
1.任務執行時間長
2.真實的文件大小獨佔一個數據存儲塊，存放到DataNode節點中。同時 DataNode一般默認存三份副本，以保障數據安全。同時該文件所存放的位置也寫入到NameNode的內存中，如果有Secondary NameNode高可用節點，也可同時復制一份過去。NameNode的內存數據將會存放到硬碟中，如果HDFS發生重啟，將產生較長時間的元數據從硬碟讀到內存的過程。
3.不論在Hive還是在Spark中，每一個存儲塊都對應一個Map程序，一個Map呈現就需要一個JVM，啟動一個JVM去讀取或者寫小文件是吃力不討好的行為。在實際的生產中，為了更好的管理集群資源，一般會要求程序執行時限制Executor數量和每個Executor的核心數量，需要頻繁創建Executor來讀取寫入。
5.影響磁碟定址時間
小文件合並，本質上就是通過某種操作，將一系列小文件合並成大文件。我們知道，以MapRece為代表的大數據系統，都習慣用K-V鍵值對的形式來處理文件，最後文件落盤，也是一個rece對應一個輸出文件。所以直觀上，我們可以減少rece數量，達到減少文件數量的目的。
從Map到Rece需要一個Shuffle過程，所以我們將小文件合並理解為通過一個Shuffle，合並小文件成一個大文件。基於這樣的思想，我們的策略可以分為兩類：一類是原來的計算已經有Shuffle了，那麼我們可以認為控制輸出文件的數量；二類是強制觸發Shuffle，進行小文件合並。
1-設置參數 (一般用於Hive)
2-distribute by rand()
往動態分區插入數據時，在已經寫好的SQL末尾加上distribute by rand()
該運算元只是起到打散的效果，但是我們還要設置文件的大小，以免打散後仍然有小文件。
表示每個rece的大小，Hive可以數據總量，得到rece個數，假設hive認為會有10個rece,那麼，這里rand()則會為 x % 10
3-group by
我們知道，group by運算元會觸發Shuffle，因此只要我們設置好Shuffle時的文件個數就好，在Spark SQL中，我們可以設置partition個數，因為一個partition會對應一個文件。
上述的操作，會觸發shuffle，因此我們再設置partition個數。
則表示，shuffle後，只會產生10個partition.
4-repartition()
5-coalesce()
需要注意的是，4和5都是spark 2.4以及以後才會支持的。
『貳』 AWS Glue中使用Spark SQL
AWS Glue 是一項完全託管的提取、轉換和載入 (ETL) 服務，讓客戶能夠輕松准備和載入數據進行分析。您只需在 AWS 管理控制台中單擊幾次，即可創建並運行 ETL 作業。您只需將 AWS Glue 指向存儲在 AWS 上的數據，AWS Glue 便會發現您的數據，並將關聯的元數據（例如表定義和架構）存儲到 AWS Glue 數據目錄中。存入目錄後，您的數據可立即供 ETL 搜索、查詢和使用。
Glue提供了DynamicFrame來操作數據，但如果用戶習慣用Spark SQL來做ETL，那是否可行呢？ 本文就做了一個嘗試：
首先我們創建一個基本的Glue Job，選擇Spark，這里要注意在Job parameters裡面加上
--enable-glue-datacatalog = true
這是為了在Spark SQL中使用Glue的元數據。
之後其他步驟都隨意選擇，進入腳本編輯環境，將腳本替換成如下:
這里做了一個簡單的insert overwrite操作，從表testdata1中選擇數據到表table_6。
嘗試運行Job，等待7-8分鍾後就可以看到任務完成了。此時去檢查table_6的數據，已經有了。
『叄』 Spark SQL CLI的元資料庫和數據默認情況下分別存在什麼地方
默認使用derby資料庫，存在本地文件
『肆』 怎樣的架構設計才是真正的數據倉庫架構
一直想整理一下這塊內容，既然是漫談，就想起什麼說什麼吧。我一直是在互聯網行業，就以互聯網行業來說。
先大概列一下互聯網行業數據倉庫、數據平台的用途：
整合公司所有業務數據，建立統一的數據中心；
提供各種報表，有給高層的，有給各個業務的；
為網站運營提供運營上的數據支持，就是通過數據，讓運營及時了解網站和產品的運營效果；
為各個業務提供線上或線下的數據支持，成為公司統一的數據交換與提供平台；
分析用戶行為數據，通過數據挖掘來降低投入成本，提高投入效果；比如廣告定向精準投放、用戶個性化推薦等；
開發數據產品，直接或間接為公司盈利；
建設開放數據平台，開放公司數據；
。。。。。。
- 上面列出的內容看上去和傳統行業數據倉庫用途差不多，並且都要求數據倉庫/數據平台有很好的穩定性、可靠性；但在互聯網行業，除了數據量大之外，越來越多的業務要求時效性，甚至很多是要求實時的 ，另外，互聯網行業的業務變化非常快，不可能像傳統行業一樣，可以使用自頂向下的方法建立數據倉庫，一勞永逸，它要求新的業務很快能融入數據倉庫中來，老的下線的業務，能很方便的從現有的數據倉庫中下線；
- 其實，互聯網行業的數據倉庫就是所謂的敏捷數據倉庫，不但要求能快速的響應數據，也要求能快速的響應業務；
- 建設敏捷數據倉庫，除了對架構技術上的要求之外，還有一個很重要的方面，就是數據建模，如果一上來就想著建立一套能兼容所有數據和業務的數據模型，那就又回到傳統數據倉庫的建設上了，很難滿足對業務變化的快速響應。應對這種情況，一般是先將核心的持久化的業務進行深度建模（比如：基於網站日誌建立的網站統計分析模型和用戶瀏覽軌跡模型；基於公司核心用戶數據建立的用戶模型），其它的業務一般都採用維度+寬表的方式來建立數據模型。這塊是後話。
- 整體架構下面的圖是我們目前使用的數據平台架構圖，其實大多公司應該都差不多：
- 邏輯上，一般都有數據採集層、數據存儲與分析層、數據共享層、數據應用層。可能叫法有所不同，本質上的角色都大同小異。
- 我們從下往上看：
- 數據採集數據採集層的任務就是把數據從各種數據源中採集和存儲到數據存儲上，期間有可能會做一些簡單的清洗。
- 數據源的種類比較多：
網站日誌：
- 作為互聯網行業，網站日誌占的份額最大，網站日誌存儲在多台網站日誌伺服器上，
- 一般是在每台網站日誌伺服器上部署flume agent，實時的收集網站日誌並存儲到HDFS上；
業務資料庫：
- 業務資料庫的種類也是多種多樣，有Mysql、Oracle、SqlServer等，這時候，我們迫切的需要一種能從各種資料庫中將數據同步到HDFS上的工具，Sqoop是一種，但是Sqoop太過繁重，而且不管數據量大小，都需要啟動MapRece來執行，而且需要Hadoop集群的每台機器都能訪問業務資料庫；應對此場景，淘寶開源的DataX，是一個很好的解決方案（可參考文章 《異構數據源海量數據交換工具-Taobao DataX 下載和使用》），有資源的話，可以基於DataX之上做二次開發，就能非常好的解決，我們目前使用的DataHub也是。
- 當然，Flume通過配置與開發，也可以實時的從資料庫中同步數據到HDFS。
來自於Ftp/Http的數據源：
- 有可能一些合作夥伴提供的數據，需要通過Ftp/Http等定時獲取，DataX也可以滿足該需求；
其他數據源：
- 比如一些手工錄入的數據，只需要提供一個介面或小程序，即可完成；
- 數據存儲與分析毋庸置疑，HDFS是大數據環境下數據倉庫/數據平台最完美的數據存儲解決方案。
- 離線數據分析與計算，也就是對實時性要求不高的部分，在我看來，Hive還是首當其沖的選擇，豐富的數據類型、內置函數；壓縮比非常高的ORC文件存儲格式；非常方便的SQL支持，使得Hive在基於結構化數據上的統計分析遠遠比MapRece要高效的多，一句SQL可以完成的需求，開發MR可能需要上百行代碼；
- 當然，使用Hadoop框架自然而然也提供了MapRece介面，如果真的很樂意開發Java，或者對SQL不熟，那麼也可以使用MapRece來做分析與計算；Spark是這兩年非常火的，經過實踐，它的性能的確比MapRece要好很多，而且和Hive、Yarn結合的越來越好，因此，必須支持使用Spark和SparkSQL來做分析和計算。因為已經有Hadoop Yarn，使用Spark其實是非常容易的，不用單獨部署Spark集群，關於Spark On Yarn的相關文章，可參考：《Spark On Yarn系列文章》
- 實時計算部分，後面單獨說。
- 數據共享這里的數據共享，其實指的是前面數據分析與計算後的結果存放的地方，其實就是關系型資料庫和NOSQL資料庫；
- 前面使用Hive、MR、Spark、SparkSQL分析和計算的結果，還是在HDFS上，但大多業務和應用不可能直接從HDFS上獲取數據，那麼就需要一個數據共享的地方，使得各業務和產品能方便的獲取數據；和數據採集層到HDFS剛好相反，這里需要一個從HDFS將數據同步至其他目標數據源的工具，同樣，DataX也可以滿足。
- 另外，一些實時計算的結果數據可能由實時計算模塊直接寫入數據共享。
- 數據應用
業務產品
- 業務產品所使用的數據，已經存在於數據共享層，他們直接從數據共享層訪問即可；
報表
- 同業務產品，報表所使用的數據，一般也是已經統計匯總好的，存放於數據共享層；
即席查詢
- 即席查詢的用戶有很多，有可能是數據開發人員、網站和產品運營人員、數據分析人員、甚至是部門老大，他們都有即席查詢數據的需求；
- 這種即席查詢通常是現有的報表和數據共享層的數據並不能滿足他們的需求，需要從數據存儲層直接查詢。
- 即席查詢一般是通過SQL完成，最大的難度在於響應速度上，使用Hive有點慢，目前我的解決方案是SparkSQL，它的響應速度較Hive快很多，而且能很好的與Hive兼容。
- 當然，你也可以使用Impala，如果不在乎平台中再多一個框架的話。
OLAP
- 目前，很多的OLAP工具不能很好的支持從HDFS上直接獲取數據，都是通過將需要的數據同步到關系型資料庫中做OLAP，但如果數據量巨大的話，關系型資料庫顯然不行；
- 這時候，需要做相應的開發，從HDFS或者HBase中獲取數據，完成OLAP的功能；
- 比如：根據用戶在界面上選擇的不定的維度和指標，通過開發介面，從HBase中獲取數據來展示。
其它數據介面
- 這種介面有通用的，有定製的。比如：一個從Redis中獲取用戶屬性的介面是通用的，所有的業務都可以調用這個介面來獲取用戶屬性。
- 實時計算現在業務對數據倉庫實時性的需求越來越多，比如：實時的了解網站的整體流量；實時的獲取一個廣告的曝光和點擊；在海量數據下，依靠傳統資料庫和傳統實現方法基本完成不了，需要的是一種分布式的、高吞吐量的、延時低的、高可靠的實時計算框架；Storm在這塊是比較成熟了，但我選擇Spark Streaming，原因很簡單，不想多引入一個框架到平台中，另外，Spark Streaming比Storm延時性高那麼一點點，那對於我們的需要可以忽略。
- 我們目前使用Spark Streaming實現了實時的網站流量統計、實時的廣告效果統計兩塊功能。
- 做法也很簡單，由Flume在前端日誌伺服器上收集網站日誌和廣告日誌，實時的發送給Spark Streaming，由Spark Streaming完成統計，將數據存儲至Redis，業務通過訪問Redis實時獲取。
- 任務調度與監控在數據倉庫/數據平台中，有各種各樣非常多的程序和任務，比如：數據採集任務、數據同步任務、數據分析任務等；
- 這些任務除了定時調度，還存在非常復雜的任務依賴關系，比如：數據分析任務必須等相應的數據採集任務完成後才能開始；數據同步任務需要等數據分析任務完成後才能開始；這就需要一個非常完善的任務調度與監控系統，它作為數據倉庫/數據平台的中樞，負責調度和監控所有任務的分配與運行。
- 前面有寫過文章，《大數據平台中的任務調度與監控》,這里不再累贅。
- 總結在我看來架構並不是技術越多越新越好，而是在可以滿足需求的情況下，越簡單越穩定越好。目前在我們的數據平台中，開發更多的是關注業務，而不是技術，他們把業務和需求搞清楚了，基本上只需要做簡單的SQL開發，然後配置到調度系統就可以了，如果任務異常，會收到告警。這樣，可以使更多的資源專注於業務之上。
『伍』 技術選型 - OLAP大數據技術哪家強
Lambda架構的核心理念是「流批一體化」，因為隨著機器性能和數據框架的不斷完善，用戶其實不關心底層是如何運行的，批處理也好，流式處理也罷，能按照統一的模型返回結果就可以了，這就是Lambda架構誕生的原因。現在很多應用，例如Spark和Flink，都支持這種結構，也就是數據進入平台後，可以選擇批處理運行，也可以選擇流式處理運行，但不管怎樣，一致性都是相同的。
Kylin
Kylin的主要特點是預計算，提前計算好各個cube，這樣的優點是查詢快速，秒級延遲；缺點也非常明顯，靈活性不足，無法做一些 探索 式的，關聯性的數據分析。
適合的場景也是比較固定的，場景清晰的地方。
ClickHouse
Clickhouse由俄羅斯yandex公司開發。專為在線數據分析而設計。
Clickhouse最大的特點首先是快 ，為了快採用了列式儲存，列式儲存更好的支持壓縮，壓縮後的數據傳輸量變小，所以更快；同時支持分片，支持分布式執行，支持SQL。
ClickHouse很輕量級，支持數據壓縮和最終數據一致性，其數據量級在PB級別。
另外Clickhouse不是為關聯分析而生，所以多表關聯支持的不太好。
同樣Clickhouse不能修改或者刪除數據，僅能用於批量刪除或修改。沒有完整的事務支持，不支持二級索引等等，缺點也非常明顯。
與Kylin相比ClickHouse更加的靈活，sql支持的更好，但是相比Kylin，ClickHouse不支持大並發，也就是不能很多訪問同時在線。
總之ClickHouse用於在線數據分析，支持功能簡單。CPU 利用率高，速度極快。最好的場景用於行為統計分析。
Hive
Hive這個工具，大家一定很熟悉，大數據倉庫的首選工具。可以將結構化的數據文件映射為一張資料庫表，並提供完整的sql查詢功能。
主要功能是可以將sql語句轉換為相對應的MapRece任務進行運行，這樣可能處理海量的數據批量，
Hive與HDFS結合緊密，在大數據開始初期，提供一種直接使用sql就能訪問HDFS的方案，擺脫了寫MapRece任務的方式，極大的降低了大數據的門檻。
當然Hive的缺點非常明顯，定義的是分鍾級別的查詢延遲，估計都是在比較理想的情況。 但是作為數據倉庫的每日批量工具，的確是一個穩定合格的產品。
Presto
Presto極大的改進了Hive的查詢速度，而且Presto 本身並不存儲數據，但是可以接入多種數據源，並且支持跨數據源的級聯查詢，支持包括復雜查詢、聚合、連接等等。
Presto沒有使用MapRece，它是通過一個定製的查詢和執行引擎來完成的。它的所有的查詢處理是在內存中，這也是它的性能很高的一個主要原因。
Presto由於是基於內存的，缺點可能是多張大表關聯操作時易引起內存溢出錯誤。
另外Presto不支持OLTP的場景，所以不要把Presto當做資料庫來使用。
Presto相比ClickHouse優點主要是多表join效果好。相比ClickHouse的支持功能簡單，場景支持單一，Presto支持復雜的查詢，應用范圍更廣。
Impala
Impala是Cloudera 公司推出，提供對 HDFS、Hbase 數據的高性能、低延遲的互動式 SQL 查詢功能。
Impala 使用 Hive的元數據, 完全在內存中計算。是CDH 平台首選的 PB 級大數據實時查詢分析引擎。
Impala 的缺點也很明顯，首先嚴重依賴Hive，而且穩定性也稍差，元數據需要單獨的mysql/pgsql來存儲，對數據源的支持比較少，很多nosql是不支持的。但是，估計是cloudera的國內市場推廣做的不錯，Impala在國內的市場不錯。
SparkSQL
SparkSQL的前身是Shark，它將 SQL 查詢與 Spark 程序無縫集成，可以將結構化數據作為 Spark 的 RDD 進行查詢。
SparkSQL後續不再受限於Hive，只是兼容Hive。
SparkSQL提供了sql訪問和API訪問的介面。
支持訪問各式各樣的數據源，包括Hive, Avro, Parquet, ORC, JSON, and JDBC。
Drill
Drill好像國內使用的很少，根據定義，Drill是一個低延遲的分布式海量數據互動式查詢引擎，支持多種數據源，包括hadoop，NoSQL存儲等等。
除了支持多種的數據源，Drill跟BI工具集成比較好。
Druid
Druid是專為海量數據集上的做高性能 OLAP而設計的數據存儲和分析系統。
Druid 的架構是 Lambda 架構，分成實時層和批處理層。
Druid的核心設計結合了數據倉庫，時間序列資料庫和搜索系統的思想，以創建一個統一的系統，用於針對各種用例的實時分析。Druid將這三個系統中每個系統的關鍵特徵合並到其接收層，存儲格式，查詢層和核心體系結構中。
目前 Druid 的去重都是非精確的，Druid 適合處理星型模型的數據，不支持關聯操作。也不支持數據的更新。
Druid最大的優點還是支持實時與查詢功能，解約了很多開發工作。
Ku
ku是一套完全獨立的分布式存儲引擎，很多設計概念上借鑒了HBase，但是又跟HBase不同，不需要HDFS，通過raft做數據復制；分片策略支持keyrange和hash等多種。
數據格式在parquet基礎上做了些修改，支持二級索引，更像一個列式存儲，而不是HBase schema-free的kv方式。
ku也是cloudera主導的項目，跟Impala結合比較好，通過impala可以支持update操作。
ku相對於原有parquet和ORC格式主要還是做增量更新的。
Hbase
Hbase使用的很廣,更多的是作為一個KV資料庫來使用，查詢的速度很快。
Hawq
Hawq是一個Hadoop原生大規模並行SQL分析引擎，Hawq採用 MPP 架構，改進了針對 Hadoop 的基於成本的查詢優化器。
除了能高效處理本身的內部數據，還可通過 PXF 訪問 HDFS、Hive、HBase、JSON 等外部數據源。HAWQ全面兼容 SQL 標准，還可用 SQL 完成簡單的數據挖掘和機器學習。無論是功能特性，還是性能表現，HAWQ 都比較適用於構建 Hadoop 分析型數據倉庫應用。
『陸』 sparkSQL用jdbc連接hive和用元數據連接hive的區別，各自優缺點
spark on hive : 是spark 通過spark-sql 使用hive 語句操作hive ,底層運行的還是 spark rdd.
*（1）就是通過sparksql，載入hive的配置文件，獲取到hive的元數據信息
* （2）spark sql獲取到hive的元數據信息之後就可以拿到hive的所有表的數據
* （3）接下來就可以通過spark sql來操作hive表中的數據
hive on spark: 是hive 等的執行引擎變成spark , 不再是maprece. 相對於上一項,這個要實現責麻煩很多, 必須重新編譯你的spark. 和導入jar包,
『柒』 spark 怎麼獲取dataframe的元數據信息
而case class類就是繼承了Proct。我們所熟悉的TupleN類型也是繼承了scala.Proct類的，所以我們也可以通過TupleN來創建DataFrame：
[python] view plain
val mobiles=sqlContext.createDataFrame(Seq((1,"Android"), (2, "iPhone"))) mobiles.printSchema mobiles.show()
root
|-- _1: integer (nullable = false)
|-- _2: string (nullable = true)
+---+-------+
| _1| _2|
『捌』 hive kerberos sparksql怎麼創建hivecontext
park+shark ,可以直接用hive原來的表。
phpHiveAdmin將HQL請求發送給HAproxy負載的Hive server集群。 三、phpHiveAdmin讀取Metadata的數據，注意這里是只讀，並不存在對Metadata的讀寫。因為元數據非常重要，涉及到底層數據的正確性，所以不能隨意修改。
『玖』 spark與hive查詢得出的數據不同
在實際工作的情況中，經常有spark與hive查詢出來的數據存在不一樣的情況，基本的原因如下： 1、由於精度不一樣導致的 2、更多的時候確實是由於元數據混亂導致的 （就是說hive中能讀到這個欄位的值，但是在spark中卻無法讀取到該欄位的值。 很多時候可能還是由於大小寫的混亂所導致的） 同一條sql,hive能生成表,而spark卻生成的一張空表,或者數據缺少,存在null值,與hive結果不一致 設置 spark.sql.hive.convertMetastoreOrc=false convertMetastoreParquet=false 原因: spark用自己的格式讀取hive文件後進行自動轉換後進行操作 官方說明『拾』 【數倉】對比spark-hive的兩種分布式計算模式
最近在學習過程中發現SparkSQL、Hive on Spark、Spark on Hive是非常容易混淆的的概念。了解三者的關系前，先要先明白幾個概念。
相對於HIve on MapRece，本質上來說，Hive on Spark是Hive把自己的引擎從MapRece替換為更高效的SparkRDD。數據源是hive本身，當我們執行HQL時底層已經不再是將HQL轉換為MapRece任務，而是跑SparkRDD任務。
在hive-site-xml中把hive.execution.engine配置換成spark，在hive所在節點安裝Spark並配置環境變數。外部遠程登錄或者hive命令行模式就會執行spark任務了。
即：Hive on Spark = HQL解析 + SparkRDD引擎
Spark on Hive是以Spark角度看Hive是數據源，在Spark中配置Hive，並獲取Hive中的元數據，然後用SparkSQL操作hive表的數據並直接翻譯成SparkRDD任務。Hive只是作為一個Spark的數據源。
bin/spark-sql、bin/spark-submit採用的是這種方式。提交任務的jar必須帶著hive-site.xml的配置。
即：Spark on Hive = SparkSql解析 + SparkRDD引擎
Spark on Hive的模式更加絲滑，性能更好。
HIve on Spark的模式對大數據周邊組件的支持兼容性更好。