Lindorm:列指向データへのアクセス

背景情報

Lindorm 列指向ストレージは、列指向の分散ストレージサービスです。列指向ストレージは、車載インターネット (IoV)、モノのインターネット (IoT)、注文、ログなどのシナリオで大量の半構造化データと構造化データを格納するのに適しています。列指向ストレージは、次のコア機能を提供します。

• コンピューティングと分析

  Lindorm コンピュートエンジンは、列指向データにアクセスして、インタラクティブな分析とオンラインコンピューティングを実行できます。列指向ストレージは、データ分散機能と豊富なインデックス機能を提供し、計算プロセスにおけるデータの位置特定と配置を効果的に高速化できます。SQL ステートメントを使用して、大量の主キーデータを追加、削除、変更、およびクエリできます。

• 高スループット

  列指向ストレージは水平方向のスケーリングをサポートし、1 分あたりテラバイトのデータを読み書きする機能を提供します。これにより、IoV データの迅速なインポート、モデル トレーニング データセット アクセス、大規模なレポート分析と生成などの高スループット データシナリオに適しています。

• 費用対効果

  Lindorm は、列指向の高圧縮率アルゴリズム、高密度低コストメディア、ホットデータとコールドデータの分離、圧縮エンコーディング、コールドデータアーカイブストレージなどのテクノロジーを実装しています。自己管理型ストレージと比較して、Lindorm 列指向ストレージはストレージコストを大幅に削減し、大量のデータを低コストでアーカイブおよび保存できます。

• 高可用性

  イレージャーコーディングなどのテクノロジーを使用することにより、Lindorm 列指向ストレージは分散データセットの高可用性を確保し、単一障害点 (SPOF) のリスクを排除します。

• オープンソースサービスとの互換性

  列指向ストレージは、Iceberg API などの複数のオープンソース標準 API と互換性があります。列指向ストレージは、Spark や Flink などのコンピューティングエンジンにも接続できます。このようにして、列指向ストレージを主流のデータエコシステムにシームレスに統合できます。

• ホットデータとコールドデータの分離

  ビジネス要件に基づいて、ホットデータとコールドデータを異なるストレージメディアに保存できます。これにより、コールドデータへのアクセスによって発生するパフォーマンスオーバーヘッドを削減しながら、ストレージコストを効果的に削減できます。

前提条件

• 注意事項 をお読みください。

• ジョブモードに応じて、次の操作が完了していることを確認してください。

  • JDBC ジョブ: アプリケーション開発で JDBC を使用する。

  • JAR ジョブ: Java でジョブを作成する。

  • Python ジョブ: Python でジョブを作成する。

• コールドデータとホットデータの分離機能を使用する場合は、Capacity ストレージが有効になっていることを確認してください。詳細については、「Capacity ストレージを有効にする」をご参照ください。

機能説明

DDL

DML

ホットデータとコールドデータのストレージ

ほとんどの場合、頻繁にアクセスされるデータは高 パフォーマンス ストレージに保存され、アクセス頻度の低い履歴データは低コストストレージに移行されます。これにより、ストレージコストを削減し、 パフォーマンス を向上させることができます。Lindorm は、L1、L2、L3 の 3 つのレベルでホットデータとコールドデータの分離をサポートしています。ビジネス要件に基づいて、ホットデータとコールドデータ間の変換ポリシーを開発できます。データレイクサービスを使用して、ホットデータストレージとコールドデータストレージ間でデータを自動的にダンプできます。これにより、主要サービスの応答時間を延長することなく、ストレージコストを効果的に管理できます。

パラメーター

列指向テーブルを作成するときは、コールドまたはホットストレージ (CHS) 属性を定義して、列指向テーブルの時間パーティションに基づいてコールドストレージとホットストレージ間でデータをダンプする方法を指定できます。次の表に、CHS パラメーターの構成方法を示します。

例

• 例 1:

  table0 という名前のテーブルを作成します。パーティションフィールド名は、年、月、日です。指定したホットデータとコールドデータの分離ポリシーに基づいて、1 か月 (2,592,000 秒) 前に保存されたデータは自動的に Capacity ストレージにダンプされます。次のステートメントを実行してテーブルを作成できます。

  CREATE TABLE table0 (col0 INT,year STRING,month STRING,day STRING)
  PARTITIONED BY  (year,month)
  TBLPROPERTIES 
  'CHS'='2592000',
  'CHS_L2'='storagetype=CAPACITY_CLOUD_STORAGE',
  'CHS_EXP'='toSec(year,yyyy,month,MM,day,dd)'
  );

• 例 2:

  table0 のホットデータとコールドデータの分離ポリシーを変更します。変更後、1 か月 (2,592,000 秒) 前に保存されたデータは自動的に Capacity ストレージにダンプされ、3 か月 (5,184,000 秒) 前に保存されたデータは自動的にアーカイブストレージにダンプされます。次のステートメントを実行してテーブルを更新できます。

  ALTER TABLE table0
  SET TBLPROPERTIES (
  'CHS'='2592000,5184000',
  'CHS_L2'='storagetype=CAPACITY_CLOUD_STORAGE',
  'CHS_L3'='storagetype=CLOUD_ARCHIVE_STORAGE',
  'CHS_EXP'='toSec(year,yyyy,month,MM,day,dd)'
  );

• 例 3:

  table1 という名前のテーブルを作成します。パーティションフィールド名は dt です。例: 2020/12/1。指定したホットデータとコールドデータの分離ポリシーに基づいて、1 か月 (2,592,000 秒) 前に保存されたデータは自動的に Capacity ストレージにダンプされ、3 か月 (5,184,000 秒) 前に保存されたデータは自動的にアーカイブストレージにダンプされます。次のステートメントを実行してテーブルを作成できます。

  CREATE TABLE table1 (col0 INT,dt STRING)
  PARTITIONED BY  (dt)
  TBLPROPERTIES (
  'CHS'='2592000,5184000',
  'CHS_L2'='storagetype=CAPACITY_CLOUD_STORAGE',
  'CHS_L3'='storagetype=CLOUD_ARCHIVE_STORAGE',
  'CHS_EXP'='toSec(dt,yyyy/MM/dd)'
  );

注意事項

• テーブルを作成するときに CHS パラメーターを指定できます。ホットデータとコールドデータの分離ポリシーを変更する場合は、ALTER TABLE ...SET TBLPROPERTIES... ステートメントを実行できます。

• CHS パラメーターを誤って指定した場合、テーブルは予期どおりに作成および更新できますが、コールドストレージとホットストレージ間でデータを自動的にダンプすることはできません。

• ホットデータとコールドデータのダンプは非同期モードでトリガーされます。データダンプ中およびデータダンプ後もデータアクセスは影響を受けませんが、アクセス パフォーマンス はストレージメディアによって異なる場合があります。

• 列指向テーブルの時間パーティションに基づいてのみ、ホットデータとコールドデータの分離ポリシーを実装できます。

ベストプラクティス

次の方法を使用して、データクエリまたはコンピューティングを高速化できます。

主キーを指定する

大量のデータセットがテーブルに保存されている場合は、主キーを指定してクエリを高速化できます。主キーデータの範囲が小さいほど、高速化の結果が向上します。

この例では、次のステートメントを実行してサンプルテーブルを作成します。

USE lindorm_columnar;
CREATE TABLE orders (
o_orderkey       INT NOT NULL,
o_custkey        INT,
o_orderstatus    STRING,
o_totalprice     DOUBLE,
o_orderdate      STRING,
o_orderpriority  STRING,
o_clerk          STRING,
o_shippriority   INT,
o_comment        STRING)
PARTITIONED BY (bucket(1024,o_orderkey))
TBLPROPERTIES(
'primary-key' = 'o_orderkey');           

• 例 1:

  USE lindorm_columnar;
  SELECT * FROM orders WHERE o_orderkey=18394;

• 例 2:

  USE lindorm_columnar;
  SELECT count(*) FROM orders WHERE o_orderkey>100000 AND o_orderkey<200000;

• 例 3:

  USE lindorm_columnar;
  SELECT count(*) FROM orders WHERE o_orderkey>100000;

パーティションを追加する

Lindorm の列指向ストレージエンジンでは、パーティションは互いに物理的に分離されています。パーティションを追加して、データクエリを高速化できます。

この例では、次のステートメントを実行してサンプルテーブルを作成します。

USE lindorm_columnar;
CREATE TABLE orders (
o_orderkey       INT NOT NULL,
o_custkey        INT,
o_orderstatus    STRING,
o_totalprice     DOUBLE,
o_orderdate      STRING NOT NULL,
o_orderpriority  STRING,
o_clerk          STRING,
o_shippriority   INT,
o_comment        STRING)
PARTITIONED BY (o_orderdate, bucket(1024,o_orderkey))
TBLPROPERTIES(
'primary-key' = 'o_orderdate,o_orderkey');

• 例 1:

  USE lindorm_columnar;
  SELECT o_orderdate, count(*) FROM orders WHERE o_orderdate='2022-01-01' GROUP BY o_orderdate;

• 例 2:

  USE lindorm_columnar;
  SELECT o_orderdate, count(*) FROM orders WHERE o_orderdate>='2022-01-01' AND o_orderdate<='2022-01-07' GROUP BY o_orderdate;

CREATE TABLE mydb.mytable (
  id INT NOT NULL, 
  city STRING NOT NULL, 
  name STRING, 
  score INT)
partitioned by (city, bucket(4, id))
tblproperties('primary-key' = 'id,city');

ALTER TABLE mydb.mytable SET TBLPROPERTIES ('read.scan-major-rewritten-files-only' = true);

USE lindorm_columnar;
CREATE TABLE orders (
o_orderkey       INT NOT NULL,
o_custkey        INT,
o_orderstatus    STRING,
o_totalprice     DOUBLE ,
o_orderdate      STRING ,
o_orderpriority  STRING,
o_clerk          STRING,
o_shippriority   INT,
o_comment        STRING)
PARTITIONED BY (bucket(1024,o_orderkey))
TBLPROPERTIES(
'primary-key' = 'o_orderkey',
'read.scan-major-rewritten-files-only' = 'true');

ALTER TABLE orders WRITE ORDERED BY o_shippriority,o_totalprice;

CALL lindorm_columnar.system.rewrite_data_files(table => 'orders');