并且从*.hoodie/20230530073115535.deltacommit* 获取internalSchemaOpt，具体的合并就是把即将写入的schema和internalSchemaOpt进行合并。因为是"bulk insert"操作，所以没有去重的需要，所以直接采用spark原生的方式，把df的schema转换成avro的schema。），则会进行去重处理，具体是调用。开始写操作，这

spark on k8s 跟 spark operator的对比对于目前基于k8s的的spark应用，主要采用两种方式运行spark原生支持的 spark on k8s基于k8s的operator的 spark on k8s operator前者是spark社区支持k8s这种资源管理框架而引入的k8s client的实现后者是k8s社区为了支持spark而开发的一种operator区别spark

支持update，支持upsert（merge），具体看类IcebergSparkSqlExtensionsParser.replaceRowLevelCommands。分区是隐藏的，在查询时不需要添加关于分区的筛选条件，建表的时候指定分区的来源（由哪个字段计算而来）Iceberg有catalog的概念，是对表进行管理(create，drop等)的一个组件。需要额外的服务治理小文件,额外的服务清理

目前Spark写hive表有两种形式，一种是基于 Hive 原生的模式，一种是Spark native datasource的模式, 这两种模式可以通过配置的参数。方法的过程，尤其如果说是已存在的hive表有百万分区的话，很容易造成。，该方法会从把hive中的properties的信息传给。，这个方法如果对于分区数比较多的情况下是比较耗时的，而且。对于第一种原生的hive写入方式来说，最终调用的是

首先是反序列化CleanPlan,然后在进行清理，主要是删除1. 如果没有满足的分区，直接删除该分区，2. 否则删除该分区下的满足条件的文件,最后返回。HoodieFlinkMergeOnReadTable*类型的hudi表,用来做clean等操作。,也就是在写数据失败的时候，会立即进行这次写失败的数据的清理，在这种情况下，创建一个只有一个线程的线程池，改线程池的主要作用来异步执行hudi写操作。

背景我们知道，随着计算引擎战争的结束（SPARK赢得了离线处理的霸权），越来越多的公司致力于性能的优化，而引擎的优化，目前直指计算的向量化，这片文章来说说spark本身对于向量化的实现。spark本身的优化我们都知道spark的Tungsten项目，这个项目中有一点就是Code Generation（代码生成）。代码生成除了消除虚函数的调用等功能外，其实在向量化这块也是做了处理的。直接跳到Colu

背景最近在帮同事排查hive UDF的时候，发现了在udf中定义了静态成员变量引发的NullPointerException，具体报错如下：java.lang.NullPointerExceptionat java.lang.String.contains(String.java:2133)at org.apache.spark.sql.hive.HiveGenericUDF.eval(hiveU

spark CTAS nuion all （union all的个数很多）导致超过spark.driver.maxResultSize配置（2G）

spark on k8s 基础镜像的构建背景这是跑spark on k8s任务的基础镜像，用来指明executor pod的基础镜像构建步骤git clone spark特定的版本（加入是3.0.1版本），克隆完后，执行一下命令进行构建,构建出包含kubernetes模块的可运行包：./dev/make-distribution.sh --name 2.6.0-cdh5.13.1--pip --t

背景对于spark shuffle service（以下简称RSS）,在社区其实早就有探讨SPARK-25299,只不过一直没有达成一致，且目前的内置的shuffle service 也能满足大部分的场景，也就被搁置了，但是由于kubernetes的越来越火热,spark社区也慢慢的集成了spark on k8s，当然k8s社区也集成了spark,具体区别见spark on k8s 与 spark