你好,游客 登录 注册 发布搜索
背景:
阅读新闻

使用Spark+Cassandra打造高性能数据分析平台

[日期:2014-10-25] 来源:CSDN  作者:许鹏 [字体: ]

  笔者(许鹏)看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;

  要用Cassandra来达到同样的效果,就必须在employee表和department表之外,再创建一张额外的表(dept_empl)来记录每一个部门拥有的员工信息。

  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)

  );

  2.4 子查询

  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数据模型的时候,要求对数据的读取需求进可能的清晰,然后利用反范式的设计方式来实现快速的读取,原则就是以空间来换取时间。

  参考资料

  http://planetcassandra.org/blog/cql-cassandra-query-language/

  http://maxgrinev.com/2010/07/12/do-you-really-need-sql-to-do-it-all-in-cassandra/

收藏 推荐 打印 | 录入:574107552 | 阅读:
相关新闻       Cassandra 数据模型 
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数
点评:
       
评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款