軟件工程師對於最荒渺的事情非常熱衷。我們傾向於認爲自己是超理性的，但是當我們面臨一種技術選擇的時候，我們最終會陷入一種瘋狂狀態——從一個人的Hacker News評論跳到另一個人的博客文章，直到變得麻木，我們無助地漂浮朝着最明亮的光線傾斜，並且俯臥在它的前面，而忽略了我們最初尋找的東西。
這不是理性的人做出決定的方式，而是軟件工程師決定使用MapReduce的方式。
正如Joe Hellerstein在他的本科數據庫課程[1]上所說的（在54分鐘）：
問題是世界上有5家公司從事如此大的工作。對於其他所有人……你正在爲實際上不需要的容錯能力執行所有這些I/O。人們在2000年代有點Google的狂熱：“我們將像Google一樣做所有事情，因爲我們也運行着世界上最大的互聯網數據服務” [橫擺傾斜，等待笑聲]
你們的數據中心大樓有幾層？Google在俄克拉荷馬州梅斯縣的數據中心是4層。
擁有比所需更多的容錯能力可能聽起來不錯，但考慮到成本：不僅會做更多的I/O，而且可能會從一個成熟的系統（如事務，索引和查詢優化器）過渡到某種相對不成熟的系統上。真是倒退了一大步[2]。有多少Hadoop用戶自覺地進行了這些折衷？有多少用戶明智地進行了這些折衷？
目前，MapReduce/Hadoop僅僅是一個簡單的目標（soft target），即使開發人員已經意識到目標不是很合適。但是，可以從更廣泛的角度進行同樣的觀察：如果你使用的技術源於一家大公司，但是你的用例卻大不相同，那麼你就不太可能達到同樣的效果；不，應該說你可以通過模仿巨人會帶來相同的財富這種儀式主義信念而達成目標。
好吧，其實：這是又一篇“不要崇拜”的文章。但是等一下！我爲你準備了一份有用的清單，你可以用來做更好的決定。
酷科技？UNPHAT
下一次當你正在搜索一些酷的新技術，用於構建（重構）你的架構時，我強烈建議你先停下來，然後遵循UNPHAT原則：
在沒有理解（Understand）問題之前，不要考慮解決方案。你的目標主要應該是在問題領域而不是在解決方案領域“解決”問題。
列舉（eNumerate）多個候選解決方案。而不是一開始就按自己喜歡的方式行事！
考慮一種候選解決方案，如果有相關論文，那麼要閱讀該論文（Paper）。
確定候選解決方案當初設計或開發的歷史背景（Historical context）。
權衡利（Advantages）弊。確定哪些不是優先考慮的，哪些是需要優先實現的。
多想想（Think）！冷靜而謙遜的思考一下該解決方式是否真的適合你的問題。基於哪些事實情況，你纔會改變想法？例如，在你選擇不使用Hadoop之前，數據需要多小纔行？
你也不是亞馬遜
應用UNPHAT原則非常簡單。最近我和一家公司有過一次交流，這家公司曾經短暫的考慮過將Cassandra用於主要對數據讀取的工作流，這些數據在夜間加載：
閱讀了Dynamo的論文，並知道Cassandra是它的一個緊密的衍生物後，我瞭解到這些分佈式數據庫優先考慮寫可用性（Amazon希望“添加到購物車”操作永遠不會失敗）。我也挺欣賞他們通過犧牲一致性以及存在於傳統RDBMS中差不多每個功能特性來做到這一點。但是與我交流的那家公司不需要優先考慮寫可用性，因爲訪問模式要求每天只需要進行一次大的寫操作就行。
亞馬遜賣很多東西。如果“添加到購物車”偶爾失敗，他們將損失很多錢。你的用例是否相同？
該公司之所以選擇Cassandra，是因爲PostgreSQL查詢需要消耗比較長的時間，他們認爲這是由於硬件的限制導致的。經過幾個問題之後，我們得出數據表大約在有5000萬行和80字節寬的時候，那麼在需要完整的文件掃描（FileScan）情況下，也需要大約5秒鐘才能從SSD上讀取全部內容。速度很慢，但是比實際查詢快2個數量級。
在這一點上，我真的很想問更多問題（question）（理解真正的問題（problem）！），並開始權衡問題發展的5種策略（列舉多個候選解決方案！），但很顯然，Cassandra是一個完全錯誤的解決方案。他們所需要做的只是進行一些耐心的調整，也許重新建模一些數據，也許（但可能不是）另一種技術選擇……但肯定不是亞馬遜爲其購物車創建的高寫入可用性鍵值存儲！
你也不是LinkedIn
我很驚訝的發現我的一個學生公司選擇使用Kafka構建他們的系統。這很讓人驚訝，據我所知，他們的業務每天僅處理幾十筆非常高價值的交易——好的情況下一天有幾百筆。以這樣的吞吐量，他們的數據存儲改成人工記錄到本子上都可以。
相比之下，Kafka設計之初用於處理LinkedIn上所有分析事件的吞吐量：一個巨大的數字。即使在幾年前，每天也有大約1萬億個事件發生，每秒峯值超過1000萬條消息[3]。當然Kafka仍可用於較低吞吐量的工作，但要低10個數量級？
太陽雖然很大，但也只是比地球大6個數量級。
也許工程師確實根據他們的預期需求和對Kafka原理的充分理解做出了明智的決定。但是我的猜測是，他們更多受社區（通常是合理的）對Kafka的熱情感染，卻絲毫沒有考慮這是否適合這項工作。我的意思是……10個數量級！
再說一遍，你不是亞馬遜
比Amazon分佈式數據存儲更受歡迎是他們認爲可擴展（scale）的架構模式：面向服務的架構。正如沃納·沃格斯（Werner Vogels）在2006年接受吉姆·格雷（Jim Gray）採訪[4]時指出的那樣，亞馬遜在2001年意識到面向服務的體系結構對於擴展前端有很大幫助。這種想法慢慢的在不同的工程師之間傳播，在剛開始只有幾個工程師在做這件事的時候，幾乎很少有用戶把他們的應用拆分成不同的小服務（nanoservices）。
但是當亞馬遜決定遷移到SOA時，他們擁有大約7800名員工，銷售額超過30億美元[5]。
舊金山的比爾·格雷厄姆禮堂可容納7,000人。遷移到SOA時，亞馬遜大約有7,800名員工。
這並不是說你應該推遲SOA，直到達到7,800名員工的水平……只是，請自己考慮一下。這是解決你問題的最佳方法嗎？你的問題到底是什麼？還有其他解決方法？
如果你告訴我，你的50人工程師團隊在沒有SOA的情況下會陷入癱瘓，那麼我想知道，爲什麼有很多大公司在一個大的但是組織良好的單應用程序上依然可以做的很好。
甚至Google也不是Google
大規模數據流引擎（如Hadoop和Spark）的使用可能特別有趣：傳統DBMS通常更適合工作負載，有時數據量非常小，甚至可以容納在內存中。你是否知道可以10,000美元左右購買1 TB的RAM？即使你有十億用戶，這也將爲每個用戶提供1KB的RAM。
可能這還不足以滿足你的工作負載，因此你需要讀寫磁盤。但是，你是否需要讀寫幾千個磁盤？你到底有多少數據？GFS和MapReduce就是爲了處理整個Web上的計算問題應運而生的，例如……在整個Web上重建搜索索引。
硬盤價格現在比GFS論文發表那年的2003年要低得多。
也許你已經閱讀了GFS和MapReduce的論文，並意識到Google的部分問題不是容量，而是吞吐量：它們分散存儲，因爲從磁盤流式傳輸字節花費的時間太長。但是，你在2017年使用的設備的吞吐量是多少？考慮到你不會需要像Google那樣多的設備，那麼你能買更好的嗎？使用SSD會花多少錢？
也許你希望做擴展。但是你有做過計算嗎？是不是可能存在數據的累積速度快於SSD價格下降的速度？你的業務需要增長多少纔會讓所有數據不再適合保存在一臺機器？截至2016年，Stack Exchange每天處理2億個請求，僅由四臺SQL服務器提供支持[6]：一個主服務器用於Stack Overflow服務，一個主服務器用於所有其他內容服務以及兩個備用服務器。
同樣，你可能經歷了類似UNPHAT的過程，但仍然決定使用Hadoop或Spark。這項決定甚至可能是正確的決定。重要的是你實際上使用了正確的工具來完成工作。Google非常瞭解這一點：一旦他們確定MapReduce不是構建索引的正確工具，便會停止使用它。
首要任務，理解問題
我的文章信息不是最新的，但也許是當前你看到的版本，或者UNPHAT讓你印象深刻，最終讓你應用它。如果沒有，你可以嘗試看看Rich Hickey的演講Hammock驅動的開發[7]，或Polya的書如何解決[8]，或Hamming的課程科學與工程的藝術[9]。我們所有人懇求的是多思考！並真正瞭解你要解決的問題。用Polya讓人深思的話說：
回答你不理解的問題是愚蠢的。爲不是自己期待的結果的工作而工作是可悲的。
相關鏈接：
https://archive.org/details/ucberkeley_webcast_NSKvCVFmk2E
https://homes.cs.washington.edu/~billhowe/mapreduce_a_major_step_backwards.html
https://engineering.linkedin.com/kafka/running-kafka-scale
https://queue.acm.org/detail.cfm?id=1142065
http://media.corporate-ir.net/media_files/irol/97/97664/reports/2001annualreport.pdf
https://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition/
https://www.youtube.com/watch?v=f84n5oFoZBc
https://www.amazon.com/How-Solve-Mathematical-Princeton-Science/dp/069111966X
https://www.youtube.com/playlist?list=PL2FF649D0C4407B30
原文鏈接：https://blog.bradfieldcs.com/you-are-not-google-84912cf44afb
Kubernetes管理員認證（CKA）培訓
本次CKA培訓在北京開班，基於最新考綱，通過線下授課、考題解讀、模擬演練等方式，幫助學員快速掌握Kubernetes的理論知識和專業技能，並針對考試做特別強化訓練，讓學員能從容面對CKA認證考試，使學員既能掌握Kubernetes相關知識，又能通過CKA認證考試，學員可多次參加培訓，直到通過認證。點擊下方圖片或者閱讀原文鏈接查看詳情。
