RedshiftからClickHouseへの切り替え

長い間、iFunnyは、バックエンドサービスおよびモバイルアプリケーションで発生するイベントのデータベースとしてRedshiftを使用していました。 実装時に、概して、コストと利便性の点で同等の代替手段がなかったため、これが選択されました。



ただし、ClickHouseの公開リリース後にすべてが変更されました。 私たちは長い間それを研究し、コストと比較し、おおよそのアーキテクチャであるふりをして、最終的に、この夏、それが私たちにとってどれほど役に立つかを見ることにしました。 この記事では、Redshiftが解決に役立てた問題と、このソリューションをClickHouseに移行した方法について説明します。

問題

iFunnyはYandex.Metricaに似たサービスを必要としていましたが、国内消費専用です。 理由を説明します。



外部クライアントはイベントを書き込みます。 モバイルアプリケーション、Webサイト、または内部バックエンドサービスになります。 これらのクライアントは、イベント受信サービスが現在利用できないこと、「15分または1時間で送信しよう」と説明することは非常に困難です。 多くの顧客がいて、彼らは常にイベントを送りたいと思っており、まったく待つことができません。



それらとは対照的に、この点で非常に寛容な内部サービスとユーザーがいます。アクセスできない分析サービスでも正しく動作することができます。 そして、ほとんどの製品測定基準とA / Bテストの結果は、一般的に1日に1回だけ、またはより少ない頻度で見るのが理にかなっています。 したがって、読み取り要件は非常に低くなります。 事故や更新が発生した場合、数時間または数日間も読むことができない、またはアクセスできない場合があります（特に無視されている場合）。



数値について言えば、1日に約50億のイベント（300 GBの圧縮データ）を取得する必要がありますが、SQLクエリにアクセス可能な「ホット」な形式で3か月間、2年間「冷たい」形式でデータを保存します以上ですが、数日以内にそれらを「ホット」に変えることができます。



基本的に、データは時間順に並べられたイベントのコレクションです。 約300種類のイベントがあり、それぞれに独自のプロパティセットがあります。 分析データベースと同期する必要のあるサードパーティのソースからのデータがまだあります。たとえば、MongoDBまたは外部のAppsFlyerサービスからのアプリケーションインストールのコレクションです。



データベースには約40 TBのディスクが必要であり、「コールド」ストレージには約250 TB以上必要です。

Redshiftソリューション

そのため、イベントを受信する必要があるモバイルクライアントとバックエンドサービスがあります。 HTTPサービスはデータを受け入れ、最小限の検証を行い、ローカルディスク上のイベントを1分ごとにグループ化されたファイルに収集し、すぐに圧縮してS3バケットに送信します。 このサービスの可用性は、アプリケーションとAWS S3を備えたサーバーの可用性に依存します。 アプリケーションは状態を保存しないため、簡単にバランスを取り、スケーリングし、交換できます。 S3は、評判と可用性が高い比較的単純なファイルストレージサービスなので、信頼できます。



次に、何らかの方法でデータをRedshiftに配信する必要があります。 ここではすべてが非常に簡単です。Redshiftには組み込みのS3インポーターがあり、これがデータのロードに推奨される方法です。 したがって、10分ごとに、Redshiftに接続し、 s3://events-bucket/main/year=2018/month=10/day=14/10_3*



プレフィックスを使用してデータをダウンロードするように要求するスクリプトが開始されますs3://events-bucket/main/year=2018/month=10/day=14/10_3*







ダウンロードタスクのステータスを監視するために、 Apache Airflowを使用します。エラーが発生した場合に操作を繰り返し、実行履歴を明確にすることができます。これは、このようなタスクの多くにとって重要です。 問題が発生した場合は、一定の時間間隔でダウンロードを繰り返すか、1年前にS3から「コールド」データをダウンロードできます。



同じエアフローで、同じ方法で、スケジュールに従って、データベースに接続し、外部リポジトリから定期的なダウンロードを実行するスクリプトが機能するか、 INSERT INTO ... SELECT ...



形式でイベントを集約しますINSERT INTO ... SELECT ...







Redshiftの可用性の保証は脆弱です。 1週間に1回、最大30時間（時間枠は設定で指定されます）AWSは、クラスターの更新またはその他のスケジュールされた作業を停止できます。 1つのノードで障害が発生すると、ホストが復元されるまでクラスターも使用できなくなります。 これには通常約15分かかり、約6か月ごとに発生します。 現在のシステムでは、これは問題ではなく、もともとは定期的に利用できないように設計されていました。



Redshiftでは、ds2.8xlargeの4つのインスタンス（36 CPU、16 TB HDD）が使用され、合計で64 TBのディスクスペースが得られます。



最後のポイントはバックアップです。 バックアップスケジュールはクラスター設定で指定でき、正常に機能します。

ClickHouse移行の動機

もちろん、問題がなければ、誰もClickHouseに移行することを考えなかったでしょう。 しかし、彼らはそうでした。



MergeTreeとRedshiftエンジンを備えたClickHouseストレージスキームを見ると、イデオロギーが非常に似ていることがわかります。 両方のデータベースは列状であり、多数の列でうまく機能し、ディスク上のデータを非常によく圧縮します（Redshiftでは、個々の列ごとに圧縮タイプを構成できます）。 データも同じ方法で保存されます。主キーで並べ替えられるため、特定のブロックのみを読み取り、個々のインデックスをメモリに保持することはできません。これは、大量のデータを扱う場合に重要です。



本質的な違いは、いつものように、細部にあります。

デイリーテーブル

ディスク上のデータをソートし、実際にRedshiftで削除するのは次の場合です。

 VACUUM <tablename>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この場合、バキューム処理はこのテーブルのすべてのデータで機能します。 1つのテーブルに3か月すべてのデータを保存する場合、このプロセスには時間がかかり、古いデータが削除されて新しいデータが追加されるため、少なくとも毎日実行する必要があります。 毎日個別のテーブルを作成し、ビューで結合する必要がありました。これは、このビューのローテーションとサポートの難しさだけでなく、クエリのスローダウンでもあります。 リクエストに応じて、explainによって判断すると、すべてのテーブルがスキャンされました。 また、1つのテーブルのスキャンにかかる時間は90個で1秒未満ですが、クエリには少なくとも1分かかります。 これはあまり便利ではありません。

重複

次の問題は重複です。 何らかの方法で、ネットワークを介してデータを送信する場合、2つのオプションがあります：データを失うか、重複を受信します。 メッセージを失うことはできませんでした。したがって、イベントの一部が複製されるという事実に単純に一致しました。 新しいテーブルを作成し、古いテーブルからデータを挿入して、重複するIDを持つ行を削除し、古いテーブルを削除して新しいテーブルの名前を変更することで、1日あたりの重複を削除できます。 毎日のテーブルの上部にビューがあったため、テーブルの名前を変更するときに、それを忘れずに削除する必要がありました。 この場合、ロックを監視することも必要でした。さもなければ、ビューまたはテーブルの1つをブロックするクエリの場合、このプロセスは長時間ドラッグされる可能性がありました。

監視とメンテナンス

Redshiftの単一のリクエストにかかる時間は数秒未満ではありません。 ユーザーを追加したり、アクティブなリクエストのリストを表示したりするだけでも、数十秒待つ必要があります。 もちろん、許容することができ、そのようなクラスのデータベースではこれは許容できますが、最終的には膨大な時間の損失になります。

費用

計算によると、まったく同じリソースを持つAWSインスタンスにClickHouseをデプロイすることは、ちょうど2倍安くなります。 もちろん、そうである必要があります。Redshiftを使用すると、AWSコンソールのいくつかのボタンをクリックするとすぐに任意のPostgreSQLクライアントに接続できる既製のデータベースが得られるため、AWSが残りの作業を行います。 しかし、それは価値がありますか？ すでにインフラストラクチャがあり、バックアップ、監視、構成ができるようです。これは、内部サービスの束に対して行います。 ClickHouseサポートに取り組んでみませんか？

移行プロセス

最初に、1台のマシンから小さなClickHouseをインストールし、組み込みツールを使用して、S3からデータをダウンロードすることを定期的に開始しました。 したがって、ClickHouseの速度と機能に関する想定をテストすることができました。



データの小さなコピーで数週間テストした後、RedshiftをClickhouseに置き換えるには、いくつかの問題を解決する必要があることが明らかになりました。

• 展開するインスタンスとディスクの種類。
• レプリケーションを使用するには？
• インストール、構成、および実行方法。
• 監視方法
• どのようなスキームになりますか。
• S3からデータを配信する方法。
• すべてのクエリを標準SQLから非標準に書き換える方法は？

インスタンスとディスクの種類 。 プロセッサ、ディスク、およびメモリの数について、現在のRedshiftのインストールに基づいて構築することを決定しました。 ローカルNVMeディスクを備えたi3インスタンスを含むいくつかのオプションがありましたが、各インスタンスでr5.4xlargeと8T ST1 EBSの形式のストレージで停止することにしました。 見積もりによると、これにより、Redshiftと同等のパフォーマンスが半分のコストで得られるはずです。 同時に、EBSディスクを使用することで、Redshiftの場合とほぼ同じように、スナップショットディスクを使用した簡単なバックアップとリカバリが可能になります。



レプリケーション 。 すでにRedshiftにあるものから始めたので、レプリケーションを使用しないことにしました。 さらに、これにより、まだインフラストラクチャにないZooKeeperをすぐに調査する必要はありませんが、オンデマンドでレプリケーションを実行できるようになったことは素晴らしいことです。



設置 これが最も簡単な部分です。 十分に小さいAnsibleロール。既製のRPMパッケージをインストールし、各ホストに同じ構成を作成します。



モニタリング すべてのサービスを監視するために、PrometheusはTelegrafおよびGrafanaと一緒に使用されるため、ClickHouseでホストにTelegrafエージェントを配置するだけで、Grafanaでダッシュボードを収集し、プロセッサ、メモリ、ディスクごとの現在のサーバー負荷を示しました。 Grafanaへのプラグインを介して、このダッシュボードに、クラスターに対する現在アクティブなリクエスト、S3からのインポートのステータス、およびその他の有用なものをもたらしました。 AWSコンソールを提供するダッシュボードよりもさらに優れた、より有益な（そして非常に高速な）ことが判明しました。



スキーム Redshiftで最も重要な間違いの1つは、メインイベントフィールドのみを別々の列に配置し、追加にほとんど使用されないフィールドを追加することでした

1つの大きな列のプロパティで。 一方で、これにより、収集するイベントを正確に把握できなかった初期段階でフィールドを変更する柔軟性が得られました。また、プロパティは1日に5回変更されました。 一方、大きな列のプロパティのリクエストには時間がかかりました。 ClickHouseでは、正しいことをすぐに行うことにしたので、可能なすべての列を収集し、それらに最適な型を入力しました。 結果は、約200列のテーブルです。



次のタスクは、ストレージとパーティション化に適切なエンジンを選択することでした。

彼らは再びパーティション化については考えませんでしたが、Redshiftで行ったのと同じことをしました-毎日のパーティションですが、現在はすべてのパーティションが1つのテーブルになっています。

リクエストを大幅に高速化し、メンテナンスを簡素化します。 ストレージエンジンは、単にOPTIMIZE ... FINALを実行することで、特定のパーティションから重複を削除できるため、ReplacingMergeTreeによって取得されました。 さらに、エラーや事故が発生した場合、毎日のパーティションスキームにより、1か月のデータではなく1日のデータのみを処理できます。



s3からClickHouseへのデータの配信 。 これは最も長いプロセスの1つでした。 S3のデータはJSONであり、Redshiftで行ったように、各フィールドを独自のjsonpathで抽出する必要があるため、組み込みのClickHouseツールを使用してダウンロードできませんでした。また、変換DD96C92F-3F4D-44C6-BCD3-E25EB26389E9



はバイトに変換し、FixedString型（16）に入れます。



RedshiftのCOPYコマンドに似た特別なサービスが欲しかったです。 彼らは準備ができていなかったので、私はそれをしなければなりませんでした。 仕組みについては別の記事を書くことができますが、要するに、これはClickHouseを使用してすべてのホストにデプロイされたHTTPサービスです。 それらのいずれかを参照できます。 要求パラメーターは、ファイルの取得元のS3プレフィックス、JSONから列のセットへの変換のためのjsonpathリスト、および各列の変換のセットを指定します。 要求の送信先のサーバーは、S3上のファイルのスキャンを開始し、解析作業を他のホストに分散します。 同時に、インポートできなかった行をエラーとともに、別のClickHouseテーブルに追加することが重要です。 これは、イベント受信サービスとこれらのイベントを生成するクライアントの問題とバグを調査するのに非常に役立ちます。 インポーターをデータベースホストに直接配置することで、複雑な要求が24時間それらに送信されないため、原則としてアイドル状態のリソースを利用しました。 もちろん、さらにリクエストがある場合は、いつでもインポーターのサービスを別のホストに移動できます。



外部ソースからのデータのインポートに大きな問題はありませんでした。 これらのスクリプトでは、宛先をRedshiftからClickHouseに変更しました。



毎日コピーを作成するのではなく、辞書形式でMongoDBを接続するオプションがありました。 残念ながら、辞書は必ずメモリに収まらなければならず、MongoDBのほとんどのコレクションのサイズはこれを許可しないため、収まりませんでした。 しかし、辞書も有用でした。辞書を使用すると、MaxMindからGeoIPデータベースに接続してクエリで使用するのに非常に便利です。 このために、サービスによって提供されるレイアウトip_trieおよびCSVファイルを使用します。 たとえば、geoip_asn_blocks_ipv4辞書の構成は次のようになります。

 <dictionaries> <dictionary> <name>geoip_asn_blocks_ipv4</name> <source> <file> <path>GeoLite2-ASN-Blocks-IPv4.csv</path> <format>CSVWithNames</format> </file> <\/source> <lifetime>300</lifetime> <layout> <ip_trie /> </layout> <structure> <key> <attribute> <name>prefix</name> <type>String</type> </attribute> </key> <attribute> <name>autonomous_system_number</name> <type>UInt32</type> <null_value>0</null_value> </attribute> <attribute> <name>autonomous_system_organization</name> <type>String</type> <null_value>?</null_value> </attribute> </structure> </dictionary> </dictionaries>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この設定を/etc/clickhouse-server/geoip_asn_blocks_ipv4_dictionary.xml



に配置するだけで十分/etc/clickhouse-server/geoip_asn_blocks_ipv4_dictionary.xml



。その後、ディクショナリにクエリを実行して、IPアドレスでプロバイダーの名前を取得できます。

 SELECT dictGetString('geoip_asn_blocks_ipv4', 'autonomous_system_organization', tuple(IPv4StringToNum('192.168.1.1')));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

データスキーマを変更します 。 上記のように、事故や計画された作業が発生した場合にアクセスできなくなり、データのコピーはすでにs3にあり、妥当な時間内にClickHouseに転送できるため、レプリケーションをまだ使用しないことにしました。 レプリケーションがない場合は、ZooKeeperを展開しませんでした。また、ZooKeeperがないため、DDLクエリでON CLUSTER式を使用できなくなります。 この問題は、各ClickHouseホストに接続する小さなPythonスクリプト（これまでに8つしかありません）によって解決され、指定されたSQLクエリを実行します。



ClickHouseの不完全なSQLサポート 。 リクエストをRedshift構文からClickHouse構文に転送するプロセスは、インポーターの開発と並行して行われ、主にアナリストチームによって処理されました。 奇妙なことに、問題はJOINでも、ウィンドウ関数でもありませんでした。 配列とラムダ関数を使用してそれらを実行する方法を理解するには、数日かかりました。 この問題がClickHouseに関するレポートでよく取り上げられているのは良いことです 。たとえば、 events.yandex.ru / lib / talks / 5420など、膨大な数があります。 この時点で、データはすでに2つの場所に一度に書き込まれています：Redshiftと新しいClickHouseの両方にあるため、リクエストを転送するときに結果を比較しました。 プロパティの1つの大きな列を削除し、ほとんどのクエリが必要な列でのみ動作し始めたため、速度を比較することは問題でしたが、当然、大幅に増加しましたが、プロパティ列が参加しなかったクエリは同じ方法で動作するか、少し速くなりました。



結果は次のスキームです。

結果

結論として、次の利点がありました。

• 90ではなく1つのテーブル
• サービス要求はミリ秒で実行されます
• コストが半減しました
• 重複するイベントを簡単に削除する

また、準備ができている欠点もあります。

• 事故の場合は、自分でクラスターを修復する必要があります
• スキーマの変更は、各ホストで個別に行う必要があります
• 新しいバージョンへの更新は自分で行う必要があります

データスキームが大幅に変更されたため、リクエストの速度を正面から比較することはできません。 多くのクエリは、ディスクから読み取るデータが少ないために高速になりました。 良い方法で、そのような変更はRedshiftで行わなければなりませんでしたが、ClickHouseへの移行と組み合わせることが決定されました。



すべての移行と準備には約3か月かかりました。 彼女は7月の初めから9月末まで歩いて、2人の参加を要求しました。 9月27日、Redshiftをオフにして以来、ClickHouseのみに取り組んでいます。 すでに2か月強でした。 この用語は短いですが、これまでのところ、クラスター全体が立ち上がるため、データ損失や重大なバグに遭遇したことはありません。 私たちの前に新しいバージョンの更新を待っています！