Блог

У меня довольно распространенная задача, имея несколько тысяч веб-сайтов и необходимость анализировать как можно больше (адекватным образом, конечно).

Во-первых, я создал конфигурацию, подобную stormcrawlerfight, используя анализатор JSoup. Производительность была довольно хорошей, очень стабильной, около 8 тысяч выборок в минуту.

Затем я хотел добавить возможность разбора PDF / doc / etc. Итак, я добавил анализатор Tika для анализа документов, отличных от HTML. Но я вижу такого рода показатели:

Так что иногда бывают хорошие минуты, иногда их количество падает до сотен в минуту. Когда я удаляю потоковые записи Tika — все возвращается в нормальное русло. Итак, вопрос в целом заключается в том, как найти причину такого поведения, узкое место. Может быть, я пропустил какую-то настройку?

Вот что я вижу в топологии сканера в пользовательском интерфейсе Storm:

es-инжектор.flux:

 name: "injector"

includes:
- resource: true
  file: "/crawler-default.yaml"
  override: false

- resource: false
  file: "crawler-custom-conf.yaml"
  override: true

- resource: false
  file: "es-conf.yaml"
  override: true

spouts:
  - id: "spout"
    className: "com.digitalpebble.stormcrawler.spout.FileSpout"
    parallelism: 1
    constructorArgs:
      - "."
      - "feeds.txt"
      - true

bolts:
  - id: "status"
    className: "com.digitalpebble.stormcrawler.elasticsearch.persistence.StatusUpdaterBol    t"
    parallelism: 1

streams:
  - from: "spout"
    to: "status"
    grouping:
      type: CUSTOM
      customClass:
        className:    "com.digitalpebble.stormcrawler.util.URLStreamGrouping"
        constructorArgs:
          - "byHost"
      streamId: "status"
  

es-crawler.flux:

 name: "crawler"

includes:
- resource: true
  file: "/crawler-default.yaml"
  override: false

- resource: false
  file: "crawler-custom-conf.yaml"
  override: true

- resource: false
  file: "es-conf.yaml"
  override: true

spouts:
  - id: "spout"
    className: "com.digitalpebble.stormcrawler.elasticsearch.persistence.AggregationSpout"
    parallelism: 10

bolts:
  - id: "partitioner"
    className:    "com.digitalpebble.stormcrawler.bolt.URLPartitionerBolt"
    parallelism: 1

  - id: "fetcher"
    className: "com.digitalpebble.stormcrawler.bolt.FetcherBolt"
    parallelism: 1

  - id: "sitemap"
    className: "com.digitalpebble.stormcrawler.bolt.SiteMapParserBolt"
    parallelism: 1

  - id: "parse"
    className: "com.digitalpebble.stormcrawler.bolt.JSoupParserBolt"
    parallelism: 5

  - id: "index"
    className:    "com.digitalpebble.stormcrawler.elasticsearch.bolt.IndexerBolt"
    parallelism: 1

  - id: "status"
    className:    "com.digitalpebble.stormcrawler.elasticsearch.persistence.StatusUpdaterBolt"
    parallelism: 4

  - id: "status_metrics"
    className: "com.digitalpebble.stormcrawler.elasticsearch.metrics.StatusMetricsBolt"
    parallelism: 1

  - id: "redirection_bolt"
    className: "com.digitalpebble.stormcrawler.tika.RedirectionBolt"
    parallelism: 1

  - id: "parser_bolt"
    className: "com.digitalpebble.stormcrawler.tika.ParserBolt"
    parallelism: 1

streams:
  - from: "spout"
    to: "partitioner"
    grouping:
      type: SHUFFLE

  - from: "spout"
    to: "status_metrics"
    grouping:
      type: SHUFFLE     

  - from: "partitioner"
    to: "fetcher"
    grouping:
      type: FIELDS
      args: ["key"]

  - from: "fetcher"
    to: "sitemap"
    grouping:
      type: LOCAL_OR_SHUFFLE

  - from: "sitemap"
    to: "parse"
    grouping:
      type: LOCAL_OR_SHUFFLE

  # This is not needed as long as redirect_bolt is sending html content to index?
  # - from: "parse"
  #   to: "index"
  #   grouping:
  #     type: LOCAL_OR_SHUFFLE

  - from: "fetcher"
    to: "status"
    grouping:
      type: FIELDS
      args: ["url"]
      streamId: "status"

  - from: "sitemap"
    to: "status"
    grouping:
      type: FIELDS
      args: ["url"]
      streamId: "status"

  - from: "parse"
    to: "status"
    grouping:
      type: FIELDS
      args: ["url"]
      streamId: "status"

  - from: "index"
    to: "status"
    grouping:
      type: FIELDS
      args: ["url"]
      streamId: "status"

  - from: "parse"
    to: "redirection_bolt"
    grouping:
      type: LOCAL_OR_SHUFFLE

  - from: "redirection_bolt"
    to: "parser_bolt"
    grouping:
      type: LOCAL_OR_SHUFFLE
      streamId: "tika"

  - from: "redirection_bolt"
    to: "index"
    grouping:
      type: LOCAL_OR_SHUFFLE

  - from: "parser_bolt"
    to: "index"
    grouping:
      type: LOCAL_OR_SHUFFLE
  

Обновление: я обнаружил, что у меня заканчиваются ошибки памяти в workers.log, даже если я установил workers.heap.size на 4 ГБ, рабочий процесс увеличивается до 10-15 ГБ..

Обновление 2: После того, как я ограничил использование памяти, я не вижу ошибок OutOfMemory, но производительность очень низкая.

Без Tika — я вижу 15 тысяч выборок в минуту. С Tika — это все после высоких показателей, только сотни в минуту.

И я вижу это в рабочем журнале: https://paste.ubuntu.com/p/WKBTBf8HMV

Загрузка процессора очень высока, но в журнале ничего нет.

Как вы можете видеть в статистике пользовательского интерфейса, болт синтаксического анализатора Tika является узким местом: его пропускная способность составляет 1,6 (значение > 1 означает, что он не может обрабатывать входные данные достаточно быстро). Это должно улучшиться, если вы придадите ему тот же параллелизм, что и анализатору JSOUP, т. е. 4 или более.

Ответ запоздалый, но может быть полезен другим.

Что происходит при использовании Tika в открытых обходах, так это то, что анализатор Tika получает все, с чем не справился JSOUPParser bolt: архивы, изображения, видео и т.д. … Обычно эти URL-адреса, как правило, очень тяжелые и медленно обрабатываются, и входящие кортежи быстро возвращаются во внутреннюю очередь, пока не закончится память.

Я только что зафиксировал набор белого списка mimetype для анализатора Tika # 712, который позволяет вам определить набор регулярных выражений, которые будут опробованы для типа содержимого для документа. если есть совпадение, документ обрабатывается, если нет, кортеж отправляется в поток СОСТОЯНИЯ как ошибка.

Вы можете настроить белый список следующим образом:

 parser.mimetype.whitelist:
 - application/. word.*
 - application/. excel.*
 - application/. powerpoint.*
 - application/.*pdf.*
  

Это должно сделать вашу топологию намного быстрее и стабильнее. Дайте мне знать, как это происходит.