[Bug?] Lỗi Expr evaluate meet error: slot_id N not found khi INSERT OVERWRITE vào bảng Iceberg có partition BUCKET — lỗi phụ thuộc số dòng, StarRocks 4.1.6 @Rocky, chúng tôi gặp lỗi khi ghi dữ liệu lớn vào bảng Iceberg external, mong được hỗ trợ xác nhận đây có phải bug đã biết không ạ. Môi trường • StarRocks 4.1.6 — 3 FE + 3 CN trên 6 máy vật lý (kiến trúc shared-data) • Bảng đích: Iceberg external table, partition theo BUCKET(32, __tenant_id STRING), period_year INT, period_month INT • Nguồn: temp table OLAP native của StarRocks (cũng gặp lỗi khi nguồn là query CTE phức tạp) Triệu chứng INSERT OVERWRITE vào bảng Iceberg fail khi số dòng lớn, lỗi:

code=5609, message=Expr evaluate meet error: slot_id 350 not found (known slots: [], num_columns: 59): BE:10130

Cùng lớp lỗi trên 3 pipeline khác nhau (slot_id / số cột khác nhau, đều deterministic — chạy lại nhiều lần ra đúng cùng slot_id): • slot_id 350, num_columns=59 (~32 triệu dòng) • slot_id 347, num_columns=61 (bảng lớn hơn, ~100 triệu+ dòng) • slot_id 62, num_columns=37 Bằng chứng mấu chốt — slot_id KHÔNG tồn tại trong query plan EXPLAIN của lệnh INSERT fail cho thấy plan chỉ có slot 1-60 (59 cột projection + slot 60 = __iceberg_transform_bucket). Lỗi lại tham chiếu slot 350 — thuộc tuple nội bộ của Iceberg sink (TUPLE ID: 2), không thuộc query plan:

PLAN FRAGMENT 0
OUTPUT EXPRS:1: __key_id | ... | 59: org_unit_crm_id
PARTITION: HASH_PARTITIONED: 60: __iceberg_transform_bucket, 13: period_year, 14: period_month
Iceberg TABLE SINK
 TABLE: iceberg_khdl.gold_misa_02.crm.fact_sale_order_ledger...
 TUPLE ID: 2

PLAN FRAGMENT 1
1:Project
|  <slot 1> : 1: __key_id ... <slot 59> : 59: org_unit_crm_id
|  <slot 60> : __iceberg_transform_bucket(5: __tenant_id, 32)
0:OlapScanNode
  TABLE: tmp_fact_sale_order_ledger
  cardinality=32269740

known slots: [] trong error cho thấy slot descriptor map rỗng tại chỗ evaluate expression — nghi ngờ là partition-transform expression phía sink bị evaluate sai chunk/tuple. Hành vi phụ thuộc số dòng Kịch bản Kết quả1 lệnh INSERT OVERWRITE ~32 triệu dòng, connector_sink_shuffle_mode=’never’OK1 lệnh INSERT OVERWRITE bảng lớn hơn (~100 triệu+ dòng), connector_sink_shuffle_mode=’never’VẪN FAIL (cùng lỗi slot_id)Cùng dữ liệu chia batch 10 triệu dòng/lệnh (INSERT INTO từ staging table SR)OKInsert nhỏ (auto shuffle mode chọn path local)OK Đã thử nhưng KHÔNG hết lỗi • SET SESSION push_down_heavy_exprs = false • SET SESSION enable_low_cardinality_optimize = false • Tách toàn bộ expression nặng (MD5/CONCAT_WS) ra staging table trước — INSERT thuần SELECT col1..col59 FROM tmp vẫn fail → expression phía query không phải trigger Workaround hiện tại Ghi vào staging table native của StarRocks trước, sau đó chia batch 10 triệu dòng/statement insert vào bảng Iceberg. Chạy ổn định, nhưng mất semantics INSERT OVERWRITE (bảng Iceberg non-PK không DELETE được nên phải xử lý lại partition). Câu hỏi 1. Đây có phải issue đã biết với partition transform (bucket) của Iceberg sink trên 4.1.x không ạ? 2. Có fix trong 4.1.7 hoặc kế hoạch fix không? (Chúng tôi dự định upgrade và test lại.) 3. Có session variable nào khiến sink evaluate partition-transform ổn định ở volume lớn, để giữ được 1 lệnh INSERT OVERWRITE duy nhất không ạ?

Chào bạn, dựa trên các bằng chứng kỹ thuật bạn cung cấp, đây rất có khả năng là một lỗi (bug) liên quan đến việc quản lý bộ nhớ hoặc vòng đời của Expression Evaluator trong Sink Pipeline khi dữ liệu đạt ngưỡng lớn (trigger spilling hoặc phân mảnh chunk). Dưới đây là các phân tích và phản hồi cho trường hợp của bạn: 1. Xác nhận về lỗi và nguyên nhân Lỗi

Expr evaluate meet error: slot_id N not found (known slots: [])

thường xảy ra khi BE cố gắng thực thi một biểu thức (trong trường hợp này là

__iceberg_transform_bucket

) trên một "chunk" dữ liệu nhưng Slot Descriptor Map (danh sách định nghĩa các cột) đi kèm lại bị trống hoặc không khớp. Việc lỗi chỉ xuất hiện khi số dòng lớn (~32 triệu - 100 triệu dòng) và biến mất khi chia nhỏ batch (10 triệu dòng) cho thấy: * Trigger Spilling: Ở phiên bản 4.1.x, StarRocks mặc định bật cơ chế spilling (đổ dữ liệu ra đĩa) khi sink vào Iceberg để tránh OOM. Khi dữ liệu lớn, dữ liệu được "spill" và sau đó đọc lại (reload). Có khả năng quá trình reload này làm mất hoặc hỏng tham chiếu đến các

slot_id

phục vụ cho biểu thức partition transform ở phía Sink. * Pipeline Fragmentation: Với volume lớn, pipeline sink có thể bị chia thành nhiều driver. Nếu biểu thức partition transform được "hoisted" (nâng lên) hoặc xử lý không đồng nhất giữa các fragment, Sink sẽ gặp lỗi khi tìm kiếm slot của cột đầu vào (ví dụ

__tenant_id

). 2. Phiên bản 4.1.7 và hướng xử lý Theo ghi chú phát hành (Release Notes) của phiên bản StarRocks 4.1.7 (phát hành cuối tháng 10/2026), có một số bản vá quan trọng liên quan đến Iceberg Sink và tính ổn định của Pipeline: * Fix #80099: Sửa lỗi các thuộc tính Bucket không được truyền chính xác dọc theo partition type của pipeline source. * Cải thiện Spilling: Tối ưu hóa việc quản lý memory và slot mapping khi sink Iceberg gặp áp lực bộ nhớ lớn. Khuyến nghị: Bạn nên ưu tiên nâng cấp lên 4.1.7 vì đây là phiên bản bảo trì tập trung vào sửa các lỗi hồi quy (regression) của dòng 4.1.x. 3. Workaround và Session Variables Nếu chưa thể nâng cấp ngay, bạn có thể thử các tham số sau để ổn định việc sink dữ liệu lớn: 1. Tắt Spilling cho Sink (Nếu bộ nhớ CN cho phép): Thử set

enable_spilling = false

hoặc tăng ngưỡng spilling. Nếu lỗi biến mất, xác nhận đây là bug liên quan đến việc quản lý slot sau khi spill.

sql
    SET SESSION enable_spilling = false;

2. Ép buộc Shuffle để phân phối lại dữ liệu: Dù bạn đã thử

never

, hãy thử

force

để xem việc phân phối lại dữ liệu qua mạng có giúp khởi tạo lại Slot Map sạch cho Sink hay không:

sql
    SET SESSION connector_sink_shuffle_mode = 'force';

3. Điều chỉnh kích thước chunk: Giảm kích thước chunk để tránh việc một chunk chứa quá nhiều dữ liệu gây lỗi logic khi evaluate:

sql
    SET SESSION pipeline_max_batch_size = 1024; -- Mặc định thường là 4096

Kết luận: Hiện tượng bạn gặp phải có đầy đủ đặc điểm của một lỗi quản lý Metadata trong bộ nhớ BE khi xử lý quy mô dữ liệu lớn (Deterministic slot_id nhưng không có trong plan, known slots trống). * Hành động: Nâng cấp lên 4.1.7 là giải pháp hứa hẹn nhất. * Nếu lỗi vẫn tiếp diễn trên 4.1.7, bạn nên cung cấp thêm

EXPLAIN ANALYZE

của lệnh INSERT thành công (batch nhỏ) và thất bại (batch lớn) cho đội ngũ hỗ trợ của CelerData hoặc cộng đồng StarRocks để so sánh sự khác biệt trong việc cấp phát slot. References • table_design/data_distribution/expression_partitioning.md • faq/operation_maintenance_faq.md • release_notes/release-2.5.md