原文鏈接

“自動駕駛汽車”在近兩年頻頻出現於各大科技新聞頭條，自2012年谷歌獲得美國首個自動駕駛汽車許可證以來，國外各大知名汽車廠商如奔馳、沃爾沃、大眾、通用、豐田、日產、特斯拉等也紛紛宣布自己的自動駕駛汽車驗證開發計劃。自動駕駛依托於人工智能技術的發展，而對於一個人工智能平臺來說，重要的不光是算法和平臺，更重要的是數據！今天我們暫且不聊自動駕駛，我們先聊聊最基礎的車聯網數據的存儲與處理。

初始方案

出於對兩客一危監管的需要，車聯網很早就開始起步，彼時大家的車聯網方案都長這個樣子：

將車輛上傳的數據進行編碼解析，存儲到對應的數據庫中。由於車輛種類的不同，所上傳的傳感器數據也會有所區別。為了避免修改表結構對服務造成的影響，采用的是將傳感器數據進行分類，分別存儲到不同的數據庫的方法，也就是圖中的數據庫層分為了軌跡庫、溫度庫、油量庫等。這樣的好處是新增一批新類型的傳感器時，不需要數據停庫維護，不會影響在線應用，但是對數據采集解析程序需要升級更新，大大增加了維護的代價。

另外一方面，隨著近幾年私家車的爆發式增長，車聯網也迎來了更多的機遇和挑戰。百萬在網車輛，幾十萬的在線車輛都讓車聯網系統時時刻刻在經受著挑戰。

存在問題

首先就是並發問題。SQLServer的單機並發是有限制的，我們只能在已經分庫分表的基礎上再對數據進行按時間或者車輛類型的二次分庫分表，這大大增加了前後端系統開發和維護的復雜性。同時，為了應對早晚高峰高的不像話的在線率，我們又對像軌跡、油量等通用的基礎數據做了數據庫的主備讀寫分離，避免數據采集高峰影響其他的在線業務，這個時候，這個架構已經非常非常復雜了。

不僅僅是在線業務，由於多層次的分庫分表，我們的報表分析程序中跨表跨庫的Join查詢讓經驗豐富的DBA也頭疼痛不已。

而為了保持在這個行業的競爭力，降低成本是非常有效的一個法寶。我們采用的最直接的手段就是在夜深人靜的時候小心翼翼的刪除掉過期的數據。

新的方案，刻不容緩！

我們開始尋找基於雲計算的分布式數據解決方案，直到我們看到了下面的一張圖。

表格存儲（OTS）是阿裏雲最近推出的一款自研分布式 NoSQL 數據庫，其schema free的特性很適合屬性列變化較為頻繁的數據存儲。車載設備更新和叠代的速度也在不斷加快，車聯網的業務模式也在不斷在變化，表格存儲這種弱結構的數據模式與當前車聯網數據的需求非常契合。所有車輛的數據均可以存儲在一張大表裏，新的車載設備上線也不需要修改表結構了。

於是，我們將原來的方案替換成：

經過測試，百萬車輛50%的在線率的時候，讀寫的性能都沒有出現明顯的變化，而且表格存儲是一款全托管的服務，也大大減輕了我們運維上的代價。

表格存儲的數據生命周期功能可謂是數據管理的神器，我們將不同數據存儲時長要求的數據存儲在一張大表中，設置好過期時間，過期的數據會自動被刪除掉，不僅僅很方便的控制了成本，更降低了人工操作的風險。

對於報表分析，我們將原來在SQLServer上的SQL分析語句遷移到了MaxCompute（就是阿裏雲以前的ODPS）https://www.aliyun.com/product/odps上，在MaxCompute上關聯好TableStore上的外表，定期執行，既方便，又省錢。這一樣以來無需維護數據分析程序，並且按量付費的模式可以最大限度節省成本。

粗略算了下，使用表格存儲的成本，一輛車不停的跑一年，存儲與讀寫分析的成本也只有1塊5，比買瓶飲料還便宜，比最初使用的方案中單車年成本低了一個數量級。

寫在最後

選擇上雲是我們一個非常大的挑戰，一度擔心雲上的穩定性會導致我們業務的失靈，然而事實證明我們的選擇是正確的，雲確確實實帶來了很多便利，節省了很多成本，讓我們可以更聚焦在業務邏輯上，技術架構也能快速叠代，為我們保持一定的行業競爭力提供了有力保障。

原文鏈接

老司機帶你用MaxCompute和表格存儲玩轉車聯網數據