在这个，我们的最后一章，是时候分享一些最后的建议，因为你正在努力在生产中部署Cassandra。我们将讨论在规划部署时要考虑的选项，并探讨在各种云环境中部署Cassandra的选项。我们将关注一些与Cassandra相得益彰的技术。

规划群集部署

Cassandra的成功部署始于良好的规划。您将需要考虑群集将容纳的数据量，将部署群集的网络环境以及运行实例的计算资源（无论是物理还是虚拟）。

调整群集大小

规划群集的重要第一步是考虑需要存储的数据量。当然，您可以在群集中添加和删除节点，以便随着时间的推移调整其容量，但计算一段时间内的初始和计划大小将有助于您在规划群集配置时更好地预测成本并做出合理的决策。

为了计算集群所需的大小，您首先需要使用我们在第5章中介绍的公式确定每个支持的表的存储大小。此计算基于每个表中的列以及估计的行数并导致磁盘上一个数据副本的估计大小。

为了估计群集中给定表所需的实际物理磁盘存储量，您还需要考虑表的键空间的复制因子和正在使用的压缩策略。得到的总大小TtT_tTt的公式如下：

Tt=St×RFk×CSFtT_t = S_t \times RF_{k} \times CSF_t Tt=St×RFk×CSFt

其中StS_tSt是使用上面引用的公式计算的表的大小，RFkRF_kRFk是键空间的复制因子，CSFtCSF_tCSFt是表示表的压缩策略的因子，其值如下：

2用于SizeTieredCompactionStrategy。该策略的最坏情况是，存在主要压缩所需的所有数据的第二个副本。
1.25其他压实策略，估计在主要压实过程中需要额外20％的压缩。

一旦我们知道了所有表的数据的总物理磁盘大小，我们就可以在所有键空间和表中对这些值求和，以得到我们集群的总数。

然后，我们可以将此总数除以每个磁盘的可用存储空间量，以估算所需的磁盘数。对磁盘可用存储空间的合理估计是磁盘大小的90％。

请注意，此计算基于在每个磁盘上提供足够的开销以处理所有键空间和表的主要压缩的假设。如果可以确保运营团队永远不会执行这样的主要压缩，则可以减少所需的开销，但这似乎是一个冒险的假设。

调整Cassandra的系统Keyspaces

警报读者可能想知道在各种系统密钥空间中用于Cassandra内部数据存储的磁盘空间。与磁盘大小相比，这通常是无关紧要的。我们创建了一个三节点集群，并测量每个节点的数据存储大小约为18 MB，没有额外的密钥空间。

如果您经常使用跟踪，这肯定会大大增加，但system_traces表确实使用TTL来允许跟踪数据到期，从而防止这些表随着时间的推移而压倒您的数据存储。

一旦计算出所需的大小和节点数量，您就可以更好地决定初始簇大小。您构建到群集中的容量取决于您预测增长的速度，这必须与其他硬件（无论是物理硬件还是虚拟硬件）的成本进行平衡。

选择实例

无论您是在物理硬件上还是在虚拟化云环境中运行，为Cassandra节点选择正确的计算资源都很重要。现代Cassandra版本（2.0及更高版本）的推荐计算资源往往因开发与生产环境而不同：

开发环境

开发环境中的Cassandra节点通常应具有至少具有两个内核和8 GB内存的CPU。尽管Cassandra已成功运行在具有512 MB内存的Raspberry Pi等较小处理器上，但这确实需要进行大量的性能调整。
生产环境

生产环境中的Cassandra节点应具有至少具有八个核心的CPU（尽管虚拟机可接受四个核心），以及16 MB到64 MB的内存。

Docker和其他容器部署

另一种迅速普及的部署选项，特别是在Linux社区中，是Docker等软件容器。

容器的价值主张通常被称为“一次构建，随处部署。”容器引擎支持为软件创建轻量级，便携式容器的能力，可以在各种硬件平台上轻松移动和部署。

在Docker中，每个容器都是一个轻量级虚拟机，提供进程隔离，以及一个单独的文件系统和网络适配器。 Docker引擎位于应用程序和操作系统之间。

在Docker中部署Cassandra的主要挑战与网络和数据目录有关。 Docker中的默认部署使用软件定义的路由。在撰写本文时，该层的性能目前将Cassandra吞吐量降低了约50％，因此推荐的配置是直接使用主机网络堆栈。这会将部署限制为每个容器的单个Cassandra节点。

如果您尝试在容器中运行多个Cassandra实例，则这实际上仅适用于开发环境。您需要仔细考虑我们在第12章中讨论的内存设置。

从数据管理的角度来看，您需要将数据目录配置为容器本身之外。这将允许您在要升级或停止容器时保留数据。

这些相同的考虑因素适用于其他容器技术，但细节略有不同。这是一个新兴领域，未来几个月和几年可能会出现持续变化。

存储

选择和配置存储时需要考虑几个因素，包括要使用的驱动器的类型和数量：

硬盘与SSD

Cassandra支持硬盘驱动器（HDD，也称为“旋转驱动器”）和固态驱动器（SSD）进行存储。尽管Cassandra使用基于追加的写入有助于在旋转驱动器上进行顺序写入，但SSD总体上提供了更高的性能，因为它们支持低延迟随机读取。

从历史上看，硬盘驱动器一直是更具成本效益的存储选项，但使用固态硬盘的成本却持续下降，尤其是越来越多的云平台提供商将其作为存储选项支持。
磁盘配置

如果您使用旋转磁盘，最好使用单独的磁盘来存储数据和提交日志文件。如果您使用的是SSD，则数据和提交日志文件可以存储在同一磁盘上。
JBOD与RAID

传统上，Cassandra社区建议将多个磁盘用于数据文件，并将磁盘配置为独立磁盘冗余阵列（RAID）。由于Cassandra使用复制来实现跨多个节点的冗余，因此RAID 0（或“条带卷”）配置被认为是足够的。

最近，Cassandra用户一直在使用Just a Bunch of Disks（JBOD）部署风格。 JBOD方法提供了更好的性能，如果您能够更换单个磁盘，则是一个不错的选择。
避免共享存储

选择存储时，请避免使用存储区域网络（SAN）和网络连接存储（NAS）。这些存储技术都没有很好地扩展 - 它们消耗额外的网络带宽以便通过网络访问物理存储，并且它们在读取和写入时都需要额外的I / O等待时间。

网络

因为Cassandra依赖于涉及多个网络节点的分布式架构，所以您需要考虑以下几点：

吞吐量

首先，确保您的网络足够强大，以处理与跨多个节点分发数据相关的流量。建议的网络带宽为1 GB或更高。
网络配置

确保为节点和网络设备正确配置了防火墙规则和IP地址，以允许用于CQL本机传输，节点间通信（listen_address），JMX等的端口上的流量。这包括数据中心之间的联网（我们将暂时讨论集群拓扑）。

应使用网络时间协议（NTP）或其他方法同步所有节点上的时钟。请记住，如果新值的时间戳比现有值的时间戳更新，Cassandra只会覆盖列。如果没有同步时钟，可能会丢失滞后节点的写入。
避免负载平衡器

负载平衡器是许多计算环境的一个特征。虽然这些通常可用于在多个服务或应用程序实例之间传播传入流量，但不建议将负载均衡器与Cassandra一起使用。 Cassandra已经提供了自己的机制来平衡节点之间的网络流量，DataStax驱动程序在副本之间传播客户端查询，因此严格来说负载均衡器不会提供任何额外的帮助。除此之外，在Cassandra节点前放置负载均衡器实际上会引入潜在的单点故障，这可能会降低群集的可用性。
超时

如果您正在构建跨多个数据中心的群集，那么最好测量数据中心之间的延迟并相应地调整cassandra.yaml文件中的超时值。

正确的网络配置是Cassandra成功部署的关键，无论是在私有数据中心，跨越多个数据中心的公共云，还是混合云环境。

云部署

现在我们已经了解了规划集群部署的基础知识，让我们来看看我们在三个最受欢迎的公共云提供商中部署Cassandra的选项。

使用商业云计算提供商可以实现几个关键优势。首先，您可以从多个数据中心中进行选择，以保持高可用性。如果将群集扩展到主动 - 主动配置中的多个数据中心并实施完善的备份策略，则可以避免必须创建单独的灾难恢复系统。

其次，使用商业云提供商可以将数据置于更接近客户群的数据中心，从而缩短应用程序响应时间。如果您的应用程序的使用情况是季节性的，您可以根据当前需求在每个数据中心中扩展和收缩集群。

您可能希望使用已包含Cassandra的预建图像来节省时间。还有一些公司将Cassandra作为托管服务提供给软件即服务（SaaS）产品。
不要忘记云资源成本

在规划公共云部署时，您需要确保估算运行群集的成本。不要忘记考虑包括计算服务，节点和备份存储以及网络在内的资源。

亚马逊网络服务

亚马逊网络服务（AWS）一直是Cassandra的流行部署选项，Cassandra项目中存在特定于AWS的扩展，如Ec2Snitch，Ec2MultiRegionSnitch和DataStax Java驱动程序中的EC2MultiRegion地址转换器。

群集布局

AWS围绕区域和可用区域的概念进行组织，这些区域和可用区域通常分别映射到数据中心和机架的Cassandra构造。跨越us-east-1（弗吉尼亚州）和eu-west-1（爱尔兰）区域的AWS集群拓扑示例如图14-1所示。节点名称是名义上的 - 这个命名不是必需的约定。

EC2实例

Amazon Elastic Compute Cloud（EC2）提供根据各种类别分组的各种不同虚拟硬件实例。最常用于Cassandra部署的两个类是M级和I级。

M级实例是平衡计算，内存和网络资源的通用实例，通常可用于开发和轻型生产环境。后来的M级实例（如M3和M4）是SSD支持的。

I-Class实例都支持SSD，专为高I / O而设计。这些实例的成本较高，通常可以为负载较重的生产集群带来回报。

您可以在https://aws.amazon.com/ec2/instance-types找到有关各种实例类型的更多信息。

DataStax Enterprise提供预构建的亚马逊机器映像（AMI）以简化部署（在Cassandra 2.1发布后，DataStax社区版的AMI已停止使用）。
数据存储

过去，AWS中推荐的磁盘选项是使用附加到每个实例的临时存储。这样做的缺点是，如果正在运行节点的实例终止（如AWS中偶尔发生的那样），则数据将丢失。到2015年底，被称为弹性块存储（EBS）的网络附加存储已经被证明可以提供一个可靠的存储数据的位置，这些数据在丢弃EC2实例时不会消失，但代价是额外的延迟。

S3和Glacier等AWS服务分别是备份的中短期和长期存储的良好选择。
联网

如果您正在运行多区域配置，则需要确保区域之间有足够的网络连接。许多人发现使用AWS虚拟私有云（VPC）的元素提供了一种在区域之间实现可靠，高吞吐量连接的有效方法。 AWS Direct Connect提供专用专用网络，并且还提供虚拟专用网络（VPN）选项。这些服务当然需要额外付费。

如果您使用区域之间的VPN连接进行单区域部署或多区域部署，请使用Ec2Snitch。如果您具有在区域之间使用公共IP的多区域部署，请使用Ec2MultiRegionSnitch。对于任何一个小报，通常建议在AWS网络环境中将cassandra.yaml文件中的phi_convict_threshold值增加到12。

Microsoft Azure

DataStax和微软已合作，共同帮助改进Windows和Ubuntu Linux操作系统中Microsoft Azure中Cassandra的部署。

群集布局

Azure使用与AWS相同的术语“区域”在全球各地提供数据中心。可用性集的概念用于管理VM的集合。 Azure管理跨更新域的可用性集中的VM分配，这相当于Cassandra的机架。
虚拟机实例

与AWS类似，Azure提供了几类VM。 D系列，D系列v2和G系列机器都是适用于Cassandra部署的SSD支持的实例。 G系列VM提供了集成所需的额外内存，如下所述。您可以在https://azure.microsoft.com/en-us/pricing/details/virtual-machines 上找到有关Azure VM类型的更多信息。
数据存储

Azure在前面提到的实例上提供标准SSD功能。此外，您还可以升级到使用高级存储，高级存储可提供最大1 TB的大型网络连接SSD。
联网

建议对单区域和多区域部署使用公共IP地址。使用GossipingPropertyFileSnitch允许您的节点检测群集拓扑。区域之间的网络选项包括VPN网关和Express Route，它提供高达2 GB / s的吞吐量。

Google云端平台

Google Cloud Platform提供云计算，应用程序托管，网络，存储以及各种软件即服务（SaaS）产品，例如Google的翻译和预测API。

群集布局

Google Compute Environment（GCE）提供的区域和区域分别对应于Cassandra的数据中心和机架。
虚拟机实例

GCE的n1标准和n1-highmemory机器类型建议用于Cassandra部署。您可以使用Cloud Launcher在Google Cloud Platform上快速启动Cassandra。例如，如果您通过https://cloud.google.com/launcher/?q=cassandra搜索启动器，则只需点击几下按钮即可找到创建群集的选项。
数据存储

GCE为短暂驱动器（local-ssd）和网络连接驱动器（pd-ssd）提供旋转磁盘（pd-hdd）和固态磁盘选项。有三种存储选项可用于存储Cassandra备份，每种备份具有不同的成本和可用性配置文件：标准，持久性降低可用性（DRA）和近线。
联网

GoogleCloudSnitch是专为GCE设计的自定义小贴士。区域之间可以使用VPN网络。

集成

正如我们在第2章中所学到的，Cassandra对于许多应用程序来说都是一个很好的解决方案，但这并不能保证它能为您的应用程序或企业提供所需的一切。在本节中，我们将讨论可与Cassandra配对的几种技术，以便为搜索和分析等功能提供更强大的解决方案。

Apache Lucene，SOLR和Elasticsearch

在Cassandra之上构建的应用程序中通常需要的功能之一是全文搜索。这个功能可以通过Apache Lucene添加到Cassandra，它提供了分布式索引和搜索的引擎，以及它的子项目Apache Solr，它为Lucene搜索引擎添加了REST和JSON API。

Elasticsearch是另一种基于Apache Lucene构建的流行的开源搜索框架。它支持多租户，并通过HTTP API提供Java和JSON。

Stratio提供了一个插件，可用于用Lucene索引替换Cassandra的标准二级索引实现。使用此集成时，每个Cassandra节点上都有一个Lucene索引，可提供高性能搜索功能。

Apache Hadoop

Apache Hadoop是一个框架，可在商用硬件上提供分布式存储和大型数据集处理。这项工作起源于21世纪初的谷歌。谷歌发现几个内部小组一直在实施类似的数据处理功能，这些工具通常分为两个阶段：地图阶段和减少阶段。 map函数对原始数据进行操作并生成中间值。 reduce函数可以提取这些中间值，从而产生最终输出。 2006年，Doug Cutting编写了谷歌文件系统和MapReduce的开源实现，因此，Hadoop诞生了。

与Cassandra类似，Hadoop使用分布式架构，节点以簇的形式组织。典型的集成是在每个将用于提供数据的Cassandra节点上安装Hadoop。您可以通过在每个Cassandra节点上运行Hadoop任务跟踪器和数据节点来使用Cassandra作为数据源。然后，当启动MapReduce作业时（通常在Cassandra集群外部的节点上），作业跟踪器可以在跟踪映射和减少任务时查询Cassandra的数据，如图14-2所示。

从21世纪后期开始，Hadoop一直是大数据社区兴趣和增长的巨大推动力。由于其受欢迎程度，围绕Hadoop开发了一个庞大的扩展生态系统，例如Apache Pig，它提供了数据分析的框架和语言，以及Apache Hive，一种数据仓库工具。 Hadoop社区已经开始远离MapReduce，因为它的性能相对较慢（所有数据都写入磁盘，即使是中间处理步骤），高内存使用，非直观API和仅批处理模式。出于这个原因，Apache Spark项目的出现得到了重大发展。

Apache Spark

Apache Spark是一种新兴的数据分析框架，它提供了一个大规模并行处理框架，可以跨大量数据实现简单的API调用。 Spark最初于2009年在加州大学伯克利分校开发，作为对MapReduce的改进，于2010年开源，并于2014年成为Apache项目。

与将中间结果写入磁盘的Hadoop不同，Spark核心处理引擎旨在最大限度地提高内存使用率，同时最大限度地减少磁盘和网络访问。 Spark使用流式传输而不是面向批处理的处理来实现比Hadoop快100倍的处理速度。此外，Spark的API比Hadoop简单易用。

Spark中数据表示的基本单位是弹性分布式数据集（RDD）。 RDD是要处理的数据的描述，例如文件或数据集合。创建RDD后，可以使用API调用转换包含的数据，就好像所有数据都包含在一台机器中一样。但是，实际上，RDD可以通过分区跨越网络中的许多节点。每个分区可以并行操作以产生最终结果。 RDD支持熟悉的映射和减少操作以及其他操作，如count，filter，union和distinct。有关转换的完整列表，请参阅Spark文档。

除核心引擎外，Spark还包含用于不同类型处理要求的更多库。这些包含在与Spark核心分开管理的子项目中，但遵循类似的发布计划：

SparkSQL为结构化数据提供熟悉的SQL语法和关系查询。
MLlib是Spark的机器学习库。
SparkR支持在Spark作业中使用R统计语言。
GraphX是Spark用于图形和集合分析的库。
Spark Streaming提供实时数据流的近实时处理。

Spark与Cassandra的用例

正如我们在本书中所讨论的那样，Apache Cassandra是需要高规模和最大可用性的事务性工作负载的绝佳选择。 Apache Spark是大规模分析大量数据的绝佳选择。将这两者结合起来可以实现许多利用这两种技术的强大功能。

示例用例是高容量时间序列数据。用于从数千个具有可变容量的传感器摄取天气数据的系统非常适合Cassandra。收集数据后，鉴于使用CQL可用的分析功能有限，对Cassandra中存储的数据的进一步分析可能会很困难。此时，将Spark添加到解决方案将为收集的数据打开许多新用途。例如，我们可以从原始传感器数据预构建聚合，并将这些结果存储在Cassandra表中，以便在前端应用程序中使用。这使得分析更接近用户，而无需在运行时运行复杂的数据仓库查询。

或者考虑我们在本书中一直使用的酒店应用程序。我们可以使用Spark在我们的预订和访客数据上实施各种分析任务，例如生成收入趋势报告或匿名访客记录的人口统计分析。

要避免的一个用例是使用Spark-Cassandra集成作为Hadoop工作负载的替代方案。 Cassandra适用于大批量的事务性工作负载，不应被视为数据仓库。当接近可能需要这两种技术的用例时，首先应用Cassandra来解决适合Cassandra的问题，例如我们在第2章中讨论的问题。然后考虑将Spark作为一种分析和丰富存储在Cassandra中的数据的方法，而不是提取，转换和加载（ETL）处理的成本和复杂性。

使用Cassandra部署Spark

Cassandra根据令牌分配为每个节点放置数据。此现有数据分布可用作并行化Spark作业的优势。由于每个节点都包含集群数据的子集，因此Spark-Cassandra集成的推荐配置是在数据中心的每个Cassandra节点上共同定位Spark Worker，如图14-3所示。

将作业提交给Spark Master时，每个节点上的Spark Workers会生成Spark Executors以完成工作。使用spark-cassandra-connector作为管道，每个作业所需的数据尽可能来自本地节点。我们将暂时了解有关连接器的更多信息。

由于每个节点都包含集群中整个数据的一部分，因此每个Spark Worker只需要处理该本地数据子集。一个例子是对表的计数操作。每个节点都有一个表的数据范围。计数在本地计算，然后从每个节点合并以产生总计数。

此设计可最大化数据局部性，从而提高分析作业的吞吐量并降低资源利用率。当需要从其他节点合并数据时，Spark Executors仅通过网络进行通信。随着簇尺寸变大，这种设计的效率增益更加明显。

使用单独的数据中心进行分析

Cassandra和分析工具集（如Spark）的通用部署模型是为分析处理创建单独的数据中心。这样做的好处是可以将分析工作负载的性能影响与群集的其余部分隔离开来。分析数据中心可以构建为“虚拟”数据中心，其中实际硬件与群集内的另一个数据中心位于相同的物理位置。使用NetworkTopologyStrategy，您可以为分析数据中心指定较低的复制因子，因为此数据中心中所需的可用性通常较低。

spark-cassandra-connector

spark-cassandra-connector是一个由DataStax在GitHub上赞助的开源项目。客户端可以将连接器用作通过Spark从Cassandra表读取和写入数据的管道。连接器提供的功能包括SQL查询和服务器端筛选。连接器在Scala中实现，但也可以使用Java API。来自spark-cassandra-connector的API调用可在与基础数据相关的上下文中直接访问Cassandra中的数据。当Spark访问数据时，连接器将作为数据源转换为Cassandra和从Cassandra转换。

要开始使用spark-cassandra-connector，您需要同时下载连接器和Spark。虽然详细的安装指南超出了我们的范围，但我们将给出快速摘要。为了更加详尽的介绍，我们建议使用O’Reilly的书“学习星火”。您可以下载预构建的Spark版本，也可以从源代码自行构建Spark。

如果您使用Java或Scala构建应用程序并使用Maven，则需要将以下依赖项添加到项目的pom.xml文件中以访问Spark核心和连接器：

<dependency><groupId>org.apache.spark</groupId><artifactId>spark-core_2.10</artifactId><version>1.5.2</version>
</dependency>
<dependency><groupId>com.datastax.spark</groupId><artifactId>spark-cassandra-connector_2.10</artifactId><version>1.5.0</version>
</dependency>

Spark支持两种部署模式：本地和集群。集群模式涉及中央Spark Master和许多计算节点。本地模式完全在本地主机上运行; 这种模式最适合开发。对于此示例，我们将以本地模式运行，但群集只需要几个步骤。

让我们回顾一下用于访问Cassandra数据的大多数Spark作业的常用API元素。在本节中，我们选择在Scala中编写示例，因为它具有简单性和可读性，以及Spark和许多Spark应用程序都是用Scala编写的。 Java API类似但更冗长; 我们在本书的GitHub存储库中提供了此示例代码的Java版本。要将Spark应用程序连接到Cassandra，首先需要创建一个包含连接参数的Spark Context：

val conf = new SparkConf(true).set("spark.cassandra.connection.host", "127.0.0.1").setMaster("local[*]").setAppName(getClass.getName)// Optionally     .set("cassandra.username", "cassandra")     .set("cassandra.password", "cassandra")val sc = new SparkContext(conf)

在Cassandra和Spark之间建立连接只是指向正在运行的Cassandra集群和Spark Master的过程。此示例配置显示如何连接到本地Cassandra节点和Spark Master。如果需要，您还可以提供Cassandra登录凭据。

创建SparkContext后，您可以通过创建表示Cassandra表的RDD来操作Cassandra数据。例如，让我们创建一个RDD，表示第5章中介绍的预留键空间中的reservations_by_hotel_date表：

val rdd = sc.cassandraTable("reservation", "reservations_by_hotel_date")

创建RDD后，您可以对其执行转换和操作。例如，要获取预留总数，请创建以下操作以计算表中的每个记录：

println("Number of reservations: " + rdd.count)

因为它作为与Cassandra并行运行的分析作业运行，所以它比从cqlsh运行SELECT count（*）FROM预留更有效。

由于RDD的底层结构是Cassandra表，因此您可以使用CQL过滤数据并选择行。在Cassandra中，使用本机CQL过滤查询需要使分区键高效，但在将查询作为Spark作业运行时会删除该限制。

例如，您可以派生一个用例来生成一个报告，列出截止日期的预订，以便每个酒店都能知道谁在某一天结账。在此示例中，end_date不是分区键或群集列，但您可以扫描整个群集的数据，查找结帐日期为2016年9月8日的预订：

val rdd = sc.cassandraTable("reservation", "reservations_by_hotel_date").select("hotel_id", "confirm_number").where("end_date = ?", "2016-09-08")// Invoke the action to run the spark job
rdd.toArray.foreach(println)

查找和检索数据只是可用功能的一半 - 您还可以将数据保存回Cassandra。传统上，事务数据库中的数据需要提取到单独的位置才能执行分析。使用spark-cassandra-connector，您可以提取数据，进行适当的转换，并将其直接保存回Cassandra表，从而消除了昂贵且容易出错的ETL过程。将数据保存回Cassandra表非常简单：

// Create a collection of guests with simple identifiers
val collection = sc.parallelize(Seq(("1", "Delaney", "McFadin"), ("2", "Quinn", "McFadin")))// Save to the guests table
collection.saveToCassandra("reservation", "guests", SomeColumns("guest_id", "first_name", "last_name"))

这是一个简单的示例，但基本语法适用于任何数据。更高级的示例是计算酒店的平均每日收入，并将结果写入新的Cassandra表。在传感器应用程序中，您可以计算给定日期的高温和低温，并将这些结果写回Cassandra。

查询数据不仅限于Spark API。使用SparkSQL，您可以使用熟悉的SQL语法对Cassandra中的数据执行复杂查询，包括CQL中不可用的查询选项。创建增强查询（如聚合，排序和连接）很容易。

要在代码中嵌入SQL查询，需要创建一个CassandraSQL上下文：

// Use the SparkContext to create a CassandraSQLContext
val cc = new CassandraSQLContext(sc)// Set the keyspace
cc.setKeyspace("reservation")
val rdd = cc.cassandraSql("
SELECT hotel_id, confirm_number
FROM reservations_by_hotel_date
WHERE end_date = '2016-09-08'
ORDER BY hotel_id")// Perform action to run SQL job
rdd.collect().foreach(println)

SQL语法类似于之前的Spark作业，但对于具有传统数据库背景的用户来说更为熟悉。要探索编写Spark作业之外的数据，您还可以使用spark-sql shell，它可以在Spark安装的bin目录下找到。

DataStax Enterprise中的集成

DataStax Enterprise是Cassandra的产品化版本，支持本章中描述的许多集成。具体而言，DSE Search提供与Solr的集成，而DSE Analytics提供与Apache Spark的集成以及Hadoop生态系统的元素，如MapReduce，Hive和Pig。

其他DSE功能包括额外的安全提供程序插件和内存配置，适用于需要极快响应时间的应用程序。

总结

在本章中，我们刚刚介绍了Cassandra可用的许多部署和集成选项。希望我们能够激发您对使用Cassandra及相关技术的各种方向的兴趣。

现在我们一起走完了我们的旅程。如果我们已经实现了目标，您现在可以深入了解使用Cassandra解决的正确问题，以及如何设计，实现，部署和维护成功的应用程序。

第十四章：Cassandra部署与整合--Cassandra：The Definitive Guide 2nd Edition相关推荐

第六章： Cassandra架构--Cassandra：The Definitive Guide 2nd Edition
在本章中,我们将研究Cassandra架构的几个方面,以了解它如何完成其工作. 我们将解释集群的拓扑结构,以及节点如何在对等设计中进行交互,以使用诸如八卦,反熵和暗示切换等技术来维护集群的健康状况并交 ...
鸟哥的Linux私房菜(基础篇)- 第二十四章、 X Window 配置介绍
第二十四章. X Window 配置介绍最近升级日期:2009/08/07 在 Linux 上头的图形介面我们称之为 X Window System,简称为 X 或 X11 罗!为何称之为系统呢?这 ...
《深入理解 Spring Cloud 与微服务构建》第十四章服务链路追踪 Spring Cloud Sleuth
<深入理解 Spring Cloud 与微服务构建>第十四章服务链路追踪 Spring Cloud Sleuth 文章目录 <深入理解 Spring Cloud 与微服务构建> ...
第二十四章、 X Window 配置介绍
好文章第二十四章. X Window 配置介绍 http://vbird.dic.ksu.edu.tw/linux_basic/0590xwindow.php 最近升级日期:2009/08/07 在 ...
R语言学习笔记——高级篇：第十四章-主成分分析和因子分析
R语言 R语言学习笔记--高级篇:第十四章-主成分分析和因子分析文章目录 R语言前言一.R中的主成分和因子分析二.主成分分析 2.1.判断主成分的个数 2.2.提取主成分 2.3.主成分旋转 ...
第十四章：监测和维护活动目录(一)(译自WindowsServer2008ActiveDirectoryResourceKit)
前言: windows server 2008系统相信大家也都接触了有段时间了,尤其最近打上了sp2补丁以后变得更加成熟和完善. 不知道大家的企业有没有已经开始使用windows server 200 ...
《网络安全工程师笔记》第十四章：渗透简单测试流程
注:本笔记来自温晓飞老师的网络安全课程第十四章:渗透简单测试流程第一章:虚拟化架构与系统部署第二章:IP地址详解第三章:进制转换第四章:DOS基本命令与批处理第五章:用户与组管理第六章: ...
游戏感：虚拟感觉的游戏设计师指南——第十四章生化尖兵
这是一本游戏设计方面的好书转自天:天之虹的博客:http://blog.sina.com.cn/jackiechueng 感谢天之虹的无私奉献 Word版可到本人的资源中下载第十四章生化尖兵 &l ...
第二十四章并发编程
第二十四章并发编程爱丽丝:"但是我不想进入疯狂的人群中" 猫咪:"oh,你无能为力,我们都疯了,我疯了,你也疯了" 爱丽丝:"你怎么知道我疯了&q ...

第十四章：Cassandra部署与整合--Cassandra：The Definitive Guide 2nd Edition