[
https://issues.apache.org/jira/browse/HUDI-1623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17758380#comment-17758380
]
Danny Chen commented on HUDI-1623:
----------------------------------
Some thoughts about TrueTime
we do not want a vender binded solution so a specific SDK like AWS clock-bound
may not be desired.
We also have no Spanner specific TrueTime API service, even for Cockroach DB,
they relies on clock synchronization of their cluster hosts to
maintain a maximum time offset of all the nodes. On Cloud, we have no that
synchronization either. I’m wondering whether the precondition header could be
a solution for lockless atomicity, but I didn’t find out any similiar API on
AWS like Google Cloud does.
So, let's get a summary about the *Time Generator* impl:
1. By default, we use an explicit lock like we mentioned in the description;
2. This lock is file based, there is no need for any munual configuratons from
the user side;
3. we may also add a TrueTime API based impl in the near future;
> Support start_commit_time & end_commit_times for serializable incremental pull
> ------------------------------------------------------------------------------
>
> Key: HUDI-1623
> URL: https://issues.apache.org/jira/browse/HUDI-1623
> Project: Apache Hudi
> Issue Type: Improvement
> Components: Common Core
> Reporter: Nishith Agarwal
> Assignee: Danny Chen
> Priority: Critical
> Fix For: 1.0.0
>
>
> We suggest a new file naming for the *completed* metadata file:
> ${start_time}.${action}.${completion_time}
>
> We also need a global *Time Generator* that can ensure the monotonical
> increasing generation of the timestamp, for example, maybe hold a mutex lock
> with the last generated timestamp backing up there. Say it may holds a lock
> {*}L1{*}. For each instant time generation, it needs guard from the lock.
>
> Before creating the completed file, we also need a lock guard from L1.
>
> Things need to note:
> 1. we only add completion timestamp to the completed metadata file;
> 2. we only add lock guard to the completed metadata file creation, not the
> whole commiting procedure;
> 3. for regular instant time generation, we also need a lock (that we should
> ship out by default)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
