はじめに
こんにちは。Turing MLOpsチームの塚本です。
自動運転AIの性能を高めるには、モデルの改良だけでなくデータの量と質が何より重要です。Turingでは「データセントリックAI」の考え方のもと、1日あたり20TBを超える膨大なセンサーデータを活用し、大容量、高品質かつ多様性のある学習データセットの構築に取り組んでいます。
学習データセットのファイル数は、画像データだけでも数億を超えています。この規模になると、inode の枯渇やアップロード・削除といった運用上の負荷が一気に増大します。さらに、TuringのE2Eモデル学習では高速なランダムアクセスが要求されます。
本記事では、これらを解決するために導入した、Webdataset の Indexed Dataset(wids) を解説します。
End-to-End自動運転の学習データセット
学習データセットは以下の要素で構成されます。
- 複数台の車載カメラによる画像データ
- LiDAR 点群
- 3D 物体検出ラベル
- CAN（Controller Area Network）ログ
- 地図情報 など
E2Eモデルの高度化をめざし、収集データの中から高品質かつ多様性に富むデータのみを抽出してデータセットを作成します。
データセットはETLパイプラインを通じて S3 に格納され、そこから学習環境へコピーされます。
従来型データセットの課題
従来の学習データセットでは、すべてのオブジェクトを個別ファイルとしてそのまま管理していましたが、データ量増加に伴い次のような問題が顕在化しました。
1.S3 への COPY リクエスト増加
ETL パイプラインで S3 に格納した後、学習環境へファイルをコピーしますが、ファイル数分だけ COPY リクエストが発生します。S3 には「1 秒あたりリクエスト数」の制限があるため、転送速度がファイル数に律速されてしまいます。
2.inode 枯渇のリスク
学習環境上のオブジェクト数にも上限があり、これを超えると inode が枯渇する恐れがあります。そのため、ファイル数をむやみに増やすこともできません。
大規模データセットのアーカイブ戦略
アーカイブされたデータセットをアクセスする方法として、TFRecordやtarファイルをロードできるWebDatasetがよく利用されます。Turingでも、過去にこれらのライブラリをご紹介しています。
TFRecordやWebdatasetは、アーカイブデータに対するシーケンシャルアクセスを前提としています。
TuringのE2Eモデルはランダムアクセスとシーケンシャルアクセスの両方に対応する必要があります。
そのため今回採用したのが wids です。widsはWebDatasetのサブセットで、ランダムアクセスを実現するライブラリを提供します。
widsの特徴
tarファイルは、ヘッダとデータが交互に格納されています。
tarに対してランダムアクセスするためには、事前に各データに対するバイナリオフセットを把握する必要があります。
widsは、ファイルアクセス時にオフセットを事前スキャンし、インデックス化します。
この時データがメモリにロードされ、インデックス指定でアクセスできるようになります。
widsの利用方法
widsのインストール
webdatasetをpipインストールします。これによりwidsも合わせてインストールされます。
pip install webdataset
tarファイルの準備
widsでアクセスするファイルは、普通のtarファイルです。
ここでは、以下のように画像ファイルがアーカイブされている物を利用します。
$ tar -tf scene-001.tar | head
IMAGE_001.jpg
IMAGE_002.jpg
IMAGE_003.jpg
IMAGE_004.jpg
IMAGE_005.jpg
IMAGE_006.jpg
IMAGE_007.jpg
IMAGE_008.jpg
IMAGE_009.jpg
IMAGE_010.jpg
メタファイルの作成
widsでは、JSONのメタファイルを経由してtarファイルにアクセスします。メタファイルは
widsindex というコマンドから作成できます。このコマンドはwebdatasetをインストールされます。
widsindex create IMAGES.tar -o IMAGES-idx.json
データアクセス
SharedListDataset のインスタンスを作成することで、datasetを作成します。
この時、メタファイルのpathを引数に渡します。
作成されたdatasetはindex指定でtar内のデータにアクセスすることができます。
import wids
idxpath = "/data/IMAGES-idx.json"
dataset = wids.ShardListDataset(idxpath)
image = dataset[3][".jpg"] # IMAGE_004.jpg
性能比較
データアクセス
画像を直接ロードする場合と、widsを使ってtarからロードする場合の性能を比較します。
tarファイルは960ファイルがアーカイブされたものから12ファイルをランダムサンプリングし、個別画像ロードのシナリオでも同じファイルにアクセスします。
| ファイル番号 | 画像個別ロード | widsロード |
|---|---|---|
| ファイル1 | 0.029477秒 | 1.086504秒 |
| ファイル2 | 0.005353秒 | 0.004193秒 |
| ファイル3 | 0.005391秒 | 0.004449秒 |
| ファイル4 | 0.006454秒 | 0.003985秒 |
| ファイル5 | 0.004572秒 | 0.003138秒 |
| ファイル6 | 0.005094秒 | 0.004310秒 |
| ファイル7 | 0.004720秒 | 0.004235秒 |
| ファイル8 | 0.005098秒 | 0.003158秒 |
| ファイル9 | 0.005173秒 | 0.004419秒 |
| ファイル10 | 0.005556秒 | 0.004036秒 |
| 合計時間 | 0.076888秒 | 1.122427秒 |
widsロードでは、初回のみ1秒程度かかっています。これは前述の通りオフセットの事前スキャンを行っている影響です。2回目以降は個別画像ロードとほぼ同等の速度でアクセスが可能です。
widsロードは画像個別ロードの10倍以上の時間がかかりますが、Turingのモデルの学習ではデータローダーのプリフェッチ時間内に十分収まるものとして、性能要求を満たしました。
S3転送
次に、個別ファイルとtarファイルのS3転送時間を比較しました。
960ファイル、合計163MBのデータを個別に転送した場合と、tarアーカイブした場合でap-northeast-1からus-west-2のs3バケット間転送を行います。
| コピー対象 | コピー時間 |
|---|---|
| 個別ファイル | 29.549秒 |
| tarファイル | 4.328秒 |
tarファイルの方が6.8倍程度速い結果となりました。S3はファイルサイズが大きくなると自動的にファイル分割して並列にコピーするため、個別ファイル転送と比較して時間が短縮されます。
最後に
今回のwids導入事例は、学習環境の効率化に大きく貢献しました。今後も、データ規模の増大ともに、さらなる進化が必要です。
そのためには大規模データを効率よく扱うデータエンジニアリングや、学習環境を取り扱うクラウド基盤開発が不可欠です。
Turing、大規模クラウド基盤を改善・運用できる経験豊富なソフトウェア開発者を募集中です。興味のある方はぜひ採用ページからご応募ください！カジュアル面談やオフィス見学などライトな交流も大歓迎です！
Discussion