소프트웨어 요구 사항

  • 많은 플링크 개발자가 선호하는 환경인 유닉스 기반으로 설정 시 여러 도구 사용 가능해 편리
  • 플링크 DataStream API는 자바와스칼라에서 사용 가능
    • 자바 JDK(8또는 그 이상의 버전) 필수
  • 플링크 애플리케이션 개발에 필수는 아니지만 아래 소프트웨어 설치됐다고 가정
    • 아파치 메이븐 3.x.
    • 자바나 스칼라 개발용 IDE

 

 

IDE에서 플링크 애플리케이션 실행과 디버깅

  • 플링크가 분산 데이터 처리 시스템이긴 하지만 로컬 머신에서도 개발과 기본 테스트가능

 

 

IDE에서 예제 코드 불러오기

 

 

IDE에서 플링크 애플리케이션 실행

  • AverageSensorReadings
    • 여러 온도 센서에서 이벤트 발생하는 것을 흉내내는 이벤트 생성, 이벤트의 온도 화씨에서 섭씨로 변환해 매초 각 센서의 평균 온도 계산. 표준 출력 아웃풋
    • 프로그램 출력 - 여러 연산 태스크 진행상황 나타내는 SCHEDULING, DEPLOYING, RUNNING과 같은 문장으로 시작
  • 플링크 애플리케이션 실행 태스크를 여러 태스크매니저로 배포하는 잡매니저(마스터)에 데이터플로우 제출
    • 잡매니저와 태스크매니저는 여러 머신에서 별도의 JVM 프로세스로 실행
    • 보통 프로그램의 main() 메서드에서 데이터플로우 조립하고 StreamExecutionEnvironment.execute()가 실행될 때 원격의 잡매니저에 데이터플로우 제출
    • 플링크는 execute() 메서드 호출 시 잡매니저와 태스크매니저를 동일 JVM에서 별도 스레드로 시작할 수 있는 모드 제공
      • 전체 플링크 애플리케이션을 하나의 JVM 프로세스에서 멀티스레드로 실행 - 플링크 프로그램 IDE에서 실행시 유용

 

 

IDE에서 플링크 애플리케이션 디버깅

  • 단일 JVM 실행 모드 덕분에 플링크 애플리케이션 IDE에서 디버깅 가능
  • 디버깅 시 고려 사항
    • 병렬 값 지정하지 않으면 개발 머신의 CPU 코어 개수만큼 스레드 생성해 프로그램 실행 (멀티스레드로 실행되는 프로그램 디버깅)
    • 단일 JVM에서 프로그램이 실행되므로 클래스 로딩과 같은 문제 제대로 디버깅 되지 않을 수 있음
  • 단일 JVM에서 실행하지만 스레드 간에 통신할 때나 상태를 저장할 때 레코드 직렬화

 

 

플링크 메이븐 프로젝트 부트스트랩

  • 플링크는 자바나 스칼라 플링크 애플리케이션을 메이븐 프로젝트로 생성하는 메이븐 아키타입(archetype) wprhd
    • Flink Maven Quickstart Scala 프로젝트 생성 및 개발 시작 시 사용하는 명령어

mvn archetype:generate

mvn archetype:generate \\
-DarchetypeGroupId=org.apache.flink \\
-DarchetypeArtifactId=flink-quickstart-scala \\
-DarchetypeVersion=1.7.1 \\
-DgroupId=org.apache.flink.quickstart \\
-DartifactId=flink-scala-project \\
-Dversion=0.1 \\
-Dpackage=org.apache.flink.quickstart \\
-DinteractivateMode=false
  • 플링크 1.7 메이븐 프로젝트를 flink-scala-project에 생성
  • mvn 명령의 각 파라미터 변경하면 플링크 버전, 그룹과 아티팩트 식별자(artifact id), 버전과 패키지 변경 가능
  • src/ 폴더와 pom.xml 파일 포함
src \\
ㄴ main
     ㄴresources
        ㄴlog4j.properties
     ㄴscala
         ㄴorg
             ㄴapache
                 ㄴflink
                     ㄴquickstart
                        ㄴBatchJob.scala
                        ㄴStreamingJob.scala
  • 기본 골격이 되는 BatchJob.scala, StreamingJob.scala 필요 없을 시 삭제
  • 다음 명령으로 JAR 파일 빌드

상태 관리

  • 보통 태스크의 상태는 태스크가 유지하고 있는 데이터와 함수의 결과를 게산할 때 사용하는 모든 데이터 포함
    • 그림 3-10. 상태가 있는 스트림 처리 태스크
    • 상태 일관성과 관련된 모든 문제, 실패 처리와 저장소의 효과적인 접근 등은 플링크가 책임지므로 개발자는 애플리케이션 로직에만 집중 가능
    • 상태의 종류 : 연산자 상태(operator state), 키 상태(keyed state)
      • 스코프(scope)에 따라 접근 제한됨

 

 

연산자 상태

  • 스코프 : 연산자 태스크 하나
    • 한 태스크가 처리하는 모든 레코드가 동일 상태에 접근 가능
    • 그림 3-11. 연산자 상태를 가진 태스크
    • 플링크가 제공하는 세 종류의 기본 연산자 상태
      • 리스트 상태(List state)
        • 리스트의 요소들로 상태 표현
      • 유니온 리스트 상태(Union List state)
        • 리스트의 상태를 나타내는 것은 같으나 장애를 복구하거나 애플리케이션을 세이브포인트에서 시작할 때 리스트 상태와 차이 있음
      • 브로드캐스트 상태(Broadcast state)
        • 연산자의 모든 태스크 상태가 동일한, 특수한 경우에 사용하는 연산자 상태
          • 체크포인팅을 수행하거나 연산자를 재확장(rescaling)할 때 사용

 

 

키 상태(keyed state)

  • 레코드의 각 키 값별로 유지하고 접근할 수 있는 상태
  • 플링크는 각 키 값별로 하나의 상태 인스턴스 유지. 이 키 상태를 관리하는 연산자 태스크로 동일 키의 모든 레코드 전송
    • 태스크가 어떤 레코드를 처리할 때 현재 처리중인 레코드의 키와 일치하는 키 상태만 접근 가능 -> 동일 키를 가진 모든 레코드는 같은 상태에 접근
  • 그림 3-12. 키 상태를 사용하는 태스크
  • 키-값 맵(key-value map)처럼 키 값으로 연산자 병렬 태스크에 레코드를 분배한 것
  • 플링크는 이 분산 키-값 맵에 키 별로 저장할 수 있는 여러 상태 값 종류 제공
    • 값 상태(Value state)
      • 임의 타입의 값을 키 별로 저장. 복잡한 데이터 구조도 값 상태로 저장 가능
    • 리스트 상태(List state)
      • 각 키별로 값 리스트 저장. 리스트의 요소는 어떤 타입이라도 가능
    • 맵 상태(Map state)
      • 키별로 키-값 맵을 저장. 맵의 키와 값은 어떤 타입이든 가능

 

 

상태 백엔드

  • 연산자 태스크는 상태를 로컬에 유지해 고속의 상태 접근 보장
  • 상태의 정확한 저장, 접근, 유지는 상태 백엔드(state backend)라 부르는 플러그인 가능한 컴포넌트가 결정
  • 상태 백엔드는 로컬 상태 관리와 원격 저장소에 상태를 체크포인팅 하는 두 가지 책임 지고있음
  • 플링크
    • JVM 힙(heap)의 메모리 데이터 구조인 객체(object)를 저장하는 것처럼 상태를 관리하는 메모리 상태 백엔드 제공
      • 고속의 상태 접근 제공, 메모리 크기에 제약
    • 상태 객체를 직렬화하고 이 데이터를 RocksDB에 저장
      • 상태 접근은 느리지만 상태 크기는 천천히 증가
  • 태스크매니저 저장소는 프로세스가 언제라도 장애가 발생할 수 있으니 휘발성(volatile)이라 생각해야함
    • 상태 백엔드는 원격의 영구적인 저장소에 태스크의 상태를 체크포인팅함

 

 

상태가 있는 연산자의 수평 확장

  • 상태가 있는 연산자의 병렬 값 변경은 상태를 재분할해(repartitioning) 늘어난 병렬 태스크에 다시 할당해야 하므로 어려움
  • 플링크의 상태 수평 확장 지원의 네 가지 패턴
    • 키 상태를 사용하는 연산자
      • 수평 확장 시 병렬 태스크가 갖고 있는 키들을 더 적거나 많게 재분할
      • 키를 키 그룹(key group)으로 구조화. 하나의 키 그룹은 하나의 키 파티션. 플링크는 이 키 그룹 단위로 태스크에 여러 키 할당
      • 그림 3-13. 키 상태를 사용하는 연산자 수평 확장과 축소
    • 리스트 상태를 사용하는 연산자
      • 리스트 요소를 재분배해 확장
      • 연산자의 모든 병렬 태스크가 갖고 있는 리스트 요소를 수집해 새 태스크로 균등하게 재분배
      • 그림 3-14. 리스트 상태를 사용하는 연산자의 수평 확장과 축소
    • 브로드캐스트 상태를 사용하는 연산자
      • 상태를 새로운 태스크로 복사해 확장
      • 모든 태스크가 동일한 상태를 가졌다는 것을 보장하므로 이런 동작이 가능
      • 3-16. 브로드캐스트 상태를 사용하는 연산자의 수평 확장과 축소

 

체크포인트, 세이브포인트, 상태 복구

  • 정확히 한번(exactly-once) 상태 일관성을 보장하려고 플링크가 사용하는 체크포인트와 복구 방식

 

 

일관성 체크포인트(consistent checkpoint)

  • 모든 태스크가 정확히 동일한 시점에 각 태스크의 상태 복사
    1. 모든 입력 스트림 인입 금지
    2. 현재 처리 중인 데이터가 완료되기까지 대기
    3. 각 태스크의 상태를 복사해 원격의 영구저장소로 체크포인트 지정
    4. 모든 스트림의 인입 재시작
  • 그림 3-17. 스트리밍 애플리케이션의 일관성 체크포인트

 

 

일관성 체크포인트에서 복구

  • 플링크는 주기적으로 일관성 체크포인팅을 수행해 상태를 원격 저장소에 저장
  • 장애 발생 시 가장 최신 체크포인트를 사용해 일관성 있게 애플리케이션 상태 복구. 레코드 처리 재시작.
  • 그림 3-18. 체크포인트에서 애플리케이션 복구
  • 애플리케이션 세 단계 복구
    1. 전체 애플리케이션 재시작
    2. 상태가 있는 모든 태스크 상태를 가장 최신의 체크포인트로 재설정
    3. 모든 태스크 처리 시작
  • 모든 연산자가 체크포인팅 수행하고 모든 상태 복구한 후 모든 입력스트림의 위치가 체크포인팅 수행 당시 마지막으로 소비했던 위치로 재설정 된다면 애플리케이션 정확히 한번(exactly-once) 일관성 제공 가능
    • 애플리케이션의 모든 입력 스트림이 재설정 가능한 데이터 소스에서 데이터 소비하면 정확히 한 번 상태 일관성 운영 가능(ex. 아파치 카프카)
  • 상태 복구 후 애플리케이션은 체크포인팅 수행과 장애로 처리 중단된 시간 동안 쌓여있던 모든 데이터 재처리
    • 모든 연산자 상태가 이 데이터들을 처리하지 않은 시점으로 재설정되어서 정확히 한번 상태 일관성 보장

 

플링크의 체크포인트 알고리즘

  • 스트림 애플리케이션 전체에서 동시에 체크포인팅을 수행하는 단순 접근 방식은 짧은 지연 요구하는 애플리케이션에선 사실상 사용 불가능
    • 스탑더월드(stop-the-world) 일으킴 (gc 실행 위해 jvm이 애플리케이션 실행 멈춤)
  • 플링크는 챈디-램포트(Chandy0Lamport) 알고리즘을 기반으로 분산 스냅샷(distributed snapshot) 체크포인팅 구현
    • 애플리케이션 전체를 정지하지 않고 체크포인트와 데이터 처리 간의 결합 분리
    • 일부 태스크는 상태 저장하고 일부는 데이터 계속 처리
    • 배리어(barrier) 레코드 사용
      • 소스 연산자가 레코드 스트림에 체크포인트 배리어 주입
      • 체크포인트 배리어 이전에 처리한 레코드가 만든 상태 변경은 배리어의 현재 체크포인트에 포함. 이후는 다음 체크포인트에 포함
  • 그림 3-19. 상태가 있는 소스 두 개, 상태가 있는 태스크 두 개, 상태가 없는 싱크 두 개를 가진 스트리밍 애플리케이션
  • 그림 3-20. 잡매니저는 모든 소스로 메시지를 보내 체크포인트 초기화
  • 그림 3-21. 소스는 자신의 상태를 체크포인팅하고 체크포인트 배리어 내보냄
    • 체크포인트 메시지 수신 시 레코드 내보내지 않음
    • 소스 태스크는 로컬 상태를 상태 백엔드에 체크포인팅하고 체크포인트를 배리어 밖으로 향하는 모든 스트림 파티션으로 브로드캐스트
    • 상태 체크포인팅 완료시 태스크에 알리고, 태스크는 잡매니저에게 알림
    • 모든 배리어 전송 후 소스는 자신의 연산 계속 수행
    • 입력스트림은 체크포인팅이 수행됐던 시점의 위치에서 다시 시작
  • 그림 3-22. 태스크는 각 입력 파티션에서 배리어를 수신하고자 기다림. 배리어가 이미 도착한 입력스트림의 레코드는 버퍼링됨. 배리어가 도착하지 않은 입력 스트림의 레코드는 계속 처리됨
    • 배리어 정렬(barrier alignment) : 모든 배리어가 도착하기를 기다리는 것
  • 그림 3-23. 모든 배리어를 받자마자 자신의 상태를 체크포인티하고 체크포인트 배리어를 내보내는 태스크
  • 그림 3-24. 체크포인트 배리어를 내보낸 후 원래의 처리를 계속 수행하는 태스크
  • 그림 3-25. 싱크가 체크포인트 배리어의 수신 여부를 잡매니저에 알리고 모든 태스크가 자신의 상태 체크포인팅이 성곶적으로 끝났음을 잡매니저에 알리면 체크포인팅 완료

 

 

체크포인트가 성능에 미치는 영향

  • 플링크 설계상 체크포인팅 수행은 상태 백엔드의 책임. 상태 백엔드 구현에 따라 태스크의 상태 복제하는 방식 다름
    • 파일 시스템(FileSystem) 상태 백엔드와 RocksDB 상태 백엔드는 비동기 체크포인팅 지원
      • 체크포인팅 시작되면 상태 백엔드는 상태를 로컬에 복사. 복사 완료시 태스크 하던 일 계속 진행
    • 백그라운드 스레드는 로컬 스냅샷을 원격 저장소에 비동기로 복사. 체크포인팅 완료되면 태스크에 알림
      • 비동기 체크포인팅은 태스크의 데이터 처리 재시작까지 걸리는 시간 줄여줌
      • RocksDB 상태 백엔드는 증분 체크포인트(Incremental checkpoint) 기능도 있어서 전송할 데이터양 많이 줄일 수 있음
  • 배리어 정렬(Barrier Alignment) 단계 변형
    • 매우 짧은 지연과 최소 한 번(at-least-once) 상태 보장으로 충분한 애플리케이션은 배리어 정렬 시 배리어 도착 후 들어오는 레코드를 버퍼에 쌓는 대신 계속 처리하도록 플링크에 설정

 

 

세이브포인트(savepoint)

  • 체크포인트에 몇 가지 메타데이터를 추가한 것
  • 사용자가 명시적으로 세이브포인트 생성해야 함. 자동 삭제x

 

 

세이브포인트 사용

  • 애플리케이션을 세이브포인트에서 시작 가능(애플리케이션과 호환성 가진 세이브포인트- 애플리케이션이 세이브포인트 상태 읽기 가능)
    • 세이브포인트와 호환되는 다른 애플리케이션 시작 가능
    • 애플리케이션 로직 버그 수정, 상태 복구 후 입력 스트림의 이벤트 재처리 가능
  • 동일 애플리케이션을 다른 병렬 값으로 시작하거나 규모 확장, 축소 가능
  • 다른 클러스터에서 동일 애플리케이션 실행 가능
  • 세이브포인트 이용해 애플리케이션 정지시키고 나중에 재시작 가능
  • 애플리케이션의 상태를 이력으로 남기거나 아카이빙 가능

 

 

세이브포인트에서 애플리케이션 시작

  • 실행중인 애플리케이션의 세이브포인팅 수행 후 애플리케이션 시작 시 상태 복구에 세이브포인트 사용
  • 그림 3-26. 애플리케이션에서 세이브포인팅 수행하고 이 세이브포인트에서 애플리케이션 복구
    • 세이브포인트 실행되면 모든 태스크의 상태를 영구 저장소로 복사
    • 세이브포인트의 상태 데이터는 연산자 식별자(ID)와 상태이름 가지고 있음
      • 세이브포인트와 관련된 연산자가 있는 태스크로 세이브포인트 데이터 재분배
    • 수정한 애플리케이션을 세이브포인트에서 시작한다면 애플리케이션이 세이브포인트와 일치하는 식별자와 상태 이름을 가진 연산자를 포함할 때만 세이브포인트의 상태 복구 가능
    • 플링크는 연산자에 고유 식별자 설정되어 있지 않으면 자동으로 할당
      • 연산자 식별자는 앞쪽의 연산자 식별해 생성됨 - 앞쪽의 연산자 식별자 변경시 현재 연산자 식별자도 변경됨
      • 상태를 유실해도 관계없는 애플리케이션일 때만 기본 연산자 식별 사용하도록 제한해야 함

시스템 아키텍처

  • 플링크는 상태가 있는 병렬 스트림을 처리할 수 있는 분산 시스템
    • 분산시스템은 일반적으로 클러스터의 컴퓨팅 자원 관리, 프로세스 조율, 신뢰성과 고가용성을 갖춘 데이터 저장소 및 장애 복구와 같은 여러 어려운 문제 다뤄야 함
    • 플링크는 핵심 기능인 분산 데이터 스트림 처리에만 집중하고 나머지 기능은 기존 클러스터 인프라와 서비스를 이용
      • 아파치 메소스, YARN, 쿠버네티스와 같은 클러스터 자원관리자와 통합. 독립형(standalone)클러스터로도 설정해 실행 가능
      • 신뢰성 있는 분산 저장소 제공하지 않지만 HDFS나 객체 저장소인 S3같은 파일 시스템 이용
      • 고가용성에서 필요한 리더 선출(leader election) 기능은 아파치 주키퍼 사용

 

플링크 컴포넌트

  • 네 개의 컴포넌트로 구성 : 잡매니저(JobManager), 리소스매니저(ResourceManager), 태스크매니저(TaskManager), 디스패처(Dispatcher)
  • 플링크는 자바와 스칼라로 구현됐기 때문에 모든 컴포넌트를 자바 가상머신(JVM)에서 실행 가능
  • 잡매니저
    • 애플리케이션의 실행을 제어하는 마스터 프로세스
    • 애플리케이션은 잡그래프(JobGraph)라 부르는 논리 데이터플로우 그래프와 애플리케이션에 필요한 모든 클래스, 라이브러리, 기타 자원을 포함하는 JAR로 구성
    • 잡매니저는 잡 그래프를 실행그래프(ExecutionGraph)라 부르는 물리 데이터플로우 그래프로 변환
    • 리소스매니저에서 태스크 실행에 필요한 자원(태스크매니저 슬롯(slot))을 요청
    • 애플리케이션을 실행할 수 있는 충분한 태스크 슬롯을 할당받으면 잡매니저는 작업을 처리할 태스크로 실행그래프 배포
    • 애플리케이션 실행 중 체크포인트를 조율하고 중앙에서 제어해야 하는 모든 동작을 책임짐
  • 리소스 매니저
    • YARN, 메소스, 쿠버네티스, 독립형 클러스터와 같은 각 환경에서 자원을 관리할 수 있는 리소스매니저를 지원
    • 플링크의 실행 단위인 태스크매니저 슬롯을 관리
    • 잡매니저가 태스크매니저 슬롯을 요청하면 리소스매니저는 유휴(idle) 슬롯을 잡매니저에게 제공하도록 태스크매니저에 지시
    • 잡매니저의 요청을 수용할 만큼 충분한 슬롯을 갖고 있지 않다면 자원 제공자(YARN, 메소스, 쿠버네티스 등)에게 태스크매니저 프로세스를 실행할 컨테이너를 제공(프로비전)하도록 요청
    • 유휴 태스크매니저를 종료해 계산 자원을 반환
  • 태스크매니저
    • 플링크의 워커(worker) 프로세스
    • 일반적으로 한 플링크 클러스터는 여러 태스크매니저 가지고 있고 각 태스크매니저는 여러 슬롯을 제공
    • 슬롯의 개수는 태스크매니저가 실행할 수 있는 최대 태스크 개수를 제한
    • 태스크매니저를 시작할 때 태스크매니저는 자신의 모든 슬롯을 리소스매니저에 등록
    • 리소스매니저에서 슬롯 제공 지시가 내려오면 태스크 매니저는 하나 이상의 슬롯을 잡매니저에 제공. 잡매니저는 실행 태스크를 이 슬롯에 할당
    • 태스크가 다른 태스크매니저에 있는 태스크와 통신이 필요하면 태스크매니저를 통해 데이터를 교환
  • 디스패처
    • 여러 잡을 실행할 때 사용하며, 애플리케이션을 제출할 수 있는 REST 인터페이스 제공
    • 사용자가 디스패처에 애플리케이션을 제출하면 디스패처는 잡매니저를 시작하고 애플리케이션을 잡매니저에게 넘김
    • REST 인터페이스 덕분에 방화벽 뒤에 있는 클러스터도 HTTP를 통해 디스패처 서비스 제공 가능
    • 잡 실행의 정보를 제공하는 대시보드도 실행
    • 애플리케이션 제출 방식에 따라 디스패처 불필요할 수도 있음
  • 그림 3-1. 애플리케이션 제출과 컴포넌트 상호작용

 

애플리케이션 배치

  • 프레임워크 방식(Framework style)
    • 플링크 애플리케이션을 하나의 JAR 파일로 패키징한 후 클라이언트를 이용해 현재 실행 중인 서비스(플링크 디스패처, 플링크 잡매니저, YARN의 리소스매니저) 중 하나로 제출
    • 어떤 서비스든 클라이언트가 제출한 플링크 애플리케이션을 받아 실행하는 것 보장
      • 잡매니저로 애플리케이션을 제출하면 잡매니저는 즉시 애플리케이션 실행
      • 디스패처, YARN 리소스매니저로 제출하면 먼저 잡매니저를 기동하고 제출한 애플리케이션을 잡매니저로 넘김 -> 잡매니저 해당 애플리케이션 즉시 실행
  • 라이브러리 방식(Library style)
    • 플링크 애플리케이션을 도커(Docker) 이미지처럼 애플리케이션에 특화된 컨테이너 이미지(container image)로 만듦
      • 잡매니저와 리소스매니저를 실행할 코드를 포함
      • 리소스매니저와 잡매니저를 자동으로 구동하고 번들링돼 있는 잡을 제출
      • 태스크매니저 컨테이너 배포는 잡과 무관한 이미지를 사용
      • 이 이미지에서 시작한 컨테이너는 태스크매니저를 시작하며, 태스크매니저는 리소스매니저에 연결해 슬롯 등록
      • 쿠버네티스와 같은 외부 자원 관리자가 컨테이너 이미지를 시작시키면 장애가 발생할 때 컨테이너 재시작 보장
  • 프레임워크 방식은 실행 중인 서비스에 애플리케이션을 제출하는 전통적 접근 방식을 따름
  • 라이브러리 방식에서는 플링크를 이용하지 않음
    • 플링크 서비스를 애플리케이션과 함께 컨테이너 이미지 안에 라이브러리로 패키징
    • 마이크로서비스 아키텍처는 일반적으로 이런 배치 방식 사용

 

태스크 실행

  • 태스크매니저는 여러 태스크를 동시에 실행 가능
  • 같은 연산자(데이터 병렬화), 다른 연산자(태스크 병렬화), 또는 다른 애플리케이션(잡 병렬화) 태스크가 태스크매니저의 태스크가 될 수 있음
  • 태스크매니저는 데이터 처리 슬롯 개수 설정을 제공해 동시 실행 가능한 태스크의 개수 제어
  • 슬롯은 연산자의 병렬 태스크 같이 스트리밍 애플리케이션의 일부분 실행
  • 그림 3-2. 연산자, 태스크 처리 슬롯
    • 연산자 A, C - 소스. 연산자 E - 싱크. 연산자 C, E - 병렬값이 2, 나머지 4.
    • 최대 병렬 값이 4이므로, 애플리케이션 실행해 최소 4개 처리 슬롯 필요 - 각 두 개의 처리 슬롯을 가진 태스크 매니저 두 개가 있다면 요구 사항 충족 가능
    • 잡매니저는 잡그래프를 실행그래프로 변환하고 네 개의 슬롯에 태스크 할당. 플링크는 병렬 값이 4인 연산자의 태스크를 각 슬롯에 할당
    • 연산자를 태스크로 분할해 슬롯에 할당하면 여러 태스크를 같은 태스크매니저에 배포할 수 있는 이점 (C - 1.1, 2.1 E - 1.2, 2.2에 할당)
      • 같은 프로세스 안에 있는 태스크들이 네트워크를 사용하지 않고도 데이터 교환을 효과적으로 할 수 있음
      • 너무 많은 태스크를 같은 태스크매니저에 할당하면 태스크매니저에 부하가 발생해 성능이 나빠지는 역효과
  • 태스크매니저는 JVM 프로세스 안에서 멀티스레드로 태스크 실행
  • 스레드는 프로세스보다 더 가볍고 태스크 간 통신 비용이 싸지만 태스크 각각을 완전히 고립시킬 수 없음
  • 태스크 중 하나만 오동작해도 전체 태스크매니저 프로세스가 죽고, 따라서 해당 태스크매니저에서 실행 중인 모든 태스크도 죽음
    • 태스크매니저당 하나의 슬롯만 설정하면 애플리케이션을 태스크매니저 장애에서 고립시킬 수 있음
  • 태스크매니저 안에서는 스레드를 이용한 병렬 방법을 사용하고, 한 호스트에 여러 태스크매니저 프로세스 배치 가능
    • 플링크에 성능과 자원 고립의 상충 문제를 같이 해결할 수 있는 유연성 제공

 

고가용성 설정

  • 애플리케이션 중 일부에 장애가 발생하더라도 애플리케이션 실행은 중단되지 않게하는 것이 중요
  • 태스크매니저 실패
    • 태스크매니저 중 하나가 실패하면 가용 슬롯이 떨어짐
    • 이 상황에서 잡매니저는 리소스매니저에게 더 많은 슬롯을 제공하도록 요청
    • 이 요청이 불가능할 때(ex. 애플리케이션이 독립형 클러스터에서 실행 중일 때) 잡매니저는 충분한 슬롯을 확보할 수 있을 때까지 애플리케이션 재실행 불가
    • 애플리케이션이 재시작 전략은 잡매니저가 얼마나 자주 애를리케이션을 재시작하고 재시작 시도 동안 얼마나 오래 기다릴지 결정
  • 잡매니저 실패
    • 잡매니저는 완료한 체크포인트 정보와 스트리밍 애플리케이션 실행 제어 관련 메타데이터 유지
    • 잡매니저가 사라지면 스트리밍 애플리케이션은 레코드 더 처리 불가
      • 플링크 잡매니저는 애플리케이션의 단일 실패 지점(single point of failure)
      • 잡매니저가 죽으면 다른 잡매니저로 책임과 메타데이터를 넘기는 고가용성 기능을 제공해 이 문제 해결
    • 플링크의 고가용성 모드는 조율(coordination)과 합의(consensus) 기능을 분산 서비스로 제공하는 아파치 주키퍼를 기반으로 함
      • 신뢰성 있는 데이터 저장소인 주키퍼를 사용해 리더 선출과 고가용성 기능 구현
      • 고가용성 모드로 운영할 때 잡매니저는 잡그래프와 애플리케이션 JAR 파일처럼 필수 메타데이터를 원격의 영구 저장 시스템에 저장
        • 잡매니저는 메타데이터 저장 위치 정보를 주키퍼에 저장
        • 애플리케이션 실행 중 잡매니저는 각 태스크의 체크포인트 위치 정보 수집
        • 모든 태스크가 자신의 상태를 원격 저장소에 저장하는 체크포인트 완료 시점이 되면 잡매니저는 태스크의 상태 정보를 원격 저장소에 저장하고 그 위치를 주키퍼에 저장
      • 플링크는 잡 매니저가 실패할 때 복구에 필요한 모든 데이터를 원격 저장소에 저장하고, 주키퍼에는 저장 위치 정보를 보관
      • 그림 3-3. 플링크의 고가용성 설정
        • 잡매니저가 실패하면 애플리케이션에 속한 모든 태스크는 자동으로 취소되고, 실패한 잡매니저에서 모든 작업을 인계받은 새 잡매니저는 다음 절차 수행
          1. 원격 저장소의 잡그래프, JAR 파일, 마지막 체크포인트 위치를 주키퍼에 요청
          2. 애플리케이션을 계속 실행할 때 필요한 처리 슬롯을 리소스매니저로 요청
          3. 애플리케이션을 재시작하고 모든 태스크의 상태를 마지막 완료한 체크포인트로 재설정
        • 쿠버네티스와 같은 컨테이너 환경에서 라이브러리 방식으로 애플리케이션을 실행할 때 보통 컨테이너 오케스트레이션 서비스(orchestration service)가 잡매니저나 태스크매니저 컨테이너를 자동으로 재시작
        • YARN이나 메소스에서 실행할 때는 남아있는 플링크 프로세스가 잡매니저나 태스크매니저 프로세스를 재시작하는 트리거 역할을 함
        • 독립형 클러스터 환경에서는 실패한 프로세스를 재시작하는 도구를 제공하지 않음
          • 실패한 프로세스의 작업을 넘겨받을 수 있는 대기(standby) 잡매니저와 태스크매니저를 실행하는 것이 나을 수 있음

 

플링크 내부의 데이터 전송

  • 태스크매니저는 전송 태스크에서 수신 태스크까지 데이터를 전송하는 역할
  • 태스크매니저의 네트워크 컴포넌트는 데이터를 전송하기 전에 버퍼에 레코드를 배치(batch)로 모아서 보냄( 네트워크 버퍼 풀(network buffer pool)
    • 네트워크 자원을 효율적으로 사용하고 높은 처리율을 낼 수 있는 기본적인 기술이며 네트워크나 디스크 IO에서 사용하는 버퍼링 기술과 유사
  • 태스크매니저는 일대일 관계의 전용 TCP 연결을 유지해 다른 태스크매니저와 데이터를 교환
    • 셔플 연결 패턴(Shuffle connection pattern)에서 각 전송 태스크는 각 수신 태스크로 데이터를 전송할 수 있어야 함
    • 태스크매니저는 내부적으로 각 전송 태스크가 각 수신 태스크로 데이터를 보낼 때 사용할 수 있는 전용 네트워크 버퍼 갖고 있어야 함
    • 그림 3-4. 태스크매니저 간의 데이터 전송
      • 네 개의 전송 태스크는 각 수신 태스크로 데이터를 전송할 때 필요한 버퍼를 적어도 하나씩 갖고 있으며, 수신 태스크도 데이터를 받는 버퍼를 적어도 하나씩 가지고 있어야 함
      • 동일 태스크매니저로 전송할 태스크 버퍼들은 동일 네트워크 연결을 통해 다중 전송(multiplex)됨
      • 데이터를 셔플링하거나 브로드캐스트하는 연결일 때 각 전송 태스크는 각 수신 태스크에 대한 버퍼 하나씩 가지고 있어야 함 - 연산에 참여한 태스크 수의 제곱
      • 플링크의 기본 네트워크 버퍼 설정은 중소규모 클러스터에서 사용하기 충분
      • 전송 태스크와 수신 태스크가 동일 태스크매니저 프로세스에서 실행될 때 전송 태스크는 외부로 나가는 레코드를 바이트 버퍼로 직렬화한 후 버퍼가 꽉 차면 큐(queue)에 넣음
        • 수신 태스크는 큐에서 버퍼를 꺼낸 후 역직렬화해 레코드 만듦
        • 따라서 동일 태스크매니저에서 실행 중인 태스크는 네트워크 통신을 유발하지 않음

 

크레딧 기반 흐름 제어

  • 버퍼링 사용은 네트워크 연결의 대역폭을 최대한 이용하는데 있어서 꼭 필요
  • 스트리밍 처리 관점에서 버퍼링의 한 가지 단점은 레코드가 생성되는 즉시 전송되지 않고 버퍼에 모이면서 발생하는 지연 시간의 증가
  • 플링크의 크레딧 기반 흐름 제어
    • 수신 태스크가 전송 태스크에 크레딧 부여(크레딧 : 수신 태스크가 데이터를 수신하려고 예약한 네트워크 버퍼 개수)
    • 수신 태스크가 전송 태스크에 크레딧 알려주면 알림을 받은 전송 태스크는 부여받은 크레딧만큼의 버퍼와 백로그 크기(backog size - 가득 차서 전송할 준비가 된 네트워크 버퍼 수)를 수신 태스크에 전송
    • 수신 태스크는 예약한 버퍼로 도착한 데이터를 처리하고, 전송 태스크의 백로그 크기를 이용해 연결돼 있는 모든 전송 태스크의 다음 크레딧을 우선순위 방식으로 정함
  • 수신 태스크가 데이터를 받을 수 있는 충분한 자원을 준비하자마자 데이터를 전송하므로 지연 시간 감소 가능
  • L 데이터 전송이 특정 태스크에 편향(skewed) 있을 때 전송 태스크의 백로그 크기에 따라 크레딧을 부여하므로, 네트워크 자원을 균등하게 분배하는 효과적인 방식
  • 플링크가 높은 처리율과 짧은 지연을 낼 수 있도록 도와주는 중요한 특징

 

 

태스크 체이닝

  • 플링크는 특정 조건에서 로컬 통신의 부하를 줄여주는 태스크 체이닝(task chaining) 최적화 기법 사용
  • 태스크 체이닝 요구 조건
    1. 두 개 이상의 연산자가 동일한 병렬값으로 설정돼 있어야 함
    2. 연산자들이 로컬 포워드 채널(local forward channel - 동일 프로세스에서 앞으로만 흐르는 통신 채널)로 연결돼야 함
  • 그림 3-5. 태스크 체이닝 요구 조건에 따라 구성한 연산자 파이프라인
  • 그림 3-6. 모든 함수를 하나로 합쳐 단일 스레드에서 실행되는 태스크에 넣고 데이터는 메서드 호출로 전달하는 태스크 체이닝
    • 함수 간의 레코드 전달에 어떤 직렬화나 통신 비용이 들지 않음
    • 로컬 태스크 간의 통신 비용을 극적으로 줄여줌
    • 태스크 체이닝 없이 파이프라인을 실행하는 것이 옳을 때
      • 많은 태스크로 구성된 긴 파이프라인을 분할하거나 태스크 체인을 여러 개로 쪼개 부하가 큰 함수를 서로 다른 슬롯에 할당
      • 그림 3-7. 태스크 체이닝 없이 한 스레드에 한 태스크를 실행하여 버퍼와 직렬화를 통해 데이터 전송
  • 플링크의 태스크 체이닝 기능은 기본적으로 활성화됨

 

이벤트 시간 처리

  • 이벤트 시간 애플리케이션은 처리 시간 애플리케이션보다 추가적인 설정 필요
  • 순수하게 처리시간 환경에서 동작하는 시스템 내부보다 이벤트 시간을 지원하는 스트림 처리기의 내부가 좀 더 복잡
  • 플링크는 일반적인 이벤트 처리 연산에서 사용가능한 직관적이며 사용이 쉬운 여러 기본 연산자를 제공할 뿐 아니라 사용자 정의 연산자로 좀 더 복잡한 이벤트 시간 애플리케이션을 개발할 수 있도록 표현력이 풍부한 API 제공

 

타임스탬프

  • 플링크 이벤트 시간 애플리케이션이 처리하는 모든 레코드는 타임스탬프 동반 필요
  • 타임스탬프는 레코드를 특정 시점(레코드가 표현하고 있는 이벤트의 발생 시점)과 결부
    • 레코드의 타임스탬프가 스트림 속도와 얼추 비슷하게 앞으로 나간다면 타임스탬프의 의미를 애플리케이션이 자유롭게 정할 수 있음)
  • 이벤트 시간 모드로 데이터 스트림을 처리할 때 플링크는 레코드의 타임스탬프를 이용해 시간 기반 연산자 실행
    • ex. 시간-윈도우 연산자는 타임스탬프를 이용해 윈도우에 레코드 할당
  • 플링크는 타임스탬프를 16바이트의 Long값으로 변환해 레코드의 메타데이터에 첨부
    • 사용자 정의 연산자에서 Long값을 마이크로초로 해석 가능

 

워터마크

  • 이벤트 시간 애플리케이션은 레코드 타임스탬프 뿐만 아니라 워터마크도 제공해야 함
  • 이벤트 시간 애플리케이션의 각 태스크는 워터마크를 사용해 현재 이벤트 시간을 얻음
  • 시간 기반 연산자는 이벤트 시간을 사용해 연산을 시작하거나 스트림을 앞으로 진행시킴
    • ex. 시간-윈도우 태스크는 이벤트 시간이 윈도우 경계 끝을 지날 때 윈도우에 모인 레코드들을 계산하고 그 결과를 내보냄
  • 플링크는 워터마크를 Long 값의 타임스탬프를 갖고 있는 특별한 레코드를 추가해 구현
  • 그림 3-8. 타임스탬프를 포함하고 있는 레코드와 워터마크가 있는 스트림
  • 워터마크의 기본 속성
    • 태스크의 이벤트 시간 시계(event-time clock)가 앞으로만 흘러가게 하고 역행하지 않게 함
    • 레코드의 타임스퀘어와 관련 있음. T 타임스탬프를 갖고 있는 워터마크는 이후에 오는 모든 레코드의 타임스탬프가 T보다 커야 한다는 것 의미
      • 레코드의 타임스탬프 순서가 바뀐 스트림을 처리하는 데 사용
      • 시간 기반 연산자를 실행하는 태스크는 순서가 바뀌었을 수도 있는 레코드들을 수집하고 이벤트 시간 시계(워터마크를 수집하면서 앞으로 가는 시계)가 해당 타임스탬프와 관련된 레코드가 더 들어오지 않을 것이라 예상할 때 연산을 시작
      • 태스크가 워터마크 속성을 위반하는 레코드를 받으면 이 레코드의 타임스탬프가 속해야 하는 연산은 이미 종료됐을 가능성 높음 - 연착 레코드(late records)라 함
        • 플링크는 연착 레코드를 처리하는 여러 방법 제공
    • 워터마크의 흥미로운 속성 중 하나는 애플리케이션 결과의 완성도와 지연을 애플리케이션이 제어할 수 있게 한다는 것
      • 레코드 타임스탬프에 가까운 매우 빠듯한 워터마크는 처리 지연을 짧게 만듦 - 결과의 완성도 떨어짐 (관련 레코드가 결과에 미포함 - 연착 레코드로 생각함)
      • 보수적으로 워터마크(타임스탬프에서 멀리 떨어진 워터마크)를 정하면 처리 지연 길어짐 - 결과의 완성도 높아짐

 

워터마크 전파와 이벤트 시간

  • 플링크는 워터마크를 연산자 태스크가 받아서 내보내는 특별한 레코드로 구현
  • 태스크는 내부에 타이머 서비스(timer service)를 갖고 있으며, 이 서비스는 타이머(timer)를 유지하고 워터마크가 도착할 때마다 타이머를 활성화함
  • 태스크는 이 타이머 서비스에 타이머를 등록해 미래의 특정 시점에 어떤 연산 수행 가능 (ex. 윈도우 연산자)
  • 태스크가 워터마크를 받으면 다음과 같은 동작 벌어짐
    1. 태스크는 내부 이벤트 시간 시계를 워터마크의 타임스탬프 기준으로 갱신
    2. 태스크의 타이머 서비스는 갱신한 이벤트 시간보다 오래된 타이머를 모두 찾음. 시간이 만료된 타이머를 등록한 태스크는 어떤 연산을 수행하거나 레코드를 내보내는 콜백 함수 호출
    3. 태스크는 갱신한 이벤트 시간을 워터마크에 실어서 내보냄
  • 플링크는 데이터 스트림을 파티션으로 분할하고 각 파티션을 개별 연산자 태스크에 할당해 병렬로 처리
    • 각 파티션은 타임스탬프가 있는 레코드와 워터마크를 흘려보내는 스트림
  • 태스크 앞뒤에 어떤 연산자와 연결돼 있는지에 따라 태스크는 여러 입력 파티션에서 레코드와 워터마ㅡ를 수신하고 여러출력 파티션으로 레코드와 워터마크 전송 가능
  • 태스크는 각 입력 파티션에 대해 하나의 워터마크 유지
    • 입력 파티션에서 워터마크 받으면 해당 파티션의 현재 워터마크 값과 새 워터마크 값 비교해 최댓값을 새로운 워터마크로 갱신
    • 태스크는 모든 입력파티션의 워터마크 중 최솟값으로 이벤트 시간 시계 값 갱신
    • 이벤트 시간 시계가 앞으로 흐르면 태스크는 등록된 타이머 중 시간이 만료된 모든 타이머 활성화
    • 마지막에는 연결괸 모든 출력 파티션으로 새 워터마크를 내보내 전체 하위 스트림 태스크가 새 이벤트 시간 받게 함
    • 그림 3-9. 워터마크로 태스크의 이벤트 시간 갱신
    • Union이나 CoFlatMap과 같은 두 개 이상의 입력 스트림을 갖고 있는 연산자의 태스크도 모든 파티션의 워터마크 중 최솟값으로 이벤트 시간 시계 계산
      • 워터마크가 다른 입력 스트림에서 나오더라도 같은 파티션에서 나온 워터마크로 취급
      • 결과적으로 두 입력의 레코드는 같은 이벤트 시간 시계를 기바으로 처리됨
      • 두 입력 스트림에서 받은 이벤트 타임스탬프가 동기화돼 잇지 않으면 이런 동작은 문제 일으킬 수 있음
    • 플링크의 워터마크 처리오 전파 알고리즘은 연산자 태스크가 생성한 레코드가 워터마크와 최대한 동기화된 타임스탬프 갖도록 보장
      • 이를 위해서 모든 파티션이 지속적으로 증가하는 워터마크 제공해야 함
        • 어떤 파티션의 워터마크가 더이상 아픙로 가지 않고 아무런 레코드나 워터마크 내보내지 않는다면 태스크의 이벤트 시간 시계 더 진행하지 않고 태스크 타이머도 트리거 되지 않음
          • 시간 기반 연산자의 처리 지연과 상태 크기 굉장히 커질 수 있음

 

타임스탬프 할당과 워터마크 생성

  • 보통 스트림 애플리케이션으로 스트림 데이터가 들어올 때 타임스탬프를 할당, 우터마크 생성
  • 타임스탬프 결정은 애플리케이션이 하고 워터마크는 타임스탬프와 스트림의 특성에 의존하므로 애플리케이션이 명시적으로 타임스탬프를 할당하고 워터마크 생성해야 함
  • 타임스탬프, 워터마크 생성 방식
    1. 소스에서
      • SourceFunction을 통해 애플리케이션으로 스트림이 들어올 때 타임스탬프 할당, 워터마크 생성
      • SourceFunction은 레코드 스트림을 내보냄. 타임스탬프는 레코드와 함께 나가고 워터마크는 특별한 레코드로 특정시점에 나감
      • SourceFunction이 일시적으로 더 이상의 워터마크 내보내지 않는다면 자신을 유휴(idle)상태로 선언 가능
      • 플링크는 SourceFunction의 유휴 상태 스트림 파티션을 다음 연산자의 워터마크 계산에서 제외
    2. 주기적인 할당자(periodic assigner)
      • DataStream API : 각 레코드에서 타임스탬프를 추출하는 AssignerWithPeriodicWatermarks라 부르는 사용자 정의 함수 지원, 이 함수를 주기적으로 질의 해 현재 워터마크 알아냄
      • 플링크는 추출한 타임스탬프를 각 레코드에 할당, 질의한 워터마크는 스트림에 주입
    3. 구두점 할당자(punctuated assigner)
      • AssignerWithPunctuatedWatermarks : 각 레코드에서 타임스탬프를 추출하는 또 다른 사용자 저으이 함수. 특별한 입력 레코드에 포함된 워터마크를 추출하는데 사용 가능
        • 필수는 아니지만 각 레코드에서 워터마크 추출 가능
  • 연산자에 따라 레코드를 처리하고 나면 레코드의 타임 스탬프나 순서 파악이 매우 어려워질 수 있으므로 보통 소스 연산자에 가까운 곳에 사용자 정의 타임스탬프 함수 적용

데이터플로우 그래프

  • 데이터플로우 프로그램
    • 데이터 처리 연산 사이로 데이터가 어떻게 흐르는지(flow) 기술
  • 방향성 그래프(directed graph)
    • 데이터플로우 프로그램을 표현하는 일반적 방법
    • 노드(node)
      • 연산자(operator)라 부르고 계산 표현
      • 연산자 : 데이터플로우 애플리케이션의 기본 기능 단위
        • 입력으로 들어온 데이터를 소비하고 어떤 계산을 수행한 후 그 결과를 다음처리에서 사용할 수 있도록 출력으로 내보냄
        • 데이터 소스(data source) : 입력이 없는 연산자
        • 싱크(sink) : 출력이 없는 연산자
      • 논리적(logical) 데이터플로우 그래프 : 개념적 수준에서 바라본 계산 로직의 모습
        • 그림 2-1. 지속적으로 해시 태그를 카운트하는 논리적인 데이터플로우 그래프
        • 논리적 데이터플로우 그래프를 실행하려면 논리적 데이터플로우 그래프를 물리적 데이터플로우로 변환해야 함
        • 물리적 데이터플로우 : 프로그램을 어떻게 실행해야 하는지 자세히 지정 (ex. 분산 처리 엔진 사용 시 각 연산자는 각각 다른 물리적 장비에서 돌아가는 여러 병렬 태스크가 됨)
          • 그림 2-2. 해시 태그를 카운트하는 물리적 데이터플로우 그래프(노드는 태스크 표현)
            • '해시 태그 추출'과 '카운트' 연산자는 두 개의 병렬 연산 태스크를 갖고 있으며, 각 태스크는 입력 데이터 분할해 연산 수행
        • 에지(edge)
          • 의존 관계 표현

 

 

데이터플로우 프로그래밍 소개

    • 데이터플로우 프로그램
      • 데이터 처리 연산 사이로 데이터가 어떻게 흐르는지(flow) 기술
    • 방향성 그래프(directed graph)
      • 데이터플로우 프로그램을 표현하는 일반적 방법
      • 노드(node)
        • 연산자(operator)라 부르고 계산 표현
        • 연산자 : 데이터플로우 애플리케이션의 기본 기능 단위
          • 입력으로 들어온 데이터를 소비하고 어떤 계산을 수행한 후 그 결과를 다음처리에서 사용할 수 있도록 출력으로 내보냄
          • 데이터 소스(data source) : 입력이 없는 연산자
          • 싱크(sink) : 출력이 없는 연산자
        • 논리적(logical) 데이터플로우 그래프 : 개념적 수준에서 바라본 계산 로직의 모습
          • 그림 2-1. 지속적으로 해시 태그를 카운트하는 논리적인 데이터플로우 그래프
            •  
  • 데이터 병렬화와 태스크 병렬화
    • 데이터플로우 그래프의 병렬화 방식
      • 데이터 병렬화(data parallelism) : 동일 연산 수행하는 태스크를 각 입력 파티션에 할당해 병렬로 실행
        • 대용량 데이터 처리의 부하를 여러 장비로 분산시킬 수 있어서 매우 유용
      • 태스크 병렬화(task parallelism) : 같거나 다른 데이터에 여러 연산을 수행하는 태스크 할당
        • 클러스터의 계산 자원을 좀 더 효율적으로 사용 가능
  • 데이터 교환 전략
    • 데이터 교환 전략(data exchange strategy) : 물리적 데이터플로우 그래프에서 어떤 태스크로 레코드를 할당할지 정의
    • 그림 2-3. 데이터 교환 전략

      • 전진(Forward) 전략 : 한 태스크로 들어온 데이터를 다른 태스크쪽으로 내보냄
        • 두 태스크가 동일한 물리적 장비에 할당된다면(보통 태스크 스케줄러가 결정), 이 교환 전략에서는 네트워크 통신 없이도 데이터 교환 가능
      • 브로드캐스트(Broadcast) 전략 : 모든 레코드를 연산자의 모든 병렬 태스크로 내보냄
        • 데이터를 복제하고 네트워크 연산자를 사용하므로 비용이 다소 비싼 편
      • 키 기반(Key-based) 전략 : 데이터를 키 기준으로 모아 같은 키 값을 가진 데이터는 같은 태스크에 모이도록 보장
        • 그림 2-2의 '해시태그 추출'의 출력데이터를 같은 키(해시태그)를 가진 데이터끼리 모으면 카운트 연산자 태스크는 각 해시태그의 등장 횟수 정확히 계산 가능
      • 랜덤(Random) 전략 : 각 계산 태스크의 부하를 균등하게 분산시키고자 모든 연산자 태스크로 데이터를 균등하게 분배

 

 

병렬 스트림 처리

데이터 스트림 : 무한 이벤트 순서열(unbounded sequence of events)

데이터 스트림의 이벤트는 모니터링 데이터, 센서 측정, 신용카드 거래, 기상 관측소의 관찰 기록, 온라인 사용자 상호작용, 웹 검색등을 표현 가능

 

 

지연과 처리율

  • 성능 측정할 때의 요소
  • 배치 어플리케이션
    • 보통 잡의 총 실행 시간이나 사용 중인 처리 엔진이 입력을 읽고 결과를 쓰는 데 얼마나 많은 시간을 소모하는지 측정
  • 스트리밍 애플리케이션
    • 지속적으로 실행되고 입력이 무한이므로 전체 실행시간은 중요하지 않음
    • 대신 빠른 속도로 이벤트를 처리하면서 최대한 빠르게 계산 결과 제공해야 함
      • 성능 요건 - 지연(latency)과 처리율(throughput)
    • 지연
      • 이벤트를 처리하는 데 얼마나 많은 시간이 걸리는지 나타냄
      • 기본적으로 이벤트 수신과 이벤트 처리 결과(효과)를 출력해서 볼 때까지의 경과 시간을 의미
      • 데이터 스트리밍에서 지연은 밀리초 같은 시간으로 측정. 애플리케이션에 따라 평균 지연 최대 지연, 또는 퍼센타일(percentile) 지연에 관심을 가질 수 있음
        • ex. 평균 지연 10밀리초 : 이벤트를 처리하는 데 평균 10밀리초가 걸림
        • ex. 95번째 퍼센타일 지연 값이 10밀리초 : 이벤트의 95%를 처리하는데 10밀리 초가 걸림
          • 평균값은 처리 지연의 실제 분포값을 가려 문제 숨길 수 있음
      • 짧은 지연 보장은 사기 감지(fraud detection), 시스템 알람, 네트워크 모니터링, 엄격한 서비스 수준 협약(service level agreements)과 같은 여러 스트리밍 애플리케이션에서 아주 중요
      • 짧은 지연은 스트림 처리의 핵심 특징이며, 짧은 지연 덕분에 실시간(real-time) 애플리케이션의 구현 가능
        • 아파치 플링크 같은 최신 스트림 처리기는 몇 밀리초 단위의 지연 제공 가능
        • 이벤트가 시스템에 도착하자마자 처리, 지연은 각 이벤트를 처리할 때 소모한 실제 작업 시간 반영
    • 처리율
      • 시스템의 처리량을 측정하는 메트릭. 단위 시간당 얼마나 많은 이벤트를 처리할 수 있는지 알려줌
      • 단위 시간당 처리한 이벤트 개수나 또는 연산 호출 횟수 측정
      • 처리율은 이벤트 도착 비율에 의존한다는 것을 명심해야함.(낮은 처리율 =/= 나쁜 성능)
      • 최대 처리율 : 시스템이 최대 부하에 다다랐을 때 성능의 한계
      • 배압(backpressure) : 시스템이 처리할 수 있는 비율보다 높게 데이터를 계속 받으면 버퍼링도 불가능하게 돼 데이터를 잃을 수 있는 상황
  • 지연과 처리율
    • 지연과 처리율은 독립적인 메트릭이 아님
    • 지연과 처리율에 영향을 주는 요소
      • 부하가 없다면 지연은 최적 - 처리율 증가
      • 이벤트를 처리하는 데 걸리는 시간 증가 - 처리율 감소
    • 짧은 지연과 높은 성능 가지려면 (짧은 지연이 처리율도 높일 수 있음)
      • 이벤트 처리 속도 증가 (최대 부하에서 처리율 높아짐)
      • 스트림 처리 파이프라인의 병렬화 (같은 시간에 더 많은 이벤트 처리 가능)

 

 

데이터 스트림 연산

  • 스트림 처리 엔진은 보통 인입, 변환, 출력에서 사용할 수 있는 여러 기본 연산 제공
    • 스트리밍 애플리케이션 로직을 구현할 때 데이터플로우 처리 그래프에서 이런 연산 조합해 사용 가능
  • 상태가 없는 연산
    • 어떤 내부 상태도 유지하지 않기 때문에 이벤트에 대한 처리가 과거의 다른 이벤트에 의존하지 않으며 아무런 이력도 유지하지 않음
    • 이벤트는 서로 독립적이고 도착하는 순서에 의존하지 않으므로 병렬화 쉬움
    • 장애 발생 시 단순히 마지막에 처리했던 지점부터 재시작해 처리 이어나감
  • 상태가 있는 연산
    • 이전에 받은 이벤트의 정보 유지. 새로 들어온 이벤트는 이 상태를 갱신하고, 미래의 이벤트는 이 상태를 이벤트 처리 로직에서 사용
    • 상태가 있는 스트림 처리 애플리케이션은 상태를 효과적으로 분할하고 장애가 발생할 때 안정적으로 복구해야 하므로 병렬화와 내고장성을 유지하는 것이 큰 도전 과제
      • 내고장성 : 시스템의 일부가 고장이 나도 전체에는 영향을 주지 않고, 항상 시스템의 정상 작동을 유지하는 능력
  • 데이터 인입(ingestion)과 방출(egress)
    • 스트림 처리기가 외부 시스템과 통신하는 연산
    • 데이터 인입
      • 외부 소스에서 원시(raw) 데이터를 가져와 스트림 처리에 맞는 형식으로 변환하는 연산
        • 데이터 소스(data source) : 데이터를 가져오는 로직을 구현한 연산자. TCP 소켓, 파일, 카프카 토픽, 또는 센서 데이터에서 데이터 가져올 수 있음
    • 데이터 방출
      • 데이터를 수신할 외부 시스템의 소비 형태에 맞게 데이터 형식을 변환해 내보내는 연산
        • 데이터 싱크(data sink) : 데이터 방출을 수행하는 연산자. 파일, 데이터베이스, 메시지 큐, 모니터링 서비스의 엔드포인트 등
  • 변환 연산(transformation)
    • 단일 경로(single path)연산으로, 각 이벤트 독립적으로 처리
    • 이벤트를 하나씩 소비하면서 각 이벤트 데이터에 변환 연산을 적용한 후 변환된 이벤트를 새 출력 스트림으로 내보냄
    • 변환 로직은 연산자 안이나 사용자 정의 함수로 구현해 제공 가능
      • 그림 2-4. 각 인입 이벤트를 더 어둡게 변환하는 함수를 포함하는 스트림 연산
      • 연산자는 여러 입력스트림에서 이벤트 받아 여러 출력 스트림 생성 가능
      • 연산자는 하나의 스트림을 여러 스트림으로 나누거나 여러 스트림을 하나의 스트림으로 변환하는 등 데이터플로우의 그래프 구조를 변경할 수 있음
  • 롤링 집계 연산(Rolling aggregation)
    • 합계(sum), 최솟값(min), 최댓값(max)과 같은 집계 연산으로, 이벤트가 들어올 때마다 계속해서 상태 갱신
    • 집계 연산은 상태가 있으며 새로 들어온 이벤트와 현재 상태를 결합해 집계 값을 계산
      • 집계 값을 효과적으로 계산하기 위해 결합 법칙과 교환 법칙이 성립해야 함 (성립 안할 시 모든 이벤트 스트림 이력 저장 필요)
      • 그림 2-5. 롤링 최솟값 집계 연산
        • 현재 최솟값 유지 및 인입되는 이벤트마다 최솟값을 계산해 현재 상태 갱신
      • 윈도우 연산
        • 결과를 계산할 때 일정량의 이벤트를 모아 보관하고 있어야 하는 연산 존재 (스트림 조인(join)이나 평균 함수와 같은 전체 집계 연산(holistic aggregate))
          • 무한 스트림에서 효과적으로 수행하려면 각 연산은 자신의 상태에 보관 가능한 수준으로 데이터양 제한 필요
        • 실제 값(집계와 같은 값)을 구하는 것 외에도 윈도우를 이용하면 스트림에서 의미 있는 질의 할 수 있음
          • 가장 최근의 데이터만 관심있거나 단일 집계로 줄이면 시간에 따라 변하는 데이터의 다양한 정보 잃을 수 있음
        • 무한 이벤트 스트림에서 버킷(bucket)이라 부르는 이벤트의 유한 집합을 지속적으로 생성하고, 이 유한집합에 어떤 연산을 수행할 수 있게 해줌
        • 윈도우 정책
          • 언제 새 버킷을 생성하고, 어떤 이벤트를 어떤 버킷에 할당하며, 언제 버킷의 내용을 평가할 것인지 결정.
            • 윈도우 내용 평가 시점은 트리거(trigger)조건을 기반으로 결정. 트리거 조건 충족 시 버킷의 내용을 평가 함수로 전달해 각 버킷 이벤트에 연산 로직 적용
          • 시간(ex. 마지막 5초 안에 받은 이벤트)이나 개수(ex.마지막 100개 이벤트), 또는 데이터의 속성을 기준으로 삼기 가능
        • 일반적인 윈도우 시멘틱(semantic) 종류
          • 텀블링 윈도우(Tumbling Window)
            • 고정 길이에 서로 겹치지 않는(중첩되지 않는) 버킷으로 이벤트 할당.
            • 이벤트가 윈도우 경계를 넘으면 처리하고자 버킷의 모든 이벤트를 평가 함수로 보냄
            • 개수 기반(count-based) 텀블링 윈도우
              • 윈도우가 트리거링 되기 전에 얼마나 많은 이벤트를 모아야하는지를 정의
              • 그림 2-6. 개수 기반 텀블링 윈도우
            • 시간 기반(time-based) 텀블링 윈도우
              • 이벤트를 어떤 버킷으로 버퍼링할지를 시간 간격으로 정의
              • 그림 2-7. 시간 기반 텀블링 윈도우
            • 슬라이딩 윈도우(Sliding Window)
              • 서로 겹치는(중첩되는) 고정 길이의 버킷으로 이벤트 할당. 두 버킷에 포함되는 이벤트도 있을 수 있음
              • 길이와 슬라이드(slide)로 정의. 슬라이드 값은 새로운 버킷이 생성될 때까지의 간격 정의
              • 그림 2-8. 네 개의 이벤트 길이와 세 개의 이벤트 슬라이드로 정의한 개수 기반 슬라이딩 윈도우
            • 세션 윈도우(Session Window)
              • 텀블링이나 슬라이딩 윈도우로 적용할 수 없는 현실 세계 시나리오에서 유용
                • ex. 온라인 사용자 행동 분석 애플리케이션 - 동일 기간에 발생한 사용자 활동이나 세션 대상으로 이벤트 함께 모음
              • 세션이 종료됐다고 판단할 수있는 비활동 시간을 세션 격차(session gap)라는 값으로 정의해서 이벤트들을 세션으로 그룹화
              • 그림 2-9. 세션 윈도우
            • 병렬 텀블링 윈도우
              • 스트림을 여러 논리적 스트림으로 분할해서 병렬 윈도우(parallel window)로 정의 가능
                • ex. 서로 다른 센서 장비에서 데이터를 받을 때 스트림을 센서 식별자로 그룹핑해서 윈도우 계산 적용
              • 그림 2-10. 길이가 2인 개수 기반 병렬 텀블링 윈도우
            • 스트림 처리의 두 가지 핵심 개념인 시간과 상태 관리에 밀접한 연관 있음
              • 윈도우 연산의 진정한 가치는 빠른 분석 결과 이상
            • 네트워크 통신 채널 같은 현실 세계 시스템은 완벽하지 않음, 스트림 데이터는 지연되거나 순서가 바뀌어 도착 가능
              • 이런 상황에서 스트리밍 처리가 정확하고 결정적인 결과를 어떻게 생성하는지 반드시 이해해야 함
              • 이벤트 발생순으로 이벤트를 처리하는 애플리케이션은 이벤트 발생순으로 이력을 따라가며 이벤트 처리해야 함
                • 오프라인 분석이나 이벤트 시간 여행 분석(event time travel analysis) 가능해짐
                  • 장애 대비 상태 보호 필요 - 모든 윈도우 종류는 결과 생성 전 데이터 버퍼링 필요
            • 스트리밍 애플리케이션은 상태 관리 꼭 필요
              • 장애 상황에서 상태를 안정적으로 복구해 어떤 일이 벌어지더라도 스트리밍 애플리케이션이 정확한 결과를 낼 수 있다는 확신 필요

 

시간 시멘틱

  • 스트리밍 처리에서 1분
    • 매분 어떤 결과를 지속적으로 계산하는 스트리밍 애플리케이션을 가정해보자
      • 이 스트리밍 애플리케이션 문맥에서 1분이 의미하는 것은 실제 무엇일까?
      • 지하철에서 온라인 게임 플레이 시 네트워크가 끊겼다 안끊겼다 하는 상황 가정
      • 그림 2-11. 지하철에서 플레이한 온라인 모바일 게임 이벤트를 받는 애플리케이션은 네트워크가 끊길 때 시간 차이를 경험하게 됨. 그러나 이벤트는 핸드폰에 버퍼링돼 있고 네트워크가 다시 연결되면 애플리케이션으로 버퍼링한 이벤트를 보낸다.
    • 이벤트를 받은 시간이 아닌, 이벤트가 실제 발생한 시간이 연산자 시멘틱에 어떤 영향을 미치는지 보여주는 단순 시나리오
      • 1분 안의 이벤트양을 정의하는 것은 처리 시간이 아닌 데이터 자체의 실제 시간
      • 처리 시간(processing time)이나 이벤트 시간(event time)을 이용해 연산 수행
    • 처리 시간
      • 스트림 처리 연산자가 실행 중인 장비의 시계에서 측정한 로컬 시간
        • 로컬 시간을 기준으로 일정 시간 동안 윈도우 연산자에 도달한 모든 이벤트는 처리 시간 윈도우(processing-time window)안으로 들어감
        • 그림 2-12. 앨리스 핸드폰 네트워크가 끊긴 후에도 처리 시간 윈도우의 시간은 계속 흘러감
    • 이벤트 시간
      • 이벤트가 실제 발생한 시간. 이벤트 내용 안에 포함된 타임스탬프(timestamp)를 기반으로 함
        • 타임스탬프는 보통 스트리밍 처리 파이프라인에 도착하기 전에(ex. 이벤트 생성 시간) 생성돼 이벤트 데이터 안에 존재
        • 이벤트 시간 윈도우는 이벤트의 일부가 지연되더라도 발생했던 일을 제대로 반영
        • 그림 2-13. 이벤트 시간은 윈도우 안에 이벤트를 정확히 넣는다. 이 윈도우는 발생한 이벤트를 제대로 반영
      • 처리 결과를 처리 속도와 완전히 분리. 연산의 예측이 가능하고 결과는 결정적
      • 스트림을 얼마나 빨리 처리하고 이벤트가 연산자에 언제 도착하든 간에 이벤트 시간 윈도우는 항상 동일한 결과 생성
      • 데이터의 순서가 바뀌더라도 결과의 정확성 보장
      • 재생(replay)가능한 스트림 로그와 결합하면 시간이 항상 동일한 것을 보장하므로(타임스탬프 결정성) 과거 이벤트도 빠르게 되돌려 볼 수 있음
        • 과거의 이력 데이터도 마치 실제시간에 발생한 것처럼 분석 가능
          • 현재 시간까지 빠르게 따라잡으면 완전히 동일한 프로그램 로직으로 실시간 애플리케이션 계속 이어나갈 수 있음
      • 워터마크
        • 이벤트가 더 지연되지 않고 도착할 것이라고 확신할 수 있는 시점을 가리키는 메트릭으로, 전체 진행 시간을 나타냄
        • 스트리밍 시스템에 현재 이벤트 시간을 알려주는 논리적인 시계 제공
        • 순서가 바뀐 이벤트를 처리하는 이벤트 윈도우와 연산자 모두에게 꼭 필요함
        • 연산자가 워터마크를 수신하면 일정 기간동안 발생한 모든 이벤트의 시간이 감지됐다는 것을 알게되고 수신한 이벤트를 대상으로 계산을 시작하거나 이벤트 정리
        • 결과의 신뢰성과 지연사이의 균형을 맞출 수 있는 설정 제공
          • 너무 빠듯하게 발생시키면 짧은 지연 보장 가능, 낮은 신뢰성
            • 워터마크를 먼저 도착한 이벤트의 시간에 가깝게 맞춘다는 것을 의미.
            • 워터마크 이후 늦게 도착한 이벤트를 처리하는 별도 코드 제공해야 함
          • 너무 느슨하게 생성 시 높은 신뢰성, 불필요한 처리 지연
            • 첫 번째 이벤트의 시간보다 늦게 워터마크를 발생시켜 늦게 도착하는 이벤트도 가능한 많이 같은 윈도우에 포함시킴
        • 워터마크를 사용자가 정의하든 자동으로 생성하든 분산 시스템에서 뒤처진 작업이 존재하는 한 전체 진행 상황을 완전하게 추적하는 것 쉽지 않음
          • 워터마크보다 늦게 도착한 이벤트 처리 방법
            • 애플리케이션의 요구 사항에 따라 워터마크보다 늦게 도착한 이벤트 무시 가능
            • 이전 결과를 보정하는 데이터로 사용 가능
      • 처리 시간과 이벤트 시간
        • 이벤트 시간으로 모든 문제를 해결할 수 있는데 왜 처리 시간도 고민해야 할까?
        • 처리 시간이 쓸만할 때
          • 정확성보다 속도가 더 중요한 애플리케이션에서는 처리 시간이 유용
            • 늦게 도착한 이벤트나 이벤트 순서 고려하지 않을 때 윈도우는 단순히 이벤트를 버퍼링, 지정 윈도우에 이벤트 도착하는 즉시 계산 동작
          • 정확도가 크게 중요하지 않은 실시간 보고서를 주기적으로 생성해야 할 때
            • 이벤트가 도착하는 대로 집계해서 보여주는 실시간 모니터링 대시보드 애플리케이션
          • 처리 시간 윈도우도 스트림 자체의 특성을 충분히 표현 가능
            • 정전 감지하고자 스트림 애플리케이션이 스트림에서 초당 얼마나 많은 이벤트 발생하는지 관찰 가능
        • 처리 시간은 짧은 지연을 제공하지만 결과는 처리 속도에 따라 다르고 결정적이지 않음
          • 이벤트 시간은 결정적 결과를 보장하고, 늦게 도착하거나 순서가 바뀐 이벤트도 처리할 수 있게 해줌

 

 

상태와 일관성 모델

  • 상태(state) : 데이터 처리 어디에나 존재. 거의 모든 계산에서 필수.
  • 함수는 일정 기간이나 일정 개수의 이벤트를 대상으로 상태(ex. 집계, 패턴 감지)를 누적해 결과 생성
  • 상태가 있는 연산자는 수신한 이벤트와 내부 상태를 사용해 연산 결과를 생성
    • ex. 롤링 집계 연산
      • 이 연산자는 내부 상태로 현재까지 합계 값을 보관하고 새로운 이벤트를 받을 때마다 이 값 갱신
    • ex. '높은 온도' 이벤트 감지 후 '연기' 이벤트가 10분 안에 발생할 것을 감지할 때 알람 보내는 연산자 가정
      • '연기' 이벤트가 도착하거나 10분이 지날 때까지 '높은 온도' 이벤트를 내부 상태에 보관해야 함
  • 상태의 중요성은 배치 처리 시스템으로 무한 데이터셋을 분석하는 것과 비교하면 더 명확해짐
    • 배치 처리 시스템
      • 작은 배치를 대상으로 잡(job)을 반복 스케줄링. 어떤 잡이 종료되면 결과를 영구적인 저장소로 전송하고 모든 연산자의 상태 사라짐
      • 다음 배치 처리에 스케줄돼 있는 잡은 이전 잡의 상태 접근 불가
        • 데이터베이스 같은 외부 시스템에 상태 관리를 위임해 문제 해결
    • 스트림 잡에서 모든 이벤트는 상태에 접근 가능, 이 상태를 프로그래밍 모델의 일급 시민(first-class citizen)으로 노출 가능
      • 추가 지연 시간이 발생할 수는 있지만 스트림 상태를 안전하게 관리하기 위해 외부 시스템 사용 가능
  • 스트림 연산자는 무한 데이터를 처리하므로 내부 상태가 무한으로 커지지 않도록 조심해야 함
    • 연산자는 지금까지 받은 이벤트들을 요약 정보나 개요(synopsis)같은 형태로 관리해 상태의 크기를 제한하는 것이 일반적
      • 카운트, 합계, 현재까지 받은 이벤트들에 대한 샘플, 윈도우 버퍼, 사용자 정의 데이터 구조를 사용
  • 상태가 있는 연산자를 사용하기 위한 극복 대상 도전 과제
    • 상태 관리(State management)
      • 시스템은 상태 관리를 효율적으로 해야 하고 동시에 상태를 갱신할 때 상태를 보호
    • 상태 분할(State partitioning)
      • 병렬로 처리할 때 처리 결과가 상태와 입력 이벤트 모두에 의존함으로 복잡해짐
        • 키(key)로 상태 분할 가능, 각 파티션 별로 상태 관리 가능
          • ex. 센서 측정하고 이 측정 값을 이벤트로 저장하는 스트림 처리 시 분할 상태를 사용해 센서별 독립적인 상태 유지 가능
    • 상태 복구(State recovery)
      • 상태를 복구하고 장애 시에도 정확한 결과를 내보내야 함

 

태스크 실패

  • 스트리밍 잡에서 연산자 상태는 매우 중요하고 장애에 대비해 보호해야 함
    • 장애 발생 시 상태 잃어버리면 복구 후 결과 부정확
    • 스트리밍 잡은 오랜 시간 동안 실행되므로 상태는 며칠이나 몇달동안 수집한 것일 수 있음
      • 장애로 유실한 상태 재생산하려 과거 입력을 모두 재처리하는 것은 매우 비용이 많이 들면서 많은 시간 소모
  • 실재 환경에서 병렬 태스크를 수백 개 실행하는 것이 일반적이며 각 태스크는 언제나 실패할 수 있음
  • 태스크 실패
    • 태스크란 입력 스트림의 각 이벤트를 대상으로 아래의 절차들을 수행하는 하나의 처리 단계
      1. 이벤트를 수신해 로컬 버퍼에 저장
      2. 경우에 따라 내부 상태 갱신
      3. 출력 레코드 생산
    • 실패는 위과정 어디에서나 발생 가능하며, 시스템은 장애 시나리오마다 어떻게 동작할지를 명확하게 정의해야 함
    • 배치 처리 시나리오에서는 배치 잡을 처음부터 다시 시작할 수 있기 때문에 어떤 이벤트도 유실되지 않고, 상태도 처음부터 다시 완전하게 만들 수 있음
    • 스트리밍 시스템은 실패가 발생할 때 결과를 보장할 수 있는 여러 방식 정의

 

결과 보장

  • 스트림 처리기 내부 상태의 일관성을 의미
    • 결과 보장의 관심사는 실패 복구 후 애플리케이션 코드가 바라보는 상태 값
    • 애플리케이션 상태 일관성 보장은 출력의 일관성 보장과 같지 않음
      • 결과를 한번 싱크로 보내면 싱크 시스템이 트랜잭션을 지원하지 않는 이상 결과의 정확성을 보장하기 어려움
  • 최대 한번(at-most-once)
    • 각 이벤트를 최대 한번 처리하는 것을 보장하는 낮은 수준의 보장 방법
      • 이벤트는 날아가고 결과의 정확성 보장을 위해 아무것도 하는 것이 없음
    • 무보장(no guarantee)이라고도 함
    • 대략적인 결과와 지연 시간 최소화에만 관심이 있다면 좋은 선택
  • 최소 한 번(at-least-once)
    • 모든 이벤트를 처리하지만 그중 일부는 한 번 이상 처리할 수 있음
    • 애플리케이션이 결과의 완결만 중요시한다면 중복 처리는 수용 가능한 조건
    • 결과의 정확성 보장하려면 소스나 어떤 버퍼에서 이벤트를 재생할 방법을 갖고 있어야 함
      • 지속성 이벤트 로그는 모든 이벤트를 신뢰할 수 있는 저장소에 저장하므로 태스크가 실패하더라도 이벤트 재생 가능
        • 파이프라인에 있는 태스크들이 이벤트를 모두 처리했다는 것을 이벤트 로그가 인식할 때 까지 모든 이벤트를 버퍼에 저장
        • 이벤트 로그는 이벤트가 모두 처리됐다고 인식하는 시점이 되면 해당 이벤트를 이벤트 로그에서 삭제 가능
  • 정확히 한번(exactly-once)
    • 단지 이벤트 유실이 없다는 것뿐만 아니라 이벤트마다 정확히 한 번씩만 내부 상태를 갱신
      • 마치 실패가 한 번도 없었던 것처럼 애플리케이션이 정확한 결과를 제공하리란 것 의미
    • 가장 엄격한 보장 방식이고 구현이 쉽지 않음
    • 최소 한 번 보장이 필요하고, 따라서 데이터 재생 기능 필수
    • 스트림 처리기는 내부 상태 일관성 보장해야 함
      • 장애 복구 후 어떤 이벤트가 상태에 이미 반영됐는지 알아야 한다는 것 의미
        • 트랜잭션 업데이트 방식 사용 가능하나 부가적인 성능 저하 발생 가능
        • 플링크는 경량 스냅샷(lightweight snapshot) 메커니즘을 사용해 정확히 한 번 결과 보장
  • 단대단 정확히 한 번
    • 단대단(end-to-end) 보장은 전체 데이터 처리 파이프라인에 걸친 결과의 정확성 의미
    • 각 컴포넌트가 각자 상태를 보장하는 방법을 완벽히 제공하더라도 전체 파이프라인의 단대장 보장 제공 쉽지 않음
    • 가끔 약한 상태 보장 방식으로 강한 상태 보장 얻을 수 있음
      • ex. 스트림 처리가 최댓값이나 최솟값 같은 멱등적(idempotent)연산을 수행할 때
        • 최소 한 번(at-least-once) 보장으로 정확히 한 번(exactly-once)보장 얻을 수있음
        • 멱등적 - 어떤 값을 여러 번 반복 연산해도 결과 같음

아파치 플링크(Apach Flink) : 분산 스트림 처리 소프트웨어.

  • 상태가 있는 스트림 처리(Stateful Stream Processing)
    • 실시간 데이터 처리를 위하여 이전에 분석된 데이터의 결과 사용. 이벤트를 처리하고 그 결과를 저장할 상태 저장소가 필요.
  • 애플리케이션을 구현하는데 필요한 직관적이고 표현력이 풍부한 API 제공

 

전통적인 데이터 인프라 아키텍처

트랜잭션 처리

  • 데이터 처리(애플리케이션)와 데이터 저장소(트랜잭션 데이터베이스 시스템)라는 두 계층 가지고 있는 아키텍처
  • 원격 데이터베이스 시스템에 데이터를 저장하는 트랜잭션 애플리케이션의 전형적인 설계
    • 그림 1-1.
  • 애플리케이션: 보통 외부 서비스나 사용자와 상호작용하면서 발생하는 주문서, 이메일이나 웹 사이트 클릭과 같은 이벤트 지속적 처리
    • 애플리케이션을 개선하거나 규모를 확장할 때 문제 발생 가능 - 여러 애플리케이션이 동일한 데이터 모델을 대상으로 작업 or 동일한 인프라를 공유해서 테이블 스키마 변경이나 데이터베이스 시스템 확장 시 문제 발생 가능
  • 마이크로서비스 설계 패턴 : 작고 자립적이며 독립적인 설계 방식. 잘 정의한 인터페이스로 서로 통신하게 강제하므로 마이크로서비스 간의 결합 완전히 분리.
    • 보통 마이크로서비스에 필요한 모든 소프트웨어와 서비스를 하나로 묶어 독립 컨테이너에 배포.
    • 그림 1-2. 마이크로서비스 아키텍처

 

 

 

 

 

분석 처리

  • 여러 트랜잭션 데이터베이스 시스템의 데이터 분석
  • 트랜잭션 데이터 대부분 서로 다른 데이터베이스 시스템에 분산돼 있으므로, 이를 통합 분석하면 더 가치있는 정보 얻을 수 있음
  • 분석 질의 시 분석 질의 전용 데이터 저장소인 데이터 웨어하우스에 데이터를 복제한 후 실행
    • ETL(Extract-추출, Transformation-변환, Load-적재)
      • 데이터를 트랜잭션 데이터베이스에서 추출하고 데이터 유효성 검사와 정규화, 인코딩, 중복 제거, 스키마 변경, 많이 사용하는 데이터 형식으로 변환 수행 등을 한 후 변환한 데이터를 분석 데이터베이스에 적재.
      • 데이터 웨어하우스와 데이터를 동기화하기 위해 ETL 처리 주기적 실행 필요
    • 데이터 웨어하우스에서 실행하는 질의 분류
      • 기업의 수익, 고객 유입 증가나 제품 출하량과 같은 비즈니스와 관련 있는 데이터 주기적으로 보고하는 질의
      • 애드혹(Ad-hoc)질의 : 특정 문의에 응답하거나 비즈니스와 관련해서 민첩한 결정이 필요할 때 사용
      • 그림 1-3. 데이터 분석을 위한 전통적인 데이터 웨어하우스 아키텍처
  • 아파치 하둡 생태계
    • 대용량의 데이터를 하둡 분산 파일 시스템(HDFS, Hadoop’s Distributed File System)이나 S3, 또는 아파치 HBase와 같은 벌크 저장소에 저장.
      • 벌크 저장소 : 저비용, 고용량의 저장소 제공.

 

 

 

상태가 있는 데이터 스트림 처리

  • 모든 데이터는 이벤트 스트림이 지속적으로 생성한 데이터라 가정할 수 있음.
  • 상태가 있는 스트림 처리는 무한 이벤트 스트림을 처리하는 애플리케이션 설계 패턴이며 여러 분야에 응용 가능.
    • 이벤트 수신 후 상태에서 데이터 읽거나 상태에 데이터 쓰는 연산 수행. 레코드, 중간 결과, 메타 데이터 등
    • 아파치 플링크 :
      • 애플리케이션 상태를 로컬 메모리나 임베디드 데이터베이스에 저장
      • 로컬의 상태를 원격의 신뢰성 있는 저장소에 애플리케이션 상태의 체크포인트(Checkpoint)를 주기적으로 기록
    • 그림 1-4. 상태가 있는 스트림 애플리케이션
  • 상태가 있는 스트림처리 애플리케이션은 주로 이벤트 로그에서 이벤트 가져옴.
    • 이벤트 로그: 이벤트 스트림 저장하고 분배
    • 이벤트 생산자(Producer)는 추가 전용(Append-only)로그에 이벤트 씀 - 이벤트 읽을 때 순서가 변경되지 않음(결정적)을 의미
    • 동일한 소비자(Consumer)나 다른 소비자가 이벤트 로그에 저장한 이벤트를 여러 번 읽을 수 있음
    • 로그의 추가 전용 특성 때문에 모든 소비자는 정확히 같은 순서의 이벤트 받아 볼 수 있음.
    • 이벤트 로그 시스템 : 아파치 카프카(Apache Kafka), 클라우드 컴퓨팅 회사가 제공하는 이벤트 로그 서비스.
  • 플링크로 실행하는 상태가 있는 스트리밍 애플리케이션과 이벤트 로그의 결합
    • 이벤트 로그는 들어오는 이벤트를 저장하고 항상 같은 순서로 애플리케이션에 보냄
    • 장애 발생 시 플링크는 직전 체크포인트에서 애플리케이션 상태 복구 및 이벤트 로그의 읽기 위치를 이전 위치로 재설정해 애플리케이션의 상태 원상 복구
    • 애플리케이션은 이벤트 스트림의 끝에 도달할 때까지 이벤트 로그를 재생(또는 빨리 감기)

 

이벤트 주도 애플리케이션(Event-Driven Application)

  • 이벤트 스트림을 입력으로 받아 특정 비즈니스 로직을 처리하는 ‘상태가 있는 스트리밍 애플리케이션’
    • 실시간 추천
    • 패턴 감지나 복합 이벤트 처리 (CEP, Complex Event Processing)
    • 이상 탐지
  • REST 호출 대신 이벤트 로그를 통해 서로 통신하고, 애플리케이션 상태는 로컬에서 관리
  • 그림 1-5. 이벤트 주도 스트리밍 애플리케이션
    • 한 애플리케이션이 이벤트 로그에 결과 출력하면 다른 애플리케이션은 이를 소비
    • 이벤트 로그는 이벤트 전송과 수신을 분리하고 비동기, 논블록킹(non-blocking)으로 이벤트를 전송
    • 각 애플리케이션은 상태가 있을 수 있으며 이를 외부 데이터베이스가 아닌 로컬에서 자신의 상태를 관리
    • 애플리케이션의 동작과 수평 확장은 각 애플리케이션이 독립적으로 수행
  • 이벤트 주도 애플리케이션과 트랜잭션 애플리케이션, 마이크로서비스와의 차이점
    • 로컬 상태 접근 - 원격 데이터 저장소에서 읽고 쓰는 것보다 훨씬 빠른 성능
    • 수평 확장과 장애 극복은 스트림 처리기가 관리
    • 이벤트 로그를 입력 소스로 사용함으로써 애플리케이션 입력 데이터를 안정적으로 저장
    • 이벤트의 순서를 보장해서 이벤트 여러번 처리 가능
    • 플링크는 애플리케이션의 상태를 이전 세이브포인트(Savepoint)로 설정해 상태를 잃지 않고 애플리케이션을 업그레이드하거나 수평 확장할 수 있게 함
  • 이벤트 주도 애플리케이션을 실행하려면 스트림 처리기의 기능이 굉장히 높은 수준에 있어야 함.
    • 비즈니스 로직의 구현과 실행은 스트림 처리기의 API 표현력과 상태 관리의 품질, 이벤트 시간(Event-Time)지원 등이 결정.
  • 정확히 한번(Exactly—once) 수준의 상태 일관성과 애플리케이션 수평 확장 지원

아파치 플링크는 위의 기능 모두 포함.

 

 

 

 

 

데이터 파이프라인

  • 데이터 파이프라인(Data Pipeline) : 짧은 지연으로 데이터를 가져와 변환, 삽입하는 종류의 애플리케이션
  • 데이터 접근 성능을 향상하고자 동일 데이터를 여러 데이터 저장 시스템에 저장하는 것은 일반적
    • 이런 데이터 복제의 필요성 때문에 데이터를 각 데이터 저장소에서 반드시 동기화해야 함
  • 데이터 동기화 방법
    • 주기적 ETL 작업 수행 - 짧은 지연 시간을 필요로 하는 최근 서비스의 요구 사항 만족시키지 못함
    • 이벤트 로그 사용해 데이터 변경 내용 분산

 

스트리밍 분석

  • 분석 ETL 작업은 주기적으로 데이터 저장소에 데이터를 적재한 후 애드혹이나 예약한 질의를 이용해 처리 - 배치 처리
    • 분석 파이프라인에 상당히 긴 지연 시간 발생시키는 원인
    • 데이터 저장소에 넣을 때 데이터 파이프라인 애플리케이션을 실행하면 어느 정도의 지연 시간은 줄일 수 있으나 실시간 데이터 수집 및 즉시 반응해야 할 때도 지연 발생
  • 스트리밍 애플리케이션의 장점
    • 지속적으로 이벤트 스트림을 가져와 짧은 지연 시간으로 최신 이벤트를 처리한 후 결과 갱신. 짧은 시간 안에 이벤트를 분석 결과에 반영 가능
      • 일반적으로, 스트림 애플리케이션은 업데이트 성능이 좋은 데이터베이스나 키-값 저장소와 같은 외부 데이터 저장소에 처리 결과 저장
      • 1-6. 스트리밍 분석 애플리케이션
  • 스트림 처리기가 지속적으로 이벤트를 가져오고, 상태를 관리하며, 연산한 결과를 갱신하는 모든 절차를 관리
    • 전통적 분석 파이프라인의 경우 ETL처리, 저장시스템, 여러 개의 개별 컴포넌트 가지고 있음
    • 정확히 한 번(exactly-once)의 일관성이 보장되는 애플리케이션 상태를 이용해 장애에서 복구 가능
    • 애플리케이션 연산에 필요한 자원 조절 가능

 

오픈소스 스트리밍 처리의 진화

최근 오픈소스 스트림 처리의 기술적 성숙은 스트리밍 처리 기술의 대규모 도입 이끌어냄

  1. 오픈소스 스트림 처리 소프트웨어는 모든 사람이 무료로 평가해보고 사용 가능
  2. 오픈소스 커뮤니티의 노력으로 확장 가능한 스트림 처리 기술이 빠른 속도로 성숙

 

스트림 처리의 역사

  • 1세대(2011) : 밀리초 단위의 지연 시간으로 이벤트를 처리하는 데 집중했으며, 장애 시 유실 허용
    • 저수준의 API, 스트림 처리 결과가 시간과 이벤트의 도착 순서에 좌우됨
    • 장애 시 이벤트를 유실하지 않더라도 이벤트를 한 번 이상 처리 가능
    • 짧은 지연 시간 > 정확한 결과
    • 람다(Lambda) 아키텍처 : 배치 분석 아키텍처 결과의 늦은 지연 시간을 보완하기 위함
      • 그림 1-7. 람다 아키텍처
        • 주기적으로 배치 처리를 수행하는 전통적인 아키텍처에 짧은 지연시간을 제공하는 스트림 처리 기반의 스피드 계층(Speed Layer)을 추가한 변형
          • 데이터가 도착하면 스트림 처리기와 배치 저장소로 데이터 전송
          • 스트림 처리기는 근실시간으로 연산을 수행해 대략적 결과 도출, 스피드 테이블(Speed Table)에 저장
          • 배치 처리기: 주기적으로 배치 저장소에 있는 데이터 처리, 정확한 결과를 배치 테이블(Batch Table)에 쓰고, 관련 있는 스피트 테이블의 부정확한 결과는 버림
          • 스피트 테이블의 대략적인 결과와 배치 테이블의 정확한 결과를 병합해 소비
        • 단점:
          • 서로 다른 이벤트 처리 시스템이 각각의 API를 이용해 의미적으로 동일한 애플리케이션을 두 벌 구현 필요
          • 스트림 처리기가 생성한 결과는 대략적인 결과 뿐
          • 람다 아키텍처를 설치하고 유지 보수하기 어려움
  • 2세대(2013년) : 몇 밀리초에서 몇 초 단위의 처리 지연 시간 보장, 처리 결과는 여전히 시간과 이벤트 도착 순서에 달림
    • 이전 보다 향상된 장애 복구 기능 지원
    • 실패 발생하더라도 각 코드가 결과에 정확히 한번만 반영 보장
    • 고수준 API로 진화
  • 3세대(2015년): 시간과 이벤트의 도착 순서에 따라 결과 달라지는 문제 다룸
    • 정확히 한 번 장애 복구와 결합한 시스템은 일관성 있고 정확한 결과를 만들어내는 최초의 오픈 소스 스트림 처리기
    • 실시간 데이터를 처리해 결과 생성하기도 하지만, 과거 데이터도 '라이브'데이터와 같은 방식으로 처리 가능
    • 짧은 지연 시간과 처리율 간의 상충 문제 제거

 

 

플링크 빠르게 살펴보기

  • 아파치 플링크 : 강력한 기능으로 무장한 3세대 분산 스트림 처리기.
  • 대규모 환경에서 높은 처리율과 짧은 지연으로 정확한 스트림 처리 결과 제공
    • 이벤트 시간과 처리 시간 시멘틱
      • 이벤트 시간 시멘틱은 순서가 바뀐 이벤트가 들어오더라도 일관성 있고 정확한 결과 제공
    • 상태 일관성 보장
      • 초당 수백만 이벤트 처리하면서 밀리초 단위의 지연 시간 보장. 플링크 애플리케이션을 수 천대의 클러스터 환경으로 확장 가능
    • 표현력과 사용 편리성에 따라 선택 가능한 계층적 API : DataStream API, 처리함수. 관계형 API(SQL, LINQ스타일의 테이블 API)
    • 아파치 카프카, 아파치 카산드라, 일래스틱 서치, HDFS, S3 등 저장 시스템에 연결하는 여러 종류의 커넥터 제공
    • 쿠버네티스, YARN, 아파치 메소스와의 강력한 통합, 빠른 장애 복구, 동적인 규모 확장이 가능한 고가용성(단일 실패 지점 없음) 덕분에 매우 짧은 타임으로 스트리밍 애플리케이션을 중단없이 24/7로 실행 가능
    • 애플리케이션 상태를 잃어버리지 않고 다른 플링크 클러스터로 잡 코드 업그레이드하거나 잡을 마이그레이션 할 수 있는 기능 제공
    • 사전에 문제 인지, 사용자 정의가 가능한 시스템과 애플리케이션 매트릭 수집
    • 최신의 완전한 배치 처리기
    • 사용하기 쉬운 API
    • 임베디드 실행 모드 : 애플리케이션과 전체 플링크 시스템을 하나의 JVM 프로세스에서 동작하게 해줌
      • IDE에서 플링크 잡 실행, 디버깅 가능
    •  
  • 검색 시 동의어가 사용되는 이유 및 방법
  • 아파치 루씬
  • 순방향 신경망의 기초
  • word2vec 알고리즘 사용
  • word2vec 사용해 동의어 생성

동의어(synonyms): 정보 검색 시 쿼리에 따른 관련 결과 개수 늘리는데 사용하는 일반적인 기법

 

2.1 동의어 확장

동의어 확장(synonym expansion): 같은 정보 여러 가지 방법으로 표현할 수 있도록 하는 기술

 

2.1.1 왜 동의어인가?

동의어(synonyms): 철자와 발음은 다르지만 의미가 같거나 아주 비슷한 단어 (ex. aircraft(항공기)와 airplane(비행기)는 모두 'plane'이라는 단어의 동의어)

  • 적절한 쿼리가 일치할 확률을 높임 -> 너무 적거나 아무런 결과도 나오지 않게 하는 쿼리 수 줄어듦
  • 재현율 개선(recall) - 관련성 높음
  • 색인화 시 동의어 확장하면 색인화 속도가 느려지고 색인디 더 커지지만 검색 속도는 빨라짐
    • 크기와 부하가 증가함에 따라 시스템의 성능에 현저한 영향 미침

 

2.1.2 어휘 기반 동의어 일치

 

ex. music is my aeroplane

  1. 토크나이저가 토큰 생성(화이트 스페이스 기준) ('music', 'is', 'my', 'aeroplane')
  2. 토큰 필터 사용해 수신된 각 토큰의 동의어 어휘를 살펴보고 키워드 있는지 확인
    • 용어 문서(위치)
      aeroplane 1(12, 17)
      aircraft 1(12, 17)
      airplane 1(12, 17)
      is 1(6, 8)
      music 1(0. 5)
      my 1(9, 11)
      plane 1(12, 17)
      • 특정 문서에서 해당 용어가 출현하는 위치에 대한 정보 기록
      • 'plane', 'airplane', 'aircraft'용어가 원래 용어인 'aeroplane'에 첨부된 정보와 동일한 위치로 색인 추가됨
      • 용어의 위치(position)를 역색인에 기록  - music is my aeroplane/aircraft/airplane/plane
        • music is my aeroplane
        • music is my aircraft
        • music is my airplane
        • music is my plane
          • 네 가지 다른 형태(form). 이 중 하나라도 일치하면 오직 하나의 문서만을 검색 엔진이 반환

 

아파치 루씬: 자바로 작성된 오픈 소스 검색 라이브러리

  •  Document(문서): 색인화하고 검색할 수 있는 주요 실체. 사용 사례에 따라 페이지, 책, 단락 이미지 등
    • 다른 부분을 파악하는 데 사용할 수 있는 다수의 Field들로 구성(페이지 제목, 페이지 내용 등)
      • 필드별 텍스트 분석 파이프라인 구성 가능
      • 용어 위치 또는 각 용어가 참조하는 원본 텍스트의 값을 게시 목록에 저장할지 등의 색인화 옵션 구성 가능
  •  Directory 통해 접근- 역색인이 유지되는 파일 목록 (역색인 저장)
  • IndexReader: 검색 엔진의 대상 경로에서 디렉토리 열기
  • IndexSearcher: 검색 및 결과 수집
  • Analyzer: 텍스트 분석 작업 수행하는 API. Tokenizer 및 TokenFilter 컴포넌트로 구성 가능
  • IndexWriter: IndexWriterConfig에 따라 역색인을 디렉토리의 디스크에 기록

 

동의어 확장을 통해 루씬 색인 설정

  1. 색인 시간 및 찾기 시간에 텍스트 분석에 사용할 알고리즘 정의
    • 모두 동일한 토크나이저 사용하는 것이 대체로 더 좋으므로 텍스트는 동일한 알고리즘에 따라 분할
  2. 설정
    • 화이트스페이스 토크나이저(whitespace tokenizer, 화이트스페이스 문자 마주쳤을 때 토큰 분할) 토크나이저 사용하는 찾기 시간 Analyzer
    • 화이트스페이스 토크나이저 및 동의어 필터를 사용하는 색인 시간 Analyzer
      • 쿼리 시간과 색인 시간 모두에 동의어 확장이 필요하지 않음

검색 엔진에서 대부분의 경우 가벼운 문서 구조를 유지하는 것이 좋음

  • 각 속성(author, title, year, album, text)에 대한 필드 정의 가능
  • 서로 다른 부분에 다른 Analyzer 사용해 보고, 데이터의 말뭉치에 대한 최적의 조합 찾기 전 여러번 변경이 일반적
  • 시간이 지남에 따라 조정 필요

 

동의어 파일 작성 - 파일 변경되어도 코드 변경할 필요 없이 그대로 유지 가능 및 언제든 필요할 때 파일 갱신 가능

  • WordNet프로젝트: 프린스턴 대학교의 영어 어휘 데이터페이스. 대규모 동의어 어휘집 이용 가능
    • 모든 언어에 사용 불가
    • 외연(denotation, 즉 외적 형식 또는 겉으로 드러난 의미)을 기반으로 하였기 때문에 단어가 문맥에 따라 정의되는 내포(connotation, 즉 내적 의미 및 함축된 의미)가 고려되지 않음 -> word2Vec 유용

 

2.2 맥락의 중요성

동의어 매핑(mapping, 즉 대응)의 한계: 정적이며, 색인화된 데이터에 구속되지 않음

  • 단어 자체와 동시에 출현하는 인접 단어의 패턴 분석해 최근접 이웃(nearest neighbor) 추출
    • 문법적 관점에서 동의어가 아니더라도 동의어로 간주
  • 분포 가설(distributional hypothesis): 같은 맥락에서 사용되고 발생하는 단어들이 유사한 의미를 갖는 경향이 있다는 생각이며, 텍스트 표현을 위한 많은 딥러닝 알고리즘의 기초가 됨
    • ex. 도시 이름은 'in' 이라는 단어 근처나 'live', 'visit' 등과 같은 동사에서 멀리 떨어지지 않고 사용됨
    • 데이터로부터 동의어 생성 가능

 

2.3 순방향 신경망

순방향 신경망(feed-forward neural network, 또는 전방전달 신경망, 피드 포워드 신경망)

  • 정보가 입력 계층에서 은닉 계층으로 전달, 마지막으로 출력 계층으로 전달되며 루프 구조가 없어 뉴런 간에 순환 고리 형성되지 않음

 

뉴런: 망의 근분적인 구성 요소

  • 어떤 계층에 속함
  • 들어오는 가중치에 맞춰 입력 처리
  • 활성 함수에 따라 출력 전파

  • 두 번째 층의 뉴런으로 들어오는 모든 가중치를 0.3으로 설정하고 첫 번째 계층으로부터 0.4, 0.5, 0.6 입력치 받는다고 가정
  • 각 가중치에 그 입력을 곱함 -> 0.3 * 0.4 + 0.3 * 0.5 + 0.3 * 0.6 = 0.45
  • 활성 함수는 이 중간 결과에 적용된 후 뉴런의 나가는 연결선에 전파. 일반적으로 쓰이는 활성함수로 탄젠트(tanh), 시그모이드(sigmoid) 및 정류 선형 장치(ReLU)가 있음
  • tanh함수 사용할 경우 tanh(0.45) = 0.4218990053 이므로, 세 번째 계츠의 뉴런은 유일한 수신 연결선을 통해 이 숫자를 수신해 자신의 입력치로 사용하여 똑같은 단계 수행

 

 

역전파: 신호가 신경망 내에서 순방향으로 전달된 뒤 다시 출력 계층에서 입력 계층으로 역방향으로 흐르게 함

  • 입력치가 순방향 방식으로 출력 계층에 전달되면 출력 계층에서는 이 값을 활성 함수를 거치며 변형하는데, 이렇게 변형된 최종 출력치는 기대 출력치와 비교됨
  • 비용 함수(cost function): 특정 사례에서 망이 얼마 잘못되었는지 나타내는 측도(measure)
  • 오차는 출력 뉴런으로 들어오는 연결선을 통해 은닉 계층의 해당 유닛에 역방향으로 전달
  • 유닛은 갱신 알고리즘(update algorithm)에 따라 가중치를 갱신하며, 이 가중치의 역방향 갱신은 입력 계층에 연결된 연결선이 나타내는 가중치까지 조정되어야 끝남
    • 각 가중치는 오차가 생기게 하는 원인 중 하나이므로, 역전파라는 과정을 통해 가중치 조정 시 입력과 출력으로 이뤄진 상이 만들어내는 오차 줄일 수 있음

 

 

2.4 word2vec 사용

word2vec: 텍스트의 한 부분을 가져다가 텍스트의 각 단어를 하나씩 일련의 벡터로 출력

  • 출력 벡터가 2차원 그래프에 표시될 때, 서로 의미가 매우 유사한 단어 벡터가 매우 가깝게 놓이게 됨
  • 단어의 동의어 찾기 가능

 

word2vec 같은 알고리즘에 의해 생성된 단어 벡터는 정적이고(static) 이산적이며(discrete), 고차원적인(high dimensional) 단어 표현을 차원이 더 낮으면서도 미분 가능한(연속적인) 벡터 공간에 사상(mapping)하기 때문에 단어 매장(word embedding)이라고 하는 경우가 많음

 

ex. i like pleasure spiked with pain and music is my aeroplane

  • 텍스트를 word2vec에 입력할 시 각 단어에 대한 벡터 생성(주성분 분석, t-SNE와 같은 차원성 축소 알고리즘 사용해 2차원 출력)
  • 각 벡터 사이의 거리 측정하기 위해 코사인 유도 사용 시 결과 중 일부는 좋고, 일부는 좋지 않음
    • music -> song, view
    • looking -> view, better
    • in -> the, like
    • sitting -> turning, could
      • 생성된 단어 벡터의 차원(2개 차원) 수가 너무 낮은 것으로 보임
      • 더 많은 예문 필요
  • 더 많은 데이터셋 사용해 word2vec 모델 다시 만들 시
    • music -> song, sing
    • view -> visions, gaze
    • sitting -> hanging, lying
    • in -> with, into
    • looking -> lookin, lustin

 

검색 엔진이 자신이 취급하는 데이터에서 동의어를 생성하는 방법을 학습할 수 있기 때문에 최신 정보를 유지하기 위한 사전이나 어휘가 필요하지 않을 수 있음

 

word2vec의 단어 표현 학습 - 연속 단어 주머니(CBOW)와 연속 스킵그램(continuous skip-gram) 사용

  • 신경망에 일정한 크기의 조각으로 쪼개지는 텍스트 한 조각이 주어지며, 모든 단편은 표적 단어(target word 또는 대상어, 목표 단어)와 문맥(context)로 구성된 쌍으로 망에 공급
    • 훈련 중 각 조각의 일부를 표적 단어로 사용하며, 나머지는 문맥으로 사용
    • 연속 단어 주머니 모델에서는 표적 단어를 망의 출력물로, 텍스트 조각(문맥)의 나머지 단어를 입력으로 사용
    • 연속 스킵그램 모델에서는 표적 단어는 입력으로, 문맥 단어는 출력으로 사용
    • 스킵그램이 자주 사용하지 않는 단어에서 약간 더 잘 작동하는 경우가 흔하므로 더 선호됨
    • ex. she keeps moet et chandon in her pretty cabinet let them eat cake she says (창: 5)
      • | she | keeps | moet | et | chandon | 5개의 텍스트 조각 표본
      • 입력: | she | keeps | et | chandon |
      • 출력: moet
  • 망의 은닉 계층에는 각 단어에 대한 일련의 가중치가 들어가며, 이 벡터들은 학습이 끝날 때 단어 표현으로 사용됨
  • 훈련 단계가 끝날 때 은닉 계층의 내부 상태 추출해 각 단어를 정확히 하나의 벡터 표현으로 산출
  • 각 단어를 원핫인코딩 벡터로 표현
  • 단어 주머니 모델
      • 입력 계층은 CxV의 차원성을 가지며, 여기서 C는 문맥의 길이(window 파라미터 1에 대응), V는 어휘의 크기
      • 은닉 계층에는 사용자가 정의한 N의 차원성 존재
      • 출력 계층은 V와 같은 차원성 가짐
    • 입력 단어의 원핫인코딩 벡터를 먼저 입력-은닉 사이에 있는 가중치들에 곱해 망을 통해 전파
    • 출력은 은닉-출력 가중치와 결합(다중)되어 출력 생성되며, 이 출력은 소프트맥스 함수 통과
    • 소프트맥스는 임의의 실제 값 k차원 벡터(출력 벡터)를 1까지 더하는 범위(0,1)의 k차원 벡터에 '스쿼시(squash)'하여 확률 분포 나타낼 수 있도록 함
    • 문맥(망 입력) 감안해 각 출력 단어가 선택될 확률 알려줌
    • 이 신경망의 가장 중요한 부분은 맥락에서 주어진 단어들을 예측하는 것이 아닌, 두 단어가 의미적으로 비슷한 경우를 결정할 수 있도록 은닉 계층의 가중치가 조정됨
  • 스킵그램 모델

      • 입력 벡터는 원핫인코딩(각 단어마다 하나씩)되어 있으므로 입력 계층에는 입력 텍스트의 단어 수와 같은 수의 뉴런 존재
      • 은닉 계층은 원하는 결과 단어 벡터의 차원성을 가짐
      • 출력 계층은 window - 1에 단어 수를 곱한 숫자의 뉴런 가지고 있음
      • ex. she keeps moet et chandon in her pretty cabinet let htem eat cake she says
        • 입력: moet
        • 출력: | she | keeps | et | chandon |

 

 

2.4.1 Deeplearning4j에 word2vec 끼워쓰기

DL4J(Deeplearning4j): 자바 가상 머신을 위한 딥러닝 라이브러리

  • 스킵그램 모델을 기반으로 word2vec 바로 구현 가능

 

2.4.2 Word2vec 기반 동의어 확장

WordNet 사용 시 제한된 동의어 집합을 가지고 있기 때문에 색인 부풀리기 불가

word2vec을 책임감 있게 사용하기 위한 전략

  • 최근접 단어를 얻기 위해 투입할 단어의 종류 제한 (ex. PoS(품사)가 NC(보통명사) 또는 VERB(동사)인 단어에 대해서만 사용)
  • 문서가 얼마나 유익한지 살펴보는 것 (ex. 긴 문서보다 짧은 문서들에 초점을 맞추면서 이 문서들의 동의어를 확장)
  • 용어 가중치를 보고 낮은 가중치를 생략
  • 유사도가 좋은 경우에만 word2vec 결과 사용

 

  • word2vec을 기반 동의어 확장 과정
  • 학습된 word2vec 모델을 사용해 필터링 중 용어 동의어를 예측할 수 있는 동의어 필터 생성 가능

 

 

2.5 평가 및 비교

쿼리 확장의 도입 전후에 정밀도, 재현율, 결과 0의 쿼리 등을 포함한 계량(metrics) 포착 가능하며, 신경망의 모든 파라미터를 최선의 구성 집합이 되게 정하는 것도 좋은 방법

 

교차 검증(cross validation): 머신러닝 모델이 훈련용 데이터와 훈련용이 아닌 데이터를 구분함으로써 훈련을 아주 잘 하게 하는 동시에 파라미터를 최적화 하는 방법

  • 훈련 집합: 모델 훈련하는 데 쓸 데이터의 출처로 사용
  • 교차 검증 집합: 가장 성능이 좋은 파라미터를 가진 모델을 선택하는데 사용
  • 테스트 집합: 교차 검증 집합과 동일한 방식으로 사용되나, 교차 검증 집합에서 테스트를 통해 선택된 모델에서만 사용되는 것 제외

 

 

2.6 프로덕션 시스템에 대해 고려할 사항

대부분의 기존 프로덕션 시스템은 이미 많은 색인화된 문서를 포함하고 있으며, 그러한 경우 색인화되기 전 존재했던 원래의 데이터에 접근하는 것이 때때로 불가능

시간이 지나 데이터셋이 변할 경우 별도의 저장소에 이전 사본을 보관하지 않으면 나중에 모든 색인된 문서에 대해 word2vec 모델 작성 불가능

-> 검색 엔진을 주요 데이터 소스로 사용해 해결

 

 

2.6.1 동의어 대 반의어

보통 텍스트에 'hate', 'love'가 비슷한 맥락에서 나타나지만, 적절한 동의어가 아니라는 것을 말해 줄 충분한 정보가 있음

단어 벡터 간의 유사도는 충분히 비슷하지 않은 최근접 이웃을 배제하는데 도움

  • 유사도의 절대값(ex. 0.6)을 기준으로 필터링

 


요약

  • 동의어 확장 시 재현율이 개선되므로 검색 엔진 사용자를 더 행복하게 하는 기법이 될 수 있음
  • 일반적인 동의어 확장 기법 적용 시 사용되는 데이터와 별 관계없는 정적인 사전이나 어휘집을 사용하게되고, 이로 인해 이러한 사전이나 어휘집을 일일이 수작업으로 정비 필요
  • 순방향 신경망은 많은 신경망 아키텍처의 기초. 정보는 입력 계층에서 출력 계층으로 흐르며, 이 두 계층 사이에 하나 이상의 은닉 계층 있을 수 있음
  • word2vec은 유사한 의미의 단어를 찾거나 유사한 문맥에 나타나는 단어를 찾기 위해 사용할 수 있는 단어들에 대한 벡터 표현을 학습하는 순방향 신경망 기반 알고리즘. 따라서 이 단어를 동의어 확장에도 사용하는 것이 합리적

'Study > 검색을 위한 딥러닝' 카테고리의 다른 글

Chapter 1. 신경망을 이용한 검색  (0) 2023.10.14
  • 검색에 관한 기초 내용
  • 검색 시에 당면할 수 있는 중요 문제
  • 신경망이 검색 엔진에 더 효과적일 수 있는 이유

 

이 책은 딥러닝(deep learning, DL)이라는 머신러닝의 하위 분야 기법을 이용해 검색 엔진의 동작에 영향을 줄 수 있는 모델과 알고리즘을 더 효과적으로 구축하는 데 필요한 내용을 담고 있다.

딥러닝 알고리즘이 로비가 하는 일을 담당하게 하면 검색 엔진은 더 나은 검색 엔진을 제공할 수 있을 테고, 따라서 최종 사용자에게 더 정확한 답을 제공할 수 있을 것이다.

 

인공지능 > 머신러닝 > 딥러닝


1.1 신경망과 딥러닝

딥러닝이란 머신러닝의 한 분야이며, 심층 신경망을 이용해 컴퓨터가 사물을 점진적으로 표현하고 인식할 수 있도록 머신이 학습할 수 있는 분야.

 

인공신경망(artificial neural network): 뇌의 신경세포가 그래프 꼴로 조직되는 방식에서 영감을 얻어 만든 연산 패러다임

  • 입력 계층(input layer, 또는 입력층): 입력 내용을 받아들이는 첫번째 계층
  • 은닉 계층(hidden layer, 또는 은닉층): 입력 - 출력 사이의 계층
  • 출력 계층(output layer, 또는 출력층): 마지막 계층으로서 신경망의 결과 출력

 

 

1.2 머신러닝이란?

이전까지 쌓아온 경험(이전에 관측한 내용과, 이러한 관측치로부터 알고리즘이 추정해야 할 내용이 서로 쌍을 이룬 형태)을 바탕으로 최적해를 학습해 낼 수 있는 알고리즘을 기반으로 문제를 해결하는 자동화된 접근법

 

딥러닝은 머신러닝을 수행하는 방법 중 한 가지에 불과하며, 심층 신경망을 사용한다는 점이 여타 머신러닝 알고리즘과 다름

 

머신 러닝

지도학습(supervised learning, 또는 감독학습): 각 입력에 따른 적합한 출력을 지정

  • 훈련 단계(training phase) 동안 머신러닝 알고리즘은 훈련 집합을 쪽쪽 씹으며 입력 텍스트를 출력 범주에 대응(map)시키는 일과 같은 방식을 배움
  • 훈련 단계를 마치면 머신러닝 모델(machine learning model, 또는 기계학습 모델)을 사용해 일을 마무리하며, 출력 예측 시 활용

비지도학습(unsupervised learning, 또는 자율학습)

  • 예상되는 출력에 대한 정보가 없는 데이터를 가지고도 학습 단계(learning phase)에서 패턴과 데이터 표현을 추출

 

 

 

1.3 검색 시에 딥러닝으로 할 수 있는 일

딥러닝 알고리즘을 적용한 검색엔진의 이점

  • 최종 사용자에게 연관도가 더 높은 결과 제공
  • 텍스트를 검색할 때와 같은 방법으로 이진 형식으로 된 내용 검색 가능(이미지 검색)
  • 검색 내용에 쓰인 언어와 다른 언어를 사용하는 사용자에게도 내용 제공
  • 데이터를 더 정교하게 처리

 

 

 

1.5 유용한 정보 꺼내기

검색 엔진이란?

  • 사람들이 정보를 끄집어 내는 데 사용할 수 있는 시스템. '데이터'를 '정보'로 만들어 제공하는 역할
  • 수직 검색 엔진(vertical search engine): 특정한 문서 형식이나 특정 주제에 특화 (ex. 구글 스칼라)

검색 엔진의 역할

  • 색인화(indexing): 데이터를 효율적으로 수집하고 저장해 둠으로써 빠르게 검색
  • 쿼리 처리(querying, 즉 질의처리): 최종 사용자가 정보를 찾아볼 수 있게 검색 기능 제공
  • 순위지정(ranking): 사용자의 정보 요구를 가장 잘 충족하기 위해 특정 지표에 맞춰 순위 지정해 결과 표시

1.5.1 텍스트, 토큰, 용어, 검색에 관한 기초 지식

텍스트 분석(text analysis): 용어(term)라고 부르는 텍스트 조각을 추출하고 저장 (텍스트를 그 구성 요소인 단어별로 분해)

용어(terms): 텍스트 분석 알고리즘에 의해 생성된 최종 단위(단어 외 문장 그룹이나 단어의 일부일 수 있음). 검색 엔진이 데이터를 저장해 결과적으로 데이터를 검색하기 위해 사용하는 기본 단위

 

키워드 검색(keyword search): 사용자가 단어 세트를 입력하면 검색 엔진이 단어의 일부 또는 모든 용어를 포함하는 문서 모두 반환

쿼리(query, 질의 또는 질의어): 사용자가 무언가를 검색하기 위해 입력하는 텍스트

 

검색 단계를 빨리 계산할 수 있는 방법?

역색인(inverted indexes, 또는 역인덱스): 용어가 원래 들어 있던 텍스트에 용어를 매핑하는 데이터 구조 (책의 뒤편에 나오는 색인 구조와 같음)

 

텍스트 분석 파이프라인 구성의 두가지 유형 빌딩 블록

  • 토크나이저(tokenizer, 즉 토큰화기 또는 토큰 생성 함수): 텍스트의 스트림을 단어나 구 또는 기호나 토큰(token)이라고 부르는 그 밖의 단위에 맞춰 분할하는 컴포넌트
    • ex. 화이트스페이스(whitespace) 문자를 만날 때마다 토큰 분할
  • 토큰 필터(token filter): 토큰 스트림을 받아들여 새 토큰으로 수정, 삭제하거나 추가할 수 있는 컴포넌트
    • ex. 불용어 목록(stopword list, '정지어 목록', '사용하지 않을 블룩)이라는 일종의 블랙리스트에 일치하는 토큰 제거

 

색인화(indexing, 인덱싱): 텍스트의 스트림을 분석한 결과로 나온 용어들을 검색 엔진에 저장하는 전체 과정

문서(document): 색인화할 텍스트 조각

 

색인화 예제

  • 'the brown fox jumped over the lazy dog' (문서 1)
  • 'a quick brown fox jumps over the lazy dog' (문서 2)
  • 역색인 표
    • 용어 문서 식별부호
      brown 1, 2
      fox 1, 2
      jumped 1
      over 1, 2
      lazy 1, 2
      dog 1, 2
      quick 2
      jumps 1
      • 불용어 기반의 토큰 필터로 인해 'the' 용어 항목 없음
      • 첫번째 열의 용어 사전과 각 행의 각 용어와 관련된 게시 목록(posting list), 즉 문서 식별자 집합 찾기 가능
      • 역색인을 사용해 특정 용어가 포함된 문서 아주 빠르게 검색 가능
        • ex. 'quick' 용어 검색 시 'quick'이라는 용어에 해당하는 게시 목록 살펴서 문서 2 반환
      • 실무에서는 문서의 서로 다른 부분들에 대한 색인들을 동일한 검색 엔진에서 모두 처리할 수 있게 역색인을 중복해서 갖춰둠

 

검색(retrieval)

쿼리 파서(query parser, 쿼리 구문분석기): 사용자가 입력한 검색 쿼리 텍스트를 검색 엔진이 찾아야 할 용어와 역색인에서 일치 항목을 찾을 때 사용하는 방법을 나타내는 일련의 절(clause)로 변환

  • ex. 'deep + learning for search' 쿼리 예제에서 기호 +와 '를 이해하는 역할 (deep, learning 반드시 포함)
  • 지능형 쿼리 파서의 경우 단어의 의미를 반영하는 절들 생성 가능

색인 시간 텍스트 분석(index-time text analysis): 색인화 하는 동안 텍스트 분석 파이프라인은 입력 텍스트를 색인에 저장할 용어로 분할

찾기 시간 텍스트 분석(search0time text analysis): 쿼리가 검색을 하는 동안 쿼리 문자열을 용어별로 분리하기 위해 텍스트 분석 적용

 

 

 

역색인

  • 시스템이 텍스트 분석(토큰화 및 필터링)을 통해 사용자가 쿼리 시간에 입력할 것으로 예상되는 용어에 맞춰 텍스트를 분류함으로써 역색인이라고 부르는 데이터 구조에 배치하는 기술
  • 저장 공간 측면 - 효율적으로 색인 작업 가능
  • 검색 소요 시간 측면 -효율적으로 검색 가능

 

 

1.5.2 연관도 우선

연관도: 문서가 특정 검색 쿼리와 관련해 얼마나 중요한지 측정하는 기준

  • 검색 모델(retrieval model)은 연관도의 개념을 가능한 한 정확하게 포착해야 함
  • 연관도가 높은 결과일수록 검색 결과의 순위지정(rank) 점수 높음

1.5.3 고전적인 검색 모델

벡터 공간 모델(vector space mode., VSM)

  • 각 문서와 쿼리는 벡터로 표현되며 문서 벡터와 쿼리 벡터가 가까울 수록 유사
  • 가중치(weights): 검색 엔진의 나머지 문서와 관련해 해당 용어가 문서/쿼리에서 얼마나 중요한지를 나타내는 실제 수
  • 용어빈도-역문서빈도(term frequency-inverse document frequency, TF-IDF, 또는 용어빈도/역문헌빈도)
    • 단일 문서에 용어가 자주 나타날수록(TF 클수록) 중요
    • 모든 문서에 걸쳐 어떤 용어가 흔하게 나타날수록(IDF 클수록) 중요성 떨어짐

Okapid BM25: 확률론적 모델. 문서가 특정 쿼리와 연관될 확률을 추정해 검색 결과 순위로 매김

 

1.5.4 정밀도와 재현율

정밀도(precision): 검색된 문서들 중 연관성이 있는 문서들의 비율을 분수로 나타냄

  • 정밀도 높을수록 사용자는 검색 결과 목록의 맨 위에서 원하는 결과 대부분 찾을 수 있음

재현율(recall): 연관성이 있는 문서들 중 검색된 문서들의 비율을 분수로 나타낸 것

  • 재현율 높을수록 검색 결과에서 모든 관련 결과 찾을 수 있지만, 관련 결과라고 해서 다 상위 차지는 못할 수 있음(랭킹 낮을 수 있음)

 

검색 엔진의 효과 측정 옵션: 공개된 데이터셋 사용

 

 

 

1.6 미해결 문제들

 필요한 모든 정보를 다 얻으려면 몇 번에 걸쳐 묻고 응답하는 과정이 반복될 수 있음

  • 심층 신경망을 사용해 더 쉽게 사용 가능하고 더 발전한 검색 엔진을 만들고자 할 때 이러한 문제들 인식 필요

 

 

1.7 검색 엔진 블랙박스 열기

효과적인 검색 쿼리를 만들 때 중요한 문제 - 어떤 쿼리 언어를 사용하는가.

쿼리 언어에 따라 검색 결과가 많이 달라질 수 있으며, 실무에서 검색 결과의 순위를 수동으로 조정하는 것은 거의 불가능

  • 딥러닝으로 그러한 문제를 해결하거나 최소한 완화시키는데 어떻게 도움이 될 수 있을까

 

 

1.8 구조의 손길을 펼치는 딥러닝

딥러닝: 심층 신경망을 사용해 일반적으로 텍스트나 이미지 또는 데이터의 깊은 표현을 배우는 데 초점을 맞춘, 머신 러닝의 하위 영역

  • 적어도 두 개의 은닉 계층을 가지고 있을 때 심층(deep) 신경망으로 간주
  • 심층 신경망은 특히 고도로 합성된 데이터(작지만 비슷한 성분들이 큰 물체 형성 시)에 사용할 때 큰 도움이 되며, 이미지와 텍스트가 이 경우에 해당

 

텍스트 문서 집함 내에서 단어 표현을 학습하기 위해 신경망 알고리즘 사용 시, 밀접하게 관련된 단어들은 벡터 공간에서 서로 인접

  • word2vec신경망 알고리즘 사용해 단어 벡터(word vector) 학습

단어 매장(word embedding, 단어 임베딩)으로도 불리는 단어 벡터나 문서 매장(document embedding, 문서 임베딩)으로도 불리는 문서 벡터에 의존하는 검색 모델이 있으면 좋을 것이므로 이를 위해 최근접 이웃(nearest neighbor) 보며 문서 유사도나 단어 유사도를 효율적으로 계산하고 사용

 

단어나 문장이나 문서가 나타내는 맥락을 사용해 가장 적절한 표현을 추론함으로써 텍스트에 숨어 있는 의미를 잘 표현 가능하고, 검색엔진의 연관도 높일 수 있음

 

딥러닝 vs 심층 신경망

딥러닝은 주로 심층 신경망을 이용해 단어, 텍스트, 문서, 이미지의 표현을 배우는 일

심층 신경망: 더 넓게 응용. (ex. 언어 모델링, 기계 번역 등)

 

 

1.9 색인아, 뉴런을 만나 주지 않을래?

신경망과 검색 엔진을 통합하는 몇가지 방법

  • 훈련 후 색인(train-then-index):
    1. 문서 모음(텍스트, 이미지)을 가지고 망을 훈련
    2. 훈련에 쓴 데이터와 동일한 데이터를 가지고 검색 엔진에서 색인
    3. 검색 시 검색 엔진과 신경망 사용
  • 색인 후 훈련(index-then-train): 
    1. 검색 엔진에서 문서 모음 색인화
    2. 색인화된 데이터로 신경망을 훈련(때때로 데이터 변경 시 다시 훈련)
    3. 검색 시 검색 엔진과 신경망 함께 사용
  • 훈련으로 색인 추출(train-extact-index):
    1. 문서 모음을 가지고 망을 훈련
    2. 훈련된 망을 사용해 데이터와 색인화될 유용한 자원 함께 생성
    3. 검색 엔진만 있으면 검색 가능

 

 

1.10 신경망 훈련

신경망 학습 알고리즘은 기대 출력과 실제 출력간의 차이를 취해 이를 바탕으로 각 계층의 가중치를 조정함으로써 다음 차례에 나올 출력 오차를 줄임

데이터가 충분할 시 오차율을 크게 줄일 수 있으며, 활성 함수는 예측을 수행하는 신경망의 능력과 학습 속도에 영향 미침

 

역전파 알고리즘: 기대 출력과 실제 출력이 주어지면 알고리즘은 각 뉴런의 오차(error)를 역전파하고 결과적으로 출력에서 입력까지 한 번에 한 계층씩 각 뉴런의 연결부에 대한 내부 상태 조정

 

정적모델(static model, 또는 정태모형)의 경우 훈련 집합을 갱신하려면 전체 과정을 순서대로 반복해야 하는데, 끊임없이 흘러 들어오는 신규 데이터를 처리해야 하는 검색 엔진과 같은 시스템에는 적절하지 않음

  • 신경망에 재훈련이 필요하지 않은 온라인 학습(online learning) 도입?

 

1.11 신경 검색의 약속들

 

신경 검색 활용

  • 의미를 깊이 파악하는 딥러닝의 능력을 통해 기초 데이터에 잘 적응하는 관련 모델과 순위지정 함수 얻을 수 있음
  • 이미지 검색에서 좋은 결과를 주는 이미지 표현 학습 가능
  • 의미적으로 유사한 단어나 문장 또는 단락등을 파악하기 위해 딥러닝이 생성한 데이터 표현에 적용 가능
  • 텍스트 생성, 번역, 검색 엔진 최적화 등..

검색 시스템에 신경망 활용

  • 색인화 시 역색인에 진입하기 전 데이터 보강 위한 신경망 사용
  • 검색 쿼리 범위 확대하거나 지정해 더 많은 수의 결과나 정환한 결과 제공하는 일에 신경망 사용
  • 사용자가 검색 쿼리를 입력할 수 있도록 돕거나, 검색 쿼리를 번역하는 일에 신경망 사용

한계

  • 훈련 비용
  • 모델 업그레이드 등..

 


요약

  • 정보 검색에 대한 일반적인 접근 방식에는 한계점과 단점이 있음
  • 텍스트 분석은 색인화와 검색 단계에서 모두 중요한 작업
  • 연관도는 검색 엔진이 사용자의 정보 요구에 얼마나 잘 대응하는지 보여주는 기초 측도며, 사용자마다 맥락과 의견이 크게 다를 수 있으므로 연관도 측정 시 검색 엔지니어에게 지속적으로 초점 맞춰야 함
  • 딥러닝은 심층 신경망을 이용해 의미적으로 목적에 적합한 유사성 측도를 포착할 수 있는 내용의 표현을 학습하는 머신러닝 분야
  • 신경 검색은 딥러닝을 사용해 검색과 관련된 다양한 작업을 개선하는 것을 목표로함

'Study > 검색을 위한 딥러닝' 카테고리의 다른 글

Chapter 2. 동의어 생성  (0) 2023.10.25

+ Recent posts