복붙노트

[HADOOP] Hadoop에 저장된 문서 검색 - 사용할 도구는 무엇입니까?

HADOOP

Hadoop에 저장된 문서 검색 - 사용할 도구는 무엇입니까?

나는 Hadoop, Hbase, Lucene, Carrot2, Cloudera, Tika, ZooKeeper, Solr, Katta, Cascading, POI에서 길을 잃었습니다.

당신이 그 중 하나에 대해 읽을 때 당신은 종종 다른 도구들 각각이 언급 될 것이라는 것을 확신 할 수 있습니다.

나는 당신이 모든 도구를 나에게 설명 할 것을 기대하지 않는다. 내 시나리오에 맞게이 범위를 좁히는 데 도움이된다면 좋을 것입니다. 지금까지 나는 위의 것 중 어느 것이 적합 할 것인지 확신하지 못했고 (항상 그렇듯이) 수행 할 일을하는 한 가지 방법이 더 많아 보입니다.

시나리오는 500GB ~ ​​20TB의 문서가 Hadoop에 저장되어 있습니다. 여러 형식의 텍스트 문서 : 이메일, 문서, PDF, odt. SQL db (보낸 사람,받는 사람, 날짜, 부서 등)에 저장된 문서에 대한 메타 데이터. 문서의 주요 출처는 ExchangeServer (전자 메일 및 첨부 파일)가 될뿐만 아니라 이제 검색 : 사용자는 해당 문서에 대해 복잡한 전체 텍스트 검색을 수행 할 수 있어야합니다. 기본적으로 그는 일부 검색 설정 패널 (웹 응용 프로그램이 아닌 자바 데스크톱 응용 프로그램)이 제공됩니다. - 날짜 범위, 문서 유형, 보낸 사람 /받는 사람, 키워드 등을 설정합니다. - 검색을 시작하고 문서의 결과 목록을 가져옵니다. (그리고 각 문서 정보에 대해 검색 결과에 포함 된 이유, 즉 문서에서 어떤 키워드가 발견되는지).

어떤 도구를 고려해야합니까? 요점은 최소한의 "접착제"코드로 이러한 솔루션을 개발하는 것입니다. 저는 SQLdbs에 능숙하지만 아파치 및 관련 기술에 대해 상당히 불편합니다.

기본 워크 플로우는 다음과 같습니다 : ExchangeServer / other source -> doc / pdf / ...에서 변환 -> 중복 제거 -> Hadopp + SQL (메타 데이터) -> 색인 빌드 / 업데이트 <- 문서를 통한 검색 ) -> 현재 검색 결과

고맙습니다!

해결법

  1. ==============================

    1.solr로가는 것은 좋은 선택입니다. 위에서 설명한 것과 비슷한 시나리오에서 사용했습니다. 분산 된 인덱스 서버로서 실제 거대한 데이터에 대해 solr을 사용할 수 있습니다.

    solr로가는 것은 좋은 선택입니다. 위에서 설명한 것과 비슷한 시나리오에서 사용했습니다. 분산 된 인덱스 서버로서 실제 거대한 데이터에 대해 solr을 사용할 수 있습니다.

    그러나 이러한 모든 문서 형식에 대한 메타 데이터를 얻으려면 다른 도구를 사용해야합니다. 기본적으로 워크 플로는 다음과 같습니다.

    1) hadoop 클러스터를 사용하여 데이터를 저장하십시오.

    2) mapreduce를 사용하여 hadoop 클러스터에서 데이터 추출

    3) 문서 식별 (문서 유형 식별)

    4)이 문서에서 메타 데이터를 추출합니다.

    5) solr 서버의 색인 메타 데이터, 다른 수집 정보를 데이터베이스에 저장

    6) Solr 서버는 분산 인덱스 서버이므로 각 처리에 대해 새 샤드 또는 인덱스를 생성 할 수 있습니다.

    7) 검색 할 때 모든 색인에 대한 검색이 필요합니다.

    8) Solr은 모든 복잡한 검색을 지원하므로 자신의 검색 엔진을 만들 필요가 없습니다.

    9) 또한 페이징을 수행합니다.

  2. ==============================

    2.우리는 Solr을 HBase의 "2 차 인덱서"로 사용하여 일부 고객들에게 정확하게이 작업을 수행했습니다. HBase에 대한 업데이트는 Solr에게 보내지고 이에 대해 쿼리 할 수 ​​있습니다. 일반적으로 사람들은 HBase로 시작한 다음 이식 검색을 시작합니다. 당신이 원하는대로 검색이 진행된다는 것을 알고있는 것처럼 들리므로 HBase를 공급하는 파이프 라인에서 보조 색인을 내장 할 수 있습니다.

    우리는 Solr을 HBase의 "2 차 인덱서"로 사용하여 일부 고객들에게 정확하게이 작업을 수행했습니다. HBase에 대한 업데이트는 Solr에게 보내지고 이에 대해 쿼리 할 수 ​​있습니다. 일반적으로 사람들은 HBase로 시작한 다음 이식 검색을 시작합니다. 당신이 원하는대로 검색이 진행된다는 것을 알고있는 것처럼 들리므로 HBase를 공급하는 파이프 라인에서 보조 색인을 내장 할 수 있습니다.

    Solr을 사용하면 필요한 모든 작업을 수행 할 수 있습니다.

  3. ==============================

    3.살펴볼 또 다른 프로젝트는 Solly와 분산 데이터베이스를 통합하는 작업을 이미 완료 한 Lily, http://www.lilyproject.org/lily/index.html입니다.

    살펴볼 또 다른 프로젝트는 Solly와 분산 데이터베이스를 통합하는 작업을 이미 완료 한 Lily, http://www.lilyproject.org/lily/index.html입니다.

    또한이 애플리케이션에 브라우저를 사용하고 싶지 않은 이유를 알지 못합니다. 당신은 정확히 어떤면을 가진 검색이 무엇인지를 설명하고 있습니다. 서버와 통신 (JSON 구문 분석)하는 데스크탑 응용 프로그램을 설정하고 씩 클라이언트 GUI에 결과를 표시 할 수 있지만이 모든 작업은 이미 브라우저에서 수행됩니다. Solr은 자유로운 패싯 검색 시스템을 제공합니다. 자습서를 따라하십시오.

  4. ==============================

    4.Solr (http://lucene.apache.org/solr)로가는 것은 좋은 해결책이지만, 명백하지 않은 몇 가지 사항을 다룰 준비가되어 있어야합니다. 먼저 인덱스를 올바르게 계획하고 있습니다. 여러 테라 바이트의 데이터는 합리적인 수준의 성능을 위해 Solr에서 여러 개의 파편이 필요하며 직접 관리해야합니다. 분산 검색 (여러 조각에서 쿼리를 수행)을 제공하지만 이는 절반의 전투에 불과합니다.

    Solr (http://lucene.apache.org/solr)로가는 것은 좋은 해결책이지만, 명백하지 않은 몇 가지 사항을 다룰 준비가되어 있어야합니다. 먼저 인덱스를 올바르게 계획하고 있습니다. 여러 테라 바이트의 데이터는 합리적인 수준의 성능을 위해 Solr에서 여러 개의 파편이 필요하며 직접 관리해야합니다. 분산 검색 (여러 조각에서 쿼리를 수행)을 제공하지만 이는 절반의 전투에 불과합니다.

    ElasticSearch (http://www.elasticsearch.org/)는 또 다른 인기있는 대안이지만 규모에 관해 많은 경험이 없습니다. 그것은 동일한 Lucene 엔진을 사용하므로 검색 기능 세트가 유사 할 것으로 기대합니다.

    또 다른 유형의 솔루션은 SenseiDB (LinkedIn에서 제공하는 개방형)와 같은 것으로, 대용량 데이터의 경우 입증 된 규모뿐 아니라 전체 텍스트 검색 기능 (Lucene 기반)을 제공합니다.

    http://senseidb.com

    그들은저기서 검색 작업에 많은 노력을 기울 였고 캐주얼 사용은 꽤 유망한 것입니다.

    모든 데이터가 이미 Hadoop에 있다고 가정하면 일관성있는 스키마 친화적 인 형식으로 데이터를 SenseiDB로 가져 오는 맞춤 MR 작업을 작성할 수 있습니다. SenseiDB는 이미 사용자가 볼 수있는 Hadoop MR 인덱서를 제공합니다.

    유일한주의 사항은 설정이 좀 더 복잡하지만 스케일링 문제를 여러 번 해결할 수 있다는 것입니다. 특히 인덱싱 성능 및 패싯 (faceting) 기능과 관련하여 여러 가지 문제가 있습니다. 또한 HA가 중요 할 경우 클러스터링 지원을 제공합니다. Solr 용 Alpha (Solr 4.x는 alpha atm)입니다.

    희망과 도움이 행운을 빕니다!

    최신 정보:

    나는 ElasticSearch에 더 많은 지식이있는 친구보다 나에게 물었다. 클러스터링 및 재 균형 조정의 장점은 기계 및 샤드를 기반으로한다. Solr에 대한 확실한 승리입니다. 특히 TB 관련 데이터를 다루는 경우 더욱 그렇습니다. 유일한 단점은 ElasticSearch에 대한 문서의 현재 상태가 많이 남아 있다는 것입니다.

  5. ==============================

    5.참고로, 문서가 Hadoop에 저장되었다고 말할 수는 없으며 분산 파일 시스템 (Hadoop을 언급 한 이래로 아마도 HDFS)에 저장되어 있다고 말할 수는 없습니다.

    참고로, 문서가 Hadoop에 저장되었다고 말할 수는 없으며 분산 파일 시스템 (Hadoop을 언급 한 이래로 아마도 HDFS)에 저장되어 있다고 말할 수는 없습니다.

    검색 / 색인 생성 관련 : Lucene은 시나리오에 사용할 도구입니다. 색인 생성과 검색 모두에 사용할 수 있습니다. 그것은 자바 라이브러리입니다. WebServices를 통해 인덱싱 / 검색 시스템에 액세스 할 수있는 관련 프로젝트 (Solr)가 있습니다. 그래서 다른 유형의 문서 (Lucene은 문서 (PDF, Word 등)를 해석하는 책임을 어깨에 가졌지 만 아마도 이미 그렇게 할 수 있습니다)를 처리 할 수 ​​있기 때문에 Solr을 살펴보아야합니다.

  6. from https://stackoverflow.com/questions/11548357/searching-over-documents-stored-in-hadoop-which-tool-to-use by cc-by-sa and MIT license