前言
首先安装好Ceph,可以参考我上篇文章Ceph分布式集群安装配置
版本
spark: 2.4.5
hadoop: hdp版本 3.1.1.3.1.0.0-78
spark-shell读写S3
jar包配置
1 | hadoop-aws-3.1.1.3.1.0.0-78.jar 注意版本要和hadoop版本对应 |
将上面的jar包拷贝到$SPARK_HOME/jars
more >>
首先安装好Ceph,可以参考我上篇文章Ceph分布式集群安装配置
spark: 2.4.5
hadoop: hdp版本 3.1.1.3.1.0.0-78
1 | hadoop-aws-3.1.1.3.1.0.0-78.jar 注意版本要和hadoop版本对应 |
将上面的jar包拷贝到$SPARK_HOME/jars
more >>
记录Ceph分布式集群安装配置过程及问题解决
主机名 | 角色 | IP地址 |
---|---|---|
ceph1 | ceph-deploy、mon、mgr、osd | 192.168.44.128 |
ceph2 | mon、mgr、osd | 192.168.44.129 |
ceph3 | mon、mgr、osd | 192.168.44.130 |
要保证每台机器能连接外网
1 | wget -qO /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo |
记录博主第一次使用Flink SQL查询Hive的配置以及问题解决过程
博主目前还没有用过Flink,没有写过Flink代码,完全是一个小白。之所以使用Flink,是因为博主目前需要测试使用dolphinscheduler的一些功能,其中包括Flink数据源,这里Flink数据源我们使用的是Kyuubi Flink Engine,且学会、了解了Flink之后对于学习Hudi、Kyuubi也是有帮助的。
flink-1.14.3,这里使用kyuubi1.5.2自带的Flink
HDP环境,Hadoop、Hive等已经安装配置好
1 | export HADOOP_CLASSPATH=`hadoop classpath` |
可以添加在比如/ect/profile里,这样等于修改全局的环境,如果想只对Flink生效,可以添加在bin/config.sh文件里
more >>一开始我对
hadoop classpath
理解错了,以为是自己手动修改成实际的路径,但是hadoop对应的jar包的路径有很多,后来发现它的意思是执行命令hadoop classpath
将返回值赋给HADOOP_CLASSPATH
上一篇文章Hudi Spark源码学习总结-spark.read.format(“hudi”).load分析了load方法直接查询Hudi表路径的源码逻辑,那么Spark SQL select 表名的方式和load最终走的逻辑是一样的吗?本文带着这个疑问来分析一下select查询Hudi表的源码逻辑
Spark 2.4.4
Hudi master 0.12.0-SNAPSHOT 最新代码
(可以借助Spark3 planChangeLog 打印日志信息查看哪些规则生效,Spark3和Spark2生效的规则大致是一样的)
先Create Table,再Insert几条数据
1 | spark.sql(s"select id, name, price, ts, dt from $tableName").show() |
补充上一篇文章Hudi Spark源码学习总结-spark.read.format(“hudi”).load,由于上篇文章篇幅已经比较长了,所以单独写一篇补充一下,没有读过的可以先阅读一下,我们在上篇文章讲到resolveBaseFileOnlyRelation
返回的是HadoopFsRelation
,那么如果返回BaseFileOnlyRelation
呢?
其实除了HadoopFsRelation
、BaseFileOnlyRelation
还有IncrementalRelation
、MergeOnReadSnapshotRelation
、MergeOnReadIncrementalRelation
、HoodieBootstrapRelation
,之所有要单独看一下BaseFileOnlyRelation
,是因为我们从提交历史上可以看出,一开始默认的就是HadoopFsRelation
后来添加了自定义的BaseFileOnlyRelation
,然后现在回退成了HadoopFsRelation
,查看对应PR了解了一下原因
添加BaseFileOnlyRelation
的PR:[HUDI-3338] custom relation instead of HadoopFsRelation,原因是:目前,HadoopFsRelation
将使用实际分区路径的值作为分区字段的值。但是,与普通表不同,Hudi在Parquet文件中保留分区值。在某些情况下,实际分区路径的值和分区字段的值是不同的。因此,这里实现了BaseFileOnlyViewRelation
,通过它,Hudi可以管理自己的关系。
回退为HadoopFsRelation
的PR:[HUDI-3902] Fallback to HadoopFsRelation in cases non-involving Schema Evolution,原因是:Spark的一些优化规则(以及一些其他处理)是基于HadoopFsRelation
的使用,这导致当我们依赖自定义Relation
时,这些优化没有得到应用。我们可以在[HUDI-3338]的PR的下面可以看到,有commiter提出,使用BaseFileOnlyRelation
后查询性能相比于之前的HadoopFsRelation
下降了大约一倍,这是因为Spark仅在少数地方做了查询优化,其中一个地方就是我们在上篇文章中讲到的FileSourceStrategy
,我们看到[HUDI-3902]虽然回退到HadoopFsRelation
,但是貌似并没有处理分区路径值的问题,所以后面又提了一个PR:
PR:[HUDI-3204] Fixing partition-values being derived from partition-path instead of source columns,这个PR添加了自定义FileFormat
:Spark24HoodieParquetFileFormat
,它重写了ParquetFileFormat
的buildReaderWithPartitionValues
方法。其中的关键点是添加了参数shouldAppendPartitionValues
来判断是否将分区路径中的值添加为分区字段的值。
1 | if (shouldAppendPartitionValues) { |
tag:
缺失模块。
1、请确保node版本大于6.2
2、在博客根目录(注意不是yilia根目录)执行以下命令:
npm i hexo-generator-json-content --save
3、在根目录_config.yml里添加配置:
jsonContent: meta: false pages: false posts: title: true date: true path: true text: false raw: false content: false slug: false updated: false comments: false link: false permalink: false excerpt: false categories: false tags: true