【原文編者的話】本文主要講述了通過規範化處理流程，可以使用相同的處理流程來處理流式或者批量處理任務，例如hadoop和storm，從而提高重用性。
當有人問起該如何處理大資料問題時，他們總是被指引到現存的產品中，例如hadoop或者storm。雖然這些產品非常棒，但也引發了一些問題。首先，就我個人的經驗來看，為了獲得最佳的處理結果，你必須使用這些框架首選的語言或者虛擬機器編寫你的**，典型的就是jvm。當語言或者虛擬機器不適用時，就意味著你必須重寫你的**來適應這些框架。同樣，像hadoop和storm這兩種框架所做的事情非常不一樣，這就給**的重用增加了更大的困難。如果你想做流式和批量處理分析，你就需要這兩種框架。當然，有些方法能夠做到這一點，但我不清楚這種方法是否有更多的選擇性，或者這種方法是否很難進行維持。
目前，我正在使用乙個分布式系統並且它沒有使用任何上述技術。這個分布式系統執行的很好，雖然它不完美，但是它的確實現了。這就引發我思考分布式框架是否是必須的。實際上，mapreduce和streaming框架的真正區別是什麼?資料通過不同的處理流程序列化，這僅僅是如何將資料鏈接到一起以及不同處理流程發出資料頻率的問題。
因此，也許我們真正需要的是規範化如何讓各種處理流程並存以及如何將它們鏈結在一起。我相信我們可以通過一些現有的技術來做到這一點。mesos 和kubernetes可以在乙個集群中用來執行處理流程。佇列化技術例如kafka和nsq能夠在不同的處理流程間傳遞訊息。處理流程可以使用不同的語言實現，並且可以通過docker或者類似產品封裝在容器中來管理其依賴。
我個人發現這種方式是比較合適的，這種解決方法聚焦在不同處理流程之間的通訊問題。通過制定相關的協議，我相信可以將不同的處理流程解耦合。同樣，當需要時分析過程中使用到的技術也能更加容易地置換出來。舉個例子來說，python能夠用來塑造乙個分析原型，當效能成為更為嚴重的問題時，它可以使用編譯型語言d或者go進行重寫。當相同的處理流程無需修改**就可以適用於流式處理和批量處理或者mapreduce任務時，我們也能從中獲得更好的重用性。
當然，這只是乙個粗略的想法，也沒有覆蓋這些系統的所有案例和各個方面，但我相信這是乙個好的開始。我更加希望看到的是有個工程能夠更加深入地研究下去，並且能夠為這些系統制定乙份詳細說明書。如果需要，這種方法可以按照詳細說明書提供執行庫來確保相容性，也許更重要的是描述在乙個相容性問題的事件中該做什麼。
分布式 常見分布式框架
分布式協調系統 日誌複製系統 paxos演算法及其變體的實現，典型的有zookeeper etcd 分布式檔案系統 hdfs hadoop 分布式nosql redis hbase 訊息佇列 rabbitmq kafka，關注訊息的at least once，at most once，only on...
複習 分布式框架
springcloud與dubbo可以實現rpc遠端呼叫框架,可以實現服務治理 相同點 springcloud是一套目前比較全面 不同點 的微服務框架,整合了分布式常用的解決方案 文件 eureka 工作原理 eureka與zookeeper的差別 技術角度 dubbo 工作原理 ribbon 原理...
分布式框架 dnmap
dnmap是乙個用python語言寫的分布式掃瞄的nmap掃瞄框架，我們可以用dnmap來通過多台機器發起乙個大規模的掃瞄，dnmap採用c s 結構，執行大量掃瞄任務時非常便捷，掃瞄結果可以統 一管理。使用者在伺服器端設定好nmap工具執行的命令，dnmap框架會自動地分配給客戶端進行掃瞄，並將掃...