2022年1月2日 - Chip Huyen

一年前，我寫了一篇關於《機器學習正在走向實時化》 這篇文章一定是抓住了許多資料科學家的痛點，因為在這篇文章之後，許多公司主動與我聯絡，分享他們的痛點，並討論如何將他們的管道實時化。這些對話促使我成立了一家關於實時機器學習的公司。我們有一些令人興奮的訊息，我迫不及待地想與你分享，但這是另一個故事 :-)

在過去的一年裡，我與不同行業的30家公司討論了他們在實時機器學習方面的挑戰。我還與不少公司合作，尋找解決方案。這篇文章概述了（1）線上預測和（2）持續學習的解決方案，以及每個級別所需的逐步使用案例、注意事項和技術。

根據你的經驗，有些階段對你來說可能是基本的。跳過這些就可以了!

免責宣告：本篇文章中概述的觀點在很大程度上受到我所交談/合作的公司的影響，這些公司主要是科技公司。我們非常感謝您的反饋和建議。

邁向線上預測

雖然我相信我們離持續學習的主流採用還有幾年的時間，但我看到公司為轉向線上推理進行了大量投資。從批處理預測系統開始，我們將討論使用批處理特徵的簡單線上預測系統需要什麼，通常對會話中的適應很有用（例如，根據使用者在網站或移動應用上的會話中的活動給他們預測）。然後，我們將繼續討論如何轉向一個更成熟的線上預測系統，利用複雜的流媒體和批處理特徵。

第一階段：批次預測

在這個階段，所有的預測都是預先計算好的，以一定的時間間隔生成，例如每4小時或每天一次。批次預測的典型用例是協作過濾、基於內容的推薦。使用批次預測的公司的例子有DoorDash的餐廳推薦，Reddit的subreddit推薦，Netflix的推薦大約在2021年。從這篇文章開始，Netflix正在將他們的預測轉移到網上。

批次預測有很多侷限性，正如我在 "我是誰 "中所概述的那樣。我想快速瀏覽一下一個例子。考慮一個電子商務網站，其一半的訪問者是新使用者或沒有登入。因為這些訪問者是新的，所以沒有預先計算好的針對他們的個性化推薦。當下一批推薦生成時，這些訪問者可能已經離開，沒有進行購買，因為他們沒有找到與他們相關的東西。

一個典型的批次預測工作流程

批次預測不是線上預測的先決條件。批次預測在很大程度上是傳統系統的產物。

在過去十年中，大資料處理一直由MapReduce和Spark等批處理系統主導，這些系統允許我們非常有效地定期處理大量的資料。當公司開始使用機器學習時，他們利用現有的批處理系統來進行預測。

如果你今天要建立一個新的ML系統，有可能從線上預測開始。

第二階段：用批次特徵進行線上預測

這個階段的公司不是在請求到來之前產生預測，而是在請求到來之後產生預測。他們實時收集使用者在其應用程式上的活動。然而，這些活動只被用來查詢預先計算的嵌入，以生成會話嵌入。沒有任何特徵是從流資料中實時計算出來的。

考慮前一階段的同一個電子商務網站的例子。當一個新訪客訪問你的網站時，你不是向他們推薦一般的商品，而是根據他們的活動向他們展示商品。例如，如果他們看了一個鍵盤和一個電腦顯示器，他們很可能是在看在家工作的設定，你的演算法應該推薦相關的物品，如HDMI線或顯示器支架。

要做到這一點，你需要收集和處理這個訪問者的活動，因為它們發生了。如果這個訪客看了專案1、專案10和專案20，你就從你的資料倉庫中提取專案1、10和20的嵌入。這些嵌入被結合起來（例如，平均），以建立這個訪客的當前會話嵌入。

你想在這個會話嵌入的情況下找到最相關的專案。直觀地說，你可以有一個模型對你網站上的每一個專案進行排名，並向訪客展示分數最高的專案。然而，你的網站上可能有數以百萬計的專案，對所有的專案進行評分可能需要太長的時間--你不希望你的訪問者永遠等待看到推薦。大多數公司使用另一種演算法，如專案-專案協同過濾和K-近鄰，來生成少量的候選專案（如1000個）來打分。這個生成候選人的過程被稱為 "候選人生成 "或 "檢索"。有興趣的讀者可以看看Eugene Yan的入門書，其中包括 session-based recommendations和 Google’s free crash course.

基於會話的建議的管道例項

嵌入可以與排序模型分開學習，也可以與排序模型一起學習。如果分開，你的系統將至少由三個模型組成：一個用於學習嵌入，一個用於檢索，一個用於排名。

在這裡，我們用一個推薦系統來說明這個階段，但它也可以應用於其他任務，包括廣告CTR、搜尋或任何檢索任務。

基於會話的預測的目標是提高轉換率（如將首次訪問者轉換為新使用者，點選率）和保留率。

已經在做線上推理或將線上推理列入2022年路線圖的公司名單越來越多，包括Netflix、YouTube、Roblox、Coveo等。每一家已經轉向線上推理的公司都告訴我，他們對自己的指標贏得非常滿意。我預計，在未來兩年內，大多數推薦系統將是基於會話的：每一次點選、每一次檢視、每一次交易都將被用來（接近）實時地生成新鮮的相關推薦。

要求

在這個階段，你將需要。

1. 將你的模型從批次預測更新為基於會話的預測。
   這意味著你可能需要新增新的模型。負責團隊：資料科學/ML。
2. 將會話資料整合到你的預測服務中。
   通常情況下，你可以用流處理基礎設施來做這件事，它由兩部分組成。

• 流式傳輸，例如Kafka/AWS Kinesis/GCP Dataflow，以移動流式資料（使用者的活動）。大多數公司使用管理的實時傳輸--自我託管Kafka是件很痛苦的事。
• 一個流計算引擎，例如Flink SQL、KSQL、Spark Streaming，來處理流資料。在會話自適應的情況下，這個流計算引擎負責將使用者的活動劃分為會話，並對每個會話中的資訊進行跟蹤（狀態保持）。在這裡提到的三個流計算引擎中，Flink SQL和KSQL在業界更受認可，併為資料科學家提供了一個很好的SQL抽象。

1. 許多人認為，線上預測在成本和效能方面都不如批次預測，因為批次處理預測比逐一處理預測更有效率。這不一定是真的，正如所討論的
   透過線上預測，你不必為沒有訪問你網站的使用者生成預測。想象一下，你執行的應用程式，只有2%的使用者每天登入 - 例如，在2020年，Grubhub有 31 million users和 622,000 daily orders.
   如果你每天為每個使用者生成預測，用於生成98%的預測的計算將被浪費掉。
   如果你的公司已經使用流媒體進行記錄，這種變化應該不會太陡峭。然而，這可能會給你的流媒體基礎設施帶來更重的工作負荷，這可能需要升級，使其更有效率/可擴充套件。
   負責團隊：資料/ML平臺。
   題外話：與我交談過的一小部分人用 "流式預測 "來指那些利用流式基礎設施進行預測的系統，而用 "線上預測 "來指那些不利用流式基礎設施的系統。在這篇文章中，"線上預測 "包含了 "流式預測"。

挑戰

這一階段的挑戰將是在。

• 推理延遲：對於批次預測，你不需要擔心推理延遲。然而，對於線上預測，推斷延遲是至關重要的。
• 建立流處理基礎設施。許多工程師仍然害怕做 SQL-like joins儘管圍繞它的工具正在成熟。
• 擁有高質量的嵌入，特別是如果你處理不同的專案型別。

第三階段。用複雜的流處理+批次特徵進行線上預測

• 批次特徵是指從歷史資料中提取的特徵，通常採用批次處理。也稱為靜態特徵或歷史特徵。
• 流式特徵是指從流式資料中提取的特徵，通常採用流式處理。也稱為動態特徵或線上特徵。

如果說第二階段的公司需要很少的流處理，那麼第三階段的公司就會使用更多的流處理功能。例如，使用者在Doordash上下單後，他們可能需要以下功能來估計交貨時間。

• 批次特徵：該餐廳過去的平均準備時間
• 流動功能：此時此刻，他們還有多少其他的訂單，有多少配送人員可以使用

在第二階段討論的基於會話的推薦的情況下，而不是僅僅使用專案嵌入來建立會話嵌入，你可能會使用流特徵，如使用者在網站上花費的時間，一個專案在過去24小時的購買次數。

具有流處理特徵和批次特徵的線上預測

這個階段的公司的例子包括Stripe、Uber、Faire，用於欺詐檢測、信用評分、駕駛和交付的估計以及推薦等用例。

每個預測的流特徵的數量可能是數百，甚至數千。流特徵的提取邏輯可能需要複雜的查詢，並沿不同維度進行連線和聚合。要提取這些特徵，需要高效的流處理引擎。

要求

要把你的ML工作流程移到這個階段，你需要：

1. 成熟的流處理基礎設施，具有高效的流處理引擎，能夠以可接受的延遲計算所有的流媒體特徵。你需要能夠將請求進入你的流媒體傳輸，並在下一個請求到達之前為預測服務快速處理它們。
2. 一個用於管理物化特徵並確保訓練和預測期間流特徵一致性的特徵儲存。注意：目前 feature stores通常管理物化的流式特徵，但不管理特徵的計算或特徵的原始碼。
3. 一個模型儲存。一個流特徵，在被建立後，需要被驗證。為了確保一個新的功能確實有助於你的模型的效能，你想把它新增到一個模型中，這就有效地建立了一個新的模型。理想情況下，你的模型商店應該幫助你管理和評估用新的流媒體特徵建立的模型，但同時評估模型的模型商店還不存在。你可以潛在地將這部分工作委託給一個功能商店。
4. 最好是一個更好的開發環境。目前，資料科學家即使在建立流媒體功能時也是根據歷史資料工作，這使得他們很難提出和驗證新的流媒體功能。如果我們能讓資料科學家直接訪問資料流，從而使他們能夠快速實驗和驗證新的流功能，那會怎樣？與其說資料科學家只能訪問歷史資料，不如說他們也能從他們的筆記本上訪問傳入的資料流，那會怎麼樣呢？

討論。Bandit的線上預測和上下文bandit的線上預測

線上預測不僅能讓你的模型做出更準確的預測，而且還能讓Bandit進行線上模型評估--這比A/B測試更有趣、更強大--並作為產生預測的探索策略。

對於那些不熟悉的人來說，Bandit演算法起源於賭博。一家賭場有多臺老虎機，有不同的賠率。老虎機也被稱為 "獨臂老虎機"，因此得名。你不知道哪臺老虎機的賠率最高。你可以隨著時間的推移進行試驗，找出哪臺老虎機是最好的，同時使你的賠率最大化。

多臂老虎機是一種演算法，允許你在利用（選擇過去支付最多的老虎機）和探索（選擇其他可能支付更多的老虎機）之間進行平衡。

用於模型評估的Bandit行為

目前，業界對線上模型評估的標準是A/B測試。透過A/B測試，你將流量隨機分配給每個模型進行預測，並在試驗結束後測量哪個模型效果更好。

A/B測試是無狀態的：你可以將流量傳送到每個模型，而不需要知道它們當前的效能。你可以做A/B測試，即使是批次預測。

當你有多個模型需要評估時，每個模型都可以被視為一臺老虎機，其報酬（如預測準確性）你不知道。匪徒允許你確定如何將流量導向每個模型進行預測，以確定最佳模型，同時儘量減少顯示給使用者的錯誤預測。

Bandits是有狀態的：在將請求路由到一個模型之前，你需要計算所有模型的當前效能。

Bandit在學術界得到了很好的研究，並被證明比A/B測試的資料效率高得多。在許多情況下，匪徒甚至是最佳方法。

匪徒需要更少的資料來確定哪個模型是最好的，同時，由於他們將流量更快地導向更好的模型，從而減少機會成本。

在 this experiment由谷歌的Greg Rafferty所做的，A/B測試需要超過63萬個樣本才能得到95%的置信區間，而一個簡單的Bandit演算法（Thompson Sampling）在不到12000個樣本的情況下確定一個模型比另一個模型好5%。

要求

為了做模型評估，你的系統需要以下三個要求。

1. 線上預測。
2. 最好是短的反饋迴路：你需要獲得關於模型所做的預測是否良好的反饋，以計算模型的當前效能。反饋被用來提取預測的標籤。
   具有短反饋環路的任務的例子是可以從使用者的反饋中確定標籤的任務，比如在推薦中--如果使用者點選了一個推薦，則推斷該推薦是好的。如果反饋環路很短，你可以快速更新每個模型的效能。如果迴圈很長，仍然可以做匪徒，但在模型做出推薦後，需要更長的時間來更新它的效能。
3. 一個收集反饋、計算和跟蹤每個模型效能的機制，以及根據不同模型的當前效能將預測請求路由到不同模型。

由於這些要求，Bandit比A/B測試更難實現。因此，除了一些大的科技公司外，在行業內沒有廣泛使用。

作為一種探索策略的 "上下文Bandit"（Contextual bandits）。

如果說用於模型評估的Bandit是為了確定每個模型的報酬（如預測準確性），那麼上下文匪徒是為了確定每個行動的報酬。在推薦的情況下，行動是向用戶展示的一個專案，而報酬是使用者點選它的可能性。

免責宣告：有些人也把用於模型評估的匪徒稱為 "背景Bandit"。這使對話變得混亂，所以在這篇文章中，上下文匪徒指的是確定預測報酬的探索策略。

為了說明這一點，考慮一個10,000個專案的推薦系統。每次，你可以向用戶推薦10個專案。這10個顯示的專案會得到使用者對它們的反饋（點選或不點選）。但是你不會得到其他9,990個專案的反饋。

如果你一直只向用戶展示他們最有可能點選的專案，你就會陷入一個反饋迴圈，只展示受歡迎的專案，而永遠不會得到不太受歡迎專案的反饋。

語境Bandit利用語境資訊，在向用戶展示他們會喜歡的專案（開發）和展示你還不太瞭解的專案（探索）之間取得平衡，同時將次優行為的成本降到最低。

上文中Bandit是經過充分研究的，並且已經被證明可以顯著提高模型的效能（見以下報道 TwitterGoogle).然而，上下文Bandit比模型Bandit更難實現，因為探索策略取決於ML模型的架構（例如，它是決策樹還是神經網路），這使得它在不同用例中的通用性較差。

邁向持續學習

當聽到持續學習時，人們想象著非常頻繁地更新模型，例如每5分鐘一次。許多人認為，大多數公司不需要那麼頻繁的更新，因為。

1. 他們沒有流量，這樣的再培訓計劃是沒有意義的。
2. 他們的模型不會衰減得那麼快。

我同意他們的觀點。然而，持續學習並不是指重新訓練的頻率，而是指重新訓練模型的方式。

大多數公司做的是無狀態再訓練--模型每次都是從頭開始訓練。持續學習意味著允許有狀態的訓練--模型在新資料上繼續訓練（微調）。

一旦你的基礎設施被設定為做有狀態的訓練，訓練頻率就只是一個旋鈕。你可以每小時更新一次模型，每天一次，也可以在你的系統檢測到分佈變化時更新你的模型。

有兩種型別的模型更新。

• 模型迭代：在現有的模型架構中增加一個新的功能，或改變模型架構。
• 資料迭代：相同的模型架構和功能，但有新的資料。

從今天起，有狀態的訓練指的是資料迭代。如果你改變了你的模型架構或增加了一個新的功能，你仍然要從頭開始訓練新的模型。已經有有趣的研究表明，這是有可能做到的 knowledge transfer(谷歌，2015）和 model surgery(OpenAI, 2019)。"在經過選擇過程後，將訓練好的權重從一個網路轉移到另一個網路，以確定模型的哪些部分沒有變化，哪些必須重新初始化。" 幾個大型研究實驗室已經對此進行了實驗，儘管我不知道在行業中是否有明確的結果。

從人工再訓練開始，第一步將是使再訓練過程自動化。然後，我們將從無狀態再訓練轉向有狀態訓練。最後但同樣重要的是，我們將討論持續學習。

第一階段。手動、無狀態再訓練

在開始時，你的ML團隊專注於開發ML模型，以解決儘可能多的業務問題--欺詐檢測、推薦、交付估算等。因為你的團隊專注於開發新的模型，所以更新現有的模型就退居其次了。你只有在以下情況下才會更新現有模型。

• 該模型的效能已經下降到弊大於利的地步，並且
• 你的團隊有時間來更新它。

你的一些模型是每六個月更新一次。有些是一個季度更新一次。有些已經在野外使用了一年，但根本沒有被更新。

更新模型的過程是手動和臨時性的。有人，通常是在資料平臺團隊，查詢資料倉庫的新資料。其他人清理這些新資料，從中提取特徵，在新舊資料上從頭開始重新訓練模型，然後將更新的模型匯出為二進位制格式。然後，其他人採用該二進位制格式，部署更新的模型。很多時候，特徵/模型/處理程式碼在模型重新訓練的過程中被更新了，但這些變化未能被複制到生產中，造成難以追蹤的錯誤。

如果這個過程對你來說聽起來很痛苦，你並不孤單。科技行業以外的絕大多數公司--例如，任何採用ML不到3年且沒有ML平臺團隊的公司--都處於這個階段。

第二階段。自動再訓練

與其以臨時的方式手動重新訓練你的模型，不如用一個指令碼來自動執行重新訓練過程。這通常是在一個批處理過程中完成的，比如Spark。

大多數擁有有點成熟的ML基礎設施的公司都處於這個階段。一些成熟的公司透過實驗來確定最佳的再培訓頻率。然而，對於大多數公司來說，重新訓練的頻率是根據直覺設定的--例如，"每天一次似乎是正確的 "或 "讓我們在每天晚上有空閒的計算時啟動重新訓練過程"。

你的管道中的不同模型可能需要不同的再培訓計劃。

在上述基於會話的推薦案例中，如果你的嵌入模型與你的排名模型是分開的，那麼嵌入模型需要重新訓練的頻率可能比排名模型要低很多。例如，你可以每週重新訓練你的嵌入模型一次，而每天重新訓練你的排名模型一次就可以了。如果你每天都有很多新的專案，需要學習它們的嵌入，那就是另外一回事了。

如果你的模型之間存在依賴關係，事情就會變得更加複雜。例如，由於排名模型依賴於嵌入物，當嵌入物發生變化時，排名模型也應該被更新。

要求

如果你的公司在生產中擁有ML模型，那麼你的公司很可能已經擁有自動再訓練所需的大部分基礎設施。你唯一需要的新部件，如果你還沒有的話，就是一個模型商店，用來自動版本和儲存複製模型所需的所有程式碼/工件。

最簡單的模型儲存可能是一個S3桶，它以某種結構化的方式儲存序列化的模型塊。如果你想要一個更成熟的模型儲存，我經常聽說的兩個解決方案是SageMaker（管理服務）和MLFlow（開源）。SageMaker更難使用，並且不儲存你的模型的程式碼和工件。MLFlow是開源的，有更多的功能，但如果你的ML平臺有很多怪癖，可能很難讓它工作。

你需要編寫指令碼來自動化你的工作流程，並配置你的基礎設施，以自動對你的資料進行取樣，提取特徵，並處理/註釋標籤以進行再培訓。這個過程需要多長時間取決於許多因素，但這裡有兩個主要因素。

1. 排程器。如果你已經有一個CRON排程器，如Airflow、Argo，把指令碼連線在一起應該不是那麼難。
2. 資料訪問和可用性。你需要的所有資料是否已經收集在你的資料倉庫中？你將不得不連線來自多個組織的資料嗎？你是否需要從頭開始建立大量的表格？Stitch Fix的ML/資料平臺經理Stefan Krawczyk評論說，他懷疑大多數人的時間可能都花在這裡。

獎金：記錄和等待（功能重複使用）。

當你在新的資料上重新訓練你的模型時，很可能新的資料已經經過了你的預測服務，這意味著已經為預測提取了一次特徵。一些公司將這些提取的特徵重新用於模型更新，這既節省了計算量，又使預測和訓練之間保持一致。這種方法被稱為記錄和等待。這是一個經典的方法，可以減少訓練服務的偏差--由生產和開發環境不匹配造成的錯誤。

這還不是一個流行的方法，但它正變得越來越流行。我預計它很快就會成為一種標準。Faire有一篇 great blog post討論了他們的日誌和等待方法的優點和缺點。

第三階段。自動的、有狀態的訓練

記住，有狀態的訓練是指你在新的資料上繼續訓練你的模型，而不是從頭開始重新訓練你的模型。有狀態的重新訓練允許你用更少的資料更新你的模型。如果你每月更新一次你的模型，你可能需要在過去3個月的資料上從頭開始重新訓練你的模型。然而，如果你每天都更新你的模型，你只需要在最後一天的資料上微調你的模型。

Grubhub在從無狀態的每日再培訓轉為有狀態的每日再培訓後，降低了他們的培訓成本 45 times(2021).

無狀態與有狀態訓練

增量學習的另一個很好的特性是，你最多隻需要看到每個資料樣本兩次：一次在預測期間，一次在模型訓練期間。如果你擔心資料隱私，你也許可以在使用完資料樣本後丟棄它們。

要求

在這個階段，你需要的主要東西是一個更好的模型商店。

• 模型世系：你不僅要對你的模型進行版本管理，還要跟蹤它們的世系--哪個模型對哪個模型進行微調。
• 流媒體特徵的可重現性：你希望能夠透過時間旅行來提取過去的流媒體特徵，並在過去的任何時候為你的模型重新建立訓練資料，以備發生一些事情，你需要進行除錯。

據我所知，現有的模型庫都不具備這兩種能力。你也許可以把流媒體功能的可重複性委託給一個功能庫，但你很可能必須在內部建立這個解決方案。

第四階段。持續學習

我正在努力實現的，也是我希望許多公司最終會採用的，就是不斷地學習。

不要根據一個固定的時間表來更新你的模型，而是在資料分佈發生變化和模型的效能急劇下降時不斷地更新你的模型。

聖盃是當你把持續學習和邊緣部署結合起來的時候。想象一下，你可以將一個基本模型與一個新的裝置--手機、手錶、無人機等--一起運送，而該裝置上的模型將不斷地更新並適應其環境。沒有集中的伺服器成本，不需要在裝置和雲之間來回傳輸資料

要求

從第三階段到第四階段的轉換很陡峭。你將需要以下條件。

• 一個觸發模型更新的機制。這個觸發器可以是基於時間的（如每5分鐘），基於效能的（如每當模型效能驟降時），或基於漂移的（如每當資料分佈轉移時）。
  今天，大多數監測解決方案都側重於分析特徵--分析一個特徵的彙總統計（如平均值、方差、最小值、最大值），並在這些統計發生重大變化時向你發出警報。然而，一個模型可能有數百，甚至數千的特徵。大多數特徵統計量的變化是良性的。問題不在於如何檢測這些變化，而在於如何知道哪些變化真正需要你的關注。
• 更好的方法來持續評估你的模型。編寫一個函式來更新你的模型，與你在第三階段所做的沒有什麼不同。困難的部分是要確保更新後的模型能正常工作。因為你正在更新你的模型以適應不斷變化的環境，一個固定的測試集不再足夠。你可能想加入回溯測試。 progressive evaluation，在生產中進行測試，包括影子部署、A/B測試、金絲雀分析和匪徒。
• 一個協調器，用於自動旋轉例項以更新和評估你的模型，而不中斷現有的預測服務。

總結

實時機器學習主要是一個基礎設施問題。解決這個問題需要資料科學/ML團隊和平臺團隊一起工作。

線上推理和持續學習都需要一個成熟的流媒體基礎設施。持續學習的訓練部分可以批次完成，但線上評估部分需要流媒體。許多工程師擔心，流媒體很難，成本很高。3年前確實如此，但從那時起，流媒體技術已經大大成熟了。越來越多的公司提供解決方案，使公司更容易轉向流媒體，包括Spark Streaming, Snowflake Streaming, Materialize, Decodable, Vectorize等。

為了更好地瞭解實時ML在行業中的採用和挑戰，我和我的團隊正在做一個 survey.如果你能與我們分享你的想法，那就太好了--這應該需要5分鐘左右。調查結果將被彙總，總結，並與社群分享。謝謝你！"。

如果你想討論我和我的團隊如何在線上預測、線上模型評估和自動、有狀態的訓練方面幫助你，請與我聯絡。

鳴謝

如果沒有一長串工程師的幫助，這篇文章是不可能的，他們對我關於他們工作流程的問題非常耐心。

我還想感謝 Stefan KrawczykZhenzhong XuMax HalfordGoku MohandasAlex EggJacopo Tagliabue，以及 Luke Metz為他們的深思熟慮的評論，使這個帖子變得更好。

感謝Ammar Asmro, Alex Gidiotis, Aditya Soni, Shaosu Liu, Deepanshu Setia, Bonson Sebastian Mampilli, Sean Sheng, and Daniel Tan對調查的反饋!

附錄

關於流處理與批處理的效率問題

我們將沿著三個維度比較效率：整體成本效率、計算效能效率和人才效率。感謝徐振中的深思熟慮的分析!

1. 成本效率
   不幸的是，在流處理和批處理之間沒有通用的成本效率公式。它取決於很多變數，如延遲要求、資料大小、晚到容忍度、故障容忍度、狀態性等。流處理的優勢在於有狀態的、連續的和無限制的資料處理。如果使用得當，與無狀態的批處理相比，它的成本往往更低。一個例子是，如果你必須計算一個滑動視窗，對使用者在30天試用期內的參與度進行評分，那麼批處理將不得不在每一個批次中重新計算30天的資料，而有狀態的流處理工作負載將避免所有的冗餘處理，因此計算成本較低。另一方面，對於靜態的極大型資料集的一次性處理，批處理仍將是首要選擇。最好的團隊是同時掌握這兩種方法的人。
2. 效能效率
   今天，流處理是一項非常成熟的技術。像Apache Flink這樣的框架被證明是高度可擴充套件和完全分佈的。流處理針對速度和無界資料進行了最佳化。它的效能是由每個操作者的吞吐量來衡量的，而可用性SLA通常被定義為在某個延遲容限內處理的事件的百分比。然而，流處理沒有為大型有界資料處理進行最佳化，在大型歷史資料處理（如回填）中，其效能明顯較低。既然如此，擁有一個凝聚力強、統一的架構，利用流處理和批處理的優勢，是一個活躍的發展領域。這裡的啟示是，流處理和批處理都有其優勢和劣勢。但最終作為一個數據處理使用者，你可能不需要擔心目前的流/批處理的鴻溝，隨著抽象度的提高，這個鴻溝將在幾年後縮小。
3. 人才效率
   今天，流媒體很難在內部管理，這仍然是一個普遍共識。你將需要一個非常強大的基礎設施工程師團隊，他們精通技術深度和運營工作。然而，隨著資料處理能力越來越商品化，許多公司將開始考慮購買而不是在內部建設。這裡打個比方，如果你需要的是把電變成更高的價值，你不需要核科學家為你工作。(哦，好吧，除非你正在經營一家核電公司:) - 在這種情況下，要準備好得到最好的人！)

特色商店是做什麼的？

感謝Stefan Krawczyk的分析。

像Tecton和FEAST這樣的特徵儲存為你做一些流式特徵計算，但它們只對不需要任何連線的資料進行操作，所以它們不太可能為你協調整個特徵計算流程。

Sagemaker’s feature store只儲存物化資料，並要求你把它與進行實際計算的管道連線起來。然後人們在系統中引用/使用物化的特徵，而不是計算它們的實際程式碼。