很多時候,那些出色的設計思路或者新穎的工具并沒有讓事情變得更快。相反,它們卻拖慢了你的速度。
這在為大規(guī)模使用設計的工具上尤為明顯。它們刻意增加復雜性以增強可擴展性。
但如果你現(xiàn)在的規(guī)模還不夠大,那么你就不需要這個工具。
讓我舉個例子...
你的 Hadoop 集群比我的命令行慢 235 倍
常用的工具通常能很好地完成工作。
我最近在 Adam Drake 的博客上發(fā)現(xiàn)了一篇很好的文章。在這篇文章中,任務是分析 200 萬局棋的勝率,數(shù)據大約有 1.75GB。他比較了 Hadoop 集群與一些簡單的命令行工具的性能。
他的發(fā)現(xiàn)是什么?
對于同樣的數(shù)據量,我使用我的筆記本電腦大約 12 秒就得到了結果(處理速度約為 270MB/秒),而 Hadoop 的處理時間大約為 26 分鐘(處理速度約為 1.14MB/秒)。
這是 235 倍的差異。
使用大數(shù)據工具,如 Hadoop,來完成流處理工具可以在命令行中完成的工作是過度設計。Hadoop 集群并沒有帶來任何好處。事實上,復雜的架構正在減緩速度。
復雜性盲點
作為一名軟件開發(fā)者,你需要注意的是...
添加復雜性經常看似會更快/更好。但除非你測試你的假設,否則你永遠不會真的確定!
這適用于數(shù)據庫索引、并行處理、緩存、數(shù)據管道以及作為開發(fā)者的其他許多時刻。
你可能會認為 Hadoop 集群更適合批處理。這就是這個工具的構建目的!但這完全取決于手頭的任務、數(shù)據的格式以及你期望的輸出。
如果你按照這個假設去執(zhí)行,你可能會在應用中引入不必要的復雜性。一個更簡單的解決方案可能會更好!
簡單幾乎總是更好
這個教訓是首先構建簡單的版本,然后測試關于更復雜版本的假設。
通常,簡單的版本已經足夠快并能夠滿足你的需求。開始時不要過度設計。
然后,當你的簡單解決方案達到其可擴展性的極限時,找到瓶頸并針對瓶頸進行優(yōu)化。
如果你讀了 Adam Drake 的博客文章,你會看到他的國際象棋分析器的第一個版本已經比 Hadoop 集群更快。但當他尋找可擴展性時,他優(yōu)化了解決方案以并行化簡單方法的一部分。
我認為這種方法在現(xiàn)實世界中會走得很遠。它可以處理除了最大的大數(shù)據集之外的所有內容。他需要在大規(guī)模下使用 Hadoop 來解決問題還需要一段時間。
也許 Hadoop 永遠都不是最佳的工具選擇。只有通過測試你的假設,你才會知道。
每日清單
2,000 名軟件開發(fā)人員會收到我的每日文章,直接發(fā)送到他們的訂閱消息中。
如果你喜歡我的文章,點贊,關注,轉發(fā)!