profile timing data doens't match the real sql elapse time.

Waiting times are not always reflected as queries can possibly delayed because of resource contention on some of the nodes.
See: https://docs.vertica.com/23.3.x/en/mc/monitoring-using-mc/monitoring-system-resources/monitoring-user-query-phases/

waiting time is not included in the execution time, but it should be included in the clock time, right? If there are resource contention, then the additional time caused by contention should be reflected in clock time. And profile I did is on a dedicate 64 nodes cluster just started up for testing, no contention at all.

No. the clock, in execution_engine_profiles, starts ticking when the query is released to execution from the queue of the resource pool it is running under. The prepared query can easily estimate a memory amount that exceeds the resource pool's memory budget, because other queries are running that already have reserved memory for themselves, and the resource pool will queue the new query until enough other queries have finished, thus giving back the reserved memory, and the new query can then be released. Or the query has a maximal concurrency of 4 queries, and 4 queries are running, and the new query will only be released when one of the 4 will finish. The time between submitting the query and the query's release to execution might very well account for the difference between what vsql reports and execution_engine_profiles might report.

Thx, so if the sql is waiting for run (queue in resource pool), then the clock won't tick, but if the sql already begins to run, and need to get other resource, such as network, io or additional memory, the clock still will tick, right? My case is that sql is already running, from below snapshot, this step has "end time" - "start time" > 200 seconds, but both clock time and execution time are less than 10 seconds, so much difference.

It is by far more complicated than you think.
For starters, system view execution_engine_profile is outdated and refer to some counters that no longer exist. You can consider output from execution_engine_profile as mostly wrong (some data still OK).
Query plan combines several different operators into one line of plan.
Can be many instances of same operator.
And so on.

Generally speaking, it is very hard to look on query_plan_profile. I recommend to users to look on int only when query still running, and only when they quickly need to find place that consume most resources. Of course I am providing my own correct and more detailed version of query_plan_profiles, see below, it is valid for v 12.0.4.
All other uses of this view are not practical. You can look on it as learning exercise, no more.

    select 
    e.is_started,
    e.is_running,
    e.is_completed,
    e.running_time runtime,
    to_timestamp(e.sum_execution_time_us/1000000.0) - to_timestamp(0.0) cpu_time,
    e.max_memory_reserved memory_reserved,
    e.sum_bytes_read_from_disk bytes_read_from_disk,
    e.sum_bytes_received bytes_received,
    e.sum_bytes_sent bytes_sent,
    e.min_estimated_rows_produced estimated_rows_produced,
    e.sum_rows_produced rows_produced,
    e.sum_rows_processed rows_processed,
    e.operator_name operator,
    p.path_line,
    e.cnt counters,    
    p.transaction_id, p.statement_id, p.path_id, p.path_line_index, e.baseplan_id 
    from
    (select 
    transaction_id, statement_id, path_id, baseplan_id, 1 path_line_index,
    min(operator_name) operator_name, count(*) cnt,
    to_timestamp(min(case when counter_name = 'start time' then counter_value else null::int end)/1000000.0) min_start_time,
    to_timestamp(max(case when counter_name = 'end time' then counter_value else null::int end)/1000000.0) max_end_time,
    min_start_time is null is_started,
    min_start_time is not null and max_end_time is null is_running,
    min_start_time is not null and max_end_time is not null is_completed,
    case when min_start_time is null then null::interval else case when max_end_time is null then clock_timestamp() - min_start_time else max_end_time - min_start_time end end running_time,
    sum(case when counter_name = 'execution time (us)' then counter_value::float else null::float end) sum_execution_time_us,
    max(case when counter_name = 'memory reserved (bytes)' then counter_value else null end) max_memory_reserved,
    sum(case when counter_name = 'bytes read from disk' then counter_value else null end) sum_bytes_read_from_disk,
    sum(case when counter_name = 'bytes received' then counter_value else null end) sum_bytes_received,
    sum(case when counter_name = 'bytes sent' then counter_value else null end) sum_bytes_sent,
    min(case when counter_name = 'estimated rows produced' then counter_value else null end) min_estimated_rows_produced,
    sum(case when counter_name = 'rows produced' then counter_value else null end) sum_rows_produced,
    sum(case when counter_name = 'rows processed' then counter_value else null end) sum_rows_processed
    from 
    (select transaction_id, statement_id, path_id, baseplan_id, operator_name, counter_name, counter_value 
    from vs_execution_engine_profiles
    where transaction_id = 'transaction_id'
    and statement_id = 'statement_id'
    union all
    select transaction_id, statement_id, path_id, baseplan_id, operator_name, counter_name, counter_value 
    from dc_execution_engine_profiles
    where transaction_id = 'transaction_id'
    and statement_id = 'statement_id'
    ) v
    group by transaction_id, statement_id, path_id, baseplan_id) e
    right outer join
    (select * from dc_explain_plans
    where transaction_id = 'transaction_id'
    and statement_id = 'statement_id'
    ) p
    using(transaction_id, statement_id, path_id, path_line_index)
    order by p.transaction_id, p.statement_id, p.path_id, p.path_line_index, e.baseplan_id;

Query is using my c++ udx to_timestamp, it takes number of micros since epoch and return Vertica timestamp. You can find it on github - verticaudxutilities.

what's wonderful. several questions to the stats:
1: you put min_estimated_rows_produced in the view, then what if min_estimated_rows_produced is way larget than sum_rows_produced? in my example the former is 95,096 Million rows while the later is 4,943 Million rows, 20 times difference.
2: The following is from path_id 24,
a: there are 2 NetworkRecv and 2 NetworkSend, so does that means 4 threads?
b: the number of gb_received (recieived in Gigbtype) and gb_send are similar, but m_rows_produced (million rows) are several times diff, why could this happen?