反思｜分散式框架是必須的嗎？

【原文編者的話】本文主要講述了通過規範化處理流程，可以使用相同的處理流程來處理流式或者批量處理任務，例如Hadoop和Storm，從而提高重用性。

當有人問起該如何處理大資料問題時，他們總是被指引到現存的產品中，例如Hadoop或者Storm。雖然這些產品非常棒，但也引發了一些問題。首先，就我個人的經驗來看，為了獲得最佳的處理結果，你必須使用這些框架首選的語言或者虛擬機器編寫你的程式碼，典型的就是JVM。當語言或者虛擬機器不適用時，就意味著你必須重寫你的程式碼來適應這些框架。同樣，像Hadoop和Storm這兩種框架所做的事情非常不一樣，這就給程式碼的重用增加了更大的困難。如果你想做流式和批量處理分析，你就需要這兩種框架。當然，有些方法能夠做到這一點，但我不清楚這種方法是否有更多的選擇性，或者這種方法是否很難進行維持。

目前，我正在使用一個分散式系統並且它沒有使用任何上述技術。這個分散式系統執行的很好，雖然它不完美，但是它的確實現了。這就引發我思考分散式框架是否是必須的。實際上，MapReduce和Streaming框架的真正區別是什麼?資料通過不同的處理流程式列化，這僅僅是如何將資料連結到一起以及不同處理流程發出資料頻率的問題。

因此，也許我們真正需要的是規範化如何讓各種處理流程並存以及如何將它們連結在一起。我相信我們可以通過一些現有的技術來做到這一點。Mesos 和Kubernetes可以在一個叢集中用來執行處理流程。佇列化技術例如Kafka和NSQ能夠在不同的處理流程間傳遞訊息。處理流程可以使用不同的語言實現，並且可以通過Docker或者類似產品封裝在容器中來管理其依賴。

我個人發現這種方式是比較合適的，這種解決方法聚焦在不同處理流程之間的通訊問題。通過制定相關的協議，我相信可以將不同的處理流程解耦合。同樣，當需要時分析過程中使用到的技術也能更加容易地置換出來。舉個例子來說，Python能夠用來塑造一個分析原型，當效能成為更為嚴重的問題時，它可以使用編譯型語言D或者Go進行重寫。當相同的處理流程無需修改程式碼就可以適用於流式處理和批量處理或者MapReduce任務時，我們也能從中獲得更好的重用性。

當然，這只是一個粗略的想法，也沒有覆蓋這些系統的所有案例和各個方面，但我相信這是一個好的開始。我更加希望看到的是有個工程能夠更加深入地研究下去，並且能夠為這些系統制定一份詳細說明書。如果需要，這種方法可以按照詳細說明書提供執行庫來確保相容性，也許更重要的是描述在一個相容性問題的事件中該做什麼。

本文作者：肖遠昊

來源：51CTO