不生產博客，只是官網的搬運工
https://docs.cloudera.com/documentation/enterprise/5-16-x/topics/kudu_background_tasks.html
kudu依賴很多後臺任務來完成重要的任務，包括flush數據到磁盤，compact數據，釋放磁盤空間等等
maintenance manager
這個服務調度並且運行任務，在任意時刻，這個服務會根據當前環境來決定下一個任務的優先級，例如減輕內存壓力，提升scan性能，釋放磁盤空間。可以通過修改配置參數maintenance_manager_num_threads來控制後臺任務的線程數
kudu1.4，該服務的功能是提高配置線程數的利用率，之前，每秒最多安排4次維護的任務，但是現在只要有可用的線程，維護任務將立即執行，
Make sure that the --maintenance_manager_num_threads property is set to
at most a 1:3 ratio for Maintenance Manager threads to the number of data
directories (for spinning disks). This will improve the throughput of
write-heavy workloads.
確保這個線程數被設置與數據目錄數比例最大爲1:3(數據目錄數？tablet指定了一個data和wal，難道是一個節點算一個目錄嗎?)，這將提高寫的吞吐量
flush數據到磁盤
將數據從內存刷到磁盤減輕內存的壓力，提高讀性能通過MemRowSet 行存，寫的快，diskRowSet列存，讀的快
後臺刷數據的任務包括FlushMRSOp和FlushDeltaMemStoresOp,與這兩個操作有關的指標有flush_mrs和flush_dms
With Kudu 1.4, the maintenance manager aggressively schedules flushes of
in-memory data when memory consumption crosses 60 percent of the configured
process-wide memory limit. The backpressure mechanism which begins to
throttle client writes was also adjusted to not begin throttling until
memory consumption reaches 80 percent of the configured limit. These two
changes together result in improved write throughput, more consistent
latency, and fewer timeouts due to memory exhaustion.
比較重要，貼原文
使用kudu1.4，該服務調度刷盤任務當佔到已配置內存的60%(已配置的是靜態資源池嗎)，背壓機制開始限制客戶端的寫入速度當內存超過80%，這兩參數改變將提高寫效率，更一致的延遲？，更少的超時,尷尬，從cdh找了找沒發現flush相關的配置
compact磁盤的數據
kudu不斷的執行一些compact任務爲了保持讀寫性能(小文件過多會影響scan性能)
將多個DiskRowSets合併成一個DiskRowSets，由CompactRowSetsOp負責
kudu也運行兩種類型的delta合併，MinorDeltaCompactionOp和MajorDeltaCompactionOp，對於更多信息可以去github看kudu的設計文檔
預寫log 辣雞回收
kudu爲每個tablet維護一個wal，被切成d大小固定的segments，tablet將定期roll出新的wal log段當達到一定大小時(大小由--log_segment_size_mb決定)，搜了下，cdh6.0，參數已經改了嗎
使max_log_size，意思也是roll新Log前舊log的大小
爲了節省磁盤空間，減少啓動時間，後臺任務LogGCOp嘗試gc老的log(不需要它來保證數據持久性，因爲數據已經持久存儲了)
歷史tablet gc
kudu使用mvcc機制來確保快照scan可以與新的dml隔離，因此，應該對老的歷史數據進行gc來釋放磁盤空間，kudu不會刪除最新最新版本的row、數據，但會刪除不再可見的歷史數據