當Facebook創造的cassandra趕上餓了麼

摘要

一、餓了麼大數據爲何選擇cassandra

二、 Cassandra的基本原理

三、餓了麼cassandra實踐

四、 Cassandra和大數據離線平臺的結合

內容來源：2017年6月11日，餓了麼數據專家翟玉勇在「餓了麼&七牛雲聯合論壇 大數據最新場景化應用實踐」進行《cassandra在餓了麼的應用》演講分享。IT 大咖說做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。

閱讀字數：1759 | 4分鐘閱讀

嘉賓演講視頻回放： t.cn/RQs4Uv2

Cassandra歷史

Google的三大論文其中有一個叫BigTable，Amazon有一個kv存儲叫Dynamo。Facebook根據Google和Amazon的這兩個本身創造出了Cassandra。2008年，Facebook放棄了Cassandra，把它交給了Apache。

Cassandra概述

Cassandra最初源自Facebook，集合了Google BigTable面向列的特性和Amazon Dynamo分佈式哈希(DHT)的P2P特性於一身，具備很高的性能、可擴展性、容錯、部署簡單等特色。

Cassandra架構關鍵字

一、Gossip 點對點通訊協議，用於集羣之間節點交換位置和狀態信息。

二、Partitioner 決定如何在集羣中的節點間分發數據，也就是哪一個節點放止數據的第一個replica。

三、Replica Strategy 決定在哪些節點放置數據的其餘replica。

四、Snitch 定義了複製策略用來放置replicas和路由請求所使用的拓撲信息。

Gossip-節點的通訊

Cassandra使用點對點通訊協議Gossip在集羣中的節點間交換位置和狀態信息。Gossip進程每秒運行一次，與最多3個其餘節點交換信息，這樣全部的節點可很快的瞭解集羣中其餘節點信息。

一、種子節點。它的做用就是讓其它節點來認識到這個集羣在哪裏，如何與集羣連上關係。

二、Cassandra故障探測。Cassandra協議就是每一個進程每秒最多會和三個其它節點作交互，判斷它是否存活。

三、Cassandra故障修復。當一個節點掛了，但不表明它從這個集羣中移走了，而只是暫時offline。當它再拉起來的時候，Gossip系統也能探測到它活了，並加入到集羣中去。

Partitioner

Partitioner定義了數據如何在集羣中的節點分佈，哪一個節點應該存放數據的第一份拷貝。基本上，Partitioner就是一個計算分區鍵token的哈希函數。

Partitioner中分爲三大類。Partition Key 決定數據在Cassandra哪一個節點上，Clustering Key 用於在各個分區內的排序，Primary Key 主鍵決定數據行的惟一性。

Replica Strategy

Cassandra在多個節點中存放replicas以保證可靠性和容錯性。Replica Strategy決定放置replicas的節點，replicas的數目由複製因子肯定，好比一般設置3表示每行數據有三份拷貝，每份數據存儲在不一樣的節點。

當前可用的兩種複製策略：

一、SimpleStrategy 僅用於但數據中心

CREATEKEYSPACE dw WITH replication = {'class':'SimpleStrategy', ‘replication_factor': 3}

二、NetworkTopologyStrategy 用於多IDC場景，可指定每一個IDC有多少replicas

CREATEKEYSPACE dw WITH replication = {'class':'NetworkTopologyStrategy', 'DC-SH' : 2,'DC-BG' : 2}

Cassandra主要的數據結構

Memtable：它的本質是java裏的跳錶。

SSTable：最終存放的數據落地在磁盤的結構。

BloomFilter：高效地用最少的內存來判斷數據是否存在。

CQL語言

CQL相似於SQL，支持DDL操做create table，drop table等，也支持DML操做INSERT、UPDATE、DELETE等等，經過select進行數據查詢。

Cassandra一致性保障

在Cassandra中，有三重策略來保障Cassandra達到最終的一致性。

HintedHandoff：若是寫了三個副本，只要有兩個響應就能夠。可是假若有一個節點掛了，Cassandra能夠把原本要寫到這個節點的數據寫到另外一個節點上。等掛了的節點拉起來以後，再把這個數據寫回去，以保證三份數據同時寫成功了。

ReadRepair：當一個讀的請求發起以後，能夠觸發後臺一個線程檢查這三個數據的副本數據是否一致，若是不一致再進行修復。

Anti-EntropyNode Repair：主動把本身節點的key和其它節點的key進行比較，不一致的進行修復。

爲何選擇Cassandra

運維成本：部署簡單，只須要運維一個組件，監控成本低。

開發成本：相似sql的cql語言，對開發友好，低成本上手；DataStax公司提供的強大的java client；可調節的數據一致性；異步接口。

適用場景：Cassandra自帶多idc策略、咱們的業務需求。

Cassandra在餓了麼的實踐

生產應用（用戶畫像、歷時訂單、dt.api）、Client選擇、運維和監控以及性能調優。

生產應用-用戶畫像

咱們的用戶畫像用了5 個節點，超過2.6億的餓了麼用戶數據，100+的用戶屬性，天天有5000萬+數據更新，Scheme變動頻繁(加字段)，99%的讀延時能控制在3-5ms以內。

生產應用-歷史訂單

咱們採用了Sata盤集羣，它對咱們的響應時間並非要求很高，平均響應時間小於80ms。這個集羣大概有15個節點。

生產應用-dt.api

Dt.api是一個餓了麼大數據平臺自助化數據接口平臺。用戶在這個平臺上只要寫出一個SQL，它就會自動生成一個HTTP或SOA接口。當前這裏有50+ 基於Cassandra的CQL API生成。

運維和監控

ansible自動部署：Cassandra的端口必須綁定到內網IP，用ansible進行自動部署特別方便。

Zabbix監控：餓了麼大數據平臺的監控主要是Zabbix。

性能調優-集羣調優化

集羣參數設置

一、memtable_allocation_type

heap_buffers:on heap nio buffer

offheap_buffers:off heap(direct) nio buffers

offheap_objects:native memory

二、concurrent_write和concurrent_read

三、Sstable compression

四、Concurrent compactor

五、memtable_flush_writers

六、Netty io線程數目

JVM調優化

一、堆的大小選擇

二、取消偏向鎖

Scheme設計優化

一、Primary key設計，避免熱點

二、關閉讀修復

三、Compaction strategy策略選擇

四、Ttl設置

五、Row cache啓用

大數據離線平臺和Cassandra的整合

兩大數據推送Cassandra工具

HiveIntegrate Cassandra Native Protocol：

1.Hive外部表映射到Cassandra表

2.InsertInto HiveTable Select 簡單快捷

3.跨機房推送限流/限速

4.異步寫

HiveIntegrate Cassandra Bulkload：

1.hive生成Cassandra底層的SSTable文件直接load到Cassandra。

2.適用於數據快速初始化。

3.須要控制生成的SSTable大小避免Compact耗時多久。

我今天的分享就到這裏，謝謝你們！