在項目中使用GeoMesa作爲時空索引數據庫，打算了解下這個組件如何做到索引數據，又是如何做到數據查詢的。本文主要是瞭解GeoMesa的索引原理(空間Z曲線和GeoHash算法)以及GeoMesa-HBase查詢流程。
空間Z曲線與GeoHash算法：
下圖中充滿空間的Z形狀的曲線就叫Z曲線，又叫peano曲線：
GeoHash算法就是對這些曲線進行編碼：
對這個大區間按左右進行劃分，左邊表示0，右邊表示1，再按上下進行劃分，下邊爲0，下邊爲1，這樣就可以用序號表示一塊空間。字符串越長，表示的範圍越小，空間位置越精確，字符串越短，表示的範圍越大越寬泛，字符串越相似表示距離空間越近(跳變情況下不是)。這樣就可以將經緯度降維成一維字符串，如果再加上時間，就是將時空三維信息使用一維表示。
當空間形狀不是點而是線之類的集合形狀時，使用XZ-Ordering曲線表示時空信息，原理和上面類似。
索引信息在HBase中如何表示：
GeoMesa HBase構建索引主要是將空間和時間、屬性等信息組織在rowkey中。以空間點數據爲例，根據Z曲線降維之後的RowKey設計如下：
ShardKey(1 byte)+Z2(x,y)(2 bytes)+FeatureID
以時空點數據爲例，RowKey設計如下：
ShardKey(1 byte)+Epoch Week(2 bytes)+Z3(x,y,t)(8 bytes)+FeatureID
所以GeoMesa有個蛋疼的地方，因爲它的索引是通過RowKey展示的，所以每建一種索引就要將全量數據完全拷貝一份，數據量多時非常磁盤資源！但是它比ElasticSearch確實提供了豐富的多的空間功能，而且性能也表現得不錯。
GeoMeas-HBase查詢時，底層是如何進行的：
高併發查詢的過程中發現HBase RegionServer的CPU佔用率會特別高(現在想想當時使用ElasticSearch高併發的時候也很高，當時40個核的服務器ES能用掉28個...)
GeoMesa-HBase查詢數據，主要是解析查詢的CQL語句，採用啓發式策略估算從哪個索引表中獲取數據最快(真正執行查詢時只會查詢一個索引表--此時這張表稱爲主索引)。內部主要是解析CQL語句，確定查詢語句內部包含那些檢索(空間檢索，時空檢索等等)，每一種索引都會對應一個常量值，根據這些常量值做計算，選擇耗時最少的索引作爲主要查詢的索引(之前的文章說過，一種索引會對應一張數據庫表，選擇索引也就選擇了要查詢的數據庫表)。
確定要查詢的表之後，接着就是構建對應的迭代器獲取數據。這部分代碼在QueryPlan.scala類中的createPlan()中，內部會根據查詢條件，將對應需要獲取的RowKey構造成多個Scan：
這些Scan是會將用戶輸入的空間範圍按照上面介紹的進行講一個矩形不斷的劃分成4個小格子，如果劃分後的小格子是完全包含在用戶輸入的空間範圍內，則這個小格子就是一個Scan，否則還要繼續劃分，直到劃分到一定的空間精度爲止。不能完全包含的，那就是相交關係。並且 這些Scan會按照rowKey的min，max進行排序：
將多個Scan扔到線程池併發執行，所以一個CQL語句執行的時候，纔會那麼的耗費內存以及CPU！：
參考：
https://malagis.com/spatial-databases-26-z-ordering-curve.html(Gis空間數據庫)
https://www.jianshu.com/p/9a13825edbda(GeoMesa索引機制)
https://blog.csdn.net/weixin_41834634/article/details/89203552(GeoMesa RowKey設計)