提到大數據，黃色小象(Hadoop)的名號已是婦孺皆知。但在巨量資料處理的實務中，Hadoop(和後起之秀Spark)只是批次運算的領頭羊，在天平另一端則是串流/即時運算(簡體稱為流運算)。Apache Storm便是名氣響亮的串流運算開源碼解決方案。
巨量資料技術最適合應用在各式的網路機制與服務。而最佳的資訊流架構規劃，應該是融合批次運算和串流運算。以這樣的使用情境為例「隨著網站使用者的瀏覽歷程，網頁自動呈現最多人感興趣的內容」。就是藉由巨量資料收集進行的批次運算結果，得出「最多人感興趣的內容」的數據洞見。配合即時(更專業上應該說「近乎即時」)收集的「使用者瀏覽數據」，動態改變「網站的呈現內容」，至此才實作出前述的系統機制。
或許有人會提出疑問，覺得同樣的數據流處理也可以用傳統的網頁程式技術來完成。差別在如果採用的是串流運算，它會針對Web主機裡的access log進行後端非同步的資料處理，實踐了營運和分析程式分離的資訊架構。一方面減少前端網頁程式的複雜度，提升程式碼的可讀性。另方面即使未來增加更多的數據分析功能，也不會因此影響到網頁回應的速度，造成整體網站的效能不彰。
從事數據分析的資訊人員，在談到串流數據處理時，肯定會聯想到Splunk(商用)和ELK(開源碼)這兩個知名的時間軸式(time-based)大數據分析平台。Storm很明顯地和它們不同，Apache Storm完全是個數據處理運算平台(platform)，或更嚴格地說是一個數據處理開發框架(framework)。而Splunk和ELK是著重在巨量數據的即時分析，一條龍地提供「收集」、「處理」、「視覺化呈現」的分析工具。
拉回來說，細看Storm組成的元件和它在處理數據流時採用的架構，資深的工程師馬上會聯想到典型的訊息佇列(message queue)服務。猜的沒錯，Storm核心元件中的Spout和Bolt，對應的正是精典的「生產者/消費者」模式中「消費者」的角色。在架構Storm的解決方案時，也少不掉要安裝提供可靠數據來源的訊息佇列服務(如AcitveMQ、Kafka)。你可能會問，若是如此，又何必花費心思導入Storm方案，只要自行撰寫符合生產者/消費者模式的數據處理程式，不就可以打造出即時的數據分析功能？但是Storm平台能做的不僅是一般常見的多執行緒(multi-thread)消費者元件，它通透地提供跨主機(multi-server)、跨處理程序(multi-process)的消費者元件，理論上可以讓數據流處理的總吞吐量接近無上限(還是會卡在系統瓶頸點)。而導入Apache Storm也連帶著引進了管理介面、標準化的開發框架，這都能增進即時巨量資料處理解決方案的可維護性及穩定性。
這本「Storm應用實踐」的內容令我大為讚賞，一開始從最基礎的串流資料處理觀念說起，接著是核心元件Spout和Bolt的介紹。它以貼近IT實務的模擬案例來引導讀者打造可運作的程式原型，從中做學地逐漸讓人熟悉著手Storm開發的最佳程式範型(pattern)。
Storm的Spout和Bolt元件，如同Hadoop著名的Map/Reduce般，在極簡的類別設計下，展現出無窮潛能的實作空間。書中後半針對效能調校、程式除錯等進階議題詳加說明，還有比官網文件更深入淺出的Storm內部運作細節解說，當之無愧地可以說是「Apache Storm自學聖經」。終章作者介紹了Trident這個建基在Strom上的抽象框架，它提供了類似Spark Streaming一樣的「微批次/小批次」資料處理功能。老實說，Trident的複雜度足以獨自出版成冊，作者也言明只想粗淺介紹這個抽象框架，讓讀者有個印象，一般在開發Storm應用時不見得需要用到Trident。
「批次處理」和「串流處理」像是大數據工程師工具箱裡的十字和一字起子，兩者適用的情境和條件限制截然不同。透過妥善的規劃將兩者相互整合，會展現出一加一大於二的驚人成果。因此從事大數據工程的資訊人員，千萬要把握學習Apache Storm的機會，更別錯過「Storm應用實踐」這本值得典藏的傑作(還是有幾個勘誤處，細讀才會發現)。
沒有留言:
張貼留言