基於CarbonData的電信時空大資料探索

華為雲開發者社群發表於2021-11-25
大資料
摘要：作為IOT最底層的無線通訊網路生成大量與位置相關的資料，用於無線通訊網路規劃和優化，幫助電信運營商建設更好體驗的精品網路，構建萬物互聯的資訊社會。

本文分享自華為雲社群《基於CarbonData的電信時空大資料探索》，作者： 張軍、龔雲駿 。

1使用場景

隨著萬物互聯的時代到來，以及智慧終端普及，現實世界超過80%的資料與地理位置相關，比如日常使用的社交、支付、出行相關APP。作為IOT最底層的無線通訊網路也會生成大量與位置相關的資料，用於無線通訊網路規劃和優化，幫助電信運營商建設更好體驗的精品網路，構建萬物互聯的資訊社會。

為表徵無線網路相關指標在地理空間的分佈情況，將地表按50*50米正方形網格進行切分，並按照網格累加統計指標，資料可以按時間（hour/day）、行政區（region ID）、無線小區（cell ID）、網格（網格中心經緯度座標）進行管理。表結構如下：

基於CarbonData的電信時空大資料探索

比如，需要分析某CBD無線通訊網路訊號覆蓋情況，使用CBD的邊界作為查詢條件，返回網格和業務KPI，對返回的網格經緯度和KPI進行視覺化渲染，得到如下效果。

基於CarbonData的電信時空大資料探索

某CBD通訊網路覆蓋情況

2 技術挑戰

查詢效能：以2000萬左右使用者規模的無線通訊網路為例：每秒約接入240萬條事件，每天約產生14TB資料，資料儲存若干天。基於行業常用資料倉儲查詢耗時在10-15秒左右，與使用者體驗2/5/8秒要求存在較大差距；同時單個查詢佔用資源較多，多使用者併發分析時，查詢效能明顯下降，以5使用者查詢為例，查詢耗時劣化為30-60秒；

線性擴充套件：隨著資料中心“雲化”演進，資料集中化儲存和管理趨勢明顯，支援省級、國家級超大規模網路交付場景明顯，急需體系化的方法解決海量資料治理的線性擴充套件問題。

考慮到業務資料是在時間和空間上持續增長，同時業務分析流程中，主要查詢包括：行政區域/問題區域/無線小區簇查詢。對資料查詢特性進行分析：

1） 行政區域查詢：行政區域查詢返回結果是在空間上聚集的；

2） 問題區域查詢：問題區域是指有網路問題的某個地表區域，查詢返回結果集是在空間上聚集的；

3） 無線小區簇查詢：無線網路的小區不是孤立存在的，一般把一定數量相鄰的無線小區按小區簇進行管理，因此小區簇查詢返回結果集是在空間上聚集的

綜上，查詢返回結果集都是在空間上聚集的，因此有必要考慮資料入庫時，支援按空間座標建立時空索引，提升查詢過程中的資料過濾效率。

3 優化方案

3.1 時空索引演算法

優化前使用如下方式設定表的Sort Column，資料先按緯度排序再按經度排序後，本來在空間相鄰的經過排序後劃分被切割為不相鄰的條帶。

基於CarbonData的電信時空大資料探索

條帶化問題可以參考下圖，行業內解決此問題的方法是引入空間排序方法，常用空間排序方式包括Z序和H序，最常用的方法是GeoHash。技術原理可以參考Halfrost的神作：高效的多維空間點索引演算法。基於CarbonData的電信時空大資料探索

關於Z序和H序的優缺點行業有較多討論。Z序曲線雖然有區域性保序性，但是它也有突變性，在每個 Z 字母的拐角，都有可能出現順序的突變。H序相比較Z序解決了拐角的突變問題，H序聚簇特性比Z序提升15%左右，但是生成複雜度卻提升很多，動態維護的代價會更高些。另外，還有很多應用，需要不同維度實時分解的應用，H序拆分耗時會增加不少。綜合考慮，當前使用簡單易用的Z序編碼：GeoSOT。

--建表SQL—

create table IF NOT EXISTS <table> ( timevalue bigint,

 longitude bigint,

 latitude  bigint,

regionid bigint,

cellkey bigint,

 kpi bigint,

 kpi2  bigint,

 kpi3  bigint)

 STORED AS carbondata TBLPROPERTIES

('SPATIAL_INDEX'='geoid',

'SPATIAL_INDEX.geoid.type'='geosot',

'SPATIAL_INDEX.geoid.sourcecolumns'='longitude, latitude',

'SPATIAL_INDEX.geoid.level'='21',

'SPATIAL_INDEX.geoid.class'='org.apache.carbondata.geo.GeoSOTIndex',

'SPATIAL_INDEX.geoid.conversionRatio'='1000000',

'SORT_COLUMNS'='timevalue,geoid,regionid,cellkey');

注：
1. 'SPATIAL_INDEX'='geoid'：用於設定空間編碼的欄位名，當前表中欄位名為geoid；
2. 'SPATIAL_INDEX.geoid.type'='geohash'：用於設定空間編碼的生成方法，當前設定為GeoSOT，考慮到行業內還存其他在多種網格編碼系統，比如GeoHash、Google S2、Uber H3。CarbonData網格編碼支援外掛化能力，可以支援不同業務場景快速引入匹配的網格編碼系統。；
3. 'SPATIAL_INDEX.geoid.sourcecolumns'='longitude, latitude'：用於指定計算空間編碼的引數欄位，需要設定為經緯度對應的欄位名稱；
4. 'SPATIAL_INDEX.geoid.level'='21': 基於GeoSOT計算空間編碼需要設定柵格等級，當前設定為21；
5. 'SPATIAL_INDEX.geoid.class'='org.apache.carbondata.geo.GeoSOTIndex'：設定空間索引的實現方法，當前設定為GeoSOT的實現演算法；
6. 'SPATIAL_INDEX.geoid.conversionRatio'='1000000'：經緯度小數點後的位數可以確定柵格資料的精度，一般場景下柵格資料的精度是固定的，經緯度就是一個具有固定位數的小數，通過該引數來設定系統內的經緯度小數位數。

3.2 時空查詢加速

在使用多邊形作為查詢條件時，簡單的方法是提前多邊形的外接矩形先進行粗過濾，再對查詢結果進行精過濾。精過濾過程就是將每個粗過濾的查詢記錄與多邊形進行關係判斷，識別出在多邊形內部的記錄。

點和多變形的關係判斷非常耗時，空間資料庫的這類查詢一般是將多邊形轉化為網格編碼的線段集，如下圖所示，淺藍色為多邊形過濾條件，可以將該多邊形變換為有序的網格編碼線段集{11-15，20，22，36-37，48}，將線段集作為資料庫底層過濾條件，可以將複雜過濾方式轉換為簡單過濾方式，並複用CarbonData的高效過濾下推能力。

基於CarbonData的電信時空大資料探索

時空索引的關鍵點在於如何高效的將多邊形轉換位網格編碼的線段集，通過對該流程分析，並與行業經典演算法進行比較，探索出一種新演算法解決該問題，相比較行業經典演算法，新演算法再剖分效能上有8倍的效能提升，在複雜多邊形的處理上更具效能優勢，並可將該優勢擴充到支援多邊形列表查詢場景。

基於CarbonData的電信時空大資料探索

3.3 優化效果

基於CarbonData的電信時空大資料探索

基於CarbonData增加時空數倉能力，SQL查詢資源開銷為優化前的1/5， 其中SQL耗時提升1.5倍，併發能力提升3倍。

3.4 線性擴充套件

CarbonData在資料排序機制上比較靈活，除了提供global sort能力外，還支援local sort，該能力可以大幅提升資料入庫效能，在實際的交付應用中，大多采用local sort方式。資料在空間位置上的分佈是唯一的，在超大規模交付場景中，為保證查詢效能不受影響，需要考慮如何避免同一入庫批次內的相同位置資料分散到不同的入庫節點。短期可以基於“分割槽”和“分桶”機制進行相關實踐，長期看需要考慮時空密度和時空潮汐，制定配套的時空負載均衡策略，相關研究已經啟動，並取得初步成效。

3.5 外掛化

時空能力是基於外掛化的模式進行開發，整個外掛包主要包括兩個部分：

1、 對空間資料經緯度到空間網格編碼的轉換以及各種基於網格編碼進行空間分析的演算法實現，目前基於GeoSOT演算法，後續隨著演算法的演進可以獨立進行迭代更新；

2、 基於CarbonData提供的索引介面，只需要在安裝部署時作為外帶Library載入到執行環境，建立資料表時指定外掛包內支援的空間索引型別以及演算法即可使用。

基於外掛化的能力，CarbonData原有的多維查詢能力不受影響，通過對業務資料和查詢特徵進行充分識別，制定合理的sort column定義，在綜合查詢效能上應該會有較大收益。同時時空能力可以獨立於CarbonData進行演算法演進，並支援對於其他場景的介面擴充。

4 應用場景舉例

人的日常活動離不開道路和樓宇兩大類場景。實際業務分析過程中，除了對某個區域的地表進行整體分析外，還涉及道路和樓宇兩類高價值場景的應用進行講解。

4.1 道路分析

基於CarbonData的電信時空大資料探索

示例1：重點道路分析場景

--SQL示例1—
select longitude, latitude, kpi
from <table>
where in_polyline_list('LINESTRING (100.785924 4.464369,100.785924 4.446571)' , 1000);

使用 SQL 語句對這些線路輻射範圍內的資料進行過濾、彙總分析，獲取網路體驗相關的kpi指標，提供直接支援製圖、製表的道路、地鐵、高鐵網路效能分析資料。SQL語法細節可以參考Carbon社群介面說明文件。

對返回的道路經緯度和KPI進行渲染，得到如下效果：

基於CarbonData的電信時空大資料探索

初步驗證，polyline總長度為50公里，快取區為1000米，查詢返回記錄數為25832條，SQL執行耗時為3.6秒。

4.1 樓宇分析

樓宇相關場景分析，一般分為2D樓宇分析和3D樓宇分析。2D樓宇分析時，建築物一般用Polygon物件表達，因此需要SQL語句上支援Polygon物件查詢相關操作。業務表裡麵包含經緯度欄位和通訊網路相關指標，空間維表包含建築物型別、建築物輪廓（Polygon物件）、建築統一編號。3D樓宇分析時，需要增加樓宇高度資訊。

按建築物列表進行業務分析時，一般需要支援對多邊形取並（OR）的操作。除此外，可能會出現“回”字形建築。因此需要提供多樣化的多邊形關係的操作方法，SQL語法細節可以參考Carbon社群介面說明文件。

基於CarbonData的電信時空大資料探索

示例2：2D樓宇分析場景

查詢某城市所有學校建築的通訊網路訊號覆蓋。先選用“學校”作為過濾條件，由空間維表獲取對應的Polygon物件集的臨時表t2，再通過業務表t1與t2進行join獲取在Polgyon內的所有記錄，最後按照polygon進行聚合，並按Polygon返回對應的業務指標。

--SQL示例2--
select t2.polygon as polygon, sum(t1.data.kpi ) as kpi
from <table> t1
inner join
(
select t2.polygon, t2.type from buildingTable as t2 where t2.type = “school”
) on in_polygon_join(t1.geoid,t2.polygon)
group by t2.polygon;

對返回的Polygon和KPI進行渲染，得到如下效果：

基於CarbonData的電信時空大資料探索

示例3：2D樓宇柵格分析場景

查詢某CBD的建築物內部通訊網路覆蓋分佈。先用CBD的範圍獲取該範圍內的Polygon物件列表，再用Polygon物件列表作為查詢條件獲取對應業務記錄，最後按網格的經緯度進行聚合，返回網格經緯度和對應業務指標。

--SQL示例3--
select longitude, latitude, sum(kpi)
from <table>
where in_polygon_list('POLYGON ((116.292365 39.845140,116.292477 39.845165,116.292523 39.845045,116.292291 39.844993,116.292245 39.845113,116.292365 39.8451402470383)), POLYGON ((116.292477 39.845165,116.292365 39.845140,116.292335 39.845218,116.292449 39.845243,116.292479 39.845165,116.292477 39.845165))
','OR')
group by longitude, latitude;

對返回網格的經緯度和KPI進行渲染，得到如下效果：

基於CarbonData的電信時空大資料探索

示例2.1是按整個建築進行聚合，獲取整棟建築的指標，在進行某些熱點區域分析時，還要分析建築內部指標分佈情況。

初步驗證，對1000個多邊形取OR進行查詢，返回結果記錄數22545條，SQL執行耗時為4.333秒。

示例4：3D樓宇分析場景

體育館、音樂廳、購物中心、機場、火車站人流量比較大的場館在網路實際運營過程中需要重點分析，需要了解每個樓層的立體空間的網路分佈情況。行業內已經提供了按經度、緯度、高度建模的三維空間資料庫，考慮通訊行業在高度上訴求與人的活動和樓的高度有關，並不是所有地區都存在大量的高度資訊，因此高度資訊暫時不參與時空排序，僅作為一般維度參與業務分析。

--SQL示例4--
select longitude, latitude, height, sum(kpi)
from <table>
where in_polygon_list('POLYGON ((116.292365 39.845140,116.292477 39.845165,116.292523 39.845045,116.292291 39.844993,116.292245 39.845113,116.292365 39.8451402470383)), POLYGON ((116.292477 39.845165,116.292365 39.845140,116.292335 39.845218,116.292449 39.845243,116.292479 39.845165,116.292477 39.845165))
','OR')
group by longitude, latitude, height;

使用建築物的輪轂作為查詢條件，獲取到經度、緯度、高度和業務KPI後，進行3D渲染，展示立體樓宇的外立面和每個樓層的業務分佈，得到如下效果：

基於CarbonData的電信時空大資料探索

在進行3D樓宇分析時，因為資料精度問題，可能部分資料偏移到樓的外部，需要對樓宇的多邊形進行適當外擴，確保業務資料查全。

5 技術展望

基於CarbonData的電信時空大資料的探索的初衷是解決產品查詢效能問題，通過我們的實踐看，帶來的收益遠不只是查詢效能大幅提升。

常用的資料庫有關係型資料庫、空間資料庫、圖資料庫，為滿足不同場景的業務分析和使用者最佳體驗，需要選用合適的資料庫。這樣會導致業務進行融合分析時，依賴多種不同分析引擎，且業務分析流程冗長。基於CarbonData的時空大資料能力使得“湖倉一體”的融合分析成為可能，在湖倉內部使用統一SQL完成普通資料分析和時空分析，大大提升研發效率和湖倉架構的健壯性。

CarbonData的SQL介面還不是行業標準介面，後續計劃完成GeoMesa與Carbon對接，提供符合OGC標準的通用時空查詢介面。另外，時空分析的查詢流程包括了資料過濾、聚合、製圖，3D場景下還涉及3D建模，這幾個場景都可以通過GPU加速獲得極大效能提升，未來是否可以通過硬體加速提供極致的使用者體驗，讓我們拭目以待。

 

點選關注，第一時間瞭解華為雲新鮮技術~

相關文章