為什么AppDynamics重構指標服務時選擇了HBase而不是別的NOSQL

AppDynamics 公司的 智能程序平臺 可以幫助客戶分析軟件程序的性能、用戶體驗和業務影響等，并可以提供實時的監控、故障解決和分析等服務。智能程序平臺的核心是負責記錄、跟蹤和比較性能指標的指標處理引擎。在軟件程序復雜度爆發性增長和許多公司把單一程序拆分成微服務的背景下，指標處理引擎需要采集和分析的指標也變得極度復雜和龐大，因而他們不得不重構了整個系統。 Gautam Borah 在AppDyamics公司負責產品設計和開發基于大數據技術的下一代指標處理系統，他最近在 博客 中記錄了這次重構的選型情況。

AppDynamics的程序性能管理（Application Performance Management ，APM）代理在為幾千個程序幾百萬行代碼收集性能指標，它們支持包括Jave、.Net、Node.js、PHP和Python等在內的多種語言和框架。可收集瀏覽器、手機和服務器程序數據，還有擴展程序從各種異構程序和基礎設施模塊收集數據。收集到的指標被周期性的發送給指標處理引擎，它把各種維度的指標收集起來再以不同角度的視圖展示出去。

最初的指標處理引擎是基于MySQL的，但當指標指數級的增長之后，要處理的指標數已經逼近MySQL的物理上限。研發團隊總結對智能平臺的主要需求是：

• 處理的指標總量要比當前翻許多倍
• 各個維度的數據保留期限要延長很多
• 實時收集業務集群指標數據，并要做集合運算
• 要支持批處理
• 系統容錯，消除單點故障
• 軟件升級不停服

研發團隊進行了周密的選型。StumbleUpon的OpenTSDB和MetaMarkets的Druid都是不錯的時間序列數據庫，但由于指標處理引擎的需求太特別，用它們不太合適。在能提供容錯和橫向擴展的開源鍵值型存儲中，最主流和使用最廣的就是HBase和Cassandra了。

最終選擇的是HBase，勝出原因也是它的分區策略是按主鍵有序排列的范圍分區，這樣就可以自由的按時間范圍進行查詢，時間跨度大也無所謂，并且方便使用各種集合算法。

HBase的鍵值對存儲在表中，而且每張表都被拆分成多個Region，每個Region中都存儲著一段按主鍵排序的連續數據，即表中從一個Region的初始主鍵開始到結束主鍵的范圍內的所有數據都存儲在這一個Region中。Hortonworks有 文章 詳細解釋了這個機制。

Cassandra分區策略與此不同，它的節點是按一致性哈希環分布的，所有的主鍵都轉換成Murmur3哈希值然后放在某個節點中。Datastax的 文章 中解釋了這種分區策略。

為什么按主鍵做范圍查詢如此重要？

如下圖所示的AppDynamics程序性能儀表盤提供了整個程序性能指標的拓樸視圖。儀表盤展現了業務程序的調用鏈，還有每分鐘調用率、平均響應時間、每分鐘錯誤率和每分鐘異常率等性能統計。

拓樸圖、調用鏈、性能統計等都是直接按時間范圍從指標庫里查出來的。典型的查詢語句是：

Select SUM(totals calls) from METRICS where metricID = m1 and time in range (t1, t2), t1-start time, t2 – end time.

Select AVG(response time) from METRICS where metricID = m1 and time in range (t1, t2), t1-start time, t2 – end time.

Select SUM(total errors) from METRICS where metricID = m1 and time in range (t1, t2), t1-start time, t2 – end time.

解決這個問題的一個最簡單設計就是把metricID做為表的主鍵，把時間點做為表的字段，在某個時間點采取的指標值就保存在對應時間點的字段里。HBase和Cassandra都支持這種設計，而且因為主鍵是metricID，不管HBase還是Cassandra，這個指標的所有值都會保存在一個分區里。查詢一個時間范圍內的指標值時，只需要把對應的時間點里的值取出，再加上上面查詢語句對應的算法就可以了。

但這個設計在現實中是不可行的，因為不管理論上還是工程上，一張表所能支持的字段數都是有限的。在指標處理系統中，一分鐘至少要保存一個值，一天就有幾千個值，一星期就會有幾百萬，而一年則會有幾十億。不可能設計一張表有這么多字段。

一個相對好得多的改進設計是把主鍵按時間段分區。即主鍵是metricID加上時間段，對應的時間段里的各個時間點的值，則和上文一樣作為表的字段保存起來。比如以一個小時為一個時間段，則從12：00AM到12：00PM總共會有12個主鍵值。有一篇 文章 講述了Cassandra如何用這個方法為時間序列問題建模的，具體就是它的組合主鍵。使用metricID作為分區鍵，使用時間段的值作為集合鍵，收到的指標值作為表的字段保存起來。Cassandra的存儲引擎底層是使用組合字段來存儲集合值的。所有相同分區鍵對應的邏輯行，實際上是做為一個物理寬行保存的。通過這種方法，Casasandra每個物理行可以支持20億個字段。

HBase則沒有組合主鍵的概念，它的主鍵就是一個字符串。數據在HBase里的保存是按照主鍵的字母順序排序的，主鍵值相鄰的記錄會保存在同一個分區里，即Region。如果主鍵設計的好的話，幾年的指標數據都可以保存在HBase的一個Region中。

這個概念很重要，對這個用例也非常有用。因為一個很長的時間范圍內的數據都存儲在同一個Region中，那即使做一個半年內甚至兩年內的集合運算，它也是在一個Region Server內部計算，算完了只把結果返回給調用程序，因而極大的減少了網絡流量。如果不是這樣的設計，那數據就可能會分散在多個分區（甚至是多臺機器）上，做集合運算就要把數據從各個分區集中到一個客戶端程序上，它做完集合運算后，再把最終結果發送到調用程序。這樣代價非常大。

除此之外，棄用Cassandra還因為它缺少幾個HBase已有的關鍵功能：

1. HBase允許把指標分配到不同的列族里，然后以列族為單位設置過期值。Cassandra則以Cell為單位設置過期值，而且對相同類型的Cell要逐一設置，就使得存儲非常臃腫。2015年11月發布的Cassandra 3.0解決了這個問題。
2. HBase的設計是在可用性的基礎上再提供了一致性，由于指標系統的策略引擎是不斷計算的，所以這個功能非常關鍵。想進一步了解CAP理論可以參考 這篇文章 。

來自： http://www.infoq.com/cn/news/2016/07/AppDynamics-HBase-NOSQL