Gururaj Mahajan
07/10/2026, 8:00 AMREFRESH 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?Rocky
07/10/2026, 8:00 AMinformation_schema.task_runs table using the query_id you received:
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:
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:
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.mdGururaj Mahajan
07/10/2026, 8:13 AMmv_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'@'%'"Rocky
07/10/2026, 8:13 AM[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:
sql
SHOW PROFILELIST;
* To see the detailed execution graph for your ID:
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.mdRocky
07/10/2026, 8:13 AMGururaj Mahajan
07/10/2026, 8:14 AMRocky
07/10/2026, 8:14 AMSELECT * 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:
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:
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:
sql
SHOW RESOURCE GROUPS;
If needed, you can assign a dedicated resource group with higher limits to this specific MV using:
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.mdRocky
07/10/2026, 8:14 AMGururaj Mahajan
07/10/2026, 8:19 AMRocky
07/10/2026, 8:19 AMcustomer_id, your StarRocks MV should also be partitioned by customer_id to enable incremental refreshes.
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:
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:
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:
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:
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.Rocky
07/10/2026, 8:19 AMGururaj Mahajan
07/10/2026, 8:20 AMRocky
07/10/2026, 8:21 AMINSERT 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
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:
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.Rocky
07/10/2026, 8:21 AMSHOW 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.mdGururaj Mahajan
07/10/2026, 8:23 AMRocky
07/10/2026, 8:23 AMsql
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:
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.mdGururaj Mahajan
07/10/2026, 8:24 AMRocky
07/10/2026, 8:25 AMsql
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.
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%):
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):
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.Rocky
07/10/2026, 8:25 AMpartition_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.mdGururaj Mahajan
07/10/2026, 8:26 AMRocky
07/10/2026, 8:27 AMcustomer_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.
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):
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:
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:
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.mdRocky
07/10/2026, 8:27 AMGururaj Mahajan
07/10/2026, 8:29 AMRocky
07/10/2026, 8:29 AMTABLE_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:
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:
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.mdGururaj Mahajan
07/10/2026, 8:30 AMRocky
07/10/2026, 8:30 AMRUNNING 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.
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:
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.Gururaj Mahajan
07/10/2026, 8:31 AMRocky
07/10/2026, 8:31 AMp44, 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).