2020年7月30日 星期四

大數據Hive離線計算開發實戰



ISBN:9787115448088

資深的資訊工程師常有一種特別的煩惱,如何在眾多實作技術中,挑選出最恰當的工具來執行軟體專案。從中牽扯的包括組織資源、同儕能力、工具成熟度、操作便易性,這項任務恰好沒有一體適用的標準答案,如同撰寫程式時「變數命名」般,十足仰賴負責人的主觀決擇。

大數據專案開發也會遇到一樣的問題,在今日開源軟體、雲端平台遍地開花的時代,要收集、分析與運用企業本身的巨量資料,可以從最精典的Map/Reduce框架到高效版本的Spark平台。不論企業最後挑選的大數據解決方案為何,勢必需要熟悉該平台的工程師運籌帷幄。

由於大數據開發有別於傳統的關聯式資料庫,因此對於工程團隊來說,大數據技術變成一個得跨越過去的門檻。而Apache Hive正是主張能一勞永逸解決這個技術「痛點」的開源工具。它無縫地運行在Hadoop平台之上,充分利用HDFS的分散式檔案系統以及Yarn平行處理框架,並在自身的對外介面套上一層相容SQL(HQL)的外衣,讓各項軟體工具、運用程式甚至是開發人員,都能用熟練的SQL語法,遨遊於巨量資料的國度中。

對我而言,由於已經熟練Map/Reduce與Spark等技術,可以隨心所欲地撰寫出大數據程式碼。其實沒必要疊床架屋的再添一層虛擬資料庫,用SQL語法來執行巨量運算。但考量到企業整體運用情境,想擴增大數據的應用面以及簡化同儕的數據使用門檻,就值得投入心力建置一個獨立運作的Hive環境。

市面上Hive的專書不多,而且絕大多數是四、五年前所出版。在決定再次架設Hive服務的當下,理所當然地挑選2020年出版的「大數據Hive離線計算開發實戰」。內文從最基礎的概念說起,再由簡入深地提及到分區、自定義函式等進階的功能,作者將Hive定位為能處理大數據的資料倉儲解決方案,全書也呼應這個想法具體地呈現如何實踐。閱後不免心有所思,在這麼強大便利的開源方案的競爭下,未來商用資料倉儲廠商肯定不好擴展市場。

作者用最後三章舉出大數據的常見運用情境,分別是推薦系統、網站流量分析以及商業數據分析。題目夠大但內容卻僅是入門級的基本範例。特別是推薦系統一章中,是用Mahout來執行協同過瀘演算法來做範例。先不論將推薦系統,用單一個協同過瀘法來涵蓋,是否會過於簡化問題以致誤導讀者。書中介紹的Mahout版本(運行在Hadoop 2.x上),已經是太舊的版本,令人懷疑這本書的出版年份是否有誤植?

總得來說本書可以讓讀者快速領略Hive在大數據平台中所能扮演的角色,免除耗費心力瀏覽散落各處的官網文件,最後還落得一頭霧水。如果動心起念想要著手大數據運算,Hive和這本「大數據Hive離線計算開發實戰」算是不錯的起點。

Senior software engineers often face a particular kind of dilemma: how to choose the most appropriate tools from a vast array of implementation technologies for a software project. The decision involves considerations such as organizational resources, team capabilities, tool maturity, and ease of use. Unfortunately, there is no universally applicable answer to this challenge. Much like “naming variables” in programming, the final decision relies heavily on the subjective judgment of the person in charge.

Big data projects encounter the same issue. In today’s era of flourishing open-source software and cloud platforms, enterprises seeking to collect, analyze, and leverage massive volumes of data can choose from everything from the classic MapReduce framework to high-performance platforms such as Spark. Regardless of which big data solution an organization ultimately adopts, it will inevitably require engineers who are proficient in that platform to guide and manage the project.

Because big data development differs significantly from traditional relational databases, mastering big data technologies has become a hurdle engineering teams must overcome. Apache Hive is an open-source tool that claims to solve this technical “pain point” once and for all. It operates seamlessly on top of the Hadoop ecosystem, fully leveraging HDFS as a distributed file system and YARN as a parallel processing framework. On top of that, Hive provides an SQL-compatible interface (HQL), allowing software tools, applications, and even developers themselves to navigate the world of big data using the familiar syntax of SQL.

From my perspective, since I am already proficient in technologies such as MapReduce and Spark, I can freely develop big data applications directly. Strictly speaking, there is no real need to add another layer of abstraction in the form of a virtual database and execute large-scale computations through SQL. However, when considering enterprise-wide adoption, expanding the accessibility of big data applications and lowering the barrier for colleagues to work with data make it worthwhile to invest in building an independently operated Hive environment.

There are not many books on Hive available on the market, and most of them were published four or five years ago. Therefore, when I decided to set up a Hive service once again, it was only natural to choose the 2020 publication Big Data Hive Offline Computing Development in Practice. The book begins with the most fundamental concepts and gradually progresses toward advanced features such as partitioning and user-defined functions. The author positions Hive as a data warehouse solution capable of handling big data, and the entire book consistently demonstrates how to implement that vision in practice. After finishing the book, one cannot help but reflect that under the competition of such powerful and convenient open-source solutions, commercial data warehouse vendors will likely find it increasingly difficult to expand their markets in the future.

In the final three chapters, the author presents several common big data application scenarios, including recommendation systems, website traffic analysis, and business data analytics. Although the topics themselves are broad, the actual content remains at an introductory level with only basic examples. In particular, the chapter on recommendation systems uses Mahout to demonstrate collaborative filtering algorithms. Setting aside the question of whether using only a single collaborative filtering approach oversimplifies recommendation systems and potentially misleads readers, the version of Mahout introduced in the book (running on Hadoop 2.x) is already severely outdated. This raises doubts as to whether the publication year of the book may have been printed incorrectly.

Overall, this book allows readers to quickly grasp the role Hive can play within a big data platform, sparing them the effort of piecing together scattered official documentation only to end up more confused. For anyone interested in getting started with big data computing, both Hive and Big Data Hive Offline Computing Development in Practice serve as solid starting points.


2020年7月26日 星期日

演算法圖鑑:26種演算法 + 7種資料結構,人工智慧、數據分析、邏輯思考的原理和應用全圖解




依舊記得在自學程式的過程中,看過某本電腦書上寫著「程式=資料結構+演算法」,簡單又有說服力,便對「演算法」這詞彙留下深刻印象。那時真心覺得要成為一個程式高手,肯定得在演算法下苦功。更因此到某大學的資訊工程研究所在職專班,修習「計算機演算法」學分,原文課本唸得我嫑嫑的。

隨著工作經驗的與日俱增,漸漸地不再迷信演算法對工作實務的重要性。不過這是因為我從事的是應用系統(AP)的設計/開發,即便後期主要在做大數據/機器學習的應用,也是直接受惠於高階程式語言和各種開源函式庫/架框。這領域的工程師已經很少花費心力在處理底層運算中枝微末節的效能議題,像Big O這個評量算法複雜性的衡量單位,真的在職場上沒遇到有同事拿來相互討論。

這不表示程式設計師可以不用瞭解精典演算法背後的概念。列表(List)、陣列(Array)、堆疊(Stack)、佇列(Queue)等資料結構,是各種程式語言中必備的核心類別/元件。而排序(Sort)算法則是實際開發時最常被使用到的基礎算法,瞭解不同排序算法的優缺點,會大大地改善程式執行的效能。因此「資料結構」和「排序算法」這兩章可視為程式工程師必備的業務知識(Domain Knowledge)。

陣列搜尋、圖形搜尋、分群以及最後一章的「其它演算法」則是各擅勝場,在特定應用領域中都是最廣為人知的核心演算法。最值得一提的是第5章介紹的「安全性演算法」,它從最基本的數位加密觀念開始介紹,一步步地擴展到「共用金鑰密碼系統」和「公開金鑰密碼系統」,而後者正是目前網站加密技術的核心。「數位簽章」和「數位憑證」說明了HTTPS的運作原理,更是網頁程式設計師不可遺漏的業務知識。

嚴格說,書名副標提到的「人工智慧、數據分析」有點言過其實。所提到的資料結構和演算法,對於數據分析、機器學習/人工智慧領域,都是不足掛齒。本書適合給有志成為程式設計師的人當做學習教材,抑或是程式設計同業用來複習或做為消遣的小讀物。在主旨為講解計算機演算法的書海中,這本「演算法圖鑑」是最容易讓讀者吸收的傑作。

2020年6月28日 星期日

行銷資料科學|大數據x市場分析x人工智慧




自擔任大數據工程師以來,除了負責大數據平台的建置與維護外,也身兼推薦系統的設計、開發。有別於其它類型的資訊系統,商品推薦系統的目標是打造出有著高轉換率的(虛擬)商品推銷員,讓我跨出資訊工程,點燃對消費者行為的興趣。在大數據分析實務上,也和行銷團隊一同商討、合作。也使得我對資訊工程在行銷領域能多做些什麼感到好奇,這本「行銷資料科學」正是具體而微地回答了我心中的種種疑問。

書中將原本在數據工程中的「資料探勘」、「大數據」、「人工智慧」等資訊技術和行銷學碰撞後產生的新學門,稱之「行銷資料科學」。因此在全書論及的實務操作/案例分享,幾乎是包山包海。近幾年在報章、網路媒體上曾被提及的數據分析和行銷資訊技術都被含蓋在內。分為「概論篇」、「大數據篇」、「行銷篇」、「策略篇」四大章。全書編排、印刷精美,文字流暢,四大章節中的各節短文,言簡意賅,卻又能做為讀者進一步鑽研的啟蒙原料。特別是「大數據」篇中所提及的數據分析與工具,提供各種實踐應用的粗淺介紹,讓有心投入行銷資料科學的組織/團隊能從中挑選要達成的功能/項目(要做什麼)。

文中也提及一些少為人知的行銷故事和研究發現。例如企業在規劃全通路策略時,應該鼓勵網路消費者到實體店面購買,研究顯示在實體通路消費者的平均客單價高於網路通路,將顧客拉到實體店面購買將有助營業額成長。而眾所皆知的「大數據神話」,沃爾瑪的啤酒和尿布,塔吉特的預測高中少女懷孕,前者是數據分析團隊編造的假故事,後者則是為了打書設計的「故事行銷」。「行銷資料科學」更像是本數據行銷新知大全,它集結了數十篇能速快閱覽的短文,讓讀者充實知識的同時也能接收到核心的行銷學觀念。

部份章節中以大專院校的召生業務為案例,說明行銷資料科學能應用、發揮的方向。然而就我來看,再優秀的戰術都無法淹蓋戰略上的錯誤,大專院校的經營困境,源起於少子化和廣設大學。利用再多的大數據分析/行銷資料科學,都難去挽救一所中後段班的私立大專院校。如果電商亞馬遜販售的商品不是市場最低價,即使有再多先進的資訊技術,都無法讓消費者心甘情願的買單。同理網飛如果沒有廣泛充實的片單和自製影集,擁有再複雜、優異的推薦演算法也是巧婦難為無米之炊。零售業的核心競爭力在於商流、物流、金流的管理,資訊流(數據分析)的良莠可說是錦上添花。

但行銷和數據分析團隊也不用妄自菲薄,再好的商品如果沒有配合適當地宣傳,一樣無法做到「貨暢其流」。書中所提及的「行銷資料科學」相關應用和工具,都是經過市場實證有效的做法,足以投入資源去研究、評估和導入。不抱著投機取巧的心態,打好企業自身在商流、物流、金流的功夫,額外再對行銷、數據整合與分析投入資源,逐漸接納以數據分析結果做決策的思維,才是真正能讓「行銷資料科學」發光發熱的實踐之道。

2020年6月17日 星期三

直播主不能說的秘密:上百場直播培訓講座,從素人到爆紅主播,經營法則首次公開!




我是不太看(幾乎沒有)直播的,對「網路直播」的熟悉度也僅止於能辨識出常上電視的「館長」、「蔡阿嘎」,最多就是因為喜愛看大胃王節目,看過FB的「大胃王千千」影片。而這本「直播主不能說的秘密」是同事看完,剛好我對炒得風風火火的直播想多點認識,就借來詳閱。

作者武老千(藝名),原先是位專職的魔術表演藝人,因緣際會下開始了他的直播生涯。由於屢創佳績在直播經營上頗有心得,後來進一步轉型成直播平台的經營者,算是直播界的演而優則導吧。本書就是他對直播產業的心得分享,小從直播主個人的經營竅門,大到對直播媒體的趨勢分析,一應俱全。非常適合做為初步瞭解直播生態的入門教材。

作者對直播文化流行的原因提出了一針見血的觀點,他認為人類天性上就是期待擁有良好的人際關係。在今日真實世界裡人際互動漸漸式微的情況下,取而代之的是網路世界的社群互動,從FB、IG等社群網站火紅的程度就足以證明。「直播平台」是一種更適合產生互動的網路新應用,連早先流行的影片平台(YouTube),都無法做到表演者和觀眾產生零時差的互動體驗。這個優勢深化了直播主和觀眾的交流,連帶提高觀眾的認同感和直播主的影響力。

直播商機,就是一種注意力經濟,和其它廣播、電視、網頁(文字)到網頁(影片)等媒介本質相同。目前也看到像飛碟電台,把錄音間的畫面直播給聽眾,讓主持人在節目播報的前後時間和網友互動。在在說明了直播是將台上台下的互動效果做到極致的一種演出,擴大定義來看,而這類型的節目在廣播和電視上早就出現過(2100全民開講),只是透過網路當媒介,執行起來更便利、便宜、有效率。

我認為,直播和其它媒體最大的差異點就是「斗內」(Donate)文化,讓表演者直接獲得觀眾的金錢贊助。傳統媒體依據收視率衡量CP值付給主持費給表演者,則是觀眾間接贊助主持人,兩者有所差異。斗內有如街頭藝人接受打賞,更直白地說,其實「直播主」就像網路世界中的「街頭藝人」。很多知名藝人跟著流行常開直播和網友互動,深怕失去人氣。有趣的是,多數直播主的夢想,卻是能成為日進斗金的真正藝人。見這山望那山,人皆如此。

在吸睛力、話題性都遠勝其它媒體的當下,商業組織和政治團體也都打起了利用/運用直播平台的主意。不過這也是行之有年的「置入性行銷」的變形,只是寄生的標的物從原本的戲據節目、新聞片段,變成了熱門的直播主。依賴直播主的口語傳播來宣傳商品,如同歐普拉在脫口秀節目中介紹商品,是廣告學中「名人背書」的手法。只因為時下年輕人熟衷此道,而人潮就是錢潮、青年就是未來,因此成為一個大家都無法忽視的社會現象。

2020年6月14日 星期日

臺灣史上最有梗的臺灣史




說來慚愧,雖然說「汝為台灣人,不可不知臺灣事」。但和我一樣出生於60、70年代,從小讀著大中國思想教材長大,又受升學主義的荼毒。往往變成「只要考試不考,都不用花心思去唸」,台灣歷史就因此被學子們忽略及漠視。這群人(包括我)對於生於斯、長於斯的這塊土地歷史,就像「最熟悉的陌生人」。

幸好有讀到「臺灣史上最有梗的臺灣史」這本書,淺略地補充近百年來重要的台灣史事。全書從史前時代的南島民族說起,據說台灣最初的原住民是南亞各國住民的共同祖先。隨著大航海時代來到,西班牙和荷蘭人發現台灣,開始殖民本地,為台灣初次帶來醫學和教育資源。沒想到台灣原住民最先是學外文,厲害吧!

後來進入明朝,才有鄭成功打敗荷蘭人,接收、治理台灣。之前到台南旅遊看到許多古蹟,像是國姓爺廟和孔廟等等,也搞不太清楚是那個時代、什麼歷史背景下的建物。在這次讀過「臺灣史上最有梗的臺灣史」後,相信舊地重遊時,就能領略名勝古蹟的典故。

台灣在清朝完全是被放牛吃草,真正開始關注並認真建設也只有最後的十幾年。沈葆楨、劉銘傳等考試要背的歷史名人,便是在晚清時參與台灣本地的建設與治理。淡水馬偕傳教士/醫師也是這個時期踏入台灣,為本地居民帶來醫療和教育的重大貢獻,其影響層面一直持續到現在(馬偕醫院,淡江中學)。

隨著甲午戰爭割讓給日本後,台灣進入了日治時代。有別於清朝是為了抵抗外國勢力入侵台灣,進行了消極、被動的基礎建設。日本國是傾全國之力,積極地在衛生、交通、農業、電力、水力全方位讓台灣邁入現代化。從「從諷刺漫畫解讀日本統治下的臺灣」一書中可以獲得更多這方面的資訊相互佐證。但日本人只是用殖民者的心態打造一座「亞太物資供應中心」,可不是把你當自己人(二等公民)。不過日本人做事都是高標準,才會讓台灣人覺得日治時期的統治者在建設上遠比前朝更用心、更有規劃。

接下來日本戰敗,歸還台灣主權。後續發展就是二二八事件、國民政府退守台灣等,近代史的歷史大事件了。隨著更多真實資料的閱讀和比對,可以發現過去課本上唸的「台灣歷史」充斥粉飾和歌功頌德的內容。60、70年代的學子,直白地說是成長在一個大謊言的世代。能不能隨著年紀增長,透過閱讀好書破繭而出瞭解真相,就是個人的取捨了。「臺灣史上最有梗的臺灣史」如同電影「駭客任務」中,能解除謊言的藥丸,不傷身體,你要吃嗎?

2020年6月13日 星期六

關於工作的9大謊言




企業與專案管理的叢書汗牛充棟,年年都有各門各派的大師們提出新的見解、主張。單就專案管理的書目,我個人很喜愛「高德拉特」以小說體裁的「目標:簡單有效的常識管理」。在企業管理的類型中我涉略有限,不算特別偏好的閱讀種類。但這本「馬克斯.巴金漢」和「艾希利.古德」合著的「關於工作的9大謊言」,卻能讓我對職場百態產生新的體悟,可謂受益良多。

端看書名,第一時間以為它是本時下流行的「職場酸雞湯」,要用上帝視角來指導大家,如何在暗潮凶湧的職涯暴風雨中保住小命,航向那個流有奶與蜜的應許之地。才看到序言就知道自己猜錯了,這是一本正經八百專為企業領導人(從老闆到基層主管都適用)撰寫的管理學指南。旨在分享兩位作者在管理學上的研究所見所聞,破除現代企業中隨手可見的人力資源/職工管理迷思。這些迷思在書中被歸納為九大謊言,之後各章開始用各謊言做破題,再旁徵博引相關研究與數據,佐證說明正確的觀念是如何如何。雖然本書的目標讀者是身為組織領導者的人們,但是其中很多觀點、做法,在舉一反三之下,也能讓基層員工瞭解怎樣明智地規劃和發展自己的職涯。

謊言一:人們在意他們為哪家公司工作
每天共事的團隊成員和上級主管的好壞,才是足以影響職員工作滿意度的核心因素。表面再華美的企業口號以及員工福利,都無法彌補惡性惡狀的頂頭上司所造成的傷害。反之亦然,好的主管和團隊會伴隨著員工出色的工作表現和高敬業度。因此謀求新職時別再執著於公司外宣的企業形象和優異福利,重點要觀察該公司是否有著培養出優秀團隊的企業文化。

謊言二:最佳計畫會致勝
現代人受到五花八門的企管理論包圍,深信藉由各種SWOT分析/圖表/顧問/會議,在面對不可測的未來時,依舊能訂定出可靠的執行計畫,帶領我們邁向成功。可惜的是現實世界裡,卻是大家朗朗上口的「人算不如天算,計畫永遠趕不上變化」。那表示我們對變動的未來就只能束手無策嗎?這也不必然。作者提出了「最佳計畫會致勝,這不是事實。事實是,最佳情報才會致勝」。為了因應不斷變化的未來,首要是打造出完整、精確的情報收集、分析工具。之後的管理竅門就是對自己公司的員工有信心,他們都擁有評估、理解資料的分析能力。組織不需要親自指導「應該」怎麼做,而是廣泛、迅速、明確的將資訊分享給所有員工,讓他們可以在第一線的工作現場,自己推導出最佳的做法。典範之一便是日本的7-11,授權讓當班店員自己決定每日的補貨品項,以快速反應各地區不同客層的實際需要。

謊言三:第一流的公司把目標層層下達
每年公司都會訂定年度經營/營業目標,再依據組織大小設定目標比率,當單位目標確定後,會再細分為單位內每個員工的個人目標,後續的目標追蹤、審核是單位主管的職責。進度表裡條列的比率數值,像是計數器般明確地向我們呈現,現在離目標有多近,很美好不是嗎?但在現實世界,很多目標要不是已經達成,就是沒有達成,這是二元性的,不會有什麼達成95%的工作成果。而時下被企業採納的目標評量考核工具,都是建立在用抽象數據去描述真實世界中的任務。最後這些考核表格/流程就淪為一年一度的腦補作文和數字填空大賽,喪失原本它承諾會實現的效用(目標管理)。真的第一流的公司,是把握機會年復一年地傳播自己核心的價值、文化給底下的員工。如此一來,才能吸引到擁有相同價值觀的有識之士加入團隊,也間接地讓無法產生認同感的員工盡早離開。

謊言四:最優秀的人才都是通才
書中引用世界頂尖足球員梅西當例子,告訴讀者追求真正的卓越是不斷地琢磨自己的長處,而非傳統教育要求的「五育均衡」。一般的企業培訓是把重點放在修補員工不擅長的項目,期待大家能多才多藝,能視任務需要自由切換不同角色。那是一種將人力資源商品化、模組化的思維,無法讓員工朝頂尖人才的方向成長。有別於字面上的解讀,「長處」的定義,並不是你「最擅長的事」。多數的活動、技能,只要透過夠多的指導和練習,都可以學會到平庸的程度。而真正能讓你不斷精進、成長的事物,是會使你感覺做起來很有力的活動。當你要執行這項任務時,會覺得時間過的很快,做完之後可能會覺得很累,但心裡很清楚,你很期待有下一次的機會。

謊言五:人們需要反饋
其實這個道理相當淺顯易懂,就是「人人愛聽好聽話」。即使管理學專家建議要對員工提供即時、正確的評批和回饋,有助於員工改善缺點,達成更好的職能表現。但實際上,人們第一時間聽到對自己的負面批評時,是會產生負面的心理防禦機制,將減低建議被採納的可能性。真正給予員工回饋的作法,是用三到五次的讚美,包含一次負面的批評。

謊言六:人們能夠可靠評量他人
相信大家對年度人事考評並不陌生,上級主管拿著制式表單,一對一地和下屬討論該員年度表現以評定分數。而這一切卻是建立在一個不可靠的立論上,「人們有能力客觀地評量他人」。人類思考有其侷限性,自身遇到困難會怪罪外在變因(景氣不好),而他人遇到困難會怪罪其人格特質(能力不足)。打分數的數字區間(寬鬆或嚴格),也像面鏡子,是反映出評量者本身的偏好和價值觀。時下流行的「360度評量」就是希望藉由引進更多周圍同事的評分,來排除單一評量者造成的偏誤。作者則對360度評量的方法提出質疑,當大家都不能正確評分時,大數法則便無法發揮效果(所有偏誤值的平均,依舊是錯的)。末段建議了一種較為可靠的評量方法,讓周圍同事直接評量對某一人的想法,但不是使用抽象的描述詞彙(效能、態度、合群等)。原本像是「團隊合作能力」的這種指標,改成「你如果有項重要的專案,會想和某某合作嗎?」。由於答案是問評量者自身的想法(沒有模糊的解讀),而不是要求他對另一人做抽象能力的評估,所得到的回答將是真實世界的實況。

謊言七:人們具有潛力
我們總是將事物簡化為二元問題,對於評估一個人的「潛力」也是(但就像謊言六所述,其實我們無法正確的評估別人的潛能)。公司大多是將員工簡單區分為「高湣力」和「低潛力」兩族群,再施以不同的獎勵和管理方法。這樣的做法忽略了每個人都有隨著環境變化,自我學習的能力(智人的特色)。要真確地評估一個人的能力,首要應區分為靜態(恆定不變)的個人特質和動態(隨時間演變)的知識、技能兩部份。員工本身的人格性質(質量),加上後天習得的本事(速率),加乘起來便是他可能發揮出來的影響力(動能)。因材施教和適才適所,都應該先判斷對象的變與不變,才能引導他走向適合他的康莊大道。

謊言八:工作與生活平衡最重要
現代人總把工作和生活一切為二。工作是辛苦的,生活是快樂的,「上班別跟我談理想,我的理想就是不用上班」。我們漸漸被說服,上班是一種交易,用我們人生寶貴的時光,換取足以養家活口的金錢。這樣的觀點卻忽視了工作本身帶來的成就感和充實感,缺少工作的人生,絕對稱不上健全。但我們會想問「工作上的鳥事這麼多,怎麼可能不辛苦?」。書中提出了一個非常好的觀點,「所謂的好工作,不是一開始就在那裡,而是你努力把手上的工作變成一個較適合你的工作,讓你樂在其中」。一項工作派下來,往往包含許多執行細項,而門道就在裡面。以我當例子,資訊研發工程師的職掌包含了新技術研發、新機制實作、系統維護等等。當我在和同事合作發展新服務/新機制時,總是很開心,常常在假日還主動試作各種原型。研讀資訊技術文件和書籍相當費時費神,還不至於到討厭的地步(愛看書?)。但遇到要撰寫各種系統文件、排定時程等文書工作,就是一整個厭煩到極點。對無法掌握技術細節的外包專案也是興趣缺缺(研發魂作祟?)。即使同屬研發工程師,也可以找到喜惡和我完全不同的員工。此時我們(不同喜好的員工)應該最大化我們最偏愛的工作項目,讓它盡可能地充滿我們的上班時間。對於不喜歡的項目,盡量的最小化,理想的工作分配,是把任務拆解成不同的工作包,讓最適當的人處理他熱愛的事,這樣對組織來說才是專案管理的最佳狀態。

謊言九:領導力是一種東西
前八章是講述理想中的領導應該是怎麼樣的型態,而它用最後一章來詳細說明「領導力」究竟是什麼。走進書店,教導人們如何成為一個好的領導者,分析優秀領導者的核心能力是什麼的理論實在太多。但卻還沒有一種論點,能一體適用真實世界中不可計數的成功人士們。其實「領導力」本身就是一個容易產生誤解的詞彙,好像是人們可以努力去學習後擁有的「能力」。但事實是「領導」的反義詞「追隨」,才是這個神秘力量的源頭。「領導者」只是有一群人「追隨者」願意跟隨他,全心全意地朝向某個目標努力,如此而已。他們相信只要跟著眼前的這個人,就能成就他們變為更好自己。如此簡明的定義,就解釋了社會上不同的組織領袖、企業領導者,在無法用定義好的「人格特質」分類下,都有各自的狂信者。真正的「領導力」,是來自信徒本身相信的「未來的自己」。

這本書所講的九大謊言,所延伸而出的觀點和說法,令我非常的驚豔。因此在心得整理上,花了更多的時間消化反芻。透過對這九大謊言的釐清、反思,讓我對職場上遭遇的一些疑點和不適感,瞬間豁然開朗。我相信書裡面隻字片語,對於身處在職海中沉浮的你我,肯定有所助益。

2020年5月31日 星期日

深入理解JVM & G1 GC



大部份的電腦技術書藉像是塊墊腳石,它們能拉升讀者的知識水平,讓人以全新的視野檢視概有的問題。而這本多達200頁的Java技術專書,就是協助讀者跨越JVM的知溝,得以有能力毫無困惑地看完下列這篇G1 GC調校的文章。(https://www.oracle.com/technical-resources/articles/java/g1gc.html)

從事Java程式開發數年,也是最近才著手調整JVM的GC算法參數。因為負責的推薦系統,有高標準的系統回應速度(三秒必須回應),整個系統架構中又含有Java-based的中間層服務。在中間層執行時需要較大Heap記憶體的情境下(十幾GB),如果還使用預設的Parallel GC算法那肯定是不行的(馬上遇到STW/Stop the world的苦果)。因此我改為採用G1 GC算法,它是從JDK7起開始現身,是專為高強度的伺服器端應用程式所設計,強調其能在超大記憶體配置下依舊維持極短GC停頓。

雖然網路上和G1 GC相關的資料多如繁星,卻沒能有系統地整理並釐清眾多GC算法參數之間的脈絡。JVM GC有著多樣的算法(Serial/Parallel/CMS/G1GC),年代型的GC又可細分為Young年代和Old年代。如果沒有按照算法演進順序來一一說明參數功能,光是看到一串名稱大同小異的GC參數組,真的會讓人一頭霧水。恰好本書對症下藥,用循序漸進的章節規劃,擇要介紹常見的GC算法/參數。後半部才正式進入主題,深入說明G1 GC算法的精要。只有極小段落的字句不甚流暢,翻閱時需要另外查詢英文資料補佐理解,讓全書有點缺憾。

不可諱言我從書中學到的知識,讓我解決了前敘提到的推薦系統效能問題,但其中仍然是充滿著不斷間的試誤(Try and Error)過程。藉由檢視gc.log的內容發現遲緩點,嘗試組合不同的GC參數值,調整後觀察運行狀況,中間絲毫沒有捷徑可走。也曾嘗試直接套用網路文章上的「G1 GC最佳參數」設定值,結果等著我的是一次最嚴重的STW停頓(暫停數十秒)。如同作者周明耀所言,GC調校這項任務,會因為不同應用程式的行為、和不同主機間的資源差異,導出截然不同的最適參數組合。在JVM的世界,沒有一組照本宣科的萬用參數組合,只能仰賴程式/系統人員的心力,試圖找出GC運作的「甜蜜點」。

[後記]
最後試出來的JDK 1.7 G1GC參數:
-XX:+PrintGCApplicationConcurrentTime
-XX:+PrintGCApplicationStoppedTime
-XX:+PrintGCDetails
-XX:+PrintGCDateStamps
-XX:+PrintGCTimeStamps
-XX:GCLogFileSize=50M
-XX:NumberOfGCLogFiles=7
-XX:+UseGCLogFileRotation
-Xloggc:/usr/local/solr/logs/gc.log
-Xmx20g
-Xms20g
-XX:+ParallelRefProcEnabled
-XX:ConcGCThreads=32
-XX:ParallelGCThreads=32
-XX:G1ReservePercent=50
-XX:InitiatingHeapOccupancyPercent=10
-XX:G1HeapWastePercent=1
-XX:G1MixedGCLiveThresholdPercent=80
-XX:MaxGCPauseMillis=900
-XX:+PrintAdaptiveSizePolicy
-XX:+UnlockExperimentalVMOptions
-XX:G1HeapRegionSize=10m
-XX:+UseG1GC

觀察用指令:
# cat gc.log.0 | grep "Eden" -A 0

相關網址: