ClickHouse Meetup Tokyo の弊社ライトニングトークで使用されたスライドです。 イベントレポートはこちら： https://geniee.co.jp/blog/2019/12/18/clickhousemeetup-tokyo-report/

1. © Geniee, Inc.
ClickHouse導入事例紹介
R&D本部
基盤技術開発部 SREチーム
犬伏

2. © Geniee, Inc.
本日の内容
2
● [1min] 登壇者紹介
● [3min] ClickHouse導入の経緯
● [8min] システム構成の紹介
○ 系全体：Kafka, Flink, ZooKeeper, MySQL, ClickHouse
○ ClickHouse cluster の構成：サーバー構成, テーブル構成
● [8min] ClickHouse導入による成果・課題
○ 遭遇した課題とその解決：メモリ, Merge engine, XID overflow
○ 未解決問題たち：MaterializedView, distributed_aggregation_memory_efficient
● [5min] 未来のClickHouseへの要望等
● [15min] 質疑応答

3. © Geniee, Inc.
登壇者紹介
3
● 犬伏 貴之 (Inubushi Takayuki)
● R&D本部 基盤技術開発部 SREチーム（インターン）
● ClickHouse歴 9ヶ月
○ 2019年2月頃 ClickHouseに触れる
○ 2019年4月頃 XID overflow と遭遇
● 趣味（Hobby）
○ テトリス（Tetris）

4. © Geniee, Inc.
本日の内容
4
● 登壇者紹介
● ClickHouse導入の経緯
● システム構成の紹介
● ClickHouse導入による成果・課題
● 未来のClickHouseへの要望等 (Our requests about CH)
● 質疑応答

5. © Geniee, Inc.
ClickHouse導入の経緯
5
● 決め手となった指標
○ 高速なSELECT
○ 圧縮による高いストレージ効率
● 2年前時点での状況
○ MySQLからClickHouseへデータを複製するバッチが動作
画面表示が高速化
● See also
○ SlideShare: 世界分散配信システムとレポートシステム刷新の話
○ GENIEEブログ: ClickHouseで...1000倍高速化した話
○ SlideShare: Report API を支える技術

6. © Geniee, Inc.
本日の内容
6
● 登壇者紹介
● ClickHouse導入の経緯
● システム構成の紹介
● ClickHouse導入による成果・課題
● 未来のClickHouseへの要望等 (Our requests about CH)
● 質疑応答

7. © Geniee, Inc.
システム構成の紹介[1/4]:全体
7

8. © Geniee, Inc.
システム構成の紹介[2/4]:ClickHouse cluster
8
● ClickHouse cluster の構成
○ 8台の物理サーバーを 4shard × 2replica でクラスター構成
● 各サーバーの性能
○ CPU: Intel Xeon Gold 6142 x 2
○ RAM: 256GB
○ Storage: HDD 18TB (RAID50)
○ Network BW: 10Gbps
○ Network RTT: 150μs
● Software versions
○ ClickHouse: 19.7.3.9 (8 servers)
○ ZooKeeper: 3.4.13 (5 servers)

9. © Geniee, Inc.
システム構成の紹介[3/4]:ClickHouse tables
9
● テーブル構成
○ Raw（詳細なデータ保持）とMaterialized（部分集計テーブル）
○ それぞれ日付（in JST）単位のテーブルの集合（Merge）
■ 日付単位なのは、再集計を可能にするため
※ 再集計 … ログ生成側、ログ集計側のどちらかが不具合を起こすと集計し直したくなるが、
再集計結果が出るまでは一部誤った結果でも残しておきたい
● カラム数・カラムの型
○ primary key → 39(Raw), 31(Materialized)
■ 2 DateTime, 15 UInt32, 14 UInt16, 2 UInt8, 1 Int16, 5 String
○ measure → 16(Raw), 16(Materialized)
■ 3 Int32, 13 Int64 (打ち消しのために符号付き数を使用）
※ 打ち消し … SummingMergeTreeでは DELETE ができないので、削除したいデータの
primary key に対し、負の measure を INSERT することで値を打ち消して擬似的に削除する

10. © Geniee, Inc.
システム構成の紹介[4/4]:ClickHouse tables
10
5 times/min
20-30MB/once

11. © Geniee, Inc.
本日の内容
11
● 登壇者紹介
● ClickHouse導入の経緯
● システム構成の紹介
● ClickHouse導入による成果・課題
● 未来のClickHouseへの要望等 (Our requests about CH)
● 質疑応答

12. © Geniee, Inc.
ClickHouse導入による成果：
12
● ◯ 高効率なストレージ
○ MySQLに置いてあるデータと比べキーをかなり増やしているが、
それでもほぼ同程度の容量しか消費していない
● ？ Meetupを開催できた
○ 本スライドを作成する工数をもらえた
→ClickHouseのドキュメントを読み直す時間を得た
● ✕ テーブル設計を失敗している感がある
○ 日単位で持っている数千のテーブルや、それを束ねるMergeテーブル
に飛んで来るクエリが悪さをしている
○ 2年前に「1000倍速く」なったものが「1000倍遅く」戻ったり
※ キーを張っていないカラムに対して GROUP BY をしているのが悪い

13. © Geniee, Inc.
ClickHouse導入による成果：良かった機能
13
● Materialized View
○ Raw に投げると時間がかかる場合に使えるが、柔軟性が課題
● PREWHERE
○ 条件やクエリにもよるが、3倍ぐらい速くなることが多い
※ PREWHERE内部で関数を呼び出すと早くならないことがあるような気がする ?
● max_memory_usage, _for_user, _for_all_users
○ 誰かの心ないSELECTが系全体を停止させることが減る
● クエリの静的解析をちゃんと頑張っていそう
○ 共通部分式削除とか

14. © Geniee, Inc.
ClickHouse導入後の課題：躓いた点
14
● メモリとの闘い
○ SELECTクエリは場合によって大量のメモリを消費する
→ max_memory_usage 等で制限した上で、必要な大きなクエリは複
数回のSELECTに分割
● 突然の Table is in readonly mode との闘い
○ 大量のReplicatedテーブルを保持していると短周期で xid overflow
○ xid overflow の処理に穴があり一部のテーブルに書き込めなくなる
→ 毎日 clickhouse-server を再起動することでごまかし
● Cannot schedule a taskとの闘い
○ 全期間でのSELECTを行うとConnectionPoolが枯渇する
※ より小さな区間での Merge を作って後で合計してごまかし
● テーブル構造との闘い
○ キーでない列へのSELECTは当然フルスキャンになる
※ ClickHouseは悪くない、我々のテーブル設計の問題

15. © Geniee, Inc.
ClickHouse導入後の課題：将来使いたい機能
15
● merge table function
○ readonly な user は使えないところがつらい
○ set readonly=2 とすれば setting 変更と table function だけ可能
● distributed_aggregation_memory_efficient setting
○ 少し試したところ数値が合わないところがあり慌てて戻した
● PARTITION feature looks great
○ おそらく導入を決めた時点ではこんなに柔軟ではなかった
○ 日単位でテーブル分けたりしなくても良いかもしれない
※ MaterializedView を考えるとまだ難しいかもしれない ?

16. © Geniee, Inc.
本日の内容
16
● 登壇者紹介
● ClickHouse導入の経緯
● システム構成の紹介
● ClickHouse導入による成果・課題
● 未来のClickHouseへの要望等 (Our requests about CH)
● 質疑応答

17. © Geniee, Inc.
Our requests about ClickHouse
未来のClickHouseへの要望等
17
● Allow use of merge table function for readonly users
○ set readonly=2 solves this
● Feature to create complete MView for existing active tables
○ Here “active” means “INSERT continues during POPULATE”
○ Flexible MView creation is essential for our use case
○ Maybe part-based approach is good?
● Provide control on #threads when SELECT on Merge table
○ We have many(>2k) tables in Merge.
● Fix incorrect results when distributed_aggregation_memory_efficient is on
○ It makes response faster, saves network usage, balances loads
● About error log
○ >650MB for each server in 3 months, both system errors and
query errors are present and cannot separate easily
○ system.text_log and system.query_log will help

18. © Geniee, Inc.
本日の内容
18
● 登壇者紹介
● ClickHouse導入の経緯
● システム構成の紹介
● ClickHouse導入による成果・課題
● 未来のClickHouseへの要望等 (Our requests about CH)
● 質疑応答

19. © Geniee, Inc.
質疑 応答
Q&A time

20. © Geniee, Inc.
ありがとうございました．
Thank you.

21. © Geniee, Inc.
参考文献
21
● https://clickhouse.yandex/docs/en/development/architecture/
● https://clickhouse.yandex/docs/en/operations/

22. © Geniee, Inc.
distributed_aggregation_memory_efficient
SELECT
banner_id,
zone_id,
any(ssp_id),
toDate(local_interval_start_utc, 'UTC') AS date,
0 AS bid,
sum(imp_count) AS impression,
sum(click_count) AS click,
sum(conversion_cost_nanojpy) AS revenue_jpy,
sum(cost_nanojpy) AS cost_jpy,
sum(geniee_cost_nanojpy) AS winprice_jpy,
sum(geniee_margin_nanojpy) AS geniee_margin_revenue_jpy,
sum(vendor_margin_nanojpy) AS vendor_margin_revenue_jpy,
sum(agency_margin_nanojpy) AS agency_margin_revenue_jpy,
is_rtb_as_yield,
any(campaign_currency)
FROM buyer.reports_v3
PREWHERE (date = '2019-11-01') AND ((banner_id % 16) = 0)
GROUP BY
banner_id,
zone_id,
date,
is_rtb_as_yield
HAVING (impression != 0) OR (click != 0) OR (revenue_jpy != 0) OR (cost_jpy != 0) OR (winprice_jpy != 0)
with distributed_aggregation_memory_efficient = 0:
349589 rows in set. Elapsed: 6.661 sec. Processed 39.54 billion rows, 318.27 GB (5.94 billion rows/s., 47.78 GB/s.)
349589 rows in set. Elapsed: 6.537 sec. Processed 39.54 billion rows, 318.28 GB (6.05 billion rows/s., 48.69 GB/s.)
349589 rows in set. Elapsed: 6.364 sec. Processed 39.54 billion rows, 318.28 GB (6.21 billion rows/s., 50.02 GB/s.)
with distributed_aggregation_memory_efficient = 1:
1378 rows in set. Elapsed: 4.290 sec. Processed 39.52 billion rows, 317.87 GB (9.21 billion rows/s., 74.10 GB/s.)
1378 rows in set. Elapsed: 4.327 sec. Processed 39.51 billion rows, 317.51 GB (9.13 billion rows/s., 73.38 GB/s.)
1378 rows in set. Elapsed: 4.323 sec. Processed 39.53 billion rows, 318.04 GB (9.14 billion rows/s., 73.56 GB/s.)
22
Faster, but
Results are different