mirror of
https://github.com/ClickHouse/ClickHouse.git
synced 2024-11-28 18:42:26 +00:00
52 lines
5.8 KiB
Markdown
52 lines
5.8 KiB
Markdown
|
---
|
|||
|
|
slug: /ja/about-us/history
|
|||
|
|
sidebar_label: ClickHouseの歴史
|
|||
|
|
sidebar_position: 40
|
|||
|
|
description: それが始まった場所...
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# ClickHouseの歴史 {#clickhouse-history}
|
|||
|
|
|
|||
|
|
ClickHouseは当初、[世界で2番目に大きなウェブ解析プラットフォーム](http://w3techs.com/technologies/overview/traffic_analysis/all)である[Yandex.Metrica](https://metrica.yandex.com/)を支えるために開発され、そのシステムのコアコンポーネントとして今も使われています。データベースには13兆を超えるレコードがあり、1日あたり200億件以上のイベントが発生しています。ClickHouseは、非集約データから直接カスタムレポートをその場で生成することを可能にします。この記事では、ClickHouseの開発初期段階での目標について簡単に説明します。
|
|||
|
|
|
|||
|
|
Yandex.Metricaは、ヒット数やセッション数に基づいてカスタマイズされたレポートをその場で作成し、ユーザーによって定義された任意のセグメントを使用します。このためには、しばしばユニークユーザー数などの複雑な集約を構築する必要があります。レポート作成のための新しいデータはリアルタイムで到着します。
|
|||
|
|
|
|||
|
|
2014年4月時点で、Yandex.Metricaは1日あたり約120億件のイベント（ページビューやクリック）を追跡していました。これらすべてのイベントはカスタムレポートを構築するために保存されなければなりません。単一のクエリでは数百万行を数百ミリ秒以内でスキャンしなければならないこともあれば、数億行を数秒でスキャンすることもあります。
|
|||
|
|
|
|||
|
|
## Yandex.Metricaとその他のYandexサービスでの使用 {#usage-in-yandex-metrica-and-other-yandex-services}
|
|||
|
|
|
|||
|
|
ClickHouseは、Yandex.Metricaにおいて多目的に利用されています。 主なタスクは、非集約データを使用してオンラインモードでレポートを作成することです。それは374台のサーバークラスターを使用し、データベースに20.3兆行以上を保存します。圧縮データのボリュームは約2 PBで、重複とレプリカを考慮しない場合のことです。圧縮されていないデータ（TSV形式）のボリュームは約17 PBになります。
|
|||
|
|
|
|||
|
|
ClickHouseはまた、以下のプロセスにおいて重要な役割を果たしています：
|
|||
|
|
|
|||
|
|
- Yandex.Metricaからのセッション再生データの保存。
|
|||
|
|
- 中間データの処理。
|
|||
|
|
- Analyticsを使用したグローバルレポートの作成。
|
|||
|
|
- Yandex.Metricaエンジンのデバッグのためにクエリを実行。
|
|||
|
|
- APIとユーザーインターフェースからのログの解析。
|
|||
|
|
|
|||
|
|
現在、他のYandexサービスや部門の検索バーティカル、eコマース、広告、ビジネス分析、モバイル開発、パーソナルサービスなどで、数十件のClickHouseのインストールが見られます。
|
|||
|
|
|
|||
|
|
## 集約データと非集約データ {#aggregated-and-non-aggregated-data}
|
|||
|
|
|
|||
|
|
統計を効果的に計算するためには、データを集約しなければならないという意見が広まりつつあります。なぜなら、これによりデータの量が削減されるからです。
|
|||
|
|
|
|||
|
|
しかし、データ集約には多くの制約があります：
|
|||
|
|
|
|||
|
|
- 必要なレポートの事前定義リストが必要です。
|
|||
|
|
- ユーザーはカスタムレポートを作成できません。
|
|||
|
|
- 多数の異なるキーに対して集約する場合、データ量はほとんど削減されないため、集約は無意味です。
|
|||
|
|
- 多数のレポートに対して、集約のバリエーションが多すぎる（組み合わせの爆発）。
|
|||
|
|
- 高いカーディナリティ（たとえばURL）のキーを集約する場合、データ量はあまり削減されません（2倍未満）。
|
|||
|
|
- このため、集約されたデータ量が縮小するどころか増加することがあります。
|
|||
|
|
- ユーザーは我々が生成するすべてのレポートを閲覧するわけではありません。大部分の計算は無駄になります。
|
|||
|
|
- さまざまな集約に対してデータの論理的一貫性が損なわれることがあります。
|
|||
|
|
|
|||
|
|
何も集約せず、非集約データとともに作業する場合、このアプローチにより計算量が削減されることがあります。
|
|||
|
|
|
|||
|
|
しかし、集約では作業の大部分がオフラインで比較的落ち着いて完了します。それに対照的に、オンライン計算ではユーザーが結果を待っているため、できるだけ早く計算する必要があります。
|
|||
|
|
|
|||
|
|
Yandex.Metricaには、Metrageというデータを集約するための専門システムがあり、大多数のレポートで使用されていました。 2009年から、Yandex.Metricaでは、レポートビルダーに以前使用されていたOLAPServerという非集約データのための専門的なOLAPデータベースも使用していました。OLAPServerは非集約データにはうまく機能しましたが、望ましいすべてのレポートで使用できない多くの制約がありました。これにはデータ型のサポート（数値のみ）がないことや、データをリアルタイムで増分更新できないこと（データを毎日書き換えることのみ可能）が含まれます。OLAPServerはDBMSではなく、専門的なDBです。
|
|||
|
|
|
|||
|
|
ClickHouseの初期目標は、OLAPServerの制約を撤廃し、すべてのレポートで非集約データを用いた作業の問題を解決することでしたが、長年にわたって成長を続け、広範囲の分析タスクに適した汎用データベース管理システムに成長しました。
|