分布式多電腦調度平台

標籤：

方案：

1，） 目前我們的程式，單獨一台電腦一天分析100G以內的xml資料，有選擇的將需要的資料入庫資料庫（sqlserver2008 r2 64）記錄近1億左右，一台128G記憶體，32核的電腦勉強能完成任務；

2，） 隨著市場的擴充，我們拿到的資料量一天的資料就有1T左右的xml資料，單台電腦運行已經分析完成時間成為了瓶頸，可能需要十天或者更長的時間。

解決方案：

為了能夠讓我們的產品能有更強的生存力，吸引到更多的使用者；項目組就有了這麼一個討論：

方案1，）使用hadoop對這種大資料處理，但由於目前公司針對hadoop技術瞭解深度有限，正常應用到產品中還需要一段時間，因此hadoop方案只作為實施層級比較低，但不太表我們不會做，時間的問題。

方案2，）基於我們目前的平台進一步擴充，怎麼擴充？

   2.1，)讓我們的工具在多個電腦運行，把任務拆分到不同的計算進行運行。假設1T的資料，我們有10電腦，每台給平均分發100G的資料，這樣對資料庫及電腦的壓力會減少少多，橫向擴充是我們目前不能立即上線的一個必行方案；

   2.2，)工具擴充後，儲存資料庫也一定需要擴充，每台電腦最好能對應一台儲存資料庫，對業務實現及資料庫壓力減負，都有好處。

   2.3，)對資料庫擴充後，應用端怎麼合并資料就成為了一個必須不可不考慮問題。那麼我們計劃怎麼處理合并呢？首先，每台計算節點上的伺服器在插入必要資料的同時，更具業務需求將必須要的資料插入到摘要資料庫中，而詳細資料只儲存到對應的計算節點對應的資料庫中，應用端直接存取資料庫為摘要資料庫，但查看某條資訊的具體資訊時，可以從該條資訊中找到具體資訊儲存的資料，進而從對應的資料庫中拿到詳細資料。

決定：

方案2已經通過了調研，怎實施？實施有多大難度？技術難題在哪？

其他問題先不說，就談下技術痛點，既然要分布多計算執行，就一定要有一個調度器，而調度器中的痛點大家就都清晰吧------心跳監控任務執行狀態，通訊的穩定性，高效性，準確性，訊息佇列怎麼規劃？

 

分布式多電腦調度平台