Differences between revisions 2 and 3
Revision 2 as of 2008-04-10 20:27:41
Size: 280
Editor: pool-71-240-162-154
Comment:
Revision 3 as of 2008-04-17 17:21:44
Size: 5057
Editor: airband-66-133-162-98
Comment: Rough Draft of Nutch 2 Architecture
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
The purpose of this page is to discuss ideas for the architecture of the next generation of Nutch. This page will be fleshed out more with different sections shortly but for now feel free to write down any ideas or desires you may have for Nutch2. === Overview ===
  1.Reuse of existing Nutch codebase
    1.While some things will change this architecture is more of a refactor than a complete re-write. Much of the existing codebase including plugin functionality should be reused.
  2.Dependency Injection
    1.Remove the plugin framework and use a DI framework, Spring for example, to create mapper and reducer classes that are auto injected with dependencies. This will take modifications to the Hadoop codebase.
  2.Have mock objects that make it easy to test jobs.

=== Data Structures ===
  1.CrawlBase
    1.Url → CrawlHistory
    2.CrawlHistory is a list of CrawlDatum objects ordered by reverse date
    3.CrawlDatum has Metadata
  2.CrawlList
    1.Url → CrawlHistory
    2.Separate from CrawlBase for Multiple concurrent crawls
  3.FetchedContent
    1.Url → BytesWritable, FetchStatus
    2.FetchStatus would be a status of the fetch, error codes, any fetch information. This would then be translated by another tool back into the CrawlBase. FetchStatus has Metadata.
  4.ParsedContent
    1.Url → MapWritable
    2.MapWritable would contain Text → Writable or Writable[] and would allow the parsing of all different types of elements within the content (href, headers, etc.)
  5.Processing
    1.Processing would take the ParsedContent and translate that into multiple specific data parts. These data parts aren't used by any part of the system except Scoring.
    2.Processing would be specific functions including updating the CrawlBase, peforming analysis on ParsedContent, Integration of data from other sources.
    3.Some processors would translate content into formats needed by scorers.
    4.Processors are not constrained by specific data structures to allow flexibility in analysis, updating, blocking or removal, and other forms of data processing. The only requirement is scoring programs must be able to access processing output data structure in a one to one relationship.
  6.Scoring
    1.Url → Field
    2.Url → Float
    3.Field is a name, value(s), and score, being Text, Text, and Float respectively.
    4.The fields become the fields that are indexed with the scores becoming field boosts.
    5.Scoring takes the specific data parts from analysis and outputs the above formats.
    6.Field needs lucene semantics.
    7.Indexing
      1.Indexing indexes Fields for a document according to the field values and boosts. Indexing does not determine either field values or boost values.
      2.Indexing aggregates document boosts to create a final document score.

=== Tools ===
  1.Injector
    1.Injects data sources into the CrawlBase creating new CrawlBase, CrawlHistory objects.
    2.This could also be used to update the status or change the state of Urls in the CrawlBase manually.
  2.Generator
    1.Creates CrawlLists from the CrawlBase
    2.Filters could be created to run on only a subset of the CrawlBase Urls.
   3.Fetcher
    1.Fetches CrawlLists objects and creates FetchedContent objects.
  4.UpdateCrawl
    1.Updates the CrawlBase Urls with the FetchedStatus objects of the FetchedContent.
    2.This does not add new Urls to the database, only updates current Urls.
  5.Parser
    1.Creates ParsedContent objects from FetchContent sources.
    2.Run multiple different parsers based on different conditions.
  6.Processors
    1.New Url Processor
      1.A processor which updates the CrawlBase with new urls parsed from ParsedContent sources.
    2.Html Processor
      1.Does specific processing on Html sources from ParsedContent.
    3.Link Processor
      1.Creates a specific database of Url → Inlinks and Outlinks.
    4.BlackList Processor
      1.Processor which removes urls and their content from being indexed if they are on a blacklist.
    5.Other Processors
      1.There should be many other tools here that perform specific functions such at language identification, handling redirected urls and scoring, etc.
  7.Scorers
    1.Html Scorer
      1.Scores Html analysis
      2.Link Scorer
        1.Create a page-rank type score from the Link Analysis.
      3.Other Scorers
  8.Indexer
    1.Create Lucene indexes from multiple Scoring objects.
  9.Query tools

=== Supporting Infrastructure ===
  1.Shard management
    1.Perhaps a separate project to be shared by Lucene, Solr, and Nutch.
    2.Nutch shards need other content besides indexes, summaries and links for example.
  2.Cluster management
  3.Automated job streams for nutch processes
  4.Build and command line scripts
    1.Allow packaging of all core and third-party contrib jars to run on a standard hadoop cluster.
    2.People should be able to create an extension and drop in a jar and it just runs, no need to deploy jar manually to all slaves.
  5.Full unit testing suite, documentation and tutorials
    1.Maybe a book would be good. We definitely need documentation to lead a person from installation to extension.

Nutch 2.0 Architecture

Overview

  • 1.Reuse of existing Nutch codebase
    • 1.While some things will change this architecture is more of a refactor than a complete re-write. Much of the existing codebase including plugin functionality should be reused.
    2.Dependency Injection
    • 1.Remove the plugin framework and use a DI framework, Spring for example, to create mapper and reducer classes that are auto injected with dependencies. This will take modifications to the Hadoop codebase.
    2.Have mock objects that make it easy to test jobs.

Data Structures

  • 1.CrawlBase

    2.CrawlList

    3.FetchedContent

    4.ParsedContent

    • 1.Url → MapWritable 2.MapWritable would contain Text → Writable or Writable[] and would allow the parsing of all different types of elements within the content (href, headers, etc.)

    5.Processing
    • 1.Processing would take the ParsedContent and translate that into multiple specific data parts. These data parts aren't used by any part of the system except Scoring. 2.Processing would be specific functions including updating the CrawlBase, peforming analysis on ParsedContent, Integration of data from other sources. 3.Some processors would translate content into formats needed by scorers. 4.Processors are not constrained by specific data structures to allow flexibility in analysis, updating, blocking or removal, and other forms of data processing. The only requirement is scoring programs must be able to access processing output data structure in a one to one relationship.

    6.Scoring
    • 1.Url → Field 2.Url → Float 3.Field is a name, value(s), and score, being Text, Text, and Float respectively. 4.The fields become the fields that are indexed with the scores becoming field boosts. 5.Scoring takes the specific data parts from analysis and outputs the above formats. 6.Field needs lucene semantics. 7.Indexing
      • 1.Indexing indexes Fields for a document according to the field values and boosts. Indexing does not determine either field values or boost values. 2.Indexing aggregates document boosts to create a final document score.

Tools

  • 1.Injector 2.Generator

    4.UpdateCrawl

    5.Parser 6.Processors
    • 1.New Url Processor 2.Html Processor 3.Link Processor
      • 1.Creates a specific database of Url → Inlinks and Outlinks.

      4.BlackList Processor

      • 1.Processor which removes urls and their content from being indexed if they are on a blacklist.
      5.Other Processors
      • 1.There should be many other tools here that perform specific functions such at language identification, handling redirected urls and scoring, etc.
    7.Scorers
    • 1.Html Scorer
      • 1.Scores Html analysis 2.Link Scorer
        • 1.Create a page-rank type score from the Link Analysis.
        3.Other Scorers
    8.Indexer
    • 1.Create Lucene indexes from multiple Scoring objects.
    9.Query tools

Supporting Infrastructure

  • 1.Shard management
    • 1.Perhaps a separate project to be shared by Lucene, Solr, and Nutch. 2.Nutch shards need other content besides indexes, summaries and links for example.
    2.Cluster management 3.Automated job streams for nutch processes 4.Build and command line scripts
    • 1.Allow packaging of all core and third-party contrib jars to run on a standard hadoop cluster. 2.People should be able to create an extension and drop in a jar and it just runs, no need to deploy jar manually to all slaves.
    5.Full unit testing suite, documentation and tutorials
    • 1.Maybe a book would be good. We definitely need documentation to lead a person from installation to extension.

Nutch2Architecture (last edited 2014-03-05 22:46:58 by LewisJohnMcgibbney)