データが経過すると、クエリは最新のレコードから歴史的アーカイブへと移行します。すべてのデータをローカルディスク上に保持するのはコストが高く、一方ですべてを HDFS に移動するとクエリパフォーマンスが低下します。E-MapReduce (EMR) ClickHouse クラスターは、Hadoop 分散ファイルシステム (HDFS) を活用した階層型ストレージをサポートすることでこの課題を解決します。すなわち、最新のデータは高速なクエリのためにローカルディスク上に保持され、古いデータは自動的に HDFS へ移動してストレージコストを削減します。この処理は、読み取りおよび書き込みパフォーマンスに影響を与えません。
前提条件
開始する前に、以下の条件を満たしていることを確認してください。
-
EMR V5.5.0 以降の ClickHouse クラスター。詳細については、「ClickHouse クラスターの作成」をご参照ください。
-
ClickHouse クラスターと同じ仮想プライベートクラウド (VPC) 内にデプロイされた HDFS サービス(例:EMR Hadoop クラスター内の HDFS サービス)
-
HDFS サービスに対する読み取りおよび書き込み権限
制限事項
HDFS を使用したホット/コールドデータ分離は、EMR V5.5.0 以降の ClickHouse クラスターでのみサポートされます。
基本概念
ストレージ階層の理解は、以降の手順で示される構成コードを正しく読み取るうえで重要です。
| 概念 | 説明 |
|---|---|
| ディスク | ClickHouse に登録されたストレージデバイス — ローカルディスクまたは HDFS などのリモートストアを含みます。 |
| ボリューム | 順序付きのディスクの集合体。データはストレージポリシーのルールに従ってボリューム間を移動します。 |
| ストレージポリシー | 名前付きのボリュームの集合体で、ボリューム間のデータ移動を制御するルール(生存時間 (TTL) の有効期限など)を含みます。 |
本ガイドでは、HDFS ディスクを定義し、ローカルディスクを local ボリュームとしてグループ化し、HDFS ディスクを remote ボリュームとしてグループ化した後、指定された期間経過後にデータを local から remote へ移動する TTL ルールを適用します。
ステップ 1:EMR コンソールで HDFS ディスクを追加
-
ClickHouse サービスの [構成] タブに移動します。
-
EMR コンソールにログインします。EMR コンソール の左側のナビゲーションウィンドウで、[EMR On ECS] をクリックします。
-
上部のナビゲーションバーで、クラスターが配置されているリージョンを選択し、リソースグループを選択します。
-
[EMR on ECS] ページで、対象のクラスターを見つけ、[操作] 列の [サービス] をクリックします。
-
[サービス] タブで、ClickHouse セクションの [構成] をクリックします。
-
-
[server-metrika] タブをクリックします。
-
storage_configurationパラメーターを更新します。-
disks内に HDFS ディスクのエントリを追加します:<disk_hdfs> <type>hdfs</type> <endpoint>hdfs://${your-hdfs-url}</endpoint> <min_bytes_for_seek>1048576</min_bytes_for_seek> <thread_pool_size>16</thread_pool_size> <objects_chunk_size_to_delete>1000</objects_chunk_size_to_delete> </disk_hdfs>パラメーター 必須 説明 disk_hdfs はい ディスクの名前。必要に応じてカスタマイズ可能です。 type はい ディスクタイプ。必ず hdfs を指定してください。 endpoint はい HDFS サービスのエンドポイント(通常は NameNode のアドレス)。NameNode が高可用性 (HA) モードで実行されている場合、ポート番号は通常 8020 です。それ以外の場合は 9000 です。 min_bytes_for_seek いいえ 最小の正のシークオフセット。実際のオフセットがこの値より小さい場合、ClickHouse はシークではなく逐次読み取りを行います。デフォルト値:1048576。 thread_pool_size いいえ このディスク上で復元要求を処理するために使用されるスレッド数。デフォルト値:16。 objects_chunk_size_to_delete いいえ 単一のバッチで削除される HDFS ファイルの最大数。デフォルト値:1000。 -
policies内に、ローカルディスクをlocalボリュームに、HDFS ディスクをremoteボリュームにマッピングするストレージポリシーを追加します:<hdfs_ttl> <volumes> <local> <!-- 現在デフォルトストレージポリシーを使用しているすべてのディスクを追加します。 --> <disk>disk1</disk> <disk>disk2</disk> <disk>disk3</disk> <disk>disk4</disk> </local> <remote> <disk>disk_hdfs</disk> </remote> </volumes> <move_factor>0.2</move_factor> </hdfs_ttl>説明既存のデフォルトストレージポリシーにこのポリシーを追加することもでき、新規に作成する必要はありません。
-
-
構成を保存します。
-
[保存] をクリックします。
-
ダイアログボックスで実行理由を入力し、[構成の保存と配信] を有効化して、[保存] をクリックします。
-
-
クライアント構成をデプロイします。
-
[構成] タブで、[クライアント構成のデプロイ] をクリックします。
-
ダイアログボックスで実行理由を入力し、[OK] をクリックします。
-
[確認] ダイアログボックスで、[OK] をクリックします。
-
ステップ 2:構成の検証
SSH 経由で ClickHouse クラスターにログインします。詳細については、「クラスターへのログイン」をご参照ください。
-
ClickHouse クライアントを起動します:
clickhouse-client -h core-1-1 -m説明core-1-1は、ログインしたコアノードの名前に置き換えてください。クラスターに複数のコアノードがある場合は、いずれか 1 つを選択できます。 -
HDFS ディスクが
system.disksに表示されることを確認します:SELECT * FROM system.disks;出力結果に、
nameがdisk_hdfsで、typeがhdfsである行が含まれている場合、構成は正しく設定されています:┌─name─────┬─path─────────────────────────────────┬───────────free_space─┬──────────total_space─┬─keep_free_space─┬─type──┐ │ default │ /var/lib/clickhouse/ │ 83868921856 │ 84014424064 │ 0 │ local │ │ disk1 │ /mnt/disk1/clickhouse/ │ 83858436096 │ 84003938304 │ 10485760 │ local │ │ disk2 │ /mnt/disk2/clickhouse/ │ 83928215552 │ 84003938304 │ 10485760 │ local │ │ disk3 │ /mnt/disk3/clickhouse/ │ 83928301568 │ 84003938304 │ 10485760 │ local │ │ disk4 │ /mnt/disk4/clickhouse/ │ 83928301568 │ 84003938304 │ 10485760 │ local │ │ disk_hdfs│ /var/lib/clickhouse/disks/disk_hdfs/ │ 18446744073709551615 │ 18446744073709551615 │ 0 │ hdfs │ └──────────┴──────────────────────────────────────┴──────────────────────┴──────────────────────┴─────────────────┴───────┘ -
hdfs_ttlストレージポリシーがsystem.storage_policiesに表示されることを確認します:SELECT * FROM system.storage_policies;出力結果に、
hdfs_ttlに関する 2 行(localボリューム用とremoteボリューム用)が含まれている場合、構成は正しく設定されています:┌─policy_name──┬─volume_name─┬─volume_priority─┬─disks──────────────────────────────┬─volume_type─┬─max_data_part_size─┬─move_factor─┬─prefer_not_to_merge─┐ │ default │ single │ 1 │ ['disk1','disk2','disk3','disk4'] │ JBOD │ 0 │ 0 │ 0 │ │ hdfs_ttl │ local │ 1 │ ['disk1','disk2','disk3','disk4'] │ JBOD │ 0 │ 0.2 │ 0 │ │ hdfs_ttl │ remote │ 2 │ ['disk_hdfs'] │ JBOD │ 0 │ 0.2 │ 0 │ └──────────────┴─────────────┴─────────────────┴────────────────────────────────────┴─────────────┴────────────────────┴─────────────┴─────────────────────┘
ステップ 3:テーブルへのホット/コールド分離の適用
既存のテーブルを対象とするか、新規テーブルを作成するかに応じて、以下のいずれかの方法を選択してください。
既存のテーブルへの適用
-
テーブルの現在のストレージポリシーを確認します:
SELECT storage_policy FROM system.tables WHERE database = '<database_name>' AND name = '<table_name>';出力結果に
defaultポリシーが表示される場合、テーブルのすべてのデータはローカルディスク上に格納されています。次のステップに進み、リモートボリュームを追加してください。 -
EMR コンソールで、
remoteボリュームをstorage_configuration内のデフォルトストレージポリシーに追加します:<default> <volumes> <single> <disk>disk1</disk> <disk>disk2</disk> <disk>disk3</disk> <disk>disk4</disk> </single> <!-- このリモートボリュームを追加します。 --> <remote> <disk>disk_hdfs</disk> </remote> </volumes> <!-- ポリシーに複数のボリュームが含まれる場合に必須です。 --> <move_factor>0.2</move_factor> </default> -
テーブルの TTL を変更し、5 分以上経過したデータを
remoteボリュームへ移動します:ALTER TABLE <yourDataName>.<yourTableName> MODIFY TTL toStartOfMinute(addMinutes(t, 5)) TO VOLUME 'remote'; -
データパーツがボリューム間で分散されていることを確認します:
SELECT partition, name, path FROM system.parts WHERE database = '<yourDataName>' AND table = '<yourTableName>' AND active = 1;ローカルディスク (
/mnt/disk{1..4}/clickhouse/...) と HDFS メタデータパス (/var/lib/clickhouse/disks/disk_hdfs/...) の両方にパスが表示される場合、分離が正常に機能しています。TTL ウィンドウ内のホットデータはローカルディスクに残り、TTL を過ぎたコールドデータは HDFS へ移動します。出力例:┌─partition───────────┬─name─────────────────┬─path──────────────────────────────────────────────────────────────────────────────────────────────────┐ │ 2022-01-12 11:30:00 │ 1641958200_1_96_3 │ /var/lib/clickhouse/disks/disk_hdfs/store/156/156008ff-41bf-460c-8848-e34fad88c25d/1641958200_1_96_3/ │ │ 2022-01-12 11:35:00 │ 1641958500_97_124_2 │ /mnt/disk3/clickhouse/store/156/156008ff-41bf-460c-8848-e34fad88c25d/1641958500_97_124_2/ │ │ 2022-01-12 11:35:00 │ 1641958500_125_152_2 │ /mnt/disk4/clickhouse/store/156/156008ff-41bf-460c-8848-e34fad88c25d/1641958500_125_152_2/ │ │ 2022-01-12 11:35:00 │ 1641958500_153_180_2 │ /mnt/disk1/clickhouse/store/156/156008ff-41bf-460c-8848-e34fad88c25d/1641958500_153_180_2/ │ │ 2022-01-12 11:35:00 │ 1641958500_181_186_1 │ /mnt/disk4/clickhouse/store/156/156008ff-41bf-460c-8848-e34fad88c25d/1641958500_181_186_1/ │ │ 2022-01-12 11:35:00 │ 1641958500_187_192_1 │ /mnt/disk3/clickhouse/store/156/156008ff-41bf-460c-8848-e34fad88c25d/1641958500_187_192_1/ │ └─────────────────────┴──────────────────────┴───────────────────────────────────────────────────────────────────────────────────────────────────────┘
ホット/コールド分離を備えた新規テーブルの作成
テーブル作成時に、hdfs_ttl ストレージポリシーと TTL ... TO VOLUME 'remote' 句を指定します。
構文
CREATE TABLE <yourDataName>.<yourTableName> [ON CLUSTER cluster_emr]
(
column1 Type1,
column2 Type2,
...
)
ENGINE = MergeTree() -- Replicated*MergeTree 型もサポートされます。
PARTITION BY <yourPartitionKey>
ORDER BY <yourPartitionKey>
TTL <yourTtlKey> TO VOLUME 'remote'
SETTINGS storage_policy = 'hdfs_ttl';
例
以下のテーブルでは、過去 5 分以内のデータをローカルディスク上に保持し、5 分経過後に HDFS 上の remote ボリュームへ移動します。
CREATE TABLE test.test
(
`id` UInt32,
`t` DateTime
)
ENGINE = MergeTree()
PARTITION BY toStartOfFiveMinute(t)
ORDER BY id
TTL toStartOfMinute(addMinutes(t, 5)) TO VOLUME 'remote'
SETTINGS storage_policy = 'hdfs_ttl';
追加パラメーター
以下のオプションパラメーターにより、レプリケーション動作をさらに細かく制御できます。
サーバー設定
merge_tree.allow_remote_fs_zero_copy_replication:Replicated\*MergeTree エンジン向けのゼロコピー・レプリケーションを有効にするには、true を設定します。ClickHouse は、HDFS ディスクを指すメタデータをレプリケートし、ClickHouse クラスター内で同一シャードに対して複数のメタデータレプリカを生成します。
[server-users]
profile.${your-profile-name}.hdfs_replication:HDFS へ書き込まれるデータレプリカの数を制御します。