-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
Fix iceberg table creation using glue metastore #20699
Fix iceberg table creation using glue metastore #20699
Conversation
3d2a0d5
to
666c739
Compare
Codenotify: Notifying subscribers in CODENOTIFY files for diff e4d8fc1...2c67fe8. No notifications. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! (docs) One small suggestion.
@@ -355,6 +355,12 @@ Create an Iceberg table with Iceberg format version 2:: | |||
format_version = '2' | |||
) | |||
|
|||
.. note:: | |||
|
|||
`GlueHiveMetastore` makes use of DynamoDb based locking mechanism. Please assign a policy similar to the below to the IAM user being used for creating table using glue catalog:: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
`GlueHiveMetastore` makes use of DynamoDb based locking mechanism. Please assign a policy similar to the below to the IAM user being used for creating table using glue catalog:: | |
`GlueHiveMetastore` makes use of DynamoDb based locking mechanism. Please assign a policy similar to the one shown below to the IAM user being used for creating tables using a Glue catalog:: |
c2b839d
to
e5bc97d
Compare
@yingsu00 This is good to review, only need to squash the commits. I will do that once I receive review comments. |
e5bc97d
to
92deb73
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pratyakshsharma Thank you for the contribution, I have commented my views on the changes, let me know your thoughts.
// properties.put("lock-impl", "org.apache.iceberg.aws.glue.DynamoLockManager"); | ||
properties.put("lock.table", tableName); | ||
properties.put("lock.acquire-timeout-ms", "300000"); | ||
LockManager lockManager = metastoreContext.getLockManager(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have some concerns with the current implementation, this lock method is a common implementation for any table format, and introducing an iceberg dependency doesn't look like an ideal solution. If we look at the implementation for Hive Metastore, it is generic. Can we brainstorm if it would be possible to do something similar in this case as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In addition to that, this also introduces iceberg dependency in the hive connector.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need to see if a similar LockManager class is available in aws-sdk for java.
presto-hive-metastore/pom.xml
Outdated
<dependency> | ||
<groupId>software.amazon.awssdk</groupId> | ||
<artifactId>dynamodb</artifactId> | ||
<version>2.17.131</version> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Presto currently makes use of AWS SDK 1.x. I think we should use the same version here as well otherwise it could result in conflicts and difficulty to maintain. We can migrate to AWS SDK 2.x collectively as a project once it is prioritized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the idea behind introducing 2.x dependencies was latest iceberg code [1.3.1] is making use of 2.x sdk. So adding 1.x version for this dependency might have resulted in issues. Moreover, Trino also currently has both the dependencies, they are adding the 2.x dependencies as bom. So I don't think it should create a major issue. What do you think?
If you still strongly feel we should proceed with 1.x only for now, I can rework these imports. Let me know either ways.
@@ -38,6 +40,9 @@ public class MetastoreContext | |||
// a new MetastoreContext from either an existing MetastoreContext or callers | |||
// that only have a handle to the provider (e.g. SemiTransactionalHiveMetastore) | |||
private final ColumnConverterProvider columnConverterProvider; | |||
private String metadataLocation; | |||
private String commitLockEntryId; | |||
private LockManager lockManager; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similar concern, we are introducing an iceberg dependency in a shared class.
Trino is currently using glue client from 1.x AWS SDK for java for iceberg connector. They are not implementing any locks for concurrent modifications in the case of glue metastore. Iceberg makes use of optimistic concurrency control for multiple writers, and currently trino only takes lock on thrift hive metastore to take care of such scenarios. References - |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pratyakshsharma I don't think this is the correct fix. The failure was because the "transaction" object created in IcebergXXXMetadata was wrong. It should be created as
transaction = createTableTransaction(tableName, operations, metadata);
but instead, it was not. Therefore the the TransactionType was not CREATE_TABLE, but just SIMPLE. Can you please verify how the transaction was created? Was it using IcebergNativeMetadata or IcebergHiveMetadata? Was beginCreateTable() executed? Was the transaction created via newCreateTableTransaction() or just icebergTable.newTransaction()?
@yingsu00 I checked and the transaction is of type CREATE_TABLE only and the flow executes via IcebergHiveMetadata. Also I did not understand the statement - "The failure was because the "transaction" object created in IcebergXXXMetadata was wrong." How is transaction object the cause of the failure? The failure is because of lock method not implemented in GlueHiveMetastore originally. |
92deb73
to
6b8429a
Compare
@@ -133,12 +132,12 @@ List<PartitionNameWithVersion> getPartitionNamesWithVersionByFilter( | |||
|
|||
default long lock(MetastoreContext metastoreContext, String databaseName, String tableName) | |||
{ | |||
throw new NotSupportedException("Lock is not supported by default"); | |||
return 1L; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can keep the default as it is in this interface and then handle lock & unlock in Glue implementation respectively instead.
And for https://github.com/prestodb/presto/blob/master/presto-hive-metastore/src/main/java/com/facebook/presto/hive/metastore/ExtendedHiveMetastore.java#L134
We can make this Optional and return empty for Glue.
Let me know what do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I agree. Let's keep the interface as-is since we don't want to allow pass-through by default in case of other metastores. We can override this in Glue Hive Metastore and allow pass-through.
Also, let's add some details about the verifications that you did to showcase we can pass through in the case of Glue Metastore
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@imjalpreet No details are needed as such I guess. The tests were all performed for concurrency issues. Iceberg table creation simply works when we bypass the check for glue case. Let me know if you think otherwise.
8e91f8f
to
2c67fe8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pratyakshsharma There are test failures and I think it's because of the test issue. Created #21346. Will you be able to fix it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pratyakshsharma Will you be able to add a test?
As discussed offline, @pratyakshsharma will add the test in our internal repo since it requires Glue account. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍🏼
@pratyakshsharma can you please add some screenshots if possible of your tests with Glue after this change for future reference?
Description
Fix iceberg table creation using glue metastore.
Motivation and Context
#18741
Impact
No impact.
Test Plan
Manual testing using self AWS account.
Contributor checklist
Release Notes
Please follow release notes guidelines and fill in the release notes below.