hive.mergeにおけるSTOREと圧縮の問題とワークアラウンド - still deeper
問題 以下のブログでSTOREをTextFileにしてで圧縮を有効にしていると、hive.merge.(mapfiles|mapredfiles)が無視される問題が報告されています。 Hiveのファイル圧縮とSTOREの種類とマージの関係 Hiveは圧縮されたTextFileをインプットにした場合は、複数ファイルのCombineを行わないようなので、圧縮された細かいファイルはsmall files problemによるパフォーマンスの悪化に繋がります。 また、RCFileでもマージはされるようです。が、実運用で用いているデータで試すとマージされないケースがあったので、下記のワークアラウンドを入れておくのが無難だと思います。 対応方法 ダメな形式の複数のMapper(Reducer)からファイルが出力されると、マージされずにそのまま残ります。 現状のワークアラウンドとしては Reducerを
データ解析基盤を構築する前に考慮すべきポイント - still deeper
概要 ここしばらく某社でデータの解析基盤を構築する仕事に携わっています。一からの構築になるので打てる手が多く楽しい一方で、適切な判断を下すのは難しいと実感しています。 解析基盤というのはもちろん解析を行うためのものですので、どう解析を行うかによってどういう基盤を構築していけばよいかが決まります。 ところで、データ（構造や収めているDBなども含めて）というのは寿命の長いもので、初期の設計を間違えてしまうと、その時点で戦略的な敗北は決まってしまいます。その後は運用しながら変更可能なところでゲリラ的に対応していくしか手を打てません。 そのため、実際に構築を行う前に、求められている解析がどのようなものかを十分に吟味した上で、適切なハードウェア、ミドルウェア、データ構造を選択し基盤を構築していくことが大変重要です。 着目すべき点 では解析のどのような点に着目すればよいかというと、私は次の5点を考えて
Impala Q&A - still deeper
2012/11/7に開催されたCloudera World Tokyoに参加してきました。 本編については他の人がまとめてくれるはずですので省略。 懇親会では米国Cloudera社のCTO、Dr. Amr Awadallah氏に直接Impalaの疑問に答えていただきました。非常に貴重な話を聞けたのでまとめておきます。（公開許可済み） その場でメモを取っていたわけではなく思い出しながらのまとめなので、一緒に聞いていた方、clouderaの方は補足をお願いします。 Q&A Q. なぜJavaでなくてC++で実装したか？ A. ImpalaのメインデザイナーがGoogleでC++を使って分散処理(Dremelのこと？)を実装した人物であるのと、JVMの起動コストがレイテンシーの増加につながるため 補足: この人でしょうか Q. 1ノードに偏ったデータを読む必要があるクエリがくると低レイテンシーを
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
