大資料/新聞媒體的實用DevOps

用例描述

新聞和媒體領域在處理來自社交媒體的大量資料流方面是一個要求很高的行業。ATC SA作為全球領先的新聞和媒體領域ICT應用品牌之一，開發了NewsAssset——一款定位於新聞和媒體領域的商業產品。NewsAsset是一款定位於新聞和媒體領域的商業產品，由位於希臘的SME雅典技術中心（Athens Technology Center）品牌化。NewsAsset套件構成了一種創新的資訊管理解決方案，為新聞生產環境中敏感資訊的儲存、管理和交付提供了一個完整且安全的電子環境。該平臺提出了一種分散式多層架構引擎來管理資料儲存，該引擎由媒體專案組成，例如文字、影像、報告、文章、影片等。創新的軟體工程實踐，如大資料技術、模型驅動工程（MDE）技術、雲計算流程和麵向服務的辦法已經滲透到媒體領域。新聞機構已經感受到了這些技術提供的功能帶來的影響（例如處理能力、資訊的透明分發、複雜的分析、快速響應等），促進了下一代產品、應用和服務的開發。特別是考慮到數字世界中存在的有趣的媒體和突發事件，這些技術可以提供高效的處理併為記者提供附加值。同時，像社交網路、感測器網路和與網際網路連線的其他一些舉措等異構來源正在以驚人的速度持續不斷地向網際網路世界提供各種真實資料：描述突發事件的媒體專案、道路上的交通速度；下雨或下雪時道路的溼滑指數；按位置劃分的空氣汙染水平；等等。隨著越來越多的此類來源進入數字世界，記者將能夠訪問越來越多的來源的資料，這不僅有助於災難報道，還可以用於各種新聞報道。隨著這種趨勢的發揮，當世界某個地方發生災難時，人們會使用Twitter、Facebook、Instagram等社交網路來觀察新聞生態系統並試圖瞭解損壞的範圍以及即時存在的情況。許多目擊者會拍攝災難照片併發布，解釋正在發生的事情。隨後，新聞機構意識到社交媒體內容對於災難新聞報道變得越來越有用，並且只有在採用上述創新技術的情況下才能從這一未來趨勢中獲益。因此，NewsAsset面臨的挑戰是趕上這一發展並提供能夠處理媒體行業發展新情況的服務。此外，在DICE專案期間，我們確定了“假新聞”領域的一個巨大的商業機會。更具體地說，我們使用DICE工具開發了特定模組（News Orchestrator應用程式的一部分），用於一個新的創新產品，該產品透過API連線到我們的NewsAsset套件或可以作為獨立解決方案出售。這個新產品被稱為TruthNest（www.truthnest.com）。TruthNest是ATC實施的一項服務，用於評估在社交媒體上發現的資訊的可信度。TruthNest使用者能夠捕獲來自社交網路的資料流，然後他們能夠分析單個帖子並根據驗證過程的幾個維度獲得見解。

用例場景

TruthNest是一款線上綜合工具，可以快速準確地發現、分析和驗證在社交媒體中出現的報道事件、新聞和多媒體內容的可靠性和真實性，接近即時。終端使用者可以透過單擊啟用一系列分析事件來實現所需的結果，從而在幾秒鐘內驗證單個帖子的可信度。更具體地說，TruthNest使用者將能夠引入來自社交網路的資料流，然後能夠分析並獲得有關驗證過程的幾個維度的見解。此外，他們還能夠在TruthNest內部建立和監控新的“智慧”資料流。

TruthNest的一個重要模組，該模組是從頭開始開發的，是“趨勢話題檢測器”。“趨勢話題檢測器”為終端使用者提供了一個視覺化環境，顯示了來自社交媒體，更具體地說是來自Twitter的突出趨勢。在此階段需要特別說明的是，只有“趨勢話題檢測器”模組是使用DICE工具開發的，而TruthNest的其他元件則是使用傳統工具和方法開發的，因為這些工具和方法一直被ATC的工程和開發團隊使用。

“趨勢話題檢測器”詳細描述

趨勢話題檢測器以聚類模組為中心。它建立與提交的搜尋條件相關的推文叢集。這些叢集是透過根據推文中的共同術語對找到的推文進行分組來形成的。該模組跟蹤在Twitter上釋出的推文的一部分，因為Twitter流式API存在限制。雖然它目前僅限於Twitter流API，但它可以接收來自多個社交媒體（YouTube、Flickr等）的輸入，但尚未實現。

架構

聚類模組的主管道實現為一個Storm拓撲，其中順序bolt對抓取過程執行特定操作。這些bolt包括實體提取（使用Stanford NER分類器）和minHash計算以估計形成的集合的相似度。推文術語被提取並索引到正在執行的Solr例項中。最常用的術語是在5分鐘的滾動視窗中計算的，並且預設情況下會形成20個叢集。一個標籤（通常是推文的文字）被分配給每個叢集。結果儲存在Mongo資料庫中。該模組高度可配置，並提供叢集的近乎即時的計算。

如何使用聚類模組

使用者透過使用者介面設定搜尋詞。預設語言為英語，其他語言未正式支援。一些趨勢話題叢集計算設定也可用（例如視窗計算時間）。
流程初始化，並通知使用者當前分析的推文數量。顯示一個圖表（折線圖），每隔幾秒鐘更新一次，顯示流進度。如果找到推文，則在10分鐘後顯示第一個趨勢話題叢集。顯示一組20個趨勢話題叢集。趨勢話題叢集是可點選的，使用者可以檢視組成它們的專案。
趨勢話題叢集每五分鐘重新計算一次，其內容也會更新。使用者可以檢視詳細資訊（例如叢集隨時間的演變）。
使用者可以搜尋趨勢話題叢集並標記最重要的叢集。還提供了一個收藏夾過濾器。
使用者可以啟動/停止趨勢話題叢集、編輯和刪除它。他可以儲存趨勢話題叢集並在以後重新啟動它。
建立的趨勢話題叢集的數量及其活動週期存在限制。通常，叢集會在24小時後停止。

DICE工具

DICE工具	對我們用例的益處
DICE IDE	大多數DICE工具計劃逐步整合到一個公共位置（DICE IDE）這一事實使得各種DICE工具之間的互動非常有效，因為大多數工具都依賴於DICE Profile模型。例如，DICE驗證工具需要一個DTSM模型作為輸入，該模型用一些關於NewsAsset DIA並行化水平的質量特徵進行適當的註釋，並且驗證過程可以從DICE IDE內部觸發。這樣，DICE IDE不僅涵蓋了我們DIA的設計時建模需求，而且將結果工件有效地連結到與DevOps方法其他階段相關的工具，例如部署和監控。
DICER	DICER工具使我們能夠表達NewsAsset應用程式的基礎設施需求和約束，並自動生成要在雲環境中使用的部署藍圖。我們根據節省時間（相對於從頭開始手動設定基礎設施所需的時間）和DICER提供的自動化程度來評估DICER工具的實用性。請注意，在計算DICER執行時間總時間時，我們包括了DICE部署服務部署生成的藍圖所需的時間。
部署服務	整個過程非常快速，與之前手動安裝 Storm 叢集及其所有依賴項（Zookeeper 等）以及 Storm 應用程式和持久化層的所有依賴項相比，節省了近 80% 的時間。TOSCA 藍圖允許預先細化 Storm 特定的配置引數，這一點非常方便，因為我們可以透過應用重新配置來嘗試不同的 Storm 叢集設定，從而產生新的測試環境，直到我們找到對我們的拓撲結構而言效能和吞吐量最有效的設定。
監控平臺	能夠監控 NewsAsset 部署的拓撲結構對於識別任何潛在的瓶頸甚至透過例如新增更多並行化來最佳化效能和吞吐量是必要的。我們已經安裝了監控平臺核心模組（ELK 堆疊、DMon 核心），然後我們使用最新部署服務版本的功能之一，在基礎設施/應用程式部署階段自動在監控平臺的核心服務上註冊 Storm 叢集節點。監控不僅可以在每個（Storm 叢集）節點上執行，也可以在每個應用程式級別上執行，這意味著我們可以區分與節點硬體規格相關的問題和與應用程式內部機制相關的問題，例如 Storm 內部訊息緩衝區的大小。
故障注入	由於 NewsAsset 的拓撲結構涉及雲部署，因此在受控環境中儘早地測試故障的後果（而不是在應用程式投入生產後）至關重要。對於 NewsAsset DIA 而言，其組成的拓撲結構必須可靠，因為其執行的處理的性質：例如，如果某個時間點發生突發事件，則由於網路故障/重新分割槽而丟失一些社交網路訊息可能會影響在此期間識別的熱門話題的質量。因此，擁有像故障注入這樣的工具可以幫助我們測試應用程式在可靠性和容錯性方面的表現。NewsAsset 應用程式還需要儘可能消除任何單點故障。我們使用故障注入工具隨機停止/終止各種型別的 Storm 程序（nimbus、supervisor 和 worker 程序），以及 Storm 叢集的整個節點，並檢查這些操作如何影響拓撲結構的正確執行。最後，我們使用故障注入工具為 Storm 叢集 VM 生成高記憶體和 CPU 使用率，以模擬高記憶體/CPU 負載。拓撲結構的各種處理 bolt 並沒有受到太大影響，因為它們都不太依賴 CPU 或記憶體。我們計劃繼續使用故障注入工具進行實驗，特別是模擬高頻寬負載，因為熱門話題檢測拓撲結構大量使用了 Twitter Stream API。
質量測試	質量測試工具的驗證 KPI 指的是手動測試周期所需時間減少 30% 以上。為此，已經執行了計時評估，將 ATC 工程師手動執行拓撲結構壓力測試所需的時間與質量測試工具執行類似任務所需的時間進行了比較。在我們的用例場景中，只有 5 次迭代/實驗實現了目標，並且每個測試周期的減少量達到了 34%。如果需要更多測試周期，則減少量可能會更高。另一個重要的發現是，可以使用質量測試工具完全自動化負載測試過程。
配置最佳化	通常，典型的 Storm 部署包含各種影響 nimbus、supervisor 以及拓撲結構行為的配置屬性。對於開發人員來說，選擇配置屬性的最佳值以微調 Storm 拓撲結構執行是一項非平凡的任務。這通常是該領域專家完成的一項複雜任務。此外，每個基於 Storm 的應用程式都有其自身的特性（I/O 繫結或 CPU 繫結或兩者兼而有之），在嘗試候選最佳值時應仔細考慮這些特性，因此遵循通用的設定模板不是一種選擇。此外，每次嘗試最佳化某些屬性時更新配置並在叢集上重新載入配置所需的開銷和時間都很大。為了評估將配置最佳化工具應用於新聞協調器依賴的 Storm 配置帶來的改進，ATC 工程師監控了拓撲結構的吞吐量和延遲。與預設配置相比，效能影響提高了兩倍以上，這是一個顯著的改進。這一成就是在僅 100 次迭代後實現的，總共執行了 16 個小時（100 * 10 分鐘）。相應的驗證 KPI 已得到充分解決，導致吞吐量和延遲指標均提高了 30% 以上。
模擬工具	可擴充套件性、瓶頸檢測和模擬/預測分析是新聞協調器 DIA 的一些核心需求。DICE 模擬工具承諾它可以執行基於 Storm 的 DIA 的效能評估，這將允許在生產雲環境中部署之前預測系統的行為。新聞協調器工程師經常花費大量時間和精力來根據目標執行時執行上下文配置和調整拓撲結構配置。引入一個可以高效地執行此類要求苛刻任務的工具將明顯提高開發人員的生產力，並促進他們的測試需求。模擬工具的相應驗證 KPI 指的是螺栓利用率的預測誤差小於 30%。應在模擬工具生成的成果與 Storm 框架公開的指標介面監控的成果之間進行比較。透過這種方式，將預測/模擬結果與透過將新聞協調器拓撲結構部署在執行在雲上的 4 個節點的 Storm 叢集上監控到的實際結果進行了驗證。結果表明，對於一些螺栓（大約超過一半），預測誤差確實非常小，小於 10%，可以相當準確地預測螺栓的容量。有趣的是，模擬工具無法預測其容量或至少以可接受的精度預測其容量的螺栓的特徵是什麼。新聞協調器拓撲結構的螺栓工作流程中有一個棘手的部分：一些螺栓不會持續地消費和分析社交專案，而是每當預定義的時間視窗到期時（該時間視窗反映了新聞協調器工程師希望檢測新聞主題的頻率，配置為 5 分鐘）就會觸發其執行。因此，事實證明，對於主題檢測和 minhash 聚類螺栓，平均執行時間難以計算，從而影響了模擬工具結果的精度。此外，其中一些螺栓本質上利用率較低，主要是因為與總實驗時間相比，它們執行的時間有限。在這些情況下，還觀察到模擬工具結果與實際監控值之間的偏差超過了關於預測的 30% 的閾值。對於 ATC 工程師來說，在幫助他們最佳化和評估新聞協調器 DIA 的工具堆疊中擁有像 DICE 模擬工具這樣的工具是一個顯著的優勢。新聞協調器 DIA 中新增的每個新功能都可能導致系統性能方面出現不希望有的不平衡。能夠在實際部署到雲基礎設施之前驗證對 DIA 的效能影響，可以靈活地預先微調拓撲結構配置並採取糾正措施（即透過增加螺栓並行性進行擴充套件），而不會浪費否則實際部署到雲上所需的資源（成本和精力）。