kafka的message包括哪些資訊 一個Kafka的Message由一個固定長度的header和一個變長的訊息體body組成 header部分由一個位元組的magic(檔案格式)和四個位元組的CRC32(用於判斷body訊息體是否正常)構成。當magic的值為1的時候，會在magic和crc32之間多一個位元組的資料：attributes(儲存一些相關屬性，比如是否壓縮、壓縮格式等等)；如果magic的值為0，那麼不存在attributes屬性 body是由N個位元組構成的一個訊息體，包含了具體的key/value訊息

怎麼檢視kafka的offset 0.9版本以上，可以用最新的Consumer client 客戶端，有consumer.seekToEnd() / consumer.position() 可以用於得到當前最新的offset：

hadoop的shuffle過程 一、Map端的shuffle 　　Map端會處理輸入資料併產生中間結果，這個中間結果會寫到本地磁碟，而不是HDFS。每個Map的輸出會先寫到記憶體緩衝區中，當寫入的資料達到設定的閾值時，系統將會啟動一個執行緒將緩衝區的資料寫到磁碟，這個過程叫做spill。 　　在spill寫入之前，會先進行二次排序，首先根據資料所屬的partition進行排序，然後每個partition中的資料再按key來排序。partition的目是將記錄劃分到不同的Reducer上去，以期望能夠達到負載均衡，以後的Reducer就會根據partition來讀取自己對應的資料。接著執行combiner(如果設定了的話)，combiner的本質也是一個Reducer，其目的是對將要寫入到磁碟上的檔案先進行一次處理，這樣，寫入到磁碟的資料量就會減少。最後將資料寫到本地磁碟產生spill檔案(spill檔案儲存在{mapred.local.dir}指定的目錄中，Map任務結束後就會被刪除)。 　　最後，每個Map任務可能產生多個spill檔案，在每個Map任務完成前，會通過多路歸併演算法將這些spill檔案歸併成一個檔案。至此，Map的shuffle過程就結束了。

二、Reduce端的shuffle

　　Reduce端的shuffle主要包括三個階段，copy、sort(merge)和reduce。 　　首先要將Map端產生的輸出檔案拷貝到Reduce端，但每個Reducer如何知道自己應該處理哪些資料呢？因為Map端進行partition的時候，實際上就相當於指定了每個Reducer要處理的資料(partition就對應了Reducer)，所以Reducer在拷貝資料的時候只需拷貝與自己對應的partition中的資料即可。每個Reducer會處理一個或者多個partition，但需要先將自己對應的partition中的資料從每個Map的輸出結果中拷貝過來。 　　接下來就是sort階段，也成為merge階段，因為這個階段的主要工作是執行了歸併排序。從Map端拷貝到Reduce端的資料都是有序的，所以很適合歸併排序。最終在Reduce端生成一個較大的檔案作為Reduce的輸入。 　　最後就是Reduce過程了，在這個過程中產生了最終的輸出結果，並將其寫到HDFS上。

spark叢集運算的模式 Spark 有很多種模式，最簡單就是單機本地模式，還有單機偽分散式模式，複雜的則執行在叢集中，目前能很好的執行在 Yarn和 Mesos 中，當然 Spark 還有自帶的 Standalone 模式，對於大多數情況 Standalone 模式就足夠了，如果企業已經有 Yarn 或者 Mesos 環境，也是很方便部署的。 standalone(叢集模式)：典型的Mater/slave模式，不過也能看出Master是有單點故障的；Spark支援ZooKeeper來實現 HA on yarn(叢集模式)： 執行在 yarn 資源管理器框架之上，由 yarn 負責資源管理，Spark 負責任務排程和計算 on mesos(叢集模式)： 執行在 mesos 資源管理器框架之上，由 mesos 負責資源管理，Spark 負責任務排程和計算

on cloud(叢集模式)：比如 AWS 的 EC2，使用這個模式能很方便的訪問 Amazon的 S3;Spark 支援多種分散式儲存系統：HDFS 和 S3

HDFS讀寫資料的過程  讀： 1、跟namenode通訊查詢元資料，找到檔案塊所在的datanode伺服器 2、挑選一臺datanode（就近原則，然後隨機）伺服器，請求建立socket流 3、datanode開始傳送資料（從磁盤裡面讀取資料放入流，以packet為單位來做校驗） 4、客戶端以packet為單位接收，現在本地快取，然後寫入目標檔案   寫： 1、根namenode通訊請求上傳檔案，namenode檢查目標檔案是否已存在，父目錄是否存在 2、namenode返回是否可以上傳 3、client請求第一個 block該傳輸到哪些datanode伺服器上 4、namenode返回3個datanode伺服器ABC 5、client請求3臺dn中的一臺A上傳資料（本質上是一個RPC呼叫，建立pipeline），A收到請求會繼續呼叫B，然後B呼叫C，將真個pipeline建立完成，逐級返回客戶端 6、client開始往A上傳第一個block（先從磁碟讀取資料放到一個本地記憶體快取），以packet為單位，A收到一個packet就會傳給B，B傳給C；A每傳一個packet會放入一個應答佇列等待應答

7、當一個block傳輸完成之後，client再次請求namenode上傳第二個block的伺服器。

RDD中reduceBykey與groupByKey哪個效能好，為什麼     reduceByKey：reduceByKey會在結果傳送至reducer之前會對每個mapper在本地進行merge，有點類似於在MapReduce中的combiner。這樣做的好處在於，在map端進行一次reduce之後，資料量會大幅度減小，從而減小傳輸，保證reduce端能夠更快的進行結果計算。     groupByKey：groupByKey會對每一個RDD中的value值進行聚合形成一個序列(Iterator)，此操作發生在reduce端，所以勢必會將所有的資料通過網路進行傳輸，造成不必要的浪費。同時如果資料量十分大，可能還會造成OutOfMemoryError。       通過以上對比可以發現在進行大量資料的reduce操作時候建議使用reduceByKey。不僅可以提高速度，還是可以防止使用groupByKey造成的記憶體溢位問題。   spark sql怎麼取資料的差集       好像不支援

spark2.0的瞭解     更簡單：ANSI SQL與更合理的API     速度更快：用Spark作為編譯器     更智慧：Structured Streaming

 rdd 怎麼分割槽寬依賴和窄依賴 寬依賴：父RDD的分割槽被子RDD的多個分割槽使用   例如 groupByKey、reduceByKey、sortByKey等操作會產生寬依賴，會產生shuffle 窄依賴：父RDD的每個分割槽都只被子RDD的一個分割槽使用  例如map、filter、union等操作會產生窄依賴

spark streaming 讀取kafka資料的兩種方式 這兩種方式分別是： Receiver-base 使用Kafka的高層次Consumer API來實現。receiver從Kafka中獲取的資料都儲存在Spark Executor的記憶體中，然後Spark Streaming啟動的job會去處理那些資料。然而，在預設的配置下，這種方式可能會因為底層的失敗而丟失資料。如果要啟用高可靠機制，讓資料零丟失，就必須啟用Spark Streaming的預寫日誌機制（Write Ahead Log，WAL）。該機制會同步地將接收到的Kafka資料寫入分散式檔案系統（比如HDFS）上的預寫日誌中。所以，即使底層節點出現了失敗，也可以使用預寫日誌中的資料進行恢復。 Direct Spark1.3中引入Direct方式，用來替代掉使用Receiver接收資料，這種方式會週期性地查詢Kafka，獲得每個topic+partition的最新的offset，從而定義每個batch的offset的範圍。當處理資料的job啟動時，就會使用Kafka的簡單consumer api來獲取Kafka指定offset範圍的資料。

kafka的資料存在記憶體還是磁碟 Kafka最核心的思想是使用磁碟，而不是使用記憶體，可能所有人都會認為，記憶體的速度一定比磁碟快，我也不例外。在看了Kafka的設計思想，查閱了相應資料再加上自己的測試後，發現磁碟的順序讀寫速度和記憶體持平。 而且Linux對於磁碟的讀寫優化也比較多，包括read-ahead和write-behind，磁碟快取等。如果在記憶體做這些操作的時候，一個是JAVA物件的記憶體開銷很大，另一個是隨著堆記憶體資料的增多，JAVA的GC時間會變得很長，使用磁碟操作有以下幾個好處： 磁碟快取由Linux系統維護，減少了程式設計師的不少工作。 磁碟順序讀寫速度超過記憶體隨機讀寫。 JVM的GC效率低，記憶體佔用大。使用磁碟可以避免這一問題。 系統冷啟動後，磁碟快取依然可用。

怎麼解決kafka的資料丟失 producer端： 巨集觀上看保證資料的可靠安全性，肯定是依據分割槽數做好資料備份，設立副本數。 broker端： topic設定多分割槽，分割槽自適應所在機器，為了讓各分割槽均勻分佈在所在的broker中，分割槽數要大於broker數。 分割槽是kafka進行並行讀寫的單位，是提升kafka速度的關鍵。 Consumer端 consumer端丟失訊息的情形比較簡單：如果在訊息處理完成前就提交了offset，那麼就有可能造成資料的丟失。由於Kafka consumer預設是自動提交位移的，所以在後臺提交位移前一定要保證訊息被正常處理了，因此不建議採用很重的處理邏輯，如果處理耗時很長，則建議把邏輯放到另一個執行緒中去做。為了避免資料丟失，現給出兩點建議： enable.auto.commit=false  關閉自動提交位移 在訊息被完整處理之後再手動提交位移 ---------------------