简单记录一下在使用cassandra与spark集成时踩到的坑

在spark的实际使用中，生成的结果集可能还会做为其他流程的数据源，进行再次分析处理，本文主要提供一个将spark结果集持久化到关系型数据库（postgresql）中的思路，毕竟对于小规模的数据，使用关系型数据库的sql处理展现数据比起nosql数据库会更加方便。

本文主要通过一个具体的spark application来讲述spark job执行过程中关于stage划分，stage提交，task运行的流程。主要也是因为上篇的源码阅读只有纯粹的理论，所以希望能通过这篇实战将理论讲的更清楚一点。

今天终于有时间把spark的源代码看了下，因为之前一直对spark的任务调度流程比较模糊，而网上关于spark的设计实现文档又不太完整，所以这篇文章主要用于梳理这方面的逻辑关系，并不会对代码的细节实现作过多的讨论，我对scala来说，也只能算个新手，许多复杂的语法和实现，无法太深入解读，只能比较宏观地介绍一下其中的逻辑和目的，如果有错漏之处，请多指教。顺便吐槽一下看源代码真是望山跑死马啊，短短一句代码隐藏N多细节。

今天翻文档的时候，偶然发现自己去年还写过一篇关于信息安全综合分析的审计方案文档草稿，真是不胜唏嘘。

上篇在讲到cassandra查询语句之坑的时候，有提到一个叫allow filtering的东东，但是令人费解的是，这货有时候出现有时候又不用出现。那到底这是怎么用的呢，让我们来用一个例子说明。首先还是沿用上篇的table2：

在Cassandra中，primary key是一个非常重要的概念。关系型数据库中表可以没有primary key（主键），但是Cassandra中建表时必须指定primary key，它不仅决定了表的结构，而且还对数据查询方式的差异有巨大影响。partition key, composite key 和 clustering key共同组成了Cassandra的primary key。

相信用过oracle的人，特别是用oracle做后端数据库开发的程序猿都听说过硬解析和软解析。

在任何一样计算机软件产品中，当我们需要考虑其性能的时候，往往都会从CPU，IO，Network这三个方面考虑。CPU代表着处理问题的能力，IO代表着存储的吞吐能力，Network代表着数据传输的能力。oracle当然也不例外。

执行计划是sql在数据库中最终的执行路径，包括索引的扫描，数据的读取，过滤，连接，排序等等一系列过程。就像平常在生活中你为了完成一个任务，需要经过很多步骤，如果没有很好的统筹规划，任务时间会不断延长。所以sql的效率跟它的执行计划息息相关，同一个sql可能会有很多不一样的执行计划，基于CBO的oracle会在其中挑选出它认为最快的执行计划进行执行。下面这个流程图展现了优化器选择执行计划过程：