メインコンテンツまでスキップ
バージョン: Candidate-3.5

Iceberg catalog

ヒント

この例では、StarRocks Basics クイックスタートで紹介されている Local Climatological Data (LCD) データセットを使用しています。データをロードして、自分で例を試すことができます。

Iceberg catalog は、StarRocks が v2.4 以降でサポートする外部 catalog の一種です。Iceberg catalog を使用すると、以下のことが可能です。

  • Iceberg に保存されたデータを直接クエリし、手動でテーブルを作成する必要がありません。
  • Iceberg に保存されたデータを処理し、StarRocks にデータをロードするために INSERT INTO または非同期マテリアライズドビュー（v2.5 以降でサポート）を使用します。
  • StarRocks 上で操作を行い、Iceberg データベースやテーブルを作成または削除したり、StarRocks テーブルから Parquet 形式の Iceberg テーブルにデータをシンクするために INSERT INTO を使用します（この機能は v3.1 以降でサポート）。

Iceberg クラスターで SQL ワークロードを成功させるためには、StarRocks クラスターが Iceberg クラスターのストレージシステムとメタストアにアクセスできる必要があります。StarRocks は以下のストレージシステムとメタストアをサポートしています。

  • 分散ファイルシステム（HDFS）または AWS S3、Microsoft Azure Storage、Google GCS、または他の S3 互換ストレージシステム（例: MinIO）

  • メタストアとして Hive metastore、AWS Glue、または Tabular

注記
  • ストレージとして AWS S3 を選択した場合、メタストアとして HMS または AWS Glue を使用できます。他のストレージシステムを選択した場合、メタストアとして HMS のみを使用できます。
  • メタストアとして Tabular を選択した場合、Iceberg REST catalog を使用する必要があります。

使用上の注意​

StarRocks を使用して Iceberg からデータをクエリする際には、以下の点に注意してください。

ファイル形式圧縮形式Iceberg テーブルバージョン
ParquetSNAPPY, LZ4, ZSTD, GZIP, NO_COMPRESSION
  • v1 テーブル: サポートされています。
  • v2 テーブル: StarRocks v3.1 以降でサポートされており、これらの v2 テーブルに対するクエリは位置削除をサポートします。v3.1.10、v3.2.5、v3.3 およびそれ以降のバージョンでは、v2 テーブルに対するクエリは等価削除もサポートします。
ORCZLIB, SNAPPY, LZO, LZ4, ZSTD, NO_COMPRESSION
  • v1 テーブル: サポートされています。
  • v2 テーブル: StarRocks v3.0 以降でサポートされており、これらの v2 テーブルに対するクエリは位置削除をサポートします。v3.1.8、v3.2.3、v3.3 およびそれ以降のバージョンでは、v2 テーブルに対するクエリは等価削除もサポートします。

統合準備​

Iceberg catalog を作成する前に、StarRocks クラスターが Iceberg クラスターのストレージシステムとメタストアと統合できることを確認してください。

ストレージ​

ストレージタイプに一致するタブを選択してください。

Iceberg クラスターがストレージとして AWS S3 を使用している場合、またはメタストアとして AWS Glue を使用している場合、適切な認証方法を選択し、StarRocks クラスターが関連する AWS クラウドリソースにアクセスできるように必要な準備を行ってください。

以下の認証方法が推奨されます。

  • インスタンスプロファイル
  • 想定ロール
  • IAM ユーザー

上記の 3 つの認証方法の中で、インスタンスプロファイルが最も広く使用されています。

詳細については、 AWS IAM での認証の準備 を参照してください。

Iceberg catalog の作成​

構文​

CREATE EXTERNAL CATALOG <catalog_name>
[COMMENT <comment>]
PROPERTIES
(
    "type" = "iceberg",
    MetastoreParams,
    StorageCredentialParams,
    MetadataUpdateParams
)

パラメーター​

catalog_name​

Iceberg catalog の名前です。命名規則は次のとおりです。

  • 名前には文字、数字 (0-9)、およびアンダースコア (_) を含めることができます。文字で始める必要があります。
  • 名前は大文字と小文字を区別し、長さは 1023 文字を超えることはできません。

comment​

Iceberg catalog の説明です。このパラメーターはオプションです。

type​

データソースのタイプです。値を iceberg に設定します。

MetastoreParams​

StarRocks がデータソースのメタストアと統合する方法に関する一連のパラメーターです。メタストアタイプに一致するタブを選択してください。

Hive metastore​

データソースのメタストアとして Hive metastore を選択した場合、MetastoreParams を次のように構成します。

"iceberg.catalog.type" = "hive",
"hive.metastore.uris" = "<hive_metastore_uri>"
注記

Iceberg データをクエリする前に、Hive metastore ノードのホスト名と IP アドレスのマッピングを /etc/hosts パスに追加する必要があります。そうしないと、クエリを開始する際に StarRocks が Hive metastore にアクセスできない可能性があります。

次の表は、MetastoreParams で構成する必要があるパラメーターを説明しています。

  • iceberg.catalog.type

    • 必須: はい
    • 説明: Iceberg クラスターで使用するメタストアのタイプ。値を hive に設定します。

  • hive.metastore.uris

    • 必須: はい
    • 説明: Hive metastore の URI。形式: thrift://<metastore_IP_address>:<metastore_port>。
      Hive metastore に高可用性 (HA) が有効になっている場合、複数のメタストア URI を指定し、カンマ (,) で区切ることができます。例: "thrift://<metastore_IP_address_1>:<metastore_port_1>,thrift://<metastore_IP_address_2>:<metastore_port_2>,thrift://<metastore_IP_address_3>:<metastore_port_3>"。

StorageCredentialParams​

StarRocks がストレージシステムと統合する方法に関する一連のパラメーターです。このパラメーターセットはオプションです。

次の点に注意してください。

  • ストレージとして HDFS を使用する場合、StorageCredentialParams を構成する必要はなく、このセクションをスキップできます。ストレージとして AWS S3、他の S3 互換ストレージシステム、Microsoft Azure Storage、または Google GCS を使用する場合、StorageCredentialParams を構成する必要があります。

  • メタストアとして Tabular を使用する場合、StorageCredentialParams を構成する必要はなく、このセクションをスキップできます。メタストアとして HMS または AWS Glue を使用する場合、StorageCredentialParams を構成する必要があります。

ストレージタイプに一致するタブを選択してください。

AWS S3​

Iceberg クラスターのストレージとして AWS S3 を選択した場合、次のいずれかの操作を行います。

  • インスタンスプロファイルベースの認証方法を選択するには、StorageCredentialParams を次のように構成します。

    "aws.s3.use_instance_profile" = "true",
    "aws.s3.region" = "<aws_s3_region>"

  • 想定ロールベースの認証方法を選択するには、StorageCredentialParams を次のように構成します。

    "aws.s3.use_instance_profile" = "true",
    "aws.s3.iam_role_arn" = "<iam_role_arn>",
    "aws.s3.region" = "<aws_s3_region>"

  • IAM ユーザーベースの認証方法を選択するには、StorageCredentialParams を次のように構成します。

    "aws.s3.use_instance_profile" = "false",
    "aws.s3.access_key" = "<iam_user_access_key>",
    "aws.s3.secret_key" = "<iam_user_secret_key>",
    "aws.s3.region" = "<aws_s3_region>"

AWS S3 用の StorageCredentialParams:

aws.s3.use_instance_profile​

必須: はい 説明: インスタンスプロファイルベースの認証方法と想定ロールベースの認証方法を有効にするかどうかを指定します。 有効な値: true および false。 デフォルト値: false。

aws.s3.iam_role_arn​

必須: いいえ 説明: AWS S3 バケットに対する権限を持つ IAM ロールの ARN です。想定ロールベースの認証方法を使用して AWS S3 にアクセスする場合、このパラメーターを指定する必要があります。

aws.s3.region​

必須: はい 説明: AWS S3 バケットが存在するリージョンです。例: us-west-1。

aws.s3.access_key​

必須: いいえ 説明: IAM ユーザーのアクセスキーです。IAM ユーザーベースの認証方法を使用して AWS S3 にアクセスする場合、このパラメーターを指定する必要があります。

aws.s3.secret_key​

必須: いいえ 説明: IAM ユーザーのシークレットキーです。IAM ユーザーベースの認証方法を使用して AWS S3 にアクセスする場合、このパラメーターを指定する必要があります。

AWS S3 へのアクセス認証方法の選択方法および AWS IAM コンソールでのアクセス制御ポリシーの構成方法については、 AWS S3 へのアクセス認証パラメーター を参照してください。

MetadataUpdateParams​

StarRocks が Iceberg メタデータのキャッシュを更新する方法に関する一連のパラメーターです。このパラメーターセットはオプションです。

v3.3.3 以降、StarRocks は 定期的なメタデータリフレッシュ戦略 をサポートしています。ほとんどの場合、MetadataUpdateParams を無視し、そのポリシーパラメーターを調整する必要はありません。これらのパラメーターのデフォルト値は、すぐに使用できるパフォーマンスを提供します。システム変数 plan_mode を使用して Iceberg メタデータキャッシュプランを調整できます。

パラメーターデフォルト説明
enable_iceberg_metadata_cachetrueIceberg 関連のメタデータ（Table Cache、Partition Name Cache、Manifest 内の Data File Cache および Delete Data File Cache を含む）をキャッシュするかどうか。
iceberg_manifest_cache_with_column_statisticsfalse列の統計をキャッシュするかどうか。
iceberg_manifest_cache_max_num100000キャッシュできる Manifest ファイルの最大数。
refresh_iceberg_manifest_min_length2 * 1024 * 1024Data File Cache のリフレッシュをトリガーする最小の Manifest ファイル長。

例​

以下の例は、使用するメタストアのタイプに応じて、Iceberg クラスターからデータをクエリするための Iceberg catalog iceberg_catalog_hms または iceberg_catalog_glue を作成します。ストレージタイプに一致するタブを選択してください。

AWS S3​

インスタンスプロファイルベースの資格情報を選択した場合​

  • Iceberg クラスターで Hive metastore を使用する場合、次のようなコマンドを実行します。

    CREATE EXTERNAL CATALOG iceberg_catalog_hms
    PROPERTIES
    (
        "type" = "iceberg",
        "iceberg.catalog.type" = "hive",
        "hive.metastore.uris" = "thrift://xx.xx.xx.xx:9083",
        "aws.s3.use_instance_profile" = "true",
        "aws.s3.region" = "us-west-2"
    );

  • Amazon EMR Iceberg クラスターで AWS Glue を使用する場合、次のようなコマンドを実行します。

    CREATE EXTERNAL CATALOG iceberg_catalog_glue
    PROPERTIES
    (
        "type" = "iceberg",
        "iceberg.catalog.type" = "glue",
        "aws.glue.use_instance_profile" = "true",
        "aws.glue.region" = "us-west-2",
        "aws.s3.use_instance_profile" = "true",
        "aws.s3.region" = "us-west-2"
    );
想定ロールベースの資格情報を選択した場合​

  • Iceberg クラスターで Hive metastore を使用する場合、次のようなコマンドを実行します。

    CREATE EXTERNAL CATALOG iceberg_catalog_hms
    PROPERTIES
    (
        "type" = "iceberg",
        "iceberg.catalog.type" = "hive",
        "hive.metastore.uris" = "thrift://xx.xx.xx.xx:9083",
        "aws.s3.use_instance_profile" = "true",
        "aws.s3.iam_role_arn" = "arn:aws:iam::081976408565:role/test_s3_role",
        "aws.s3.region" = "us-west-2"
    );

  • Amazon EMR Iceberg クラスターで AWS Glue を使用する場合、次のようなコマンドを実行します。

    CREATE EXTERNAL CATALOG iceberg_catalog_glue
    PROPERTIES
    (
        "type" = "iceberg",
        "iceberg.catalog.type" = "glue",
        "aws.glue.use_instance_profile" = "true",
        "aws.glue.iam_role_arn" = "arn:aws:iam::081976408565:role/test_glue_role",
        "aws.glue.region" = "us-west-2",
        "aws.s3.use_instance_profile" = "true",
        "aws.s3.iam_role_arn" = "arn:aws:iam::081976408565:role/test_s3_role",
        "aws.s3.region" = "us-west-2"
    );
IAM ユーザーベースの資格情報を選択した場合​

  • Iceberg クラスターで Hive metastore を使用する場合、次のようなコマンドを実行します。

    CREATE EXTERNAL CATALOG iceberg_catalog_hms
    PROPERTIES
    (
        "type" = "iceberg",
        "iceberg.catalog.type" = "hive",
        "hive.metastore.uris" = "thrift://xx.xx.xx.xx:9083",
        "aws.s3.use_instance_profile" = "false",
        "aws.s3.access_key" = "<iam_user_access_key>",
        "aws.s3.secret_key" = "<iam_user_access_key>",
        "aws.s3.region" = "us-west-2"
    );

  • Amazon EMR Iceberg クラスターで AWS Glue を使用する場合、次のようなコマンドを実行します。

    CREATE EXTERNAL CATALOG iceberg_catalog_glue
    PROPERTIES
    (
        "type" = "iceberg",
        "iceberg.catalog.type" = "glue",
        "aws.glue.use_instance_profile" = "false",
        "aws.glue.access_key" = "<iam_user_access_key>",
        "aws.glue.secret_key" = "<iam_user_secret_key>",
        "aws.glue.region" = "us-west-2",
        "aws.s3.use_instance_profile" = "false",
        "aws.s3.access_key" = "<iam_user_access_key>",
        "aws.s3.secret_key" = "<iam_user_secret_key>",
        "aws.s3.region" = "us-west-2"
    );

カタログの使用​

Iceberg catalog の表示​

現在の StarRocks クラスター内のすべての catalog をクエリするには、 SHOW CATALOGS を使用できます。

SHOW CATALOGS;

外部 catalog の作成ステートメントをクエリするには、 SHOW CREATE CATALOG を使用することもできます。次の例は、Iceberg catalog iceberg_catalog_glue の作成ステートメントをクエリします。

SHOW CREATE CATALOG iceberg_catalog_glue;

Iceberg Catalog とそのデータベースへの切り替え​

Iceberg catalog とそのデータベースに切り替えるには、次のいずれかの方法を使用できます。

  • 現在のセッションで Iceberg catalog を指定するには SET CATALOG を使用し、次にアクティブなデータベースを指定するには USE を使用します。

    -- 現在のセッションで指定された catalog に切り替えます。
    SET CATALOG <catalog_name>
    -- 現在のセッションでアクティブなデータベースを指定します。
    USE <db_name>

  • Iceberg catalog とそのデータベースに直接切り替えるには USE を使用します。

    USE <catalog_name>.<db_name>

Iceberg catalog の削除​

外部 catalog を削除するには、 DROP CATALOG を使用できます。

次の例は、Iceberg catalog iceberg_catalog_glue を削除します。

DROP Catalog iceberg_catalog_glue;

Iceberg テーブルのスキーマを表示​

Iceberg テーブルのスキーマを表示するには、次のいずれかの構文を使用できます。

  • スキーマを表示

    DESC[RIBE] <catalog_name>.<database_name>.<table_name>

  • CREATE ステートメントからスキーマと場所を表示

    SHOW CREATE TABLE <catalog_name>.<database_name>.<table_name>

Iceberg テーブルをクエリ​

  1. Iceberg クラスター内のデータベースを表示するには、 SHOW DATABASES を使用します。

    SHOW DATABASES FROM <catalog_name>

  2. Iceberg catalog とそのデータベースに切り替えます。

  3. 指定されたデータベース内の宛先テーブルをクエリするには、 SELECT を使用します。

    SELECT count(*) FROM <table_name> LIMIT 10

Iceberg データベースの作成​

StarRocks の内部 catalog と同様に、Iceberg catalog に対して CREATE DATABASE 権限を持っている場合、 CREATE DATABASE ステートメントを使用して、その Iceberg catalog にデータベースを作成できます。この機能は v3.1 以降でサポートされています。

ヒント

GRANT および REVOKE を使用して権限を付与および取り消すことができます。

Iceberg catalog に切り替え、次にその catalog に Iceberg データベースを作成するために次のステートメントを使用します。

CREATE DATABASE <database_name>
[PROPERTIES ("location" = "<prefix>://<path_to_database>/<database_name.db>/")]

location パラメーターを使用して、データベースを作成するファイルパスを指定できます。HDFS とクラウドストレージの両方がサポートされています。location パラメーターを指定しない場合、StarRocks は Iceberg catalog のデフォルトのファイルパスにデータベースを作成します。

prefix は使用するストレージシステムに基づいて異なります。

HDFS​

Prefix 値: hdfs

Google GCS​

Prefix 値: gs

Azure Blob Storage​

Prefix 値:

  • ストレージアカウントが HTTP 経由でのアクセスを許可する場合、prefix は wasb です。
  • ストレージアカウントが HTTPS 経由でのアクセスを許可する場合、prefix は wasbs です。

Azure Data Lake Storage Gen1​

Prefix 値: adl

Azure Data Lake Storage Gen2​

Prefix 値:

  • ストレージアカウントが HTTP 経由でのアクセスを許可する場合、prefix は abfs です。
  • ストレージアカウントが HTTPS 経由でのアクセスを許可する場合、prefix は abfss です。

AWS S3 または他の S3 互換ストレージ（例: MinIO）​

Prefix 値: s3

Iceberg データベースの削除​

StarRocks の内部データベースと同様に、Iceberg データベースに対して DROP 権限を持っている場合、 DROP DATABASE ステートメントを使用して、その Iceberg データベースを削除できます。この機能は v3.1 以降でサポートされています。空のデータベースのみを削除できます。

Iceberg データベースを削除すると、HDFS クラスターまたはクラウドストレージ上のデータベースのファイルパスはデータベースと共に削除されません。

Iceberg catalog に切り替え、次にその catalog に Iceberg データベースを削除するために次のステートメントを使用します。

DROP DATABASE <database_name>;

Iceberg テーブルの作成​

StarRocks の内部データベースと同様に、Iceberg データベースに対して CREATE TABLE 権限を持っている場合、 CREATE TABLE または [CREATE TABLE AS SELECT ../../sql-reference/sql-statements/table_bucket_part_index/CREATE_TABLE_AS_SELECT.mdELECT.md) ステートメントを使用して、その Iceberg データベースにテーブルを作成できます。この機能は v3.1 以降でサポートされています。

Iceberg catalog とそのデータベースに切り替え、次にそのデータベースに Iceberg テーブルを作成するために次の構文を使用します。

構文​

CREATE TABLE [IF NOT EXISTS] [database.]table_name
(column_definition1[, column_definition2, ...
partition_column_definition1,partition_column_definition2...])
[partition_desc]
[PROPERTIES ("key" = "value", ...)]
[AS SELECT query]

パラメーター​

column_definition​

column_definition の構文は次のとおりです。

col_name col_type [COMMENT 'comment']
注記

すべての非パーティション列はデフォルト値として NULL を使用する必要があります。つまり、テーブル作成ステートメントで各非パーティション列に対して DEFAULT "NULL" を指定する必要があります。さらに、パーティション列は非パーティション列の後に定義され、デフォルト値として NULL を使用することはできません。

partition_desc​

partition_desc の構文は次のとおりです。

PARTITION BY (par_col1[, par_col2...])

現在、StarRocks は identity transforms のみをサポートしており、これは StarRocks が各一意のパーティション値に対してパーティションを作成することを意味します。

注記

パーティション列は非パーティション列の後に定義される必要があります。パーティション列は FLOAT、DOUBLE、DECIMAL、および DATETIME を除くすべてのデータ型をサポートし、デフォルト値として NULL を使用することはできません。

PROPERTIES​

PROPERTIES で "key" = "value" 形式でテーブル属性を指定できます。 Iceberg テーブル属性 を参照してください。

次の表は、いくつかの主要なプロパティを説明しています。

location​

説明: Iceberg テーブルを作成するファイルパス。メタストアとして HMS を使用する場合、location パラメーターを指定する必要はありません。StarRocks は現在の Iceberg catalog のデフォルトのファイルパスにテーブルを作成します。メタストアとして AWS Glue を使用する場合:

  • テーブルを作成するデータベースに対して location パラメーターを指定している場合、テーブルに対して location パラメーターを指定する必要はありません。そのため、テーブルは所属するデータベースのファイルパスにデフォルト設定されます。
  • テーブルを作成するデータベースに対して location を指定していない場合、テーブルに対して location パラメーターを指定する必要があります。
file_format​

説明: Iceberg テーブルのファイル形式。Parquet 形式のみがサポートされています。デフォルト値: parquet。

compression_codec​

説明: Iceberg テーブルに使用される圧縮アルゴリズム。サポートされている圧縮アルゴリズムは SNAPPY、GZIP、ZSTD、および LZ4 です。デフォルト値: gzip。このプロパティは v3.2.3 で非推奨となり、それ以降のバージョンでは Iceberg テーブルにデータをシンクするために使用される圧縮アルゴリズムはセッション変数 connector_sink_compression_codec によって一元的に制御されます。

例​

  1. unpartition_tbl という名前の非パーティションテーブルを作成します。このテーブルは id と score の 2 つの列で構成されています。

    CREATE TABLE unpartition_tbl
    (
        id int,
        score double
    );

  2. partition_tbl_1 という名前のパーティションテーブルを作成します。このテーブルは action、id、および dt の 3 つの列で構成されており、そのうち id と dt はパーティション列として定義されています。

    CREATE TABLE partition_tbl_1
    (
        action varchar(20),
        id int,
        dt date
    )
    PARTITION BY (id,dt);

  3. 既存のテーブル partition_tbl_1 をクエリし、そのクエリ結果に基づいて partition_tbl_2 という名前のパーティションテーブルを作成します。partition_tbl_2 では、id と dt がパーティション列として定義されています。

    CREATE TABLE partition_tbl_2
    PARTITION BY (id, dt)
    AS SELECT * from employee;

Iceberg テーブルへのデータシンク​

StarRocks の内部テーブルと同様に、Iceberg テーブルに対して INSERT 権限を持っている場合、 INSERT ステートメントを使用して、StarRocks テーブルのデータをその Iceberg テーブルにシンクできます（現在、Parquet 形式の Iceberg テーブルのみがサポートされています）。この機能は v3.1 以降でサポートされています。

Iceberg catalog とそのデータベースに切り替え、次にそのデータベース内の Parquet 形式の Iceberg テーブルに StarRocks テーブルのデータをシンクするために次の構文を使用します。

構文​

INSERT {INTO | OVERWRITE} <table_name>
[ (column_name [, ...]) ]
{ VALUES ( { expression | DEFAULT } [, ...] ) [, ...] | query }

-- 指定されたパーティションにデータをシンクする場合、次の構文を使用します。
INSERT {INTO | OVERWRITE} <table_name>
PARTITION (par_col1=<value> [, par_col2=<value>...])
{ VALUES ( { expression | DEFAULT } [, ...] ) [, ...] | query }
注記

パーティション列は NULL 値を許可しません。したがって、Iceberg テーブルのパーティション列に空の値がロードされないようにする必要があります。

パラメーター​

INTO​

StarRocks テーブルのデータを Iceberg テーブルに追加します。

OVERWRITE​

StarRocks テーブルのデータで Iceberg テーブルの既存のデータを上書きします。

column_name​

データをロードしたい宛先列の名前。1 つ以上の列を指定できます。複数の列を指定する場合、カンマ (,) で区切ります。Iceberg テーブルに実際に存在する列のみを指定できます。また、指定した宛先列には Iceberg テーブルのパーティション列を含める必要があります。指定した宛先列は、StarRocks テーブルの列と順番に 1 対 1 でマッピングされます。宛先列名が何であっても関係ありません。宛先列が指定されていない場合、データは Iceberg テーブルのすべての列にロードされます。StarRocks テーブルの非パーティション列が Iceberg テーブルの任意の列にマッピングできない場合、StarRocks は Iceberg テーブル列にデフォルト値 NULL を書き込みます。INSERT ステートメントに含まれるクエリステートメントの戻り列タイプが宛先列のデータタイプと異なる場合、StarRocks は不一致の列に対して暗黙の変換を行います。変換が失敗した場合、構文解析エラーが返されます。

expression​

宛先列に値を割り当てる式。

DEFAULT​

宛先列にデフォルト値を割り当てます。

query​

Iceberg テーブルにロードされるクエリステートメントの結果。StarRocks がサポートする任意の SQL ステートメントである可能性があります。

PARTITION​

データをロードしたいパーティション。Iceberg テーブルのすべてのパーティション列をこのプロパティで指定する必要があります。このプロパティで指定するパーティション列は、テーブル作成ステートメントで定義したパーティション列と異なる順序であってもかまいません。このプロパティを指定する場合、column_name プロパティを指定することはできません。

例​

  1. partition_tbl_1 テーブルに 3 行のデータを挿入します。

    INSERT INTO partition_tbl_1
    VALUES
        ("buy", 1, "2023-09-01"),
        ("sell", 2, "2023-09-02"),
        ("buy", 3, "2023-09-03");

  2. 簡単な計算を含む SELECT クエリの結果を partition_tbl_1 テーブルに挿入します。

    INSERT INTO partition_tbl_1 (id, action, dt) SELECT 1+1, 'buy', '2023-09-03';

  3. partition_tbl_1 テーブルからデータを読み取る SELECT クエリの結果を同じテーブルに挿入します。

    INSERT INTO partition_tbl_1 SELECT 'buy', 1, date_add(dt, INTERVAL 2 DAY)
    FROM partition_tbl_1
    WHERE id=1;

  4. partition_tbl_2 テーブルの dt='2023-09-01' および id=1 の条件を満たすパーティションに SELECT クエリの結果を挿入します。

    INSERT INTO partition_tbl_2 SELECT 'order', 1, '2023-09-01';

    または

    INSERT INTO partition_tbl_2 partition(dt='2023-09-01',id=1) SELECT 'order';

  5. partition_tbl_1 テーブルの dt='2023-09-01' および id=1 の条件を満たすパーティション内のすべての action 列の値を close で上書きします。

    INSERT OVERWRITE partition_tbl_1 SELECT 'close', 1, '2023-09-01';

    または

    INSERT OVERWRITE partition_tbl_1 partition(dt='2023-09-01',id=1) SELECT 'close';

Iceberg テーブルの削除​

StarRocks の内部テーブルと同様に、Iceberg テーブルに対して DROP 権限を持っている場合、 DROP TABLE ステートメントを使用して、その Iceberg テーブルを削除できます。この機能は v3.1 以降でサポートされています。

Iceberg テーブルを削除すると、HDFS クラスターまたはクラウドストレージ上のテーブルのファイルパスとデータはテーブルと共に削除されません。

Iceberg テーブルを強制的に削除する場合（つまり、DROP TABLE ステートメントで FORCE キーワードを指定した場合）、HDFS クラスターまたはクラウドストレージ上のテーブルのデータはテーブルと共に削除されますが、テーブルのファイルパスは保持されます。

Iceberg catalog とそのデータベースに切り替え、次にそのデータベース内の Iceberg テーブルを削除するために次のステートメントを使用します。

DROP TABLE <table_name> [FORCE];

メタデータキャッシュの構成​

Iceberg クラスターのメタデータファイルは、AWS S3 や HDFS などのリモートストレージに保存されている場合があります。デフォルトでは、StarRocks はメモリ内に Iceberg メタデータをキャッシュします。クエリを高速化するために、StarRocks はメモリとディスクの両方にメタデータをキャッシュできる 2 レベルのメタデータキャッシングメカニズムを採用しています。初期クエリごとに、StarRocks はその計算結果をキャッシュします。以前のクエリと意味的に等価な後続のクエリが発行された場合、StarRocks は最初にそのキャッシュから要求されたメタデータを取得しようとし、キャッシュでメタデータがヒットしない場合にのみリモートストレージからメタデータを取得します。

StarRocks は、データをキャッシュおよび削除するために最も最近使用されたものを優先する（LRU）アルゴリズムを使用します。基本的なルールは次のとおりです。

  • StarRocks は最初にメモリから要求されたメタデータを取得しようとします。メモリでメタデータがヒットしない場合、StarRocks はディスクからメタデータを取得しようとします。StarRocks がディスクから取得したメタデータはメモリにロードされます。ディスクでもメタデータがヒットしない場合、StarRocks はリモートストレージからメタデータを取得し、取得したメタデータをメモリにキャッシュします。
  • StarRocks はメモリから削除されたメタデータをディスクに書き込みますが、ディスクから削除されたメタデータは直接破棄します。

v3.3.3 以降、StarRocks は 定期的なメタデータリフレッシュ戦略 をサポートしています。システム変数 plan_mode を使用して Iceberg メタデータキャッシュプランを調整できます。

Iceberg メタデータキャッシュに関する FE の設定​

enable_iceberg_metadata_disk_cache​
  • 単位: N/A
  • デフォルト値: false
  • 説明: ディスクキャッシュを有効にするかどうかを指定します。
iceberg_metadata_cache_disk_path​
  • 単位: N/A
  • デフォルト値: StarRocksFE.STARROCKS_HOME_DIR + "/caches/iceberg"
  • 説明: ディスク上のキャッシュされたメタデータファイルの保存パス。
iceberg_metadata_disk_cache_capacity​
  • 単位: バイト
  • デフォルト値: 2147483648、2 GB に相当
  • 説明: ディスク上で許可されるキャッシュされたメタデータの最大サイズ。
iceberg_metadata_memory_cache_capacity​
  • 単位: バイト
  • デフォルト値: 536870912、512 MB に相当
  • 説明: メモリ内で許可されるキャッシュされたメタデータの最大サイズ。
iceberg_metadata_memory_cache_expiration_seconds​
  • 単位: 秒
  • デフォルト値: 86500
  • 説明: メモリ内のキャッシュエントリが最後にアクセスされてから期限切れになるまでの時間。
iceberg_metadata_disk_cache_expiration_seconds​
  • 単位: 秒
  • デフォルト値: 604800、1 週間に相当
  • 説明: ディスク上のキャッシュエントリが最後にアクセスされてから期限切れになるまでの時間。
iceberg_metadata_cache_max_entry_size​
  • 単位: バイト
  • デフォルト値: 8388608、8 MB に相当
  • 説明: キャッシュできるファイルの最大サイズ。このパラメーターの値を超えるサイズのファイルはキャッシュできません。クエリがこれらのファイルを要求する場合、StarRocks はリモートストレージからそれらを取得します。
enable_background_refresh_connector_metadata​
  • 単位: -
  • デフォルト値: true
  • 説明: 定期的な Iceberg メタデータキャッシュのリフレッシュを有効にするかどうか。これが有効になると、StarRocks は Iceberg クラスターのメタストア（Hive Metastore または AWS Glue）をポーリングし、頻繁にアクセスされる Iceberg catalog のキャッシュされたメタデータをリフレッシュしてデータの変更を認識します。true は Iceberg メタデータキャッシュのリフレッシュを有効にし、false はそれを無効にします。
background_refresh_metadata_interval_millis​
  • 単位: ミリ秒
  • デフォルト値: 600000
  • 説明: 2 つの連続した Iceberg メタデータキャッシュリフレッシュの間隔。- 単位: ミリ秒。
background_refresh_metadata_time_secs_since_last_access_sec​
  • 単位: 秒
  • デフォルト値: 86400
  • 説明: Iceberg メタデータキャッシュリフレッシュタスクの有効期限。アクセスされた Iceberg catalog に対して、指定された時間を超えてアクセスされていない場合、StarRocks はそのキャッシュされたメタデータのリフレッシュを停止します。アクセスされていない Iceberg catalog に対して、StarRocks はそのキャッシュされたメタデータをリフレッシュしません。

付録: 定期的なメタデータリフレッシュ戦略​

  • 大量のメタデータに対する分散プラン

    大量のメタデータを効果的に処理するために、StarRocks は複数の BE および CN ノードを使用して分散アプローチを採用しています。この方法は、現代のクエリエンジンの並列計算能力を活用し、マニフェストファイルの読み取り、解凍、フィルタリングなどのタスクを複数のノードに分散させます。これにより、これらのマニフェストファイルを並列に処理することで、メタデータの取得にかかる時間が大幅に短縮され、ジョブプランニングが迅速化されます。これは、多数のマニフェストファイルを含む大規模なクエリに特に有益であり、単一ポイントのボトルネックを排除し、全体的なクエリ実行効率を向上させます。

  • 少量のメタデータに対するローカルプラン

    小規模なクエリでは、マニフェストファイルの繰り返しの解凍と解析が不要な遅延を引き起こす可能性があるため、異なる戦略が採用されます。StarRocks は、特に Avro ファイルのデシリアライズされたメモリオブジェクトをキャッシュすることで、この問題に対処します。これらのデシリアライズされたファイルをメモリに保存することで、後続のクエリでは解凍と解析の段階をバイパスできます。このキャッシングメカニズムにより、必要なメタデータに直接アクセスでき、取得時間が大幅に短縮されます。その結果、システムはより応答性が高くなり、高いクエリ要求やマテリアライズドビューの書き換えニーズにより適しています。

  • 適応型メタデータ取得戦略（デフォルト）

    StarRocks は、FE および BE/CN ノードの数、CPU コア数、現在のクエリに必要なマニフェストファイルの数など、さまざまな要因に基づいて適切なメタデータ取得方法を自動的に選択するように設計されています。この適応型アプローチにより、メタデータ関連のパラメーターを手動で調整することなく、システムが動的にメタデータ取得を最適化します。これにより、StarRocks はシームレスなエクスペリエンスを提供し、分散プランとローカルプランのバランスを取り、さまざまな条件下で最適なクエリパフォーマンスを実現します。

システム変数 plan_mode を使用して Iceberg メタデータキャッシュプランを調整できます。