DataHub introduces batch serialization and zstd compression to significantly reduce server-side resource consumption, improve performance, and lower costs for users.
Upgrade details
Support for zstd compression
DataHub now supports Zstandard (zstd) compression. Compared with LZ4 and Deflate, zstd delivers better compression ratios and performance.
Zstd is a high-performance compression algorithm developed by Facebook and open-sourced in 2016. It excels in both compression speed and ratio, making it well-suited for DataHub workloads.
Serialization transformation
Batch serialization is a method for organizing data in DataHub. Rather than referring to a specific serialization format, it involves a secondary encapsulation of serialized data. For example, to send 100 data records in a batch, the records are first serialized into a buffer, then compressed, and finally wrapped with a header that stores the buffer size, record count, compression algorithm, CRC checksum, and other metadata. The resulting buffer with the header represents a complete batch.
Batch serialization provides the following benefits:
-
Effectively mitigates dirty data.
-
Reduces CPU overhead on backend servers and improves data processing performance.
-
Reduces latency for read and write operations.
After a batch buffer is sent to the server, the server only needs to verify the CRC checksum to confirm the buffer integrity, because the client has already performed thorough data validity checks. Once verified, the server can persist the buffer directly to disk without additional serialization, deserialization, compression, decompression, or validation. This optimization improves server performance by more than 80%. Compressing multiple data entries together also improves the compression ratio, which reduces storage costs.
Cost comparison
To verify the benefits of batch serialization, the following test data and conditions are used:
-
About 200 columns of advertising-related data are used for the test. The ratio of null values in the test data is about 20% to 30%.
-
Each 1,000 data entries comprise a batch.
-
Apache Avro is used for batch serialization.
-
Before the upgrade, LZ4 is used for data compression by default. After the upgrade, zstd is used for data compression by default.
The following table lists the test results.
|
Original data size (unit: bytes) |
Size of data compressed by using LZ4 (unit: bytes) |
Size of data compressed by using zstd (unit: bytes) |
|
|
Protobuf serialization |
11,506,677 |
3,050,640 |
1,158,868 |
|
Batch serialization |
11,154,596 |
2,931,729 |
1,112,693 |
Cost reduction is compared across the two main billing dimensions of DataHub: storage and traffic. Other billable items are designed to prevent abuse and can be ignored under normal usage.
-
Storage costs: When DataHub uses Protobuf serialization, data in storage is not compressed but data is compressed only during transmission over HTTP. After the batch serialization+zstd mode is used, the storage size is reduced from 11,506 KB to 1,112 KB. This means that the storage costs are reduced by about 90%.
-
Traffic costs: When DataHub uses the Protobuf+LZ4 mode, the data size is 3,050 KB. When DataHub uses the batch serialization+zstd mode, the data size is 1,112 KB. This means that the traffic costs are reduced by about 60%.
The preceding results are based on sample data. Actual results vary depending on your data. We recommend that you run your own tests based on your business requirements.
Use batch serialization
Usage notes
-
The main advantage of batch writing is the ability to gather data records in batches. If a client cannot gather records into a batch, or the number of records per batch is small, the improvements may not meet your expectations.
-
For convenience, batch mode is compatible with the original read and write methods, ensuring a smooth transition. Data written in batch mode can still be read in the original mode, and vice versa. However, if data is written in batches, we recommend that it is also consumed in batches. Otherwise, the performance may be deteriorated.
Prerequisites
-
The multi-version schema feature is enabled.
-
The Client library 1.4 or later is used.
-
Only DataHub SDK for Java is supported.
Enable the multi-version schema feature
Enable the multi-version schema feature in the console
You cannot modify existing topics in the console. To use batch serialization, you must turn on Enable Multi-version when you create a topic. For more information about how to create a topic, see Create and configure topics.

Enable the multi-version schema feature by using an SDK
public static void createTopicWithOption() {
try {RecordSchema recordSchema = new RecordSchema() {{
this.addField(new Field("field1", FieldType.STRING));
this.addField(new Field("field2", FieldType.BIGINT));
}};
TopicOption option = new TopicOption();
// Enable the multi-version schema feature.
option.setEnableSchemaRegistry(true);
option.setComment(Constant.TOPIC_COMMENT);
option.setExpandMode(ExpandMode.ONLY_EXTEND);
option.setLifeCycle(Constant.LIFE_CYCLE);
option.setRecordType(RecordType.TUPLE);
option.setRecordSchema(recordSchema);
option.setShardCount(Constant.SHARD_COUNT);
datahubClient.createTopic(Constant.PROJECT_NAME, Constant.TOPIC_NAME, option);
LOGGER.info("create topic successful");
} catch (ResourceAlreadyExistException e) {
LOGGER.info("topic already exists, please check if it is consistent");
} catch (ResourceNotFoundException e) {
// project not found
e.printStackTrace();
throw e;
} catch (DatahubClientException e) {
// other error
e.printStackTrace();
throw e;
}
}
Configure batch serialization
If the server supports the batch transmission protocol, DataHub uses batch serialization by default. If the server does not support the protocol — for example, it does not run the latest version of Apsara Stack or runs a version earlier than Apsara Stack V3.16 — DataHub automatically falls back to the original serialization method. Clients adapt automatically without additional configuration. The following example uses Client library 1.4.1. The system automatically selects the optimal compression algorithm. For Client library 1.4 or later, zstd is used by default.
Add Maven dependencies
<dependency>
<groupId>com.aliyun.datahub</groupId>
<artifactId>aliyun-sdk-datahub</artifactId>
<version>2.25.3</version>
</dependency>
<dependency>
<groupId>com.aliyun.datahub</groupId>
<artifactId>datahub-client-library</artifactId>
<version>1.4.3</version>
</dependency>
Configure batch serialization
ProducerConfig config = new ProducerConfig(endpoint, accessId, accessKey);
DatahubProducer producer = new DatahubProducer(projectName, topicName, config);
RecordSchema schema = producer.getTopicSchema();
List<RecordEntry> recordList = new ArrayList<>();
// To achieve better performance, we recommend that you add as many records as possible to recordList.
// Set the size of recordList to be within the range of 512 KB to 1 MB if possible.
for (int i = 0; i < 1000; ++i) {
RecordEntry record = new RecordEntry();
TupleRecordData data = new TupleRecordData(schema);
// Assume that the following schema is used: {"fields":[{"name":"f1", "type":"STRING"},{"name":"f2", "type":"BIGINT"}]}
data.setField("f1", "value" + i);
data.setField("f2", i);
record.setRecordData(data);
// Optional. Add custom attributes.
record.addAttribute("key1", "value1");
recordList.add(record);
}
try {
// Write data repeatedly for 1,000 times.
for (int i = 0; i < 1000; ++i) {
try {
String shardId = datahubProducer.send(recordList);
LOGGER.info("Write shard {} success, record count:{}", shardId, recordList.size());
} catch (DatahubClientException e) {
if (!ExceptionChecker.isRetryableException(e)) {
LOGGER.info("Write data fail", e);
break;
}
// Execute the sleep statement to retry data writing.
Thread.sleep(1000);
}
}
} finally {
// Disable producer-related resources.
datahubProducer.close();
}
What to do next
If you have questions or encounter issues when using DataHub, submit a or join the DingTalk group 33517130.