想象乙個裝置網路，包括許多交換機、路由器、閘道器伺服器、radius
伺服器，等等。如果要集中式的監控各個裝置的工作狀態，就需要在網路中部署乙個網路裝置管理系統。從網管系統側看來，所有裝置都直接或間接與之相連，並通過各種可達的通訊協議，諸如但不限於snmp
，定時或不定時的不間斷的報告各自當前或歷史和工作狀態相關的資料。網管系統需要對所獲得的裝置資訊進行計算，以維護和重新整理系統內部用於表徵實際裝置的模型物件(
該物件可能會包括至少乙個有限狀態機，和若干統計量)
，所有抽象物件構成乙個對映實際網路的裝置拓撲模型，這是系統實現裝置管理和監控的基礎。
就裝置資訊的計算而言，可能會有如下特徵： l
計算必須迅速，以保證分析結果的時效性； l
同一時間切片上的資料量可能很大，主要取決於網路規模的大小； l
基於前面兩點，我們會考慮採用平行計算提高資料處理速度。而且不同裝置產生的資料的處理不具有相關性，在保證時效性的前提下，對它們的處理順序的改變不會影響計算結果。這是得以採用平行計算的前提； l
但是同一裝置的資料產生在時間上是有序的；網管系統對其處理順序也需與其一致，否則可能會影響計算結果(
後面將舉例說明這點)
。所以時序相關的資料計算必須保證被偏序執行－比如序列計算； l
而且每個裝置的資料隨著時間的推移理論上是個無限集，它可以對映為正整數集(
以系統執行後收到的該裝置第乙份資料為d(1)
，第二份為d(2)
，依此類推)
。所以要在全集上進行重新排序然後再處理，是不可能的； l
網管系統資料獲取介面通常為乙個或幾個，和實際網路中的裝置形成一對多的關係。也就是說每個介面獲取的資料並不必然來自乙個裝置，必須在處理它們前分析其相關性，以決定何種計算方式。
在此舉乙個簡化了的例子來說明考慮資料處理時序相關特徵的重要性。想象只有正常、故障兩種狀態的乙個裝置。和該裝置狀態相關的只有一種告警資訊，狀態轉換和事件的關係如圖1
所示。假設裝置目前在正常狀態下，先產生乙個「告警產生」事件，緊接著又產生乙個「告警消除」事件，裝置應該最終仍舊處於正常狀態。但由於某種原因，第二個事件先於第乙個事件被處理，這種情況下，由於裝置當前狀態為正常，它會丟棄「告警消除」事件，然後「告警產生」事件會將裝置轉變為故障狀態。
圖1
網路裝置狀態機簡化示例
為了便於推演，使本文的討論適用於同一類問題，這裡試著對問題進行一般性歸納，以確保後面的討論是在問題的一般性特徵基礎上，而不是基於具體的網管問題。
處理物件資料(target data)
是從資料來源(
裝置)到處理機(
網管系統，後面詳細討論)
，供處理機運算的資訊。假設集合v=
是資料來源提供的所有n
個描述自身的資料指標(
或稱變數)
的全集。則每乙個具體的資料訊息d=
包含了v
的乙個子集的指標值，可能各有差異。但對於每乙個d
，必須包含可以用於計算相關性的指標，可以稱為相關鍵(correlativity key)
；以及標識其時序特徵的指標，可以稱為資料的時間標籤(timestamp)。
相關鍵(correlativity key)
任意兩個資料d, d』
correlativity
(d, d』) ∈
其中1表示全相關，0
標識不相關。並非d
中所有指標都需參與相關性計算，而是乙個子集，可以稱為相關鍵。在前面討論的問題中，來自同乙個裝置的資料相關，否則就不相關。相關鍵就是標識資料來源身份的指標，比如裝置id
，裝置ip
，或者裝置的mac
位址等。要注意具體問題中，相關鍵並不一定都由單指標組成，如果上述裝置網路跨多個區域網，裝置只有內網ip
位址，考慮到屬於不同區域網裝置的ip
位址可能重複，用裝置ip
但不論相關鍵ck
簡單或複雜，為了解決問題的方便，我們可以尋找一種對映關係cf
，將ck
對映到乙個相關因子(correlativity factor)
集i上，使得
i = cf (ck(d)), i ∈i
i可以是正整數(
或整數)
子集，在網管問題中，給每乙個裝置編號，即形成裝置id
，就是一種簡單可行的cf
對映關係。
這樣，資料相關性判斷就可以歸結為相關因子的比較：
correlativity
(d, d』) = (i = = i』 ? 1 : 0)
這裡並非為了故弄玄虛。相關鍵的歸納是為了讓討論適用於可能更多的問題，而不僅僅侷限於網路裝置網管資料處理。相關因子的引入則是為了後面排程演算法的簡化－以相關因子作為輸入的排程演算法不用再考慮隨具體情況變化的相關鍵，更具有通用性。
時間標籤(timestamp)
和時序索引(chronologic index)
在許多具體問題中，資料本身就帶有其產生的時間，可以稱為內建時間標籤(inline timestamp)
，比如網管問題中的告警、心跳資訊、話單資料等。但內建時間標籤並不見得可用。考慮到其它具體問題中，時序相關的資料不見得一定要來自同一物理源，所以可能會出現有的資料有內建時間標籤而有的沒有的情況。或者即便有，由於不同源，它們的標準可能不一樣(
比如和不同的ntp
伺服器同步，甚至是系統時間)
，從而不具有可比性。
另乙個選擇就是資料到達處理器的時間，或稱提交時間。雖然提交時間順序並不總是和資料的本質時序嚴格一致，但實際應用證明，提交時序通常能比較好的反應資料的本質時序。在沒有更好的選擇的前提下，採用提交時序不失為一種次優的選擇，而且可以簡化問題的解決(
將在後面討論)。
在具體問題的解決過程中，我們並不一定(
有時也會，將在後面討論)
關心資料的時間標籤(ts)
，而更關心基於時間標籤的資料順序。在此引入時序索引j = ci ( ts(d) )
，對於任意兩個時序相關的d, d』
，如果ts(d) < ts(d』)
，則可以j < j』
，時序索引可以落在乙個正整數(
或非付整數)
集合j上。資料的時序索引可以讓我們知道先處理哪個，後處理哪個－當然，如果它們時序相關的話。
時序相關(chronologically correlative)
在此需要專門強調的是，時序相關並非資料的固有特徵，即便它們包括了時間標籤，時序相關取決於資料處理的業務邏輯或處理演算法(
前面我們表述為資料處理的時序相關的，或者資料針對具體處理演算法的相關性)
。比如，前面的網管問題中，同樣是以裝置告警為物件資料，告警次數的統計就是非時序相關的，而基於告警的裝置狀態計算就可能是時序相關的了。
任務(task)
和處理器(processor)
加速資料處理的解決方案就是對資料處理的流程進行劃分，分解成小任務，再對映到處理器上，實現平行計算甚至分布式計算。這裡所說的處理器並非物理上的，而是虛擬處理器，如執行緒(thread)
，不跨或跨物理邊界的程序(intra/inter-box process)
。對於離散的到達處理器的每乙份資料dij
，可以定義對應的處理任務taskij
，其中i
指任務的相關因子，j
則是基於相關因子的任務時序索引值，如前所述。
鑑於平行計算中任務間的偏序關係可以用有向無環圖dag(directional acyclic graph)
描述，刻畫任務時序相關關係的dag(t, e, a, d)
是乙個如圖2
所示的特殊距陣：
圖2
時序相關任務距陣
其中t =
為任務集，e =
為任務間時序關係集合。a =
為任務計算量集合，d =
是對應任務的通訊量。
在執行過程中，任務間的通訊方式依賴於虛擬機器型別，比如可以採用佇列、共享記憶體，套接字連線等，實現技術都很成熟，這裡不展開討論。時序相關任務解決方案要回答的問題主要有兩個： l
怎樣組織虛擬處理器。處理器拓撲結構也可以用乙個dag
表示。
l將任務dag
對映到虛擬器dag
，即任務排程演算法，將每乙個任務分配給乙個確定的處理器執行。
js相關問題的解決方案
1 ie9 button 超連結 無效解決方案 nclick this.parentnode.click 很關鍵 3 js將選擇的時間與當前時間比較 var str 2012 08 12 23 13 15 str str.replace g,var date new date str var cur...
多版本（ 30）並行控制的解決方案
之前也寫了和轉了一些解決方案，發現並沒有乙個能完全符合自己需求的方式，於是在現有的方案中取各家精華，盡量規避各種坑，形成了現在的管理模式，可以看做 是 fork 機制的另一種實現方式。fork 是同乙個賬戶只能 對同乙個專案 fork 一次，無法滿足我的要求 單版本庫多分支簡直滅絕人性，分支數量多到...
pyspark提交任務依賴模組的解決方案
spark submit deploy mode client driver memory 2g executor memory 2g executor cores 3 num executors 3 properties file etc spark conf spark defaults.con...