使用Spark+Cassandra打造高性能數據分析平臺（一）

看Spark源碼的時間不長，記筆記的初衷只是為了不至于日后遺忘。在源碼閱讀的過程中秉持著一種非常簡單的思維模式，就是努力去尋找一條貫穿全局的主線索。在筆者看來，Spark中的線索就是如果讓數據的處理在分布式計算環境下是高效，并且可靠的。

在對Spark內部實現有了一定了解之后，當然希望將其應用到實際的工程實踐中，這時候會面臨許多新的挑戰，比如選取哪個作為數據倉庫，是HBase、MongoDB還是Cassandra。即便一旦選定之后，在實踐過程還會遇到許多意想不到的問題。

要想快速的解決開發及上線過程中遇到的系列問題，還需要具備相當深度的Linux知識，恰巧之前工作中使用Linux的經驗在大數據領域中還可以充分使用。

筆者不才，就遇到的一些問題，整理出來與諸君共同分享。

1. Cassandra

NoSQL數據庫的選擇之痛，目前市面上有近150多種NoSQL數據庫，如何在這么龐雜的隊伍中選中適合業務場景的佼佼者，實非易事。

好的是經過大量的篩選，大家比較肯定的幾款NoSQL數據庫分別是HBase、MongoDB和Cassandra。

Cassandra在哪些方面吸引住了大量的開發人員呢？下面僅做一個粗略的分析。

1.1 高可靠性

Cassandra采用gossip作為集群中結點的通信協議，該協議整個集群中的節點都處于同等地位，沒有主從之分，這就使得任一節點的退出都不會導致整個集群失效。

Cassandra和HBase都是借鑒了Google BigTable的思想來構建自己的系統，但Cassandra另一重要的創新就是將原本存在于文件共享架構的p2p(peer to peer)引入了NoSQL。

P2P的一大特點就是去中心化，集群中的所有節點享有同等地位，這極大避免了單個節點退出而使整個集群不能工作的可能。

與之形成對比的是HBase采用了Master/Slave的方式，這就存在單點失效的可能。

1.2 高可擴性

隨著時間的推移，集群中原有的規模不足以存儲新增加的數據，此時進行系統擴容。Cassandra級聯可擴，非常容易實現添加新的節點到已有集群，操作簡單。

1.3 最終一致性

分布式存儲系統都要面臨CAP定律問題，任何一個分布式存儲系統不可能同時滿足一致性(consistency)，可用性(availability)和分區容錯性(partition tolerance)。

Cassandra是優先保證AP，即可用性和分區容錯性。

Cassandra為寫操作和讀操作提供了不同級別的一致性選擇，用戶可以根據具體的應用場景來選擇不同的一致性級別。

1.4 高效寫操作

寫入操作非常高效，這對于實時數據非常大的應用場景，Cassandra的這一特性無疑極具優勢。

數據讀取方面則要視情況而定：

• 如果是單個讀取即指定了鍵值，會很快的返回查詢結果。
• 如果是范圍查詢，由于查詢的目標可能存儲在多個節點上，這就需要對多個節點進行查詢，所以返回速度會很慢
• 讀取全表數據，非常低效。

1.5 結構化存儲

Cassandra是一個面向列的數據庫，對那些從RDBMS方面轉過來的開發人員來說，其學習曲線相對平緩。

Cassandra同時提供了較為友好CQL語言，與SQL語句相似度很高。

1.6 維護簡單

從系統維護的角度來說，由于Cassandra的對等系統架構，使其維護操作簡單易行。如添加節點，刪除節點，甚至于添加新的數據中心，操作步驟都非常的簡單明了。

參考資料

• 1.http://cassandra.apache.org
• 2.http://www.datastax.com/doc
• 3.http://planetcassandra.org/documentation/

2. Cassandra數據模型

2.1 單表查詢

2.1.1 單表主鍵查詢

在建立個人信息數據庫的時候，以個人身份證id為主鍵，查詢的時候也只以身份證為關鍵字進行查詢，則表可以設計成為：

create table person (
	userid text primary key,
	fname text,
	lname text,
	age	int,
	gender int);

Primary key中的第一個列名是作為Partition key。也就是說根據針對partition key的hash結果決定將記錄存儲在哪一個partition中，如果不湊巧的情況下單一主鍵導致所有的hash結果全部落在同一分區，則會導致該分區數據被撐滿。

解決這一問題的辦法是通過組合分區鍵(compsoite key)來使得數據盡可能的均勻分布到各個節點上。

舉例來說，可能將(userid,fname)設置為復合主鍵。那么相應的表創建語句可以寫成

create table person (
userid text,
fname text,
lname text,
gender int,
age int,
primary key((userid,fname),lname);
) with clustering order by (lname desc);

稍微解釋一下primary key((userid, fname),lname)的含義：

• 其中(userid,fname)稱為組合分區鍵(composite partition key)
• lname是聚集列(clustering column)
• ((userid,fname),lname)一起稱為復合主鍵(composite primary key)

2.1.2 單表非主鍵查詢

如果要查詢表person中具有相同的first name的人員，那么就必須針對fname創建相應的索引，否則查詢速度會非常緩慢。

Create index on person(fname);

Cassandra目前只能對表中的某一列建立索引，不允許對多列建立聯合索引。

2.2 多表關聯查詢

Cassandra并不支持關聯查詢，也不支持分組和聚合操作。

那是不是就說明Cassandra只是看上去很美其實根本無法解決實際問題呢？答案顯然是No,只要你不堅持用RDBMS的思路來解決問題就是了。

比如我們有兩張表，一張表(Departmentt)記錄了公司部門信息，另一張表(employee)記錄了公司員工信息。顯然每一個員工必定有歸屬的部門，如果想知道每一個部門擁有的所有員工。如果是用RDBMS的話，SQL語句可以寫成：

select * from employee e , department d where e.depId = d.depId;

Create table dept_empl (
deptId text,

看到這里想必你已經明白了，在Cassandra中通過數據冗余來實現高效的查詢效果。將關聯查詢轉換為單一的表操作。

2.3 分組和聚合

在RDBMS中常見的group by和max、min在Cassandra中是不存在的。

如果想將所有人員信息按照姓進行分組操作的話，那該如何創建數據模型呢？

Create table fname_person (
fname text,
userId text,
primary key(fname)
);

Cassandra不支持子查詢，下圖展示了一個在MySQL中的子查詢例子： 

要用Cassandra來實現，必須通過添加額外的表來存儲冗余信息。 

Create table office_empl (
officeCode text,
country text,
lastname text,
firstname,
primary key(officeCode,country));
create index on office_empl(country);

 2.5 小結

總的來說，在建立Cassandra數據模型的時候，要求對數據的讀取需求進可能的清晰，然后利用反范式的設計方式來實現快速的讀取，原則就是以空間來換取時間。CDA數據分析師培訓官網