大家好，我是360的王峰，我今天主要通過Cassandra在多場景下的應用來介紹一下Cassandra在360落地的情況。
我會從以下這幾個方面進行介紹。首先介紹下Cassandra落地的背景和業務情況，接著看看當前業界的一些進展，然後我還會分享對資料庫發展趨勢的一些個人看法，最後給大家介紹一下Cassandra在360未來的一個定位。
關於我
先介紹下我自己，我大概在2009年就開始接觸Cassandra的一些早期版本了，當時也是為了在一些百度的專案中得到一些簡單的應用。接著我來到了360，從2011年5月開始，藉著360雲盤業務的發展，才實現了Cassandra的大規模落地。目前我主要在負責基礎雲大資料體系的建設，還有云上彈性的大資料。
Cassandra和360的歷史回顧
首先我想跟大家簡單回顧一下Cassandra的歷史。
Cassandra可以最早追溯到2006、2007年的兩篇在頂級會議上發表的論文，一篇是谷歌關於bigtable的，還有一篇是亞馬遜關於Dynamo的。然後次年，也就是從2008年開始，以bigtable架構為基礎的兩個產品，Hypertable和Hbase基本上就已經出來了。
在2008年，Facebook的兩位工程師也基於這兩篇論文實現了Cassandra的一個基本系統。在當年這個時間點，其實還有比較有意思的一點，就是Dropbox的一個出現。這個時間點之後，國內各家公司也是以Dropbox為藍本，開始爭相推出自己的網盤。
在2008年7月，Facebook就已經把Cassandra放出來了。2009年，Cassandra作為孵化專案被Apache社群所接受，之後在2012年正式成為頂級專案。最早從2010年開始，國內就有一些公司開始模仿Dropbox推出面向個人的儲存服務了。
2011年之後，大家都紛紛看到了商機，這個趨勢也就更加的明顯。那一年其實大家會發現出現了很多網盤，包括115、酷盤、華為、金山、百度，當然包括360等等。現在來看，其實很多網盤已經不存在了。那時360選擇Cassandra作為後端的儲存，以支撐整個360雲盤的產品線。當初Cassandra的版本也不是特別的穩定，所以我們當時就做了很多的深度定製化。
另一個時間節點就是2015年11月了，當時是Cassandra 3.0的釋出，我們發現Cassandra社群發展的很快，實現了我們很多之前不是很完善的功能。因此我們準備在未來的兩三年更新到某個社群版本。
直到2018年7月份，我們正式切換到了社群的3.11.1版本，開始在企業雲盤和億方雲上大規模的應用，並一直使用到現在。當然，我們也做了一些簡單的定製化，但現在Cassandra社群的版本比之前版本有了翻天覆地的變化。2020年，Cassandra 4.0發了幾個Alpha/Beta版本，未來我們也可能在這方面做一些關注。
360資料與應用場景
360的資料其實主要是兩塊，一方面是網際網路，另外一方面是安全。安全資料肯定是全球檔案的最大樣本庫，還包括行為庫、網址庫、域名庫，這些都是和安全相關的。
當然，360還有自己網際網路的業務。比如下圖中以億方云為代表的個人儲存，還有以視訊為核心的智匯雲，就是圍繞著視訊生態來做的一些上層的產品。所以整體業務就涉及到大量的結構化、半結構化、非結構化的儲存，包括視訊圖片、檔案日誌。這些可能都是360資料的一部分，其中很大的一部分大資料可能以Hadoop生態為主。
對於我之前說的類似這種個人資料儲存、個人圖片的半結構化、非結構化的資料，其實我們大量的在用Cassandra做一個儲存。
我詳細地介紹一下Cassandra在360的一些應用場景，整體上可以歸結為幾類。
場景一：通用物件儲存
這就是我上面說的以個人雲端儲存為契機發展起來的一套系統。這套系統從2011年最初的15個節點，到15年個人雲端儲存的競爭激烈時，已經達到14,000個節點。當然，對於國內做個人雲端儲存的服務商來說，如果使用者數越多，成本可能也越高。
因此在15年其實就有一些分化了，比如百度雲盤在這個基礎上有持續的投入，使用者數其實也在一直持續的擴大。在360這可能就有所收斂，把個人云盤往企業雲盤、安全雲盤上轉型，資料量和叢集的規模會有所下降。360對個人儲存這塊還是有比較好的一個預期，因此還會繼續的發展，但不會有之前這麼大的規模。
對於通用的物件儲存有幾個特點：首先是資料的多樣化，有結構化、半結構化、非結構化的資料。尤其是圖片視訊這樣的非結構化資料會比較多。然後還有像我們內部的圖片服務。對於圖床、靜床這樣通用的公共服務也都基於這個，所以這就帶來了海量的資料儲存需求。其實這成本也是非常大的。
比方在2015年，不管是百度網盤還是360雲盤，每年的成本都大概在10億以上。換句話說，300臺全新機器的Cassandra叢集，可以在一星期到兩個星期記憶體滿。所以對於這塊業務來說，它的成本訴求是非常大的。
另外由於它是線上訪問，那它對持續線上的要求也會比較高。這樣其實又帶來一些挑戰，比如你首先需要利用好自己的現存的存量空間，才能讓成本越來越低。如果持續遇到大量的刪除和更新，如何及時釋放一些空間，以及如何保證資料的可靠性。因為它本身基於local append的方式去做的LSM模型，所以需要通過Compaction合併減少SSTable的數量。
如果在資料量很小的情況下，這些挑戰其實還好。但當資料規模飛速地增長時，這都是要面臨的挑戰。所以我們在主要場景上對平臺還是做了很多改動的。
場景二：輕量資料分析的應用
Cassandra應用還是主要以寬表的儲存場景為主——資料來源通過抽取服務，落地到Kafka，接著進行批流計算。比如通過Flink做一些OLAP的預處理，生成視覺化報表，同時把資料落地到Cassandra上，通過spark做一些分析。
它使用的場景其實也很簡單，第一個就是對360大量樣本漏洞的掃描。在安全領域有一個首發的優勢，誰能先找出漏洞，做出的貢獻是最大的。所以我們需要的就是快速樣本掃描的應用，這也是基於Cassandra做的。
另外就是做一些輕量的BI分析，最主要的還是通過Flink的預處理形成了一個輕量的Pipeline。這在早期的安全業務和小型業務上使用得會多一些。基本上它優勢就是極輕量化的部署，節點數量大概也就10臺以內就足夠了，主要是面向ToB的場景。
場景三：海量安全日誌全文檢索
第三種場景就是海量這種安全日誌的全文檢索，這在360是一塊比較有挑戰性的工作。360會有大量資料安全的日誌，安全分析師需要從日誌中去溯源，比方查詢一個APT攻擊。
像我們這種搜尋引擎，目前的建庫規模也就在千億級別。但在安全日誌基本上就是百萬億的級別，基本上都是在兩三個數量級以上的。
其次它沒有冷熱之分，一般搜尋大家更多會關心最近的資料，但是對安全來講，它是沒有差別的。 一個APT攻擊可能在數年前就已經埋下了，現在我們需要通過一些蛛絲馬跡，找出這些漏洞，這樣的挑戰實際上非常大。
我們最初通過流式資料建立索引，接著將索引存放在Cassandra中。然後資料是放在HDFS中。這樣每天要大概建千億級別的索引，這樣的規模實際上是非常大的。這兩套系統通過上層的一個BigSQL（我們研發的一套大SQL檢索）還有面向研發的這種SPL語言進行檢索。
另一方面，這是一套非常專用的系統，比如面向我國政府的需求量大的的場景。但他們資料規模並可能沒那麼大。將這種百萬億規模的海量的儲存架構落地到B端其實是不太可行的，所以這更像是一套專用的系統。
我們後來在做這塊的時候，是將我們在HBase層面的一套二級索引搬到了Cassandra上，也就相當於內嵌Lucence，從而提供全文檢索的功能，其實我們主要還是為了支援百億規模的檢索系統，讓我們可以很快的落地B端。
大家也可能會問為什麼我不用ES(Elastic Search)，這其實是基於兩點：
-
首先是Cassandra的架構，它支援從0到1， 1到n的這種靈活的擴充套件。
-
其次本身ES在我們實測中，在十億到百億級別的規模下，效能會相對好一些。但是我們架好Lucence後，其實百億級別的查詢檢索效能會稍微高一些。
場景四：時序與圖
這個場景想必大家也都比較瞭解，比如OpenTSDB能在HBase上執行，靠HBase為底層的基座，將資料按時序進行儲存，從而對上層的TSDB提供一些時序服務。如果大家瞭解JanusGraph，這其實也是可以建在HBase之上的。
當落地一些2B場景時，我們認為HBase和Cassandra在資料模型上是可以對等的，但Cassandra這種靈活性、小型化可能正是我們需要的，所以我們將服務跑在了Cassandra上。
下面是我們基於Cassandra做的一個圖資料庫，是一套網路資料分析的系統。這套資料庫主要儲存了DNS資料，像樣本的、認證的、證照一類的資料。 通過視覺化，我們可以進行一些關聯分析，做一些溯源。
這套系統對標的像是谷歌投資的一家以色列公司VirusTotal，還有國內的ThreatBook、Threat Graph一類的。這整套系統完全是基於Cassandra搭建的，360這套系統的競爭力還是相對比較明顯的。
如果綜合來看這這四種場景，360目前以通用的物件儲存為主，但同時我們也在嘗試擴充一些新的應用場景。
Cassandra的技術特點和優勢
那下面我們可以看下Cassandra的技術特點和優勢，這也是為什麼我們要持續發展Cassandra的原因。
我們更多看中的Cassandra去中心化的設計，它有架構簡單、可以輕鬆運維的特點。其次是持續可用，它可以持續寫入，不像HBase會有failover的時間間隔。
接著就是按需擴容。 HBase的架構是建立在HDFS之上的，在大規模的儲存平臺上，整體的成本會降低平攤的平均成本。但在中小型規模的應用場景中沒有這麼多的資料，我們需要一個小型化的資料庫儲存以滿足相同的需求。這就是我們常常說的從1個節點到n個節點的擴容，這一塊Cassandra的優勢是非常明顯的。
另外在Cassandra版本的迭代中，在這種跨IDC副本的儲存上，它也有很強的優勢。我可以很輕鬆地通過設定兩個IDC、一致性級別就可以構造同城多活的模式。對於一些關鍵的原資料儲存，我們就是這麼做的。
Wide-Column: Cassandra VS HBase
在寬表這一塊，我們可以通過下圖中幾個方面將Cassandra和HBase進行對比，其中有以下注意的幾點
-
高可用：Cassandra本身無中心，所以不會有單點故障。 HBase可能會有HDFS方面的單點故障， 也可能會有自身服務的單點故障，這都會導致整體MTTR（平均修復時間）時間較長。
-
資料恢復機制：Cassandra提供了Hinted handoff、讀修復、repair等一系列修復機制。HBase肯定依賴於HDFS的塊彙報、讀修復。從資料恢復效率來講，我個人認為相比Cassandra的EC更多通過的是Key-Value這種方式進行修復，可能HBase通過Trunk方式的修復力度會大一些。因此它的效率會更高一些，把EC的機制加進去之後會更明顯。
在SCAN效率上，因為HBase依賴於HDFS，所以它的OUTSCAN（繞過HBase本身直接掃描下面檔案）在批處理的場景下可能效率會更高一些。
在360中，HBase主要還是用於大規模儲存、高吞吐的場景，我們更多把它用於一種離線的資料分析場景，如網頁建庫這一塊。因為它能容忍訪問的抖動和Region在遷移過程中短暫的中斷。
對於Cassandra，我們更多會用在中等資料規模、低延遲的、高線上服務質量要求一些場景中。
360在Cassandra技術上的發展
360目前接觸Cassandra已經大約10年了，我們最早是基於0.7.3版本發展起來的。我們在這方面也做了很多的改動，前期主要是提高服務的穩定性、資料的可靠性，就是構建基本的能力。同時，我們也有一些故障自動恢復的Pipline之類的工具，可以加快恢復速度。還有通過臨時副本的機制保證Cassandra叢集能在最短時間內達到全副本的狀態。最後就是主備複製和同城雙活。
第二塊就是成本上的考量，我們的思路也很簡單。首先是儲存的異構和冷熱分層，通過EC可插式編碼降低資料的平均副本數。另外Cassandra本身是一套儲存系統，我們也嘗試用它的計算能力做一些離線的計算。
像我之前提到的，我們在轉型做2B的場景下做了一些小型化的方案，包括我們從1到N的平滑擴充。有些之前在HBase下場景，完全可以遷移到Cassandra上來實現。
360 Cassandra 改進示例 - 自修復（26：27）
我們現在用一些例子來展示我們在Cassandra下主要的一些改動，之前在技術上做了哪些方面的優化。
第一個是自修復，對於海量資料儲存遇到最大的困難其實是磁碟的故障率，如果伺服器超過了一萬臺，壞盤的機率是非常高的。因此我們不得不做一些和磁碟資料修復相關的事情，如果全靠人完成的話，那人力的開銷成本是非常大的。
我們前期也做了很多這方面的事情，比如我們需要基於規則去檢查smart control、硬體的一些資訊。如果我們監測到一個磁碟在未來幾天或一個星期磁碟可能會壞掉，在真正壞掉之前我們會做一些磁碟遷移的工作。當磁碟不可讀時，我們會啟動這repair task，從ring上做一些修復。當磁碟真正壞後，我們會自動上報維修，SA會在壞盤數積累到一定程度後進行統一的更換。換盤後，系統也會觸發一些恢復的邏輯，接著通過Cassandra常規的方式恢復資料。
另外是臨時副本，這點我們實現的比較早。 比如當三個節點中有一臺故障時，Coordinator會把副本寫到另一臺臨時節點上，等故障節點恢復後，再將資料恢復回來。這和社群的Transient Replication有一些區別，區別在於我們的寫入後只是一個暫存，使用者是不可見的，但社群版本在寫入臨時副本後使用者是可見的，因此我認為社群實現的會更好些。
這就是我們一些低運維的操作，當資料量大的時候，這些優勢就顯現出來了。我們當時最高峰時有一萬多臺機器，但真正在進行運維的只有一個人。到目前為止，大部分的東西都可以通過自動化平臺化來實現，所以我們以Cassandra為基礎的運維其實就一個人。
360 Cassandra 改進示例 - 資料分層與EC
EC是我們在2013、2014年左右實現的比較早的策略，主要是為了降低成本。當時個人雲端儲存發展過於迅速，結果導致我們成本上開銷較大，因此不得不實現EC。 隨著後期的優化，我們整體上對Cassandra進行了改造。
第一個是資料分層，我們更多的通過節點物理架構上的調整，可能裡面存在著NVME的儲存，同時也有HDD的儲存。當然有些表是通過EC的方式實現，這樣我們便會寫入NVME中，接著我們會按時間順序通過Compaction將它們寫入HDD中，再過段時間我們可能會用自己的rebalance機制將它寫入EC中。
通過這套機制，我們在成本上會有較大的降低。成本和可靠性是我們在Cassandra最主要努力的兩個方向。
業界/社群近年的工作
社群方面的工作我就不詳細介紹了，關於Cassandra 4.0的一些變動，這個DataStax同行做的幻燈片有詳細的介紹。
資料庫發展的趨勢
接著讓我來分享下對於資料庫發展的看法。
首先讓我們來看看DB-Engine下面兩張表，我們大概可以對比下各個資料庫排名，從而瞭解Cassandra的地位。我們可以大概看到Cassandra一直位於行業前十。在右圖寬表資料庫排名中我們可以看到，在寬表存取資料模型一樣的情況下Cassandra排名要比HBase高一些。
此外我整理了有大概三個方向的變化：
-
私有化部署往雲（雲原生資料庫）的轉變
-
NoSQL向NewSQL的轉變
-
單模到多模的融合
大家可以看左圖資料庫中，無論是SQL還是NoSQL，在database model中都有一個“Multi-model” 的標籤。很多資料庫其實都希望能支援多模的儲存。
從On-Premise向On-Cloud的轉變
展開來講，首先是私有化部署往雲的轉變。其實不止是資料庫， 其實從資料倉儲到資料科學，大家都在往這個方面轉變。右圖反映了分析資料庫儲存隨時間的變化，傳統的資料庫呈一個平穩上升的趨勢，如以BigQuery和Redshift為代表的資料庫，發展是比較快的。它主要的特點是存算分離和按需彈性。
NoSQL向NewSQL轉變
第二個是NoSQL向NewSQL的轉變。在上世紀70年代到2000年之前還是以TP強一致性的關係式資料庫為主，主要用於金融、電信的領域。
但2000年之後，隨著網際網路的興起，半結構化資料在急劇性的增長，以Mongo、Cassandra、HBase為代表的NoSQL資料庫也在2001年開始快速的發展起來，主要用於網際網路非結構化資料的儲存。
然而隨著像Spanner、F1論文的出現，NewSQL這方面的需求就開始變大，它既要求有TP的強一致性，也要求有NoSQL高效能、高擴充的靈活性，所以產生了兩種資料庫之間的融合。
資料倉儲也十分類似，如最早的Teradata、HANA，到現在代表NoSQL的Hive、SparkSQL， 包括今年比較火的Snowflake。
單模到多模的融合
大家可以看到從2010年往後，除了傳統的關係型資料，大量的半結構化非結構化資料增長的比較快，對這種資料的訪問需求其實也變得多種多樣，如物件訪問、全文檢索、時序分析、圖的查詢等等。能否對現有的資料庫或模式進行鍼對這些場景擴充，這也是很有需求的。
舉個例子，首先就是TiDB，國內很多小夥伴也應該聽過，是一套以做事務為主的資料庫。到後面，它就以針對事務分析一體做了延展。
對國外環境比較瞭解的小夥伴可能知道，有將Cassandra和ElasticSearch進行結合，從而實現全文檢索功能的案例。這相當於從WideColumn擴充到Search。
還有以NoSQL資料庫為基礎，進行構建Graphdb的引擎的場景，比如國內百度HugeGraph。
業界/社群可能的工作
以下的猜想只代表我個人的觀點，並不是社群的最終發展方向，主要有三個猜想。
首先是時序和搜尋的支援，從WideColumn向Multi-Model的發展。我知道DataStax很早將Solr融合到DataStax Enterprise中支援搜尋。
其次是NewSQL，Cassandra本身的事務在不斷的增強，那會不會有可能朝NewSQL的方向發展呢？
第三個是彈性雲化，這依賴於網路和硬體的發展，現在100GB的網路已經逐漸成為了主流。在未來的3到5年，整體的網路設施甚至可能會超過IO硬體的發展。那彈性的雲化可能會成為一個發展目標。現在我們已經有了對Cassandra進行了容器化的Cassandra K8s，這大大提升了Cassandra的隔離性和擴充性。這便可以把離線的計算力可以調動上去，從而實現離線上的混步 。
360的思考：未來如何定位Cassandra
最後我們說說Cassandra在360未來的定位。
360也經歷了從商業資料庫到開源到自研一個歷程， 所以我們在自研方面投入了很多力量，包括“高吞吐、低成本儲存”與“高效能、低時延儲存”的統一，希望提供一套整體的儲存基座。在上層資料庫層面，可能會做一些存算分離的調整，這樣我們便可以依託於Cassandra實現一些時序分析、企業搜尋、圖儲存分析以及表格/物件的場景。
我們對Cassandra的定位是希望它能做到高效能、低延遲、高擴充、輕量化、多模。但在未來2～3年可能會整體遷移到基礎儲存底座之上。
提問環節
1. Canssandra看起來可以適用很多的場景，但和專用的系統，如時序和influxDB，圖和圖資料庫Neo4j相比是否會存在劣勢？（47：05）
對於時序，Cassandra可以做底層基礎的底座，OpenTSDB可以利用Cassandra的資料模型實現持續資料的組織。
圖資料庫也同理，這是一種典型的存算分離的架構。如果你用Neo4j和現在這種模式實現的HugeGraph或JanusGraph相比，它有自己一套資料組織的方式，比如單機模式，可能效能會相對高一些。但這種基於Cassandra構建的圖資料庫的擴充性則會更優，這也是它特有的趨勢。
我們在用這種圖資料庫做網路安全分析時，在點查或多步鄰居這方面的效能能滿足我們絕大多數場景的需求。如果我們需要做圖計算的分析，我們可以用SCAN來載入Cassandra或HBase中的底層資料，再用Spark裡的GraphX做一些計算。總體來說，它的靈活性和可擴充性是一般Neo4j不具備的。
當然，這也取決於你的資料規模，Neo4j對單機本身的資料規模在十億、百億之間使用案例會比較好。但我們用Cassandra構建的圖資料庫規模已經達到了百億甚至千億的規模，明年甚至可能會再提高至少50%到1500億。當然，這些基於Cassandra的開源方案相對於企業版的Neo4j成本也會低很多。
2. 關於Cassandra叢集的監控是否有一些很好的經驗？
Cassandra本身能通過虛擬表獲取一些資訊，但我們的做法有些不同。我們關注的首先是磁碟，第二個則是通過JMX將資訊收集起來，再做整體分析。
Cassandra的系統相對穩定，更多的問題可能存在於磁碟上，尤其是現在使用比較廉價的硬體情況下，所以我們更需要關注的則是資料的可靠性，要能快速恢復資料。
其他方面，因為Cassandra的對等性，所以它的監控邏輯會的相對簡單。我們在之前的活動裡也提到，360的Cassandra監控體系其實被納入到了一個完整監控體系Xmanager中。
我們一方面，會通過主動排查巡檢，另一方面通過自動化流程的打通。總體來說，Cassandra運維的穩定性要遠遠高於HBase，所以它也能滿足我們日常線上服務質量的要求。
3. 關於之前提到的NoSQL和NewSQL概念，Cassandra是否會支援HTAP(Hybrid Transactional/Analytical Processing)特性?
我回答這個問題可能不是很適合，因為360本身並沒有做到這點。比如TiDB本身就是一個TP系統，在TP的基礎上通過三個副本中兩個副本去保證我的TP，然後另外一個副本可能是做一個AP，也就是列存的方式來實現。
Cassandra能否通過這種方式實現這樣的架構，既能滿足 AP的場景，又能滿足TP的場景，但這都是一個猜想了。但是我個人認為，短期內社群也不會這麼去做。所以說整體上來講，短期大家如果需要這方面可能會有點失望。