反思｜分布式框架是必須的嗎？
【原文編者的話】本文主要講述了通過規范化處理流程，可以使用相同的處理流程來處理流式或者批量處理任務，例如Hadoop和Storm，從而提高重用性。
當有人問起該如何處理大數據問題時，他們總是被指引到現存的產品中，例如Hadoop或者Storm。雖然這些產品非常棒，但也引發了一些問題。首先，就我個人的經驗來看，為了獲得***的處理結果，你必須使用這些框架***的語言或者虛擬機編寫你的代碼，典型的就是JVM。當語言或者虛擬機不適用時，就意味著你必須重寫你的代碼來適應這些框架。同樣，像Hadoop和Storm這兩種框架所做的事情非常不一樣，這就給代碼的重用增加了更大的困難。如果你想做流式和批量處理分析，你就需要這兩種框架。當然，有些方法能夠做到這一點，但我不清楚這種方法是否有更多的選擇性，或者這種方法是否很難進行維持。
目前，我正在使用一個分布式系統并且它沒有使用任何上述技術。這個分布式系統運行的很好，雖然它不***，但是它的確實現了。這就引發我思考分布式框架是否是必須的。實際上，MapReduce和Streaming框架的真正區別是什么?數據通過不同的處理流程串行化，這僅僅是如何將數據鏈接到一起以及不同處理流程發出數據頻率的問題。
因此，也許我們真正需要的是規范化如何讓各種處理流程并存以及如何將它們連結在一起。我相信我們可以通過一些現有的技術來做到這一點。Mesos 和Kubernetes可以在一個集群中用來執行處理流程。隊列化技術例如Kafka和NSQ能夠在不同的處理流程間傳遞消息。處理流程可以使用不同的語言實現，并且可以通過Docker或者類似產品封裝在容器中來管理其依賴。
我個人發現這種方式是比較合適的，這種解決方法聚焦在不同處理流程之間的通信問題。通過制定相關的協議，我相信可以將不同的處理流程解耦合。同樣，當需要時分析過程中使用到的技術也能更加容易地置換出來。舉個例子來說，Python能夠用來塑造一個分析原型，當性能成為更為嚴重的問題時，它可以使用編譯型語言D或者Go進行重寫。當相同的處理流程無需修改代碼就可以適用于流式處理和批量處理或者MapReduce任務時，我們也能從中獲得更好的重用性。
當然，這只是一個粗略的想法，也沒有覆蓋這些系統的所有案例和各個方面，但我相信這是一個好的開始。我更加希望看到的是有個工程能夠更加深入地研究下去，并且能夠為這些系統制定一份詳細說明書。如果需要，這種方法可以按照詳細說明書提供運行庫來確保兼容性，也許更重要的是描述在一個兼容性問題的事件中該做什么。
大家有什么想法呢?
