3. What’s Semantic Web?
• RDF “statements” consist of
resources (= nodes) = subject
which have properties = predicate
which have values (= nodes,strings) = object
resource value
property
5. 시맨틱 웹의 현황
• 시맨틱 웹이 죽은 이유
– 어렵다
• HTML과 XML에 비해 콘텐츠 생산이 어려움
• 이상적 표준론자와 학자들의 전유물로 인식
• 웹 개발자를 위한 쉬운 표준과 개발 도구 부재
– 킬러앱이 없다
• 매력적인 웹 서비스 및 웹 애플리케이션 부재
• 포털, 검색, 동영상, 소셜네트웍과 연계 부재
• 시맨틱 웹의 현실
– 특정 도메인에서만 이용: 콘텐츠, 의료, 문헌, 특허 정보 등
– RSS, 오픈 API, 마이크로포맷 등 구조적 데이터 저작 가능
– RDF 기반 데이터웹(LinkedData)로 재도약 준비 중
– 여전히 어렵고 킬러앱이 없다!
6. 시맨틱 검색 서비스의 출현
• 국내
– 네이트는 시맨틱 검색을 기반으로 10%까지 점유율 상승.
– 네이버 역시 시맨틱 웹 기반 영화 검색 서비스 베타 제공
7. • 국외
– Microsoft Bing은 Powerset을 인수 및 점유율 상승.
– 구글은 Squared라는 구조화 서비스 베타 서비스 시작.
– Wolfram Research에서 DB 기반 검색 서비스 베타 서비스 시작.
– LinkedData의 급격한 성장.
8. What’s Linked Data?
. In October 2007, datasets consisted of over two
billion RDF triples, which were interlinked by over
two million RDF links. By September 2010 this had
grown to 25 billion RDF triples, interlinked by
around 395 million RDF links.
http://en.wikipedia.org/wiki/Linked_Data
9. 검색 기술 비교 및 변화
기존 웹 검색 엔진 방법 시맨틱 웹 검색
외부 웹 문서 및 링크드데이터(LinkedData) 및
대상
사내 콘텐츠 DB 사내 콘텐츠 DB
웹 크롤러를 통해 수집 수집 RDF 수집
랭킹에 따라 문서 인덱스 저장 관계에 따라 RDF Triple 변환
IR 알고리즘 결과 SPAQL 쿼리 응답
키워드 기반 랭킹 기반 검색 서비스 그래프 기반 의미 검색
Google(1조) 데이터 용량 LinkedData(250억)
Google, 네이버, 다음 대표 기업 Bing, Hakia
– 검색은 정보 수집, 저장, 서비스 모든 면에서 주기적으로 대용량 처리
능력이 필요하며, 웹 기반 데이터가 기하 급수적으로 늘어나면서 클
라우드 플랫폼이 절실히 요구 되고 있음.
– 2009년을 기점으로 시맨틱 웹 데이터 처리가 이슈가 되면서, 기존 검
색 엔진과 마찬가지로 클라우드 컴퓨팅 기반 분산 플랫폼이 필요.
10. But, 기존 시맨틱 웹 처리 방법
1. 모델 만들기
개념과 관계 속성에 대한 정의
최대한 현실에 부합하는 모델을
만들며 확장 유연성
2.RDF 처리
대개 기존 DB에서 변환
RDF, Triple, N-Triple 형태 저장
처리 시간이 길다!
3. SPARQL 질의
원하는 답을 얻기 위한 추론
응답 시간이 길다!
14. 3. Key/Value DB 이용
• 키워드 확장용 Answer Set 저장 가능
– “Subject Property” 기반 검색어 e.g “이효리 나이” ⇒ Daum 스마트앤서
– “Subject Property sameAs Subject” 방식 확장
• “이효리 나이 같은 가수”
15. • 의미 검색 서비스에 용이
– Update Heavy job
– Real-time incremental
Update
http://research.yahoo.com/Web_Information_Management/YCSB
16. 시스템 구성도
- 클라우드 인스턴스 동적 처리
- MR Job Scheduler
Music
Music People Movie
Movie
DB People DB
DB DB DB Map/Reduce
DB
RDF
RDF
Search Service Hadoop M/R
-Incremental
Update
N3
N3
{"Name": "Cheeso",
Internet REST APIs "Rank": 7} NoSQL M/R
{"Name": "Cheeso",
"Rank": 7}
{"Name": "Cheeso",
"Rank": 7}
- 사용자 쿼리 분석기
- 동적 생성
Hbase
Answer
Answer
Search Service Cassandra Set
Set
iCube Storage
Front-end Cloud Clould
19. • 기존 서비스와 차별점
– 콘텐츠 검색은 주제 중심으로만 제공함
– 속성 중심의 질의어 확장을 통한 검색 제공에 한계
• 의미 검색 서비스 특징
– 사용자에게 친숙한 질의어 확장을 통한 콘텐츠 의미 검색
– 기존 스마트 앤서에 대한 보강 데이터 확보
– 클라우드 플랫폼을 이용 영화/인물/음악을 기반한 RDF
Triple/Answer Set 등 5억~10억 규모 데이터 실시간 처리 처리
• 기존 방식: Database에서 질의별 속성만 추출 작업
20. Why Cloud in Search?
1. 사회적 이슈가 발생했을 때, 클라우드 동적 제어 API를 이용하
여 크롤링 및 인덱싱 작업을 비주기적으로 시행.
2. UCC 검색 콘텐츠 DB에 대해서 신규 작업 시 클라우드 기반으
로 테스트 가능
3. Hadoop, Hbase 등 각종 분산 컴퓨팅 자원을 필요 시 이용.
4. 실시간 웹(Realtime Web) 검색을 대응하기 위한 검색 엔진
및 처리 시스템 필요
21. Daum내 Hadoop 이용 사례
• 사용자 스팸 필터링
– 문서 내부 단어 및 사용자 프로필을 기반한 스팸 필터링
Document Set
Document
Feature
Map Reduce
(User ID, Doc Features) (User ID, Doc Features List)
Extraction
Filtering with Map
(User ID, User Profiles)
Reduce
User Profile (User ID, User Profiles)
+ +
Spam Users
Data Node
Spam User Job Tracker
DB + 2nd Name Node
nd
Data Node
Data Node
Document Name Node
DB
Data Node
–처리 성능 : Blog 10일치 Data (32.7GB) : 4대 CPU 32개 : 11분 42초
22. • 각종 통계 처리
– 검색 및 쇼핑 광고 로그 분석 (Hadoop 이용)
– 검색 및 쇼핑 광고 매출 통계 분석 (Hive 이용)
