三、金融業企業服務匯流排鏈路追蹤監控分析平臺的建設實踐--CASSANDRA儲存方案

上篇我們講了ORACLE的儲存方案，知道這種方案有很大缺陷，只能做一個臨時的方案，18年的時候我們啟動的第二波改造行動。
開始的時候我們考慮了使用HBASE來儲存資料，使用hbase儲存資料其實再好不過，但是，需要自己搭建環境並運維，我們調研了一段時間，hbase依賴的元件太多，維護困難，就直接PASS掉了。

一、首先簡單介紹下CASSANDRA原理及工作過程

架構： 簡單說就是 一致性hash + Gossip。
Gossip：負責維護叢集狀態
一致性hash：組織資料如何在叢集節點中儲存。

寫資料：依據LSM-TREE實現，其核心是，假定記憶體足夠大，因此不需要每次有資料更新就必須將資料寫入到磁碟中，而可以先將最新的資料駐留在記憶體中，等到積累到足夠多之後，再使用歸併排序的方式將記憶體中的資料合併追加到磁碟隊尾，能顯著地減少硬碟磁碟臂的開銷，寫入操作主要包含以下4個步驟
（1）記錄資料到commit log
（2）寫資料到memtable
（3）當commit log的size達到閥值或者memtable的size達到閥值時，將memtable中資料flush到SSTable中，flush完成後清空commit log和memtable
（4）sstalbe Compaction.

讀過程：
(1)檢查 memtable
(2) 如果開啟了row cache， 讀row cache
(3) 讀Bloom Filter，Bloom filter用於檢查當前查詢的partition key位於哪一個SSTable中。
(4) 如果開啟了partition key cache，讀partition key cache。partition key cache是partition index的快取。
(5) 如果在partition key快取中找到了partition key,直接去compression offset map中，如果沒有，檢查 partition summary
(6)根據compression offset map找到資料位置
(7)從磁碟的SSTable中取出資料
如下圖所示。


二、cassandra設計一般原則。
1、避免實時熱點資料寫：
小表：無需關注；
大表：叢集中每個節點（假設各節點效能一樣）接收的資料應該基本相同。
2、避免查詢擴散：
一次查詢，儘量在一個節點上查出所有資料，避免擴散到多個節點查詢資料。
3、避免使用cassandra索引：
小表：可以使用，如基表等資料量少且資料固定。
大表：禁止使用。
4、Row cache： 查多寫少時使用，寫多查少時禁用
5、避免批量提交資料。

三、設計方案
上篇《ORACLE儲存方案》我們已經講了，我們會儲存兩種資料：統計資料及明細資料，明細資料量大、統計資料量小，下面我們以明細表來講解百億級資料的儲存及查詢，以統計表講解多維報表的實現。
1，明細資料儲存：
明細主表：
create table m_trace(
traceId text,
side text,
spanId text,
…
primary key(traceId,side,spanId)
)with compaction = {‘class’ : ‘TimeWindowCompactionStrategy’,‘compaction_window_size’:'6,‘compaction_window_unit’:‘HOURS’}
and default_time_to_live = 864000
and gc_grace_seconds = 60
and dclocal_read_repair_chance = 0
and read_repair_chance = 0;
索引表：
create table m_trace_idx_by_uri(
traceId text,
strTime text,//形如202011212030
requestUri text,
side text,
spanId text,
…
primary key((requestUri,strTime),side,traceId)
)with compaction = {‘class’ : ‘TimeWindowCompactionStrategy’,‘compaction_window_size’:'6,‘compaction_window_unit’:‘HOURS’}
and default_time_to_live = 864000
and gc_grace_seconds = 60
and dclocal_read_repair_chance = 0
and read_repair_chance = 0;

		程式碼說明： 	
		a、Partition Key：選擇或設計一個合理的Partition Key可以避免熱點資料、避免查詢擴散。明細主表中的分割槽鍵是traceId,索引表的分割槽鍵是（requestUri,strTime)，它們都有一個特點，即：同一時刻，存在大量的鍵值。 對寫，可以避免出現熱點資料，資料均勻流向各個節點；對讀，明細表根據traceID查，精確查詢效率高，索引表根據URI及時間聯合查詢，集合查詢，每次查詢只從一個節點讀資料（應用層控制，每次只查一個分割槽的資料），CASSANDRA是按順序報錯，DB讀的時候按塊讀入記憶體，因此大多數情況一個IO就可以查詢出大量需要的介面，效率也非常的高。
       b、Clustering Key：Clustering Key可以用來在Partition內部排序，利用這個特性來實現列表查詢的分頁功能，如，索引表查詢出大量資料時需要上下分頁。 利用這個特性實現翻頁還是有一些侷限，比如，side,traceId ，traceId是在side下面是按順序排列的。
       c、壓縮策略：TWCS
    	理由：trace都是時序類資料（時序是根據primarykey判斷，一個primarykey只出現在很短的時間段內），資料只有insert，沒有update,資料的生命週期是10天，過期會清理。需要特別注意亂序問題，比如說，正常情況下某個traceId只會出現在某一時刻，但是因為某些原因，比如程式碼BUG，造成採集上了的相同traceId持續出現幾天，這種情況會造成SSTABLE不能及時清理（traceId分佈在的所有SSTABLE都過期時才能刪除），為避免這種情況，需要在primarykey的末尾加上時間相關的鍵值，避免造成大量資料不能及時清理。
    	d、read repair：dclocal_read_repair_chance = 0  read_repair_chance = 0
    		 這兩個引數是調整讀修復的概率，並不能完全禁止。
	    e、資料清理：default_time_to_live = 864000   gc_grace_seconds = 60
		    default_time_to_live：定義資料生命週期
		    gc_grace_seconds：預設10天。刪除資料，本質是插入一條tombstone資料,此參數列示tombstone資料能夠保留多長時間才會被真正刪除。當Cassandra進行compaction操作並且一條資料的deletion time + gc_grace_seconds小於當前時間時，此條資料才會被真正刪除。
		    我們的整張表設定一個預設的_time_to_live屬性。每條資料都被標記為一個TTLs;如果一條記錄超過了表級別的TTL，Cassanda會立即將它刪除，而沒有標記墓碑或者compaction過程，因此gc_grace_seconds設定很短或不設定都是可以的。
		f、非同步提交、禁止批量提交
			非同步提交：主要是跨機房儲存，能提高應用的併發能力。
			批量提交：若批量提交的資料都在同一個節點，並且這些資料之間存在事務關係，否則不能使用批量提交。

2、多維分析報表

       待補充

四、反思
待補充