Fendora范东_2021-04-30对RDD和DataFrame的理解 1.首先区分这两个东西，RDD分布式数据集;DF是带数据模式的结构化分布式数据集。核心区别在于DF带数据模式(感觉像传统分布式数据库中的一张表)，RDD不带数据模式或者说是泛型的。 2.其次是这两者分别提供的API，RDD API优化引擎是Spark Core(没理解这句话，我理解Spark Core负责task调度计算存储，和优化的联系在哪呢？);DF API优化引擎是SparkSQL，包括Catalyst执行过程优化和Tungsten数据结构优化。两者API的区别在于一个提供标量算子一个高阶算子和两者底层优化引擎不一致。 3.上面两组概念应该区分开。之前子框架如Streaming，mlib,graph都是采用RDD API来编写，现在都是采用DF API来重新编写。 4.调用DF API生成DF，但DF 的action算子触发执行后最终还是生成RDD，通过Spark Core框架来进行调度计算。所以可不可以认为DF API+SparkSQL就是代替了之前的RDD API？目的就是为了提供更简单的API，让Spark做统一优化，在rdd计算时更高效？展开作者回复: Perfect x 4 ！ 理解得非常到位了~ 老弟的概括能力很强，确实，把握这4点，关于RDD和DataFrame的区别与联系，其实就算是吃透了。 关于你说的第二点，确实，Spark Core实际就是分布式运行时，负责分布式任务调度、执行，严格来说，并不存在什么优化机制，仅仅是分发分布式代码、运行、状态交互，等等。 第四点说得尤其到位，大赞👍
共 2 条评论14
sky_sql2021-04-29老师好，DataFrame和RDD这两套独立的API，最终还是会转化为RDD之上的计算吧？作者回复: 对，没错，DataFrame的code，经过Spark SQL优化之后，最终交由Tungsten生成代码和RDD[InternalRow]，代码交由DAGScheduler进行分发、运行在RDD[InternalRow]之上。 后面的21、22、23会详细展开从DataFrame到Catalyst、再到Tungsten，最终生成代码和RDD的过程，可以重点关注下哈~
10
CycleGAN2021-05-16老师好，我们的业务有很复杂的计算udf，用dsl或者sql无法描述，PySpark嵌入udf，使得优化无能为力，性能也一直很低，我们对于反复使用的数学操作会编译成so执行，也在提升udf本身的执行效率，请问将python的udf改写成scala提升会大吗？老师对于我们写复杂udf有什么建议吗？作者回复: 好问题，UDF本身的开销其实大家有目共睹。不过对于你的cases来说，其实没办法武断地说用Scala重写效果如何。因为就像咱们最开始讲调优方法论的时候一样，其实这取决于UDF本身是不是整体作业的瓶颈。 对于UDF的优化，我觉得不妨这样，就是从你众多的UDF中，选中一个开销最大的，或者至少是“看上去”开销最大的，然后用Scala优化，对比前后作业端到端的执行效果，然后再去决定，要不要对其他UDF做同样的优化。 另外，对于复杂的业务逻辑，如果DSL和SQL都无法实现，除了UDF，其实还可以考虑用Script Transformation，这块Facebook有个最佳实践，可以参考下，看看对你们是否有帮助：https://databricks.com/session_eu19/powering-custom-apps-at-facebook-using-spark-script-transformation
共 5 条评论6- Geek_d794f82021-04-29磊哥，Tungsten 使用定制化的数据结构 Unsafe Row 来存储数据，是不是指的cache缓存的时候使用Unsafe Row存储的数据，或是shuffle溢写到磁盘的时候存储的结构，还是说从数据源读进来的时候会转化成Unsafe Row的结构？
作者回复: 都对，或者换句话说，只要是走Spark SQL的流程（DataFrame、Dataset、SQL三种API），就都能利用到Tungsten的这种二进制Unsafe Row。比如，就像你说的： 1）缓存的时候，可以利用得到，Tungsten用Unsafe Row来封装每条数据记录； 2）数据源读进来的时候（当然这么说不太严谨，严格来说，应该是Tungsten生成的“手写代码”交付执行的时候，在运行时执行读取数据源的时候，会把它convert成Tungsten的二进制Unsafe Row）； 3）Shuffle的时候也是一样，不仅如此，Shuffle还能利用文中介绍的Memory Page（一个JVM对象），来进一步提升内存的利用效率。
6 
aof2021-05-05PySpark应用中如果用到了Python里面的数据结构都会导致在JVM进程和Python进程间进行交互的吧作者回复: 对没错，除此之外，还有万恶的UDF。
5
Z宇锤锤2021-05-02Java Object 在对象存储上为什么会有比较大的开销？ 我查阅了了一些资料，Java对象的存储在JVM上至少需要32或64Bit的字节存储对象自身信息，哈希码（HashCode）、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳。 "ABCD"的存储至少需要8个字节。作者回复: 是的，你说的这些开销都对，不过“ABCD”在JVM中实际需要48个字节才能存下哈~ 我怀疑你是不是漏打了个4，哈哈~ 具体计算细节可以参考这里：https://databricks.com/blog/2015/04/28/project-tungsten-bringing-spark-closer-to-bare-metal.html
共 4 条评论4
强2021-11-01曾经看到一个视频,说是Dataset后续要取代DataFrame。Dataset和DataFrame这两者之间有什么关系？实际项目中用的哪个偏多些？作者回复: 好问题~ DataFrame和Dataset的关系，非常紧密。 首先，DataFrame实际上是Dataset[Row]，不论是DataFrame、还是Dataset，他们都能享受到Spark SQL带来的性能红利，因此在执行效率上，二者没有区别。 因此，两者的区别，最主要的，还是在开发效率。DataFrame其实就是二维表，承载结构化数据。Dataset可以用来处理非结构化数据，但是Dataset需要用户明确定义数据类型，比如自定义的Person、School之类的。 所以总结下来，如果需要处理结构化数据，一般大家都会用DataFrame，因为简单直接，不需要自定义User Class，省去这一步的麻烦。但如果需要从（非结构化）日志解析一些内容，往往会用Dataset先把数据抽出来，得到结构化数据之后，再考虑转成DataFrame，方便后续处理。 一言以蔽之，没有优劣之分，只有不同的适应场景。一般来说，DataFrame用的偏多，因为大部分情况，我们处理的都是结构化数据。相应地，Dataset用的就会少一些。另外，Dataset取代DataFrame这种说法，听听就好了，不用特别当真~
3- Z宇锤锤2021-05-02RDD和DataFrame的最大区别，DF像是一张二维表，可以用来写SQL。RDD只能使用算子。
作者回复: DF确实就是二维表，和RDD相比，除了API的区别之外，最大的区别，还是DF可以走Spark SQL做优化~
共 2 条评论1 - Geek_d794f82021-04-29Tungsten的这种存储数据结构，感觉和parquet类似，他们之间有什么关联吗
作者回复: 确实有相似之处，毕竟都是用二进制的形式来存储数据，所以会有相通的地方。 不过，两者没啥联系哈，实际上，我倒是觉得，Parquet的数据结构，要比Tungsten的复杂得多。
共 3 条评论1 - sky_sql2021-04-28RDD是Spark对于分布式数据模型的抽象，调度、存储都是RDD维度的，DataFrame底层是使用RDD的算子实现的吧？ 对于普通开发者后面使用DataFrame实现业务逻辑，尽量不使用RDD？
作者回复: DataFrame底层不是RDD实现的，DataFrame和RDD是两套独立的API。区别在于，RDD的优化引擎是Spark Core；而DataFrame的优化引擎是Spark SQL，这个我们后面3讲：21、22、23会详细的介绍哈~ 对于开发者来说，强烈推荐DataFrame开发API，放弃RDD开发API。Spark SQL的优化机制远胜于Spark Core，换句话说，同样的业务应用，仅仅是API不同，你用DataFrame开发的code，天然地就比你用RDD开发的code，在执行效率上面更高，啥都不用调优，天然就更快。
共 3 条评论1