[#2062][FOLLOWUP]Improvement(dashboard): Display detailed info for application in dashboard ui

[lwllvyb]

What changes were proposed in this pull request?

1. Display detailed info for application in dashboard ui
2. Persist the application info in coordinator.
3. Display application history information in dashboard ui.

Why are the changes needed?

(Please clarify why the changes are needed. For instance,

1. If you propose a new API, clarify the use case for a new API.
2. If you fix a bug, describe the bug.)

Fix: https://github.com/apache/incubator-uniffle/issues/2062

Does this PR introduce any user-facing change?

(Please list the user-facing changes introduced by your change, including

1. Change in user-facing APIs.
2. Addition or removal of property keys.)

Yes.

How was this patch tested?

(Please test your changes, and provide instructions on how to test it:

1. If you add a feature or fix a bug, add a test to cover your changes.
2. If you fix a flaky test, repeat it for many times to prove it works.)

[github-actions[bot]]

Test Results

 2 792 files  ±0   2 792 suites  ±0   5h 51m 46s :stopwatch: +20s    988 tests ±0     987 :white_check_mark: ±0   1 :zzz: ±0  0 :x: ±0  12 403 runs  ±0  12 388 :white_check_mark: ±0  15 :zzz: ±0  0 :x: ±0 

Results for commit 0f2a0716. ± Comparison against base commit ba2302c1.

[zuston]

This looks a huge change, could you help check this? @maobaolong If this has been applied in your internal cluster, please let me know, this will strength my approval confidence.

[maobaolong]

@zuston yeah, this has been applied to our internal codebase and deployed in our RSS cluster already.

[lwllvyb]

Ping @zuston @jerqi @maobaolong

[jerqi]

Could we use rocksDB to store the history data? If we load the history data, maybe we can't start coordinator quickly.

[lwllvyb]

Could we use rocksDB to store the history data? If we load the history data, maybe we can't start coordinator quickly.

I am not good at rocksDB. Is it possible to open a new PR to optimize this using rocksDB?

[jerqi]

Could we use rocksDB to store the history data? If we load the history data, maybe we can't start coordinator quickly.

I am not good at rocksDB. Is it possible to open a new PR to optimize this using rocksDB?

You should have a common abstraction both for file and Rocksdb first. What's more, you should reply my second question, f we load the history data, maybe we can't start coordinator quickly. How to handle this case.

[lwllvyb]

Could we use rocksDB to store the history data? If we load the history data, maybe we can't start coordinator quickly.

I am not good at rocksDB. Is it possible to open a new PR to optimize this using rocksDB?

You should have a common abstraction both for file and Rocksdb first. What's more, you should reply my second question, f we load the history data, maybe we can't start coordinator quickly. How to handle this case.

Next, I will split this PR into more independent PRs and deal with the abstraction suggestion. About you second question, coordinator only loads a portion of the latest history data, not the whole history data.

[jerqi]

Could we use rocksDB to store the history data? If we load the history data, maybe we can't start coordinator quickly.

I am not good at rocksDB. Is it possible to open a new PR to optimize this using rocksDB?

You should have a common abstraction both for file and Rocksdb first. What's more, you should reply my second question, f we load the history data, maybe we can't start coordinator quickly. How to handle this case.

Next, I will split this PR into more independent PRs and deal with the abstraction suggestion. About you second question, coordinator only loads a portion of the latest history data, not the whole history data.

I can't see the logic to read part of history data. And although we only read part of data, the start time will still be long.