載自品友互動：http://www.ipinyou.com.cn/technicalnews/201112/Technical_6.html
ETL(Extraction, Transformation, and Load)是基於日誌數據挖掘中的重要環節。現在Hadoop用於日誌ETL的工具主要有Facebook的Scribe，Apache的Chukwa和Cloudera的Flume等等。
從容錯性、負載均衡和可擴展性上考慮，我們最後選擇了Flume作爲我們的日誌ETL工具。Flume是Cloudera提供的非常優秀的日誌ETL工具。它支持在日誌系統中定製各類數據發送方來收集數據。同時，Flume提供對數據進行簡單處理，並寫到各種數據接受方(可定製)的能力。
Flume包含3個部分，Master、Collector和Agent。Master是管理節點，Agent用於採集數據，Agent是Flume中產生數據流的地方。同時，Agent會將產生的數據流傳輸到Collector。Collector用於對數據進行聚合，往往會產生一個更大的流，然後傳輸到存儲服務器。
Flume的優化也一般在Master、Agent和Collector上進行。
1.Master的優化
Master存儲的內容較少，存儲着數據傳輸路徑上的發送者和接受者信息。所以性能一般不會成爲瓶頸，主要是安全性方面的優化。Master是Flume的管理節點，一旦Master宕了，整個Flume也就無法運轉了。我們可以在兩臺服務器上分別搭建Master，Master之間進行同步，從而避免單點故障的問題。
2.Agent的優化
Agent的優化主要分爲兩個方面，內存和CPU。
我們在使用Agent的服務器上發現其使用的系統資源很高。Agent的內存使用率基本佔總內存的15%。CPU使用了237.6%。但是我們每個Agent上生成日誌的頻率並沒有那麼大，而且日誌文件的大小也不是很大。是什麼原因導致了Agent佔用如此高的系統資源？
通過檢查Agent進程的資源使用，發現Agent進程的MaxHeapSize 爲8G，而將Java Heap的Young Generation、Old Generation 和Perm Generation 3部分相加才240.5M。這種現象很奇怪，很多的內存不知道用在什麼地方了。我們試着降低MaxHeapSize的大小，設置爲512M，重啓Agent發現報出“java.lang.OutOfMemoryError: Direct buffer memory ”的異常。很奇怪，按照剛纔的計算，Java Heap的使用才240.5M，現在512M的Heap Size應該足夠了。查閱Flume的源碼，發現Flume使用了Java NIO 用於數據的傳輸，傳輸時用的是Direct Buffer，Direct buffer是ByteBuffer的一種模式，它通常創建在進程的Native Heap而非Java Heap上。報異常的真正原因是Native Heap上的Direct Memory不夠了。所以我們通過MaxDirectMemorySize參數調整Direct Memory爲1G，但是啓動後還是會報出OOM的異常。經過一些研究發現很可能是由於JVM的GC機制引起的。JVM的GC機制主要針對於Java Heap，而不是Native Heap，由於Agent使用的Java Heap並不高（上面也得到驗證），GC的頻率很低，導致Native Heap上的資源難以釋放，越積越多。所以我只能加大了MaxDirectMemorySize的大小，重啓Agent後，經過驗證，Agent運行正常。優化後，Agent的內存使用率降低到7.2%，降低了53%的內存使用。
雖然我們不能直接控制Native Heap 的GC，但是我們可以通過調整Java Heap的參數來加大GC的頻率，這樣間接的控制Native Heap的GC。但是由於Java Heap 和Native Heap相互影響，過多的GC會增大CPU的使用率，所以我們需要找到一個平衡點，如果能找到， Flume Agent的資源使用能夠更低。
注意，對於我們品友現在日誌產生的量和頻率，如上參數是可以的。但是對於其他環境，內存需要根據數據的實際情況來進行優化。
在CPU方面，我們主要修改了Flume的源碼，主要是TailDirSource類。
具體做法是減少了Agent探測是否有新日誌內容產生的頻率，默認是100毫秒，我們對此進行了調整。當然，這種優化的手段還是要和實際的業務和數據情況結合在一起。例如，如果業務對實時性要求很低的話，我們可以把這個時間間隔設置得更長一些。
通過優化，CPU的使用率從237.6%降到了77.7%。
3.Collector的優化
在Flume中，Collecor也是一個性能的瓶頸。如果從Agent發送過來要處理的event的數量不斷增加，那麼將會給Collector帶來很大的處理壓力，從而影響整個系統性能。
在這個問題上，我們可以配置多個Collector進行分流。然後我們可以通過某種規則，例如手動設置，將不同的Agent產生的event發送給相應的Collector，這樣就將壓力分攤給了多個Collector節點。