分布式計算的核心思想在沒有包裹業務之前并不復雜，簡單而言，如果有一個任務（可以是查詢，排序，搜索）可以被拆分為互不影響的若干個重復的小任務，那么我們就可以使用多臺計算機并行的執行這些小任務。
任務執行必然需要對各種資源進行調用，例如硬件，數據，網絡等，這些資源的調用會形成至少3個問題：
- 數據的一致性，如果某一個子任務對數據進行了修改，需要有策略保證其他子任務訪問這塊數據時得到及時更新。
- 任務執行的時序，如果先后執行的任務有依賴性，或者稱之為stateful的執行，那么執行順序需要進行一定的保證。
- 執行失敗的處理，如果某一個計算節點掛掉了，那么如何保證整個計算框架可以繼續執行，并且對失敗的子任務進行重新分配。
接下來，在實現分布式計算的過程中，上層應用往往不希望對底層的任務調度，資源訪問進行直接操作。我們還希望對節點的訪問體驗如同本地一般。這時，可以采用RPC框架進行接口的封裝。
Hadoop，Spark，Storm，Flink在某種程度上都是提供了一個寬泛的分布式計算框架。它們并不針對于一個特定的計算問題，而是對任務的實現進行底層分布式實現并且提供面向上層的抽象接口。
Hadoop是最早的分布式框架，它的核心兩個東西，MapReduce的任務拆分，和HBase。如果我們的任務只是純粹計算和內存資源訪問，Hadoop本身可能沒什么優勢。
Storm和Spark是針對實時處理的框架，例如它們具備的消息隊列，流處理設計。在結構上，和Hadoop最大的區別可能是它們引入了內存訪問，所以直觀上感覺對數據的訪問會比Hadoop要快一些。
Flink重點在于stateful的應用，即它對資源的訪問不是單純面向SQL，而是保留了內部的狀態。相比前三者，Flink的優點在于能夠對Stateful的應用降低延遲（latency）。如果我們的數據是消息隊列，交易，那么考慮用flink。阿里在Flink之上開發了Blink，性能也非常好。
MeSoS是資源的分布式訪問，即我們需要解決的第1個問題。
分布式計算框架選擇，最根本的原則在于能否解決計算的瓶頸，包括磁盤讀寫，計算力，網絡帶寬，異構數據處理。這其中，計算力往往是最后才需要考慮的，其次是異構數據處理。一般而言，非涉及到復雜計算如神經網絡訓練，系統的瓶頸往往是數據量和傳輸帶寬。如果是復雜計算，也沒必要頻繁調用分布式框架，以目前大部分公司常規業務而言，優先考慮單機。
如果我們的任務是純粹的計算，并且強調實時性的時候，上面幾個框架都顯得過分冗余了，這時，利用rpc和多核進程反而能帶來最優的性能。
