You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Parquet file doesn't mark date and timestamp columns #7
Yes, these Parquet files are just converted from the source data.
It's ok to convert the types during load. Or should we add this information for convenience?
It would definitely be useful to include this information in the Parquet file so that I don't have to explicitly convert it on load, especially for a stateless table engine.
Same happen with Strings, which are just binaries that are not being marked as Strings.
Apache Pinot is quite strict about that and when importing data from parquet (which is quite faster than using tsv) the data is not imported as UTF-8 but as a byte array (because that is what parquet says)
The lack of timestamp annotation https://github.com/apache/parquet-format/blob/master/LogicalTypes.md#timestamp in particular on eventtime, clienteventtime and localeventtime columns is a blocker for running this benchmark in Trino, Apache Hive and Apache Spark. All three engines reject attempts to read integers without timestamp logical annotation into timestamp column type.
Without the annotation, the engine cannot know what units the given data has been provided in, so it cannot scale or round values to account for any mismatch in the timestamp precision in the table definition vs in the file.
Currently, Spark handles this via explicit casting (like df.withColumn("EventTime", F.col("EventTime").cast("timestamp"))). While this works for Spark, its accelerators (#517) struggle since they are mostly under active development and don't support all types of casts yet. So Spark backends (e.g., Comet) will benefit from this change too.
@alexey-milovidov why don't you consider fixing the benchmark data by regenerating the parquet files with the expected logical annotations ?
Its a straightforward one time effort which will avoid other engines from hitting this problem and having to apply various workarounds. This issue is open for more than 3 years now.
@raunaqmorarka ClickBench is a community project, please consider converting the Parquet files by yourself and provide them for download somewhere. We'd be happy to incorporate them into the benchmark.
@rschu1ze@alexey-milovidov do you want only the new Parquet file or related scripts as well? In other words, should one just attach a link or open a PR?
It would be nice if you could place the file somewhere and adjust a couple of benchmark scripts, e.g. ClickHouse, DuckDB, Spark so it's clear how the import statements can be simplified.
Let me make some clarifications about the nature of this benchmark.
The benchmark is intended to test how different database management systems are able to insert and store the data and run queries.
For the purpose of testing the data insertion, we provide data in three formats: TSV, CSV, Parquet. The data in these files should have the same order, and this order should be randomized - this is important for testing, as real-life data is also often arrives out of order.
The Parquet file does not have embedded indexes, but it is also expected, because it does not matter when the data is loaded into the database in its entirety.
Some of the participants in the benchmark are not really databases, but just query engines. The first entry that we added in this category was AWS Athena, and then we added ClickHouse in its serverless (clickhouse-local) mode, and then other systems. These systems can work directly on top of the source Parquet file, but it could be suboptimal when the file does not contain indexes and is not pre-sorted.
However, if we optimize these Parquet files beforehand, it will miss the point of comparing the loading time with other databases. If it works on top of the original TSV, CSV, or Parquet files, we can confidently say that the loading time is zero. If it requires better files, like presorted ones, it hides the time that a hypothetical production system will have to spend on the sorting of the incoming data.
TLDR, How to test a system on the ideal, optimized Parquet files? - Let's say it's DataFusion. In this case, you should take the original files in the format of your choice (Parquet, CSV, TSV), transform them to the ideal files (using DataFusion as well), count it as loading time, then run the queries on top of the transformed data.
Activity
alexey-milovidov commentedon Jul 20, 2022
Yes, these Parquet files are just converted from the source data.
It's ok to convert the types during load. Or should we add this information for convenience?
What will be the easiest way to do this?
dcory commentedon Jul 20, 2022
It would definitely be useful to include this information in the Parquet file so that I don't have to explicitly convert it on load, especially for a stateless table engine.
gortiz commentedon Jul 21, 2022
Same happen with Strings, which are just binaries that are not being marked as Strings.
Apache Pinot is quite strict about that and when importing data from parquet (which is quite faster than using tsv) the data is not imported as UTF-8 but as a byte array (because that is what parquet says)
For example:
raunaqmorarka commentedon Apr 25, 2025
The lack of timestamp annotation https://github.com/apache/parquet-format/blob/master/LogicalTypes.md#timestamp in particular on eventtime, clienteventtime and localeventtime columns is a blocker for running this benchmark in Trino, Apache Hive and Apache Spark. All three engines reject attempts to read integers without timestamp logical annotation into timestamp column type.
Without the annotation, the engine cannot know what units the given data has been provided in, so it cannot scale or round values to account for any mismatch in the timestamp precision in the table definition vs in the file.
Iskander14yo commentedon Jul 17, 2025
Currently, Spark handles this via explicit casting (like
df.withColumn("EventTime", F.col("EventTime").cast("timestamp"))). While this works for Spark, its accelerators (#517) struggle since they are mostly under active development and don't support all types of casts yet. So Spark backends (e.g., Comet) will benefit from this change too.alexey-milovidov commentedon Jul 18, 2025
@Iskander14yo, for now, you can use one of the following workarounds:
clickhouse localto convert from the source Parquet file to a file with Date and Timestamp columns.raunaqmorarka commentedon Aug 7, 2025
@alexey-milovidov why don't you consider fixing the benchmark data by regenerating the parquet files with the expected logical annotations ?
Its a straightforward one time effort which will avoid other engines from hitting this problem and having to apply various workarounds. This issue is open for more than 3 years now.
rschu1ze commentedon Aug 7, 2025
@raunaqmorarka ClickBench is a community project, please consider converting the Parquet files by yourself and provide them for download somewhere. We'd be happy to incorporate them into the benchmark.
Iskander14yo commentedon Nov 16, 2025
@rschu1ze @alexey-milovidov do you want only the new Parquet file or related scripts as well? In other words, should one just attach a link or open a PR?
rschu1ze commentedon Nov 16, 2025
It would be nice if you could place the file somewhere and adjust a couple of benchmark scripts, e.g. ClickHouse, DuckDB, Spark so it's clear how the import statements can be simplified.
rschu1ze commentedon Nov 16, 2025
While at it, we should also make sure that the updated Parquet file has an enabled Bloom filters (writing them is supported since ClickHouse 25.2)
alexey-milovidov commentedon Nov 16, 2025
Let me make some clarifications about the nature of this benchmark.
The benchmark is intended to test how different database management systems are able to insert and store the data and run queries.
For the purpose of testing the data insertion, we provide data in three formats: TSV, CSV, Parquet. The data in these files should have the same order, and this order should be randomized - this is important for testing, as real-life data is also often arrives out of order.
The Parquet file does not have embedded indexes, but it is also expected, because it does not matter when the data is loaded into the database in its entirety.
Some of the participants in the benchmark are not really databases, but just query engines. The first entry that we added in this category was AWS Athena, and then we added ClickHouse in its serverless (clickhouse-local) mode, and then other systems. These systems can work directly on top of the source Parquet file, but it could be suboptimal when the file does not contain indexes and is not pre-sorted.
However, if we optimize these Parquet files beforehand, it will miss the point of comparing the loading time with other databases. If it works on top of the original TSV, CSV, or Parquet files, we can confidently say that the loading time is zero. If it requires better files, like presorted ones, it hides the time that a hypothetical production system will have to spend on the sorting of the incoming data.
TLDR, How to test a system on the ideal, optimized Parquet files? - Let's say it's DataFusion. In this case, you should take the original files in the format of your choice (Parquet, CSV, TSV), transform them to the ideal files (using DataFusion as well), count it as loading time, then run the queries on top of the transformed data.