5G時代，大資料流儲存平臺“Pravega”誕生記
隨著5G網路、容器雲、高效能儲存硬體水平的不斷提高，資料增長進入了空前的發展階段。無處不在的物聯網、自動駕駛汽車等邊緣計算所產生的資料來源源不斷，就像開著的水管，資料來源一直在流出。這就給當前大資料處理系統（無論何種架構）提出了一個問題，計算是原生的流計算，而儲存卻不是原生的流儲存。因此目前大資料儲存面臨的三大缺陷。
目前大資料處理平臺最常見的是Lambda架構，它的優勢在於滿足了實時處理與批處理需求，但是，從儲存的角度看Lambda有三個缺點：
第一、實時處理、批處理不統一，不同的處理路徑採用了不同的儲存元件，增加了系統的複雜度，導致了開發人員的額外學習成本和工作量。
第二、資料儲存多元件化、多份化，如下圖，同樣的資料會被儲存在Elastic Search 、S3物件儲存系統、Kafka等多種異構的系統中，而且考慮到資料的可靠性，資料還都是多份冗餘的，這就極大的增加了使用者的儲存成本。而往往對於企業使用者來說，0.1%的儲存冗餘都意味著損失。
第三、系統裡儲存的元件太多太複雜，也增加了使用的運維成本。並且大部分現有的開源專案還處於“強運維”的產品階段，對於企業使用者來說又是很大的開銷。
每種型別的資料都有其原生的屬性和常用訪問模式，對應有最佳的適用場景以及最合適的儲存系統。
這三大缺點帶了儲存過程中的三個問題，即開發成本、儲存成本以及運維成本。那麼如何降低開發成本、減少儲存成本與減少運維成本？在這裡，從最新的資料型別出發，探討5G時代下資料儲存新思路。
從儲存的視角來說，儲存架構的設計需要首先明確所儲存的資料的特點。目前企業資料的儲存模式為塊儲存、檔案儲存和物件儲存。而今天移動互聯、物聯網的發展，在物聯網、自動駕駛汽車、金融等實時應用場景中，需要儲存的資料目前被稱之為“流資料”，流資料一般被定義為：
流資料是一組順序、大量、快速、連續到達的資料序列，一般情況下，資料流可被視為一個隨時間延續而無限增長的動態資料集合。
四大儲存型別
上圖將流資料定義為第四種資料型別，從左到右分佈著四種最常見的儲存型別。傳統資料庫這類基於事務的程式適合採用塊儲存系統。檔案共享場景下需要在使用者間共享檔案進行讀寫操作，因此適合採用分散式檔案 (NAS) 儲存系統。而需要無限擴充套件並支援REST介面讀寫的非結構化的影象/音影片檔案則非常適合採用物件儲存系統。
而針對流資料的應用場景，就需要流資料儲存滿足以下需求：
低延時：在高併發條件下 <10ms 的讀寫延時。
僅處理一次：即使客戶端、伺服器或網路出現故障，也確保每個事件都被處理且只被處理一次。
順序保證：可以提供嚴格有序的資料訪問模式
檢查點：確保每個讀客戶端 / 上層應用能儲存和恢復原來的使用狀態
在物聯網的世界，資料是實時的，分析也是實時的。獲得業務洞察以贏得價值還是錯失關鍵機會，對企業來說也許只有幾毫秒的差距，而真正的流式資料處理可以減少傳統的小批次分析方法的寶貴時間。
為此，戴爾科技集團IoT部門的團隊重新思考了流式資料處理和儲存規則，重新設計了新的儲存型別，即原生的流儲存，就這樣“Pravega”誕生了。
Pravega是以前的成熟技術與新技術的組合。Pravega 團隊擁有著基於日誌儲存的設計經驗，也擁有 Apache ZooKeeper/BookKeeper 的專案歷史，加之大量實時系統同樣也採用日誌儲存的方式來完成實時應用的訊息佇列，想要滿足這三種資料訪問模式，非Pravega莫屬。
5G時代，大資料流儲存平臺“Pravega”誕生記
隨著5G網路、容器雲、高效能儲存硬體水平的不斷提高，資料增長進入了空前的發展階段。無處不在的物聯網、自動駕駛汽車等邊緣計算所產生的資料來源源不斷，就像開著的水管，資料來源一直在流出。這就給當前大資料處理系統（無論何種架構）提出了一個問題，計算是原生的流計算，而儲存卻不是原生的流儲存。因此目前大資料儲存面臨的三大缺陷。
目前大資料處理平臺最常見的是Lambda架構，它的優勢在於滿足了實時處理與批處理需求，但是，從儲存的角度看Lambda有三個缺點：
第一、實時處理、批處理不統一，不同的處理路徑採用了不同的儲存元件，增加了系統的複雜度，導致了開發人員的額外學習成本和工作量。
第二、資料儲存多元件化、多份化，如下圖，同樣的資料會被儲存在Elastic Search 、S3物件儲存系統、Kafka等多種異構的系統中，而且考慮到資料的可靠性，資料還都是多份冗餘的，這就極大的增加了使用者的儲存成本。而往往對於企業使用者來說，0.1%的儲存冗餘都意味著損失。
第三、系統裡儲存的元件太多太複雜，也增加了使用的運維成本。並且大部分現有的開源專案還處於“強運維”的產品階段，對於企業使用者來說又是很大的開銷。
每種型別的資料都有其原生的屬性和常用訪問模式，對應有最佳的適用場景以及最合適的儲存系統。
這三大缺點帶了儲存過程中的三個問題，即開發成本、儲存成本以及運維成本。那麼如何降低開發成本、減少儲存成本與減少運維成本？在這裡，從最新的資料型別出發，探討5G時代下資料儲存新思路。
從儲存的視角來說，儲存架構的設計需要首先明確所儲存的資料的特點。目前企業資料的儲存模式為塊儲存、檔案儲存和物件儲存。而今天移動互聯、物聯網的發展，在物聯網、自動駕駛汽車、金融等實時應用場景中，需要儲存的資料目前被稱之為“流資料”，流資料一般被定義為：
流資料是一組順序、大量、快速、連續到達的資料序列，一般情況下，資料流可被視為一個隨時間延續而無限增長的動態資料集合。
四大儲存型別
上圖將流資料定義為第四種資料型別，從左到右分佈著四種最常見的儲存型別。傳統資料庫這類基於事務的程式適合採用塊儲存系統。檔案共享場景下需要在使用者間共享檔案進行讀寫操作，因此適合採用分散式檔案 (NAS) 儲存系統。而需要無限擴充套件並支援REST介面讀寫的非結構化的影象/音影片檔案則非常適合採用物件儲存系統。
而針對流資料的應用場景，就需要流資料儲存滿足以下需求：
低延時：在高併發條件下 <10ms 的讀寫延時。
僅處理一次：即使客戶端、伺服器或網路出現故障，也確保每個事件都被處理且只被處理一次。
順序保證：可以提供嚴格有序的資料訪問模式
檢查點：確保每個讀客戶端 / 上層應用能儲存和恢復原來的使用狀態
在物聯網的世界，資料是實時的，分析也是實時的。獲得業務洞察以贏得價值還是錯失關鍵機會，對企業來說也許只有幾毫秒的差距，而真正的流式資料處理可以減少傳統的小批次分析方法的寶貴時間。
為此，戴爾科技集團IoT部門的團隊重新思考了流式資料處理和儲存規則，重新設計了新的儲存型別，即原生的流儲存，就這樣“Pravega”誕生了。
Pravega是以前的成熟技術與新技術的組合。Pravega 團隊擁有著基於日誌儲存的設計經驗，也擁有 Apache ZooKeeper/BookKeeper 的專案歷史，加之大量實時系統同樣也採用日誌儲存的方式來完成實時應用的訊息佇列，想要滿足這三種資料訪問模式，非Pravega莫屬。