<@U0A71G31CDV> After executing ```REFRESH MATERIAL...
# questions-and-troubleshooting
g
@Rocky After executing
Copy code
REFRESH MATERIALIZED VIEW mv_fact_insights_market_product_daily_poc;
i got query id - 2fb1ac42-7c35-11f1-9595-8a5cd1361ab8 Where can i see its logs? i have shared data architecture, so created MV will have files in s3 bucket. how would i know the transfer from iceberg to s3 is completed?
r
You can track the status and logs for your manual refresh task using the following methods. 1. Check Refresh Status and Progress The most direct way to check the state of the refresh (including the transfer of data from Iceberg to your S3-backed StarRocks storage) is to query the
information_schema.task_runs
table using the
query_id
you received:
Copy code
sql
SELECT 
    TASK_NAME,
    CREATE_TIME,
    FINISH_TIME,
    STATE,
    PROGRESS,
    ERROR_MESSAGE
FROM information_schema.task_runs 
WHERE QUERY_ID = '2fb1ac42-7c35-11f1-9595-8a5cd1361ab8';
* STATE: Will show
RUNNING
,
SUCCESS
, or
FAILED
. * PROGRESS: Shows the percentage of completion. * Completion: When the
STATE
becomes
SUCCESS
, the data has been fully processed and written to your S3 bucket. 2. View Execution "Logs" (Profiles) If you want to see the detailed execution plan and performance of the data transfer (how many rows were read from Iceberg and written to S3), you can view the Query Profile:
Copy code
sql
-- This will only work if the profile has been captured (profile_level >= 1)
SHOW PROFILE FOR '2fb1ac42-7c35-11f1-9595-8a5cd1361ab8';
3. System-level Logs If the task fails and the
ERROR_MESSAGE
in
task_runs
isn't detailed enough, you can check the physical logs on your StarRocks nodes: * FE Logs (
fe.log
)
: Look for your
query_id
here to see metadata operations and task scheduling info. * BE Logs (
<http://be.INFO|be.INFO>
)
: Look here for the actual execution details on the backend nodes, especially if there were issues connecting to Iceberg or S3. 4. Verify Data in S3 Since you are using a shared-data architecture, StarRocks manages the files in S3 automatically. You don't need to manually check S3 files to confirm completion; the
SUCCESS
state in
task_runs
is the authoritative confirmation. However, you can also run:
Copy code
sql
SHOW MATERIALIZED VIEWS WHERE NAME = 'mv_fact_insights_market_product_daily_poc';
Look at the
last_refresh_time
and
is_active
columns to ensure the MV is up-to-date and healthy. References • using_starrocks/async_mv/materialized_view_task_run_details.md
g
@Rocky 1) mv-29457 2026-07-10 155850 2026-07-10 160000 FAILED 0% "Refresh mv mv_fact_insights_market_product_daily_poc failed after 1 times, try lock failed: 0, error-msg : com.starrocks.common.DdlException: [E1014]Got EOF of Socket{id=279 fd=247 addr=10.97.47.228806047932} (0x0xfffe212f0000) [R1][E112]Not connected to 10.97.47.228:8060 yet, server_id=279 [R2][E112]Not connected to 10.97.47.228:8060 yet, server_id=279 [R3][E112]Not connected to 10.97.47.228:8060 yet, server_id=279: BE:10079 at com.starrocks.common.ErrorReport.reportDdlException(ErrorReport.java:100) at com.starrocks.qe.StmtExecutor.handleDMLStmt(StmtExecutor.java:2776) [wrapped] com.starrocks.common.StarRocksException: [E1014]Got EOF of Socket{id=279 fd=247 addr=10.97.47.228806047932} (0x0xfffe212f0000) [R1][E112]Not connected to 10.97.47.228:8060 yet, server_id=279 [R2][E112]Not connected to 10.97.47.228:8060 yet, server_id=279 [R3][E112]Not connected to 10.97.47.228:8060 yet, server_id=279: BE:10079 at com.starrocks.qe.StmtExecutor.handleDMLStmt(StmtExecutor.java:3009) at com.starrocks.load.InsertOverwriteJobRunner.executeInsert(InsertOverwriteJobRunner.java:409) at com.starrocks.load.InsertOverwriteJobRunner.doLoad(InsertOverwriteJobRunner.java:178) at com.starrocks.load.InsertOverwriteJobRunner.handle(InsertOverwriteJobRunner.java:158) at com.starrocks.load.InsertOverwriteJobRunner.transferTo(InsertOverwriteJobRunner.java:224) at com.starrocks.load.InsertOverwriteJobRunner.prepare(InsertOverwriteJobRunner.java:277) at com.starrocks.load.InsertOverwriteJobRunner.handle(InsertOverwriteJobRunner.java:155) at com.starrocks.load.InsertOverwriteJobRunner.run(InsertOverwriteJobRunner.java:143) at com.starrocks.load.InsertOverwriteJobMgr.executeJob(InsertOverwriteJobMgr.java:90) at com.starrocks.qe.StmtExecutor.handleInsertOverwrite(StmtExecutor.java:2528) at com.starrocks.qe.StmtExecutor.handleDMLStmt(StmtExecutor.java:2621) at com.starrocks.qe.StmtExecutor.handleDMLStmtWithProfile(StmtExecutor.java:2537) at com.starrocks.scheduler.PartitionBasedMvRefreshProcessor.refreshMaterializedView(PartitionBasedMvRefreshProcessor.java:1255) at com.starrocks.scheduler.PartitionBasedMvRefreshProcessor.doRefreshMaterializedView(PartitionBasedMvRefreshProcessor.java:502) at com.starrocks.scheduler.PartitionBasedMvRefreshProcessor.doRefreshMaterializedViewWithRetry(PartitionBasedMvRefreshProcessor.java:408) at com.starrocks.scheduler.PartitionBasedMvRefreshProcessor.doMvRefresh(PartitionBasedMvRefreshProcessor.java:342) at com.starrocks.scheduler.PartitionBasedMvRefreshProcessor.processTaskRun(PartitionBasedMvRefreshProcessor.java:195) at com.starrocks.scheduler.TaskRun.executeTaskRun(TaskRun.java:382) at com.starrocks.scheduler.TaskRunExecutor.lambda$executeTaskRun$0(TaskRunExecutor.java:60) at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1768) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base/java.lang.Thread.run(Thread.java:840)" 2) Query 1 ERROR at Line 38: : Getting syntax error at line 1, column 5. Detail message: No viable statement for input 'SHOW PROFILE'. 3) 29457 adhoc mv_fact_insights_market_product_daily_poc MANUAL true UNPARTITIONED 29467 mv-29457 2026-07-10 155850 2026-07-10 160000 70.184 FAILED false NULL NULL {} [mv_fact_insights_market_product_daily_poc] -1 "Refresh mv mv_fact_insights_market_product_daily_poc failed after 1 times, try lock failed: 0, error-msg : com.starrocks.common.DdlException: [E1014]Got EOF of Socket{id=279 fd=247 addr=10.97.47.228806047932} (0x0xfffe212f0000) [R1][E112]Not connected to 10.97.47.228:8060 yet, server_id=279 [R2][E112]Not connected to 10.97.47.228:8060 yet, server_id=279 [R3][E112]Not connected to 10.97.47.228:8060 yet, server_id=279: BE:10079 at com.starrocks.common.ErrorReport.reportDdlException(ErrorReport.java:100) at com.starrocks.qe.StmtExecutor.handleDMLStmt(StmtExecutor.java:2776) [wrapped] com.starrocks.common.StarRocksException: [E1014]Got EOF of Socket{id=279 fd=247 addr=10.97.47.228806047932} (0x0xfffe212f0000) [R1][E112]Not connected to 10.97.47.228:8060 yet, server_id=279 [R2][E112]Not connected to 10.97.47.228:8060 yet, server_id=279 [R3][E112]Not connected to 10.97.47.228:8060 yet, server_id=279: BE:10079 at com.starrocks.qe.StmtExecutor.handleDMLStmt(StmtExecutor.java:3009) at com.starrocks.load.InsertOverwriteJobRunner.executeInsert(InsertOverwriteJobRunner.java:409) at com.starrocks.load.InsertOverwriteJobRunner.doLoad(InsertOverwriteJobRunner.java:178) at com.starrocks.load.InsertOverwriteJobRunner.handle(InsertOverwriteJobRunner.java:158) at com.starrocks.load.InsertOverwriteJobRunner.transferTo(InsertOverwriteJobRunner.java:224) at com.starrocks.load.InsertOverwriteJobRunner.prepare(InsertOverwriteJobRunner.java:277) at com.starrocks.load.InsertOverwriteJobRunner.handle(InsertOverwriteJobRunner.java:155) at com.starrocks.load.InsertOverwriteJobRunner.run(InsertOverwriteJobRunner.java:143) at com.starrocks.load.InsertOverwriteJobMgr.executeJob(InsertOverwriteJobMgr.java:90) at com.starrocks.qe.StmtExecutor.handleInsertOverwrite(StmtExecutor.java:2528) at com.starrocks.qe.StmtExecutor.handleDMLStmt(StmtExecutor.java:2621) at com.starrocks.qe.StmtExecutor.handleDMLStmtWithProfile(StmtExecutor.java:2537) at com.starrocks.scheduler.PartitionBasedMvRefreshProcessor.refreshMaterializedView(PartitionBasedMvRefreshProcessor.java:1255) at com.starrocks.scheduler.PartitionBasedMvRefreshProcessor.doRefreshMaterializedView(PartitionBasedMvRefreshProcessor.java:502) at com.starrocks.scheduler.PartitionBasedMvRefreshProcessor.doRefreshMaterializedViewWithRetry(PartitionBasedMvRefreshProcessor.java:408) at com.starrocks.scheduler.PartitionBasedMvRefreshProcessor.doMvRefresh(PartitionBasedMvRefreshProcessor.java:342) at com.starrocks.scheduler.PartitionBasedMvRefreshProcessor.processTaskRun(PartitionBasedMvRefreshProcessor.java:195) at com.starrocks.scheduler.TaskRun.executeTaskRun(TaskRun.java:382) at com.starrocks.scheduler.TaskRunExecutor.lambda$executeTaskRun$0(TaskRunExecutor.java:60) at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1768) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base/java.lang.Thread.run(Thread.java:840)" 0 "CREATE MATERIALIZED VIEW
mv_fact_insights_market_product_daily_poc
(
date
,
market_product_id
,
master_product_id
,
marketplace_id
,
customer_id
,
vendor_id
,
customer_type
,
customer_state_id
,
estimated_total_page_views
,
estimated_total_page_views_non_china
,
estimated_total_sold_units
,
estimated_page_views_lost_to_suppression
,
estimated_lost_suppression_sales
,
estimated_lost_suppression_sales_aed
,
estimated_lost_suppression_sales_ars
,
estimated_lost_suppression_sales_aud
,
estimated_lost_suppression_sales_cad
,
estimated_lost_suppression_sales_cny
,
estimated_lost_suppression_sales_eur
,
estimated_lost_suppression_sales_gbp
,
estimated_lost_suppression_sales_jpy
,
estimated_lost_suppression_sales_usd
,
avg_rating
,
reviews_count
,
estimated_lost_suppression_sales_krw
,
estimated_lost_suppression_sales_pln
,
estimated_lost_suppression_sales_sek
,
estimated_total_sales
,
estimated_total_sales_aed
,
estimated_total_sales_ars
,
estimated_total_sales_aud
,
estimated_total_sales_cad
,
estimated_total_sales_cny
,
estimated_total_sales_eur
,
estimated_total_sales_gbp
,
estimated_total_sales_jpy
,
estimated_total_sales_usd
,
estimated_total_sales_krw
,
estimated_total_sales_pln
,
estimated_total_sales_sek
) COMMENT ""MATERIALIZED_VIEW"" DISTRIBUTED BY HASH(
customer_id
) REFRESH MANUAL PROPERTIES ( ""replicated_storage"" = ""true"", ""replication_num"" = ""1"", ""datacache.enable"" = ""true"", ""enable_async_write_back"" = ""false"", ""storage_volume"" = ""builtin_storage_volume"", ""warehouse"" = ""default_warehouse"" ) AS SELECT
fact_insights_market_product_daily_poc
.
date
,
fact_insights_market_product_daily_poc
.
market_product_id
,
fact_insights_market_product_daily_poc
.
master_product_id
,
fact_insights_market_product_daily_poc
.
marketplace_id
,
fact_insights_market_product_daily_poc
.
customer_id
,
fact_insights_market_product_daily_poc
.
vendor_id
,
fact_insights_market_product_daily_poc
.
customer_type
,
fact_insights_market_product_daily_poc
.
customer_state_id
,
fact_insights_market_product_daily_poc
.
estimated_total_page_views
,
fact_insights_market_product_daily_poc
.
estimated_total_page_views_non_china
,
fact_insights_market_product_daily_poc
.
estimated_total_sold_units
,
fact_insights_market_product_daily_poc
.
estimated_page_views_lost_to_suppression
,
fact_insights_market_product_daily_poc
.
estimated_lost_suppression_sales
,
fact_insights_market_product_daily_poc
.
estimated_lost_suppression_sales_aed
,
fact_insights_market_product_daily_poc
.
estimated_lost_suppression_sales_ars
,
fact_insights_market_product_daily_poc
.
estimated_lost_suppression_sales_aud
,
fact_insights_market_product_daily_poc
.
estimated_lost_suppression_sales_cad
,
fact_insights_market_product_daily_poc
.
estimated_lost_suppression_sales_cny
,
fact_insights_market_product_daily_poc
.
estimated_lost_suppression_sales_eur
,
fact_insights_market_product_daily_poc
.
estimated_lost_suppression_sales_gbp
,
fact_insights_market_product_daily_poc
.
estimated_lost_suppression_sales_jpy
,
fact_insights_market_product_daily_poc
.
estimated_lost_suppression_sales_usd
,
fact_insights_market_product_daily_poc
.
avg_rating
,
fact_insights_market_product_daily_poc
.
reviews_count
,
fact_insights_market_product_daily_poc
.
estimated_lost_suppression_sales_krw
,
fact_insights_market_product_daily_poc
.
estimated_lost_suppression_sales_pln
,
fact_insights_market_product_daily_poc
.
estimated_lost_suppression_sales_sek
,
fact_insights_market_product_daily_poc
.
estimated_total_sales
,
fact_insights_market_product_daily_poc
.
estimated_total_sales_aed
,
fact_insights_market_product_daily_poc
.
estimated_total_sales_ars
,
fact_insights_market_product_daily_poc
.
estimated_total_sales_aud
,
fact_insights_market_product_daily_poc
.
estimated_total_sales_cad
,
fact_insights_market_product_daily_poc
.
estimated_total_sales_cny
,
fact_insights_market_product_daily_poc
.
estimated_total_sales_eur
,
fact_insights_market_product_daily_poc
.
estimated_total_sales_gbp
,
fact_insights_market_product_daily_poc
.
estimated_total_sales_jpy
,
fact_insights_market_product_daily_poc
.
estimated_total_sales_usd
,
fact_insights_market_product_daily_poc
.
estimated_total_sales_krw
,
fact_insights_market_product_daily_poc
.
estimated_total_sales_pln
,
fact_insights_market_product_daily_poc
.
estimated_total_sales_sek
FROM
iceberg_adhoc
.
adhoc
.`fact_insights_market_product_daily_poc`;" "{""queryIds"":[""2fb1ac42-7c35-11f1-9595-8a5cd1361ab8""],""isManual"":true,""isSync"":false,""isReplay"":false,""priority"":80,""lastTaskRunState"":""FAILED""}" VALID "'root'@'%'"
r
The error message and the syntax issue you encountered indicate two separate problems: a Backend (BE) node failure and a syntax mismatch for viewing profiles. 1. Analysis of the Refresh Failure The error
[E1014]Got EOF of Socket... [E112]Not connected to 10.97.47.228:8060 yet
is a classic indicator that the Backend (BE) node crashed or the process was terminated during the refresh. * What happened: Your StarRocks FE was talking to the BE at
10.97.47.228
on its BRPC port (
8060
). While the BE was processing the data transfer from Iceberg to S3, the connection was abruptly closed (
EOF
). * Most common cause: An OOM (Out Of Memory) event. Because your MV is
UNPARTITIONED
, StarRocks attempts to refresh the entire dataset in one job. If the Iceberg table is very large, the memory required to process the data might have exceeded the BE's limits, causing the Linux OOM killer to stop the process. * How to verify: 1. Run
SHOW BACKENDS;
and check if the node
10.97.47.228
is still
Alive
. 2. Log into that specific BE server and check the system logs for OOM:
dmesg -T | grep -i oom
. 3. Check the BE's own logs (usually at
storage/log/be.INFO
or
be.out
) for the specific time
16:00:00
. 2. Correct Syntax for Profiles The error
No viable statement for input 'SHOW PROFILE'
occurs because the syntax changed in recent versions (v3.1+). To view the execution details for your failed query ID: * To see the list of available profiles:
Copy code
sql
    SHOW PROFILELIST;
* To see the detailed execution graph for your ID:
Copy code
sql
    ANALYZE PROFILE FROM '2fb1ac42-7c35-11f1-9595-8a5cd1361ab8';
(Note: If the BE crashed, the profile might be incomplete or missing because the node couldn't send the metrics back to the FE before dying.) 3. How to know if the transfer to S3 is complete? In a shared-data architecture, the "transfer" is the refresh task itself. * Status Check: Query
information_schema.task_runs
. If the
STATE
is
SUCCESS
, all data has been successfully written to S3 and the MV metadata has been updated. * Current State: Your task shows
FAILED
at
0%
progress, meaning no data was successfully transferred/committed to the MV in S3. The transaction was rolled back automatically. Recommendations 1. Partition the MV: If the source Iceberg table is large, do not use
UNPARTITIONED
. Partition the MV by a date column (e.g.,
PARTITION BY date
) so that StarRocks can refresh data in smaller increments. 2. Increase Memory: If you cannot partition, you may need to increase the
mem_limit
for the query or the
be_process_mem_limit
in
be.conf
. 3. Manual Refresh by Partition: Use
REFRESH MATERIALIZED VIEW ... PARTITION START ("...") END ("...")
to process the data in chunks rather than all at once. References • administration/Management_ports.md • sql-reference/sql-statements/cluster-management/plan_profile/ANALYZE_PROFILE.md • using_starrocks/async_mv/materialized_view_task_run_details.md References • sql-reference/sql-statements/cluster-management/plan_profile/SHOW_PROFILELIST.md • best_practices/query_tuning/query_profile_text_based_analysis.md • sql-reference/sql-statements/cluster-management/plan_profile/ANALYZE_PROFILE.md
g
@Rocky DDL - CREATE MATERIALIZED VIEW mv_fact_insights_market_product_daily_poc DISTRIBUTED BY HASH(customer_id) REFRESH MANUAL AS SELECT * FROM iceberg_adhoc.adhoc.fact_insights_market_product_daily_poc; here iceberg_adhoc.adhoc.fact_insights_market_product_daily_poc is very big table of 500M + records and since its at lowest granularity, i want ASYNC MV same as the table thats why i'm doing SELECT * FROM
r
Refreshing a 500M row table into an unpartitioned Materialized View (MV) is the primary cause of the failure you encountered. When you run
SELECT *
on such a large dataset without partitioning, StarRocks attempts to process the entire 500M rows in a single massive transaction, which typically leads to the Backend (BE) crashing due to OOM (Out Of Memory). To handle a table of this size at the lowest granularity, you should follow these best practices: 1. Re-create the MV with Partitioning Partitioning is the most important step. If your Iceberg table is partitioned (e.g., by a
date
column), you must align your MV with those same partitions. This allows StarRocks to refresh the data in smaller, manageable increments instead of all at once. Recommended DDL Structure:
Copy code
sql
CREATE MATERIALIZED VIEW mv_fact_insights_market_product_daily_poc
PARTITION BY `date`  -- Use the same partition column as your Iceberg table
DISTRIBUTED BY HASH(customer_id)
REFRESH MANUAL
PROPERTIES (
    "session.enable_spill" = "true",      -- Enables spilling to disk if memory is low
    "session.insert_timeout" = "28800",   -- Increases timeout to 8 hours for large initial load
    "replication_num" = "1"
)
AS 
SELECT * FROM iceberg_adhoc.adhoc.fact_insights_market_product_daily_poc;
2. Perform the Initial Load in Chunks Don't run a full
REFRESH
on the entire 500M rows immediately after creation. Instead, load the history partition-by-partition (or in date ranges) to keep memory usage stable:
Copy code
sql
-- Refresh only a specific range of dates
REFRESH MATERIALIZED VIEW mv_fact_insights_market_product_daily_poc 
PARTITION START ("2024-01-01") END ("2024-01-31");
Once the historical data is loaded, subsequent refreshes will be much faster as StarRocks will only need to refresh the partitions that have changed in Iceberg. 3. Enable "Spill to Disk" As shown in the DDL above, setting
"session.enable_spill" = "true"
is a critical safety net. If a refresh task starts running out of RAM, it will spill intermediate data to the BE's local disk instead of crashing the node with an OOM error. 4. Check Resource Group Limits StarRocks uses a default resource group for MVs (
default_mv_wg
). If your cluster is under heavy load, this group might have a low memory limit that causes the refresh to be killed. You can check your resource groups with:
Copy code
sql
SHOW RESOURCE GROUPS;
If needed, you can assign a dedicated resource group with higher limits to this specific MV using:
Copy code
sql
ALTER MATERIALIZED VIEW mv_fact_insights_market_product_daily_poc SET ("resource_group" = "your_large_job_rg");
Summary of the Error The
Got EOF of Socket
error occurred because the BE node
10.97.47.228
literally disappeared mid-query (crashed). By partitioning the MV and enabling disk spilling, you prevent the BE from being overwhelmed by the 500M row "Select All" operation. References • using_starrocks/async_mv/use_cases/create_partitioned_materialized_view.md • using_starrocks/async_mv/troubleshooting_asynchronous_materialized_views.md • using_starrocks/async_mv/use_cases/data_lake_query_acceleration_with_materialized_views.md • best_practices/audit_log_resource_group.md " operation. References • knowledge/usage/best-practice.md • best_practices/audit_log_resource_group.md
g
@Rocky its my iceeberg table reading from catalog. table DDL - CREATE TABLE IF NOT EXISTS {{ namespace }}.{{ table_name }} ( date STRING, market_product_id BIGINT, master_product_id BIGINT, marketplace_id INTEGER, customer_id BIGINT, vendor_id BIGINT, customer_type INTEGER, customer_state_id INTEGER, estimated_total_page_views DECIMAL(38,9), estimated_total_page_views_non_china DECIMAL(38,9), estimated_total_sold_units DECIMAL(38,9), estimated_page_views_lost_to_suppression DECIMAL(18,9), estimated_lost_suppression_sales DECIMAL(18,9), estimated_lost_suppression_sales_aed DOUBLE, estimated_lost_suppression_sales_ars DOUBLE, estimated_lost_suppression_sales_aud DOUBLE, estimated_lost_suppression_sales_cad DOUBLE, estimated_lost_suppression_sales_cny DOUBLE, estimated_lost_suppression_sales_eur DOUBLE, estimated_lost_suppression_sales_gbp DOUBLE, estimated_lost_suppression_sales_jpy DOUBLE, estimated_lost_suppression_sales_usd DOUBLE, avg_rating DECIMAL(3,2), reviews_count BIGINT, estimated_lost_suppression_sales_krw DOUBLE, estimated_lost_suppression_sales_pln DOUBLE, estimated_lost_suppression_sales_sek DOUBLE, estimated_total_sales DECIMAL(38,9), estimated_total_sales_aed DOUBLE, estimated_total_sales_ars DOUBLE, estimated_total_sales_aud DOUBLE, estimated_total_sales_cad DOUBLE, estimated_total_sales_cny DOUBLE, estimated_total_sales_eur DOUBLE, estimated_total_sales_gbp DOUBLE, estimated_total_sales_jpy DOUBLE, estimated_total_sales_usd DOUBLE, estimated_total_sales_krw DOUBLE, estimated_total_sales_pln DOUBLE, estimated_total_sales_sek DOUBLE ) USING ICEBERG PARTITIONED BY (customer_id) TBLPROPERTIES ( 'write.format.default' = 'parquet', 'write.parquet.compression-codec' = 'zstd', 'write.target-file-size-bytes' = '268435456', 'write.parquet.row-group-size-bytes' = '134217728', 'write.distribution-mode' = 'range', 'write.metadata.metrics.default' = 'truncate(16)', 'write.metadata.metrics.column.customer_id' = 'full', 'write.metadata.metrics.column.marketplace_id' = 'full', 'write.metadata.metrics.column.market_product_id' = 'full', 'write.metadata.metrics.column.date' = 'full', 'write.metadata.metrics.column.customer_type' = 'full', 'write.metadata.metrics.column.customer_state_id' = 'full', 'write.parquet.bloom-filter-enabled.column.marketplace_id' = 'true', 'write.parquet.bloom-filter-enabled.column.market_product_id' = 'true', 'commit.manifest-merge.enabled' = 'true', 'write.metadata.delete-after-commit.enabled' = 'true' ); its 500M+ records, not sure size but how can we have MV same as iceberg table? so that i will get stored into starRocks native table format in s3 instread of iceberg and query latency will decrease
r
To successfully mirror a 500M+ record Iceberg table into StarRocks native storage and avoid the "BE Crash/EOF" error you encountered, you must use Partitioning in your Materialized View (MV). Without partitioning, StarRocks treats the 500M rows as one single "chunk." With partitioning, StarRocks can process the data in smaller increments (e.g., 100,000 rows at a time per partition), which stays within memory limits. 1. Updated DDL for the Materialized View Since your Iceberg table is partitioned by
customer_id
, your StarRocks MV should also be partitioned by
customer_id
to enable incremental refreshes.
Copy code
sql
CREATE MATERIALIZED VIEW mv_fact_insights_market_product_daily_poc
-- 1. Partition by the same column as Iceberg to enable incremental sync
PARTITION BY (customer_id)
-- 2. Distribute by the same key for optimized joins/aggregation
DISTRIBUTED BY HASH(customer_id)
REFRESH MANUAL
PROPERTIES (
    -- 3. Safety: only refresh 5-10 partitions at a time to prevent OOM
    "partition_refresh_number" = "10",
    -- 4. Set a high timeout for the initial massive load (8 hours)
    "session.insert_timeout" = "28800",
    -- 5. Enable spill to disk to handle memory pressure
    "session.enable_spill" = "true",
    "replication_num" = "1"
)
AS 
SELECT 
    `date`, `market_product_id`, `master_product_id`, `marketplace_id`, 
    `customer_id`, `vendor_id`, `customer_type`, `customer_state_id`,
    -- ... (other columns)
FROM iceberg_adhoc.adhoc.fact_insights_market_product_daily_poc;
2. Why this solves your problem * Storage Change: Once the MV is created, the data is moved from Iceberg (Parquet on S3) into StarRocks Native Format (also on S3, but with StarRocks' custom indexing and metadata). This significantly reduces latency because StarRocks can use its Data Cache, Columnar Indexes, and CBO (Cost-Based Optimizer) more effectively. * Memory Management: The
partition_refresh_number
=
10
property is the most important. If you have 1,000 customers (partitions), StarRocks will run 100 small jobs instead of 1 giant job that crashes the BE. * Incremental Sync: When your Iceberg table gets new data for specific `customer_id`s, StarRocks will detect which partitions changed and only refresh those specific partitions, rather than the whole 500M rows. 3. How to perform the initial "Massive" Load Even with the correct DDL, the first refresh of 500M rows is a heavy operation. Do not use a simple
REFRESH...
. Instead: Option A: Automatic Chunked Refresh Simply run:
Copy code
sql
REFRESH MATERIALIZED VIEW mv_fact_insights_market_product_daily_poc;
Because of
"partition_refresh_number" = "10"
, StarRocks will automatically queue up the partitions and process them in batches of 10. Option B: Manual Range Refresh (Safest) If you are worried about the cluster load, refresh by specific values:
Copy code
sql
REFRESH MATERIALIZED VIEW mv_fact_insights_market_product_daily_poc 
PARTITIONS (customer_id_val1, customer_id_val2, ...);
4. How to know it's working Since you are in shared-data architecture: 1. Check Task Progress:
Copy code
sql
    SELECT * FROM information_schema.task_runs
    WHERE task_name = 'mv-29457' -- Use your task ID
    ORDER BY create_time DESC;
You will see the
PROGRESS
increase (e.g., 5%, 10%) as batches of partitions complete. 2. Verify S3 Storage: The data is now in your StarRocks S3 bucket. You can verify the row count in StarRocks:
Copy code
sql
    SELECT count(*) FROM mv_fact_insights_market_product_daily_poc;
⚠️ Warning: High Cardinality If
customer_id
has millions of unique values, partitioning by it will create millions of small files in S3, which will hurt performance. * If
customer_id
cardinality is low/medium (< 10,000):
Use the DDL above. * If
customer_id
cardinality is very high:
Consider partitioning the MV by the
date
column instead, even if the Iceberg table is not. You can then refresh the MV by date ranges.
g
@Rocky Also this iceberg table will get full refresh every hour, so all 500M+ records get full refreshed every hour. as of now there is no incremental or CDC. what can we do here?
r
Handling a 500M+ row full refresh every hour is a significant workload. In StarRocks, an Asynchronous Materialized View (MV) on a data lake table essentially performs an
INSERT OVERWRITE
under the hood. When your source Iceberg table undergoes a full refresh (e.g., via a new snapshot that replaces all data), StarRocks perceives every partition as "changed" and attempts to refresh the entire dataset. To prevent the Backend (BE) from crashing (OOM) and to make this hourly process stable, you should apply the following strategies: 1. Batch the Refresh (Avoid the "Big Bang") The reason your BE crashed is likely that StarRocks tried to load all 500M rows in a single massive task. You must force StarRocks to break the 500M rows into smaller batches. * Property:
"partition_refresh_number" = "N"
* How it works: Even if all 500M rows (across all partitions) need refreshing, StarRocks will only refresh
N
partitions at a time in separate transactions. * Recommendation: Set this to a small number like
5
or
10
. This ensures that if a single batch fails, the system doesn't lose hours of work, and memory pressure remains low. 2. Enable Memory Spilling Since you are dealing with a huge "Select *", memory spikes are inevitable. * Property:
"session.enable_spill" = "true"
* Effect: If the BE runs low on RAM during the refresh, it will spill intermediate data to disk instead of crashing. 3. Critical: Check Partition Cardinality Your Iceberg table is
PARTITIONED BY (customer_id)
. * Warning: If
customer_id
has tens of thousands or millions of unique values, partitioning by it in StarRocks is a mistake. StarRocks (and S3) perform poorly with millions of tiny partitions. * Solution: * If
customer_id
has < 10,000 unique values: Keep the partition. * If
customer_id
is high-cardinality: Do not partition the MV by
customer_id
. Instead, partition the MV by the
date
column (even if the Iceberg source isn't). _ _Note:* If you partition the MV by a column that is not a partition key in Iceberg, StarRocks cannot perform "incremental detection." However, since your source is a "full refresh" anyway, you aren't losing anything. You are simply using the MV's partitioning to help StarRocks manage the 500M rows in chunks. 4. Optimized DDL for Hourly Full Refresh
Copy code
sql
CREATE MATERIALIZED VIEW mv_fact_insights_market_product_daily_poc
-- Partition by date to manage the 500M rows in time-chunks
PARTITION BY (`date`) 
DISTRIBUTED BY HASH(customer_id)
REFRESH ASYNC EVERY (INTERVAL 1 HOUR) -- Matches your source refresh rate
PROPERTIES (
    "partition_refresh_number" = "1",      -- Refresh 1 day at a time
    "session.enable_spill" = "true",       -- Safety net for OOM
    "session.insert_timeout" = "3600",     -- 1 hour timeout per batch
    "replication_num" = "1"
)
AS 
SELECT * FROM iceberg_adhoc.adhoc.fact_insights_market_product_daily_poc;
5. Alternative: "Atomic Swap" for Full Refresh If the hourly 500M row refresh is too unstable for an MV, you can use the Manual ETL Pattern: 1. Create a standard StarRocks table (
Duplicate Key
). 2. Create a "Buffer" table with the same schema. 3. Every hour, run an
INSERT INTO buffer_table SELECT * FROM iceberg_table
. 4. Once the load is complete, swap them:
Copy code
sql
    ALTER TABLE main_table SWAP WITH buffer_table;
This ensures your queries always see the old data until the entire 500M rows are ready in the new table. Final Recommendation Because your source is a full refresh of 500M rows, you are essentially re-importing the entire data lake into StarRocks every hour. 1. Try the Partitioned MV first with
partition_refresh_number = 1
. 2. Monitor the Task: Use
SELECT * FROM information_schema.task_runs WHERE task_name = '...'
to see if individual batches are succeeding.
3. If it still OOMs: Check
SHOW BACKENDS
to see if your BEs have enough memory allocated (
mem_limit
). For 500M rows, we recommend at least 64GB+ RAM per BE. References • using_starrocks/async_mv/use_cases/data_lake_query_acceleration_with_materialized_views.md • sql-reference/sql-statements/materialized_view/CREATE_MATERIALIZED_VIEW.md • using_starrocks/async_mv/use_cases/create_partitioned_materialized_view.md
g
@Rocky 1. since we have shared data architecture, we want data in the s3 only. so basically stateless. we dont want to go for starRocks native tables 2. i want to track how much time will it take to completely transfer the data? so when i can query on the mv it should give me correct answer. how can i get that?
r
1. Storage: Shared-Data and "Statelessness" In a Shared-Data (Cloud-Native) architecture, StarRocks "native" tables are already essentially stateless. * Where is the data? Even though the MV is a "StarRocks table," all its data is stored in your S3 bucket, not on the local disks of the Backend (BE) nodes. * BE Statelessness: If a BE node dies, no data is lost. A new BE can start up, fetch the metadata from the FE, and begin serving the same data from S3 immediately. * Performance: The reason the MV will be faster than Iceberg is that StarRocks stores the data in its own segment format on S3. This format is optimized for StarRocks' execution engine (supporting features like primary keys, better pruning, and local SSD caching on the BEs). To be clear: You cannot have a Materialized View that stores its results back into Iceberg format. The performance gain you are looking for comes from StarRocks taking ownership of the storage in S3. 2. Tracking Refresh Time and Progress You can monitor exactly how long the data transfer (refresh) takes and its current status by querying the system views. Track Progress and Time:
Copy code
sql
SELECT 
    TASK_NAME,
    CREATE_TIME,
    FINISH_TIME,
    -- Total duration in seconds
    timestampdiff(SECOND, CREATE_TIME, FINISH_TIME) as duration_sec,
    STATE,
    PROGRESS, -- This will show 0-100%
    ERROR_MESSAGE
FROM information_schema.task_runs
WHERE TASK_NAME LIKE (
    SELECT concat('mv-', TABLE_ID) 
    FROM information_schema.tables 
    WHERE table_name = 'mv_fact_insights_market_product_daily_poc'
)
ORDER BY CREATE_TIME DESC;
How to know when it is "Correct": * STATE = 'SUCCESS': The data transfer is complete. * Querying during refresh: If you query the MV while it is refreshing, StarRocks will show you the last successfully completed version of the data. It will not show "half-finished" data or empty results (unless it's the very first load). * In-Sync Status: You can check if the MV is currently up-to-date with the source Iceberg table:
Copy code
sql
    SHOW MATERIALIZED VIEWS WHERE NAME = 'mv_fact_insights_market_product_daily_poc';
Look at the
is_active
and
last_refresh_status
columns. Summary for your 500M row requirement: Since your Iceberg table refreshes fully every hour, the MV will effectively "re-download" and "re-index" that data into StarRocks' S3 format every hour. 1. Use the Partitioned MV DDL I provided previously (partitioning by
date
or
customer_id
into batches). 2. Monitor the first run using the
task_runs
query above. 3. Check Duration: If the transfer takes 45 minutes and your source refreshes every 60 minutes, you are safe. If the transfer takes >60 minutes, you will need to increase your BE count to handle the higher throughput. References • deployment/shared_data/s3.md • using_starrocks/async_mv/materialized_view_task_run_details.md • using_starrocks/async_mv/troubleshooting_asynchronous_materialized_views.md • using_starrocks/async_mv/Materialized_view.md • quick_start/shared-data.md • using_starrocks/async_mv/use_cases/data_lake_query_acceleration_with_materialized_views.md throughput. References • using_starrocks/async_mv/materialized_view_task_run_details.md
g
@Rocky give me final set of queries from dropping exisitng MV, creating new MV and tracking the time.
r
To ensure your 500M+ record refresh is stable and doesn't crash your cluster, here is the sequence of queries for a Shared-Data (Cloud-Native) environment. 1. Drop the Existing MV First, clear the old materialized view to start fresh.
Copy code
sql
DROP MATERIALIZED VIEW IF EXISTS mv_fact_insights_market_product_daily_poc;
2. Create the Optimized MV This DDL uses Partitioning to break the 500M rows into manageable batches. Even though your Iceberg source is a "full refresh," StarRocks will use these partitions to process the data in small chunks (e.g., one day at a time), preventing Memory (OOM) crashes.
Copy code
sql
CREATE MATERIALIZED VIEW mv_fact_insights_market_product_daily_poc
-- 1. Partition by date to enable batched processing of the 500M rows
PARTITION BY (`date`)
DISTRIBUTED BY HASH(customer_id)
-- 2. Schedule to match your Iceberg refresh cycle
REFRESH ASYNC EVERY (INTERVAL 1 HOUR)
PROPERTIES (
    -- 3. Safety: Process only 1 partition (day) at a time to stay under RAM limits
    "partition_refresh_number" = "1",
    -- 4. Safety: Spill to S3 if memory usage gets too high
    "session.enable_spill" = "true",
    -- 5. Increase timeout for the massive initial load (8 hours)
    "session.insert_timeout" = "28800",
    "replication_num" = "1",
    -- 6. Important for shared-data: Data is stored in your S3 bucket
    "storage_volume" = "builtin_storage_volume" 
)
AS 
SELECT 
    `date`, `market_product_id`, `master_product_id`, `marketplace_id`, 
    `customer_id`, `vendor_id`, `customer_type`, `customer_state_id`,
    `estimated_total_page_views`, `estimated_total_page_views_non_china`,
    `estimated_total_sold_units`, `estimated_page_views_lost_to_suppression`,
    `estimated_lost_suppression_sales`, `estimated_lost_suppression_sales_aed`,
    `estimated_lost_suppression_sales_ars`, `estimated_lost_suppression_sales_aud`,
    `estimated_lost_suppression_sales_cad`, `estimated_lost_suppression_sales_cny`,
    `estimated_lost_suppression_sales_eur`, `estimated_lost_suppression_sales_gbp`,
    `estimated_lost_suppression_sales_jpy`, `estimated_lost_suppression_sales_usd`,
    `avg_rating`, `reviews_count`, `estimated_lost_suppression_sales_krw`,
    `estimated_lost_suppression_sales_pln`, `estimated_lost_suppression_sales_sek`,
    `estimated_total_sales`, `estimated_total_sales_aed`, `estimated_total_sales_ars`,
    `estimated_total_sales_aud`, `estimated_total_sales_cad`, `estimated_total_sales_cny`,
    `estimated_total_sales_eur`, `estimated_total_sales_gbp`, `estimated_total_sales_jpy`,
    `estimated_total_sales_usd`, `estimated_total_sales_krw`, `estimated_total_sales_pln`,
    `estimated_total_sales_sek`
FROM iceberg_adhoc.adhoc.fact_insights_market_product_daily_poc;
3. Tracking Refresh Time and Progress Use these queries to monitor the data transfer from Iceberg to StarRocks S3 storage. Check current progress (0-100%):
Copy code
sql
SELECT 
    TASK_NAME,
    CREATE_TIME,
    STATE,
    PROGRESS,
    ERROR_MESSAGE
FROM information_schema.task_runs
WHERE TASK_NAME LIKE (
    SELECT concat('mv-', TABLE_ID) 
    FROM information_schema.tables 
    WHERE table_name = 'mv_fact_insights_market_product_daily_poc'
)
ORDER BY CREATE_TIME DESC 
LIMIT 5;
Calculate exact transfer duration (for successful runs):
Copy code
sql
SELECT 
    TASK_NAME,
    CREATE_TIME,
    FINISH_TIME,
    -- Duration in minutes
    timestampdiff(MINUTE, CREATE_TIME, FINISH_TIME) as duration_minutes,
    STATE
FROM information_schema.task_runs
WHERE STATE = 'SUCCESS'
AND TASK_NAME LIKE 'mv-%'
ORDER BY CREATE_TIME DESC;
Summary of Benefits * Shared-Data Architecture: By creating this MV, the data is moved from Iceberg's S3 location into StarRocks' S3 location. It remains "stateless" at the compute level but gains StarRocks' native performance optimizations.
* Hourly Stability: By setting
partition_refresh_number = 1
, StarRocks will not try to load 500M rows at once. It will load them in a loop, one partition after another, ensuring your Backend (BE) never runs out of memory. * Query Readiness: You can query the MV even while it is refreshing; StarRocks will serve the "last consistent version" until the new hourly refresh is 100% complete. References • using_starrocks/async_mv/materialized_view_task_run_details.md • using_starrocks/async_mv/troubleshooting_asynchronous_materialized_views.md • using_starrocks/async_mv/Materialized_view.md • sql-reference/information_schema/task_runs.md
g
@Rocky while crating MV got error - Query 1 ERROR at Line 8: : Getting analyzing error. Detail message: Materialized view partition column in partition exp must be base table partition column.
r
This error occurs because StarRocks requires a partitioned Materialized View (MV) to align with the partition columns of the base table. Since your Iceberg table is partitioned by
customer_id
, StarRocks insists that the MV also be partitioned by
customer_id
(or a transformation of it). It does this so it can track which specific slices of data have changed in the source to perform "incremental" logic. How to fix this You have two options depending on how many unique
customer_id
values you have. Option A: Partition the MV by
customer_id
(If cardinality is low)
If you have a manageable number of customers (e.g., fewer than 10,000), you can partition the MV by that column. This satisfies the StarRocks requirement and still allows you to use
partition_refresh_number
to avoid OOM.
Copy code
sql
CREATE MATERIALIZED VIEW mv_fact_insights_market_product_daily_poc
PARTITION BY (customer_id) -- Must match Iceberg partition column
DISTRIBUTED BY HASH(customer_id)
REFRESH ASYNC EVERY (INTERVAL 1 HOUR)
PROPERTIES (
    "partition_refresh_number" = "10", -- Refreshes 10 customers at a time
    "session.enable_spill" = "true",
    "replication_num" = "1"
)
AS 
SELECT * FROM iceberg_catalog.adhoc.fact_insights_market_product_daily_poc;
Option B: Use a Manual Table (Best for 500M rows + High Cardinality) If
customer_id
has millions of unique values, partitioning the MV by it will cause metadata overhead and poor performance. Since you cannot partition the MV by
date
(because Iceberg isn't partitioned by it), the most stable "Shared-Data" approach is to use a Standard StarRocks Table and a scheduled task. This approach gives you full control over the 500M row load without the strict MV partition-mapping rules. 1. Create the destination table (Native StarRocks table on S3):
Copy code
sql
CREATE TABLE fact_insights_market_product_daily_poc (
    `date` DATE,
    `customer_id` BIGINT,
    ... -- other columns
)
PARTITION BY (`date`) -- You ARE allowed to partition by date here!
DISTRIBUTED BY HASH(customer_id)
PROPERTIES ("replication_num" = "1");
2. Create a Task to refresh the data: Since your source is a full refresh, you can't easily do incremental. You can use a task to perform the "Atomic Swap" every hour:
Copy code
sql
-- This task clears and reloads the data every hour
CREATE TASK refresh_iceberg_data
WAREHOUSE = 'your_warehouse_name'
SCHEDULE = '0 * * * *' -- Every hour
AS
INSERT OVERWRITE fact_insights_market_product_daily_poc 
SELECT * FROM iceberg_catalog.adhoc.fact_insights_market_product_daily_poc;
Which one should you choose? * Choose Option A (MV) if you want the "Auto-Refresh" convenience and your
customer_id
count is small. * Choose Option B (Manual Table + Task) if
customer_id
is unique/high-cardinality or if you want the best query performance by partitioning the StarRocks data by
date
. To Track Time (For either option): You can use the same query I provided earlier to check how long the
INSERT OVERWRITE
or the MV task took:
Copy code
sql
SELECT 
    TASK_NAME,
    CREATE_TIME,
    FINISH_TIME,
    timestampdiff(MINUTE, CREATE_TIME, FINISH_TIME) as duration_minutes,
    STATE,
    ERROR_MESSAGE
FROM information_schema.task_runs
ORDER BY CREATE_TIME DESC LIMIT 10;
References • using_starrocks/async_mv/use_cases/create_partitioned_materialized_view.md • sql-reference/sql-statements/data-manipulation/INSERT.md • using_starrocks/Internal_Task_Management.md References • using_starrocks/async_mv/use_cases/create_partitioned_materialized_view.md
g
@Rocky SELECT TASK_NAME, CREATE_TIME, STATE, PROGRESS, ERROR_MESSAGE FROM information_schema.task_runs WHERE TASK_NAME LIKE ( SELECT (concat('mv-', TABLE_ID) ) FROM information_schema.tables WHERE table_name = 'mv_fact_insights_market_product_daily_poc' ) ORDER BY CREATE_TIME DESC LIMIT 5; - Query 1 ERROR at Line 20: : Getting analyzing error. Detail message: Column 'TABLE_ID' cannot be resolved.
r
The error occurred because the
TABLE_ID
column does not exist in the
information_schema.tables
view (it is located in
information_schema.tables_config
instead). However, there is a much simpler way to track your Materialized View. You can query
information_schema.materialized_views
directly, which already contains the
TASK_NAME
and the status of the most recent refresh. 1. The Corrected "Single Query" for Progress Use this query to join the task history with the specific MV name:
Copy code
sql
SELECT 
    tr.TASK_NAME,
    tr.CREATE_TIME,
    tr.FINISH_TIME,
    tr.STATE,
    tr.PROGRESS,
    tr.ERROR_MESSAGE
FROM information_schema.task_runs tr
JOIN information_schema.materialized_views mv 
  ON tr.TASK_NAME = mv.TASK_NAME
WHERE mv.TABLE_NAME = 'mv_fact_insights_market_product_daily_poc'
ORDER BY tr.CREATE_TIME DESC
LIMIT 5;
2. Quickly Check Last Refresh Summary If you just want to see if the last attempt was successful and how long it took without looking at the full history:
Copy code
sql
SELECT 
    TABLE_NAME,
    IS_ACTIVE,
    LAST_REFRESH_STATE,
    LAST_REFRESH_START_TIME,
    LAST_REFRESH_FINISHED_TIME,
    LAST_REFRESH_DURATION as duration_seconds,
    LAST_REFRESH_ERROR_MESSAGE
FROM information_schema.materialized_views
WHERE TABLE_NAME = 'mv_fact_insights_market_product_daily_poc';
Why this works better: * No guessing IDs:
information_schema.materialized_views
acts as a lookup table that maps your MV name directly to its background
TASK_NAME
. * Direct Access: The
LAST_REFRESH_...
columns give you an instant snapshot of the current state without having to filter through thousands of task logs. References • sql-reference/information_schema/materialized_views.md • sql-reference/information_schema/task_runs.md • using_starrocks/async_mv/materialized_view_task_run_details.md References • sql-reference/information_schema/materialized_views.md • sql-reference/sql-statements/materialized_view/SHOW_MATERIALIZED_VIEW.md • sql-reference/information_schema/columns.md
g
@Rocky 1. output attached 2. mv_fact_insights_market_product_daily_poc true RUNNING 2026-07-10 162801
r
It is good news that the MV is
RUNNING
and
IS_ACTIVE
. Since you are processing 500M+ records, the "Running" state might last for a while. To see exactly how much progress has been made (e.g., 10%, 50%) and check if it's hitting any memory limits, use this query: 1. Check Real-Time Progress (%) This query looks into the
task_runs
table specifically for the currently active execution.
Copy code
sql
SELECT 
    TASK_NAME,
    CREATE_TIME,
    STATE,
    PROGRESS, -- This will show percentage or status like 'RUNNING'
    EXTRA_MESSAGE -- Often contains specific info about the current partition being processed
FROM information_schema.task_runs
WHERE STATE = 'RUNNING'
  AND TASK_NAME = (
      SELECT TASK_NAME 
      FROM information_schema.materialized_views 
      WHERE TABLE_NAME = 'mv_fact_insights_market_product_daily_poc'
  )
ORDER BY CREATE_TIME DESC;
2. How to interpret the progress * If
PROGRESS
is increasing:
The data is flowing correctly from Iceberg to StarRocks S3 storage. * If
PROGRESS
stays at 0% for a long time:
It is likely still "Analyzing" the 500M rows or building the initial execution plan. * If you see
partition_refresh_number
logic in action:
If you used the partition settings from earlier, StarRocks will process the data in batches. The
EXTRA_MESSAGE
may show which specific date/partition is currently being inserted. 3. Safety: How to stop it if needed If the task takes too long or you want to change the settings (like adding more memory/timeout), you can stop the current run:
Copy code
sql
-- Replace 'mv-12345' with the actual TASK_NAME from the query in Step 1
CANCEL TASK RUN FOR mv-xxxxxx;
Note: Since this is a Shared-Data cluster, the compute nodes (CN) will handle the heavy lifting. You can monitor the CPU/Memory of your cluster nodes in your Cloud console to ensure they aren't hitting 100% utilization.
g
1. @Rocky mv-32782 2026-07-10 163035 RUNNING 4% "{""forceRefresh"":false,""partitionStart"":""30"",""partitionEnd"":""2439"",""mvPartitionsToRefresh"":[""p44"",""p36"",""p46"",""p38"",""p37"",""p30"",""p52"",""p51"",""p32"",""p53""],""refBasePartitionsToRefreshMap"":{""fact_insights_market_product_daily_poc"":[""p44"",""p36"",""p46"",""p38"",""p37"",""p30"",""p52"",""p51"",""p32"",""p53""]},""basePartitionsToRefreshMap"":{},""processStartTime"":1783672235441,""executeOption"":{""priority"":90,""taskRunProperties"":{""PARTITION_START"":""30"",""warehouse"":""default_warehouse"",""PARTITION_END"":""2439"",""mvId"":""32782"",""START_TASK_RUN_ID"":""435463e3-7c39-11f1-9595-8a5cd1361ab8""},""isMergeRedundant"":true,""isManual"":false,""isSync"":false,""isReplay"":false},""planBuilderMessage"":{""fact_insights_market_product_daily_poc"":""((((customer_id \u003e\u003d 30) AND (customer_id \u003c 31)) OR ((customer_id \u003e\u003d 32) AND (customer_id \u003c 33))) OR (((customer_id \u003e\u003d 36) AND (customer_id \u003c 39)) OR ((customer_id \u003e\u003d 44) AND (customer_id \u003c 45)))) OR (((customer_id \u003e\u003d 46) AND (customer_id \u003c 47)) OR ((customer_id \u003e\u003d 51) AND (customer_id \u003c 54)))""}}"
r
This output is excellent—it confirms that the Materialized View is working exactly as intended. Here is the breakdown of what is happening: 1. Batch Refresh is Active The JSON shows that StarRocks is processing the data in a batch of 10 partitions (
p44
,
p36
,
p46
, etc.). This confirms that your property
"partition_refresh_number" = "10"
is working. * Instead of trying to load all 500M rows at once (which might OOM), it is only pulling data for the specific
customer_id
ranges shown in the
planBuilderMessage
(e.g.,
customer_id >= 30 AND customer_id < 31
). 2. Understanding the Progress (4%) The 4% progress indicates that it has successfully processed or is currently working on the first small slice of the total 2,400+ partitions (range 30 to 2439). * What happens next: Once these 10 partitions are finished, StarRocks will automatically start the next batch of 10 until all partitions are synchronized. 3. Key Observations from the JSON * Source Filter: The
planBuilderMessage
shows the exact SQL logic StarRocks is sending to Iceberg. It is efficiently targeting specific
customer_id
ranges. * Warehouse: It is using the
default_warehouse
. * Partition IDs: The
p30
,
p32
names are internal StarRocks identifiers for the
customer_id
values. What you should do now: * Just let it run. Since it’s at 4% and has successfully calculated the plan, the most "dangerous" part (the planning phase) is over. It is now in the data-shoveling phase. * Monitor Memory: If you see the status change from
RUNNING
to
FAILED
with an "Intermediate Result exceeding limit" or "OOM" error, we may need to reduce the
partition_refresh_number
from
10
down to
5
or
2
. * Check again in 30 mins: Run the same query to see if the
PROGRESS
has increased or if the
mvPartitionsToRefresh
list has moved on to the next set of IDs. Is the current speed acceptable to you, or do you need it to go faster? (If it's too slow, we can discuss increasing the warehouse size or the batch number of parallel partitions).