@Rocky hãy so sánh vì sao khi insert bảng đầu lại bị lỗi Expr evaluate meet error: slot_id 1 not found (known slots: [], num_columns: 37): BE:10129 còn query thứ 2 lại ko lỗi ở đây bảng đầu tiên dùng partition là Field ID Source Transform Tên partition 1000 5 bucket[32] __tenant_id_bucket 1001 13 identity period_year 1002 14 identity period_month bảng thứ 2 là: Field ID Source Transform Tên partition 1000 5 identity __tenant_id 1001 13 identity period_year 1002 14 identity period_month EXPLAIN INSERT INTO iceberg_khdl.

gold_misa_02.crm

.wide_customer SELECT * FROM tv_wide_q; PLAN FRAGMENT 0 OUTPUT EXPRS1 __key_id | 2: __id | 3: __deleted | 4: __sync_date | 5: __tenant_id | 6: __tenant_code | 7: __tenant_name | 8: __tax_code | 9: __accounting_system | 10: __session_id | 11: period_type | 12: period_date | 13: period_year | 14: period_month | 15: period_quarter | 16: period_label | 17: org_unit_id | 18: org_unit_code | 19: org_unit_name | 20: org_unit_level | 21: org_full_path | 22: org_type | 23: branch_id | 24: customer_id | 25: customer_name | 26: customer_code | 27: is_new_customer | 28: first_book_date | 29: ledger_revenue | 30: ledger_revenue_orders | 31: ledger_revenue_returns | 32: ledger_order_count | 33: order_count | 34: total_order_amount | 35: avg_order_amount | 36: return_count | 37: total_return_amount PARTITION: HASH_PARTITIONED: 38: __iceberg_transform_bucket, 13: period_year, 14: period_month Iceberg TABLE SINK TABLE: iceberg_khdl.gold_misa_02.crm.wide_customer.7fefc1a6-6308-433d-9591-82557840485f TUPLE ID: 2 RANDOM 2:EXCHANGE PLAN FRAGMENT 1 OUTPUT EXPRS: PARTITION: RANDOM STREAM DATA SINK EXCHANGE ID: 02 HASH_PARTITIONED: 38: __iceberg_transform_bucket, 13: period_year, 14: period_month 1:Project | <slot 1> : 1: __key_id | <slot 2> : 2: __id | <slot 3> : 3: __deleted | <slot 4> : 4: __sync_date | <slot 5> : 5: __tenant_id | <slot 6> : 6: __tenant_code | <slot 7> : 7: __tenant_name | <slot 8> : 8: __tax_code | <slot 9> : 9: __accounting_system | <slot 10> : 10: __session_id | <slot 11> : 11: period_type | <slot 12> : 12: period_date | <slot 13> : 13: period_year | <slot 14> : 14: period_month | <slot 15> : 15: period_quarter | <slot 16> : 16: period_label | <slot 17> : 17: org_unit_id | <slot 18> : 18: org_unit_code | <slot 19> : 19: org_unit_name | <slot 20> : 20: org_unit_level | <slot 21> : 21: org_full_path | <slot 22> : 22: org_type | <slot 23> : 23: branch_id | <slot 24> : 24: customer_id | <slot 25> : 25: customer_name | <slot 26> : 26: customer_code | <slot 27> : 27: is_new_customer | <slot 28> : 28: first_book_date | <slot 29> : 29: ledger_revenue | <slot 30> : 30: ledger_revenue_orders | <slot 31> : 31: ledger_revenue_returns | <slot 32> : 32: ledger_order_count | <slot 33> : 33: order_count | <slot 34> : 34: total_order_amount | <slot 35> : 35: avg_order_amount | <slot 36> : 36: return_count | <slot 37> : 37: total_return_amount | <slot 38> : __iceberg_transform_bucket(5: __tenant_id, 32) | 0:OlapScanNode TABLE: tv_wide_q PREAGGREGATION: ON partitions=1/1 rollup: tv_wide_q tabletRatio=3/3 tabletList=5738996,5738997,5738998 cardinality=7459244 avgRowSize=529.92194 EXPLAIN INSERT INTO iceberg_khdl.

gold_misa_02.crm

.wide_customer_ltquan_test SELECT * FROM tv_wide_q; PLAN FRAGMENT 0 OUTPUT EXPRS1 __key_id | 2: __id | 3: __deleted | 4: __sync_date | 5: __tenant_id | 6: __tenant_code | 7: __tenant_name | 8: __tax_code | 9: __accounting_system | 10: __session_id | 11: period_type | 12: period_date | 13: period_year | 14: period_month | 15: period_quarter | 16: period_label | 17: org_unit_id | 18: org_unit_code | 19: org_unit_name | 20: org_unit_level | 21: org_full_path | 22: org_type | 23: branch_id | 24: customer_id | 25: customer_name | 26: customer_code | 27: is_new_customer | 28: first_book_date | 29: ledger_revenue | 30: ledger_revenue_orders | 31: ledger_revenue_returns | 32: ledger_order_count | 33: order_count | 34: total_order_amount | 35: avg_order_amount | 36: return_count | 37: total_return_amount PARTITION: HASH_PARTITIONED: 5: __tenant_id, 13: period_year, 14: period_month Iceberg TABLE SINK TABLE: iceberg_khdl.gold_misa_02.crm.wide_customer_ltquan_test.4ab6c340-7481-4e20-b22e-68b26a5847d2 TUPLE ID: 1 RANDOM 1:EXCHANGE PLAN FRAGMENT 1 OUTPUT EXPRS: PARTITION: RANDOM STREAM DATA SINK EXCHANGE ID: 01 HASH_PARTITIONED: 5: __tenant_id, 13: period_year, 14: period_month 0:OlapScanNode TABLE: tv_wide_q PREAGGREGATION: ON partitions=1/1 rollup: tv_wide_q tabletRatio=3/3 tabletList=5738996,5738997,5738998 cardinality=7459244 avgRowSize=528.92194

Lỗi bạn gặp phải (

Expr evaluate meet error: slot_id 1 not found

) khi sử dụng

bucket[32]

cho bảng Iceberg là một lỗi liên quan đến việc xử lý các Hidden Partition Transforms (phân vùng ẩn) trong StarRocks khi thực hiện lệnh

INSERT

. Dưới đây là so sánh chi tiết nguyên nhân tại sao bảng đầu bị lỗi và bảng thứ hai thì không: 1. Sự khác biệt trong Kế hoạch thực thi (Query Plan) * Bảng 1 (Lỗi) - Dùng `bucket[32]`: * Trong bảng này, cột

*tenant_id

không được dùng trực tiếp để phân vùng mà phải qua một hàm biến đổi:

bucket<*tenant_id|32>

. * Nhìn vào bản tin

EXPLAIN

của bảng 1, StarRocks tạo ra một slot ảo (slot 38) trong `1:Project`:

| <slot 38> : *iceberg_transform_bucket(5: *tenant_id, 32)

. * Dữ liệu sau đó được đẩy qua một tiến trình trao đổi (

EXCHANGE

) và phân tán (

HASH_PARTITIONED

) dựa trên slot 38 này. * Vấn đề: Khi

Iceberg TABLE SINK

ở Fragment 0 cố gắng ghi dữ liệu, hệ thống gặp lỗi vì BE (Backend) không tìm thấy định nghĩa hoặc giá trị của các slot gốc (như

slot 1: __key_id

) trong ngữ cảnh tính toán của partition transform. Thông báo

known slots: []

cho thấy tại thời điểm lỗi, bộ nhớ đệm (context) của biểu thức đang bị trống, dẫn đến việc không truy xuất được cột ID 1. * Bảng 2 (Thành công) - Dùng `identity`: * Với

identity

, giá trị phân vùng chính là giá trị thực của cột

__tenant_id

(slot 5). * StarRocks không cần tạo thêm slot ảo phức tạp hay thực hiện hàm biến đổi

bucket

trong quá trình shuffle dữ liệu cho Sink. * Mọi cột từ 1 đến 37 được truyền thẳng từ bản nguồn sang bản đích mà không làm thay đổi cấu trúc Tuple (bản ghi) trong bộ nhớ, giúp BE xử lý ổn định. 2. Nguyên nhân kỹ thuật Đây thường là một lỗi logic trong phần mã nguồn (bug) của StarRocks khi lập lịch cho Iceberg Sink: * Mismatch Metadata: Khi có hàm biến đổi như

bucket

hoặc

truncate

, StarRocks cần tạo ra một cấu trúc dữ liệu trung gian. Trong một số phiên bản, việc ánh xạ (mapping) giữa các cột gốc và cột biến đổi này bị lỗi khi đi qua các Fragment khác nhau. * Version: Tính năng

INSERT

vào Iceberg và hỗ trợ các hàm biến đổi partition (Hidden Partitions) được hoàn thiện dần từ phiên bản v3.1 trở đi. Nếu bạn đang dùng các phiên bản cũ hơn hoặc các bản build sớm của v3.2/v3.3, lỗi này rất dễ xảy ra với các hàm

bucket()

. 3. Cách khắc phục đề xuất 1. Sử dụng Identity (như bạn đã làm): Đây là cách an toàn nhất hiện tại nếu logic nghiệp vụ cho phép. Nó tránh việc BE phải tính toán thêm hàm băm (hash) của Iceberg trong lúc ghi. 2. Cập nhật phiên bản StarRocks: Các lỗi liên quan đến

slot_id not found

khi xử lý Iceberg Sink thường xuyên được fix trong các bản patch mới (ví dụ các bản cập nhật của v3.2.x hoặc v3.3.x trở lên). 3. Kiểm tra dữ liệu NULL: Iceberg không cho phép giá trị

NULL

trong cột phân vùng. Hãy đảm bảo cột

*tenant_id

không chứa giá trị NULL bằng cách thêm

WHERE *tenant_id IS NOT NULL

vào câu lệnh

SELECT

để loại trừ khả năng hàm

bucket

gặp lỗi khi tính toán trên giá trị rỗng. 4. Cấu hình bổ sung: Thử thiết lập biến sau trước khi thực hiện insert để ép kiểu xử lý pipeline:

sql
    SET enable_pipeline_engine = true;

Tóm lại: Lỗi xảy ra do StarRocks gặp trục trặc khi quản lý các "cột ảo" được sinh ra từ hàm

bucket[32]

. Việc chuyển sang

identity

giúp đơn giản hóa cấu trúc dữ liệu truyền giữa các node xử lý, do đó tránh được lỗi này. References • data_source/catalog/iceberg/DML.md • quick_start/iceberg.md • data_source/catalog/iceberg/iceberg_catalog.md • data_source/feature-support-data-lake-analytics.md • faq/loading/Loading_faq.md