cassandra去中心化
❶ cassandra创建列族要放在配置文件里吗
Cassandra是一个混合型的非关系的数据库，类似于Google的BigTable。其主要功能比Dynamo （分布式的Key-Value存储系统）更丰富，但支持度却不如文档存储MongoDB（介于关系数据库和非关系数据库之间的开源产品，是非关系数据库当中功能最丰富，最像关系数据库的。
支持的数据结构非常松散，是类似json的bjson格式，因此可以存储比较复杂的数据类型）。Cassandra最初由Facebook开发，后转变成了开源项目。它是一个网络社交云计算方面理想的数据库。以Amazon专有的完全分布式的Dynamo为基础，结合了Google BigTable基于列族（Column Family）的数据模型。P2P去中心化的存储。很多方面都可以称之为Dynamo 2.0。
❷ 如何建立一个完整可用的安全大数据平台
“
要建立一个大数据系统，我们需要从数据流的源头跟踪到最后有价值的输出，并在现有的Hadoop和大数据生态圈内根据实际需求挑选并整合各部分合适的组件来构建一个能够支撑多种查询和分析功能的系统平台。这其中既包括了对数据存储的选择，也涵盖了数据线上和线下处理分离等方面的思考和权衡。此外，没有任何一个引入大数据解决方案的商业应用在生产环境上承担的起安全隐患。
1
计算框架篇
大数据的价值
只有在能指导人们做出有价值的决定时，数据才能体现其自身的价值。因此，大数据技术要服务于实际的用途，才是有意义的。一般来说，大数据可以从以下三个方面指导人们做出有价值的决定：
报表生成（比如根据用户历史点击行为的跟踪和综合分析、 应用程序活跃程度和用户粘性计算等）；
诊断分析（例如分析为何用户粘性下降、根据日志分析系统为何性能下降、垃圾邮件以及病毒的特征检测等）；
决策（例如个性化新闻阅读或歌曲推荐、预测增加哪些功能能增加用户粘性、帮助广告主进行广告精准投放、设定垃圾邮件和病毒拦截策略等）。
图 1
进一步来看，大数据技术从以下三个方面解决了传统技术难以达成的目标（如图1）：
在历史数据上的低延迟（交互式）查询，目标是加快决策过程和时间， 例如分析一个站点为何变缓慢并尝试修复它；
在实时数据上的低延迟查询，目的是帮助用户和应用程序在实时数据上做出决策， 例如实时检测并阻拦病毒蠕虫（一个病毒蠕虫可以在1.3秒内攻击1百万台主机）；
更加精细高级的数据处理算法，这可以帮助用户做出“更好”的决策， 例如图数据处理、异常点检测、趋势分析及其他机器学习算法。
蛋糕模式
从将数据转换成价值的角度来说，在Hadoop生态圈十年蓬勃成长的过程中，YARN和Spark这二者可以算得上是里程碑事件。Yarn的出现使得集群资源管理和数据处理流水线分离，大大革新并推动了大数据应用层面各种框架的发展（SQL on Hadoop框架, 流数据，图数据，机器学习）。
它使得用户不再受到MapRece开发模式的约束，而是可以创建种类更为丰富的分布式应用程序，并让各类应用程序运行在统一的架构上，消除了为其他框架维护独有资源的开销。就好比一个多层蛋糕，下面两层是HDFS和Yarn, 而MapRece就只是蛋糕上层的一根蜡烛而已，在蛋糕上还能插各式各样的蜡烛。
在这一架构体系中，总体数据处理分析作业分三块（图2），在HBase上做交互式查询（Apache Phoenix, Cloudera Impala等）， 在历史数据集上编写MapRece程序抑或利用Hive等做批处理业务， 另外对于实时流数据分析Apache Storm则会是一种标准选择方案。
虽然Yarn的出现极大地丰富了Hadoop生态圈的应用场景，但仍存有两个显而易见的挑战：一是在一个平台上需要维护三个开发堆栈；二是在不同框架内很难共享数据，比如很难在一个框架内对流数据做交互式查询。这也意味着我们需要一个更为统一和支持更好抽象的计算框架的出现。
图 2
一统江湖
Spark的出现使得批处理任务，交互式查询，实时流数据处理被整合到一个统一的框架内（图3），同时Spark和现有的开源生态系统也能够很好地兼容（Hadoop, HDFS, Yarn, Hive, Flume）。 通过启用内存分布数据集，优化迭代工作负载， 用户能够更简单地操作数据，并在此基础上开发更为精细的算法，如机器学习和图算法等。
有三个最主要的原因促使Spark目前成为了时下最火的大数据开源社区（拥有超过来自200多个公司的800多个contributors）：
Spark可以扩展部署到超过8000节点并处理PB级别的数据，同时也提供了很多不错的工具供应用开发者进行管理和部署；
Spark提供了一个交互式shell供开发者可以用Scala或者Python即时性试验不同的功能；
Spark提供了很多内置函数使得开发者能够比较容易地写出低耦合的并且能够并发执行的代码，这样开发人员就更能集中精力地为用户提供更多的业务功能而不是花费时间在优化并行化代码之上。
当然Spark也和当年的MapRece一样不是万灵药，比如对实时性要求很高的流数据处理上Apache Storm还是被作为主流选择， 因为Spark Streaming实际上是microbatch（将一个流数据按时间片切成batch,每个batch提交一个job）而不是事件触发实时系统，所以虽然支持者们认为microbatch在系统延时性上贡献并不多，但在生产环境中和Apache Storm相比还不是特别能满足对低延时要求很高的应用场景。
比如在实践过程中， 如果统计每条消息的平均处理时间，很容易达到毫秒级别，但一旦统计类似service assurance（确保某条消息在毫秒基本能被处理完成）的指标， 系统的瓶颈有时还是不能避免。
但同时我们不能不注意到，在许多用例当中，与流数据的交互以及和静态数据集的结合是很有必要的, 例如我们需要在静态数据集上进行分类器的模型计算，并在已有分类器模型的基础上，对实时进入系统的流数据进行交互计算来判定类别。
由于Spark的系统设计对各类工作（批处理、流处理以及交互式工作）进行了一个共有抽象，并且生态圈内延伸出了许多丰富的库（MLlib机器学习库、SQL语言API、GraphX）, 使得用户可以在每一批流数据上进行灵活的Spark相关操作，在开发上提供了许多便利。
Spark的成熟使得Hadoop生态圈在短短一年之间发生了翻天覆地的变化， Cloudera和Hortonworks纷纷加入了Spark阵营，而Hadoop项目群中除了Yarn之外已经没有项目是必须的了（虽然Mesos已在一些场合替代了Yarn）, 因为就连HDFS，Spark都可以不依赖。但很多时候我们仍然需要像Impala这样的依赖分布式文件系统的MPP解决方案并利用Hive管理文件到表的映射，因此Hadoop传统生态圈依然有很强的生命力。
另外在这里简要对比一下交互式分析任务中各类SQL on Hadoop框架，因为这也是我们在实际项目实施中经常遇到的问题。我们主要将注意力集中在Spark SQL, Impala和Hive on Tez上, 其中Spark SQL是三者之中历史最短的，论文发表在15年的SIGMOD会议上， 原文对比了数据仓库上不同类型的查询在Shark（Spark最早对SQL接口提供的支持）、Spark SQL和Impala上的性能比较。
也就是说， 虽然Spark SQL在Shark的基础上利用Catalyst optimizer在代码生成上做了很多优化，但总体性能还是比不上Impala, 尤其是当做join操作的时候， Impala可以利用“predicate pushdown”更早对表进行选择操作从而提高性能。
不过Spark SQL的Catalyst optimizer一直在持续优化中，相信未来会有更多更好的进展。Cloudera的Benchmark评测中Impala一直比其他SQL on Hadoop框架性能更加优越，但同时Hortonworks评测则指出虽然单个数据仓库查询Impala可以在很短的时间内完成，但是一旦并发多个查询Hive on Tez的优势就展示出来。另外Hive on Tez在SQL表达能力也要比Impala更强（主要是因为Impala的嵌套存储模型导致的）， 因此根据不同的场景选取不同的解决方案是很有必要的。
图 3
各领风骚抑或代有才人出？
近一年比较吸引人眼球的Apache Flink（与Spark一样已有5年历史，前身已经是柏林理工大学一个研究性项目，被其拥趸推崇为继MapRece, Yarn，Spark之后第四代大数据分析处理框架）。 与Spark相反，Flink是一个真正的实时流数据处理系统，它将批处理看作是流数据的特例，同Spark一样它也在尝试建立一个统一的平台运行批量，流数据，交互式作业以及机器学习，图算法等应用。
Flink有一些设计思路是明显区别于Spark的，一个典型的例子是内存管理，Flink从一开始就坚持自己精确的控制内存使用并且直接操作二进制数据，而Spark一直到1.5版本都还是试用java的内存管理来做数据缓存，这也导致了Spark很容易遭受OOM以及JVM GC带来的性能损失。
但是从另外一个角度来说, Spark中的RDD在运行时被存成java objects的设计模式也大大降低了用户编程设计门槛， 同时随着Tungsten项目的引入，Spark现在也逐渐转向自身的内存管理， 具体表现为Spark生态圈内从传统的围绕RDD（分布式java对象集合）为核心的开发逐渐转向以DataFrame(分布式行对象集合)为核心。
总的来说，这两个生态圈目前都在互相学习，Flink的设计基因更为超前一些，但Spark社区活跃度大很多，发展到目前毫无疑问是更为成熟的选择，比如对数据源的支持（HBase, Cassandra, Parquet, JSON, ORC）更为丰富以及更为统一简洁的计算表示。另一方面，Apache Flink作为一个由欧洲大陆发起的项目，目前已经拥有来自北美、欧洲以及亚洲的许多贡献者，这是否能够一改欧洲在开源世界中一贯的被动角色，我们将在未来拭目以待。
2
NoSQL数据库篇
NoSQL数据库在主流选择上依旧集中在MongoDB, HBase和Cassandra这三者之间。在所有的NoSQL选择中，用C 编写的MongoDB几乎应该是开发者最快也最易部署的选择。MongoDB是一个面向文档的数据库，每个文档／记录／数据（包括爬取的网页数据及其他大型对象如视频等）是以一种BSON（Binary JSON）的二进制数据格式存储, 这使得MongoDB并不需要事先定义任何模式, 也就是模式自由（可以把完全不同结构的记录放在同一个数据库里）。
MongoDB对于完全索引的支持在应用上是很方便的，同时也具备一般NoSQL分布式数据库中可扩展，支持复制和故障恢复等功能。 MongoDB一般应用于高度伸缩性的缓存及大尺寸的JSON数据存储业务中，但不能执行“JOIN”操作，而且数据占用空间也比较大，最被用户诟病的就是由于MongoDB提供的是数据库级锁粒度导致在一些情况下建索引操作会引发整个数据库阻塞。一般来说，MongoDB完全可以满足一些快速迭代的中小型项目的需求。
下面来主要谈谈Cassandra和HBase之间的比较选择。Cassandra和HBase有着截然不同的基因血统。HBase和其底层依赖的系统架构源自于著名的Google FileSystem（发表于2003年）和Google BigTable设计（发表于2006年）， 其克服了HDFS注重吞吐量却牺牲I/O的缺点，提供了一个存储中间层使得用户或者应用程序可以随机读写数据。
具体来说，HBase的更新和删除操作实际上是先发生在内存MemStore中， 当MemStore满了以后会Flush到StoreFile, 之后当StoreFile文件数量增长到一定阈值后会触发Compact合并操作，因此HBase的更新操作其实是不断追加的操作，而最终所有更新和删除数据的持久化操作都是在之后Compact过程中进行的。
这使得应用程序在向内存MemStore写入数据后，所做的修改马上就能得到反映，用户读到的数据绝不会是陈旧的数据，保证了I/O高性能和数据完全一致性； 另一方面来说， HBase基于Hadoop生态系统的基因就已经决定了他自身的高度可扩展性、容错性。
在数据模型上，Cassandra和HBase类似实现了一个key-value提供面向列式存储服务，其系统设计参考了 Amazon Dynamo (发表于2007年) 分布式哈希（DHT）的P2P结构（实际上大部分Cassandra的初始工作都是由两位从Amazon的Dynamo组跳槽到Facebook的工程师完成)，同样具有很高的可扩展性和容错性等特点。
除此之外， 相对HBase的主从结构，Cassandra去中心化的P2P结构能够更简单地部署和维护，比如增加一台机器只需告知Cassandra系统新节点在哪，剩下的交给系统完成就行了。同时，Cassandra对多数据中心的支持也更好，如果需要在多个数据中心进行数据迁移Cassandra会是一个更优的选择。
Eric Brewer教授提出的经典CAP理论认为任何基于网络的数据共享系统，最多只能满足数据一致性、可用性、分区容忍性三要素中的两个要素。实际分布式系统的设计过程往往都是在一致性与可用性上进行取舍，相比于HBase数据完全一致性的系统设计，Cassandra选择了在优先考虑数据可用性的基础上让用户自己根据应用程序需求决定系统一致性级别。
比如：用户可以配置QUONUM参数来决定系统需要几个节点返回数据才能向客户端做出响应，ONE指只要有一个节点返回数据就可以对客户端做出响应，ALL指等于数据复制份数的所有节点都返回结果才能向客户端做出响应，对于数据一致性要求不是特别高的可以选择ONE，它是最快的一种方式。
从基因和发展历史上来说，HBase更适合用做数据仓库和大规模数据处理与分析（比如对网页数据建立索引）， 而Cassandra则更适合用作实时事务和交互式查询服务。Cassandra在国外市场占有比例和发展要远比国内红火， 在不少权威测评网站上排名都已经超过了HBase。目前Apache Cassandra的商业化版本主要由软件公司DataStax进行开发和销售推广。另外还有一些NoSQL分布式数据库如Riak, CouchDB也都在各自支持的厂商推动下取得了不错的发展。
虽然我们也考虑到了HBase在实际应用中的不便之处比如对二级索引的支持程度不够（只支持通过单个行键访问，通过行键的范围查询，全表扫描），不过在明略的大数据基础平台上，目前整合的是依然是HBase。
理由也很简单，HBase出身就与Hadoop的生态系统紧密集成，其能够很容易与其他SQL on Hadoop框架（Cloudera Impala, Apache Phoenix, or Hive on Tez）进行整合，而不需要重新部署一套分布式数据库系统，而且可以很方便地将同样的数据内容在同一个生态系统中根据不同框架需要来变换存储格式（比如存储成Hive表或者Parquet格式）。
我们在很多项目中都有需要用到多种SQL on Hadoop框架，来应对不同应用场景的情况，也体会到了在同一生态系统下部署多种框架的简便性。 但同时我们也遇到了一些问题， 因为HBase项目本身与HDFS和Zookeeper系统分别是由不同开源团队进行维护的，所以在系统整合时我们需要先对HBase所依赖的其他模块进行设置再对HBase进行配置，在一定程度上降低了系统维护的友好性。
目前我们也已经在考虑将Cassandra应用到一些新的客户项目中，因为很多企业级的应用都需要将线上线下数据库进行分离，HBase更适合存储离线处理的结果和数据仓库，而更适合用作实时事务和并发交互性能更好的Cassandra作为线上服务数据库会是一种很好的选择。
3
大数据安全篇
随着越来越多各式各样的数据被存储在大数据系统中，任何对企业级数据的破坏都是灾难性的，从侵犯隐私到监管违规，甚至会造成公司品牌的破坏并最终影响到股东收益。给大数据系统提供全面且有效的安全解决方案的需求已经十分迫切：
大数据系统存储着许多重要且敏感的数据，这些数据是企业长久以来的财富
与大数据系统互动的外部系统是动态变化的，这会给系统引入新的安全隐患
在一个企业的内部，不同Business Units会用不同的方式与大数据系统进行交互，比如线上的系统会实时给集群推送数据、数据科学家团队则需要分析存储在数据仓库内的历史数据、运维团队则会需要对大数据系统拥有管理权限。
因此为了保护公司业务、客户、财务和名誉免于被侵害，大数据系统运维团队必须将系统安全高度提高到和其他遗留系统一样的级别。同时大数据系统并不意味着引入大的安全隐患，通过精细完整的设计，仍然能够把一些传统的系统安全解决方案对接到最新的大数据集群系统中。
一般来说，一个完整的企业级安全框架包括五个部分：
Administration: 大数据集群系统的集中式管理，设定全局一致的安全策略
Authentication: 对用户和系统的认证
Authorization：授权个人用户和组对数据的访问权限
Audit：维护数据访问的日志记录
Data Protection：数据脱敏和加密以达到保护数据的目的
系统管理员要能够提供覆盖以上五个部分的企业级安全基础设施，否则任何一环的缺失都可能给整个系统引入安全性风险。
在大数据系统安全集中式管理平台这块，由Hortonworks推出的开源项目Apache Ranger就可以十分全面地为用户提供Hadoop生态圈的集中安全策略的管理，并解决授权(Authorization)和审计(Audit)。例如，运维管理员可以轻松地为个人用户和组对文件、数据等的访问策略，然后审计对数据源的访问。
与Ranger提供相似功能的还有Cloudera推出的Apache Sentry项目，相比较而言Ranger的功能会更全面一些。
而在认证（Authentication）方面, 一种普遍采用的解决方案是将基于Kerberos的认证方案对接到企业内部的LDAP环境中， Kerberos也是唯一为Hadoop全面实施的验证技术。
另外值得一提的是Apache Knox Gateway项目，与Ranger提高集群内部组件以及用户互相访问的安全不同，Knox提供的是Hadoop集群与外界的唯一交互接口，也就是说所有与集群交互的REST API都通过Knox处理。这样，Knox就给大数据系统提供了一个很好的基于边缘的安全（perimeter-based security）。
基于以上提到的五个安全指标和Hadoop生态圈安全相关的开源项目， 已经足已证明基于Hadoop的大数据平台我们是能够构建一个集中、一致、全面且有效的安全解决方案。
我市再ITjob管网上面找的
❸ 如何设置cassandra集群
1、基本配置
首先需要准备3台或以上的计算机。下面假定有3台运行 Linux 操作系统的计算机，IP地址分别为 192.168.0.100, 192.168.0.101 和 192.168.0.102。 系统需要安装好 Java 运行时环境，然后到这里下载 0.7 版本的 Cassandra 二进制发行包。
挑选其中的一台机开始配置，先展开 cassandra 发行包：$ tar -zxvf apache-cassandra-$VERSION.tar.gz
$ cd apache-cassandra-$VERSION
其中的 conf/cassandra.yaml 文件为主要配置文件，0.7 版以后不再采用XML格式配置文件了，如果对 YAML 格式不熟悉的话最好先到这里了解一下。
Cassandra 在配置文件里默认设定了几个目录：data_file_directories: /var/lib/cassandra/data
commitlog_directory: /var/lib/cassandra/commitlog
saved_caches_directory: /var/lib/cassandra/saved_caches
data_file_directories 可以一次同时设置几个不同目录，cassandra 会自动同步所有目录的数据。另外在日志配置文件 log4j-server.properties 也有一个默认设定日志文件的目录：log4j.appender.R.File=/var/log/cassandra/system.log
一般情况下采用默认的配置即可，除非你有特殊的储存要求，所以现在有两种方案：一是按照默认配置创建相关的目录，二是修改配置文件采用自己指定的目录。
下面为了简单起见采用第一种方案：$ sudo mkdir -p /var/log/cassandra
$ sudo chown -R `whoami` /var/log/cassandra
$ sudo mkdir -p /var/lib/cassandra
$ sudo chown -R `whoami` /var/lib/cassandra
上面的 `whoami` 是 Linux 指令用于获取当前登录的用户名，如果你不准备用当前登录用户运行 Cassandra，那么需要把 `whoami` 替换成具体的用户名。
2、有关集群的配置
由于 Cassandra 采用去中心化结构，所以当集群里的一台机器（节点）启动之后需要一个途径通知当前集群（有新节点加入啦），Cassandra 的配置文件里有一个 seeds 的设置项，所谓的 seeds 就是能够联系集群中所有节点的一台计算机，假如集群中所有的节点位于同一个机房同一个子网，那么只要随意挑选几台比较稳定的计算机即可。在当前的例子中因为只有3台机器，所以我挑选第一台作为种子节点，配置如下： seeds:
- 192.168.0.100
然后配置节点之前通信的IP地址：listen_address: 192.168.0.100
需要注意的是这里必须使用具体的IP地址，而不能使用 0.0.0.0 这样的地址。
配置 Cassandra Thrift 客户端（应用程序）访问的IP地址：rpc_address: 192.168.0.100
这项可以使用 0.0.0.0 监听一台机器所有的网络接口。
Cassandra 的 Keyspaces 和 ColumnFamilies 不再需要配置了，他们将在运行时创建和维护。
把配置好的 Cassandra 复制到第2和第3台机器，同时创建相关的目录，还需要修改 listen_address 和 rpc_address 为实际机器的IP地址。至此所有的配置完成了。
3、启动 Cassandra 各个节点以及集群管理
启动顺序没什么所谓，只要保证种子节点启动就可以了：$ bin/cassandra -f
参数 -f 的作用是让 Cassandra 以前端程序方式运行，这样有利于调试和观察日志信息，而在实际生产环境中这个参数是不需要的（即 Cassandra 会以 daemon 方式运行）。
所有节点启动后可以通过 bin/nodetool 工具管理集群，比如查看所有节点运行情况：
$ bin/nodetool -host 192.168.0.101 ring
运行结果类似如下：
Address Status State Load Owns Token
159559...
192.168.0.100 Up Normal 49.27 KB 39.32% 563215...
192.168.0.101 Up Normal 54.42 KB 16.81% 849292...
192.168.0.102 Up Normal 73.14 KB 43.86% 159559...
命令中 -host 参数用于指定 nodetool 跟哪一个节点通信，对于 nodetool ring 命令来说，跟哪个节点通信都没有区别，所以可以随意指定其中一个节点。
从上面结果列表可以看到运行中的节点是否在线、State、数据负载量以及节点Token（可以理解为节点名称，这个是节点第一次启动时自动产生的）。我们可以使用 nodetool 组合 token 对具体节点进行管理，比如查看指定节点的详细信息：$ bin/nodetool -host 192.168.0.101 info
运行的结果大致如下：
Load : 54.42 KB
Generation No : 1302057702
Uptime (seconds) : 591
Heap Memory (MB) : 212.14 / 1877.63
查看指定节点的数据结构信息： $ bin/nodetool -host 192.168.0.101 cfstats
运行结果：
Keyspace: Keyspace1
Read Count: 0
Write Count: 0
Pending Tasks: 0
Column Family: CF1
SSTable count: 1
使用下面命令可以移除一个已经下线的节点（比如第2台机器关机了或者坏掉了） $ bin/nodetool -host 192.168.0.101 removetoken
下了线的节点如何重新上线呢？什么都不用做，只需启动 Cassandra 程序它就会自动加入集群了。
在实际运作中我们可能会需要隔一段时间备份一次数据（创建一个快照），这个操作在 Cassandra 里非常简单：$ bin/nodetool -host 192.168.0.101 snapshot
4、测试数据的读写
使用客户端组件加单元测试是首选的，如果仅想知道集群是否正常读写数据，可以用cassandra-cli 作一个简单测试：$ bin/cassandra-cli -host 192.168.0.101
接着输入如下语句：
create keyspace Keyspace1;
use Keyspace1;
create column family Users with comparator=UTF8Type and default_validation_class=UTF8Type;
set Users[jsmith][first] = 'John';
set Users[jsmith][last] = 'Smith';
get Users[jsmith];
上面语句创建了一个名为“Keyspace1”的 keyspace，还创建了一个名为“Users”的 Column Family，最后向 Users 添加了一个 item。正常的话应该看到类似下面的结果：
=> (column=first, value=John, timestamp=1302059332540000)
=> (column=last, value=Smith, timestamp=1300874233834000)
Returned 2 results.
❹ nosql解决方案为什么需要固态硬盘
Membase
Membase 是 NoSQL 家族的一个新的重量级的成员。Membase是开源项目，源代码采用了Apache2.0的使用许可。该项目托管在GitHub.Source tarballs上，可以下载beta版本的Linux二进制包。该产品主要是由North Scale的memcached核心团队成员开发完成，其中还包括Zynga和NHN这两个主要贡献者的工程师，这两个组织都是很大的在线游戏和社区网络空间的供应商。
Membase容易安装、操作，可以从单节点方便的扩展到集群，而且为memcached（有线协议的兼容性）实现了即插即用功能，在应用方面为开发者和经营者提供了一个比较低的门槛。做为缓存解决方案，Memcached已经在不同类型的领域（特别是大容量的Web应用）有了广泛的使用，其中 Memcached的部分基础代码被直接应用到了Membase服务器的前端。
通过兼容多种编程语言和框架，Membase具备了很好的复用性。在安装和配置方面，Membase提供了有效的图形化界面和编程接口，包括可配置 的告警信息。
Membase的目标是提供对外的线性扩展能力，包括为了增加集群容量，可以针对统一的节点进行复制。 另外，对存储的数据进行再分配仍然是必要的。
这方面的一个有趣的特性是NoSQL解决方案所承诺的可预测的性能，类准确性的延迟和吞吐量。通过如下方式可以获得上面提到的特性：
◆ 自动将在线数据迁移到低延迟的存储介质的技术（内存，固态硬盘，磁盘）
◆ 可选的写操作一一异步，同步（基于复制，持久化）
◆ 反向通道再平衡[未来考虑支持]
◆ 多线程低锁争用
◆ 尽可能使用异步处理
◆ 自动实现重复数据删除
◆ 动态再平衡现有集群
◆ 通过把数据复制到多个集群单元和支持快速失败转移来提供系统的高可用性。
MongoDB
MongoDB是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。他支持的数据结构非常松散，是类似json的bjson格式，因此可以存储比较复杂的数据类型。Mongo最大的特点是他支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引。它的特点是高性能、易部署、易使用，存储数据非常方便。
主要功能特性：
◆ 面向集合存储，易存储对象类型的数据
“面向集合”（Collenction-Oriented），意思是数据被分组存储在数据集中，被称为一个集合（Collenction)。每个 集合在数据库中都有一个唯一的标识名，并且可以包含无限数目的文档。集合的概念类似关系型数据库（RDBMS）里的表（table），不同的是它不需要定 义任何模式（schema)。
◆ 模式自由
模式自由（schema-free)，意味着对于存储在mongodb数据库中的文件，我们不需要知道它的任何结构定义。如果需要的话，你完全可以把不同结构的文件存储在同一个数据库里。
◆支持动态查询
◆支持完全索引，包含内部对象
◆支持查询
◆支持复制和故障恢复
◆使用高效的二进制数据存储，包括大型对象（如视频等）
◆自动处理碎片，以支持云计算层次的扩展性
◆支持RUBY，PYTHON，JAVA，C++，PHP等多种语言
◆文件存储格式为BSON（一种JSON的扩展）
BSON（Binary Serialized document Format）存储形式是指：存储在集合中的文档，被存储为键-值对的形式。键用于唯一标识一个文档，为字符串类型，而值则可以是各种复杂的文件类型。
◆可通过网络访问
MongoDB服务端可运行在Linux、Windows或OS X平台，支持32位和64位应用，默认端口为27017。推荐运行在64位平台，因为MongoDB在32位模式运行时支持的最大文件尺寸为2GB。
MongoDB把数据存储在文件中（默认路径为：/data/db），为提高效率使用内存映射文件进行管理。
Hypertable
Hypertable是一个开源、高性能、可伸缩的数据库，它采用与Google的Bigtable相似的模型。在过去数年中，Google为在PC集群 上运行的可伸缩计算基础设施设计建造了三个关键部分。第一个关键的基础设施是Google File System（GFS），这是一个高可用的文件系统，提供了一个全局的命名空间。它通过跨机器（和跨机架）的文件数据复制来达到高可用性，并因此免受传统 文件存储系统无法避免的许多失败的影响，比如电源、内存和网络端口等失败。第二个基础设施是名为Map-Rece的计算框架，它与GFS紧密协作，帮 助处理收集到的海量数据。第三个基础设施是Bigtable，它是传统数据库的替代。Bigtable让你可以通过一些主键来组织海量数据，并实现高效的 查询。Hypertable是Bigtable的一个开源实现，并且根据我们的想法进行了一些改进。
Apache Cassandra
Apache Cassandra是一套开源分布式Key-Value存储系统。它最初由Facebook开发，用于储存特别大的数据。Facebook在使用此系统。
主要特性：
◆ 分布式
◆ 基于column的结构化
◆ 高伸展性
Cassandra的主要特点就是它不是一个数据库，而是由一堆数据库节点共同构成的一个分布式网络服务，对Cassandra 的一个写操作，会被复制到其他节点上去，对Cassandra的读操作，也会被路由到某个节点上面去读取。对于一个Cassandra群集来说，扩展性能 是比较简单的事情，只管在群集里面添加节点就可以了。
Cassandra是一个混合型的非关系的数据库，类似于Google的BigTable。其主要功能比 Dynomite（分布式的Key-Value存 储系统）更丰富，但支持度却不如文档存储MongoDB（介于关系数据库和非关系数据库之间的开源产品，是非关系数据库当中功能最丰富，最像关系数据库 的。Cassandra最初由Facebook开发，后转变成了开源项目。它是一个网络社交云计算方面理想的数据库。以Amazon专有的完全分布式的Dynamo为基础，结合了Google BigTable基于列族（Column Family）的数据模型。P2P去中心化的存储。很多方面都可以称之为Dynamo 2.0。
CouchDB
所用语言： Erlang
特点：DB一致性，易于使用
使用许可： Apache
协议： HTTP/REST
双向数据复制，持续进行或临时处理，处理时带冲突检查，因此，采用的是master-master复制
MVCC – 写操作不阻塞读操作
可保存文件之前的版本
Crash-only（可靠的）设计
需要不时地进行数据压缩
视图：嵌入式 映射/减少
格式化视图：列表显示
支持进行服务器端文档验证
支持认证
根据变化实时更新
支持附件处理
因此， CouchApps（独立的 js应用程序）
需要 jQuery程序库
最佳应用场景：适用于数据变化较少，执行预定义查询，进行数据统计的应用程序。适用于需要提供数据版本支持的应用程序。
例如：CRM、CMS系统。 master-master复制对于多站点部署是非常有用的。
和其他数据库比较，其突出特点是：
◆ 模式灵活 ：使用Cassandra，像文档存储，你不必提前解决记录中的字段。你可以在系统运行时随意的添加或移除字段。这是一个惊人的效率提升，特别是在大型部 署上。
◆ 真正的可扩展性 ：Cassandra是纯粹意义上的水平扩展。为给集群添加更多容量，可以指向另一台电脑。你不必重启任何进程，改变应用查询，或手动迁移任何数据。
◆ 多数据中心识别 ：你可以调整你的节点布局来避免某一个数据中心起火，一个备用的数据中心将至少有每条记录的完全复制。
◆ 范围查询 ：如果你不喜欢全部的键值查询，则可以设置键的范围来查询。
◆ 列表数据结构 ：在混合模式可以将超级列添加到5维。对于每个用户的索引，这是非常方便的。
◆ 分布式写操作 ：有可以在任何地方任何时间集中读或写任何数据。并且不会有任何单点失败。
问度娘，啥都有。
❺ Dynamo的高级分析
有了上面一章里的两个基础介绍之后，我们开始进入Dynamo的世界。
Dynamo的数据分区与作用
在Dynamo的实现中提到一个关键的东西，就是数据分区。 假设我们的数据的key的范围是0到2的64次方（不用怀疑你的数据量会超过它，正常甚至变态情况下你都是超不过的，甚至像伏地魔等其他类Dynamo系统是使用的 2的32次方），然后设置一个常数，比如说1000，将我们的key的范围分成1000份。然后再将这1000份key的范围均匀分配到所有的节点（s个节点），这样每个节点负责的分区数就是1000/s份分区。
如图二，假设我们有A、B、C三台机器，然后将我们的分区定义了12个。
图二：三个节点分12个区的数据的情况
因为数据是均匀离散到这个环上的（有人开始会认为数据的key是从1、2、3、4……这样子一直下去的，其实不是的，哈希计算出来的值，都是一个离散的结果），所以我们每个分区的数据量是大致相等的。从图上我们可以得出，每台机器都分到了三个分区里的数据，并且因为分区是均匀的，在分区数量是相当大的时候，数据的分布会更加的均匀，与此同时，负载也被均匀地分开了（当然了，如果硬要说你的负载还是只集中在一个分区里，那就不是在这里要讨论的问题了，有可能是你的哈希函数是不是有什么样的问题了）。
为什么要进行这样的分布呢，分布的好处在于，在有新机器加入的时候，只需要替换原有分区即可，如图三所示：
图三：加入一个新的节点D的情况
同样是图二里的情况，12个分区分到ABC三个节点，图三中就是再进入了一个新的节点D，从图上的重新分布情况可以得出，所有节点里只需要转移四分之一的数据到新来的节点即可，同时，新节点的负载也伴随分区的转移而转移了（这里的12个分区太少了，如果是1200个分区甚至是12000个分区的话，这个结论就是正确的了，12个分区只为演示用）。
从Dynamo的NRW看CAP法则
在Dynamo系统中，第一次提出来了NRW的方法。
N：复制的次数；
R：读数据的最小节点数；
W：写成功的最小分区数。
这三个数的具体作用是用来灵活地调整Dynamo系统的可用性与一致性。
举个例子来说，如果R=1的话，表示最少只需要去一个节点读数据即可，读到即返回，这时是可用性是很高的，但并不能保证数据的一致性，如果说W同时为1的 话，那可用性更新是最高的一种情况，但这时完全不能保障数据的一致性，因为在可供复制的N个节点里，只需要写成功一次就返回了，也就意味着，有可能在读的这一次并没有真正读到需要的数据（一致性相当的不好）。如果W=R=N=3的话，也就是说，每次写的时候，都保证所有要复制的点都写成功，读的时候也是都读到，这样子读出来的数据一定是正确的，但是其性能大打折扣，也就是说，数据的一致性非常的高，但系统的可用性却非常低了。如果R + W > N能够保证我们“读我们所写”，Dynamo推荐使用322的组合。
Dynamo系统的数据分区让整个网络的可扩展性其实是一个固定值（你分了多少区，实际上网络里扩展节点的上限就是这个数），通过NRW来达到另外两个方 向上的调整。
Dynamo的一些增加可用性的补救
针对一些经常可能出现的问题，Dynamo还提供了一些解决的方法。
第一个是hinted handoff数据的加入：在一个节点出现临时性故障时，数据会自动进入列表中的下一个节点进行写操作，并标记为handoff数据，在收到通知需要原节点恢复时重新把数据推回去。这能使系统的写入成功大大提升。
第二个是向量时钟来做版本控制：用一个向量（比如说[a,1]表示这个数据在a节点第一次写入）来标记数据的版本，这样在有版本冲突的时候，可以追溯到出现问题的地方。这可以使数据的最终一致成为可能。（Cassandra未用vector clock，而只用client timestamps也达到了同样效果。）
第三个是Merkle tree来提速数据变动时的查找：使用Merkle tree为数据建立索引，只要任意数据有变动，都将快速反馈出来。
第四个是Gossip协议：一种通讯协议，目标是让节点与节点之间通信，省略中心节点的存在，使网络达到去中心化。提高系统的可用性。
❻ elasticsearch的自动发现节点机制是怎么实现的，原理是怎样
著作权归作者所有。 商业转载请联系作者获得授权，非商业转载请注明出处。 作者：ben well 链接：http://www.hu.com/question/29360024/answer/55368070 来源：知乎 早期 es 版本有 split brain 问题，俗称脑裂。ES 采用的是一种 P2P 的 gossip 选举方式，Gossip 算法因为 Cassandra 而名声大噪。 背景: Gossip 算法, 灵感来自办公室八卦, 只要一个人八卦一下, 在有限的时间内所有人都会知道该八卦的信息, 这种方式也与病毒传播类似, 因为 Gossip 有众多的别名"闲话算法"、"疫情传播算法"、"病毒感染算法"、"谣言传播(Rumor-Mongering)算法". 但 Gossip 并不是一个新东西, 之前的泛洪查找、路由算法都归属于这个范畴, 不同的是 Gossip 给这类算法提供了明确的语义、具体实施方法及收敛性证明. 特点: Gossip 算法又被称为反熵(Anti-Entropy), 熵是物理学上的一个概念, 代表杂乱无章, 而反熵就是在杂乱无章中寻求一致, 这充分说明了 Gossip 的特点：在一个有界网络中, 每个节点都随机地与其他节点通信, 经过一番杂乱无章的通信, 最终所有节点的状态都会达成一致. 每个节点可能知道所有其他节点, 也可能仅知道几个邻居节点, 只要这些节可以通过网络连通, 最终他们的状态都是一致的, 当然这也是疫情传播的特点. 要注意到的一点是, 即使有的节点因宕机而重启, 有新节点加入, 但经过一段时间后, 这些节点的状态也会与其他节点达成一致, 也就是说, Gossip 天然具有分布式容错的优点. 本质: Gossip 是一个带冗余的容错算法, 更进一步, Gossip 是一个最终一致性算法。 虽然无法保证在某个时刻所有节点状态一致, 但可以保证在”最终“所有节点一致, ”最终“是一个现实中存在, 但理论上无法证明的时间点。 因为 Gossip 不要求节点知道所有其他节点, 因此又具有去中心化的特点, 节点之间完全对等, 不需要任何的中心节点。 实际上 Gossip 可以用于众多能接受“最终一致性”的领域：失败检测、路由同步、Pub/Sub、动态负载均衡。 但 Gossip 的缺点也很明显, 冗余通信会对网路带宽、CPU 资源造成很大的负载, 而这些负载又受限于通信频率, 该频率又影响着算法收敛的速度。 总结: Gossip 是一种去中心化、容错而又最终一致性的绝妙算法, 其收敛性不但得到证明还具有指数级的收敛速度。 使用 Gossip 的系统可以很容易的把 Server 扩展到更多的节点, 满足弹性扩展轻而易举。 唯一的缺点是收敛是最终一致性, 不适应那些强一致性的场景, 比如 2PC。
❼ cassandradaemon什么进程
1、基本配置
首先需要准备3台或以上的计算机。下面假定有3台运行 Linux 操作系统的计算机，IP地址分别为 192.168.0.100, 192.168.0.101 和 192.168.0.102。 系统需要安装好 Java 运行时环境，然后到这里下载 0.7 版本的 Cassandra 二进制发行包。
挑选其中的一台机开始配置，先展开 cassandra 发行包：$ tar -zxvf apache-cassandra-$VERSION.tar.gz
$ cd apache-cassandra-$VERSION
其中的 conf/cassandra.yaml 文件为主要配置文件，0.7 版以后不再采用XML格式配置文件了，如果对 YAML 格式不熟悉的话最好先到这里了解一下。
Cassandra 在配置文件里默认设定了几个目录：data_file_directories: /var/lib/cassandra/data
commitlog_directory: /var/lib/cassandra/commitlog
saved_caches_directory: /var/lib/cassandra/saved_caches
data_file_directories 可以一次同时设置几个不同目录，cassandra 会自动同步所有目录的数据。另外在日志配置文件 log4j-server.properties 也有一个默认设定日志文件的目录：log4j.appender.R.File=/var/log/cassandra/system.log
一般情况下采用默认的配置即可，除非你有特殊的储存要求，所以现在有两种方案：一是按照默认配置创建相关的目录，二是修改配置文件采用自己指定的目录。
下面为了简单起见采用第一种方案：$ sudo mkdir -p /var/log/cassandra
$ sudo chown -R `whoami` /var/log/cassandra
$ sudo mkdir -p /var/lib/cassandra
$ sudo chown -R `whoami` /var/lib/cassandra
上面的 `whoami` 是 Linux 指令用于获取当前登录的用户名，如果你不准备用当前登录用户运行 Cassandra，那么需要把 `whoami` 替换成具体的用户名。
2、有关集群的配置
由于 Cassandra 采用去中心化结构，所以当集群里的一台机器（节点）启动之后需要一个途径通知当前集群（有新节点加入啦），Cassandra 的配置文件里有一个 seeds 的设置项，所谓的 seeds 就是能够联系集群中所有节点的一台计算机，假如集群中所有的节点位于同一个机房同一个子网，那么只要随意挑选几台比较稳定的计算机即可。在当前的例子中因为只有3台机器，所以我挑选第一台作为种子节点，配置如下： seeds:
- 192.168.0.100
然后配置节点之前通信的IP地址：listen_address: 192.168.0.100
需要注意的是这里必须使用具体的IP地址，而不能使用 0.0.0.0 这样的地址。
配置 Cassandra Thrift 客户端（应用程序）访问的IP地址：rpc_address: 192.168.0.100
这项可以使用 0.0.0.0 监听一台机器所有的网络接口。
Cassandra 的 Keyspaces 和 ColumnFamilies 不再需要配置了，他们将在运行时创建和维护。
把配置好的 Cassandra 复制到第2和第3台机器，同时创建相关的目录，还需要修改 listen_address 和 rpc_address 为实际机器的IP地址。至此所有的配置完成了。
3、启动 Cassandra 各个节点以及集群管理
启动顺序没什么所谓，只要保证种子节点启动就可以了：$ bin/cassandra -f
参数 -f 的作用是让 Cassandra 以前端程序方式运行，这样有利于调试和观察日志信息，而在实际生产环境中这个参数是不需要的（即 Cassandra 会以 daemon 方式运行）。
所有节点启动后可以通过 bin/nodetool 工具管理集群，比如查看所有节点运行情况：
$ bin/nodetool -host 192.168.0.101 ring
运行结果类似如下：
Address Status State Load Owns Token
159559...
192.168.0.100 Up Normal 49.27 KB 39.32% 563215...
192.168.0.101 Up Normal 54.42 KB 16.81% 849292...
192.168.0.102 Up Normal 73.14 KB 43.86% 159559...
命令中 -host 参数用于指定 nodetool 跟哪一个节点通信，对于 nodetool ring 命令来说，跟哪个节点通信都没有区别，所以可以随意指定其中一个节点。
从上面结果列表可以看到运行中的节点是否在线、State、数据负载量以及节点Token（可以理解为节点名称，这个是节点第一次启动时自动产生的）。我们可以使用 nodetool 组合 token 对具体节点进行管理，比如查看指定节点的详细信息：$ bin/nodetool -host 192.168.0.101 info
运行的结果大致如下：
Load : 54.42 KB
Generation No : 1302057702
Uptime (seconds) : 591
Heap Memory (MB) : 212.14 / 1877.63
查看指定节点的数据结构信息： $ bin/nodetool -host 192.168.0.101 cfstats
运行结果：
Keyspace: Keyspace1
Read Count: 0
Write Count: 0
Pending Tasks: 0
Column Family: CF1
SSTable count: 1
使用下面命令可以移除一个已经下线的节点（比如第2台机器关机了或者坏掉了） $ bin/nodetool -host 192.168.0.101 removetoken
下了线的节点如何重新上线呢看什么都不用做，只需启动 Cassandra 程序它就会自动加入集群了。
在实际运作中我们可能会需要隔一段时间备份一次数据（创建一个快照），这个操作在 Cassandra 里非常简单：$ bin/nodetool -host 192.168.0.101 snapshot
4、测试数据的读写
使用客户端组件加单元测试是首选的，如果仅想知道集群是否正常读写数据，可以用cassandra-cli 作一个简单测试：$ bin/cassandra-cli -host 192.168.0.101
接着输入如下语句：
create keyspace Keyspace1;
use Keyspace1;
create column family Users with comparator=UTF8Type and default_validation_class=UTF8Type;
set Users[jsmith][first] = 'John';
set Users[jsmith][last] = 'Smith';
get Users[jsmith];
上面语句创建了一个名为逗Keyspace1地的 keyspace，还创建了一个名为逗Users地的 Column Family，最后向 Users 添加了一个 item。正常的话应该看到类似下面的结果：
=> (column=first, value=John, timestamp=1302059332540000)
=> (column=last, value=Smith, timestamp=1300874233834000)
Returned 2 results.
❽ 为什么 elasticsearch 获取节点信息失败
为什么 elasticsearch 获取节点信息失败
早期 es 版本有 split brain 问题，俗称脑裂。ES 采用的是一种 P2P 的 gossip 选举方式，Gossip 算法因为 Cassandra 而名声大噪。
背景:
Gossip 算法, 灵感来自办公室八卦, 只要一个人八卦一下, 在有限的时间内所有人都会知道该八卦的信息,
这种方式也与病毒传播类似, 因为 Gossip 有众多的别名"闲话算法"、"疫情传播算法"、"病毒感染算法"、"谣言传播(Rumor-Mongering)算法".
但 Gossip 并不是一个新东西, 之前的泛洪查找、路由算法都归属于这个范畴, 不同的是 Gossip 给这类算法提供了明确的语义、具体实施方法及收敛性证明.
特点:
Gossip 算法又被称为反熵(Anti-Entropy), 熵是物理学上的一个概念, 代表杂乱无章, 而反熵就是在杂乱无章中寻求一致,
这充分说明了 Gossip 的特点：在一个有界网络中, 每个节点都随机地与其他节点通信, 经过一番杂乱无章的通信,
最终所有节点的状态都会达成一致. 每个节点可能知道所有其他节点, 也可能仅知道几个邻居节点,
只要这些节可以通过网络连通, 最终他们的状态都是一致的, 当然这也是疫情传播的特点.
要注意到的一点是, 即使有的节点因宕机而重启, 有新节点加入, 但经过一段时间后,
这些节点的状态也会与其他节点达成一致, 也就是说, Gossip 天然具有分布式容错的优点.
本质:
Gossip 是一个带冗余的容错算法, 更进一步, Gossip 是一个最终一致性算法。
虽然无法保证在某个时刻所有节点状态一致, 但可以保证在”最终“所有节点一致, ”最终“是一个现实中存在, 但理论上无法证明的时间点。
因为 Gossip 不要求节点知道所有其他节点, 因此又具有去中心化的特点, 节点之间完全对等, 不需要任何的中心节点。
实际上 Gossip 可以用于众多能接受“最终一致性”的领域：失败检测、路由同步、Pub/Sub、动态负载均衡。
但 Gossip 的缺点也很明显, 冗余通信会对网路带宽、CPU 资源造成很大的负载, 而这些负载又受限于通信频率, 该频率又影响着算法收敛的速度。
❾ cassandra在pom.xml里面怎么设置library
1.执行代码//CassandraTest.scalaimportorg.apache.spark.{Logging,SparkContext,SparkConf}importcom.datastax.spark.connector.cql.{defmain(args:Array[String]){#配置spark，cassandra的ip，这里都是本机valSparkMasterHost="127.0.0.1"valCassandraHost="127.0.0.1"//:valconf=newSparkConf(true).set("spark.cassandra.connection.host",CassandraHost).set("spark.cleaner.ttl","3600").setMaster("local[12]").setAppName("CassandraTestApp")//ConnecttotheSparkcluster:lazyvalsc=newSparkContext(conf)//预处理脚本,连接的时候就执行这些CassandraConnector(conf).withSessionDo{session=>session.execute("={'class':'SimpleStrategy','replication_factor':1}")session.execute("CREATETABLEIFNOTEXISTStest.key_value(keyINTPRIMARYKEY,valueVARCHAR)")session.execute("TRUNCATEtest.key_value")session.execute("INSERTINTOtest.key_value(key,value)VALUES(1,'firstrow')")session.execute("INSERTINTOtest.key_value(key,value)VALUES(2,'secondrow')")session.execute("INSERTINTOtest.key_value(key,value)VALUES(3,'thirdrow')")}//加载connectorimportcom.datastax.spark.connector._//Readtabletest.kvandprintitscontents:valrdd=sc.cassandraTable("test","key_value").select("key","value")rdd.collect().foreach(row=>println(s"ExistingData:$row"))//Writetwonewrowstothetest.kvtable:valcol=sc.parallelize(Seq((4,"fourthrow"),(5,"fifthrow")))col.saveToCassandra("test","key_value",SomeColumns("key","value"))//.kvtable:assert(col.collect().length==2)col.collect().foreach(row=>println(s"NewData:$row"))println(s"Workcompleted,stoppingtheSparkcontext.")sc.stop()}}2.目录结构由于构建工具是用sbt，所以目录结构也必须遵循sbt规范，主要是build.sbt和src目录，其它目录会自动生成。qpzhang@qpzhangdeMac-mini:~/scala_code/CassandraTest$lltotal8drwxr-xr-x6qpzhangstaff204112612:14./drwxr-xr-x10qpzhangstaff340112517:30../-rw-r--r--1qpzhangstaff460112610:11build.sbtdrwxr-xr-x3qpzhangstaff102112517:42project/drwxr-xr-x3qpzhangstaff102112517:32src/drwxr-xr-x6qpzhangstaff204112517:55target/qpzhang@qpzhangdeMac-mini:~/scala_code/CassandraTest$treesrc/src/└──main└──scala└──CassandraTest.scalaqpzhang@qpzhangdeMac-mini:~/scala_code/CassandraTest$catbuild.sbtname:="CassandraTest"version:="1.0"scalaVersion:="2.10.4"libraryDependencies+="org.apache.spark"%%"spark-core"%"1.5.2"%"provided"libraryDependencies+="com.datastax.spark"%%"spark-cassandra-connector"%"1.5.0-M2":={casePathList(ps@_*)ifps.lastendsWith".properties"=>MergeStrategy.firstcasex=>valoldStrategy=().valueoldStrategy(x)}这里需要注意的是，sbt安装的是当时最新版本0.13,并且安装了assembly插件(这里要吐槽一下sbt，下载一坨坨的jar包，最好有FQ代理，否则下载等待时间很长)。qpzhang@qpzhangdeMac-mini:~/scala_code/CassandraTest$cat~/.sbt/0.13/plugins/plugins.sbtaddSbtPlugin("com.typesafe.sbteclipse"%"sbteclipse-plugin"%"2.5.0")addSbtPlugin("com.eed3si9n"%"sbt-assembly"%"0.14.1")3.sbt编译打包在build.sbt目录下，使用sbt命令启动。然后使用compile命令进行编译，使用assembly进行打包。在次期间，遇到了sbt-assembly-deplicate-error的问题，参考这里。>compile[success]Totaltime:0s,completed2015-11-2610:11:50>>assembly[info]Includingfromcache:slf4j-api-1.7.5.jar[info]Includingfromcache:metrics-core-3.0.2.jar[info]Includingfromcache:netty-codec-4.0.27.Final.jar[info]Includingfromcache:netty-handler-4.0.27.Final.jar[info]Includingfromcache:netty-common-4.0.27.Final.jar[info]Includingfromcache:joda-time-2.3.jar[info]Includingfromcache:netty-buffer-4.0.27.Final.jar[info]Includingfromcache:commons-lang3-3.3.2.jar[info]Includingfromcache:jsr166e-1.1.0.jar[info]Includingfromcache:cassandra-clientutil-2.1.5.jar[info]Includingfromcache:joda-convert-1.2.jar[info]Includingfromcache:netty-transport-4.0.27.Final.jar[info]Includingfromcache:guava-16.0.1.jar[info]Includingfromcache:spark-cassandra-connector_2.10-1.5.0-M2.jar[info]Includingfromcache:cassandra-driver-core-2.2.0-rc3.jar[info]Includingfromcache:scala-reflect-2.10.5.jar[info]Includingfromcache:scala-library-2.10.5.jar[info]Checkingevery*.class/*.jarfile'sSHA-1.[info]Mergingfiles[warn]Merging'META-INF/INDEX.LIST'withstrategy'discard'[warn]Merging'META-INF/MANIFEST.MF'withstrategy'discard'[warn]Merging'META-INF/io.netty.versions.properties'withstrategy'first'[warn]Merging'META-INF/maven/com.codahale.metrics/metrics-core/pom.xml'withstrategy'discard'[warn]Merging'META-INF/maven/com.datastax.cassandra/cassandra-driver-core/pom.xml'withstrategy'discard'[warn]Merging'META-INF/maven/com.google.guava/guava/pom.xml'withstrategy'discard'[warn]Merging'META-INF/maven/com.twitter/jsr166e/pom.xml'withstrategy'discard'[warn]Merging'META-INF/maven/io.netty/netty-buffer/pom.xml'withstrategy'discard'[warn]Merging'META-INF/maven/io.netty/netty-codec/pom.xml'withstrategy'discard'[warn]Merging'META-INF/maven/io.netty/netty-common/pom.xml'withstrategy'discard'[warn]Merging'META-INF/maven/io.netty/netty-handler/pom.xml'withstrategy'discard'[warn]Merging'META-INF/maven/io.netty/netty-transport/pom.xml'withstrategy'discard'[warn]Merging'META-INF/maven/joda-time/joda-time/pom.xml'withstrategy'discard'[warn]Merging'META-INF/maven/org.apache.commons/commons-lang3/pom.xml'withstrategy'discard'[warn]Merging'META-INF/maven/org.joda/joda-convert/pom.xml'withstrategy'discard'[warn]Merging'META-INF/maven/org.slf4j/slf4j-api/pom.xml'withstrategy'discard'[warn]Strategy'discard'wasappliedto15files[warn]Strategy'first'wasappliedtoafile[info]SHA-1:[info]Packaging/Users/qpzhang/scala_code/CassandraTest/target/scala-2.10/CassandraTest-assembly-1.0.jar[info]Donepackaging.[success]Totaltime:19s,completed2015-11-2610:12:224.提交到spark，执行结果qpzhang@qpzhangdeMac-mini:~/project/spark-1.5.2-bin-hadoop2.6$./bin/spark-submit--class"CassandraTestApp"--masterlocal[4]~/scala_code/CassandraTest/target/scala-2.10/CassandraTest-assembly-1.0.jar//5/11/2611:40:23INFOTaskSetManager:Startingtask0.0instage0.0(TID0,localhost,NODE_LOCAL,26660bytes)15/11/2611:40:23INFOExecutor:Runningtask0.0instage0.0(TID0)15/11/2611:40:23INFOExecutor:Fetchinghttp://10.60.215.42:57683/jars/CassandraTest-assembly-1.0./11/2611:40:23INFOCassandraConnector::TestCluster15/11/2611:40:23INFOUtils:Fetchinghttp://10.60.215.42:57683/jars/CassandraTest-assembly-1.0.jarto/private/var/folders/2l//T/spark-4030cadf-8489-4540-976e-e98eedf50412/userFiles-63085bda-aa04-4906-9621-c1cedd98c163/.tmp15/11/2611:40:23INFOExecutor:Addingfile:/private/var/folders/2l//T/spark-4030cadf-8489-4540-976e-e98eedf50412/userFiles-63085bda-aa04-4906-9621-c1cedd98c163/CassandraTest-assembly-1.0.jartoclassloader15/11/2611:40:24INFOCluster:NewCassandrahostlocalhost/127.0.0.1:9042added15/11/2611:40:24INFOCassandraConnector:ConnectedtoCassandracluster:TestCluster15/11/2611:40:25INFOExecutor:Finishedtask0.0instage0.0(TID0).2676bytesresultsenttodriver15/11/2611:40:25INFOTaskSetManager:Finishedtask0.0instage0.0(TID0)in2462msonlocalhost(1/1)15/11/2611:40:25INFOTaskSchelerImpl:RemovedTaskSet0.0,whosetaskshaveallcompleted,frompool15/11/2611:40:25INFODAGScheler:ResultStage0(collectatCassandraTest.scala:32)finishedin2.481s15/11/2611:40:25INFODAGScheler:Job0finished:collectatCassandraTest.scala:32,took2.940601sExistingData:CassandraRow{key:1,value:firstrow}ExistingData:CassandraRow{key:2,value:secondrow}ExistingData:CassandraRow{key:3,value:thirdrow}//..5/11/2611:40:27INFOTaskSchelerImpl:RemovedTaskSet3.0,whosetaskshaveallcompleted,frompool15/11/2611:40:27INFODAGScheler:ResultStage3(collectatCassandraTest.scala:41)finishedin0.032s15/11/2611:40:27INFODAGScheler:Job3finished:collectatCassandraTest.scala:41,took0.046502sNewData:(4,fourthrow)NewData:(5,fifthrow)Workcompleted,stoppingtheSparkcontext.cassandra中的数据cqlsh:test>select*fromkey_value;key|value-----+------------5|fifthrow1|firstrow2|secondrow4|fourthrow3|thirdrow(5rows)到此位置，还算顺利，除了assembly重复文件的问题，都还算ok。