架構
要了解乙個系統，一般都是從架構開始。我們關心的問題是：系統部署成功後各個節點都啟動了哪些服務，各個服務之間又是怎麼互動和協調的。下方是 flink 集群啟動後架構圖。
當 flink 集群啟動後，首先會啟動乙個 jobmanger 和乙個或多個的 taskmanager。由 client 提交任務給 jobmanager，jobmanager 再排程任務到各個 taskmanager 去執行，然後 taskmanager 將心跳和統計資訊匯報給 jobmanager。taskmanager 之間以流的形式進行資料的傳輸。上述三者均為獨立的 jvm 程序。
可以看到 flink 的任務排程是多執行緒模型，並且不同job/task混合在乙個 taskmanager 程序中。雖然這種方式可以有效提高 cpu 利用率，但是個人不太喜歡這種設計，因為不僅缺乏資源隔離機制，同時也不方便除錯。類似 storm 的程序模型，乙個jvm 中只跑該 job 的 tasks 實際應用中更為合理。
graph
flink 中的執行圖可以分成四層：streamgraph -> jobgraph -> executiongraph -> 物理執行圖。
這裡對一些名詞進行簡單的解釋。
jobgraph：streamgraph經過優化後生成了 jobgraph，提交給 jobmanager 的資料結構。
executiongraph：jobmanager 根據 jobgraph 生成executiongraph。executiongraph是jobgraph的並行化版本，是排程層最核心的資料結構。
物理執行圖：jobmanager 根據 executiongraph 對 job 進行排程後，在各個taskmanager 上部署 task 後形成的「圖」，並不是乙個具體的資料結構。
那麼 flink 為什麼要設計這4張圖呢，其目的是什麼呢？spark 中也有多張圖，資料依賴圖以及物理執行的dag。其目的都是一樣的，就是解耦，每張圖各司其職，每張圖對應了 job 不同的階段，更方便做該階段的事情。我們給出更完整的 flink graph 的層次圖。
首先我們看到，jobgraph 之上除了 streamgraph 還有 optimizedplan。optimizedplan 是由 batch api 轉換而來的。streamgraph 是由 stream api 轉換而來的。為什麼 api 不直接轉換成 jobgraph？因為，batch 和 stream 的圖結構和優化方法有很大的區別，比如 batch 有很多執行前的預分析用來優化圖的執行，而這種優化並不普適於 stream，所以通過 optimizedplan 來做 batch 的優化會更方便和清晰，也不會影響 stream。jobgraph 的責任就是統一 batch 和 stream 的圖，用來描述清楚乙個拓撲圖的結構，並且做了 chaining 的優化，chaining 是普適於 batch 和 stream 的，所以在這一層做掉。executiongraph 的責任是方便排程和各個 tasks 狀態的監控和跟蹤，所以 executiongraph 是並行化的 jobgraph。而「物理執行圖」就是最終分布式在各個機器上執行著的tasks了。所以可以看到，這種解耦方式極大地方便了我們在各個層所做的工作，各個層之間是相互隔離的。
flink學習 flink架構
flink結構 graph 2個併發度 source為1個併發度 的sockettextstreamwordcount四層執行圖的演變過程 jobgraph streamgraph經過優化後生成了 jobgraph，提交給 jobmanager 的資料結構。executiongraph jobman...
flink架構介紹
flink作為基於流的大資料計算引擎，可以說在大資料領域的紅人，下面對flink 1.7的架構進行邏輯上的分析並和spark做了一些關鍵點的對比。如圖1，flink架構分為3個部分，client，jobmanager 簡稱jm 和taskmanager 簡稱tm client負責提交使用者的應用拓撲...
OpenCart 架構概覽
opencart是乙個 設計精緻小巧的電子商務系統。written by iefreer founder of techbrood.com 1 mvc架構 opencart是基於mvc正規化的。model層負責獲取資料。和其他一些框架如cakephp相比，model的功能實現有限但簡潔，直接呼叫db...