Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use compatible column name to set Parquet bloom filter #11799

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

huaxingao
Copy link
Contributor

When writing a Parquet file, if a column name contains special characters, e.g. -, Iceberg converts it to a compatible format. However, the bloom filter is still set using the original column name, which results in an invalid bloom filter. This pull request resolves the issue by setting the bloom filter with the compatible column name instead of the original one.

@huaxingao
Copy link
Contributor Author

cc @szehon-ho

.columnBloomFilterEnabled()
.forEach(
(colPath, isEnabled) -> {
Types.NestedField fieldId = schema.caseInsensitiveFindField(colPath);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[doubt] does sensitivity matters ? can this :

write.parquet.bloom-filter-enabled.column.CoL1

be applied to parquet files with schema containing col1 ?

if not should we explicitly do lowercase post deriving the configs

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sensitivity matters. I changed to findField. Thanks!


String parquetColumnPath = fieldIdToParquetPath.get(fieldId.fieldId());
if (parquetColumnPath == null) {
LOG.warn("Skipping bloom filter config for missing field: {}", fieldId);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we update this message to say something like

Suggested change
LOG.warn("Skipping bloom filter config for missing field: {}", fieldId);
LOG.warn("Skipping bloom filter config for field: {} due to missing parquetColumnPath for fieldId: {}", colPath, fiedId);

mostly coming from the above log lines are identical mostly though at one part we add columnPath and the other we do fielId

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed. Thanks!

context
.columnBloomFilterEnabled()
.forEach(
(colPath, isEnabled) -> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[question] do we need to do anything for isEnabled as false ? or can parquet pro-actively decide if it should have a BF for a column and this isEnabled as false serves as explicit deny ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If isEnable is true, iceberg will call withBloomFilterEnabled(String columnPath, boolean enabled). If isEnable is false, we don't need to do anything.

.columnBloomFilterEnabled()
.forEach(
(colPath, isEnabled) -> {
Types.NestedField fieldId = schema.findField(colPath);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we call this as field instead ?

Suggested change
Types.NestedField fieldId = schema.findField(colPath);
Types.NestedField field = schema.findField(colPath);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated. Thanks!

Copy link
Contributor

@singhpk234 singhpk234 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, Thank you @huaxingao !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants