並行処理を実現するアイディアを実装してみた．- Idea for data persistence in Pararell Processing

未だに本ブログにおいて自分が作成したメインプログラムの解説を行っていないのだが(笑)

私はNYTimesの記事をスクレイピングするプログラムを作成した．本日はそれにまつわる内容だ(笑)

で，NYTimesは1996年?以降の記事に関しては積極的にオンライン掲載を行ってきたのであるが，それ以前の記事はアーカイブとして管理されている．

アーカイブの記事のうち，1960年代とか割と最近の記事に関してはその内容をデジタルテキストとして同様に掲載してくれている．

だが，それ以前の記事に関してはPDF画像として公開しているものが多い．

そのため，PDF画像として公開している記事の文章を取得したい場合には一筋縄では行かない．

そこで，私はOCRを用いてテキストデータに変換して取得するという方針にして，そのプログラムを作成したのである．

その概念図は次のようになっており，番号が振られているように3つの過程で分割され，それぞれの過程の処理を行うためのメインプログラム？的なものをそれぞれ作成した．

作成したプログラムを実行してみたところ，約5年分のデータに対して

ステップ1の実行速度が5時間だとすると，

ステップ2の実行速度は約1日から1日半程度

ステップ3の実行速度は約2週間程度

となっており，仕方ないことだがステップ3にとてつもなく時間がかかる．

この問題を何とかするために，次の2つの方法を思いついた．

ステップ1を実行している最中に，別のターミナルでステップ2やステップ3を実行して，若干逐次的なイメージでデータを処理していく．
最終的にステップ2が終了して，ステップ3のみが残っているという状態に陥る．その時に，複数のターミナルでステップ3を実行する．要するに，同時に3つぐらいのファイルにOCRの処理をかけているという状態を実現する．

だが，これをやっていく上で問題になってくるのがpersistenceやログ的な問題である．

あるターミナルでステップ1の処理のループの一つを終えて，一旦データファイルを保存して（更新して）から次のループを処理しているとする．その直後に同様に一部のループ処理を終えたステップ2の方でデータファイルを保存して更新したとする．

このステップ2の更新後のデータファイルには，きちんとステップ1の処理による更新内容が引き継がれていなければならないのである．

こういった類の問題のことをどのような名前で読んでいるのかがわからないのでくどくどと長い説明になってしまったが，今回はこの対策案について考えた結果をここに記す．