开发者学堂课程【2020版大数据实战项目之DMP广告系统（第三阶段）：KuduSpark_DF 优势】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/678/detail/11786
KuduSpark_DF 优势
接下来继续了解 spark 和 kudu 的整合，Spark.sql 也就是 spark 离线处理当中最重要的一个对象、一个数据结构是 dataframe。接下来介绍 dataframe 和 kudu，有一些前提，刚才了解了增删改数据，但是怎么查？可以想一想 Spark、Data frame、Spark.sql 的作用是什么。Spark.sql 可以使用 SQL 语句进行相应的数据处理和转换，SQL 语句就是一种查询语句，所以 spark 当中的 dateframe 就是做查询的，所以使用 dateframe 去查 kudu 就最合适。Dateframe 还支持写，但是在介绍 dateframe 的读写 kudu 之前，先去介绍一下 dataframe 操作 kudu 的优势，再了解 dateframe 落地到 kudu以及 Dataframe 读取 kudu 表。
接下来介绍说 dataframe 操作 kudu 的优势，它有什么样的优点。
一、DataFrame 操作 Kudu 的优势
1、谓词下推
先问一个问题，这有一条非常简单的语句，是使用 spark.sql 进行完成的，spark.sql 当中可以 select*from kudu，这个 kudu 肯定是读出来的一个 dataframe，然后注册为临表，才能够在使用 SQL 语句的时候查询这张临表，但是这张表也是来自于 kudu 的。首先，介绍两个前提知识，第一个前提知识，spark.read 的时候生成的 dataframe 中可能是没有数据的，当 action 执行的时候才会进行数据读取，这一点称之为延迟加载或者懒加载这样的一个道。第二步，直接 select*还好，但是如果 select name 就有一个问题了，这叫做投影操作，投影操作是将一个大数据集投影为小数据集，然后操作小数据集，这样的一个过程就叫做投影。
针对于投影来说，投影发生在什么时候更合适，有两个选择，第一个选择是在 kudu 上进行投影，这样 spark 拿到的数据就只有一个列，换句话说，其实就是 kudu 来做投影。第二种，在 spark 上进行投影，spark 拿到所有的数据列，然后再投影。两种方式显然是1更好，spark 在和 kudu 进行整合的时候，有一个优化叫做谓词下推。比如在进行查询的时候只 select 一个列，那么这一个列会推给 kudu，kudu 给 spark 的数据当中就只有一个列，那么 Spark 就无需再去处理所有的数据从其中拿出一个列，那么 spark 处理的数据量越小，效能就越高，这就是谓词下推。
Spark 做到谓词下推得益于刚才所说的第一点，懒加载。Spark 会把整个执行计划生成以后，然后再去处理、优化这个执行计划，到 kudu 这一边就只剩下一个相对比较好的执行计划，那么它会把这个谓词下推给 kudu 来进行执行。
2、DataFrame 读取的时候有分区
Dataframe 内部是 RDD，RDD 是弹性分布式数据集，分布式是支持分区，前面在 spark 当中着重介绍了好几次分区，就是为了让大家理解 spark 最大的优势就是分区。一个 RDD 或者一个 dataframe 的分区对应了一个 kudu 的分片，kudu 的表可以分片，表会分布在不同的 tablet 里头，tablet 又分布在不同的 tablet server 当中。
但是这个地方还有一个小问题，首先，kudu 表分布为 tablet，tablet 分布在 tablet server 当中。第二点，一个tablet 可能分布在多个 tablet server 中，因为第三点，一个 tablet 是有复制因子的，根据 factor，会复制对应的数量份，第四点，逻辑上的一个 tablet 可能真实会有多个 tablet 存在，这些 tablet 之间存在主从关系，假如一个 tablet，那么这个 tablet 可能会有三个物理上的 tablet，一个是 leader，两个是 follower，默认的复制因子是3。理解一下刚才所说的内容，主要就两点，Tablet 可以分片，kudu 的表可以分片，每一片对应一个逻辑的 tablet，一个逻辑上的 tablet 又对应了多个物理上的 tablet，分布在不同的 tablet server 上。如果是这样的话，RDD 的分区能否读取 leader tablet 和 follower tablet，问题很简单，一个 RDD 的分区有可能对应 kudu 的一个 tablet，那么它也有可能对应多个 tablet，也有可能对应 follower 的 tablet，一个逻辑上的 tablet 分为多个物理上的 tablet，它们又分为 leader 和 follower。
kuduclient 在读取数据的时候，只能读 leader，在写数据的时候写也是 leader，也就是通过 leader 的 tablet 来进行读写，然后把数据分发给其他的 follower tablet，这是传统的 kuduclient。在 spark 当中，RDD 的分区可以对应一个 tablet leader，也可以对应 tablet follower，对应 follower 当中它也可以读写 follower tablet 当中的数据，如果有这一点存在，那么 Spark 再去读取一张 kudu 表的时候，它的并发性就会更好，简单来说，kudu 默认情况下，数据的读写只能发生 kudu tablet leader 上，和 spark 整合，读操作也可以发生在 follower tablet 上，但现在这个版本还不支持写的时候写到 follower 上，读的时候可以从 follower 上读的，在读取的时候，这个并发性就会更好。
这就是 dataframe 操作 kudu 的优势。
