0

EC2 datastax amiを使用した DSE 3.1.3 Cassandra の評価。

テストのセットアップ

  1. 1 つのテストで 5 x m1.xlarge: 4vcpus、15G、4x420G インスタンス ストア。
  2. 別の 5 x hi1.4xlarge: 16vcpus、60G、2x1TB SSD インスタンス ストア。

データ

  • 5000 以上の Apache ログ ファイル、最大 60GB、60MM 行。

ワークフロー

  1. dse hadoop fs -put を介して CFS にロードします。
  2. RegexSerDe を使用して CFS から Hive にロードします。
  3. キースペース ログで CQL を介して Cassandra にイベント テーブルを作成します。
  4. INSERT INTO logs.event を介してハイブから Cassandra に挿入します。

全体として、最初の 2 つのステップのパフォーマンスと基本的なクエリは、他の Hadoop スタックと同等です。また、外部テーブルを明示的に定義しなくても、Hive から直接 Cassandra テーブルを簡単に参照できることは素晴らしいことです。

ただし、INSERT 操作には、他の一般的な Hadoop スタックよりも 3 ～ 4 倍の時間がかかります。何か間違った設定をしたに違いないので、助けや提案を探しています。

基本的な外観から、hive INSERT コマンドを実行したノードの CPU は 12 ～ 16 で実行されており、他の 4 つのノードは 1 ～ 2 の CPU を示していることが明らかです。また、書き込み要求はすべて同じノードに送信され、他のノードには送信されません。

私の仮定では、Hive は作業を各ノードに分散 (プッシュダウン) し、これは一般的な Hadoop スタックで行われているようです。

それ以外の場合、キーはランダムであり、データ負荷はノード間でバランスよく増加します。キースペースは次のように作成されました。

CREATE KEYSPACE logs WITH REPLICATION = { 'class' : 'SimpleStrategy', 'replication_factor' : 1 };

ジョブトラッカー/タスクの詳細を見ると、ジョブはノード間で分割されています。しかし、ステータス列からは、cfs へのすべての呼び出しが、ジョブが開始されたノードを介してルーティングされているように見えます。

cfs://10.0.0.21/user/hive/warehouse/event/1:2483027968+67108864

構成の問題であることを願っています。他の提案も受け付けています。しかし、このアプローチは、他のスタックと同じように機能する場合、確かに非常にシンプルです。

4

1 に答える 1