2026年6月5日 星期五
大數據 Hadoop 3.X 分佈式處理實戰
2025年9月4日 星期四
Next.js實戰
2022年5月13日 星期五
Jenkins 2.x實踐指南
在開源軟體的解決方案中講到「持續整合/持續佈署(CI/CD)」,十之八九會提到Jenkins這項工具。即便我已經利用Ansible把程式佈署的流程自動化,但是相較於Jenkins,Ansible還是缺少網頁管理介面、帳號與權限管理、操作記綠檔等功能。因此進一步導入Jenkins來整合Ansible的自動化腳本,就是完善我自動化佈署的終極方案。
Jenkins早在2011年就問世,網路上的參考資料多不勝數。熟練地運用適當的關鍵字,谷哥大神確實能告訴你一些答案。不過我個人以為,想要有系統、依循脈絡地學習一項新知,一本好書絕對是性價比最高的投資。而「Jenkins 2.x實踐指南」是值得我掛保證,它能讓讀者從零開始學會Jenkins 2,進而運用自如。尤其全書中著眼在介紹2.x版本的「pipeline as code」,Jenkins中的流程用程式碼的形式來撰寫和分享,受惠於此理念,流程將可以被版本庫儲存與管理!完全克服了1.x版本時最為人詬病的流程設定「黑箱化」問題。
就Java語言而言,軟體開發過程是一連串的「手工」操作。寫好程式碼後,先將原始碼編譯成位元組檔,再打包為可執行檔,然後上傳到主機的特定目錄,以終端機指令啟動該程式。著重軟體品質的專案,則會在編譯後加上測試作業。如果是網頁專案,還得多一項重啟網頁伺服器的作業。當然Java技術棧早就發明Ant、Maven和Gradle等自動化建置(Build)工具,來處理這些惱人的例行工作。說穿了Jenkins工具,只是把你手上既有的版本庫(如Gitlab)、測試腳本(如JUnit)、建置工具(如Maven)或佈署腳本(如sh)用pipeline程式碼整合起來。所以對尚未使用軟體版控、尚未對建置/佈署步驟自動化的開發團隊來說,Jenkins絕對不是仙女的魔法棒,可以讓你輕鬆略過應有的基本功。
對於「一條龍」(從頭到尾都一人負責)的開發團隊來說,並沒有急迫得導入CI/CD工具的誘因。非多人同步開發的專案,只要程式有單元/功能測試,根本用不上持續整合(CI)。程式編譯到佈署的「手工藝」,只要夠細心謹慎,用不用持續佈署(CD)差異也不會太大。不過從中長期來看,所有軟體專案都應該完成CI/CD的設定。達成CI,可以讓小型專案在擴展成大型專案的過程中,維持軟體品質和降低溝通成本。而做到CD,則得利於佈署作業標準化,可輕易地讓專案系統平行擴充。
2021年12月25日 星期六
實戰Gradle
和微軟(.Net)程式人員習慣的「一條龍」式解決方案不同,Java程式人員在挑選開發工具時的常是各吹各的調,誰叫開源碼(OpenSource)的小天地中多的是免費又功能強大的「整合開發環境」(Integrated Development Environment)。說句玩笑話,想要組織一群Java工程師來開發專案,第一件事是得敲定大家應該用哪個開發工具。開發工具的挑選,如果再加上「自動化建置工具」(build automation tool)來攪局,開發團隊肯定難有共識。而Gradle便是新一代的自動化建置工具,時常出現在Android手機程式和Java技術書籍的範例程式。
如下圖所示,在打造軟體專案的過程中,整合開發環境和自動化建置工具都可以用來執行同樣的步驟(例如:編譯程式),兩種工具能相互取代。
「我現在用IDE寫程式好好地,為何要改用Maven來做IDE能辨到的步驟?」便是我在學Maven(另一套知名的自動化建置工具)時心中的困惑。在研讀「實戰Gradle」之後,對此問題的答案逐漸清晰,採用自動化建置工具最主要的目的就是實踐「持續整合/持續佈署(Continuous Integration/Continuous Deployment)」。像Maven、Gradle的自動化建置工具,能直接用命令(Command)模式執行,如此一來才能輕易地與Jenkins這類CI/CD工具整合,讓軟體開發的各步驟都能規劃出標準作業程序(SOP)並隨之自動化,減少因人為疏失造成的錯誤。
身為Java程式開發人員,有時心中不免嘀咕,每隔幾年總有新工具和新框架橫空出世,對相同的問題提出不同的解法,學起來真的折騰人。像是自動化建置,從最早的Ant、中期的Maven到本書提到的Gradle就有三種。工具的設計思維從完全靠自己(Ant),進化為約定優先於設定(Maven),最後變成約定與開放兼容(Gradle)。Gradle勝過Maven的地方在於兩者雖然都是採用預先定義好的規則並透過各種插件(Plugin)來滿足各式建置需求,但開發者可以在Gradle中使用Groovy語言來程式化建置邏輯,能完成諸如if(條件判斷)、for(迴圈)等高度複雜的建置情境。「豐儉由人」是Gradle踏在Maven肩膀上悟出的心得,也會是開發者投入Gradle懷抱的最大原因。
「實戰Gradle」是一本讓讀者獲得Gradle入門到進階功力的速成寶典,透過一個相當真實的範例專案,帶領我們一步步完成各種自動化項目。作者不單單介紹程式專案的編譯、打包和佈署等必要步驟,在自動化的議題上更引導我們走向測試導向開發(Test-Driven Development)、持續整合/持續佈署(CI/CD)等成熟的軟體工程應用方案。本書以Gradle工具做核心,向外提到的延伸工具相當多(例如:JUnit、Jenkins、Ansible等),讀者想要透曉所有工具軟體細節會有一定門檻,必須視自己情況選擇性閱讀。最後不得不警告,「理想很美好,現實很骨感」雖然上述的分享把此書說成像本軟體工程知識的Gradle速成寶典,但事實上這書提到的工具軟體版本都已經過時,在閱讀時要不斷地自行考證和更新程式碼的內容,簡直像幫出版社進行新版本的校訂工作,值不值得就看你是否願意花時間練功了。
2021年12月5日 星期日
大數據架構商業之路:從業務需求到技術方案
自從看過黃申的「大數據架構和算法實現之路:電商系統的技術實戰」一書後,就對他在大數據領域的研究和心得有所共鳴。這本「大數據架構商業之路:從業務需求到技術方案」是「大數據架構和算法實現之路」的前作,在內容的規畫上著重理論層面的介紹和解說,兩書互為表裏,做為大數據從業人員當然不能掛萬漏一。全書有12章,除了第1章引言外,2到7章將大數據應用的不同題目,各自整理成專章,分為「數據收集」、「數據儲存」、「數據處理」、「信息檢索」、「數據挖掘」、「效能評估」。
數據收集中有「網路資料收集」也就是常說的「網路爬蟲」。抓取網路資料的演算法有「深度優先」、「廣度優先」和「最佳優先」三種,其中又以「最佳優先」效果最好。在開源碼中有「Apache Nutch」和「Heritrix」可以實踐網路爬蟲。另一種數據收集則是「企業內部資料收集」,簡單說就是內部轉檔程式(從各種不同的資料來源),開源碼中有「Apache Flume」可用。
數據儲存分成「持久化儲存」和「非持久化儲存」兩類。在持久化儲存部份,「Hadoop(HDFS)」是業界公認的唯一選項,普及程度已到言大數據者不可不用HDFS,另外建基在HDFS上的noSQL解決方案「HBase」也常被企業採用。近來在noSQL應用中異軍突出的「MongoDB」,則是自成一格用來儲存非結構化資料的文件資料庫。非持久化儲存的主要訴求是超高的反應速度,因此主流產品都是用記憶體做為儲存機制。開源產品有「Memcached」和功能更強大的「Redis」。
數據處理依照處理的頻率分為「離線批次」、「近乎即時」和「在線即時」三種。Hadoop(MapReduce)是離線批次處理中的業界公理,被視為大數據技術的原點。針對MapReduce的缺點再進化而成的「Spark(RDD)」,則是近來有望取而代之的平台。另外也有將MapReduce程式碼封裝成SQL like語法的「Apache Hive」,和基於相同簡化概念而產生的「Pig」、「Impala」和「Spark SQL」等平台和套件,這些產品都是提供一個做法讓非程式人員更方便地操作大數據資料。近乎即時的機制是仰賴訊息佇列,開源碼中的「ActiveMQ」和「Apache Kafka」較為知名。在線即時處理和離線批次處理是站在天秤上兩側的對立面,在應用面上能互補,免除實踐時在運算時效和資料規模非得取捨的兩難。開源碼有全即時的「Storm」和批量即時的「Spark Streaming」。
黃申在信息檢索章節花費相當大篇幅介紹,畢竟此階段已經可以看到具體的大數據運用成果,相信讀者有意願深入瞭解。有別於對資料庫查詢結構化資料,大數據資料檢索的長處是查詢非結構化資料。檢索和比對非結構化資料的核心問題有「相關性」和「即時性」。在相關性的判定上,目前已經發展出許多模型,包含了「布林模型」、「基於排序的布林模型(增強型布林模型:TF/IDF)」、「向量空間模型」和「語言模型(機器學習:Naive Bayes)」。處理即時性需求,最基本會用到「倒排索引」技術。信息檢索的需求在IT業界最具體的例子就是「搜尋引擎」,依應用目的可以分成「通用型搜尋引擎」和電子商務中的「商品搜尋引擎」。像Google般的通用型搜尋引擎,重點會放在網路爬蟲技術,書中就介紹了Google的PageRank演算法和由權威值與中心值構成的HITS演算法。電商的商品搜尋機制,考量的重點是「排序演算法」,其中排序的「金字塔模型」包含了「文本模型」、「反作弊模型」、「商家服務模型」、「商業規則」、「人氣模型」、「分類模型」、「輪播模型」、「個性化模型」。搜擎引擎最有名的開源碼套件為「Lucene」,從中發展出各佔半邊天的「Solr」和「Elasticsearch」。
推薦系統是大數據在電商應用中的第二個亮點,因為它能顯著地增加商品被瀏覽、被銷售的機會。好的推薦系統能幫公司出售多樣化的商品,增加用戶的滿意度和忠誠度。推薦系統可以依「基於商品」、「基於用戶」和「基於情景」分類。推薦演算法的核心是相似度,在概念上和搜尋系統的相關性一樣,只是應用領域和實作細節有所不同。相似度的定義方法可以有四種類型,「基於內容」、「基於知識」、「基於用戶行為」和「基於社交和社群」等。在混合不同推薦算法時,則可以用「微觀混合」或「宏觀混合」。
線上廣告系統是大數據在電商環境的另一種常見應用,系統中的角色有「廣告投放主」、「廣告」、「用戶」和「廣告平台」,過去常見橫幅廣告播放,現在都是精準投放。收費的模式有「CPM(Cost per Mille千次)」、「CPT(Cost per Time)」、「CPC(Cost per Click)」和「CPS(Cost per Sale)」與其它。廣告關鍵字的拍賣競標是廣告系統不同於搜尋、推薦系統的地方,也是最具技術門檻的機制。
數據挖掘又稱數據探勘或是機器學習,常見的任務有「頻繁模式」和「關聯性分析」,用於預測的「分類」和「迴歸」,非預測性的「聚類(分群)」,最後還有「異常點分析」。在開源碼中有「Apache Mahout」套件,「R」語言也是另一種常見的工具。
大數據的效能評估,依評估手法可分為「離線評估」、「用戶訪談」和「線上評估」。離線評估中針對信息檢索系統的最基本評測指標是「精度(Precision)」和「召回率(Recall)」,機器學習的評測有針對分類問題的「混淆矩陣」。對分群問題來說並沒有方便量測的驗證工具,此時可以「外部準則法」,藉由將額外提供的資料標籤和分群後的結果逐一比對,求出分群效果的「精確度(Accuracy)」和「F值」。線上評估就是「A/B測試」,也是電商營運上最有效的測試手法。應用系統的性能評估有「性能測試(驗證系統合乎預期目標)」、「負載測試(找出系統的安全臨界負載)、「壓力測試(找出系統崩潰的壓力點)」和「穩定性測試(在適當的壓力下系統長時間運作)」。開源碼的「JMeter」工具可以滿足上述所有的性能評估需要。
最後的9到12章,黃申快速地介紹搜尋系統、推薦系統、資料收集、數據探勘的實作案例。而更清楚的說明與完整的程式碼,是放在「大數據架構和算法實現之路:電商系統的技術實戰」一書中。黃申在本書中點出大數據技術在電子商務的運用主題,涵蓋「搜尋引擎」、「推薦系統」、「數據探勘」和「線上廣告系統」,這和我在大數據開發歷程中體悟到的心得不謀而合。推薦引擎就如同不須使用者自行輸入關鍵字的商品搜尋引擎,當看到黃申寫的這句話時,不由得拍案叫絕,他居然和我對推薦系統的看法一致。
2021年6月4日 星期五
PHP網站開發:CodeIgniter敏捷開發框架
除了第一份工作是用ASP語言寫網頁程式以外,之後在職涯中逐漸走向後端/大數據領域。所以即便在電子商務公司工作,自己也是少數不懂PHP程式語言的工程師。但2021年,什麼事都可能發生,由於同事調任要職務交接,得接手他的PHP+CI程式。剛好趁著看不到盡頭的WFH,來瞭解一下PHP和CodeIgniter框架。
市面上中文的CI專書很少,買得到的大概也只有這本「PHP網站開發」,話雖如此,但這書的內容真的不差。從網頁開發最基礎的HTML教起,接著是JavaScript和SQL,篇幅是點到為止,但按步就班的學習下來也能獲得必要的相關知識。後面的重頭戲包括PHP語法、函式與資料庫操作,當然對已經熟悉其它程式語言的讀者來說,這些觀念很容易理解,差別是語法的熟練度。如果是初學者,書中節章的安排和練習用的範例,是恰到好處,不疾不徐地讀者逐漸習慣PHP。
第四章的CI框架介紹,是本書的精華,也確實讓人覺得物有所值。第一眼看到同事交接來的PHP+CI程式碼,真的是霧裡看花,弄不清Request的URL是被轉到專案中的那支PHP程式。畢竟MVC(Model-View-Controller)雖然是跨語言/平台的網站設計架構,但不同的框架(Framework)實踐的方法卻是截然不同。這本「PHP網站開發」確實把CI架構說明得一清二楚,讓我讀完後就具備看懂PHP+CI程式的技能。
當然本書只介紹最基本的CI觀念,未來遇到進階的技術問題,還是得去看CI官網文件。如果說「PHP網站開發」有什麼缺點,大概是範例程式裡的MVC切分做法有點奇怪。作者讓Model直接讀取網頁的input,而不是用函式參數傳遞的方法讓Controller把input傳給Model,這不是標準的MVC呀。
2021年2月27日 星期六
大數據架構和算法實現之路:電商系統的技術實戰
工作上是管理大數據平台和建置其上的個人化推薦系統,目前在系統設計、開發和維運算是得心應手。不過資訊技術進展一日千里,為此我總會買些大數據、推薦系統的專書來溫故知新。翻閱過數本推薦系統的好書後,和本書作者黃申在序中出提的想法一樣,這些專論推薦系統的書目分別處於理論和技術的兩個極端。不是純粹介紹理論、演算法、數學公式和學術進程,像是一本大學院校的教科書,另一種是過於微觀地介紹單一技術工具、框架,從安裝設定到開發、操作步驟,像是常見的Hadoop實戰、Spark入門等。
「大數據架構和算法實現之路」的作者以全然不同的角度切入「推薦系統」這主題,用電商營運中的大數據資訊處理需求當主軸貫穿全書,在各子章節中詳述設計思維、系統架構,並提供可實際運作的完整程式碼,讓讀者「知其然,又知其所以然」。隨著章節進行,範例程式逐步演進變成強大的運算模組,完成度極高的程式碼,徹底揭開大數據技術如何落地實作的神秘面紗。
這一兩年有關心IT產業動向的人,應該能感受到先前刮起的機器學習/人工智慧風潮開始消褪。我認為原因有二,一是資本市場和資訊同業的大舉投入,讓AI技術以十倍速成長而達到高原期,相關工具、框架汗牛充棟、舉手可得。同時AWS、GCP等IT領頭羊也極積推廣AI雲端服務,這些因素造成AI技術平價化,喪失成為公司營運上做為技術壁壘的優勢。其次,在僅扮演AI供應商的角色,無法獲取高利潤的情況下(AI普及化的負作用),目前又缺乏能將AI技術在市場中變現的商業模式。不論是強調未來能降低人力成本,或是主打可以提升既有服務的精準度,都無法直接對業績帶來顯著的高成長,因此從投資者/市場的觀點來看,AI技術是言過其實。
相對地,雖然大數據早先AI已步入高原期,已是十分普及的資訊技術。但它具體回應電商在不同層面所遭遇的問題,改善它們在營運管理中的痛點。推出推薦系統、精準行銷和網站追蹤等資訊服務,今日也都成為各大電商平台的系統標準配備。AI和大數據在商業價值上反映的此消彼長,如同波紋般擴散到資訊書市。開始有專書在講述如何運用機器學習/深度學習打造出電商的推薦引擎。在在證明,雖然商品推薦系統不如人臉/聲音辨識那般具有話題性,卻是電商運用資訊科技促進業務成長的最佳實踐做法。
「大數據架構和算法實現之路:電商系統的技術實戰」一書分成四部份,包含大數據、搜尋引擎、機器學習和網站行為追蹤。而前三項技術恰好吻合我在打造電商推薦系統過程中,獨自摸索、拼湊找到的核心組件。我認為一個完善的推薦引擎,必然是倚靠在大數據、搜尋引擎和機器學習這三根基柱上。雖然和書中節章順序略有不同,但看到自己一路來的領略心法,是從他人之筆成為篇篇書頁,不免讓我拍案叫絕,對黃申有千里遇知音的感觸。
書中先介紹機器學習在電商的應用,從分類、分群再到迴歸分析。全書先以故事中角色的互動帶出技術需求,再說明理論、架構,展示完整的程式碼,後續各章的綱要都是如此。雖然本章用的是較早期的Apache Mahout開源框架,但只要舉一反三,讀者可以自行改用其它開源框架(例如Apache Spark)。迴歸分析的部份,點出了機器學習如何用來進行商品銷售預測。能正確預測未來的銷售數字是個大問哉,實務上不會像書中描述地這麼簡單,但畢竟它還是成功破題,讓有志於此課題的讀者,能對技術實踐有個粗略的印象,用來踏出第一步。
全書花了近半的篇幅講解搜尋引擎的核心和應用,包括最基本的逆排索引觀念到進階的分散式搜尋架構,同時一併介紹了各據半邊天的開源Solr和ElasticSearch。當然後續重心是放在如何整合大數據分析和機器學習算法,用來優化搜尋結果頁的排序,最終達成個人化搜尋。光是這些內容,「大數據架構和算法實現之路」就能充當為一本搜尋技術專書,可見黃申在搜尋領域的專精與經驗。
在錙銖必較網頁回應效率的電子商務,推薦系統一方面要滿足特定演算法的需求,另外也得遵守整體網站訂定的系統回應速度。為此絕大多數的推薦系統都會導入搜尋引擎做為核心模組。武斷地說,想打造大數據導向的個人化推薦系統,必須具備可以靈活使用搜尋引擎的技術力。換個角度看,推薦系統就像是個不需要消費者主動輸入關鍵字的商品搜尋引擎,可見得兩者有多相似,關係有多密切。
在推薦系統的章節,意料之中地提到了耳熟能詳的協同過瀘法,這個算法已經是每書必提、婦孺皆知。令人驚豔的是,黃申居然使用搜尋引擎來實作此算法,而不是採用開源的機器學習框架。他活用了TF/IDF和逆排索引的特性,以開創的做法,簡單、迅速地完成了基於物和基於人的協同推薦服務。黃申描述的個人化商品推薦,和我這些年摸索打造的推薦引擎不謀而合,是藉由大數據的運算能力,混合群眾和會員個人的商品偏好,即時呈現給消費者最感興趣的商品。
電商經營不可或缺的數據追蹤,本書當然沒有遺漏。它先比較第三方方案(例如GA)和自行打造平台的優缺點,再具體而微地展示利用大數據技術該怎麼打造出客製的網站行為追蹤系統。裡面採用的Apache Storm也是我目前採用的開源框架,再一次讓我直呼好巧。
在建置推薦系統時累積的許多想法和技術巧門,曾經動心起念要書寫成冊。畢竟推薦系統這個主題涵蓋大數據、搜尋引擎和機器學習三個當下十分火紅的資訊領域,而且還能跨足數位行銷的範疇,也是行銷資料科學中一個重要的應用。在實務操作中,除了滿足算法需求,得克服效能瓶頸,更要關注消費心理學,與公司商業策略相互呼應。
「大數據架構和算法實現之路:電商系統的技術實戰」的內文,很多和我個人的體悟如出一轍,其中還有不少目前我還未嘗試過的設計。有幸翻閱本書,一來感嘆資訊科技萬變不離其宗,自身的領悟與心法非舉世所罕見,已有行家立著成冊,不勞我費心落筆分享。二來慶幸,自己一路走來琢磨、堆積而成的推薦系統,在設計思維和整體架構上,和對岸名人大腕的做法相比也毫不遜色。可以說是「德不孤,必有鄰」嗎?
2020年11月12日 星期四
Maven實戰
從事資訊系統開發的人,如果不是天生神力有著「一目十行,過目不忘」的本領,或多或少都會有如何達到「溫故知新」的困擾。畢竟資訊技術一日千里,永遠有學不完的新東西,但手頭上合用的工具與技術還是要維護,常常會有蠟燭兩頭燒的焦慮感。
相信今日從事Java程式開發的工程師們,肯定對Apache Maven這套開源工具不陌生。它將軟體開發生命週期的想法融入到專案管理及自動編譯工具中,讓不同的軟體專案能依循相同的目錄結構與建置階段。它有如Java開發社群的巴比倫塔,在跨團隊合作的專案中,減輕了因各自的專案開發風格(路徑規劃、編譯步驟)所造成的文化障礙。
Maven對Java社群更大的改變在於,它拯救了無數受困於JAR參考地獄的程式開發人員。透過POM設定檔中的依賴管理功能,宣告式地指名專案需要引用的JAR,Maven就自動幫你完成下載、相依性引用等讓人操煩的技術性細節。平心而論,採用Maven做為開發輔助工具,大大地提升了Java工程師的產能。
而這本「Maven實戰」便是具體而微地說明如何使用Apache Maven在實務的工作場景。它用一個前後呼應的Web應用程式專案做為範例,不疾不徐地說明了Maven中的方方面面。雖然在專案自動化建構工具的領域上已經又出現了Gradle這個後起之秀,但不可避免地仍然有許多專案是採用Maven,對於想要掌握Apache Maven工具的朋友們,「Maven實戰」絕對是值得收藏的好書。
2020年9月13日 星期日
Storm應用實踐:實時事務處理之策略
提到大數據,黃色小象(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應用實踐」這本值得典藏的傑作(還是有幾個勘誤處,細讀才會發現)。
2020年8月20日 星期四
Splunk大數據分析
有別於Hadoop和Spark嘗試在大數據批次處理找出最佳實作範型,Splunk專注在替即時大數據/流式大數據的應用情境提供解法。它既不像Spark streaming以短批次模擬即時,又和Apache Storm只負責數據的「處理」截然不同。Splunk是真正在流式大數據上,同時做到「收集、儲存、處理、呈現」這四個數據分析上的核心功能。簡單說,一但使用了Splunk平台,公司馬上就擁有完整、強大的即時數據分析解決方案。在開源碼的世界,可以和Splunk比肩的是由Elasticsearch、Logstash和Kibana組成的ELK平台。兩相比較,Splunk因為是用單一軟體做到收集、索引、查詢、視覺化等所有功能,因此在建置、維運以及使用上都比ELK簡易流暢。然而不論是Splunk或ELK,在大數據分析中都只是做為完善批次分析平台的不足,即時分析平台是無法取代像Hadoop和Spark這種通用平台,用於執行客製、複雜的大數據運算。
「Splunk大數據分析」是本資訊量很高的電腦書,即便在說明概念/術語的初章,就不廢話地介紹即時數據分析的獨特價值。接著一章章地講解數據導入、SPL分析語法、數據視覺化。各章內容採用實際範例來讓讀者練習,在看完功能簡述的文字後,緊接著具體的指令操作和執行結果截圖,大大地提升吸收、理解的效率。書中提及的Splunk指令集相當扎實,進階功能的應用常常就躲在隻字片語裡。最後兩章,更納入分散式佈署、效能調校等系統架構規劃的議題,全書比Splunk原廠的基礎課程更為豐富深入,可說是one for all。
美中不足的是,這本是上市已久的舊書,介紹的軟體版本/功能已經有點過時,因此少部份功能截圖與新版本對不上。另外書中舉的練習範例較貼近美國社會(此為簡體翻譯書),不論是航班資訊或是Twitter社群,都不是台灣人所熟悉的情境。如果將內文簡化,範例更濃縮,集中在Splunk指令集的介紹與功能呈現,有成為非官方教材的潛力。
2020年5月31日 星期日
深入理解JVM & G1 GC
2019年7月16日 星期二
羅輯思維:有種·有趣·有料
「羅輯思維」一書,是對岸知識網紅的代表性人物「羅振宇」, 匯集其影片內容編印成冊,算是相當有趣的影音內容文字化的嘗試。
我本人是不常接觸對岸的影視娛樂作品,第一次聽到「邏輯思維」這節目,是在茶水間和前同事閒聊時他推薦給我的,之後也未曾特別去點閱過。隨著此節目名聲漸大,台灣出版社出了本「羅輯思維:我懂你的知識焦慮」的繁體書,我才首次體會此人、此節目所提供的知識內容確實是引人入勝,有種特別的魔力。
隔些日子,在市面上又看到有簡體字的相關書藉上架,想說之前的閱讀體驗挺好的,就追加買了三本系列作品,「羅輯思維:有種·有趣·有料」就是其中的一本。
這本書的編排方式有別於傳統書籍,「羅輯思維」除了中間版位留給正文外,側邊還印了一些網友對於影片的評論文字。在立場上正反都有,有特意想營造一種知識份子能容納百川之言的風格。但就閱讀體驗上卻是讓人不知從何讀起,加上正反論點交織的文字,更打亂了正文想傳達的核心觀點。像是把網路平台的操作強加在紙本載具中,簡單說就是畫蛇添足。
每個主題都採用三段論的章節呈現,應該是配合影片播出時穿插廣告(中場休息)的結構。內容以兩、三個歷史典故,以古論今談天說地,讓讀者有增廣見聞的新鮮感。但就像經濟學所說的「邊際效應遞減」,當讀者把整本書從頭到尾一口氣看完時,應該會開始感受到一點老套、又來了的不適。畢竟講者的論述形式都是先提一個罕為人知的歷史故事,加上一些主觀因果論述,再帶入命題想講的現今問題中,最後導出極為正向而激勵人心的結論。
這樣的內容可以說是知識網紅版的心靈雞湯,看完的時候好像懂了一些東西。但過了一陣子可能全部還是忘掉了,畢竟讀者們只是單純的接收資訊,這些資訊並沒有內化成自己腦袋中的東西。把它當成閒暇無聊時的娛樂讀本,好過認為讀完後會有智識上的成長。
2019年1月31日 星期四
推薦系統
2018年10月11日 星期四
Redis 4.x Cookbook中文版
大約在2010年左右,「noSQL」風潮幾乎席捲網站開發者圈,言者必稱傳統資料庫已不能支持大型網站,紛紛投向各種noSQL的懷抱。當然我也不能免俗地在那個時間點學起noSQL的觀念,「CAP理論」和「Apache Cassandra」確實開擴了我的視野。2012年開始導入後,許久未能升級的Casssandra,在使用了六個年頭後也漸漸露出疲態。恰好同事K這兩年在公司導入了「Redis」做為快取服務,已經在公司穩定運作中。在考量到學習曲線、維護成本以及服務適用性後,打算用Redis取代Cassandra做為推薦系統的快取機制。
這本「Redis 4.x Cookbook中文版」就是介紹Redis的專書,目的當然是讓我快點學會Redis再把快取功能移植過去。書的內容也不說廢話,沒有介紹任何noSQL的基礎觀念,應該是認定讀者會買這本Cookbook,想必已經知道noSQL是什麼和優點在那裡。前面的節章介紹如何安裝以及Redis支持的資料結構(它是屬於儲存體服務的一種),緊接著就是示範客戶端如何撰寫程式來使用Redis。中半部說明了進階的服務設定,包括了「資料複製」、「資料持久化」、「叢集架構」等等。可以發現Redis 4.x是非常成熟的noSQL產品,加上其Memory-Based的效能優勢,已經可以預期「Memcahced」將被邊緣化。
後面的節章專注於目前維運的管理技巧和參數調校,這些資訊對於剛導入Redis服務的讀者來說有點霧裡看花。因為大部份異常處理和效能不佳的改善,都是在長期維護後才遇到問題並試著改善。不過這也說明了這本書的準備周詳,連未來所需的資訊都編列給你了。至於「故障診斷」和「Redis模組開發」就完全是進階讀者才看的懂的內容了。對於作業系統底層參數和C語言開發有基礎的人,才會體會到這兩篇的價值,作者的技術廣度實在令人欽佩。
對於曾經使用過其它noSQL產品的開發者來說,讀完這本「Redis 4.x Cookbook中文版」,應該就能在短期間內學會並使用Redis。同事K說書中的內容在Redis官網上也有,對於這點我還是偏好紙本書的觸感和細細翻閱的節奏呀~(一直在螢幕看文件,眼睛受不了)。推薦給目前有用Memcached又有心想跟上時代的網站開發者。











