物聯(lián)網(wǎng)大數(shù)據(jù)平臺建設(shè)方案1物聯(lián)網(wǎng)平臺建設(shè)需求技術(shù)方案選型對比物聯(lián)網(wǎng)大數(shù)據(jù)平臺建設(shè)物聯(lián)網(wǎng)大數(shù)據(jù)平臺建設(shè)方案物聯(lián)網(wǎng)業(yè)務(wù)需求與特點

企業(yè)在開展業(yè)務(wù)過程中，其各類終端設(shè)備、傳感器、應(yīng)用日志等渠道會收集到大量指標數(shù)據(jù)，需要對其進行有效管理與利用，主要的需求特點包括：規(guī)模性(Volume)：

需要對大量監(jiān)測點產(chǎn)生的海量數(shù)據(jù)進行穩(wěn)定的歸集與存儲高速性(Velocity)：

各監(jiān)測點數(shù)據(jù)產(chǎn)生頻率高，需要對高速增長的數(shù)據(jù)進行接入與處理多樣性(Variety)：

需要對來源廣、類型多的物聯(lián)網(wǎng)數(shù)據(jù)進行相應(yīng)的加工處理價值性(Value)：

需要對價值巨大但價值密度低的物聯(lián)網(wǎng)指標數(shù)據(jù)進行有效利用傳統(tǒng)數(shù)據(jù)處理技術(shù)的瓶頸實施難度大人工分庫分表的設(shè)計實現(xiàn)較為復(fù)雜且維護成本高寫入吞吐低存儲模型的寫入吞吐低，很難承載時序數(shù)據(jù)千萬級的寫入壓力查詢性能差傳統(tǒng)關(guān)系型數(shù)據(jù)庫對海量數(shù)據(jù)的聚合分析處理性能差存儲效率低對于時序數(shù)據(jù)壓縮效率不高，且存儲規(guī)模存在瓶頸

時序數(shù)據(jù)往往是由大量物聯(lián)網(wǎng)終端設(shè)備產(chǎn)生的基于時間戳的指標數(shù)據(jù)，寫入并發(fā)量比較高，屬于海量數(shù)據(jù)場景。由于傳統(tǒng)數(shù)據(jù)庫大多使用Btree索引模型實現(xiàn)行式存儲，對于OLTP隨機查詢操作的性能優(yōu)化較好，但對于時序數(shù)據(jù)高并發(fā)隨機寫入的場景會帶來大量磁盤尋道代價，難以實現(xiàn)較高的寫入吞吐量，數(shù)據(jù)壓縮的效率也比較低。因此，傳統(tǒng)關(guān)系型數(shù)據(jù)庫處理時序數(shù)據(jù)的能力較差，即使進行分庫分表的復(fù)雜設(shè)計也難以承載海量時序數(shù)據(jù)的存儲與分析需求。大數(shù)據(jù)處理技術(shù)體系Hadoop是利用大量服務(wù)器組成集群進行分布式存儲和計算的技術(shù)體系，能夠承載PB級別結(jié)構(gòu)化、非結(jié)構(gòu)化數(shù)據(jù)，適合海量數(shù)據(jù)的離線存儲與分析處理，包括HDFS、YARN、HIVE、SPARK等Hadoop處理框架NoSQL數(shù)據(jù)庫NewSQL數(shù)據(jù)庫實時處理框架NoSQL泛指非關(guān)系型的數(shù)據(jù)庫，其不保證ACID特性，數(shù)據(jù)模型靈活，在大數(shù)據(jù)量下特殊業(yè)務(wù)場景的讀寫性能較高，包括列族型數(shù)據(jù)庫HBASE、時序數(shù)據(jù)庫openTSDB、圖數(shù)據(jù)庫Neo4J等。NewSQL是對各種新的可擴展/高性能數(shù)據(jù)庫的簡稱，這類數(shù)據(jù)庫不僅具有NoSQL對海量數(shù)據(jù)的存儲管理能力，還保持了傳統(tǒng)數(shù)據(jù)庫支持ACID和SQL等特性。包括TIDB、KUDU、Oceanbase等。實時處理框架是通過消息隊列及流處理引擎等工具實現(xiàn)實時數(shù)據(jù)的接入與加工的技術(shù)體系，適合進行高時效要求的數(shù)據(jù)傳輸與流式業(yè)務(wù)處理，包括KAFKA、Flink、Spark-Streaming等

傳統(tǒng)關(guān)系型數(shù)據(jù)庫在事務(wù)處理方面能力強，適合數(shù)據(jù)量小、高可靠、數(shù)據(jù)價值密度高的應(yīng)用。但面對物聯(lián)網(wǎng)業(yè)務(wù)場景，需要使用能夠滿足海量數(shù)據(jù)存儲、分析、高并發(fā)寫入等功能特點的數(shù)據(jù)平臺，當前大數(shù)據(jù)處理技術(shù)體系下有如下實現(xiàn)框架：物聯(lián)網(wǎng)數(shù)據(jù)平臺方案

對于物聯(lián)網(wǎng)設(shè)備采集數(shù)據(jù)的持續(xù)高并發(fā)寫入，查詢時按時間范圍對指標進行統(tǒng)計分析，且存在明顯的冷熱數(shù)據(jù)等特點，業(yè)界主流方案為采用支持LSMtree存儲模型的大數(shù)據(jù)產(chǎn)品替代Btree存儲模型的傳統(tǒng)關(guān)系型數(shù)據(jù)庫。LSMtree在設(shè)計上將寫入操作追加到內(nèi)存中，定期刷寫到磁盤并進行后臺多版本數(shù)據(jù)的合并工作，從而將隨機寫轉(zhuǎn)化為順序?qū)?，保障?shù)據(jù)庫的寫入性能優(yōu)勢，并提供相對較好的讀取性能。相關(guān)的產(chǎn)品方案有以下幾種：時序數(shù)據(jù)庫是一種以時間為主索引的專用NoSQL數(shù)據(jù)庫，針對時序數(shù)據(jù)的特點對寫入、存儲、查詢等流程進行了優(yōu)化時序數(shù)據(jù)庫Hbase是能夠支持PB級海量數(shù)據(jù)存儲與高并發(fā)寫入的通用Nosql數(shù)據(jù)庫，可結(jié)合Hive數(shù)倉進行數(shù)據(jù)的歸檔及復(fù)雜分析HBASE+離線數(shù)倉Iceberg、Hudi等基于Hadoop的數(shù)據(jù)湖組件或TIDB、KUDU等類MPP架構(gòu)分布式數(shù)據(jù)庫可實現(xiàn)PB級數(shù)據(jù)的實時接入與分析處理。實時數(shù)倉/數(shù)據(jù)湖時序數(shù)據(jù)庫方案介紹

時序數(shù)據(jù)庫是一種通過使用特殊的存儲方式，針對時序數(shù)據(jù)的特點對寫入、存儲、查詢等流程進行了優(yōu)化的NoSQL數(shù)據(jù)庫，使其可以高效存儲和快速處理物聯(lián)網(wǎng)

設(shè)備、應(yīng)用日志等產(chǎn)生的時序數(shù)據(jù)。例如：數(shù)據(jù)先寫入內(nèi)存，再周期性落盤形成為不可變的文件存儲，從而保障寫入性能；利用時間遞增、維度重復(fù)、指標平滑變化的特性，合理選擇編碼壓縮算法，節(jié)省存儲空間；通過預(yù)降精度，對歷史數(shù)據(jù)做聚合，優(yōu)化數(shù)據(jù)管理；內(nèi)部集成的時間序列函數(shù)具備更加優(yōu)越的查詢性能原生產(chǎn)品集成組件原生時序數(shù)據(jù)庫大多為商業(yè)化產(chǎn)品，例如InfluxDB，由其自身實現(xiàn)數(shù)據(jù)的存儲與處理功能，因此集成性與擴展性較差，但一般可以實現(xiàn)較為優(yōu)秀的產(chǎn)品功能與處理性能。例如通過數(shù)據(jù)保留策略高效去除過期數(shù)據(jù)；通過連續(xù)查詢功能自動采樣計算聚合數(shù)據(jù)等。集成組件一般為在開源大數(shù)據(jù)體系下實現(xiàn)時序處理功能的插件，例如OpenTSDB，其使用HBASE作為存儲引擎，自身僅實現(xiàn)數(shù)據(jù)的處理操作。雖然其功能和性能往往弱于獨立的商業(yè)化產(chǎn)品，但其能夠與開源大數(shù)據(jù)體系進行良好集成，且能夠基于后端存儲擴展到較大的數(shù)據(jù)規(guī)模。HBASE是構(gòu)建在Hadoop上的實時數(shù)據(jù)庫組件，通過LSM存儲引擎實現(xiàn)數(shù)據(jù)的高并發(fā)增刪改操作，能夠承載單表PB級規(guī)模海量數(shù)據(jù)的實時存儲與檢索，也可結(jié)合開源時序數(shù)據(jù)庫組件OpenTSDB、開源SQL引擎Phoniex等組件進行相應(yīng)的業(yè)務(wù)處理，廣泛應(yīng)用于物聯(lián)網(wǎng)、日志分析等業(yè)務(wù)場景。但由于HBASE的范圍讀取性能較差，不適合進行復(fù)雜分析與批處理作業(yè)，行業(yè)中一般使用由Hbase承接海量數(shù)據(jù)的實時接入與檢索，定期將數(shù)據(jù)導(dǎo)出到離線數(shù)倉中由Hive或Spark進行分析處理的Lambda技術(shù)架構(gòu)，其實現(xiàn)流程如下：

數(shù)據(jù)源-->推送日志數(shù)據(jù)-->實時更新HBase-->用戶實時查詢-->定時導(dǎo)出到離線數(shù)倉->批量分析處理HBASE+離線數(shù)倉方案介紹實時數(shù)倉/數(shù)據(jù)湖方案介紹

由于Lambda架構(gòu)中存在的部分缺點無法滿足實時數(shù)據(jù)分析業(yè)務(wù)的需求，例如：開發(fā)人員需要編寫復(fù)雜的代碼來管理兩個系統(tǒng)之間的數(shù)據(jù)傳輸及同步，且HDFS文件不可更改的存儲特點會帶來諸多不便；運維人員必須管理跨系統(tǒng)的一致性備份、安全策略以及監(jiān)控；而對于業(yè)務(wù)人員而言，新數(shù)據(jù)從HBase到HDFS的同步鏈路中存在較高延遲，不能馬上分析使用。因此，大數(shù)據(jù)項目中往往希望使用同時兼?zhèn)銱ive與HBASE優(yōu)勢特性的實時數(shù)倉/數(shù)據(jù)湖組件來改進數(shù)據(jù)處理流程，實現(xiàn)數(shù)據(jù)實時寫入與實時處理的一體化，例如能夠支持秒級實時寫入的Kudu、ArgoDB、Hologres等實時數(shù)倉與支持分鐘級寫入的Iceberg、Hudi等數(shù)據(jù)湖組件。物聯(lián)網(wǎng)大數(shù)據(jù)平臺建設(shè)方案對比HBASE+離線數(shù)倉實時數(shù)倉/數(shù)據(jù)湖原生時序數(shù)據(jù)庫代表產(chǎn)品基于大數(shù)據(jù)平臺HBASE、Hive、Spark基于大數(shù)據(jù)平臺Kudu、Iceberg、Hudi以InfluxDB為例商業(yè)版特點免費版已具備全部核心功能；商業(yè)版本大數(shù)據(jù)平臺具備更完善的多租戶權(quán)限管理與資源協(xié)調(diào)能力免費版未集成數(shù)據(jù)湖組件功能，實時數(shù)倉Kudu相對商業(yè)平臺中的產(chǎn)品成熟度低；多租戶權(quán)限與資源管理能力低商業(yè)版可實現(xiàn)集群高可用功能，免費版只能單節(jié)點部署存儲能力支持數(shù)千節(jié)點的分布式集群，PB~EB級別承載能力實時數(shù)倉具備TB~PB級別承載能力數(shù)據(jù)湖具備PB~EB級別承載能力2~3個節(jié)點的高可用集群GB~TB級別承載能力處理性能Hbase對非rowkey的分析性能低，需要結(jié)合離線數(shù)倉實現(xiàn)復(fù)雜分析處理通過分布式計算實現(xiàn)數(shù)據(jù)高性能實時分析處理必須基于時間窗口進行分析，大數(shù)據(jù)量下單點處理聚合性能較低開發(fā)兼容Hbase不支持SQL（可接入外部SQL引擎）與事務(wù)，Hive兼容SQL與事務(wù)大多數(shù)實時數(shù)倉產(chǎn)品對標準SQL及事務(wù)的支持較為完善支持類SQL，不支持事務(wù)、表關(guān)聯(lián)及數(shù)據(jù)單點刪改操作實施難點數(shù)據(jù)開發(fā)鏈路較為復(fù)雜，需要在Hbase與離線數(shù)倉中存儲兩份數(shù)據(jù)硬件要求較高，具備完善功能的商業(yè)版大數(shù)據(jù)平臺采購費用較高存儲規(guī)模及聚合性能存在瓶頸；難以承接其他擴展業(yè)務(wù)需求方案優(yōu)點數(shù)據(jù)分析時效要求較低（小時級）的實時OLTP+離線OLAP方案，能夠承載包含物聯(lián)網(wǎng)業(yè)務(wù)在內(nèi)的大數(shù)據(jù)混合業(yè)務(wù)場景，如報表分析、流式預(yù)警等業(yè)務(wù)處理時效高（秒級或分鐘級）的實時HTAP方案，能夠承載包含物聯(lián)網(wǎng)業(yè)務(wù)在內(nèi)的大數(shù)據(jù)混合業(yè)務(wù)場景，如報表分析、流式預(yù)警等方案實施的軟硬件成本相對較低；對高并發(fā)時序?qū)懭霟o需刪改的分析型業(yè)務(wù)場景處理效率高，例如物聯(lián)網(wǎng)數(shù)據(jù)、日志分析

考慮到項目實施的成本與穩(wěn)定性、擴展性的需求，建議使用更加通用的Hadoop體系大數(shù)據(jù)產(chǎn)品構(gòu)建物聯(lián)網(wǎng)基礎(chǔ)平臺，可使用具備核心功能的免費社區(qū)版大數(shù)據(jù)平臺產(chǎn)品（如CDH、HDP等）或采購商用版大數(shù)據(jù)平臺產(chǎn)品。整體方案使用消息隊列KAFAK承載物聯(lián)網(wǎng)數(shù)據(jù)的實時傳輸，通過Spark-Streaming等流處理引擎將消息實時入庫到Hbase中，調(diào)用數(shù)據(jù)庫接口或內(nèi)部集成的SQL處理引擎Phoniex、時序數(shù)據(jù)處理引擎OpenTSDB、地理信息處理引擎Geomesa等組件提供物聯(lián)網(wǎng)數(shù)據(jù)的實時檢索服務(wù)。同時結(jié)合Hive、Spark等大數(shù)據(jù)計算組件進行冷數(shù)據(jù)歸檔、復(fù)雜分析與規(guī)則預(yù)警工作，從而實現(xiàn)物聯(lián)網(wǎng)平臺中各類業(yè)務(wù)需求的實現(xiàn)。物聯(lián)網(wǎng)大數(shù)據(jù)平臺整體方案選型

若采購商業(yè)版大數(shù)據(jù)平臺產(chǎn)品，可使用其集成的更加成熟完善的實時數(shù)倉/數(shù)據(jù)湖組件替代HBASE+離線數(shù)倉的Lambda處理架構(gòu)。例如，華為大數(shù)據(jù)解決方案中的實時數(shù)倉GaussDB200在標準數(shù)倉的架構(gòu)基礎(chǔ)上內(nèi)置時序引擎和CEP引擎，以處理時序數(shù)據(jù)和流數(shù)據(jù)，支持持續(xù)計算、規(guī)則計算、預(yù)測分析以及實時數(shù)據(jù)與歷史數(shù)據(jù)關(guān)聯(lián)分析，從而大幅提升了物聯(lián)網(wǎng)數(shù)據(jù)處理的性能與敏捷性。（可選方案）商業(yè)大數(shù)據(jù)平臺實時數(shù)倉/數(shù)據(jù)湖物聯(lián)網(wǎng)數(shù)據(jù)接入流程

物聯(lián)網(wǎng)設(shè)備采集到相關(guān)信息后會通過相關(guān)通訊協(xié)議將數(shù)據(jù)發(fā)送給物聯(lián)網(wǎng)平臺，行業(yè)內(nèi)一般使用消息隊列作為數(shù)據(jù)傳輸鏈路的中間通道，用于解耦上下游系統(tǒng)間的關(guān)聯(lián)，并在業(yè)務(wù)高峰期提供隊列緩沖。在接入KAFKA等消息隊列工具后，物聯(lián)網(wǎng)終端無需對數(shù)據(jù)平臺所選擇的存儲及計算產(chǎn)品進行適配，只需負責數(shù)據(jù)的推送工作；數(shù)據(jù)平臺也可根據(jù)自身的加工需求與處理能力進行靈活消費。例如，數(shù)據(jù)平臺可使用流處理引擎或其他功能程序?qū)afka中的物聯(lián)網(wǎng)消息寫入HBase進行存儲，并通過數(shù)據(jù)庫接口或Phoenix等集成工具對外提供指標查詢服務(wù)，也可以關(guān)聯(lián)其他維度表進行規(guī)則計算，從而實現(xiàn)設(shè)備預(yù)警等業(yè)務(wù)需求。物聯(lián)網(wǎng)業(yè)務(wù)實現(xiàn)流程Hive離線數(shù)倉物聯(lián)網(wǎng)終端消息隊列時序采集數(shù)據(jù)大數(shù)據(jù)計算業(yè)務(wù)應(yīng)用實時采集物聯(lián)網(wǎng)數(shù)據(jù)調(diào)用接口發(fā)送到消息隊列物聯(lián)網(wǎng)歸檔數(shù)據(jù)Flink/Spark-Streaming業(yè)務(wù)歸集數(shù)據(jù)復(fù)雜統(tǒng)計業(yè)務(wù)報表大數(shù)據(jù)存儲流處理引擎實時儀表查詢Zookeeper批量業(yè)務(wù)數(shù)據(jù)批量交換業(yè)務(wù)、財務(wù)等需要進行BI分析的數(shù)據(jù)HBASE實時入庫Spark、Impala等規(guī)則預(yù)警流式加工數(shù)據(jù)檢索數(shù)據(jù)分析KAFKA定期導(dǎo)出規(guī)則預(yù)警指標查詢物聯(lián)網(wǎng)大數(shù)據(jù)平臺產(chǎn)品技術(shù)架構(gòu)

數(shù)據(jù)開發(fā)、任務(wù)調(diào)度Hue、Oozie、AzkabanSPARK迭代計算通用查詢引擎資源管理

YARNx86服務(wù)器&云服務(wù)器計算、內(nèi)存、存儲、網(wǎng)絡(luò)資源管理層消息隊列KafkaNoSQL圖形數(shù)據(jù)庫時序數(shù)據(jù)庫

文檔數(shù)據(jù)庫

ClickHouse實時多維分析引擎Flink/Spark-streaming實時流處理引擎DataDelivery

數(shù)據(jù)交換分布式存儲

HDFS分布式協(xié)作Zookeeper日志采集Flume數(shù)據(jù)采集Sqoop

安裝、監(jiān)控、運維、管理

ClouderaManager、AmbariHBase實時數(shù)據(jù)庫ElasticSearch搜索引擎Kudu/ArgoDB實時數(shù)據(jù)倉庫

數(shù)據(jù)整合

數(shù)據(jù)治理

數(shù)據(jù)分析MachineLearning

深度學習

數(shù)據(jù)挖掘

數(shù)據(jù)服務(wù)Hive離線數(shù)據(jù)倉庫IMPALAMPP內(nèi)存計算交互式查詢引擎分布式計算MapReduce大數(shù)據(jù)平臺數(shù)據(jù)服務(wù)器大數(shù)據(jù)平臺管理服務(wù)器大數(shù)據(jù)平臺應(yīng)用服務(wù)器機器數(shù)量至少3臺，建議5臺以上（根據(jù)存儲及處理工作負載確定）