けしからん画像分類器を作ってみる (6) データ管理 その2

目次

• けしからん画像分類器を作ってみる (1) 序章
• けしからん画像分類器を作ってみる (2) データ収集 その1
• けしからん画像分類器を作ってみる (3) データ収集 その2
• けしからん画像分類器を作ってみる (4) データ収集 その3
• けしからん画像分類器を作ってみる (5) データ管理 その1
• けしからん画像分類器を作ってみる (6) データ管理 その2（本記事）
• けしからん画像分類器を作ってみる (7) 学習 その1
• けしからん画像分類器を作ってみる (8) 学習 その2
• けしからん画像分類器を作ってみる (9) 推論
• けしからん画像分類器を作ってみる (10) 公開
• 番外編:
  • EfficientNet B0〜B7で画像分類器を転移学習してみる
  • EfficientNet B0のKerasモデルをONNXモデルに変換して推論する
  • 類似画像検索ツールを作ってみる (1) 序章

続 データ管理

前回に続き、学習に使用するデータの管理について述べたいと思います。

データ管理に関して工夫した点、上手くいった点などは以下の通りです。（再掲）

• 使用するハッシュアルゴリズムを1つに絞りました
• URLはハッシュ値で管理しました
• データはハッシュ値で管理しました
• データはGitで管理しました
• データはNFSを経由して読み書きしました
• データはOverlayFSでマージして参照しました

前回は前半3つを紹介したので、今回は後半3つについて書きたいと思います。

データはGitで管理しました

収集したデータ（HTML、画像、動画、それらのメタ情報）は、分散バージョン管理システムである「Git」で管理しました。
理由は以下の通りです。

• ソースコードの管理のためにGitを既に使っており、使用するツールを増やさずに済む。
• 個人の写真の管理にも使用しており、数十GBのデータを管理する実績があった。
• 差分バックアップを行いやすい。（他のマシンに転送しやすい）
• タグを打つことができる。

Gitリポジトリは、データを収集するサイト毎に分割しました。参考に、サイト毎のリポジトリのサイズを以下に示します。

サイト	容量
サイトC	32 GB
サイトI	8.6 GB
サイトO	15 GB
サイトS	69 GB
サイトX	0.9 GB
合計	125 GB

一方でデメリットもいくつかあります。

• リポジトリ本体（.gitディレクトリ）と作業ディレクトリの両方でストレージ容量を使用するため、容量効率が悪い。
• 転送時の圧縮に時間がかかる。
  • JPEGやMP4はそもそもそれ以上の圧縮は期待できないので、転送時の圧縮を無効化する方法があると良いのですが、見つけられませんでした。情報求む！

データはNFSを経由して読み書きしました

データを収集するクローラはDockerコンテナ内で動作し、そのDockerコンテナにデータを格納しているディレクトリをNFS経由でマウントしました。Docker Composeの設定ファイルにマウントの設定を書いておけば楽チンです。

上記の通りデータは125GBと大きいため、マシンを越えた移動やコピーにはそれなりの時間が掛かります。
NFS経由で共通のストレージをマウントすることでデータの移動やコピーを最小限にでき、かつ好きな場所（マシン）でクローラを動かすことができます。

実際、GPUが搭載されたLinuxマシンにデータを置き、手元のMacBook Proからマウントしつつクローラの開発を進めました。
ネットワークを経由したストレージI/Oなので速度は期待できませんが、そもそもインターネットからのダウンロードの方が圧倒的に遅いので、たいして気になりませんでした。

データはOverlayFSでマージして参照しました

上記の通り、データを格納するリポジトリはサイト毎に分割しました。
また、前回の記事の通り、学習に使用する主なデータ（画像、動画）は、オブジェクトID（ハッシュ値）をキーとしてパスを決定し、格納しました。

それらはそれらで上手く機能しているのですが、サイト毎にパスを切り替える必要があり不便です。
そこで複数のディレクトリをOverlayFS（英語版Wikipedia）でマージ（オーバーレイ）し、サイトを気にすることなくオブジェクトIDでデータを参照できるようにしました。

例えば以下の様な、2サイトから取得した2ファイルがある場合を考えます。

• site_a/
  • object/
    • 59/
      • 5c/
        • 595c3cce2409a55c13076f1bac5edee529fc2e58.jpg
• site_b/
  • object/
    • 0b/
      • ee/
        • 0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33.jpg

site_a/object/とsite_b/object/という2つのディレクトリをOverlayFSでマージすることで、サイトを気にすることなくオブジェクトIDで参照できるようになります。

• object/
  • 0b/
    • ee/
      • 0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33.jpg
  • 59/
    • 5c/
      • 595c3cce2409a55c13076f1bac5edee529fc2e58.jpg

注意点は、参照専用（読み取り専用）であることです。仕組み上は書き込みもできますが、書き込み用ディレクトリに書き込まれることになり、管理上不便です。
クローラはsite_a/object/、site_b/object/などに直接書き込むため、問題は生じません。
当初はシンボリックリンク、ハードリンクを使って参照していましたが、OverlayFSを使うとマウント1回で済むため、とても便利です。

今回はここまで

データ管理に関する6つのトピックの内、残りの3つを紹介しました。
次回は「ラベル付け」（アノテーション）について書きたいと思っています。今日はここまで！

「けしからん画像分類器を作ってみる (7) 学習 その1」に続く。