【我們為什麼挑選這篇文章】我覺得這可以歸類為「迷信權威」。來聊個之前曾經犯的錯吧，我之前也想要模仿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，不要試圖模仿它〉。）
