大數據文摘作品，轉載要求見文末
原作者 | Ozan Onay
編譯 | 高寧，朱璇，Aileen
導讀：MapReduce,Hadoop,Kafka……似乎每天都有新的名詞出現，每天都會有看似很酷的新技術誕生。是否我們現在的系統框架已經過時了？是否應該效仿谷歌、亞馬遜或者領英的技術和方式？
本文作者提出的UNPHAT方法非常實用，它教你如何在急著行動前，清醒的想一想，最適合自己的選擇才是對的。
除了技術/系統框架的抉擇，這個方法對解決生活中的任何問題都是不錯的啟發。
21世紀，每個人都多少有些谷歌狂熱症，似乎按照谷歌的方式做事，我就能得到谷歌的財富。比如，作為一名軟件工程師，我是否該效仿谷歌建立MapReduce框架？是否應該像領英一樣用Kafka來搭建系統？
伯克利計算機學院教授Joe Hellerstein會在每次課上會告誡他的本科生：“你不是谷歌，你經營的可不是全球最大的互聯網數據服務。”
有興趣可參考視頻：
https://archive.org/details/ucberkeley_webcast_NSKvCVFmk2E
事實上，這個世界上目前只有5家公司在運行著足夠巨大需要MapReduce框架的程序。而對於其他公司，只是在 I/O(輸入輸出)上做了很多不必須的防錯工作。
你們的數據中心大樓有多少層？谷歌的有4層，上圖就是他們位於俄克拉荷馬州梅斯縣的數據中心。
這當然也涉及了更多不必要的費用的產生：一方面你需要做更多的I/O，另一方面你需要從一個使用了很久、相對成熟的系統轉移到一個你並不熟悉的系統。這其實是一種大的退步。有多少Hadoop的用戶清醒地權衡過這些得失？又有多少用戶能對此做出明智的決定？
如果你正在使用的技術來源於一家大公司，但是你的業務情景完全不同，你將很難從容地用他們的技術來實現同樣的效果。
恩，是的，這是另一篇“不要盲目崇拜新技術”的文章。
嘗試新技術前，先試試UNPHAT法則
軟件工程師有時會為些荒誕不羈的事情而瘋狂。當需要選擇實用哪一種技術時，我們會從社交網絡裡中某人的評論，跳到另一個人的博客，不斷的搖擺不定下不了決心，最終陷入到一種瘋狂的狀態。迷茫中，我們總是朝著那些好像最耀眼的光芒漂游著，卻忘記了我們真正尋找的是什麼。
下一次，當你發現自己在網上了搜索 某些很酷的技術去（重新）搭建架構時，請先用這個UNPHAT 法則對這個新技術進行審視：
1. Understand (理解）：在你理解問題之前，不要開始思考解決方案。應該從問題入手，而不是從答案入手。在問題的領域思考如何結局，而不是在“解決方案的領域”裡選擇解決辦法。
2. Numerate(列舉）：請列舉出多個候選方案，而不是直接選擇你喜歡的那個。
3. Paper (論文）：選定一個候選方案。如果你找到一篇候選方案的論文的話，請閱讀它。
4. Historical Context (歷史背景）：在設計和開發候選方案時，請考慮相關方法的歷史背景。
5. Advantage （優勢）：權衡利弊。決定使用什麼樣的優先級來排序所列出的利弊。
6. Think! (思考！)： 冷靜而謙遜地思考這個解決方案與你的問題的匹配狀況。考慮出現什麼樣的情況，你會改變自己的想法？例如，數據集小到什麼程度，你會決定放棄使用Hadoop？
你不是亞馬遜
下面是一個很簡單的使用UNPHAT方法的例子。我最近和某家公司就是否使用Cassandra對夜間產生的大批量工作流數據進行讀取的問題展開了討論。
我讀過Dynamo的論文，而且我知道Cassandra是一個Dynamo的衍生物，所以我清楚地瞭解這些分佈式數據庫將讀寫可用性放在第一位（亞馬遜希望所有的“添加到購物車”行為永遠不會失敗）。我也知道他們是通過部分降低數據庫的一致性來提高它的讀寫可用性，這會對傳統關係型數據管理系統中的幾乎所有特性都會產生一定影響。但是與我交談的這家公司並不需要將讀寫可用性放在第一位，因為他們的傳輸模式是一天進行一次大批量的讀寫。
亞馬遜出售大批量商品。如果“添加到購物車”功能偶爾發生故障，他們可能會損失很多收益，但是你的使用場景也是這樣嗎？
這家公司之所以想要使用Cassandra是因為PostgreSQL在讀取文件時需要好幾分鐘的時間，他們認為這是一個硬件限制問題。在問了幾個問題後，我們確定瞭如果需要從固態硬盤中讀取一個5000萬行、80字節寬的表格的完整的文件，大概需要5秒。雖然這個速度比較慢，但是仍比實際查詢快了2個數量級。
此時，我需要再多問一些問題（來理解他們的問題），並衡量為防止問題變得嚴重的5個策略（列出多個候選方案！），但是我已經很清楚地知道使用Cassandra是一個完全錯誤的解決方案。他們需要去做的是耐心調試原有的結構，或者重新搭建一些數據結構，或者選擇其他的技術方案（應該不需要）……但肯定不是亞馬遜為購物車所搭建的高讀寫可用性的關鍵值存儲方案！
你不是領英
我很驚奇地發現有個學生的公司選擇使用Kafka來搭建他們的系統。而他們的業務流程只有每天幾十條高價值交易，如果生意好的話，可能一百多條。對於這個吞吐量而言，一個人手工去進行記錄就可以完成數據庫存儲了。
相對而言，Kafka是為了處理領英上所有的待分析的事件而設計的：這是一個很巨大的數字。即使是幾年前，這個數字可以達到每天處理萬億事件，在高峰時期可以超過每秒一千萬的信息量。我同意Kafka對於低吞吐量的工作負荷同樣有效，但是相比之下，低了十個數量級的數據真的需要Kafka嗎？
或許工程師們根據預期需要和對Kafka理論基礎的充分理解，“確實”做了一個經過考量的決定。但我估計他們是被一些社交網站（通常是合理的評論）中對Kafka的熱情所洗腦，而幾乎沒有考慮它是否適合這個問題。畢竟……這個是差了十個數量級的情況。
回到亞馬遜
比亞馬遜分佈式數據存儲架構更受歡迎的是能支持他們規模化的面向服務的體系結構：service-oriented architecture（SOA）。Werner Vogels在2006年對Jim Gray的採訪中提到，在2001年亞馬遜意識到他們擴展前端受到限制，從而設計了一個面向服務的架構最終解決了這個問題。這種想法在工程師中產生了巨大影響，甚至只有幾個工程師和很少的用戶的創業公司都開始將他們的APP分解為一系列的迷你服務了。
但是當亞馬遜決定遷移到SOA的時候，他們已有大概7800名僱員，而且銷售額超過了三十億美金。
上圖：舊金山的比爾·格雷厄姆禮堂可以容納7000人。而亞馬遜決定轉向到面向服務的框架（SOA）的時候，它的僱員大約有7800人。
我並不是說當你有7800名僱員的時候你才可以轉向SOA。只是希望你可以思考，SOA對你的問題而言是最好的解決方案嗎？你的問題到底是什麼，以及你是否可以使用其他方法解決？
如果你說你的50人的工程師團隊如果沒有SOA就會難以運轉，那麼我會很好奇為什麼那麼多大公司使用一個很大但是管理得很好的單個應用程序也可以做的很好。
即使谷歌也不是谷歌
使用大型數據流引擎類似Hadoop和Spark也會特別有趣：通常，傳統的數據庫管理系統（DBMS）更適合於整體的工作負載，有時候數據量非常小，甚至可以存儲在內存中。你知道可以使用10000美元購買一個千兆的內存條（RAM）嗎？即使您擁有十億用戶，它仍可以為每個用戶提供1kb的內存。
或許對於你的工作負載而言可能還不夠，你需要對硬盤進行讀寫。但是你需要對數以千計的磁盤進行讀寫嗎？確切的說，你擁有多少數據呢？GFS（可擴展的分佈式文件系統）和MapReduce是為了處理整個網絡的計算量而創造的，例如，在整個網絡上重建搜索引擎……
上圖：硬盤驅動器的每千兆字節的成本（美元）。今天的硬盤驅動器價格比2003年（GFS研究論文發佈那年）低了很多很多。
或許你已經閱讀了GFS和MapReduce的相關論文，而且很感謝谷歌的問題出現在輸入輸出量而不是容量上：他們進行分佈式存儲，因為磁盤存儲需要太長時間。在2017年你將使用的硬件設備會有多大的輸入輸出量呢？考慮到你不會需要和谷歌一樣的輸入輸出量，你是否只需要買一個更好的磁盤呢？使用SSD你會花多少錢呢？
或許你期望可以進行規模化。但是你有進行過數學計算嗎？你累積數據的速度會比SSD價格下降的速度更快嗎？你的業務需要增長多少，你的數據才會多到不能放在一臺機器上。在2016年，Stack Exchange網站每天收到2億個請求，而他們的後臺僅僅是4臺SQL服務器，一臺主要服務於Stack Overflow網站，一臺為其他事物服務，其他兩臺用來保存副本。
再次重申，你走完整個UNPHAT流程後，可能仍然決定使用Hadoop或者Spark。這個決定有可能是正確的。最重要的是，對於這個問題，你真的選擇了最合適的工具。在這一點上，谷歌做的很好：當他們發現MapReduce不是構建索引最合適的工具後，他們就不再使用它了。
最重要的是理解問題
我上面提到的並不是全新的內容，但也許它能引起你的思考，或許使用UNPHAT對你來說有難以置信的效果。如果是這樣，你可以嘗試Rich Hickey談話中（https://www.youtube.com/watch?v=f84n5oFoZBc）所提到的“吊床推動發展”，或者Polya書中（https://www.amazon.com/How-Solve-Mathematical-Princeton-Science/dp/069111966X）寫到的“如何解決一個問題”，或者Hamming的課程中（https://www.youtube.com/playlist?list=PL2FF649D0C4407B30）所提到的“科學和工程實踐的藝術”。我們希望你可以去思考並真正的瞭解你正在嘗試解決的問題！
最後，我想以Ploya書中令人警醒的一段話作為結尾：
去回答一個你不明白的問題是愚蠢的。為了一個你並不想要的結局而努力是悲哀的。
原文鏈接：https://blog.bradfieldcs.com/you-are-not-google-84912cf44afb