給軟體工程師、創業者的一封信:別學 Google!因為你不是、也不會成為 Google

【我們為什麼挑選這篇文章】我覺得這可以歸類為「迷信權威」。來聊個之前曾經犯的錯吧,我之前也想要模仿 Google 或是任何一個知名的新創建立扁平化組織,結果這變成了我的第一個團隊倒的亂七八糟的一個重要原因。

「人家成功的,你不一定會成功,人家適合的,你不一定會適合」。對於一個第一次創業的人、或是任何一個要往未知領域探索的人,別迷信那些巨頭成功的因素,因為那不會成為你成功的因素,了解自己需要什麼還是最重要的事。(責任編輯:林子鈞)

軟體工程師因為一些可笑的事物而瘋狂。我們會認為自己是超級合理的,但是當我們選擇一門技術時,最終卻陷入了迷亂:從一個人在 Hacker News 留下的評論到另一個人的博客文章,我們神智混亂,茫然無助朝著最明亮的亮光前進,匍匐在光明之前,忘了我們最初追求的是什麼。

我們所說的並不是理智之人如何做決策,而是說軟體工程師為何決定使用 MapReduce。

Joe Hellerstein 給學生上資料庫課程時說過:

「在世界上,可能只有 5 家公司有如此多的員工。對於其它人來說……你從事相關的 I/O 工作,對容錯性提出很高要求,這種要求是沒有必要的。2000 年代,人們因 Google 而狂熱:『我們做一切事都要按 Google 的方式進行,因為我們也運營著世界上最大的互聯網資料服務。』」

在容錯率上提出更高要求,超過你的需要,聽起來不錯,不過要考慮一下成本:你不只要做更多的 I/O 工作,還要從成熟的系統(包括交易、索引、查詢最佳化工具)轉向相對破舊的系統。簡直就是重大的倒退。有多少 Hadoop(一種開源軟體框架)用戶無意中妥協?又有多少用戶的妥協是明智的

就目前而言,MapReduce/Hadoop 只是一個軟目標,甚至連「貨物崇拜者」(當貨物崇拜者看見外來的先進科技物品,便會將之當作神祇般崇拜。)也知道飛機偏離了航線。從更廣泛的層面上我們也可以看到同樣的現象:如果你使用一門技術,這門技術原本是針對大企業的,你的使用情況大不相同,可能無法得到預料的結果;不能,模仿巨頭就能獲得同樣的財富,這只是儀式般的信念,無法變成現實。

我有一張實用的清單供你檢查,你可以用它來制定更好的決策。

很酷的技術?UNPHAT

下一次,如果你發現自己模仿 Google,想將一些很酷的新技術拿來用,我希望你停下來,用 UNPHAT 標準檢查一下:

1、在真正理解(Understant)問題之前,不要考慮新的解決方案 。你的目標應該是在問題的範圍之內「解決」大部分問題,而不是在解決方案內解決。

2、枚舉(eNumerate)多個候選解決方案,不要選那些你喜歡的。

3、考慮候選解決方案,如果有論文(Paper)拿來讀一讀。

4、候選解決方案是如何設計的?如何開發出來的?搞清它的歷史環境(Historical Context)。

5、搞清優點(Advantages)和缺點。為了將優先的事情做好,搞清哪些事情是非優先的。

6、思考(Think)!冷靜一點,謙虛一點,多想想這個方案能從多大程度上解決你的問題。如果要讓你改變想法,事實必須有多大的變化?例如,如果讓你不選擇 Hadoop,資料必須小多少?

你也不是亞馬遜

使用 UNPHAT 法很直白。最近我與一家企業交流,這家公司要在夜間處理資料,當中包括大量讀取操作的工作流,它想使用 Cassandra。

讀了 Dynamo 的論文之後,我知道 Cassandra 分散式資料庫將「寫操作」放在優先位置(亞馬遜需要完成「加入購物車」的動作,不能出現錯誤)。我還知道,亞馬遜選擇這種技術犧牲了一致性,傳統 RDBMS 的每一個功能也都犧牲了。不過與我交流的公司沒有必要將寫操作放在優先位置,因為它的讀取模式是每天大規模寫一次。

這家公司為什麼考慮 Cassandra?因為用 PostgreSQL 查詢問題需要幾分鐘,他們認為是硬體局限性造成的。問了幾個問題之後,我發現表格有大約 5000 萬行,80 位元組寬,能不能用 5 秒左右的時間從所有 SSD 中讀取資料。仍然很慢,但是比實際查詢速度快了很多很多。

在這件事情上,我想問更多的問題(理解問題),當問題出現時我權衡了 5 種策略(枚舉多個候選解決方案),有一點很明顯,選擇 Cassandra 是完全錯誤的。它們要做的是優化系統,可能還要對一些資料重新建模,或者(也可能不是)選擇另一種技術……顯然不是 Cassandra 技術,亞馬遜將關鍵值存儲起來,這些資料高度重視寫操作,它們是為購物車創建的。

你也不是 LinkedIn

我的一名學生創辦了一家公司,他的公司根據 Kafka 搭建系統,我感到很驚訝。為什麼吃驚?因為據我所知,他們的企業每天只處理幾十宗高價值交易——最多可能幾百宗。既然處理的資料如此少,最好的資料庫可能是讓人寫在實體書上。

對比一下,Kafka 是用來處理 LinkedIn 所有分析事件的:海量的數字。放在幾年前,每天這樣的事件可能有 1 萬億件,高峰時期每秒 1000 萬條資訊。我知道,即使輸送量低,Kafka 仍然可以使用,但是如果少了 10 個數量級呢?

可能工程師做出這樣的決定是因為他們預計未來需求會大增,或者對 Kafka 的基本原理有著深刻的理解。不過照我猜測,可能是社區對 Kafka 熱情高漲,影響了他們,工程師沒有深入思考它是否適合自己。我的意思是處理的資訊少了 10 個數量級!

再次重申,你不是亞馬遜

與亞馬遜分散式資料庫相比,讓它可以擴展的架構模式更流行,也就是以服務為中心的架構。2006 年,Jim Gray 採訪 Werner Vogels,當時 Werner Vogels 說亞馬遜早在 2001 年就意識到它們想擴展前端相當吃力,最終以服務為中心的架構幫上大忙。這種觀點得到了工程師的推崇,結果一些只有幾名工程師、沒有多少用戶的創業公司也將自己的 App 打碎,放進微服務。

當亞馬遜決定向 SOA 轉移時,它的員工數量已經達到 8700 人,銷售額超過 30 億美元。並不是說你的員工數量達到 8700 人才能使用 SOA……只是你應該多掂量掂量自己。要解決你的問題,它的方案真的是最好的嗎?你的問題到底是什麼,能不能用其它辦法解決?

如果你告訴我,說你們有 50 人的工程團隊,如果沒有 SOA 工作將無法開展下去,我會感到奇怪,因為有許多更大的企業只有更大、但是組織更好的單一應用,它們同樣做得很好。

甚至連 Google 都不是 Google

使用大規模資料流程引擎(比如 Hadoop、Spark)是一件相當有趣的事:不過許多時候傳統 DBMS 夠用了,與工作流更匹配,有時資料的數量很小,完全可以放進記憶體中。你知道嗎,花 1 萬美元就可以買 1TB 的記憶體?即使你有 10 億用戶,每位用戶也可以分派 1KB 的記憶體。

對你來說也許不夠,你要將資料寫入硬碟,從硬碟上讀取。但是你要從無數的硬碟中完成讀寫操作嗎?你到底有多少數據?GFS 與 MapReduce 之所以開發出來,是為了處理基於整個網路的計算問題,例如為整個網路重建搜索索引。

你也許已經讀過 GFS 和 MapReduce 的相關論文,知道 Google 的部分問題不在於容量,而在於輸送量:它採用分散式存儲方式,主要是位元元組流離開硬碟需要太長的時間。2017 年,你所使用的設備輸送量如何?假設你需要的數量沒有 Google 多,你能否購買更好的?使用 SSD 到底要花多少錢?

也許你想在未來擴容。那麼你計算過嗎?數位元的增長速度比 SSD 價格下跌的速度快嗎?當你所有的資料不再適合用一台機器處理時,你的企業需要變得有多大?截止 2016 年,Stack Exchange 每天處理 2 億查詢量,它只用了 4 台 SQL 伺服器:一台伺服器處理 Stack Overflow,一台用來做其它事,還有兩台備用。

用 UNPHAT 之類的流程審查之後,你可能還是決定使用 Hadoop 或者 Spark。這個決定可能是正確的。無論怎樣,為工作配備正確的工具,這才是最重要的。Google 深知這點:當它知道 MapReduce 不是構建索引的正確工具時,它就停用了。

第一步是理解問題

我的觀點並不新穎,但是這個觀點可能適合你,或者 UNPHAT 便於記憶,可以讓你拿來用。如果不滿意,你可以瞭解一下 Rich Hickey 在 Hammock Driven Development 的講話,或者讀讀 Polya 的書「How to Solve It」(如何解決問題),還可以聽聽 Hamming 的課程「The Art of Doing Science and Engineering」(科學與工程的藝術)。我們都在向你傳輸一個理念:思考。從實際出發理解你要解決的問題。用 Polya 的話說就是:「回答你不理解的問題是愚蠢的,為了一個你不想要的結果工作是悲哀的。」


延伸閱讀

Google 神秘創新團隊 ATAP 崩壞:老闆跳槽、資金被撤,Google 怎麼了?
Google 如何在自動駕駛領域橫掃全球?Waymo CEO 公布無人車黑科技細節
【Google I/O 發表會】從今天起,Google 的每一個服務、每一個位元,都是人工智慧

(本文經合作夥伴 36kr 授權轉載,並同意 TechOrange 編寫導讀與修訂標題,原文標題為 〈你不是 Google,不要試圖模仿它〉。)

 

點關鍵字看更多相關文章: