分享嘉賓：王懷遠 阿里雲 表格儲存架構師
編輯整理：李瑤 DataFun
出品平臺：DataFunTalk
導讀： 大家好，我是王懷遠，我2015年加入阿里雲，一直從事表格儲存的研發和架構相關工作，目前擔任表格儲存的架構師。我在儲存和資料庫領域有一些研發和架構方面的經驗。
本次分享的主題是一站式物聯網儲存產品的架構設計，希望大家可以先回答以下幾個問題：
- 第1個問題：物聯網場景下的資料需求有哪些，如何分類？
- 第2個問題：如何針對物聯網場景設計一款儲存或資料庫產品？
- 第3個問題：怎麼達到成本效能相比傳統方案能夠優化10倍的目標，技術選型的原則和方向是什麼？
本次分享側重於技術分析，不介紹具體的產品功能。帶著這3個問題，我們進入今天的分享和討論。
今天的介紹會圍繞下面四部分展開：
- 物聯網儲存的需求：通過分析物聯網儲存的場景，對場景中涉及到的資料進行分類，分析這些資料對於資料庫或者儲存系統的相關需求，後面我們對於解決方案和架構設計的分析也會基於這些具體的需求來展開。
- 物聯網儲存解決方案：介紹一些物聯網場景下的儲存解決方案，並由此引出為什麼需要一個一站式的物聯網儲存產品，要實現的技術目標是什麼。
- 架構設計：分析如何進行架構選型，從而實現我們對於一站式儲存產品的技術目標。
- 總結
--
01 物聯網儲存的需求
1. 物聯網資料
從整體來說，對於一個物聯網業務，首先要解決裝置接入的問題。裝置接入後，資料不斷上傳，儲存到儲存系統或者是資料庫中。然後再對這些資料進行分析和視覺化。
常見的物聯網資料可以分為三個類別，分別是裝置後設資料、裝置訊息資料和裝置時序資料。
裝置後設資料儲存了裝置的標識、屬性、狀態等。這部分資料可以用來進行裝置管理、裝置狀態查詢和裝置圈選等。
裝置的訊息資料，分為上行訊息和下行訊息，上行訊息比如裝置事件的上報，下行訊息比如控制指令的下發、訊息推送等等。訊息資料常常用佇列模型來建模，每個裝置可以設計兩個佇列用來區分上行訊息和下行訊息，在佇列模型下，對寫入同一個佇列的訊息天然有保序的要求，新寫入的訊息必須排在佇列的末尾，否則可能會出現訊息漏收的問題。
第三類資料是裝置的時序資料，時序資料一般是這三類資料中規模最大的。常見的時序資料比如端上感測器採集的資料、裝置的監控資料、裝置的軌跡資料等等。這些資料很少更新，一般採用時序模型進行儲存，資料規模大。
2. 對儲存系統的需求
首先是一些通用的要求，比如高可靠、高可用、低成本、高效能、易擴充套件、易運維等等。
其次，不同型別資料也有著不同的功能需求。
裝置後設資料的要求是需要支援多維度檢索、支援靈活分析、對於地理位置相關的場景需要支援地理空間的檢索能力。
訊息資料的要求是要支援佇列模型、支援海量資料、支援訊息保序等。
時序資料的要求是支援時序資料模型、支援時間序列的後設資料檢索、支援資料的聚合計算等。由於時序資料儲存量大，對儲存成本的需求非常明顯。
總結一下，物聯網儲存的核心需求是，在海量資料下實現極低的成本、高併發寫入和查詢能力、可快速分析、支援後設資料高頻更新和多條件檢索。
--
02 物聯網儲存解決方案
帶著這些需求，我們進入第二部分，物聯網儲存解決方案。
1. 車聯網場景例子
在開源資料庫或者儲存系統中，單一產品很難同時滿足一個物聯網場景中多種不同型別資料的需求。因此，常見的物聯網儲存解決方案需要使用多款產品。
這裡我們舉一個車聯網場景的例子。這個場景中也包含三類資料，第一類是車輛狀態彙報，屬於後設資料場景，主要用於車輛圈選、車輛排程等；第二類是訊息通道，屬於訊息資料場景，包括事件上報、控制指令、訊息推送等；第三類是行駛資料，屬於時序資料場景，包括行駛軌跡，以及行駛狀態的一些資訊，如速度、發動機引數等。
每類資料對儲存都有著不同的要求。
使用開源的解決方案來解決以上三個場景需求，通常需要使用組合的解決方案。對於車輛後設資料，可能會使用MySQL + Elasticsearch的方案，引入ES是為了解決多欄位組合條件檢索的問題。對於訊息資料，使用MySQL來進行儲存。時序資料，則會採用HBase，來滿足高吞吐寫入和大規模儲存的需求。
這樣的組合解決方案在架構方面有著明顯不足：
- 首先是運維複雜度較高，因為要運維多個產品，並且需要維護多個產品之間的資料同步；
- 其次是擴充套件性差，當資料規模不斷增加時，某個產品在規模和效能方面可能會出現不足，這時候又要尋找新的解決方案，如果引入新的元件也會進一步加大運維複雜度和成本；
- 最後，整個方案的成本和效能並不優，一方面是這些產品並沒有針對物聯網場景進行優化，另一方面是由於資料庫的發展，也產生了很多新的技術。
為了解決以上問題，我們希望設計一個更適合物聯網的儲存產品。
2. 一站式儲存解決方案設想
首先，我們的目標是一個一站式的物聯網儲存產品。這個產品通過多模型來滿足不同型別資料的需求，對外提供多種訪問介面，包括標準SQL、API或SDK，另外也需要提供標準的資料訂閱介面，用於資料匯出和生態對接。
在核心方面，儲存引擎和計算引擎應該針對物聯網場景的大規模、低成本、資料分析等需求進行優化。
在生態方面，需要對接物聯網生態的上下游，上游包括資料採集、寫入，以及大資料分析結果表的寫入。下游對接實時計算、大資料分析、BI、AI、以及一些視覺化工具。
整體技術目標如下：
- 從功能方面，需要滿足後設資料、時序、訊息三類場景，支援高併發寫入和查詢，支援物聯網場景的分析需求。
- 從成本方面，希望儲存成本相比傳統解決方案能夠降低90%。
- 從效能方面，希望分析效能相比傳統解決方案可以提升10倍。
為什麼要提出這樣的目標呢？
一方面，從物聯網客戶的角度，資料規模在不斷膨脹，如果資料增長10倍，成本也增長10倍，那麼將是巨大的一筆IT支出。換個角度來說，必須存在一個成本為現有方案1/10的解決方案，才能支撐物聯網資料的高速增長。
另外一方面，傳統的解決方案並沒有很好地利用雲端計算、資料庫方面的一些最近的發展和技術，在成本和效能方面並不優，所以我們才提出一個更高的目標。
那麼如何設計才能滿足這樣的成本和效能目標，這是一個長期需要討論的話題，本次分享跟大家一起討論一下我們在這方面的思考和經驗。
--
03 架構設計
1. 時序資料特徵
首先，以時序場景為例，分析資料模型和特徵。
以時序為例，主要有兩方面原因，一方面是因為時序資料是物聯網場景下佔比最大的一類資料，另一方面時序資料本身也有後設資料，所以針對時序資料的優化技術也可以應用到裝置後設資料場景中。
時序資料模型，是一個典型的時間線加多值資料點的結構。
時間線：描述產生資料的裝置或者叫資料來源，同時可以記錄相關標籤和屬性。如上圖表格中的前三列，第一列是度量型別，第二列是資料來源標識，第三列是時間線的標籤。標籤是對資料來源的一些描述，可以作為維度，基於標籤進行聚合。
資料點：即度量值，如上圖表格中的後三列，每個資料點都對應一個時間戳，每個時間可能對應單個點（單值模型）或多個點（多值模型）。
另一方面，時序資料模型是一種靈活的表結構模型。
標籤可以自定義、度量點可以自定義。
靈活表結構對使用者使用是非常方便的，但只有部分時序資料庫是支援靈活表結構的。
時序資料模型具有以下特點：
- 首先，從寫入角度，一般是由裝置端按照一定頻率上報資料，一般只有新增，很少更新歷史資料。
- 其次，從查詢角度，熱資料查詢頻率較高，冷資料也會進行查詢，頻率較低，同時對熱資料或冷資料都有統計分析的需求。
在進行技術架構設計時，會針對這些資料特點進行設計。
2. 車聯網例子
下面我們通過一個具體的例子，來分析儲存產品的優化方向。這個例子主要是用來儲存車輛行駛資料：
- 10W輛車，每5秒上傳1條資料，200byte
- 寫入：平均每秒 20000 行，約 4MB/s 流量
- 儲存：每天上傳約 321G 資料。資料保留5年，約 587TB
- 查詢：查詢一輛車一段時間的狀態資料；查詢最近5分鐘、1小時、1天、1周、1月的所有車輛統計資訊
在這個場景中，為了保障資料可靠性，需要做冗餘，比如採用多副本技術，那麼實際儲存量就可能會達到PB級別，將會是一筆不小的儲存成本。
對這個場景進行一定分析：
- 首先，該場景每秒寫入流量並不高，但由於資料儲存時間長，因此總儲存量大，儲存成本佔比高。
- 其次，業務的首要需求是資料能夠廉價地存下來，其次是能夠查詢和分析。而對於分析產生的資源開銷，取決於查詢請求覆蓋的時間範圍以及相應的資料掃描量。
那麼怎麼針對這個場景做優化呢？
首先，我要介紹一個資料庫優化方面的經典理論，叫做讀/寫/儲存優化的共軛關係。這個理論簡單來說就是，一項技術很難同時優化讀/寫/儲存三個方面，往往只能優化其中一個或者兩個。比如面向讀優化的技術，往往是對寫效能不友好的。而面向寫優化的技術，往往又對讀效能是不友好的。有些可以同時優化讀和寫的技術，比如快取技術，對儲存空間又是不友好的，即需要更大的儲存空間，比如我們經常說的一句話，就是用空間來換時間。因此，我們的設計原則就是要找到場景中的主要矛盾點，選擇不同的技術組合。
針對上述場景，主要的優化方向在哪裡呢？
前面我們已經分析過，儲存成本是這個場景中成本佔比最高的部分，也是使用者最重要的需求。因此首要目標是面向儲存優化，其次是面向讀效能優化。而對於寫效能，因為本身TPS不高，在這個場景中需求並不強。
下面就來分析如何進行儲存成本和讀效能的優化。
3. 面向儲存成本的優化
① 第一個問題，選擇怎樣的儲存格式？
不同儲存格式有著不同的優缺點，我們這裡還是以剛才的例子為例，對比一下不同的儲存格式，分析一下采用不同格式儲存，最終的儲存空間大小。
這個資料樣例如下，每行大約200byte，包括車輛ID、里程、速度、溫度、發動機狀態引數等採集指標。
原始資料生成500w行，大小為975MB，大約1GB。分別採用Apache Avro和Parquet格式進行儲存，其中Avro大小為265MB，相比原始優化3.7倍，Parquet大小為46MB，相比原始優化21倍。
可以看到使用不同的儲存格式，有著巨大的差異。
這裡簡單再介紹下Avro和Parquet。
Avro是一種行存格式，相比原始格式的優勢在於，Avro的schema是預先定義好的，每行只儲存一個列值。同時，數字使用變長編碼，相比原始資料減少了約3倍。
Parquet是一種列存格式，優化效果更加明顯。列存格式為何能降低儲存大小：
-
按列組織，相鄰資料更具有近似性
-
** 列存編碼技術**
a. RLE、DICTIONARY、DELTA、BIT-PACKING、定製編碼；
b. 可直接在編碼後資料上做掃描分析，效能高。 -
列存編碼後，仍可用通用壓縮演算法進一步壓縮
總結一下，使用列存技術，可以把資料從587TB減少到27TB。
套用之前的資料庫優化理論，列存技術是面向儲存空間優化，同時面向分析優化的一種儲存結構。當然，它也有一定的劣勢，比如對於寫效能會增加額外開銷，這種一般都是採用行模式寫入，後臺批量轉列存的方式來優化。另外對於整行資料讀取，列存會有多次IO，這個場景也相比行存有一定的劣勢。
② 第二個問題，選擇怎樣的儲存架構？
這裡的儲存架構選擇，指的是選擇儲存計算耦合的架構還是儲存計算分離的架構。
首先，還是對這兩種架構做一下介紹。
- 儲存計算耦合
計算資源和儲存資源繫結
機器之間複製資料，保障資料可靠性和可用性 - 儲存計算分離
計算資源和儲存資源解耦
由共享儲存滿足資料可靠性要求
更適合雲原生架構，共享儲存可選擇雲基礎服務
我們認為儲存計算分離的架構是更適合物聯網和大規模資料場景的：
- 雲上共享儲存，單位儲存成本更低，規格更豐富，按量計費
- 彈性計算資源，減少閒置
- 更高可靠性和可用性
使用存計分離架構，我們預計，儲存成本可以下降1/3，並且計算的彈性更好，可以降低計算成本。
③ 第三個問題，如何降低冷資料訪問成本？
物聯網場景下，冷資料訪問頻率低，很多時候只是為了歸檔，並不怎麼查詢，因此思考如何優化這部分的成本。解決方案就是將資料進行分層儲存。
分層策略有如下兩種：
- 基於資料時間分層
- 基於寫入時間分層
分層之後我們可以做的第一個優化是，將不同層的資料採用不同介質來儲存，以降低單位儲存大小的成本，例如：
- SSD（TLC、QLC），HDD（PMR、SMR）
- 不同規格物件儲存
另外，不同層還可以採用不同的儲存格式，以平衡成本和效能的需求。
- 對於熱資料，行列混存：兼顧寫入、更新和查詢
- 對於溫資料，列存：兼顧壓縮率和讀取效能
- 對於冷資料，列存+更高壓縮率壓縮：追求極致壓縮率，降低儲存成本
後面在查詢效能分析時，也會對不同層的儲存結構選擇進行分析。
總結一下，使用冷熱分層技術，預計儲存成本再進一步下降1/3。那麼綜合之前講的儲存格式優化、儲存計算分離架構以及冷熱分層技術，我們希望達到儲存成本整體降低10倍的目的。
4. 面向讀效能優化
首先，我們還是分析一下物聯網查詢場景和特點。
下面列舉了三類典型的查詢模式，分別是熱資料查詢，資料分析和後設資料檢索。
- 熱資料查詢場景，比如查詢單個或者多個裝置最近一段時間的狀態，可用於監控等場景。
- 資料分析場景，比如分析一段時間內所有裝置的某個資料點的統計值等等，用來做報表、資料統計或者異常點篩選等，一般會查詢熱資料或者溫資料。對於冷資料也會有分析統計需求，一般查詢頻率比較低。
- 後設資料檢索場景，一般是根據多種組合條件來檢索滿足條件的裝置列表，有多種用途。
這三類場景對資料庫的查詢模式也有很大差別：
- 第一類場景的查詢模式一般是點查和小範圍的掃描，單個請求開銷比較低，但是併發要求高，適合採用一些分散式的KV引擎技術。
- 第二類場景的查詢模式一般是大量資料掃描，單個請求掃描量比較大，但併發低，延遲要求一般不高，適合採用一些分散式的OLAP引擎技術。
- 第三類場景的查詢模式一般是通過靈活的組合條件做資料篩選，資料的篩選率比較低，一般是採用搜尋引擎相關的技術。
綜上，物聯網查詢的需求非常豐富，但是我們可以總結出來一些基本規律：
- 對於熱資料，需要具備高併發查詢和分析能力
- 對於溫冷資料，查詢頻率低，但需要具備分析能力
- 對於後設資料，需要支援多條件組合查詢等靈活的檢索能力
此外，還需要平衡查詢效能和儲存成本，不能為了滿足查詢需求而大幅增加整體成本。
① 第一個問題，如何在低成本儲存上滿足查詢分析需求？
首先是分層，針對熱、溫、冷資料採用不同的儲存格式來進行優化。
- 對於熱資料，採用行列混存，這裡行列混存是結合了行存和列存優勢的一種儲存結構，在儲存空間上相比純列存會有一些冗餘。因為結合了行存和列存的優勢，因此既適合點查、小範圍掃描，也針對資料分析做了優化，同時也支援高併發的寫入和更新。
- 對於溫資料，採用純列存儲存，列存一方面壓縮率有優勢，另一方面也非常適合掃描和分析，可以很好的滿足對溫資料的分析需求。
- 對於冷資料，採用純列存，同時進行一些引數調整、使用更高壓縮率的演算法，降低儲存成本。
套用之前資料庫優化的理論，對於熱資料，採用的是空間換時間的方式，追求寫效能和讀效能；對於溫資料，面向儲存空間和讀效能優化；對於冷資料，面向儲存空間優化，但是會增加讀的開銷。
這樣的儲存架構，很好的滿足了對於查詢和分析的需求。
為了進一步優化效能，還需要儲存和計算層的聯合優化。這裡主要講以下幾個方面：
首先，資料可以進行水平切分和垂直切分。水平切分，指的是資料可以分為不同的shard，在不同的shard查詢時可以有一定的併發度，同時也可以靈活控制shard的大小。垂直切分是針對時間維度做分片。
基於這樣的切分，在查詢時，就可以根據時間範圍和一些檔案級別的統計資訊來過濾掉不需要掃描的資料檔案。
另一方面，整個查詢需要一個分散式的執行器，從而提高查詢的併發度。
另外，也可以利用雲原生的能力，在需要進行大量資料分析需求之前，彈性地擴容一批機器，計算後再進行縮容。
總結一下，通過使用分層技術和採用不同儲存格式，既降低了儲存成本，同時也滿足了查詢和分析需求。另一方面，通過分散式的SQL執行能力，提升計算效能，通過雲原生的存計分離架構，可以彈性的擴容計算資源。
② 第二個問題，如何進行快速的後設資料檢索
如何在海量的時序資料中檢索時間線?
第一個方案是直接在資料上進行掃描和過濾，但是由於後設資料僅佔資料的一小部分，所以直接掃描的篩選率很低，效果並不好。
第二個方案就是採用倒排索引，這也是很多時序資料庫都採用的方案。倒排索引的方案經常遇到的一個問題是規模問題，因為很多時序資料庫的倒排索引實現是一個單機版本，並且需要載入很多索引資料到記憶體中，因此只能支援較小規模的時間線。
為了解決規模問題，可以採用這樣的方案：
首先是後設資料和資料分離儲存。
其次是要採用分散式的索引技術。具體來說，就是分shard來儲存索引部分，查詢時查詢多個shard的資料再進行合併。這樣總體時間線規模可以支撐到百億到千億的級別，這在物聯網場景下已經完全足夠了。
有了後設資料索引之後，在資料查詢時也可以根據後設資料索引進行查詢優化。
這部分主要涉及計算引擎的查詢優化器部分，查詢優化器可以根據查詢條件和索引資訊，計算該查詢命中的時間線數量，結合其他的統計資訊，就可以計算出一個篩選率。這個篩選率表示如果進行資料掃描，有多少比例資料是滿足時間線過濾條件的。根據這個篩選率可以決定查詢計劃是分時間線進行定位加小範圍掃描，還是直接掃描資料。
總結一下，為了滿足後設資料檢索的需求，儲存引擎需要支援分散式倒排索引技術，同時計算引擎可以利用儲存引擎的索引資訊做查詢優化，這部分查詢優化的前提是需要實現一個定製化的查詢優化器。
現在我們已經分析瞭如何優化儲存成本，如何優化查詢分析效能，如何優化後設資料檢索效能。下面我們總結一下這樣一個物聯網儲存產品的整體架構。
5. 整體架構
整體架構如下。
從訪問介面和模型方面，整個架構支援多資料模型訪問，包括時序、訊息場景的定製模型，介面支援API、SDK介面，SQL、JDBC介面，以及資料訂閱介面。
從架構方面，需要採用儲存計算分離的架構，滿足彈性、高可靠、易擴充套件，支援資料分層儲存，以滿足低成本的需求。
從儲存引擎方面，需要支援多種儲存格式，內建不同儲存格式的轉換和生命週期管理，以平衡成本和效能的需求。另外，也要支援多元化的分散式索引技術，用於快速的資料檢索。
在SQL查詢引擎方面，需要定製查詢優化器，支援分散式執行，適應更多型別的查詢負載。
最後，也要選用一個合適的共享儲存底座。
--
04 總結
最後進行一下總結。
在前文中，首先介紹了物聯網場景下的幾類資料，包括後設資料、訊息、時序，時序是資料量最大的一類，架構設計部分也是以時序為例進行了場景分析。
其次，我們分析了物聯網場景對儲存產品的需求，我們也看到在很多場景下，儲存成本和分析能力是主要需求。
從場景和需求出發，我們進行了架構設計選型的分析，並且得到了一定的結論。在架構方面，要選擇雲原生、存計分離、分層儲存的架構。在儲存引擎方面，要選擇以列存為主，熱資料行列混存的儲存格式，同時支援後設資料索引。在計算引擎方面，需要分散式的執行器和定製化的儲存計算聯合優化。同時，整個方案也需要充分利用雲的彈性和雲原生架構的優勢。
最終我們希望通過這樣的架構設計，在成本和效能方面相比傳統方案有著一個數量級的優化，同時做到功能上的一站式和一體化。這樣的架構優化也必然是一個持續的過程，最終持續助力物聯網的資料增長和更豐富的場景應用的出現。
本文首發於微信公眾號“DataFunTalk”。