Spiral在Facebook通過實時機器學習自動調節服務
【51CTO.com快譯】對於使用Facebook的數十億人來說，我們的服務可能看起來就像一個統一的移動應用系統或網站。從公司內部來看，情況卻不一樣。Facebook使用成千上萬的服務構建而成，從均衡網際網路流量、對影象進行轉碼處理到提供可靠的儲存，功能不一而足。Facebook作為整體的效率在於結合了各項服務的效率，每項服務通常都以自己的方式加以優化，採用的方法可能很難推廣開來或適應快節奏的變化。
為了更有效地優化眾多服務，可以靈活地適應不斷變化、相互聯絡的內部服務，我們開發了Spiral。Spiral這種系統充分利用實時機器學習的技術，在Facebook這等規模的環境下自動調節高效能的基礎設施服務。由於用Spiral取代了手工調節的啟發法，我們可以在短短几分鐘內而不是幾周內優化更新後的服務。
應對規模挑戰的新方法
在Facebook，變化的步伐很快。Facebook程式碼庫每隔幾個小時被推送到生產環境――比如 ofollow,noindex" target="_blank">前端的新版本 ，這是我們持續部署過程的一部分。當下變化萬千，試圖手動微調服務以保持峰值效率不切實際。手動重寫快取/許可/驅逐（caching/admission/eviction）策略及其他手動調節的啟發法實在太難了。我們必須從根本上改變原有的軟體維護觀念。
為了有效地克服這個難題，系統需要變成自動調節，而不是依賴手動硬編碼的啟發法和引數。這種轉變促使Facebook的工程師們以新的眼光看待工作：工程師們現在不再檢視系統生成的圖表和日誌以驗證正確高效的執行，而是用程式碼表達系統怎樣才算正確高效地執行。今天，我們的工程師通過程式設計實現向自我調節系統提供反饋的方法，而不是指定如何計算請求的正確響應。
傳統的快取策略看起來像是帶有分支的樹，考慮到了物件的大小、型別及其他元資料，從而決定要不要快取它。自動調節快取將以不同的方式來實現。這種系統可以檢查某物件的訪問歷史記錄：如果之前從未訪問過該物件，快取它可能是個壞主意。在機器學習語言中，使用元資料（特徵）和相關反饋（標籤）來區分物件的系統將是“分類器”（classifier）。該分類器將用於針對進入快取的物件做出決策，系統將持續被重新訓練。這種持續的重新訓練讓系統得以在即使環境發生了變化也能保持時效性。
從概念上來講，這種方法類似宣告性程式設計。SQL就是這種方法的一個典型案例：工程師不用指定如何計算複雜查詢的結果，只要指定需要計算的內容，然後引擎就會找出最佳查詢並執行查詢。
對系統使用宣告性程式設計的挑戰在於，確保正確完整地指定目標。與上述的自動調節影象快取策略一樣，如果什麼物件應該快取、什麼不應快取方面的反饋不準確或不完整，系統會很快學會提供不正確的快取決策，這會降低效能。
幾位谷歌工程師撰寫的這篇論文（https://storage.googleapis.com/pub-tools-public-publication-data/pdf/43146.pdf）詳細介紹了這個問題以及與使用閉環機器學習有關的其他問題。根據我們的經驗，精準定義自動調節所需的結果是入手Spiral方面最棘手的部分之一。然而我們還發現，幾次迭代之後，工程師往往在清晰正確的定義上觀點一致。
Spiral：易於整合和實時預測
為了讓Facebook的系統工程師能夠跟上越來越快的變化步伐，Facebook波士頓辦事處的工程師們構建了Spiral，這是一個小巧的嵌入式C++庫，依賴項極少。Spiral使用機器學習為資源受限的實時服務建立資料驅動的反應式啟發法。與手工編碼的替代方法相比，該系統大大加快了開發和自動維護這些服務的速度。
與Spiral整合包括只需為程式碼新增兩個呼叫點（call site）：一個用於預測，一個用於反饋。預測呼叫點是用於做出決策的智慧啟發法的輸出，比如“應該許可該條目進入快取嗎？”預測呼叫作為快速本地計算來實現，旨在針對每個決策來執行。
圖1
反饋呼叫點用於提供偶爾的反饋，比如“該條目因根本未命中而失效退出快取，所以我們可能不應該快取這樣的條目。”
圖2
庫可以在完全嵌入的模式下執行，或者可以向Spiral後端服務傳送反饋和統計數字，該後端服務可顯示用於除錯的實用資訊，將資料記錄到長期儲存供以後分析，以及執行訓練和選擇模型方面的繁重任務，這些模型在嵌入模式下訓練起來太耗費資源，但執行起來並不太耗費資源。
圖3
傳送到伺服器的資料採用反偏差取樣，避免類別不平衡偏差滲入到樣本中。比如說，如果一段時間內我們收到的負樣本比正樣本多1000倍，我們只要將1000個負樣本中的1個記錄到伺服器，同時表示它的權重為1000。伺服器深入瞭解資料的全域性分佈，通常帶來比任何一個節點的本地模型更好的模型。除了連結到庫和使用上面兩個函式外，這一切都不需要任何設定。
在Spiral中，一旦反饋進入，學習就開始。隨著生成的反饋越多，預測質量會逐漸提高。在大多數服務中，可在幾秒鐘到幾分鐘內獲得反饋，所以開發週期很短。主題專家可以新增新的特徵，在幾分鐘內看看它是否有助於改進預測質量。
與硬編碼的啟發法不同，基於Spiral的啟發法可以適應不斷變化的條件。以快取許可策略為例，如果某些型別的條目不太頻繁地請求，反饋將重新訓練分類器，以減小在不需要人為干預的情況下許可這類條目的可能性。
案例研究：反應式快取啟發法實現自動化
Spiral的第一個生產級用例恰好吻合Phil Karlton的著名引言：“電腦科學界只有兩個難題：快取失效和命名。”（我們已為自己的專案取了貼切的名稱，所以我們實際上使用Spiral立即解決了快取失效。）
在Facebook，我們推出了一個反應式快取，以便Spiral的“使用者”（我們的其他內部系統）訂閱查詢結果。從使用者的角度來看，該系統提供查詢結果和針對該結果的訂閱。只要外部事件影響查詢，它自動將更新後的結果傳送到客戶端。這為客戶端減輕了輪詢的負擔，並減輕了計算查詢結果的Web前端服務的負載。
使用者提交查詢時，反應式快取先將查詢傳送到Web前端，然後建立訂閱，快取並返回結果。除了原始結果外，快取還收到計算結果時涉及的物件和關聯列表。然後，它開始監控針對查詢訪問的任何物件或關聯源源不斷的資料庫更新。每當它看到可能影響其中一個活躍訂閱的更新，反應式快取會重新執行查詢，並將結果與快取內容進行比較。如果結果確實發生變化，它將新結果傳送到客戶端，並更新自己的快取。
該系統面臨的一個問題是，有大量的資料庫更新，但只有很小一部分影響查詢的輸出。如果某個查詢想知道“我的哪些朋友贊過此帖？”，沒必要獲得“該帖最近一次檢視”方面的持續更新。
這個問題類似垃圾郵件過濾：面對一封郵件，系統應該將它分類成垃圾郵件（不影響查詢結果）還是非垃圾郵件的正常郵件（確實影響查詢結果）？第一個解決方法是，手動建立靜態黑名單。這是可行的，因為反應式快取工程團隊認識到超過99%的負載來自一小組查詢。對於低容量查詢而言，他們只是假設所有更新都是正常郵件，重新執行查詢，以便物件的每次更新被查詢引用。針對一小組高容量查詢，他們建立了黑名單，為此精心觀察查詢執行，確定每個物件中的哪些欄位實際上影響了查詢的輸出。對於每份黑名單，這個過程通常需要工程師花幾周時間。使情況進一步複雜化的是，這一組高容量查詢在不斷變化，因此黑名單很快過時了。每當使用快取的服務改變它所執行的查詢，系統就要改變垃圾郵件過濾策略，這需要工程團隊更多的工作量。
一種更好的解決方案：Spiral垃圾郵件過濾
重新執行查詢後，只要將新的查詢結果與舊的查詢結果進行比較，就很容易確定觀察到的更新是垃圾郵件還是正常郵件。該機制用於向Spiral提供反饋，以便它為更新建立分類器。
為了確保無偏差取樣，反應式快取維護並只提供來自一小組訂閱的反饋。快取並不過濾這些訂閱的更新；只要修改了相關物件或關聯，就重新執行查詢。它將新的查詢輸出與快取版本進行比較，然後用它來向Spiral提供反饋――比如說，告訴它更新“上一次檢視”並不影響“點贊數”。
Spiral從所有反應式快取伺服器收集該反饋，並用它為每種不同型別的查詢訓練分類器。這些分類器定期推送到快取伺服器。為新查詢建立過濾器或更新過濾器以響應Web層不斷變化的行為不再需要工程團隊的任何手動干預。新查詢的反饋到來後，Spiral會自動為那些過濾器建立新的分類器。
Spiral：更快的部署和更多的機會
使用一種基於Spiral的快取失效機制，反應式快取中支援新查詢所需的時間從幾周縮短到幾分鐘。在Spiral之前，反應式快取工程師必須通過執行實驗和手動收集資料來檢查每個新查詢的副作用。但是有了Spiral，大多數用例（對映到查詢）可由本地模型在幾分鐘內自動學習，所以可以立即獲得本地推斷。
對於大多數用例而言，伺服器能夠在10到20分鐘內使用來自多臺伺服器的資料訓練模型。一旦釋出到所有單臺伺服器，這個更高質量的模型可用於精準度改進的推斷。查詢更改後，伺服器能夠適應變更，一旦收到更新後的查詢，就重新學習新的重要性模式。
我們繼續致力於使後端服務實現自動化，並運用機器學習，以獲得更好的運營體驗。 Spiral未來的潛在應用包括使用貝葉斯優化的連續引數優化、基於模型的控制，以及針對每秒請求數（QPS）很高的實時服務和離線（批量）系統的線上強化學習技術。我們會在今後的帖子中繼續分享我們的工作和成果。
原文標題：Spiral: Self-tuning services via real-time machine learning，作者：Vladimir Bychkovsky、Jim Cipar、Alvin Wen、Lili Hu和Saurav Mohapatra
【51CTO譯稿，合作站點轉載請註明原文譯者和出處為51CTO.com】
【責任編輯：龐桂玉 TEL：（010）68476606】