pandazx's blog

データ分析など雑多な技術ブログ

EC2のGPUインスタンスにChainerインストール

DeepLearning

前提

基本的には以下のサイトを参考にすればよい。

その際に、ハマったことだけメモ。

最初、NVIDIA GPU DRIVER入りのAMIを使って、EC2を作成したが、CUDA ver6.5であることに気づかず、cuDNN v4をインストールしてしまった。 この状態で、サンプルのtrain_mnist.py を実行すると以下のWARNINGが出る。

 'cuDNN is not enabled'

CUDA ver6.5 に対応するcuDNN v2をインストールして、Chainerを再インストールしたが、状況は変わらなかった。公式ドキュメントに書いてあるが、 以下のように、クリーンインストールすることで解決。

pip uninstall chainer
pip install chainer --no-cache-dir

Chainer公式ドキュメント：Install Guide — Chainer 1.7.2 documentation

HyperLogLogメモ

何かのデータベースソフトウェアでカーディナリティを計算するためにHyperLogLog使ってる、という記述があり、 HyperLogLogがわからん。ということで調べた時のメモ。

まずは、Wikipedia様。

HyperLogLog - Wikipedia, the free encyclopedia

HyperLogLogはデータのカーディナリティを推定する手法の１つ。 詳細は全然わかっていないが、バイナリにおけるLeading Zeros（先頭から0が続く数）の最大値をnとした場合、 2のn乗をカーディナリティの推定値とするアルゴリズム。

調べていくと、以下のスライドを発見。計算例も記載されている。

www.slideshare.net

これを読むと、カーディナリティの値が低いと（1000以下ぐらい？）、HyperLogLogの推定誤差が大きくなり、使えないらしいことがわかる。 そして、それを改善するために、Historic Inverse Probability Estimator(HIP Estimator)という手法が最近、提案されている。 資料後半には手法による誤差を比較したグラフがあり、HIP Estimatorが優れていることを示している。

使い道

データベースのテーブル定義にはカーディナリティいくつと設定しないので、データベースがカーディナリティを把握するのに使える。

データ分析においてはどうか。

カーディナリティが10以下など小さい場合、そもそも、設計者が正確にカーディナリティを把握している可能性が高いので、推定する必要がない。 サービス全体のユーザ数はわかっているが、ある期間のアクセスログから、アクティブユーザ数をざっくりでいいから、とにかく早く計算したい場合に使えるかもしれない。

Cookpad TechConf 2016に行ってきた

勉強会

日時：2016/1/23

以下、完全にただのメモ。読みやすさゼロ

おでかけスポット検索の難しさ

  • 検索：どこで + だれと、いつ、なにを
  • 初期は全文検索
  • 中目黒は住所的な中目黒ではない
  • など、ノイズ、検索対象にズレが出てしまっていた
  • 他に中目黒駅とした場合に、駅からの距離が考慮できていなかった
  • Elasticsearchを使用

形態素解析

  • Kuromoziは中目黒駅を駅として認識できなかった
  • NEologdを導入
  • 新語、流行語に対応している
  • 辞書は2週間に一度、updateされる
  • そのupdateは今は手動で開発者が行っている

Railgアプリ開発環境の高速化

発表者：@k0kubun

検索ページのロード時間が10秒かかっていたので、色々なキャッシュを使って高速化した話。 不要なライブラリを読まないなど。そもそも、ブラウザキャッシュが無効になってた

プリセットコンパイルに23分かかっていたのを1分に短縮した話。並列コンパイルや、差分コンパイラの導入。Sprocketsを4にアップデートすることで、RubyがC++になって高速など。

R&D in foodtech company

発表者：有賀、@chezou

  • NIIでクックパッドデータを提供
  • 1年で55大学81研究室が利用
  • たべみるサービスを学術機関向けに無償アカウント提供開始
  • アプリエンジニアでも機械学習を使ったサービス開発をしている事例がある
  • データからカテゴリを自動で生成。SVMを使用。これを以下に横展開

おまかせ整理

  • 大量にある、お気に入りを自動分類
  • 例、麺類を分けたい
  • アプリエンジニアが自分で試行錯誤できる仕組みを開発
  • テストデータで精度がデグレしたら、ストップする仕組みもある

技術を事業の競争力にするために

発表者：大野

  • 責任範囲とリーダーシップ
  • 成果で評価

開発した技術をプロダクト開発手法

発表者：五十嵐

  • 技術→製品→価値ではなく、価値→製品→技術という順番で考える
  • 新しい技術が出来ても、すぐに使いたい欲求を、ぐっと堪える

今日なに作ろうを支えるデザイン

発表者：木村

  • デザイナーとエンジニアの協業について
  • よく使うアイコンをフォント化
  • いちいち、画像を作る必要がなくなる
  • ファイルサイズの削減

確かめながら作るユーザ体験

発表者：出口

メモなし

インタラクション

発表者：デザイナー多田

モバイル開発の標準を探る

発表者：FUJI GORO

  • コードレビューは誰がどうやっている？工夫など
  • クックパッドでも、善意で成り立っている

DWHに必要なこと

発表者：Aoki

  • Redshift使用
  • 生データ、横断型データ、アプリデータと3層構造に分けている
  • 層間のデータ移動はINSERT SELECT
  • 一度、外にエクスポートして加工して戻すのは悪手。ビッグデータでは通用しない

開発と運用の失敗と成功

発表者：成田

ColdFusionからRailsに移行した時に、事業的に痛みが大きかったが、あれがあったからこそ、今のクックパッドがあり、ソフトとインフラのアップデートの重要性を理解する組織になっている

Hadoopソースコードリーディング 第20回に行ってきた

Hadoop HBase

久しぶりの参加。 www.eventbrite.com

本日のお品書き

  • Apache Kylin: Materialized View for Big Data
  • Apache Phoenix: Relational database layer over HBase
  • Upgrading from HDP2.1 to HDP2.4

Kylin, Phoenixって何だろう、という動機で参加。どちらもHBaseをデータソースとして、ユーザにSQL I/Fを提供するソフトウェア。

KylinはOLAP on HBase, PhoenixはSQL on HBaseという感じ。 Kylinはアドホッククエリが苦手で定型レポートのDBに向く。 Phoenixはデータセットをクライアントでマージするので、結果が巨大だとつらい。

どちらも参考になったが、一番興味を惹かれたのは両者が使う／使う予定のSQL Parser「Apache Calsite」の存在。 Hiveでも、コストベース最適化として、これを利用している（Hiveのクエリを何倍も速くする４つの方法 - Qiita）

Apache Kylin: Materialized View for Big Data

Yahoo! Japan. 古山慎悟

Kylin概要

  • Kylinの最初の開発元eBay
  • OLAP on HBase
  • キューブをpre-buildしてHBaseに配置しておくことで、高速なReadアクセスを実現
  • ANSI SQL対応。TableauなどのBIツールをフロントに使える
  • kafkaのストリームデータを入力にキューブ作成可能

アーキテクチャ

  • 入力は基本、Hive table。Hiveにデータストアするまではユーザが自分で行う
  • １つのキューブがHTableに対応
  • データの物理配置はHBaseのCoprocessorを使って工夫している

Kylinの強み

  • 多重度の歪み、ファクトの歪みに強い
    • 例えば、特定顧客が8割の売りげを占めているような場合
  • 事前にpre-buildでキューブを作っているので、レイテンシがデータボリュームに依存しない

Kylinの弱み

  • 多重度が高いとキューブのpre-build時間が極端にかかり、サイズも大きくなる。クエリのレイテンシも大きくなる
    • そのため、なるべく多重度や次元を減らして組み合わせ数を減らす設計が必要
    • 例えば、多重度が100万を超えると厳しくなる
  • 事前にキューブを作成する必要があるため、アドホックなクエリに対応できない

キューブのセグメントとインクリメンタルビルド

  • キューブは複数のセグメントキューブで構成される
  • キューブの運用において、前回以降の差分を更新できる
  • インクリメンタルビルドはストリームビルドとは異なる概念

Mandatory Dimension

  • クエリする際に常に使うキーを指定することで、指定しない場合のcuboidを計算しなくてよくなる
  • ex) user_id

Hierarchy Dimension

  • メモれず（名前からして、階層関係を定義してあげることで、不要なディメンジョンの組合せ数を減らすのだと思う）

Derived Dimension

  • ID、名前、生年月日のディメンジョンがある場合に、IDだけをキューブに参加させて、名前でクエリされた場合に、インメモリで対応関係を処理する
  • （なんで高速処理できるのか、わからなかったので講演者も使っていなかったので確認できず）
  • （メモリ上でキューブに名前、生年月日をひも付けた状態で展開しておくということ？それならサーバのメモリ制約がありそう）
  • この辺のDocumentは充実していないらしい

Benchmark performance

  • 構成：21 slave nodes, 16cores-32threads, 128GB mem, 12disk/node, HDP2.2
  • Data
    • Record: 500 billion over
    • Cardinality: Maxで5 million over
  • Result
    • pre-build time: 20h
    • SELECT user, sum(a), sum(b), sum(c) FROM tableで、latency = 約4 sec
    • これにGROUP BYや特定ユーザ指定、期間指定を追加して対象データ範囲を絞ることで、レイテンシは小さくなる。1 sec 以下

他の低レイテンシクエリ実行エンジン

  • Presto, Impala, Phoenix, etc
    • OLAPカテゴリとしてはROLAP
    • Kylinとは違い、クエリ時にデータを集めるので、データ量が大きいとつらくなる
  • Druid
    • 機械学習ライブラリがKylinよりも先行
    • 独自実装が多いので普及するかは不透明。Mesos感
  • Kudu
    • Kuduならデータを突っ込んだ瞬間にクエリできるので、Kylinよりも筋がいいかも
    • アドホッククエリにもImpala+Kuduで対応できるが、色々なワークロードが走るところで、Kuduを使って大丈夫かは不明

Kylinを使うためには

  • キューブの設計が出来るアナリストが必要
  • ディメンジョンの組合せ数を減らして、キューブの作成負荷を軽くする
  • アドホッククエリには対応できない
  • 定型レポートを参照するためのOLAPとして使える

参考資料 conferences.oreilly.com

Apache Phoenix: Relational database layer over HBase

Hortonworks Japan. 今井雄太, @imai_factory

  • Phoenixの最初の開発元はSalesforce
  • SQL client libraryとして動作し、データソースとしてHBaseを利用。Region Serverに対して並列に実行
  • Region serverにもPhoenixクエリ実行エンジンを配置
  • ドキュメントが充実
  • SQL parserのApache Calciteを導入予定。CalciteはKylinでも利用している
  • Phoenix tableは裏でHBaseのtableとして作成される
    • この時、カラムはHBaseのcolumnとしてマッピングされ、Column Familyは使われない
  • 既存HBase tableをRead OnlyなPhoenix tableとして使える
  • Multi-Tenancyに対応。詳細不明
  • Salted Tables
    • 32を設定すれば、自動的に32個のテーブルに分割される
    • 実装上は、裏でPKの値にprefixとして値を追加することで実現している
  • Skip scans
    • BaseはRow keyでソートされているので、不要な部分はSkipする仕組み
  • 取得したデータのマージはクライアントで行う
    • 当然、検索結果が巨大な場合は厳しい

HBase Availability

  • Timeline Consistency
    • 同一Regionを異なるRegion Serverに保存

特性

  • Pros
    • SQLが使える
    • パフォーマンスがリニアなスケーラビリティ
  • Cons
    • OUTER JOINできない
    • 並列ワークロード
    • 複雑なJOIN
    • 巨大なデータ取得
  • Use cases
    • SQL DB for BI
      • JOINを避けるためのDe-normalized table
    • Phoenix application
      • HBaseを使うアプリケーションをPhoenixを経由する形にしてもいいのでは？という意見

Benchmark

  • レイテンシを小さくするために、クエリに最適化したテーブルを作ることで、ImpalaやDrillと比較して、チューニングがやりやすい。Key-Value的にテーブルを作ることでHBaseの性能を活かせる

その他

  • Hive + LLAP(Long Lived excecution)との対比
    • 複雑なクエリはHiveが強い
    • Hiveは検索結果をHDFSに書き込んで、ThriftでシリアライズすることをHiveserver2でやるので、そこがボトルネックになるのが難点
  • Hive on TEZ のメリット
    • YARNリソースがある限りは並列度をあげられるのがメリット
    • ノードを追加すれば、リソース増強できる

Upgrading from HDP2.1 to HDP2.4

@wyukawa

今は亡き@tagomorisさんのHDPクラスタ（遺産）をHDP2.4にした話 ピザで手が空いていなかったので、内容は以下参照

www.slideshare.net

@tagomorisさんの過去資料はこちら

www.slideshare.net

HDP2.1を2.2にした話から、2.2を2.4にした話でアレ？ってなるけど、そこは知らない。

ssh接続可能なDockerコンテナ作成

docker

Dockerizing an SSH service

上記Dockerブログを参考にすれば出来る。まず、このブログに書いてあるDockerfileの内容をコピペしたファイルを作成。ファイル名はDockerfile。次に、以下のコマンドを実行。

# Dockerfileがカレントディレクトリにあること
# Ubuntuのコンテナイメージ作成. イメージ名はeg_sshd
sudo docker build -t eg_sshd .

# コンテナ起動. コンテナ名はtest_sshd
sudo docker run -d -P --name test_sshd eg_sshd
# ※ -P でコンテナのすべてのポートをホストに対して公開

# test_sshd コンテナ 22番ポート のポートフォワーディング状況を確認
sudo docker port test_sshd 22

# コンテナにssh ログイン
ssh root@ホストOSのIPアドレス -p 確認したポート
# ※rootのパスはscreencast

IPアドレスはDockerが勝手に設定したものになる。静的IPアドレスを設定するなどしたい場合は、別ブログを参考にしてください。

nvidia-dockerでコンテナからGPUアクセス環境構築

docker cuda gpu

（作業中。ローカルにGPU環境を作らずに、Docker上で作れば、すんなり行くのかもしれないが、未確認）

前提

以下のサイトの通り、一通り、CUDA, cuDNNが使える状態になっていること

Ubuntu 14.04 にChainer1.7.0環境構築 - pandazx's blog

目標

Dockerコンテナ上からGPUを使える環境を構築する。

そのために、nvidia-dockerで環境構築し、Chainerで動作確認する。

作業ログ

  • Docker, nvidia-dockerをインストール
  • コンテナ起動
    • sudo nvidia-docker run -v local_dir:mount_dir:ro --device /dev/nvidia0:/dev/nvidia0 --device /dev/nvidiactl:/dev/nvidiactl --device /dev/nvidia-uvm:/dev/nvidia-uvm -i -t nvidia/cuda /bin/bash
    • -v optionはホストとコンテナの共有ディレクトリ設定
    • -v の :ro は read only 設定
    • local_dirには、CUDAインストール時に作成しているcudaのsampleがあるディレクトリを指定
    • --device はローカルのGPU deviceを指定. 通常、同じパスで問題ないはず
  • 動作確認（以下はコンテナ上での操作）
    • コンテナからGPUが見えるか確認
    • CUDA動作確認
      • cudaのsampleについて、cuda/samples/1_Utilities/deviceQuery/deviceQuery を実行
  • cuDNNインストール
    • インストーラは共有したディレクトリに置いておく
    • あとは、ローカルでやったのと同じようにcuDNNをインストール
  • Chainerインストール
    • train_mnist.py を実行したところ、以下のエラーが発生

RuntimeError: CUDA environment is not correctly set up (see https://github.com/pfnet/chainer#installation).cannot import name core

調査中

Ubuntu 14.04 にChainer1.7.0環境構築

DeepLearning

構築する環境

CUDA7.5, cuDNN v4, Chainer 1.7.0 のインストール

作業ログ

Tips

NVIDIAグラフィックドライバの確認

# TITAN Xが表示されればOK
lspci | grep -i nvidia

CUDAインストール前に、nouveauを無効化するが、その設定確認

# nouveauが表示されなければOK
lsmod | grep nouveau

参考：CentOS 7にNVIDIA GeForce GTX TITAN Xを導入 - Qiita

ハマったこと

  • NVIDIAドライバのインストール確認をGUIでやるために、lightdmをインストールし、ログインしようとするが、なぜか、パスワード入力後にログイン画面に戻される。対応できず、あきらめる。上記Tipsの確認で、確認したことにして先に進んだ

その他

デスクトップサービスの停止

How To : Install NVIDIA 346.59 Graphics Drivers in Ubuntu/Linux Mint Systems ~ Your Own Linux..!