通信電纜 網絡設備 無線通信 云計算|大數據 顯示設備 存儲設備 網絡輔助設備 信號傳輸處理 多媒體設備 廣播系統 智慧城市管理系統 其它智慧基建產品
南京云創大數據科技股份有限公司
南京云創大數據科技股份有限公司
背景近年來，隨著計算機技術的發展，各領域數據的增長越來越快
背景
近年來，隨著計算機技術的發展，各領域數據的增長越來越快。這些數據來自方方面面，從搜集天氣情況的感測器，接入社交媒體網站的指令，數碼圖片，在線的視頻資料，到網絡購物的交易記錄，手機的定位系統信號等等。隨著數據規模的急劇膨脹，各行業累積的數據量越來越巨大，數據類型也越來越多、越來越復雜，已經超越了傳統數據管理系統、處理模式的能力范圍，傳統的串行數據庫系統已經難以適應這種飛速增長的應用需求。在這種需求的驅動下，云計算中的MapReduce[1]技術、并行數據庫技術以及云計算與數據庫相結合的技術應運而生。font>
我們在大數據的背景下，對大數據處理技術進行了探討，將其分為三類：MapReduce技術、并行數據庫技術和云計算與數據庫相結合的技術。通過研究這些技術的架構、適用環境，提出了一種云計算數據庫--數據立方。font>
產品介紹
通過對MapReduce、并行數據庫和兩者的混合技術研究，南京云創大數據科技股份有限公司推出了實施云計算數據庫--數據立方，該系統通過引入索引模塊、并行執行架構以及讀取本地磁盤的執行方式，使查詢達到了實時完成、簡單易用、高可靠安全的效能，使EB級的數據能夠秒級處理，較大地提高了用戶執行查詢操作后的使用效率，不僅在查詢和檢索這部分數據的時候具有非常高的性能優勢，數據立方還可以支持數據倉庫存儲、數據深度挖掘和商業智能分析等業務。
數據立方的體系架構
數據立方（DataCube）的結構分為用戶接口、索引、SQL解析器、作業生成器、元數據管理、并行計算架構、分布式文件系統等部分，如圖4所示。用戶接口主要有兩個：JDBC和Shell。JDBC主要執行數據的定義操作，即建立數據庫、建表、建分區，對數據庫、表和分區的刪改等，同時可執行數據查詢的SQL語句，暫不支持單條記錄的增刪改；數據立方提供友好的shell交互界面，shell支持數據庫、表的增刪改以及數據查詢的SQL語句。數據在入庫的同時與數據對應的索引也在同時建立，索引是一顆B樹，數據插入到內存的同時，索引B樹也在生成，當達到設置上*，數據和索引會刷新到分布式文件系統上成為文件。數據立方的元數據存儲在數據庫中。其中包括，數據庫的名字和屬性，數據庫中的表，表的名字，表的列和分區及其屬性，表的屬性，表的數據所在目錄等等。SQL解析器接收從JDBC和SHELL傳來的SQL查詢語句，同時對SQL進行詞法分析、語法分析、編譯、優化。作業生成器根據SQL語法樹生成查詢作業，分析所要處理的數據表對應的索引文件的所在存儲子節點位置，并將作業發送給并行計算架構。并行計算架構接收到作業生成器生成的作業，根據索引文件的位置切分查詢作業形成子任務，然后將子任務發送給數據所在的存儲子節點，每個節點執行這些子任務查詢索引得到結果記錄所在的數據文件名與偏移量，并以廣播的方式發送查詢子任務到數據文件所在的節點，在執行完畢后將結果返回。數據立方可以使用HDFS和cStor[19]作為底層存儲系統，cStor是一個主從結構的分布式文件系統，不僅具有HDFS的高吞吐率、高讀寫性能等特性，還支持HDFS所不具備的對文件修改等功能，并且支持POXIS接口。
分布式并行計算架構（DPCA）
數據立方的分布式并行架構（DPCA）是典型的主從結構，主Master與從Master分別部署在HDFS的主從NameNode物理節點上，而Slave部署在DataNode物理節點上，主從Master使用Zookeeper同步，并共享系統日志，Master與Slave之間用心跳信息保持信息交換。
相對于MapReduce架構，DPCA具有實時性、計算的數據本地性以及數據平衡性。MapReduce架構的job提交過程較為復雜，客戶端將job提交到JobTracker有較長的延遲， JobTracker將job處理為MapReduce task后，通過TaskTracker的心跳信息將task任務返回給TaskTracker，此過程中也存在延遲。MapReduce架構雖然也遵循數據本地性，但仍會有很大比例的數據處理不是本地的，相對于MapReduce架構， DPCA的job提交是實時性的，在提交job之前所需程序jar包已經分發到所有計算節點，在job提交之后，master在初始化處理之后即將task直接分發到所有slave節點上，如并行計算架構上作業執行過程圖所示，在job提交后， master根據數據文件所在位置分配task，這樣在每個計算節點上要處理的HDFS上的數據塊就在本地，這樣避免了數據的移動，大大地減少了網絡IO負載，縮短了計算時間，每個計算節點會根據Task中SQL解析器生成的執行計劃對Task執行的結果進行分發，分發的方式有三種：分發所有中間數據到所有計算節點，分發所有中間數據到部分節點，根據數據所在位置分發，如并行計算架構的三中分發方式圖所示。并行計算架構能夠周期性地對HDFS上的數據表進行維護，保持數據表在所有的DataNode節點上所存儲的數據量的平衡，減少因數據負載的不平衡而導致的計算負載的不平衡。
舉一個典型的小表與大表join連接的實例，如圖7所示，Master解析Job中的執行計劃，判斷小表的位置后，將Task0發送給了Slave0，指令Slave0發送小表到所有節點，而其他節點接收到的子任務是等待接受小表的數據，接收到數據后將小表與大表連接并將數據返回給Master，當所有數據返回完成則這個job完成。
分布式索引
MapReduce是對每個查詢都是直接從分布式文件系統中讀入原始數據文件，I/O代價遠高于數據庫，相對于MapReduce架構以及在其之上的SQL解析器Hive，數據立方引入了一種高效的分布式索引機制，不同于并行數據庫的 shared-nothing和shared-disk架構，數據立方的數據文件與索引文件都存放在分布式文件系統之上。
MapReduce數據在入庫的同時B樹索引在內存中同步生成，B樹中的葉子節點存儲的是數據文件路徑與記錄在文件中的偏移量，如圖所示，在B樹中的葉子節點達到設置上限后，索引將被序列化到分布式文件系統之上，在根據條件進行單表查詢的時，job被提交到并行計算框架，master節點首先分析該表的索引文件根據索引文件所在的節點將task發送到相應的節點，每個節點在查詢本地的索引文件之后將符合條件的數據文件路徑+偏移量打包成task根據數據文件位置進行再次分發，在數據文件中的記錄查詢出來之后將結果返回，如上圖所示。
測試與評估
測試環境
MapReduce測試環境搭建在兩個機架的12臺物理機組成的集群上。每臺物理機使用Ubuntu9.04 server系統，JDK版本為1.6.0.18,使用的Hadoop版本為2.0.0，將HDFS作為分布式存儲環境。軟硬件配置如表1、表2所示。
| 設備名稱 | 數量 | CPU | 內存 | 硬盤 |
| 主控制服務器 | 2 | 雙路四核，主頻2GHz | 32G | 2T*8 |
| 子處理服務器 | 10 | 雙路四核，主頻2GHz | 32G | 2T*8 |
| 客戶端 | 5 | 單路雙核，主頻2GHz | 8G | 1T |
| 48口千兆交換機 | 1 |
| 軟件名稱 | 軟件版本 |
| CentOS | 6.3 |
| HadoopDB | 0.1.1.0 |
| Hive | 0.9.0 |
| 數據立方 | 1.0 |
| Hadoop | 2.0.0 |
當前與數據立方類似的產品有分布式數據庫和數據倉庫，如：開源的HIVE、HadoopDB等，因此我們在數據入庫、查詢、查詢的并發量以及線性擴展等多方面對數據立方、HIVE和HadoopDB做了對比測試。
數據入庫測試
數據立方能夠快速進行數據入庫同時實時建立索引，相對于基于傳統數據庫的HadoopDB來說具有天然的優勢，而對于HIVE來說，雖然入庫速度相差不大，但由于HIVE在數據入庫的同時并沒有建立索引使其在查詢的過程中沒有優勢。測試結果如下圖所示：
單表查詢測試
對于簡單的單表查詢來說，數據量較小時，HadoopDB與數據立方的查詢速度都是比較快的，但在大數據量下，數據立方的高效分布式查詢更有優勢，而HIVE的底層是基于MapReduce，所以速度較慢。測試結果如下圖所示：
多表查詢測試
在多表查詢方面，在小表與小表、大表與小表之間的關聯查詢，數據立方和HadoopDB都是較快的，但在大表與大表之間做關聯查詢時，數據立方相對于HadoopDB更快，而HIVE是很慢的。測試結果如下圖所示：
并發查詢測試
數據立方的每個節點支持200個并發查詢，同時每個查詢均是秒級響應，HadoopDB由于是SMS的中間層，由于MapReduce架構本身的心跳機制而導致了較大的延遲，所以是很難達到秒級響應的，HIVE的任務并發數取決于MapReduce的并發任務數，所以會更低。測試結果如下圖所示：
線性擴展測試
數據立方、HadoopDB和HIVE均支持線性擴展，而數據立方的擴展效率更高，即對系統的軟硬件做擴展后，性能也能夠達到類似線性的增長。測試結果如下圖所示：
您感興趣的產品PRODUCTS YOU ARE INTERESTED IN
智慧城市網 設計制作，未經允許翻錄必究 .? ? ?
請輸入賬號
請輸入密碼
請輸驗證碼
