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

Iceberg catalog

ヒント

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

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

  • Iceberg に保存されたデータを直接クエリし、手動でテーブルを作成する必要がありません。
  • INSERT INTO または非同期マテリアライズドビュー（v2.5 以降でサポート）を使用して、Iceberg に保存されたデータを処理し、StarRocks にデータをロードします。
  • StarRocks 上で Iceberg データベースやテーブルを作成または削除する操作を行ったり、StarRocks テーブルから Parquet 形式の Iceberg テーブルにデータをシンクすることができます。この機能は 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 テーブル: v3.1 以降でサポートされ、これらの v2 テーブルに対するクエリは位置削除をサポートします。v3.1.10、v3.2.5、v3.3 およびそれ以降のバージョンでは、v2 テーブルに対するクエリは等価削除もサポートします。
ORCZLIB, SNAPPY, LZO, LZ4, ZSTD, NO_COMPRESSION
  • v1 テーブル: サポートされています。
  • v2 テーブル: 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_catalog_hms または iceberg_catalog_glue という名前の Iceberg catalog を作成し、Iceberg クラスターからデータをクエリする例です。ストレージタイプに応じたタブを選択してください。

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"
    );

catalog の使用​

Iceberg catalog の表示​

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

SHOW CATALOGS;

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

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_glue という名前の Iceberg catalog を削除します。

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 権限を持っている場合、その Iceberg catalog 内でデータベースを作成するために CREATE DATABASE ステートメントを使用できます。この機能は 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 権限を持っている場合、その Iceberg データベースを削除するために DROP DATABASE ステートメントを使用できます。この機能は v3.1 以降でサポートされています。空のデータベースのみを削除できます。

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

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

DROP DATABASE <database_name>;

Iceberg テーブルの作成​

StarRocks の内部データベースと同様に、Iceberg データベースに対して CREATE TABLE 権限を持っている場合、その Iceberg データベース内でテーブルを作成するために CREATE TABLE または CREATE TABLE AS SELECT ステートメントを使用できます。この機能は 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 権限を持っている場合、StarRocks テーブルのデータをその Iceberg テーブルにシンクするために INSERT ステートメントを使用できます（現在は 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. 2つの条件 dt='2023-09-01' および id=1 を満たす partition_tbl_2 テーブルのパーティションに 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 権限を持っている場合、その Iceberg テーブルを削除するために DROP TABLE ステートメントを使用できます。この機能は 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 メタデータキャッシングプランを調整できます。