簡介：40年技術發展變革，物聯網行業的趨勢、現狀與挑戰

基礎設施的完善，推動應用形態不斷變遷

我們把過去四十年分為五個重要的技術發展階段，從時間軸上我們把它切分為：1980 - 2000，2000 - 2005，2005 - 2010，2010 - 2020 以及 2020 - 2025。今天的釋出會和第五個階段的技術發展有關，從過去看未來，所以我們先回顧下技術發展史，先來看下前四個階段分別經歷了怎樣的技術發展？在技術應用上的主要場景是什麼？主流的應用形態是什麼？誕生了什麼樣的新技術和新產品？

在 1980~2000 這個階段，是計算機技術發展和應用的階段。計算機能夠幫助企業更好的管理自己的資料，對提升流程效率有很大的幫助，所以這個階段的應用主要是企業資訊系統。這個階段誕生了很多專為企業服務的科技公司，創造了很多偉大的商業產品。應用系統的資料主要儲存在資料庫內，資料庫以關係資料庫為主，這一階段是關係資料庫理論和產品的成熟期，誕生了像 Oracle、IBM DB2、微軟 SQL Server 等商業資料庫產品。

在 2000~2005 這個階段，是網際網路技術的初始發展階段。資訊能夠通過網際網路更有效的傳遞，所以這個階段誕生了大量門戶類的網站，也就是 Web 1.0 時代。LAMP（Linux+Apache+MySQL+PHP） 是當時最流行的建站技術，是一個完全由開源產品組合的低成本解決方案。應用系統的資料儲存仍以關係資料庫為主，MySQL 以其開源和低成本的優勢替換商業關係資料庫，得到大規模的應用。隨著網際網路上的資訊越來越多，人們獲取有效資訊的訴求越來越強烈，所以搜尋引擎作為一個新的應用形態誕生。搜尋引擎是首個面臨大規模資料處理挑戰的應用，Google 作為一家偉大的技術公司首創了很多大資料處理技術。大家熟知的三駕馬車（GFS、Mapreduce 和 Bigtable），奠定了未來十年 NoSQL 和 Bigdata 技術的發展基礎。

在 2005~2010 這個階段，隨著個人 PC 得到普及，以及接入網際網路的成本逐漸降低，接入網際網路的『人』越來越多。有一些新的應用形態因此誕生，一是人們不再僅滿足於從網際網路上單向獲取資訊，更渴望在網際網路上進行人與人之間的資訊交流，於是促進了社交網路的發展；二是圍繞『人群』的應用，一些 B2C 或 C2C 的電商網站開始發展。這個時代就是所謂的 Web 2.0 時代，『人』作為新的資料來源開始在網際網路上產生大量資料。這個階段誕生了一些超大體量的網際網路公司，主要是在電商和社交網路領域。這些公司面臨著如何支撐如此大規模資料線上服務，以及如何處理和分析這些海量資料的挑戰。彼時還沒有成熟可用的解決方案，所以這些公司不得不開始自研系統的開發，所以之後流行的一些 NoSQL 和 Bigdata 系統都是誕生或孵化自這個時代的超大體量網際網路公司，比如 Hadoop 最早在雅虎內部孵化，Cassandra 最早是應用在 Facebook 的收件箱搜尋場景。

在 2010~2020 這個階段，隨著 4G 技術發展和智慧手機的普及，移動網際網路開始發展。人們可以隨時隨地聯網，移動應用可以覆蓋到更廣的人群，滲透到更多的生活場景，比如支付、打車等。傳統網際網路應用逐步向移動應用形態轉換，產生了大量應用搭建的需求，雲平臺作為低成本、易接入的資料中心被更多企業接受，這十年也是雲計算髮展的黃金十年。雲端計算徹底改變了應用的執行環境，與傳統 IDC 不同，在這個執行環境中，計算、儲存等資源是池化的，可彈性獲取多型別的儲存和計算資源。基於雲的彈性資源構建的應用即『雲原生』應用，越來越多的大資料、資料庫產品基於雲原生構建，而為了擁有彈性可擴充套件能力，分散式技術也得到大量的使用。現代的新的大資料和資料庫產品，分散式和雲原生一定是必備的能力。

最後在 2020~2025 這個階段，我們已經能看到 5G、IoT 技術逐漸成熟，又會誕生一個新的應用形態即物聯網。我們能看到的一些新的應用場景，包括車聯網、工業物聯網以及智慧家居等。

總結下過去幾十年的技術和產品演進的規律（基礎設施技術 -> 資訊化範圍變大 -> 更多場景、更大資料規模 -> 技術和產品發展）：

每個階段都是由一個『基礎設施』的完善和普及作為起點，基礎設施的核心作用是讓資訊化的範圍進一步變大。比如網際網路讓應用能與更多終端連線，移動網際網路直接打破了終端這個壁壘，直接讓應用能與更多人連線，而物聯網會把更多裝置也加入這個連線。

隨著資訊化的範圍變大，更多新的應用場景誕生，同時更大數量的『個體』產生更大規模的資料，成為基礎技術發展的推動力。

在這個過程中，往往基礎技術會落後於應用形態發展。但隨著分散式技術和雲端計算的普及，基礎技術演進和普及的速度越來越快。我們也可以看到基礎技術產品形態的變化，從最早的商業型產品，到開源型產品，再到現在的雲原生產品。

那在物聯網這個新階段，裝置的數量以及產生的資料會是更大的規模，會有更大的挑戰。那在這樣的挑戰下，又會推動怎樣的技術發展呢？

物聯網行業將迎來高速發展，會面臨怎樣的技術挑戰

我們來看下物聯網到底在經歷怎樣的高速發展，從以下兩個市場報告中來看下物聯網整體的增長態勢：

裝置數的大規模增長：Gartner 預測到 2021 年物聯網內裝置數增長到 250 億。如何管理如此海量的裝置是第一大挑戰。

裝置資料的大規模增長：IDC 報告中可以看到，到 2025 年物聯網資料規模達到 79.4 ZB，年平均增長率高達 34.91%。那如何儲存和分析如此海量的資料是第二大挑戰。

以車聯網場景為例，定義對資料儲存的具體需求

這次釋出會的主題是物聯網儲存解決方案，所以我們來具體看下物聯網場景下對資料儲存的具體需求是什麼。我們以一個車聯網中的一個真實應用場景為例，假如你是一家提供網約車服務的新能源車企，日常管理數十萬量新能源汽車提供網約車服務，你會遇到如下幾個具體的場景。

為便於對這些汽車進行管理，每輛汽車都得實時彙報自己的狀態，包括位置資訊、剩餘電量、行駛里程、行駛速度等等。除了這些動態資訊外，每輛車還會有自己的一些靜態資訊例如型號、車主等，每輛車的這些資訊都需要在後端實時獲取和管理。

有了這些車輛的實時狀態資訊後，就可為車主、乘客或者是後臺提供車輛的實時狀態查詢服務。後臺也會有一些計算任務依賴於實時狀態，例如根據位置資訊或特定條件進行車輛圈選來進行特定任務的管理，或者是根據實時狀態來進行車輛排程。

除了車輛自身需要實時彙報狀態外，車輛與管理後臺還需要保持一個訊息通道。通過這個訊息通道，車輛會彙報自身的一些異常事件，後臺也可下發一些訊息資訊或者控制指令。

另外車輛的一些行駛資訊會上報並存儲為軌跡資料，同時行駛中的一些感測器資料也需要儲存。有了這些資料後，一方面可以對行駛軌跡進行查詢，另一方面是可以基於資料進行一些計算分析，挖掘更多的價值，比如通過分析歷史行駛資料來優化排程演算法等。

從這幾個場景中可以看到，車輛相關的資料主要有三類，一是實時狀態資料，我們把這類資料歸類為『元資料』；二是訊息通道，我們把這類資料歸類為『訊息資料』；三是軌跡資料，我們將這類資料歸類為『時序資料』。這三類資料對底層儲存有不同的要求，『元資料』的特徵是高頻更新，對查詢能力要求高，需要根據多欄位條件進行資料查詢或篩選；『訊息資料』的特徵類似訊息佇列，佇列數量極多，需要為每個裝置維護一個獨立的對壘；『時序資料』的特徵是高吞吐寫入，資料規模較大，比較偏重分析場景。

在傳統方案中，元資料一般使用 MySQL 儲存，但 MySQL 最大的問題是無法靈活支援多欄位條件篩選，一般需要組合 Elasticsearch，依賴 Elasticsearch 來提供多欄位檢索能力。訊息資料雖然具備訊息佇列的特徵，但無法使用傳統訊息佇列，因為傳統訊息佇列無法支撐如此多數量的 Topic，所以一般也有選擇使用 MySQL 來模擬佇列實現。時序資料一般選擇使用 HBase 來儲存，能提供高吞吐寫入和支撐大規模儲存，但 HBase 不具備分析能力。

往往基礎技術會落後於應用形態發展，傳統架構是通過組合多款產品的方式來構建整個物聯網儲存系統。這種多元件的組合架構，架構複雜度高，帶來極高的運維成本。開發者需要理解和使用多款產品，且分散式元件的運維具備一定的難度，導致整體的成本非常高。另外每個元件並不是為物聯網場景設計和優化，我們可以看到物聯網場景下裝置元資料、訊息資料和時序資料都有非常典型的特徵，且整體規模增長速度會遠超網際網路時代，可以預見老一代產品無法應對物聯網下更大資料規模的增長。

物聯網需要什麼樣的儲存產品

根據過去幾十年技術產品發展的客觀規律，物聯網時代已經到來，當前的技術架構難以支撐未來物聯網規模的增長。面對物聯網下萬物互聯這一新的應用形態，在海量裝置和海量資料的挑戰下，基於雲端計算這一新一代基礎平臺，我們利用雲原生、分散式等基礎技術，需要打造一個什麼樣的新的基礎產品呢？

我們希望這個新的基礎產品具備以下幾個特性：

基於雲原生和分散式技術構建，具備可擴充套件性和彈性

滿足裝置元資料、訊息資料、時序資料的一站式儲存、檢索和分析需求

具備足夠低的成本來支撐如此海量資料

原文連結
本文為阿里雲原創內容，未經允許不得轉載。