You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@hudi.apache.org by yi...@apache.org on 2022/09/13 07:21:30 UTC
[hudi] branch asf-site updated: [DOCS] Update concepts.md (#5219)
This is an automated email from the ASF dual-hosted git repository.
yihua pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/hudi.git
The following commit(s) were added to refs/heads/asf-site by this push:
new c8a9b6ffe3 [DOCS] Update concepts.md (#5219)
c8a9b6ffe3 is described below
commit c8a9b6ffe3c2d9d07c48192631f49d05a9c04100
Author: lipsa308 <10...@users.noreply.github.com>
AuthorDate: Tue Sep 13 12:51:22 2022 +0530
[DOCS] Update concepts.md (#5219)
Co-authored-by: Y Ethan Guo <et...@gmail.com>
---
website/docs/concepts.md | 2 +-
website/versioned_docs/version-0.10.0/concepts.md | 2 +-
website/versioned_docs/version-0.10.1/concepts.md | 2 +-
website/versioned_docs/version-0.11.0/concepts.md | 2 +-
website/versioned_docs/version-0.11.1/concepts.md | 2 +-
website/versioned_docs/version-0.12.0/concepts.md | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/website/docs/concepts.md b/website/docs/concepts.md
index 277484df63..8d0adf8dd5 100644
--- a/website/docs/concepts.md
+++ b/website/docs/concepts.md
@@ -154,7 +154,7 @@ Following illustrates how the table works, and shows two types of queries - snap
There are lot of interesting things happening in this example, which bring out the subtleties in the approach.
- We now have commits every 1 minute or so, something we could not do in the other table type.
- - Within each file id group, now there is an delta log file, which holds incoming updates to records in the base columnar files. In the example, the delta log files hold
+ - Within each file id group, now there is an delta log file, which holds incoming updates to the records already present in the base columnar files. In the example, the delta log files hold
all the data from 10:05 to 10:10. The base columnar files are still versioned with the commit, as before.
Thus, if one were to simply look at base files alone, then the table layout looks exactly like a copy on write table.
- A periodic compaction process reconciles these changes from the delta log and produces a new version of base file, just like what happened at 10:05 in the example.
diff --git a/website/versioned_docs/version-0.10.0/concepts.md b/website/versioned_docs/version-0.10.0/concepts.md
index 277484df63..8d0adf8dd5 100644
--- a/website/versioned_docs/version-0.10.0/concepts.md
+++ b/website/versioned_docs/version-0.10.0/concepts.md
@@ -154,7 +154,7 @@ Following illustrates how the table works, and shows two types of queries - snap
There are lot of interesting things happening in this example, which bring out the subtleties in the approach.
- We now have commits every 1 minute or so, something we could not do in the other table type.
- - Within each file id group, now there is an delta log file, which holds incoming updates to records in the base columnar files. In the example, the delta log files hold
+ - Within each file id group, now there is an delta log file, which holds incoming updates to the records already present in the base columnar files. In the example, the delta log files hold
all the data from 10:05 to 10:10. The base columnar files are still versioned with the commit, as before.
Thus, if one were to simply look at base files alone, then the table layout looks exactly like a copy on write table.
- A periodic compaction process reconciles these changes from the delta log and produces a new version of base file, just like what happened at 10:05 in the example.
diff --git a/website/versioned_docs/version-0.10.1/concepts.md b/website/versioned_docs/version-0.10.1/concepts.md
index 277484df63..8d0adf8dd5 100644
--- a/website/versioned_docs/version-0.10.1/concepts.md
+++ b/website/versioned_docs/version-0.10.1/concepts.md
@@ -154,7 +154,7 @@ Following illustrates how the table works, and shows two types of queries - snap
There are lot of interesting things happening in this example, which bring out the subtleties in the approach.
- We now have commits every 1 minute or so, something we could not do in the other table type.
- - Within each file id group, now there is an delta log file, which holds incoming updates to records in the base columnar files. In the example, the delta log files hold
+ - Within each file id group, now there is an delta log file, which holds incoming updates to the records already present in the base columnar files. In the example, the delta log files hold
all the data from 10:05 to 10:10. The base columnar files are still versioned with the commit, as before.
Thus, if one were to simply look at base files alone, then the table layout looks exactly like a copy on write table.
- A periodic compaction process reconciles these changes from the delta log and produces a new version of base file, just like what happened at 10:05 in the example.
diff --git a/website/versioned_docs/version-0.11.0/concepts.md b/website/versioned_docs/version-0.11.0/concepts.md
index 277484df63..8d0adf8dd5 100644
--- a/website/versioned_docs/version-0.11.0/concepts.md
+++ b/website/versioned_docs/version-0.11.0/concepts.md
@@ -154,7 +154,7 @@ Following illustrates how the table works, and shows two types of queries - snap
There are lot of interesting things happening in this example, which bring out the subtleties in the approach.
- We now have commits every 1 minute or so, something we could not do in the other table type.
- - Within each file id group, now there is an delta log file, which holds incoming updates to records in the base columnar files. In the example, the delta log files hold
+ - Within each file id group, now there is an delta log file, which holds incoming updates to the records already present in the base columnar files. In the example, the delta log files hold
all the data from 10:05 to 10:10. The base columnar files are still versioned with the commit, as before.
Thus, if one were to simply look at base files alone, then the table layout looks exactly like a copy on write table.
- A periodic compaction process reconciles these changes from the delta log and produces a new version of base file, just like what happened at 10:05 in the example.
diff --git a/website/versioned_docs/version-0.11.1/concepts.md b/website/versioned_docs/version-0.11.1/concepts.md
index 277484df63..8d0adf8dd5 100644
--- a/website/versioned_docs/version-0.11.1/concepts.md
+++ b/website/versioned_docs/version-0.11.1/concepts.md
@@ -154,7 +154,7 @@ Following illustrates how the table works, and shows two types of queries - snap
There are lot of interesting things happening in this example, which bring out the subtleties in the approach.
- We now have commits every 1 minute or so, something we could not do in the other table type.
- - Within each file id group, now there is an delta log file, which holds incoming updates to records in the base columnar files. In the example, the delta log files hold
+ - Within each file id group, now there is an delta log file, which holds incoming updates to the records already present in the base columnar files. In the example, the delta log files hold
all the data from 10:05 to 10:10. The base columnar files are still versioned with the commit, as before.
Thus, if one were to simply look at base files alone, then the table layout looks exactly like a copy on write table.
- A periodic compaction process reconciles these changes from the delta log and produces a new version of base file, just like what happened at 10:05 in the example.
diff --git a/website/versioned_docs/version-0.12.0/concepts.md b/website/versioned_docs/version-0.12.0/concepts.md
index 277484df63..8d0adf8dd5 100644
--- a/website/versioned_docs/version-0.12.0/concepts.md
+++ b/website/versioned_docs/version-0.12.0/concepts.md
@@ -154,7 +154,7 @@ Following illustrates how the table works, and shows two types of queries - snap
There are lot of interesting things happening in this example, which bring out the subtleties in the approach.
- We now have commits every 1 minute or so, something we could not do in the other table type.
- - Within each file id group, now there is an delta log file, which holds incoming updates to records in the base columnar files. In the example, the delta log files hold
+ - Within each file id group, now there is an delta log file, which holds incoming updates to the records already present in the base columnar files. In the example, the delta log files hold
all the data from 10:05 to 10:10. The base columnar files are still versioned with the commit, as before.
Thus, if one were to simply look at base files alone, then the table layout looks exactly like a copy on write table.
- A periodic compaction process reconciles these changes from the delta log and produces a new version of base file, just like what happened at 10:05 in the example.