大資料實踐 DevOps/配置最佳化

簡介

找到資料密集型應用程式的最佳配置是一個具有挑戰性的問題，因為影響其效能的引數數量眾多，並且缺乏分析模型來預測更改的影響。為了解決這個問題，DevOps 可以結合調整方法，在這些方法中，實驗者被賦予有限的實驗預算，需要謹慎地分配此預算以找到最佳配置。在本節中，我們將討論一種可以用於在 DevOps 中實現配置最佳化的方法。

動機

一旦資料密集型系統接近其最終的部署階段以交付給終端使用者，調整其效能和可靠性變得越來越重要。調整在初始原型中也可能很重要，以確定可實現效能的界限。在任何一種情況下，這都是一個耗時的操作，因為候選配置的數量可能非常大。例如，最佳化 10 個取 ON/OFF 值的配置選項在最壞情況下需要 1024 個實驗才能確定全域性最優配置。由於資料密集型應用程式可能同時使用多種技術，例如由 Apache Spark 和 Kafka 組成的​​資料分析管道，因此最佳化此類系統的配置變得越來越困難。次優配置意味著某項技術的操作成本更高，並且可能無法提供預期的效能，迫使服務提供商提供額外的硬體資源。因此，DevOps 中需要配置最佳化工具來指導此配置階段，以便快速找到一個接近最佳的配置。

現有解決方案

目前，有一些數學方法和方法可用於尋找最佳配置。

一個經典的數學方法系列是實驗設計 (DoE) 方法，這些方法將非線性多項式擬合到響應資料以預測系統在未探索配置中的響應。此類方法提供了一種在特定情況下減少擬合響應模型所需的實驗數量的方法，例如那些配置選項是二進位制值的配置選項（例如，ON/OFF）。但是，用這些方法很難考慮數十個引數，這些方法通常限於更小的維度（8-10）。

相關方法是在統計學和機器學習中發展起來的方法，用於解決多臂匪問題。這是一個普遍的問題，它抽象地分配了一組有限的資源，而這些資源在可以從決策中獲得的獎勵方面的資訊不完整。這種情況在配置最佳化中很常見，因為事先不清楚改變配置選項的級別將如何影響系統。這裡的關鍵權衡是決定花多少時間用於開發與探索，而前者是指專注於預期收益最大的最佳化選項，而後者是指改進對其他最佳化選項的瞭解以完善對預期收益的估計。本章提出的方法稱為貝葉斯最佳化，屬於此類解決方案技術，並且在選擇這種權衡時提供靈活性。

市場上存在一些用於效能最佳化的商業服務，例如

• PragmaticWorks
• Oracle
• HP
• Centaurea

這些服務部分依賴於顧問的專業知識和技能。這裡追求的解決方案是演算法化的，並且對於大資料框架而言，很少有類似的方法存在。例如，http://unraveldata.com/ 提供了一個大資料管理解決方案，其中包含針對大資料應用程式的自動調整。關於基礎自動調整方法沒有公開資訊，並且該網站相當含糊，表明這不是該產品的主要功能。相反，這裡討論的解決方案完全針對配置，並以基於高斯過程的創新方法為特色，這些方法在實驗上已被證明比科學技術水平更有效。

工具工作原理

配置最佳化 (CO) 使用 DevOps 工具鏈迭代地對大資料應用程式進行測試。在每次迭代中，使用負載生成器測試新的配置，並收集效能資料。此資料用於訓練機器學習模型，以決定在下次迭代中評估系統的配置。使用此決定，測試迴圈將迭代進行，直到找到滿足效能目標的配置。

對於測試系統而言，挑戰在於定義一種有效的搜尋演算法，該演算法可以自動決定要執行哪些實驗以快速調整系統。調整系統所需的實驗越少，該過程就越具有成本效益。主要問題是系統行為難以預測，因此配置引數對效能的影響在負載測試在該引數更改後在應用程式上進行之前可能未知。

BO4CO 是在 DICE 中生產的 CO 的實現，它專注於基於稱為貝葉斯最佳化的技術來最佳化配置。貝葉斯最佳化是一種用於黑盒全域性最佳化的機器學習方法。在此方法中，使用高斯過程 (GP) 對系統對新配置的未知響應進行建模，高斯過程是機器學習模型的重要類別。GP 用於預測平臺對配置更改的響應。GP 可以考慮與測量相關的平均值和置信區間，預測系統在未探索配置中的行為，並且可以快速重新訓練以適應新資料。更重要的是，貝葉斯最佳化方法在真實系統上的速度可能比任何現有的自動調整技術都快得多。

CO 方法學步驟

CO 工具的邏輯是迭代的。配置最佳化器在每次迭代中自動選擇一個配置，使用 BO4CO 演算法確定在過程中下一個要測試的最佳配置。BO4CO 使用觀察到的效能資料來估計系統的響應曲面。它使用估計的資料選擇下一個要測試的配置，尋找有很大機會成為最佳配置的點。這在下面圖的左側進行了說明，該圖顯示了將這些步驟定義為配置最佳化過程的步驟。

使用 DICE 最佳化大資料應用程式的配置

上面圖的右側提醒了一個重要事實，即基於 GP 的響應模型提供了查詢應用程式在未測試配置中的效能的能力，從而提供了一種引導 CO 搜尋的機制。特別是，在進行新的測試後，可以評估模型的準確性並向其提供新的觀察結果，以改進其準確性以供將來使用。在該方法的 DICE 實現中，除了基於 GUI 的配置選項邊界規範之外，還支援自動執行 GP 的訓練和預測。

開放挑戰

原則上，諸如 CO 之類的方法也適用於遷移問題，但目前它僅在最佳化新的資料密集型應用程式的背景下使用。許多公司和公共部門組織正在逐步將其應用程式遷移到新興的大資料框架，例如 Spark、Cassandra、Storm 和 Hadoop。可以預見三個研究挑戰

1. 基於機器學習的自動調整方法沒有針對單個大資料技術進行定製，導致實驗時間和成本不理想，特別是當我們將多個託管技術一起使用時，情況會更糟。
2. 效能自動調整缺乏在工業大資料環境中的驗證，當前的研究集中在學術和實驗室測試平臺上。
3. 大資料需要持續的自動調整，因為工作負載強度和資料量在不斷增長。

應用領域

Storm 配置

CO 方法論已經在中針對不同的 Apache Storm 拓撲進行了測試。與預設值相比，CO 找到最佳配置時，對 Storm 拓撲配置和端到端延遲（作業到達拓撲的時間戳與作業完成處理並離開拓撲的時間戳之差）的改進幅度高達 3 個數量級。研究表明，該工具僅在最初的 100 次迭代中就找到了最佳配置。在本實驗中，配置引數的全因子組合為 3840，100 次實驗等於總實驗的 2%。請注意，為了衡量配置最佳化工具找到的最佳配置與預設配置之間的差異，我們進行了全因子實驗（即，每個實驗 8 分鐘，共 3840 個實驗，總計 3480*8/60/24=21 天）。在中可以找到更多針對真實社交媒體平臺的應用。

Cassandra 配置

在中也進行了一項驗證研究，旨在最佳化 Cassandra 讀取延遲。還考慮了 BO4CO 演算法的一種變體 TL4CO。TL4CO 將一種稱為遷移學習的技術整合到貝葉斯最佳化方法中，該技術允許重複使用來自過去配置最佳化週期的歷史資料以加速新的配置週期。有關 TL4CO 的更多詳細資訊，請參見。實驗收集了 20 個引數配置空間中讀取和寫入操作的延遲與吞吐量測量值。由 CO 工具（使用 TL4CO 和 BO4CO 演算法）找到的配置、預設設定以及專家建議的配置都已標註。結果表明，使用 TL4CO 初始化的 CO 工具僅在 20 次迭代後找到的配置，與專家建議的配置相比，延遲略低，但吞吐量高得多。

結論

本章討論了自動最佳化資料密集型應用程式配置的問題。Storm 等技術體現了這一挑戰，因為它們需要共同最佳化幾十個配置引數，而對每個引數級別如何與其他引數互動並沒有很好的理解。CO DevOps 工具說明了一種可能的解決方案。進行迭代實驗，直到找到最佳配置。貝葉斯最佳化是一種黑盒最佳化技術，與統計學中常用的實驗方法（如響應面和實驗設計）相比，可以大大加快配置任務。