nsivabalan commented on a change in pull request #3257:
URL: https://github.com/apache/hudi/pull/3257#discussion_r670009217
##########
File path: docs/_docs/2_2_writing_data.md
##########
@@ -424,3 +424,192 @@ Here are some ways to efficiently manage the storage of
your Hudi tables.
- Intelligently tuning the [bulk insert
parallelism](/docs/configurations.html#withBulkInsertParallelism), can again in
nicely sized initial file groups. It is in fact critical to get this right,
since the file groups
once created cannot be deleted, but simply expanded as explained before.
- For workloads with heavy updates, the [merge-on-read
table](/docs/concepts.html#merge-on-read-table) provides a nice mechanism for
ingesting quickly into smaller files and then later merging them into larger
base files via compaction.
+
+
+## Schema Evolution
+
+Schema evolution is a very important aspect of data management.
+Hudi supports common schema evolution scenarios, such as adding a nullable
field or promoting a datatype of a field, out-of-the-box.
+Furthermore, the evolved schema is queryable across engines, such as Presto,
Hive and Spark SQL.
+The following table presents a summary of the types of schema changes
compatible with different Hudi table types.
+
+| Schema Change | COW | MOR | Remarks |
Review comment:
@danny0405 @yanghua @leesf : May be someone from flink can do a similar
exercise (try out all these) and certify. We can add "flink" to line 433. Or
add another column to call out the engines where certain schema evolution
works.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
