Real-time full-text search with Luwak and Samza This is an edited transcript of a talk given by Alan Woodward and Martin Kleppmann at FOSDEM 2015.

1. Real-time full-text search
with Luwak and Samza
by Alan Woodward and Martin Kleppmann
번역: 이명현 thicliwin@gmail.com

2. 이 자료는...
• Martin Kleppmann 이 confluent.io 블로그로 올린 글을 번역
한 자료입니다.
• 때문에 글의 진행과 내용이 원문의 그것과 같습니다.
• 번역 과정에서 다소 주관적인 해석이 들어가기도 했습니다.
• 원문을 읽어보시기를 추천드립니다.

3. 검색의 변화

4. 검색의 변화
• 전통적인 데이터
• 큰 규모의 코퍼스(corpus)
• 사용자의 필요에 따라서 그때 그때 필요한 내용을 코퍼스에서 검색한다
• 때때로 코퍼스 문서 내용에 변화가 있긴 하지만, 크게 변하지 않는다
• 빠르게 변화하는 데이터
• 문서가 들어오는대로 검색을 할 수 있으면 유용하다
• 뉴스 모니터링, 트위터 검색과 같은 경우에 적용 가능

5. 여기서 소개하고자 하는 것은
• Luwak과 Samza를 연동해서 효율적이고 확장가능한 stream 검색엔진을
만드는 것
• Luwak
• Lucene-based library
• 단일 문서에 여러 쿼리를 수행할 수 있다
• Samza (+Kafka)
• Kafka 기반의 stream 처리 프레임워크
• 실시간 스트림 처리를 분산된 컴퓨터들에서 할 수 있도록 한다

6. Full-text search on stream

7. Full-text search on stream
• Solr나 Elasticsearch 와 같은 일반적인 검색엔진과 다른 문제
들을 다뤄야 한다
• 데이터가 급속히 변화하는 경우에 그 중요성이 더 커진다

8. 여기서 말하는 Stream은 무엇인가?
• 데이터의 모음
• 데이터의 ‘추가’만 가능하다
• 데이터들이 일정한 순서를 가지고 있다
• 예
• log file
• exception stack trace

9. • Producer
• Stream에 쓰기 작업을 하는 프로세스
• Consumer
• Stream으로 부터 읽는 프로세스
• can read entire file sequentially
• can use tail -f to watch new records

10. 그렇다면 Stream을 어떻게 full-text 검색을 할까?
• 전통적인 방법
• 모든 것을 큰 색인에 올린다
• Elasticsearch 나 Solr 등을 사용해서
• ELK (Elasticsearch, Logstash and Kibana) is a trendy
way

11. • 새로운 데이터가 추가된다
• 검색을 할 수 있도록 색인에 추가한다
• 색인 구성의 예: index of different time periods
• 어제
• 지난 1시간
• 지난 1분
• Near-real-time search 을 구성할 수 있다
• 위에 구성한 모든 색인에 검색을 한다

12. 그렇다면 Stream 검색을 하는 곳은 어디가 있을까?
• Twitter
• 검색을 하면 지난 얼마간의 트윗들을 검색한다
• 어느 정도 시간이 지나면 새로운 트윗들이 결과에 추가된다
• 트위터는 검색 쿼리를 기억하고 새로운 트윗들 중에서 검색을
계속 수행한다.
• called firehose of tweets

13. • Google Alerts
• 사용자가 쿼리를 등록한다
• 검색에 매칭되는 페이지가 새로 등장하면 시스템이 알림을 보
내준다
• Google Alerts 는 수집되는 문서들의 stream에서 등록된 쿼
리와 매칭되는 문서를 검색하는 것

14. 검색은 두가지로 나눠볼 수 있다
• After-the-fact search
• 과거의 문서들을 검색한다
• 모든 문서들을 큰 색인에 담는다
• Streaming search
• 쿼리를 문서보다 먼저 등록한다
• Stream에 나타나는 문서들을 등록된 쿼리들에 매칭한다

15. • 이 둘을 결합하는게 좋은 결과를 가져오기도 한다
• Twitter
• 7day search + stream search
• 비슷한 제품: Elasticsearch Percolator

17. Implementing Stream Search

18. Stream search, 단순한 접근 방법
• 극단적으로는 한 문서당 색인을 생성하고 등록된 모든 쿼리를 날려
볼 수 있다.
• 하지만 위 방법은 효율적이지 못하다.
• 쿼리가 많아지면: 느려진다
• 쿼리가 복잡할수록: 느려진다
• 예: Media monitoring service
• “which” magazine 의 복잡한 쿼리 사례

19. 옵티마이징을 해야한다
• The fastest query is a query that you never execute
• 절대 실행되지 않을 쿼리를 찾아낼 수 있다면 그 쿼리들을 건너
뜀으로써 많은 시간을 아낄수있다

20. Luwak: A java library for stored queries

21. Luwak
• “A library that we (Flax) wrote in order to do efficient
streaming search. Luwak is open source and builds upon
Apache Lucene"
• 쿼리를 먼저 등록하고 새로운 문서들을 매칭한다
• 문서를 먼저 색인하는 것이 아니다
• 매칭해야하는 쿼리의 수를 줄이기 위해 몇 가지 옵티마이징을 한
다

22. Index of Queries

23. • Conjunction 쿼리
• Q1: “WHEELS” NEAR “BUS”
• Q2: “WHEELS” NEAR “CAR”
• 모든 단어들이 문서에 등장해야한다
• Q1 쿼리와 매칭되는 문서는 “wheels” 와 “bus” 가 등장하는 문서
• 만일 문서에 “bus”/“wheels” 중 하나가 없다면 Q1하고 매칭이 안된다
• 쿼리에서 단어를 하나 골라서 어떤 문서와 전체 쿼리가 매칭되는지를 확
인할 수 있다

24. • Disjunction 쿼리
• Q3: “WHEELS” OR “BUMPERS”
• 단어 중 하나만 문서에서 등장 해도 쿼리가 문서와 매치가 된
다
• 반대로 어떤 쿼리가 문서와 매칭되지 않는지를 확인하려면 모
든 단어를 문서와 매칭해봐야 한다

25. • Query 글에서 추출한 단어들을 가지고 색인을 만든다.
• Q1: “bus”
• Q2: “car”
• Q3: “bumpers” and “wheels”
• 이 색인은 term들을 실제의 query 와 매핑하는 역할을 한다.

26. Document as a Query

27. • 어떤 문서와 매칭되는 모든 쿼리들을 찾기위해 문서를 쿼리로 던
져야 한다
• 문서의 모든 단어들로 disjunction(OR) query 를 만든다
• 문서의 단어 중에서 하나라도 나타나는 모든 쿼리를 찾는다
• 하나의 문서로부터 inverted index를 만들면 자동으로 이
term 들이 생성된다

28. 문서와 매칭되는 쿼리들을 찾는 과정
1. 쿼리의 색인을 만든다
2. 문서의 disjunction query 를 퀴리의 색인에 검색해서 어떤 쿼
리들이 매칭될 가능성이 있는지 찾는다
3. 이 쿼리들을 가지고 실제로 문서에 검색을 해서 매칭이 되는지
확인한다

30. • 문서: “The wheels on the bus go round and round”
• disjunction query:
“and” OR “bus” OR “go” OR “on” OR “round” OR “the” OR “wheels”
• 쿼리 색인 term
• Q1: “bus”
• Q2: “car”
• Q3: “wheels”, “bumpbers”
• Q1와 Q3는 전체 쿼리를 검색을 해서 문서와 매칭되는지 확인한다
• Q2는 검색을 할 필요가 없으므로 건너뛴다

31. • 이 작업이 복잡해 보일수있지만 전체 99%의 쿼리들을 수행하지
않아도 되게 한다
• 가장 빠른 쿼리는 수행하지 않는 쿼리다

32. More Optimizations

33. Term Frequency Analysis
• Conjunction query 의 단어를 선택할때 기준을 term
frequency 로 잡을 수 있다.
• “car” AND “bumpers”
• Query 색인과 문서를 매칭할때 한 단어라도 나타나지 않으면
그 문서와 매칭되지 않는 다는 것을 안다
• “bumpers” 라는 단어가 나타나는 빈도가 적으므로 선택한다

34. More Optimization
• 지금까지 세운 규칙
• Conjunction(AND)인 경우 그 중 하나의 단어만 추출
• Disjunction(OR) 인 경우 모든 단어를 추출

35. • 규칙에 의해 예제 트리에서 3가지의 다른 조합을 추출할 수 있다

36. • 조합에 따라서 매치가 될수도 있고 안될수도 있다
• 문서의 내용이 “term1 term2 term3” 라면 세번째 경우에 매치
가 안된다.
• 세번째: term4 term5

37. • 조금 더 정확하게 query pre-selection을 만들 수 없을까?
• 위 조합을 다시 조합하면 된다. 각각의 경우의 수를 다른 필드에 색인하
고, 문서를 각 필드에 검색한 결과를 AND 한다.
• _a:(term1 OR term2 OR term3) AND
• _b:(term1 OR term2 OR term3) AND
• _c:(term1 OR term2 OR term3)
• 여전히 실제로 문서가 매칭되는지는 검색을 통해야 알 수 있지만, 많이
줄일 수 있다.

38. Luwak stream search 정리
• Luwak은 위 optimizations들을 다 구현했다
• Luwak은 library 이다
• Single machine 에서 돌리는 건 한계가 있다.
• 어떤 시점 부터는 쿼리양이 늘어나서 위에서 설명한
optimization들로도 감당이 되지 않는다.
• 그렇다면 어떻게 확장할 것인가?

39. Scaling Stream Searching

40. 어떻게 확장 할 것인가?
• Scaling search across a cluster of machines
• 분산프레임워크를 새로 구축하는 것은 어렵다
• Apache Kafka 와 Apache Samza를 사용하기로 했다

41. Kafka

42. • “Kafka is a kind of message broker or message queue”
• 하나의 프로세스(producer)에서 생성한 메세지를 다른 프로세
스(consumer)로 전달한다
• Scalable
• Fault-tolerant

43. • 매우 큰 append-only file이라고 생각할 수 있다.
• Producer는 이 파일 맨 마지막에 메세지를 쓸 수 있다
• Consumer는 tail -f 와 같다
• 각 consumer는 순차적으로 메세지를 읽는다
• 각 consumer 별로 파일의 position을 가지고 있다
• Kafka 는 누가 어디까지 읽었는지 추적하지 않아도 된다.
• Consumer는 자기 위치만 기록해두면 된다.

44. Kafka Stream

45. Kafka: for scaling
• Kafka의 stream은 partition 되어있다
• hash 방식의 partitioning 이다
• Kafka는 replication을 지원한다
• Leader/follower 모델을 사용한다. Leader가 broker 역할
• 새로운 메세지는 모두 leader에게 가고 follower들에게 복제된
다
• Leader였던 노드가 죽으면 follower 중 하나가 leader가 된다

47. Kafka: Messages
• Kafka의 모든 메세지는 key, value 형태로 되어있다.
• Key는 메세지를 구분짓는 값이다
• Partition할때 사용한다
• Compaction을 할때 사용한다 (다음장에)
• Value는 임의의 길이의 문자열

48. Kafka: Compaction
• Compaction 은 append-only 정책의 예외
• 스트림에 동일한 key를 가진 스트림이 여럿 있다면 가장 최신의
메세지만 남기고 나머지를 삭제한다
• 즉, 나중에 들어온 메세지들이 그 전 메세지들을 overwrite 한
다
• 이것은 바로 일어나지 않고 특정 시간에 이루어진다. GC처럼.

50. • Compaction을 사용하지 않으면 메세지 개수가 늘면서 stream
크기가 증가
• Compaction을 사용하면 유일한 key 개수에 비례해서 stream
이 커진다. 즉, DB와 비슷하다.
• DB에 모든 key value 를 저장할 수 잇다면 Kafka에도 그렇
게 할 수 있다

51. Kafka 와 Luwak의 관계는?
• Luwak은 메모리에 모든 쿼리를 로딩한다
• Luwak은 누군가 query를 새로 등록하거나, 수정하거나, 삭제했을
때 알림을 받을 수 있어야 한다
• Query ID을 key 로 사용하고 query string을 value 로 사용한다.
• Stream compaction 으로 stream이 너무 커지는 것을 방지
• Luwak을 처음 실행할때 stream을 처음부터 끝까지 읽는다
• bootsrap stream이라고 부른다.

52. Samza

53. Samza
• “A framework for writing stream processing jobs on top
of Kafka”

54. Samza: Jobs
• 특정 stream을 consume 하도록 지정
• StreamTask Interface를 상속해서 구현
• process() 함수에서 stream message를 처리한다
• Output stream에 메세지를 출력하도록 할 수도 있다

56. Samza: Scaling
• Samza의 StreamTask를 Kafka의 partition 별로 생성
• 각 stream의 partition들의 message들을 순차적으로 처리한다
• Output은 자신의 stream 중 어떠한 partition으로도 보낼 수 있
다

57. • Partition별로 작업을 처리하는 특성을 이용해서 두 개 이상의
stream 작업을 join 할 수 있다
• 두 개의 stream
• 각 stream의 partition1 들을 join 처리하는 StreamTask
• 각 stream의 partition2 들을 처리하는 StreamTask
• 단, input stream 들이 같은 수의 partition을 가지고 있어야 한
다.

59. • 이러한 특성때문에 stream join을 scale 할 수 있다
• 각 stream이 user ID로 partition
• 각 stream 에서 user ID가 동일한 message들을 하나의
StreamTask에서 처리한다

60. 이 둘을 이용해서 어떻게 full-text search on stream을
할 수 있는 것일까?

61. Luwak & Samza

62. • Query Stream
• Bootstrap stream with compaction
• 사용자 쿼리를 추가/수정/삭제 할 수 있다
• 쿼리를 Luwak의 in-memory 에 반영한다
• Document Stream
• 쿼리와 매칭될 문서들
• Samza job이 문서를 읽어서 query색인에 매칭한다
• 결과를 output stream에 쓴다

63. • Does it scale?
• Samza 의 partition 모델은 다음과 같다.
• Stream A는 query stream
• Stream B는 document stream
• 각자 자신과 관련된 query-document 끼리 partition을 구성할
수 있으면 예제와 같은 모델을 사용할 수 있다.

65. • 하지만, 실제로는 다음과 같은 모델이 필요하다
• 모든 query 들과 모든 document들을 매칭할 방법이 필요하다
• SimpleTask8는 쿼리 파티션 4와 문서 파티션 2를 처리
• 쿼리와 문서 모두 여러개의 task에서 처리되는 것이다
• 그러면 마지막에 모든 matches를 합치면 된다.

67. • 안타깝게도 지금 Samza는 이러한 기능을 지원하지 않는다
• SAMZA-353 이슈에서 다뤄지는 중
• Samza와 Luwa 연동의 POC (Proof of Concept)를 Github에
서 찾을 수 있다.

68. 마무리
Luwak + Kafka + Samza

69. Luwak & Samza를 이용한 stream 검색의 시사점
• Luwak
• 쿼리를 색인하고 문서와 매칭하는 과정의 옵티마이징에서 배울
점이 있다
• Kafka
• Streaming framework 에 대한 이해
• Samza
• Streaming framework 을 어떻게 처리해야할지에 대해 시사

70. 출처
• Blog post: Real-time full-text search with Luwak and Samza
• http://www.confluent.io/blog/real-time-full-text-search-with-luwak-and-samza/
• Samza-Luwak Proof of Concept
• https://github.com/romseygeek/samza-luwak#high-level-architecture
• Luwak GitHub
• https://github.com/flaxsearch/luwak
• Apache Kafka
• http://kafka.apache.org
• Apache Samza
• http://samza.apache.org
• Blog post: Elasticsearch Percolator & Luwak: a performance comparison of streamed search implementations
• http://www.flax.co.uk/blog/2015/07/27/a-performance-comparison-of-streamed-search-implementations/