各地的公司都已升級或正在升級到現代資料棧，越來越多的公司已經開始部署雲原生事件流平臺，以獲取各種實時資料來源。
那麼，為什麼他們的分析結果仍然是分批處理，而不是實時處理？
這可能是因為他們的分析資料庫缺乏必要的功能，無法實時準確地提供資料驅動的決策。 可變性這是最重要的能力，但緊隨其後且相互交織的是處理失序資料的能力。
失序資料是有時間戳的事件，由於一些原因，這些事件在最初的資料流被接收資料庫攝取後才到達，或資料倉庫。
在這篇博文中，我將解釋為什麼可變性是處理失序資料的必備條件，失序資料成為今天這樣一個問題的三個原因，以及現代可變性實時分析資料庫如何高效、準確、可靠地處理失序事件。
失序資料的挑戰
從1990年起，流資料已經出現了，事件流、事件處理、事件流處理（ESP）等多種名稱。機器感測器讀數、股票價格和其他按時間順序排列的資料被收集並傳輸到資料庫或資料倉庫，這些資料按時間序列順序進行物理儲存，以便快速檢索或分析。換句話說，時間相近的事件被寫入相鄰的磁碟群組或分割槽中。
自從有了流資料，就有了失序資料。傳輸送貨卡車實時位置的感測器可能因為電池沒電或卡車離開無線網路範圍而離線。如果網站或活動釋出者崩潰或出現網路問題，網路點選流可能會中斷。該點選流資料需要重新發送或回填，可能是在攝取資料庫已經儲存了該資料之後。
傳輸失序的資料不是問題。大多數流媒體平臺可以重新發送資料，直到它收到來自接收資料庫的確認，表明它已經成功寫入資料。這就是所謂的 “一次性語義”（at-least-once semantics）。
問題是下游資料庫如何儲存更新和晚到的資料。傳統的事務性資料庫，如Oracle或MySQL，在設計時假定資料需要持續更新以保持準確性。因此，執行中的資料庫幾乎都是完全可變的，這樣單個記錄就可以在任何時候被輕易更新。
不變性和更新。對資料的準確性而言，成本高且風險大
相比之下，大多數資料倉庫，無論是在企業內部還是在雲端，都是以不可改變的資料為基礎設計的，當資料到達時永久地儲存到磁碟。所有的更新都是附加的，而不是寫在現有的資料記錄上。
這有一些好處。首先，它可以防止意外刪除。對於分析來說，不變性的主要好處是，它使資料倉庫能夠透過在快速的RAM或SSD中快取資料來加速查詢，而不用擔心磁碟上的源資料已經改變並變得過時。
（Martin Fowler： Retroactive Event）
然而，不可變的資料倉庫受到失序時間序列資料的挑戰，因為不能在原始資料記錄中插入更新或更改。
作為迴應，不可變的資料倉庫製造商被迫創造變通方法。Snowflake和其他公司 Apache Druid使用的一種方法被稱為 copy-on-write。當事件姍姍來遲時，資料倉庫會寫入新的資料以正確的時間順序將所有的東西儲存到磁碟上。
在一個不可變的資料系統中，處理更新的另一個糟糕的解決方案是將原始資料保留在分割槽A（見上圖），並將晚到的資料寫到不同的位置，即分割槽B。這種做法被稱為 referential integrity它確保分散的資料行之間的關係是按照定義建立和使用的。因為資料庫不提供參考完整性約束，所以應用開發者有責任理解並遵守這些資料依賴關係。
這兩種解決方法都有很大的問題。寫時複製需要大量的處理能力和時間——當更新很少的時候還可以忍受，但隨著失序資料量的增加，成本和速度都會變得難以忍受。例如，如果1，000條記錄儲存在一個不可變的blob中，並且需要對該blob中的一條記錄進行更新，那麼系統就必須將所有的1，000條記錄讀入緩衝區，更新記錄，並將所有的1，000條記錄寫回磁碟上的新blob——
然後
刪除舊blob。這是非常低效、昂貴和浪費時間的做法。它可以排除對偶爾收到的資料流的實時分析，而這些資料流是不按順序的。
使用參照完整性來跟蹤分散的資料有其自身的問題。查詢必須反覆檢查他們是否從正確的位置提取資料，否則就有可能出現數據錯誤。試想一下，在訪問一個記錄的最新版本時，應用程式開發人員的開銷和困惑。開發人員必須編寫程式碼，檢查多個分割槽，去掉重複的內容，並在應用中使用前合併多個分割槽的同一記錄。這大大阻礙了開發人員的工作效率。當同一記錄的更新分散在磁碟的多個地方時，嘗試任何查詢最佳化（如資料快取）也會變得更加複雜和危險。
今天不變性的問題
當失序更新很少，速度不那麼重要時，上述所有問題都是可以處理的。然而，由於三個原因，環境變得更加苛刻。
1.流資料的爆炸性增長
在Kafka、Spark和Flink之前，流資料有兩種味道。 Business Event Processing （BEP）和 Complex Event Processing （CEP）。 BEP提供了簡單的監控和即時觸發器，用於 SOA和早期的演算法股票交易。CEP速度較慢，但更深入，它將不同的資料流結合在一起，以滿足不同的需求。
BEP和CEP有三個共同特點。
它們是由大型企業軟體供應商提供的。
他們是在現場的。
對大多數公司來說，它們是負擔不起的。
然後，新一代的事件流平臺出現了。許多（Kafka、Spark和Flink）是開源的。大多數都是雲端原生的（Amazon Kinesis， Google Cloud Dataflow），或在商業上為雲計算而調整（Kafka⇒ Confluent， Spark ⇒ Databricks）。而且它們更便宜，更容易開始使用。
這使流處理民主化，並使更多的公司開始利用他們被壓抑的實時資料供應。以前被鎖定在BEP和CEP之外的公司開始收穫網站使用者點選流、物聯網感測器資料、網路安全和欺詐資料，以及更多。
公司也開始接受 CDC以便從執行中的資料庫進行流式更新——認為 Oracle， MongoDB或 Amazon DynamoDB- 到他們的資料倉庫。公司也開始將額外的相關時間戳資料附加到現有的資料集上，這個過程被稱為資料豐富化。CDC和資料豐富化都提高了他們分析的準確性和範圍。
由於所有這些資料都有時間戳，它有可能不按順序到達。這種失序事件的湧入給不可更改的資料倉庫帶來了沉重的壓力，他們的工作方法沒有考慮到這種數量。
2.從批處理到實時分析的演變
當公司首次將雲原生流釋出平臺與現代資料堆疊的其他部分一起部署時，如果資料是分批攝取的，如果查詢結果需要很多分鐘，那麼他們就沒有問題。
然而，正如我的同事 Shruti Bhat 指出世界正在走向實時化。為了避免被尖端對手破壞，公司正在擁抱電子商務客戶個性化，互動資料探索，自動化物流和車隊管理，以及異常檢測以防止網路犯罪和金融欺詐。
這些實時和接近實時的用例極大地縮小了資料新鮮度和查詢速度的時間視窗，同時增加了資料錯誤的風險。為了支援這一點，需要一個分析資料庫能夠在幾秒鐘內攝取原始資料流和失序資料，並在一秒鐘內返回準確結果。
不可變的資料倉庫所採用的變通方法，要麼是攝取失序資料的速度太慢（寫時複製），要麼是以一種複雜的方式（參考完整性）來降低查詢速度，並造成重大的資料準確性風險。除了造成延誤，排除了實時分析，這些變通方法也會造成額外的成本。
3.實時分析是關鍵任務
今天的顛覆者不僅是資料驅動的，而且正在使用實時分析將競爭對手置於後視窗。這可以是一個電子商務網站透過個性化的優惠和折扣促進銷售，一個線上電子競技平臺過即時的方式讓玩家參與進來。 或建築物流服務確保混凝土和其他材料按時到達建築商手中。
當然，反過來說，複雜的實時分析現在對一個公司的成功是絕對重要的。資料必須是新鮮的、正確的和最新的，這樣查詢才不會出錯。當傳入的資料流激增時，攝取這些資料不能拖累你正在進行的查詢。資料庫必須促進而不是減損你的開發人員的生產力。這是一個很高的要求，但當你的不可變的資料庫使用笨拙的駭客來攝取無序的資料時，它就特別困難。
可變分析資料庫如何解決失序資料問題
該解決方案簡單而優雅：一個可變的雲原生實時分析資料庫。晚到的事件被簡單地寫入資料庫的部分，如果它們一開始就準時到達的話。
在 Rockset是我幫助建立的一個實時分析資料庫，資料記錄中的各個欄位可以被本機更新、覆蓋或刪除。不需要像Apache Druid那樣昂貴而緩慢的寫時複製，也不需要笨重的隔離動態分割槽。
不過，Rockset超越了其他可變的實時資料庫。Rockset不僅持續地攝取資料，而且還可以 “rollup”資料。透過使用SQL在資料被攝取時進行聚合，這大大減少了儲存的資料量（5-150倍）以及查詢所需的計算量（提升了30-100倍效能）。這使使用者不必為他們的流資料管理緩慢、昂貴的ETL管道。
我們還將底層的RocksDB儲存引擎與我們的 Aggregator-Tailer-Leaf （ALT） 架構。因此，我們的索引是即時的、完全可變的。這確保了所有的資料，甚至是剛出爐的失序資料，都可以用於準確的、超快的（亞秒級）查詢。
Rockset的ALT架構還將儲存和計算的任務分開。這確保了在有突發資料流量的情況下，包括回填和其他失序資料時的平穩可擴充套件性，並防止查詢效能受到影響。
最後，RocksDB的合併演算法自動合併了舊的和更新的資料記錄。這確保了查詢能夠訪問最新的、正確的資料版本。它還可以防止資料膨脹，因為這將妨礙儲存效率和查詢速度。
換句話說，像Rockset這樣設計的可變的實時分析資料庫提供了高的原始資料攝取速度、更新和回填記錄的原生能力，所有這些都不會產生額外的成本、資料錯誤風險，或為開發人員和資料工程師帶來工作。這支援了當今資料驅動的顛覆者所需要的關鍵任務的實時分析。