Alibaba Cloud ApsaraDB for ClickHouse Introduction

Transcript

1. Alibaba Cloud ApsaraDB for ClickHouse紹介 2021/09/30 Hironobu Ohara
2. 内容についての注意点 2 • 本資料は2021年9月30日時点でのサービス内容、SLA、価格についてご説明になります。 最新の情報はAlibaba Cloud公式サイト（ https://www.alibabacloud.com/ ）にて ご確認ください。 • 資料内容とAlibaba Cloud公式サイトに相違があった場合、Alibaba Cloud公式サイトを 優先させていただきます。
3. Alibaba Cloud データベースサービスポートフォリオ 3 カテゴリ データベースタイプ Alibaba Cloud プロダクトサービス 用途例 CDDC データベース サービスクラスター 複数のデータベースクラスター で運用する大規模なOLTP OLTP リレーショナル データベース リテール、eコマース、EPR、 ゲーム、金融、Web、etc NoSQL インメモリ Key-Value チャット、セッションストア、ショッ ピングカート、IoT NoSQL ドキュメント ゲーム、Webアプリ、大量 データ分析、データハブ NoSQL ワイドカラム 予約システムなど、トランザク ションの多い処理 NoSQL グラフ ソーシャル、ネットワーク、コン テンツ、不正検知、事象分析 NoSQL 時系列 IoT、産業向け監視と管理、 アプリケーション監視 OLAP MPP 大規模データのリアルタイム分 析、インサイト分析 OLAP サーバレス OSSデータ分析、テーブルスト ア分析および関連付け分析 Utility Tools データ管理・運用 マイグレーション、バックアップ、 データのトレースとロールバック ApsaraDB RDS for MySQL ApsaraDB RDS for PostgreSQL ApsaraDB RDS for SQLServer ApsaraDB for PolarDB Distributed Relational Database Service ApsaraDB RDS for MariaDB ApsaraDB for OceanBase ApsaraDB for Redis ApsaraDB for Memcache Table Store ApsaraDB for HBase ApsaraDB for MongoDB ApsaraDB for Cassandra GraphDB Time Series Database AnalyticDB for MySQL AnalyticDB for PostgreSQL ClickHouse Data Lake Analytics Database Management Advanced Database & Application Migration Database Backup Data Transmission Service Database Gateway Database Autonomy Service 2021/09/30時点 ApsaraDB for MyBase
4. 4 ApsaraDB for ClickHouseとは
5. Yandex社がもたらした技術 5 https://metrica.yandex.com/about JavaScriptによるWeb解析ツール「 Yandex.Metrika 」をリリース →外部ユーザーがサイトにアクセスして、その行動を分析しながら、 コンバージョン拡張、ユーザーアクセス増加など施策を実施
6. ClickHouseが登場する前にYandexが抱えていた課題 6 2009年 2010年 2011年 2012年 データ量増加に伴う、 書き込み処理の負荷大 サイト訪問イベント、購入商品と金額など、 複雑なSQLクエリができない 分析や集計のために、データを区切ったり 別々のテーブルへ区切ることが出来ない
7. データは重力（Data Gravity） 7
8. Yandex.Metrikaのためのサービス基盤 8 データ量が増えても、書き込み処理は 一切低下しないアーキテクチャ 列指向でありながら、複雑なSQLクエリに 素早く対応できるように対応 データを効率よく高圧縮し格納するため、 別々のテーブル/データベース区切りは不要  大量のデータをリアルタイムで取り込み  高速SQLクエリ処理  複雑なSQLクエリをサポート  Shard nothingアーキテクチャ  効率的なSIMDとベクトル化で実行  数PBへスケーリングが可能  MySQLサポート  オープンソース a b c d ※ClickHouseのiconは列指向をイメージ https://presentations.clickhouse.tech/meetup40/introd uction/#13
9. ClickHouseとは 9 ロシアの大手インターネット企業の Yandex 社がオープンソースとして開発した、 非集計データを含む大量のデータを安定的かつ継続しながら集計といった リアルタイム分析を支える列指向の分散型データベースです。 x500 大量のデータの高速インポートを提供 書き込み処理はMySQLより500倍速い。 20 Engines 可視化、集計、リアルタイム更新処理など 様々なシナリオに応じて20種類以上の テーブルエンジンを提供。 Storage1/10 特殊なテーブル構造により、 Storage保存量を10分の１へ圧縮。 MySQLと 同じSQL構文 MySQLと同じSQL構文で、Select句や GROUPBY句クエリなどをサポート。 X1000 SQLクエリ処理はMySQLや他の列指向 DBと比較して1000倍速い。 2017年に初期リリースして、人気急上昇中。
10. 行指向と列指向の物理ストレージ内容 10 Date_ID Item_ID Item_Name Price num Total_Price 2021/8/10 11011 apple 40 2 80 2021/8/10 32422 lemon 45 5 225 2021/8/10 34867 orange 1300 1 1300 2021/8/10 68432 banana 3000 1 3000 Block 1 --> 2021/08/10 11011 apple 40 2 80 Block 2 --> 2021/08/10 32422 lemon 45 5 225 Block 3 --> 2021/08/10 34867 orange 1300 1 1300 Block 4 --> 2021/08/10 68432 banana 3000 1 3000 . . Block 1 --> 2021/08/10 2021/08/10 2021/08/10 2021/08/10 ... Block 2 --> 11011 32422 34867 68432 ... Block 3 --> apple lemon orange banana ... Block 4 --> 40 45 1300 3000 ... Block 5 --> 2 5 1 1 ... Block 6 --> 80 225 1300 3000 ... 行指向DBシステムの物理構造 列指向DBシステムの物理構造 行指向の物理ストレージ処理 列指向の物理ストレージ処理 Read/Write処理の頻度が高く、 また複雑なSQLクエリで検索時は効果的だが、 データ量が大きいほどIO的にも高負荷・・・ 行指向だとクエリは行単位で検索するが、列指向だと列単位で検索。 これだけでも物理ストレージでの構造や処理形式が異なるため、 トランザクション、分析それぞれのシナリオに分けた用途が望ましい。 Read/Write処理の頻度が低く、 データ量が大きい場合でもIO的にも優しいが、 複雑なSQLクエリだとデータのスキャン量から 処理時間がかかってしまう・・・ ※ACIDトランザクションメイン、正規化前提 ※読み取り処理メイン、大きなバッチで更新や抽出前提
11. ClickHouse = 完成度の高い列指向データベース 11 列指向で格納し処理 分析シナリオのために、読み取り処理に特化するために、データは列単位で格納。 検索時は必要な列だけ読み取りなので、IOコストが削減しクエリが高速化。 列指向なので圧縮率10倍以上 データを列単位で格納するため、同じ列のデータは同じデータ型なので 列単位のデータを高圧縮し、ストレージコストを削減。 列指向DB/DWHよりもっと高圧縮 ClickHouseは列単位のエンコードがあるため、列指向サービスより高圧縮 してくれるので、他サービスより最小のコストでより多くのデータ格納が出来ます。 データを素早く読み取り 列指向で圧縮率が高いほど、データサイズが小さくなるため、 ディスクから必要なデータ読み取り時間が短縮化。 列単位圧縮アルゴリズムの選定 テーブルの列によってはデータの種類が異なるため、最適な圧縮アルゴリズムが 異なる問題に対し、様々な列タイプに応じた最適な圧縮アルゴリズムを提供。 メモリにより多くのデータをキャッシュ 同じメモリサイズでも、圧縮率が高い分より多くのデータを保存できるため、 システムキャッシュの効果がより向上。これにより処理速度が倍増。 列指向の性能を隅々最適化したアーキテクチャなので、行指向 サービスや他の列指向サービスより速い（MySQLの1000倍速い）
12. ClickHouseのメモリアライメント 12 Struct S1 { let a: Bool let b: Int64 let c: Bool let d: Int64 let e: Bool } Struct S2 { let b: Int64 let e: Bool let a: Bool let d: Int64 let c: Bool } 列指向で分析用途のために設計された共通の交換データ形式。 データを素早く書き込み・読み込み処理するために相互参照をマップ。  被参照列のみを参照するため、 IO量が少なく済む  省エコのデータパスなので プロセッサ実行効率が高い  MVCC検査はSkip ※メモリアライメント・・・CPUハードウェアレベルでデータのメモリアドレスに関する制約 SELECT 列a, 列b, 列d FROM table_xxx;の場合、、、 列a 列d 列b 書き込み 読み込み Map Map Map CPU
13. ClickHouseのSQL構文 13 基本はMySQLベース テーブルエンジン。 シナリオや目的に応じて テーブルエンジンを選定。 Partitionをサポート。 データをパートごとに分割 Primary Key Indexの粒度。
14. Primary key Index 14 Indexの粒度は8192がデフォルトですが、 この粒度の数値が小さいと、SkipIndexが可能に、 粒度の数値が大きいとIndexを小さくしてくれます Primary Key Indexをサポートしており、Indexの粒度に応じてデータを 分割。（デフォルトが8192行→Indexあたりの行数またはレコード数） Primary Keyは、Index粒度の先頭の行に対応する主キー値を格納します。 そのため、Where条件などのクエリ処理時、Primary Keyが含まれている場 合はPrimary Keyからバイナリインデックスを使用して、対応するインデックス 粒度を直接見つけることができます。 注意として、MySQLなどRDBのIndexとは異なる考えであり、 例えば重複排除に使用することはできないです。これは同じPrimary Keyを 持つレコードでも、同時にデータベース内に存在するためです。 重複排除をしたい場合は、ClickHouseのテーブルエンジンである ReplacingMergeTree、CollapsingMergeTree、 VersionedCollapsingMergeTreeと組み合わせる必要があります。
15. Sparse Index 15 Table Part Index Columns Part Index Columns Sparse Index ClickHouseはシナリオに応じてテーブルエンジンを選定することができま す。そのため、データはPrimary Keyに沿って、それぞれのデータはパー ツとして分割しながら処理します。 また、任意の列に任意の数でSparse Indexを設定することができます。 Sparse Indexは、Primary Indexのようにファイル内の各行の位置 把握はせず、Indexの粒度（デフォルトは8192行）を統計する情報 のことを指します。そのため、Sparse Indexを利用することでRAM メモリを効率的に運用から、大量のテーブルデータをスムーズに管理 することができます。 Sparse Indexには次のような変数があります。 minmax :インデックス粒度を単位として、指定した計算式での最大 値と最小値を格納 set（max_rows）: 指定した計算式の結果をインデックスの粒度 単位で格納。クエリ結果がこの結果に満ちていない場合、そのブロックを SkipすることでIOコストを削減します。 ngrambf_v1 : 文字列のngramセグメンテーション分析。例えば equival、like、in、などの条件クエリを最適化
16. データシャーティング 16 ClickHouseはstand-aloneモード、分散クラスタモードに対応。 分散クラスタモードでは、データを複数のShardへ分割し、それらを異なるノードに分散。 ClickHouseは、様々なシャーティング戦略を提供しています。 ランダムシャーティング：書き込みデータは分散クラスタ内のノードにランダムで分散 固定シャーティング：書き込みデータは固定のノードに分散 列データ型フラグメンテーション：列の値に応じてハッシュを断片化 カスタム型フラグメンテーション：任意の式を指定し、その式の計算結果に応じてハッ シュを断片化 これにより、 ・ Spark/Flink/Kafka/LogServiceからストリーミングでデータ格納（AWS Redshiftなど他サービスは書き込み処理が追い付かないから制限事項になっている） ・ログデータなど1億レコードを超える大量のレコードからSQLでデータを素早く検出 ・RDS for MySQLからのリアルタイムレプリケーションによる分析 など、様々なシナリオやSQLアクセスパターンに最適なシャーティング戦略ができます（= シャード間のデータスキューなどの問題を解決） 更に、シャード構造から小規模クラスタをはじめ大規模分散クラスタへ 柔軟に構築、切り替えができます（水平方向にスケーリング） Shard1 Shard2 Shard3 Shard1 Shard2 Shard3 Table1 Table2 Table1 Table2
17. ClickHouseの弱点 17 弱点 #1 Updateなど更新系を含めた トランザクション処理は苦手 弱点 #3 JOIN構成は考える必要がある 弱点 #4 Replica構成によるDDL操作が異なる （Singleとは別操作） フロー分析用途メインで利用 Ex: 監視基盤、SIEM、DataLake分析、 （トランザクション処理はDB側に任して）同期/レプリケーション Primary Indexを考慮したJoin処理 SingleとReplicaのSQLクエリの違いを 抑えたうえで操作 Ex; - 外部辞書を使って「小さなテーブル」の結合を排除 - 結合テーブルエンジンの使用。HASHJOINなど - ANY-strictnessの使用 - join_algorithm、partial_merge_join_optimizationsなどを使用 https://www.youtube.com/watch?v=FsVrFbcyb84&t=1915s https://www.youtube.com/watch?v=6WICfakG84c&t=1635s https://www.alibabacloud.com/help/doc-detail/170943.htm 弱点 #2 データ更新時、1レコード、1レコードと ちまちま更新だと処理が遅くなってしまう Indexの粒度（default 8192）に合わせて、 大量のレコードを一括で更新処理
18. 18 ApsaraDB for ClickHouse
19. Alibaba Cloud ApsaraDB for ClickHouseとは 19 SQL分析ショートカットとなる 辞書型関数を独自サポート Hot DataとCold Dataによる 階層型ストレージでコスト削減 スケーリング機能 クエリやユーザーごとに 並列で処理順位を管理する Resource Queues Secondary Index SLA 99.99% ClickHouse を Alibaba Cloud のApsaraDB分散システムによって 展開されたクラウドサービスが、 ApsaraDB for ClickHouse です。 OpenSource の ClickHouse と 同じ機能・エコシステムをサポート 自動レプリケーション・ 自動フェイルオーバー フルマネージドサービス
20. ApsaraDB for ClickHouseとしての実装について 20 ClickHouse ECS Replica0 Replica1 CloudDisk Shard0 ClickHouse ECS CloudDisk ClickHouse ECS Replica0 Replica1 CloudDisk Shard0 ClickHouse ECS CloudDisk ClickHouse ECS Replica0 Replica1 CloudDisk Shard0 ClickHouse ECS CloudDisk Data Backup SLB ・・・ Alibaba CloudとしてApsaraDB for ClickHouseは 可用性・高性能を持つECS上にSLBで分散クラスタとしてデプロイ。
21. Secondary Index 21 ClickHouseはPrimary Indexのみをサポートしていま すが、  クエリ処理や集計など計算のために事前に大量の データをフルスキャンする必要がある  頻繁なデータ更新やクエリパターンの変更頻度が高 い場合、メモリへ再度リロードするコストがかかる という課題から、Alibaba Cloud ApsaraDB for ClickHouseのみ「Secondary Index」をサポート。 Secondary IndexはPrimary Index以外のKeyで 作成したもので、 Primary Indexで作成したデータファ イルの中のレコードへのポインタを持つため、Primary Indexに対し結果を素早く返却するようにします。 これにより、Elasticsearchと同等以上の大量のクエリ 投与でもすぐ結果が表示できるようになります。 https://www.alibabacloud.com/blog/s econdary-index-in-alibaba-cloud- clickhouse-best-practices_597894
22. ClickHouseとElasticsearchとの違い 22 https://www.alibabacloud.com/blog/clickhouse-vs- -elasticsearch_597898 Latency（低いほど良い） Throughput（高いほど良い） Elasticsearchと比較して、以下のメリットがあり  データ追加後すばやく検索対象へ  データの長期間保持をサポート  過去データの参照・比較が可能  最小限のスペック・少ないノード台数で最大の パフォーマンス  スキーマレス  Token/全文検索サポート 一方、検索クエリやデータの変更頻度が高い場 合はElasticsearchが優れていましたが、 AlibabaはClickHouseにSecondary Index を独自実装。 そのため、Elasticsearchより安いコストで Elasticsearchを上回る処理性能を発揮します。
23. ApsaraDB for ClickHouseとHologresとの違い 23 ApsaraDB for ClickHouse Hologres ポジション フロー分析 リアルタイムDWH ストレージ形式 列指向 列指向＋行指向 書き込み直後に可視化できるまでのリードタイム 秒 ミリ秒 書き込み性能 高 非常に高い(1,000万RPS) Primary Key Index ◦ ◦ Secondary Index ◦ × オプティマイザー RBO CBO クエリフェデレーション ◦(エンジンはHDFS, Kafkaに対応) ◦(FDW直読、MaxCompute、Hiveなど) 単一テーブルの複雑なクエリ High performance High performance マルチテーブルJOIN Low performance High performance SQL構文 MySQLベース＋カスタマイズ構文 PostgreSQL Window機能 × ◦ O&M 手動。ApsaraDBは全てフルマネージド化 自動 ストレージ機能 コンピューティングのストレージ容量次第ですが、7日分 のデータしか保存できない ※拡張は可能 ストレージとコンピューティングを分離した構造なので、 15日以上のデータを簡単に保存することが可能 問い合わせ機能 コンピューティングのメモリ次第ですが、 メモリが保持できる範囲で直近分のデータしか 照会できない 7日分、15日分のデータを簡単に検索でき、検索性 能が大幅に向上します 可用性 Replica付きのクラスター構成もあり Replica付きで自動マルチコピー コスト 非常に安い 高い 監視基盤など、フロー分析用途であればClickHouse、 DWHとしての用途であればHologresが有利（ただし少し高くなる）
24. ClickHouseの公式ドキュメント 24 https://clickhouse.com/docs/en/ ApsaraDB for ClickHouseはオープンソースのClickHouse + Alibaba Cloud独自機能（フルマネージドサービス、 自動フェイルオーバー、Secondary Indexなど）が 充実しています。 Alibaba Cloud Helpには載っていない説明箇所や機能も、 このドキュメントを参考に頂ければ幸いです。
25. 25 テーブルエンジンについて
26. ClickHouseのテーブルエンジン 26  データの保存モードと場所  データの書き込みと読み出しの場所  どのようなSQLクエリがサポートされてるか  データへの同時アクセス  Indexがある場合、Indexを使用するか  並列SQLクエリの実行可否  データレプリケーションのパラメータ etc… ClickHouseは様々なシナリオでも高速処理するために、ユーザー側で テーブル作成時、シナリオに合わせたテーブルエンジンを選択できます。 ほとんどのシナリオはMergeTree Familyでカバー可（公式に推奨） https://www.alibabacloud.com/blog/selecting-a-clickhouse-table-engine_597726
27. 4種類のテーブルエンジンファミリー 27 MergeTree Family  代表的なテーブルエンジン  保存されたデータは基本的に主キーでSort  Partitionを完全サポート。参照や指定も可  データの複製をサポート。レプリケーションにも対応 Log Family  小さなデータを素早く書き込むように設計されてる  新規・更新データはDiskへ順番に書き込み  削除・更新は非対応（あくまでも可視化・分析）  Index、アトミック書き込み処理は非対応  Insert処理時はSelect操作処理が不可 （非同期処理が出来ない） Special  データをメモリに保持しながらSQLクエリを更に高速化 （ただし再起動等何かのアクション後データは消失）  テーブルのメモリバッファをDiskに反映  ローカルファイルを直接データストレージとして使用  書き込みデータが破棄された場合、読み込みデータは Nullとして処理 Integrations  外部データとのやり取り向けに設計されている  外部データをClickHouseへインポート処理  外部データソースをClickHouseで直接管理  データソースはkafka、jdbc/odbc、HDFS アプリケーションやシナリオに応じてテーブルを高速Write/Read処理 するための手法として、4種類のテーブルエンジンファミリーを提供 https://www.alibabacloud.com/help/doc-detail/146002.htm
28. テーブルエンジンファミリーの具体的な使い方 28 Engine＝Logでデータを受け取る専用の テーブルAを作成 Engine=MergeTreeテーブルBを作成し、 SELECT文などでテーブルAからテーブルB へデータを格納 COPY …TO PROGARMなどで、外部 データをテーブルAへ格納 テーブルBでSQLを使った 様々な分析を実施。 ※もし収集専用のテーブルAで分析をした 場合、時間がかかってしまう。 ClickHouseは１つのデータベース上で  データ収集専用のテーブル  データ加工・ETL専用のテーブル  データ保存用のテーブル  データ分析用のテーブル それぞれを処理し展開することが出来ます。 =今までは分析基盤のために複数のサービスを 挟んで連携処理していたが、ClickHouseなら不要 ⇒大量のデータを様々なシナリオに応じて収集、保存、 集計、抽出することができるため、データ移動コストが大 幅に減り、同時に１つのデータベース配下で整備が 出来るためワークロードや作業工数を大幅に短縮出来ます。 OPTIMIZE TABLE テーブルB FINAL; でテーブルBを強制圧縮
29. 流れをyoutubeで説明 29 https://www.youtube.com/watch?v =IqRPB8RN1Ls
30. MergeTree Family 30 テーブルへ格納するデータが大きい場合、効率的にClickHouseは様々なシ ナリオに応じてデータを部分的に高速処理するために ユーザー側でテーブル作成時、テーブルエンジンを選定することができます。 ほとんどのシナリオはMergeTree Familyでカバー可（公式に推奨） MergeTree ReplacingMergeTree SummingMergeTree AggregatingMergeTree CollapsingMergeTree Single構成 MergeTree ReplacingMergeTree SummingMergeTree AggregatingMergeTree CollapsingMergeTree HA構成 ReplicatedMergeTree ReplicatedReplacingMergeTree ReplicatedSummingMergeTree ReplicatedAggregatingMergeTree ReplicatedCollapsingMergeTree 説明 Basicな使用時に利用 バックグラウンドデータのマージ中に、同じソート キーを持つデータが重複排除されます。 データをマージするときに、同じ主キーを持 つレコードが1つのレコードにマージされます。 集計フィールドの設定によると、このフィール ドの値は集計後の集計値であり、非集計 フィールドは最初のレコードの値を使用し、 集計フィールドのタイプは数値タイプである 必要があります。 同じデータパーティション内で、 同じ主キーを持つデータを集約できます。 同じデータパーティション内で、 同じ主キーを持つデータを集約できます。 MergeTree Familyの例：
31. MergeTree（ Single構成とHA構成の書き方） 31 Single構成（MergeTree） HA構成（ReplicatedMergeTree） HA構成のテーブルエンジン名 = Replicated +（Single構成の）テーブルエンジン名
32. MergeTree（Single構成、最適化前） 32  主に大規模データの分析に使用  データの割り当て、順序付け、Primary key index、 Sparse Indexをサポート  保存したデータはPrimary keyでソート  Primary keyをPartitionとして設定が可能  データコピーに対応
33. MergeTree（Single構成、最適化後） 33  optimize table ＜Table Name＞ final; でテーブルを最適化（圧縮）してくれます。  テーブルのレコード数が大きい場合でも、 Primary Keyを設定することにより、テーブルを 最適化することができます。  最適化時、グループ集計時や重複除去などは MargeTreeファミリーの他エンジンを使って対応します。
34. ReplacingMergeTree（Single構成、最適化前） 34 ReplacingMergeTreeエンジンは、同じレコードがある場合、 主キーを持つ範囲内でのレコード重複を削除することができます。
35. ReplacingMergeTree（Single構成、最適化後） 35 MergeTreeエンジンはマージに重複処理しますが、 ReplacingMergeTreeエンジンは重複除去処理となります。
36. SummingMergeTree（SQLクエリはSingle構成） 36  SummingMergeTreeエンジンのテーブルを使うことで、同じ主 キーを持つ全ての行をグループ集計するとき、マージされた行の 数値データを持つ列の集約値を含む単一行へ結合します。  1つのキーの値が多数の行に対応するように、主キーを組み合わ せれば、ストレージスペースを大幅に削減しつつ、データ集計によ る検索を高速化することが出来ます。
37. 37 ClickHouseの使い方
38. 接続方法に関して 38 ECSなどからCLIでClickHouseへ接続 DMSでClickHouseへ接続
39. VSCodeからClickHouseへSQL操作もできます 39 https://vscode- sqltools.mteixeira.dev/features/book marks
40. 40 ClickHouseの運用
41. Scale Up/Down（クラスターのスペックをアップグレート/ダウングレート） 41 データ容量増加に伴うCPU/メモリ負荷などに応じて ClickHouseのスペックをアップグレート/ダウングレートします。
42. Scale Out/In （Nodeの追加/削除） 42 接続ユーザーが多い、あるいはNode台数による並列分散処理の 処理能力を上げたい場合、Nodeの追加/削除が出来ます。
43. Hot data/Cold Data 43 ApsaraDB for ClickHouse  ApsaraDB for ClickHouseはHot Data/Cold Data機能が あり、大量のデータに対するコスト対策を実現することが出来ます。  Hot DataはECS付帯のESSD、Cold Dataはデータセンター  Cold Dataは1GBあたり$0.000031USD/hourly/GBと OSSより安いコストパフォーマンス  TTLと組み合わせることで、時間が経つにつれてHot dataを Cold Dataへ自動切換えという構成も可能 https://www.alibabacloud.com/help/doc-detail/202879.htm Hot Data Cold Data SQLクエリやTTLなどで Hot dataをCold Dataへ 切換え
44. BackupとRestore 44 ApsaraDB for ClickHouse データセンター https://www.alibabacloud.com/help/doc-detail/208840.htm  ApsaraDB for ClickHouseはbackupとRestore機能があり、 いつでもクラスターレベルで復元することができます。  現在、無料。事前にチケットを発行する必要があります。 Backup Restore
45. 対応BI Tool 45  OSS系のBI Toolにはほとんど対応。  ClickHouseとしてはGrafanaを公式に推奨。  ただし、TableauやPowerBIのように企業開発の BI Toolには未対応なので、もし利用する場合は JDBC/ODBCドライバー接続となります。
46. 46 ClickHouseのコスト比較
47. ApsaraDB for ClickHouseの価格について 47 ApsaraDB for ClickHouse Hot Data Cold Data インスタンス代（4core16GB～104core384GB） ＋ ストレージスペースとバックアップスペース（ESSD代） ＋ Cold Dataストレージ代（$0.000029USD/hourly/GB) https://www.alibabacloud.com/he lp/doc-detail/167450.htm  一か月最低1万円～と良心的な価格  HA構成だと可用性は上がるが価格が上がる  HA構成はSingle構成インスタンス代の2倍の価格 Hot data/Cold dataを上手く扱うことで ストレージコストを80%近く削減が可能 ※ESSD 32000GBの場合
48. 他社比較 48 ApsaraDB for ClickHouse AWS Redshift 1 Node 2 Nodes 10 Nodes データ量増加に伴う比較としてApsaraDB for ClickHouseが安い
49. 49 代表的なユースケース
50. 接続パターン 50 Computing Collector Storage RDBMS SIEM Apache Spark Streaming Search DWH ⇒毎月50GBの新しいデータをリアルタイム収集・可視化するとして、 トータルで毎月3万円～ ※LogService、LogStash、ClickHouse、ECS代を含める ApsaraDB for ClickHouse Grafana （ECSにインストール） 構成例： LogServiceもしくはLogStashから始めるサービス監視基盤 ApsaraDB for ClickHouse Grafana on ECS LogService LogStash LogStash MaxCompute Apache Flink Apache kafka DLA ServerlessSpark Apache Spark LogService RDS for MySQL PolarDB-M （MySQL） OSS Fluentd ECS 収集 蓄積・処理 可視化 https://grafana.com/grafana/plugins/v ertamedia-clickhouse-datasource/ Real-Time Superset Timber.io VECTOR
51. ClickHouseが優れている理由 51 ClickHouse Elasticsearch AWS Redshift GCP BigQuery snowflake ログ収集 Fluentd連携 ◦ △ ◦ ◦ ◦ LogStash連携 ◦ ◦ △ （jdbcドライバー） △ （jdbcドライバー） △ （jdbcドライ バー） データベース連携 MySQL直接連携 ◦ × × × × レプリケーション ◦ △ △ △ ◦ DataLake CSV ◦ ◦ ◦ ◦ ◦ HDFS ◦ × ◦ ◦ × DWH CSV ◦ ◦ ◦ ◦ ◦ HDFS ◦ × ◦ ◦ × ストリーミング Apache Kafka連携 ◦ △ ◦ ◦ ◦ Apache Spark連携 ◦ ◦（ES-Hadoop） ◦ ◦ ◦ Apache Flink連携 ◦ ◦（ES-Hadoop） ◦ ◦ ◦ コスト 処理コスト ◦ × × ◦ ◦ 保存コスト ◦ × × × ◦ ClickHouseのみ、様々なシナリオを全て満たすことができます。しかも一番安い金額で。
52. ログ収集・監視基盤／FluentdでClickHouseへ格納 52 ECS VPC fluent-plugin- clickhouse Nginx (access.log) ApsaraDB for ClickHouse td-agent  NginxやApacheログなどをリアルタイム可視化したい  RaspberryPiなど複数のIoTセンサーを一元集約したい  Kubernetesやsalesforce、cloudなど様々なログ監視 をしたい メモリ使用量の低い、軽量ジッパーであるFluentdで、 アクセスログを収集してClickHouseへ転送 シナリオ 解決策 応用例 1000を超えるFluentdの様々なプラグインを使うことで 様々なサービス基盤やシステムのデータを収集しながら監視 構築方法は 右のQRコードから
53. ログ収集・監視基盤／ LogStashでClickHouseへ格納 53  Fluentdでは扱い切れない大量のログを収集し、フィルタリ ングしながら可視化したい  beatsと連携してリアルタイム監視基盤を作りたい  セキュリティを意識した監視基盤としてデータ欠損なしにデー タを収集したい  大量のログ収集のLogStashと連携することで大量データを 素早く処理できるClickHouseでフロー監視を実現 シナリオ 解決策 応用例  LogStashはbeats連携ができるため、winlogbeatsを 使ったWindows各種ログやWebログなどを集約、クエリ処 理パフォーマンスの高い大規模監視基盤を実現 ECS VPC fluent-plugin- clickhouse Nginx (access.log) ApsaraDB for ClickHouse 構築方法は 右のQRコードから firebeats
54. LogService連携／LogDeliveryでClickHouseへ格納 54  Alibaba Cloud各種プロダクトサービスもしくはOSSログな どをLogServiceで収集したのち、それをLogServiceと同 等レベルの低コストサービスで大量のデータを可視化したい  LogServiceからLogDeliveryでClickHouseへリアルタイ ム格納。ApsaraDB for ClickHouseのみ、コンソールか らワンクリック操作するため、簡単に連携展開 シナリオ 解決策 応用例  クエリ数やデータ量による課金を行うLogServiceより ずっと低価格のClickHouseでコスト節約を実現 ECS VPC fluent-plugin- clickhouse ApsaraDB for ClickHouse 構築方法は 右のQRコードから LogService sls-webtracking
55. DataLake／CSVをOSSへ格納し分析・OSSへCSV出力 55 VPC OSSのCSV読み取り ApsaraDB for ClickHouse OSS  OSSにある大量のCSVファイルをクイックに分析したい  OSSをセントラルストレージとした運用基盤で、分析をしたい  分析結果をOSSへCSV出力したい  OSS - ClickHouse連携運用。OSSにあるCSVファイルを 読み取り分析し、分析結果はOSSへCSV出力。  また大量のCSVファイルや、ファイルサイズの大きいCSVファ イルをリロードできるため、分析におけるIOコストを削減 シナリオ 解決策 応用例  OSSをセントラルストレージとした様々なシナリオにて、 ETLを介せずクイックな分析基盤としての構築・展開が可能 構築方法は 右のQRコードから CSV出力
56. MySQL連携／MaterializeMySQLでデータ同期 56 RDS for MySQL VPC ApsaraDB for ClickHouse  RDS for MySQLもしくは自作MySQLからClickHouse へリアルタイムデータ同期したい  RDS MySQLをデータ分析サービスへ連携するにあたり、 データ移植のコストをかけたくない  TableEngineとしてMaterializeMySQLを使うことで、 MySQLのデーブルとデータをClickHouseへ完全同期しつ つ、MySQL側で更新等があれば自動で増分同期されます シナリオ 解決策 応用例  RDS for MySQLもしくは自作MySQLを使ったサービス 基盤からMySQLデータ/binログを使った分析・監視基盤 構築方法は 右のQRコードから MaterializeMySQL エンジンでデータを同期 https://www.alibabacloud.com/help/doc- detail/209912.htm
57. データベース連携／DTSによるレプリケーション 57 RDS for MySQL VPC ApsaraDB for ClickHouse DTS PolarDB  PolarDBもしくは別のRDSデータベースから ClickHouseへリアルタイムデータ同期したい  データベースから分析基盤連携において、サービスを 一切停止することなくスムーズな処理をしたい  DTSを使うことで異種データソース間のレプリケーショ ンを実現 シナリオ 解決策 応用例  PolarDBもしくは別のRDSデータベースを使ったサービ ス基盤からレプリケーションによる分析・監視基盤 構築方法は 右のQRコードから
58. ストリーミング／KafkaからClickHouseへ格納 58  様々なデータソースからのストリームデータを分散メッセージン グとしてリアルタイムで分析基盤へ連携したい  連続データに対し、遅延なく集計処理を実現したい  Kafkaエンジンのテーブルを作ることで、kafkaからストリーム データを確実にClickHouseへ直接格納します  AggregatingMergeTreeエンジンなどで、連続データに対 する集計処理の高速化を実現します。 シナリオ 解決策 応用例  機器の動作情報/APサーバのログ/ECサイトの購入情報 /SNSの投稿など様々なデータを一切止めることなく 集計・可視化する分析基盤を低価格で展開 ECS VPC Kafkaエンジンでデータを Clickhouseへ格納 ApsaraDB for ClickHouse 構築方法は 右のQRコードから Message Queue for Apache Kafka ECSでJarを実行、 KafkaMessageを生成 メッセージを受信
59. バッチ・ストリーミング／SparkからClickHouseへ格納 59  大量のデータから特定のデータや条件に合致するレコードだ けを蓄積し、集計したい  Sparkで日々大量のデータを処理しているが、データ増加 に伴う処理パフォーマンス低下から、スケールアウトが必要  大量のデータをバッチで一括インポートが出来る ClickHouseでハンドリングしつつ、集計系エンジンを使って スケールアウトせずに集計処理 シナリオ 解決策 応用例  Apache Sparkでスケールアウトが望ましい状況でも ClickHouseと連携することでスケールアウトしない分だけコ スト節約を実現 OSS VPC SparkRun ApsaraDB for ClickHouse 構築方法は 右のQRコードから E-MapReduce DLA ServerlessSpark Apache Spark
60. ストリーミング／FlinkからClickHouseへ格納 60  耐障害性/拡張性を備えたストリーム処理基盤からリアルタ イム分析基盤へ連携したい  リアルタイムでデータ格納直後に分析ができるようにしたい  ClickhouseはHDFSを使わずにローカルストレージへ直接 格納するため、Apache Flinkによるバッチ/リアルタイムデー タを素早く書き込み、すぐに分析や集計処理することが出来 ます シナリオ 解決策 応用例  Apache Flinkを使った大規模ストリーミングデータによる フロー監視基盤、集計基盤 ECS VPC ApsaraDB for ClickHouse 構築方法は 右のQRコードから Apache Flink FlinkRun https://developpaper.com/interesting-headlines- based-on-flink-clickhouse-to-build-a-real-time- data-analysis-platform/
61. 61 EOF