Spark Read/Write Hudi Development Specifications

Updated on 2024-08-30 GMT+08:00

View PDF

Specifications of the parameters in various write modes for the Spark write Hudi

Type	Description	Enable parameter	Scenario Selection	Features
upsert	update + insert Hudi default write type, which has the update capability.	This parameter is set by default and does not need to be set to Enabled. SparkSQL: set hoodie.datasource.write.operation=upsert; DataSource Api: df.write .format("hudi") .options(xxx) .option("hoodie.datasource.write.operation", "upsert") .mode("append") .save("/tmp/tablePath")	The default value is selected.	Pros: Small files can be merged. Updates are supported. Disadvantages: Write speed go by the rules to the letter.
append	Directly write data without updates	Spark: Spark does not have the pure append mode. You can use the bulk insert mode instead. SparkSQL: set hoodie.datasource.write.operation = bulk_insert; set hoodie.datasource.write.row.writer.enable = true; DataSource Api: df.write .format("hudi") .options(xxx) .option("hoodie.datasource.write.operation", "bulk_insert") .option("hoodie.datasource.write.row.writer.enable", "true") .mode("append") .save("/tmp/tablePath")	High throughput and no data update scenario.	Pros: Fastest write speed. Disadvantages: Small files cannot be merged. No update capability. Clustering is required to merge small files.
delete	Delete operation	No parameter is required. You can directly use the delete syntax. delete from tableName where primaryKey='id1';	The SQL statement deletes data.	Same as the upsert type.
Insert overwrite	Override partition	No parameter is required. Use the insert overwrite syntax directly. insert overwrite table tableName partition (dt = '2021-01-04') select * from srcTable;	Partition level again.	Overwrite the partition.
Insert overwrite table	Override the entire table	No parameter is required. Use the insert overwrite syntax directly. insert overwrite table tableName select * from srcTable;	Rewrite it all.	Overwrite the entire table.
Bulk_insert	Batch Import	SparkSQL: set hoodie.datasource.write.operation = bulk_insert; set hoodie.datasource.write.row.writer.enable = true; DataSource Api: df.write .format("hudi") .options(xxx) .option("hoodie.datasource.write.operation", "bulk_insert") .option("hoodie.datasource.write.row.writer.enable", "true") .mode("append") .save("/tmp/tablePath")	You are advised to use this tool during table initialization and migration.	The mode is the same as the append mode.

Specifications for Spark to read Hudi parameters in incremental mode

Type	Description	Enable parameter	Scenario Selection	Features
snapshot	Real-time data reading.	Default value. No parameter is required to enable this function. SparkSQL: set hoodie.datasource.query.type=snapshot; DataSource Api: val df = spark.read .format("hudi") .option("hoodie.datasource.query.type", "snapshot") .load("tablePath")	Default selection	Each read data is the latest, and the data is visible immediately after being written.
incremental	Incremental query. Only the data between two commit operations is queried.	SparkSQL: set hoodie.tableName.consume.mode=INCREMENTAL;// The current table must be read in incremental mode. set hoodie.tableName.consume.start.timestamp=20201227153030;// Specify the initial incremental pull. commit set hoodie.tableName.consume.end.timestamp=20210308212318; // specifies the end of the incremental pull. If the end of the commit operation is not specified, the latest commit operation is used. select * from tableName where `_hoodie_commit_time`>' 20201227153030'and `_hoodie_commit_time`<=' 20210308212318'; //The results must be filtered by start.timestamp and end.timestamp. If end.timestamp is not specified, the results are filtered by start.timestamp. set hoodie.tableName.consume.mode=SNAPSHOT; // After using the incremental mode, the query mode must be reset. DataSource Api: val df = spark.read .format("hudi") .option("hoodie.tableName.consume.mode", "INCREMENTAL") .option("hoodie.tableName.consume.start.timestamp", "20201227153030") .option("hoodie.tableName.consume.end.timestamp", "20210308212318") .load("tablePath") .where ("`_hoodie_commit_time`>' 20201227153030' and `_hoodie_commit_time`<=' 20210308212318 '")	In the streaming processing scenario, only incremental data is obtained each time.	Reads only the data between two commit operations. It is not a full table scan, which is much more efficient than obtaining the data before the commit operation by using the where condition.
read_optimized	Read-optimized view. Only the data in the parquet file in the table is read. For the mor table, new data is written to the log. Therefore, the data read in this mode is not the latest.	SparkSQL: When the Mor table is synchronized to Hive, three tables are generated: primary table, ro table, and rt table. The ro table is the read optimization table. You can directly read the ro table. select * from tableName_ro; DataSource Api: val df = spark.read .format("hudi") .option("hoodie.datasource.query.type", "read_optimized") .load("tablePath")	The query performance is required, but the data delay is acceptable.	For the mor table, the performance of this read mode is much faster than that of the real-time table. In this mode, log data is not read and can be read only after data is compacted. Therefore, data reading in this mode has a certain data latency.

Type

Description

Enable parameter

Scenario Selection

Features

snapshot

Real-time data reading.

Default value. No parameter is required to enable this function.

SparkSQL:

set hoodie.datasource.query.type=snapshot;

DataSource Api:

val df = spark.read
.format("hudi")
.option("hoodie.datasource.query.type", "snapshot")
.load("tablePath")

Default selection

Each read data is the latest, and the data is visible immediately after being written.

incremental

Incremental query. Only the data between two commit operations is queried.

SparkSQL:

set hoodie.tableName.consume.mode=INCREMENTAL;// The current table must be read in incremental mode.
set hoodie.tableName.consume.start.timestamp=20201227153030;// Specify the initial incremental pull. commit
set hoodie.tableName.consume.end.timestamp=20210308212318; // specifies the end of the incremental pull. If the end of the commit operation is not specified, the latest commit operation is used.
select * from tableName where `_hoodie_commit_time`>' 20201227153030'and `_hoodie_commit_time`<=' 20210308212318'; //The results must be filtered by start.timestamp and end.timestamp. If end.timestamp is not specified, the results are filtered by start.timestamp.
set hoodie.tableName.consume.mode=SNAPSHOT; // After using the incremental mode, the query mode must be reset.

DataSource Api:

val df = spark.read
.format("hudi")
.option("hoodie.tableName.consume.mode", "INCREMENTAL")
.option("hoodie.tableName.consume.start.timestamp", "20201227153030")
.option("hoodie.tableName.consume.end.timestamp", "20210308212318")
.load("tablePath")
.where ("`_hoodie_commit_time`>' 20201227153030' and `_hoodie_commit_time`<=' 20210308212318 '")

In the streaming processing scenario, only incremental data is obtained each time.

Reads only the data between two commit operations. It is not a full table scan, which is much more efficient than obtaining the data before the commit operation by using the where condition.

read_optimized

Read-optimized view.

Only the data in the parquet file in the table is read. For the mor table, new data is written to the log. Therefore, the data read in this mode is not the latest.

SparkSQL:
When the Mor table is synchronized to Hive, three tables are generated: primary table, ro table, and rt table. The ro table is the read optimization table. You can directly read the ro table.
```
select * from tableName_ro;
```

DataSource Api:

val df = spark.read
.format("hudi")
.option("hoodie.datasource.query.type", "read_optimized")
.load("tablePath")

The query performance is required, but the data delay is acceptable.

For the mor table, the performance of this read mode is much faster than that of the real-time table. In this mode, log data is not read and can be read only after data is compacted. Therefore, data reading in this mode has a certain data latency.