読者です 読者をやめる 読者になる 読者になる

無駄と文化

実用的ブログ

Scrapy でエラーハンドリング for v1.1.3 (※一部未解決)

Python Scrapy

f:id:todays_mitsui:20160827190511p:plain


突然ですが Scrapy v1.1.0 から Python 3 に対応して嬉しいですね。これまで Scrapy のために 2.7 で通してきたんで。


さて、今回は Scrapy における エラーハンドリング(例外処理) についてまとめようと思います。

スクレイピングという行為は外部の構造化されていないデータを取ってくるものなので例外はつきものです。
例外が投げられたとき 何となく正常終了したように見せる ことは厳禁です。例外から正しく復帰させるか、または例外が投げられたならば正しく落とすことが重要です。
でないと、その後に例外に気づいて調節→リトライできませんからね。


Scrapy データフローに沿ったエラーハンドリング

スクレイピング中に起こる不測の例外をキャッチするために通常の try ... except 文を使う事はできません。
なぜなら、我々が記述した Spider を実際に起動するのは Scrapy エンジンだからです。

我々は parse() メソッドを実装することはあっても、parse() メソッドに response を食わせて呼び出すことはしません。parse() メソッドの呼び出しは Scrapy エンジンの管轄になります。

では parse() メソッドでの処理中に投げられた例外は誰が面倒を見るのでしょうか?
デフォルトでは Scrapy エンジンが控えめにログに書き出してくれます。が、その動作をカスタマイズすることは可能です。


Scrapy でエラーハンドリングするために (私の観測範囲では) 以下の3種類の方法があります。

  1. Request オブジェクトを生成するときに errback を渡す
  2. Spider の spider_error シグナルをキャッチする
  3. Spider Middleware の process_spider_exception で処理する

それぞれ解説していきます。


1. Request オブジェクトを生成するときに errback を渡す

スクレイピング中、parse() メソッドの中で scrapy.Request のインスタンスを返すと、スクレイピング対象 URL を追加できます。
そのとき errback という名前付き引数に関数を渡してあげると、レスポンスの取得に失敗したときにその関数が呼ばれます。

こんな風に、

# spiders/foo.py

import scrapy
from scrapy import Request


class FooSpider(scrapy.Spider):
    name = "foo"
    allowed_domains = ["httpbin.org"]
    start_urls = (
        "http://www.httpbin.org/",           # ステータスコード: 200
        "http://www.httpbin.org/status/500", # ステータスコード: 500
    )

    def start_requests(self):
        for url in self.start_urls:
            yield Request(
                url,
                callback=self.parse,
                errback=self._errback # 200 以外が返ったときに呼ばれる
            )

    def parse(self, response):
        return {
            "url": response.url,
            "status": response.status,
        }

    def _errback(self, failure):
        self.logger.error("### ERRBACK ###")
        self.logger.error(failure.type)
        self.logger.error(failure.getErrorMessage())

Request オブジェクトの errback にコールバック関数を渡しています。
コールバック関数の _errback() はリクエストに対して 200 以外のステータスコードが返ってきたときに呼ばれます。

上記のサンプルコードで start_urls に指定している httpbin(1) は色々なステータスコードで色々なレスポンスを返してくれる便利なサービスです。
1つめURLは ステータスコード200 が、2つめのURLは ステータスコード500 が返ります。なので2つめのリクエストは parse() ではなく _errback() で処理されることになります。

errback で指定したコールバック関数には failure オブジェクトを渡してもらえるので、エラーメッセージなどを取得することも可能です。
今回のログはこんな感じになりました

2016-09-24 22:35:08 [foo] ERROR: ### ERRBACK ###
2016-09-24 22:35:08 [foo] ERROR: <class 'scrapy.spidermiddlewares.httperror.HttpError'>
2016-09-24 22:35:08 [foo] ERROR: Ignoring non-200 response


ところが、この方法は私の求めている例外処理ではありません。
なぜなら parse() メソッドの実行中に何かしらの例外が投げられても、_errback() が呼ばれることは無いからです。

_errback() が呼ばれるのは

  • リクエストに対して 200 以外のステータスコードが返ったとき
  • そもそもDNSルックアップに失敗したとき
  • リクエストがタイムアウトしたとき

この場合に限ります。

ステータスコード200 が返って、そのあとに parse() で例外が投げられたとしても _errback() は呼ばれません。

この方法は「全部でnページ分のリクエストを投げてmページの取得に失敗した」みたいなログを残すのに使うようです。
あくまでもダウンロード時のエラーに対処する目的ですね。


2. Spider の spider_error シグナルをキャッチする

というわけで、本当の例外処理です。

パース中に例外が投げられると、spider_error というシグナルが発生します。
spider_error シグナルにコールバック関数を紐づけることでエラーハンドリングが可能です。

# spiders/bar.py

import scrapy
from scrapy import signals


class BarSpider(scrapy.Spider):
    name = "bar"
    allowed_domains = ["httpbin.org"]
    start_urls = (
        "http://www.httpbin.org/",
    )

    @classmethod
    def from_crawler(cls, crawler, *args, **kwargs):
        spider = super(BarSpider, cls).from_crawler(crawler, *args, **kwargs)

        # シグナルとコールバック関数を紐づける
        crawler.signals.connect(spider._handle_error, signal=signals.spider_error)

        return spider

    def parse(self, response):
        bar = 1 / 0 # ZeroDivisionError 例外が発生

        yield {
            "url": response.url,
            "status": response.status,
            "bar": bar,
        }

    def _handle_error(self, failure, response, spider):
        self.logger.error("### HANDLE_ERROR ###")
        self.logger.error(failure.type)
        self.logger.error(failure.getErrorMessage())

from_crawler() の中で signals.spider_error シグナルと _handle_error() メソッドを紐づけています。

parse() メソッドの中の bar = 1 / 0 の行で ZeroDivisionError 例外が投げられます。
それが _handle_error() でキャッチされ、ログにエラーの詳細が吐き出される流れです。


ログはこんな感じ、

2016-09-24 22:38:15 [bar] ERROR: ### HANDLE_ERROR ###
2016-09-24 22:38:15 [bar] ERROR: <class 'ZeroDivisionError'>
2016-09-24 22:38:15 [bar] ERROR: division by zero

例のごとく failure オブジェクトを渡してもらえるので、カスタムのエラーログを書き出したりエラー詳細をメールで通知することも可能でしょう。


ところが、この方法ではパース中の例外の通知を受けることしかできません。
そう、エラーからの復帰が出来ない のです。

というわけで続きます。


3. Spider Middleware の process_spider_exception で処理する

最後の方法です。例外をキャッチして、復帰するところまでをやります。
そのためには Spider Middleware を自作する必要があります。


f:id:todays_mitsui:20160924231058p:plain

Scrapy のアーキテクチャを紹介でよく見る図ですね。Spider と Scrapy エンジンの間にあるのが Spider Middleware です。

カスタム Middleware を定義することで、

  • Downloader から Spider に渡される直前のリクエストオブジェクト
  • Spider から Pipeline に渡される直前のアイテムオブジェクト
  • Spider から投げられた例外オブジェクト

この3つを加工できるようになります。

3つめのやつが本題ですね。
Spider で投げられた例外を Middleware の中で正常なアイテムにすり替えて Pipeline に流すことができるわけです。

これが try ... except で例外から復帰する処理に最も似ていると思いませんか?


カスタム Middleware 自体は普通の class として書きます。

# middlewares.py

class HandleErrorMiddleware(object):
    def process_spider_exception(self, response, exception, spider):
        spider.logger.error("### PROCESS_SPIDER_EXCEPTION ###")
        spider.logger.error(exception)

        return [{
            "url": response.url,
            "status": response.status,
            "error": str(exception),
        }]

このように、

そして、settings.py の中で有効化してあげます。

# Enable or disable spider middlewares
# See http://scrapy.readthedocs.org/en/latest/topics/spider-middleware.html
SPIDER_MIDDLEWARES = {
    'example.middlewares.HandleErrorMiddleware': 543,
}

そうして、先ほどと同じ Spider を走らせてみると、

2016-09-24 22:54:46 [bar] ERROR: ### PROCESS_SPIDER_EXCEPTION ###
2016-09-24 22:54:46 [bar] ERROR: division by zero
2016-09-24 22:54:46 [scrapy] DEBUG: Scraped from <200 http://www.httpbin.org/>
{'url': 'http://www.httpbin.org/', 'error': 'division by zero', 'status': 200}

このように、bar = 1 / 0 の時点で process_spider_exception() が呼び出されつつ、例外が無かったことにされてアイテムが流れています。

試しに、結果を JSON で保存してみると、

[
  {
    "url": "http://www.httpbin.org/",
    "error": "division by zero",
    "status": 200
  }
]

このようにエラーの詳細をアイテムとして流すことに成功しています。


ところが...


何度目の「ところが」でしょうか。
Spider Middleware の process_spider_exception には バグがあります


Spider Middleware のバグ

先ほどの process_spider_exception() ですが、通常のメソッドの中で投げられた例外は正しくキャッチしてくれますが、ジェネレーター関数の中で投げられた例外をキャッチすることができません 。(v1.1.3 時点)

Issue にも挙げられています。

どうやら Scrapy が内部的に依存している Twisted の挙動が関係しているらしく一筋縄では解消できないようです。
「help-wanted」というタグがつけられているのが絶望感を煽りますね。

Scrapy では複数のアイテムを抜き出して返すためにジェネレーター関数を多用しますからね。これは痛い。痛すぎる。


まとめ

というわけで Scrapy のエラーハンドリングの方法3種類をまとめてみました。

ちなみに、最後のバグについては、現時点でこれといった解決策を見つけられていません。 ひとまず今後の Isuue の流れを watch しておきます。あー、力が欲しい。


私からは以上です。

【jQueryの基本の"き"】パート4 - jQueryのいろんなバージョン

JavaScript jQuery jQueryの基本の"き"

これまでjQueryの使い方についてねちっこく解説してきましたが...。
今回は「使い方」ではなく「選び方」です。

ビギナーズからよく飛び出す質問「どのバージョンのjQueryを使えばいいの?」について。


jQueryは最新版だけでも全部で8つ

2016年8月末時点でjQuery本体の最新バージョンは バージョン3.1.0 です。
しかし バージョン1系列バージョン2系列 についてもサポートが打ち切られているわけではありません。
さらにファイル名に「.slim」や「.min」という文字がつくものも配布されています。

現在 公式サイトで配布されているjQuery を並べてみるとこんな感じ。

うむ、困りましたね。
少しずつ噛みくだきながら解説していきます。


.min の有無はファイルサイズの大きさの違い(機能は同じ)

「.min」が付くものと付かないものは、コードが圧縮されているか圧縮されていないかという違い があります。

JavaScript はコードの途中とちゅうに改行やスペースを入れても動作自体は変わりません。
これは HTML や CSS と同じ性質ですよね。

そのために「.min」無しバージョンでは適宜改行を入れ込んで読みやすく整形されています。
逆に「.min」付きバージョンではできる限り改行もスペースも入れずに書かれているため、ファイルサイズが小さくなっています。


というわけで「jquery-3.1.0.js」と「jquery-3.1.0.min.js」などは基本的に同じ機能を持っています。
どちらを使っても同じです。

ファイルの読みやすさを重視するならば「.min」無しを、サイズの小ささを重視するならば「.min」付きを選べばいいでしょう。
ただ、jQuery本体のソースコードを読みたくなることってほとんど無いので、基本的には「.min」付きで充分 だと思います。

参考に、

  • jquery-3.1.0.js - 263,767 バイト
  • jquery-3.1.0.min.js - 86,351 バイト

1/3 ほどのファイルサイズになってますね。軽い!


バージョン1系列とバージョン2系列の違いは対応しているブラウザの違い

バージョン1系列とバージョン2系列は 対応しているブラウザの違い です。
バージョン2系列は比較的新しいブラウザでしか動きませんが、バージョン1系列を使えば古いブラウザでも動きます。

公式サイト によれば、バージョン2系列の対応ブラウザは、

  • Google Chrome の最新版とひとつ前のバージョン
  • Microsoft Edge の最新版とひとつ前のバージョン
  • Firefox の最新版とひとつ前のバージョン
  • Internet Explorer 9~11
  • Safari の最新版とひとつ前のバージョン
  • Opera の最新バージョン
  • (モバイル)Android 4.0以上の標準ブラウザ
  • (モバイル)iOS 7以上のSafari

だそうです。

バージョン1系列を使えば、ここにさらに古いブラウザが加わります。

  • Internet Explorer 6~8
  • Opera 12.1x (Prestoエンジンを積んだバージョン)
  • Safari 5.1以上

特に重要なのは Internet Explorer に対応するかどうかでしょう。
IE8 などでも問題なく表示できるサイトにしようと思えば、jQueryのバージョン1.12を使うべきです。


ただし、対応しているブラウザが多いことはメリットだけではありません。
バージョン1系列は古いブラウザに対応させるためにファイルサイズが大きく、処理速度も遅いのです。


ちなみに、対応ブラウザって時代によって変わります

さて、ここで要注意なんですが、
さきほど紹介した対応ブラウザはあくまでも2016年8月末時点のものです。

時が流れて「こんな古いブラウザ誰も使ってないよね」というようなブラウザが出てくれば、そのブラウザのサポートは打ち切られるはずです。
公式サイト では常に対応ブラウザについての情報が公開されています。
定期的に情報を確認して、最新のブラウザ事情にキャッチアップしてみてください。


バージョン2系列とバージョン3系列の違いは設計の違い

バージョン2系列とバージョン3系列では対応しているブラウザは同じです。
が、バージョン3系列は2016年現在のブラウザ事情や JavaScript 事情に合わせて 設計のレベルから見直されて作り直されています

そのために機能の面でも大幅な違いがあり、jQuery バージョン2.2.4 を想定して作られたプラグインとjQuery バージョン3.1.0を組み合わせて使うと正常に動作しないかもしれません。


バージョン2系列からバージョン3系列に上がるあたって、もっとも大きく変わったのは .hide().show() が廃止されたことです。

.hide() はページ上の要素を見えなくする機能、反対に .show() は見えなくなっていた要素を表示する機能です。
これらがバージョン3系列では廃止されています。

jQueryの開発チーム曰く、要素を隠したり再表示したりしたいとき今後は、

.hide {
  display: none;
}

というような CSS を用意したうえで、隠したい要素に class="hide" を付与するようにして対応してほしいとのことです。

.hide().show() はこれまでにも多用されてきた機能だけに、その影響範囲は大きそう です。
バージョン3系列を採用する前に、自分が使いたいjQueryプラグインがバージョン3系列に対応しているかどうか調べる必要があります。

その代わり、バージョン3系列ではこれまで以上の性能向上が謳われていますよ。


.slim 付きは必要最低限の機能だけが含まれている

バージョン3系列にはさらにファイル名に「.slim」が付くものと付かないものがあります。
「.slim」付きバージョンは、「.slim」無しバージョンから Ajax やアニメーション関連機能など 一部の機能を削除することで究極の軽量化を目指したバージョン です。

「機能を削除する」なんてそんなことして大丈夫なんでしょうか?
大丈夫です。jQueryは本当に多機能で、中には「この機能最近あんまり使う機会無いよなぁ」というようなものもあるのです。

「.slim」付きバージョンはそういった機能を思い切って削除しています。


ちょっと余談ですが、Ajax やアニメーション関連機能がなぜ最近あんまり使う機会が無いのかお話ししましょう。


当たり前に使われるようになったがために標準機能に組み込まれた Ajax

Ajax とは、ユーザーがページを見ている最中にブラウザとサーバーがやり取りするための仕組みです。

実は Ajax 自体は2005年よりも前からブラウザに標準で存在した伝統的な機能でした。
しかし使い方が少々煩雑で初心者にはなかなか扱いづらいものだったのです。

そんな扱いづらい Ajax を断然扱いやすくする機能を提供したのもjQueryの功績でした。


それから時は流れ...
現在では Ajax はWebサイトを作るうえで欠かせない機能になっています。多くのサイトで今日も Ajax は多用されています。

そして需要の増加に伴って最新のブラウザでは、扱いが煩雑な Ajax の代わりに、より高機能でより扱いやすい Fetch API という機能が標準搭載されるようになってきています。

実際「もう Ajax のためにjQuery持ち出さなくていいよね、Fetch API使おうぜ」という考え方が現在の主流になりつつあります。


アニメーションの舞台は JS から CSS へ

もう一つアニメーション関連機能についてです。

こちらはご存知の方も多いでしょう。
CSS3 でアニメーション関連のプロパティ transition, animate などが追加されたおかげで、ページ上で要素をアニメーションさせることはとても手軽になりました。

CSSアニメーションはブラウザ自身が動作を制御してくれるため負担が少なく、レスポンシブデザインにも対応しやすいという利点があります。
「いまどきjQueryでアニメーションなんて流行らねぇんだよ、時代はCSSアニメーションだ!」そんな声が聞こえてきそうです。



このような時代背景から、わざわざjQueryでやる必要もなさそうな機能が「.slim」付きバージョンでは削除されています。
最新のWeb制作事情にしっかりと追いつけている人であれば、「.slim」付きバージョンも魅力的に見えるでしょう。

参考に再びサイズ比べを、

  • jquery-3.1.0.js - 263,767 バイト
  • jquery-3.1.0.min.js - 86,351 バイト
  • jquery-1.12.4.min.js - 68,952 バイト

うーんコンパクト!


まとめ

ざっくりまとめます。

  • 基本的に「.min」付きのほうがファイルサイズ小さくて素敵
  • 古いブラウザにも対応したいならバージョン1系列を使わざるを得ない
  • プラグインなどがバージョン3系列に対応してそうなら、バージョン3系列を使ってみよう
  • 慎重になるなら様子見でバージョン2系列かなぁ...
  • 最新のトレンドに乗っかって究極の最小化を目指すなら、バージョン3系列の「.slim」付きで

こんな感じになりますかね。


私からは以上です。


jQueryの基本の"き" シリーズ

blog.mudatobunka.org

blog.mudatobunka.org

blog.mudatobunka.org