TableStore是阿裡雲自研的線上資料平台，提供高可靠的存儲，實時和豐富的查詢功能，适用于結構化、半結構化的海量資料存儲以及各種查詢、分析。
交通資料是一種資料規模大，實時性要求高的資料，資料的專業性極強，對社會生産的價值極大，我們接下來先看一下交通資料的場景和特征，我們僅以交通路口的車輛同行資料為例。
交通資料特點
資料量大
每個城市都有數以萬計的交通路口，每時每刻都有車輛通過每個交通路口，這些交通路口的車輛實時資料，包括車牌、顔色、車速、位置、類型等，就是可以發揮重大價值的交通資料。假設一個城市有五千個交通路口，每個交通路口每秒同行1輛車，那麼每秒就會産生5000行資料，每天就能産生5000 * 3600 * 24 = 4億行資料，每個月就能産生120億行資料，這個資料規模已經非常大。同時，這些資料對公安刑偵也有價值，保留時間越長越好，資料規模隻會越來越大。
查詢種類多
交通類的資料種類比較多，既包括了車輛資訊（車牌、顔色、類型），也包括了車輛實時狀态（車速、位置、時間），資料既包括了枚舉類型，字元串，也包括地理位置。是以，對查詢的需求就比較多，比如：
- 查詢某一輛車過去十二個小時的行車路線（隻要列出交通路況，就能畫出行車路線）。
- 查找某個時間段經過某個交通路況的，白色私家轎車的清單。
- 查找某個銀行（地點）附近5公裡的交通路口，過去10分鐘同行過的紅色機車。
- 查找過去1分鐘内，全市通行車輛最多的10個路口，以及通過的車輛數。
上述列舉了三種查詢，這三種查詢涉及了好幾種查詢類型：
- 多字段自由組合查詢。
- 範圍查詢。
- 地理位置查詢。
- 統計聚合。
資料不能丢
交通資料除了用來調節城市交通外，還有一個重要作用是公安用來查詢嫌疑車輛的通行情況，類似于我上面“查詢種類多”中列舉的第一種查詢需求，這種場景下，每一輛經過交通路況的車輛資訊都不能丢失，否則會影響刑偵判斷和進展，可能會造成比較嚴重的後果。是以，整個系統對資料存儲的可靠性，以及傳輸鍊路的可靠性要求都極高，盡力要做到不丢資料。
針對上述的場景需求，目前業内已經有多種解決方案，我們接下來看一下：
開源解決方案
一種很容易想到的方案是使用關系型資料庫，比如MySQL或PostgreSQL存儲，但是這種隻适合存儲小資料量，如果資料量超過單機存儲能力，則會不适合。就算采用了分庫分表的方式，也會帶來極大的運維壓力和産品功能犧牲。
另外一種方案，是從資料可靠性角度考慮，使用HBase等分布式NoSQL資料庫，但是這種NoSQL資料庫隻提供單Key和Key字首範圍查詢，無法支援按照其他屬性列查詢，無法滿足我們上面的需求，就算引入Phoenix使用了二級索引，也需要提前固定好查詢，無法支援自由組合，更無法支援地理位置查詢。
還有一種方案，是從查詢複雜度考慮，直接使用搜尋引擎Elasticsearch或Solr，但是這種雖然能滿足查詢需求，可惜沒法滿足資料不能丢的要求，存在丢失資料的風險。
至此，考慮了所有開源系統後，沒有一個系統能滿足使用者需求，那麼隻能退而求其次，采用組合大法：
- 存儲系統使用HBase，保證資料可靠性。
- 同步方式采用Lily Indexer。
- 查詢引擎使用solr系統。
上述架構方案，看起來滿足了我們上面的所有需求，雖然麻煩了點。但是隻能算是基本滿足，因為這套架構存在比較大的問題：
- Lily indexer基于HBase的日志順序，依賴一個時間戳，推送服務需要根據時間戳進行重排序再寫入，在很多場景下難以做到嚴格的保序，可能會丢資料。
- 存量資料，以及solr中索引資料損壞後需要rebuild index時，需要使用運維人員通過工具去做，增加風險的同時還要隻能整個系統的運維壓力。
除此之外，還需要運維HBase、Lily index、Proxy和Solr四個系統，需要配備熟悉這四個開源系統的人員，這個又是一筆額外支出。除了開源解決方案外，如今又多了一種選擇，使用雲解決方案。
TableStore雲解決方案
在現有的各種雲産品中，能滿足上述交通資料存儲需求的系統并不多，阿裡雲TableStore是一款符合要求的系統，10年前就開始自研，多年的雙十一、公有雲客戶的錘煉沉澱，保證了系統的可靠性和穩定性。
我們先來看一下基于TableStore存儲交通資料的架構方案：
- 資料存儲在TableStore中，TableStore可以提供10個9的資料可靠性保障，資料可靠性更高。
- 資料和索引都在一個系統裡面，寫入，讀取都是通過同一套API寫入和查詢，易用性更高。
- 完全滿足上述提出的查詢需求，包括：
- TableStore是分布式系統，可以水準擴充，目前生産環境單表最大有幾十PB，每秒寫入有幾千萬行，完全能勝任任何大資料的寫入和存儲。
示例
接下來，我們舉個例子幫助讀者了解。
某個城市在每一個交通路口安裝了攝像頭，記錄通過每個路口的實時車輛資訊，包括車牌、車顔色、車類型（救護車、消防車、公共汽車、私家轎車等）、車速、時間、路口位置、路口名稱。
首先，我們設計TableStore中主表結構：
| 主鍵列 | 屬性列 | ||||||
| 路口ID | 時間戳 | 車牌 | 車顔色 | 車類型 | 車速 | 路口名稱 | 路口位置 |
| String | Double | ||||||
| 10001 | 1551340084 | 浙A. XXXXX | 藍色 | 私家轎車 | 42.5 | 西湖區餘杭塘路五常港路口 | [30.295,120.059] |
上述主表結構中，隻能支援查詢某個路口過去一段時間内的車輛通行清單，或者每個路口實時的車輛通行情況。
另外，這種表中，我們把路口的資訊，包括路口名稱、路口位置等也存在了每輛車通行資訊中，這樣帶來的好處是查詢的時候簡單，隻需要查詢單個系統即可，但是也帶來了資料備援，有時候也會将這部分資料單獨存儲。
接下來，我們定義TableStore多元索引的結構：
| 列 | ||||||
| Text：單字分詞 | GeoPoint |
- 時間戳、車牌、車顔色、車類型都是String，其中車牌可以支援模糊查詢和字首查詢。
- 車速是浮點數。
- 路口名稱采用了Text類型， 支援分詞，分詞使用了單字分詞，這樣通過查詢“餘杭塘河路”就能查詢到“花蔣路和餘杭塘路”，這裡不要采用其他分詞方式，因為其他分詞方式總會有bad case，會導緻某些查詢不到。
- 路口位置采用了GeoPoint類型，這個類型支援範圍查詢，比如某個點附近幾公裡内的車輛資訊，同時也支援某個多邊形範圍内的車輛通行資訊。
基于上述的表和index，我們就能滿足上述提到的所有查詢需求。另外，可能還有一些統計需求，比如統計每個路口過去二十小時的通行車輛數，或者統計過去一分鐘通過車輛最多的前10個路口。
總結
至此，開源解決方案和TableStore雲解決方案都介紹完了，使用了TableStore雲解決方案後，能帶來不少的收益。
減少運維負擔
在TableStore解決方案中，使用者隻需要運維自己的應用程式，不需要運維任何的存儲系統、查詢系統和其他中間件，運維壓力大大減少，同時也減少了運維方面的成本開支。
另外，TableStore是Serverless的服務化産品，使用者也無需考慮運維，不需要關注擴容、水位等事項，隻需要關注功能開發即可。
系統架構更簡單
在開源解決方案中4個系統，而TableStore解決方案中隻有1個系統，系統數減少後，系統架構會更簡單，系統可能産生的風險會更少，系統的穩定性等會更高，可以提供更優質的服務體驗。
減少時間成本
TableStore雲架構方案相對于開源方案，系統更少，從零開始到上線需要的開發時間更少，同時，TableStore是serverless的雲服務，全球多個區域即開即用，可以大大降低客戶的開發上線的時間，提前将産品推出，搶先争取市場領先優勢。
資料可靠性更高
在開源解決方案中，資料有可能會丢失，影響最終的業務，而在TableStore解決方案中，可以提供更高的可靠性，可以讓資料不丢失，保障業務的準确執行。
最後
目前，已經有大量的業務在使用TableStore，後續我們會繼續優化改進TableStore，為客戶持續提供一款高性能、豐富功能、低成本、高可用性的分布式系統，為客戶的海量資料保駕護航。