Newer
Older
# 엔진유형 목록 (v19.03)
KSB 인공지능 프레임워크가 기본적으로 제공하는 엔진 유형으로서 크게 배치방식, 스트림방식, 실시간 스트림 방식, 온디맨드 방식으로 동작하는 엔진들과 기타 외부연동용 엔진, GenericType의 엔진 유형이 존재합니다.
## 배치방식 처리엔진
엔진 타입 | 설명 | 사용 예제
--|--|--
**Batch** | 배치성 처리에 사용되는 엔진컨테이너로서 배치저장소로부터 데이터를 읽어 일괄처리 후 배치저장소로 출력하기 위한 용도로 활용가능. <br>BatchReader, BatchWriter, BatchOperator, BatchRunner, BatchController로 구성. <br>대표적으로 딥러닝학습용 엔진컨테이너를 구성하고자 하는 경우 이 엔진을 활용 |<a href="https://etrioss.kr/thkimetri/ksb19.03-manual/blob/master/manual1903/2.5.10.HourlyTensorflowTraining.md" > • 텐서플로우 모델 주기적으로 학습하기 </a>
**BatchToBatchStream** | 배치성 데이터 처리에 사용되는 컨테이너로서 배치저장소로부터 많은 데이터를 읽어 미니배치 형태의 다양한 처리를 수행한 후 배치저장소에 적재하는데 사용. <br>BatchReader, BatchWriter, StreamOperator, StreamRunner, StreamController로 구성 |<a href="./2.5.2.KMeansExample.md" > • 배치방식으로 데이터 처리하기 </a> <br> <a href="https://etrioss.kr/thkimetri/ksb19.03-manual/blob/master/manual1903/2.5.3.DeidentificationExample.md" > • 비식별 처리하기 </a>
배치처리 방식의 엔진들은 파일, DB 등의 배치저장소로부터 데이터를 한번 읽은 후 데이터를 가공하고, 배치저장소로 출력합니다. 따라서 엔진이 실행되면 데이터 처리가 끝난 후 자동으로 종료됩니다. 배치방식 처리 엔진들은 한번 실행하거나 주기적으로 실행할 수 있습니다 (엔진의 RUNTYPE 속성 지정).
배치방식 처리 엔진들이 두 개 이상 포함된 워크플로우의 경우, 워크플로우의 속성 값 중 Batch 를 true 로 선택할 경우, 맨 앞의 엔진부터 실행과 종료가 순차적으로 실행이 됩니다. 반대로 Batch 를 false 로 설정할 경우 동시에 엔진이 실행됩니다. 따라서 앞의 엔진의 처리 결과를 이용해 뒤에 엔진이 처리해야하는 순차적인 실행을 하고자하는 워크플로우는 반드시 Batch 를 true 로 설정하시고 실행하여야 합니다.
## 스트림방식 처리엔진
엔진 타입 | 설명 | 사용 예제
--|--|--
**StreamToBatch** | 스트림을 입력받아 처리한 후 배치저장소에 출력하기 위한 엔진컨테이너.<br>StreamReader, BatchWriter, StreamOperator, StreamRunner, StreamController로 구성 | <a href="https://etrioss.kr/thkimetri/ksb19.03-manual/blob/master/manual1903/2.5.1.HttpToMongodbExample.md" > • 스트림 데이터 적재하기 </a> <br> <a href="https://etrioss.kr/thkimetri/ksb19.03-manual/blob/master/manual1903/2.6.1.TrafficPreprocessing.md" > • 교통속도 스트림 데이터 전처리하기 </a>
**StreamToStream** | 스트림 데이터처리에 사용되는 엔진컨테이너. <br>StreamReader, StreamWriter, StreamOperator, StreamRunner, StreamController로 구성 | <a href="https://etrioss.kr/thkimetri/ksb19.03-manual/blob/master/manual1903/2.5.12.TfStreamPredictionMnist.md" > • 스트림 방식으로 MNIST 모델 서빙하기 </a> <br> <a href="https://etrioss.kr/thkimetri/ksb19.03-manual/blob/master/manual1903/2.5.7.RealtimeIngestToPredictInSingleEngine.md" > • 스트림방식으로 ML모델 예측결과 얻기 </a>
스트림방식 처리 엔진들은 카프카, HTTP 등을 이용해 스트림 데이터를 입력받은 후 일정한 주기 (Mini batch 주기)로 깨어나 미니배치 형태로 동작합니다. 스트림 데이터를 들어온 순서대로 일정한 개수만큼 잘라서 가공하고, 배치저장소에 출력하거나 또는 스트림 형태로 출력합니다. 스트림 처리 엔진은 계속해서 스트림 데이터를 받고 있으므로 사용자가 종료 명령을 내릴 경우 종료됩니다. 종료는 **KSB 웹툴킷** 의 모니터링 화면에서 할 수 있습니다.
현재 프레임워크 상에 구현되어 있는 대부분의 스트림 처리용 컴퍼넌트들은 Spark Streaming (<a href="https://spark.apache.org/docs/latest/streaming-programming-guide.html" >참고사이트 바로가기</a>) 기반으로 구현되었습니다.
스트림방식 처리 엔진들은 데이터를 처리하는 시간이 길 경우 (데이터 처리 오퍼레이터가 많을 경우) delay 가 발생할 수 있습니다. 실시간 처리가 필요할 경우 실시간 스트림방식 처리 엔진을 사용할 것을 권장합니다.
스트림방식 처리 엔진들이 두 개 이상 포함된 워크플로우의 경우, 워크플로우의 속성 값 중 Batch 를 반드시 false 로 설정하셔야 합니다. Batch 를 true 로 설정할 경우 앞의 엔진이 종료되기 전까지 뒤에 엔진이 실행되지 않습니다.
## 실시간 스트림방식 처리엔진
엔진 타입 | 설명 | 사용 예제
--|--|--
**StreamJoin** | 실시간 스트림처리를 제공하기 위한 엔진컨테이너로서 하나 이상의 Reader와 Writer 탑재 가능. <br>StreamController, StreamPipeReader, StreamPipeWriter, StreamPipeOperator, StreamRunner로 구성. <br>Spark structed-streaming 처리에 사용 |<a href="https://etrioss.kr/thkimetri/ksb19.03-manual/blob/master/manual1903/2.6.5.TrafficTimeseriesProcessing.md" > • 실시간 시계열 교통속도 센서스트림 처리 하기 </a>
**StreamPipe** | Deprecated by StreamJoin <br> 삭제예정 |
실시간 스트림방식 처리 엔진은 카프카 등을 이용해 시간정보가 포함된 스트림 데이터를 계속해서 받고 있고 (입력 테이블은 새로 들어온 데이터를 append 함), trigger 시 입력 테이블에서 데이터를 가져와 쿼리를 수행하고 결과 테이블을 출력하는 방식의 실시간 처리를 합니다.
현재 프레임워크 상에 구현되어 있는 대부분의 실시간 스트림 컴퍼넌트들은 Spark의 Structred Streaming (<a href="https://spark.apache.org/docs/latest/structured-streaming-programming-guide.html" >참고사이트 바로가기</a>) 기반으로 구현되었습니다.
실시간 스트림방식 처리 엔진은 데이터에 포함된 시간 정보를 기반으로 처리합니다. 현재 시간은 받은 데이터의 시간 중 가장 늦은 시간이 됩니다. 이 시간을 기준으로 늦게 들어오는 데이터를 얼마동안 고려해서 처리할 것인지를 watermark 설정을 통해 할 수 있습니다 (watermark 는 Reader 의 속성으로 설정합니다). 따라서 실시간 스트림방식 처리 엔진에서는 시간 순으로 들어오지 않는 데이터도 처리 가능합니다.
실시간 스트림방식 처리 엔진에서 결과 테이블을 출력하는 방식은 3가지가 존재합니다 (Writer 의 mode 속성으로 설정합니다). "complete" 모드는 결과 테이블의 전체 row 들을 모두 출력합니다. "update" 모드는 결과 테이블에서 쿼리 수행 결과 변화가 있는 row들을 모두 출력합니다. "append" 모드는 변화가 있는 row들 중 앞으로 변화가 더 이상 일어나지 않을 row 들을 출력합니다. "update" 모드와 "append" 모드는 watermark 설정과 관련이 있으며, watermark 설정을 하지 않았을 경우 출력값이 동일합니다. 현재는 "append" 모드를 사용할 것을 권장합니다.
실시간 스트림방식 처리 엔진은 single 쿼리를 수행하므로 복잡한 가공을 하기는 어렵습니다. window 설정을 통한 총계처리 등을 통해 무작위로 들어오는 데이터를 시간순으로 처리하고, 잡음을 스무딩하고, missing 데이터를 채우는 용도로 사용하고, 복잡한 가공은 스트림 처리 엔진을 통해 미니배치 형태로 수행하는 것을 권장합니다.
실시간 스트림방식 처리 엔진은 계속해서 데이터를 받고 있으므로 사용자가 종료 명령을 내릴 경우 종료됩니다. 종료는 **KSB 웹툴킷** 의 모니터링 화면에서 할 수 있습니다. 따라서 실시간 스트림 방식 처리 엔진들은 한번 실행할 수 있습니다 (엔진의 RUNTYPE 속성 지정).
실시간 스트림방식 처리 엔진들이 두 개 이상 포함된 워크플로우의 경우, 워크플로우의 속성 값 중 Batch 를 반드시 false 로 설정하셔야 합니다. Batch 를 true 로 설정할 경우 앞의 엔진이 종료되기 전까지 뒤에 엔진이 실행되지 않습니다.
## 온디맨드방식 처리엔진
엔진 타입 | 설명 | 사용 예제
--|--|--
**OnDemandServing** | OnDemand 요청에 응답을 제공하기 위한 엔진컨테이너로서, OnDemandOperator, OnDemandRunner, OnDemandController로 구성 |<a href="https://etrioss.kr/thkimetri/ksb19.03-manual/blob/master/manual1903/2.5.11.InceptionServingExample.md" > • 온디맨드 방식으로 Inception 모델 서빙하기 </a> <br><a href="https://etrioss.kr/thkimetri/ksb19.03-manual/blob/master/manual1903/2.6.3.TrafficOnDemandServing.md" > • 온디맨드 방식으로 교통속도예측 모델 서빙하기 </a>
**OnDemandPipeServing** | OnDemand 요청에 하나 이상의 오퍼레이터를 파이프라인 처리하여 응답을 제공하는 엔진으로서 OnDemandPipeReader, OnDemandPipeOperator, OnDemandRunner, OnDemandController로 구성. <br>주로 **융합서빙** 에 사용 |<a href="https://etrioss.kr/thkimetri/ksb19.03-manual/blob/master/manual1903/2.5.13.ConvergedServingEndToEndExample.md" > • 융합 REST API 만들기 </a>
**OnDemandStreamServing** | OnDemand 요청에 서비스를 제공하기 위한 엔진컨테이너로서, OnDemandReader, OnDemandOperator, OnDemandRunner, OnDemandController로 구성 |<a href="https://etrioss.kr/thkimetri/ksb19.03-manual/blob/master/manual1903/2.5.8.RealtimeIngestToServingInTwoEngines.md" > • 스트림 예측하여 REST 방식으로 서빙하기 </a>
**OnDemandExternalServing** | OnDemand 요청에 서비스를 제공하기 위한 엔진컨테이너로서, OnDemandExternalRunner로 구성. <br>주로 사용자가 작성한 Python 모듈을 API화 하기 위한 엔진 구성시 사용 |<a href="https://etrioss.kr/thkimetri/ksb19.03-manual/blob/master/manual1903/2.5.13.ConvergedServingEndToEndExample.md" > • 융합 REST API 만들기 </a>
온디맨드방식 처리 엔진들은 텐서플로우 기반 딥러닝 모델, 사용자가 작성한 Python 모듈 등을 REST API 형태로 서비스 하는 용도로 사용합니다. 사용자 (클라이언트) 는 프레임워크 외부에서 쿼리를 요청하고, 결과를 응답받는 방식으로 사용합니다. Reader 를 통해 데이터를 받지 않는 경우 데이터를 쿼리에 포함하여 요청합니다.
텐서플로우 기반 딥러닝 모델은 TensorFlow Serving (<a href="https://www.tensorflow.org/serving/" >참고사이트 바로가기</a>) 을 통해 서비스 합니다. 따라서 사용자는 학습한 딥러닝 모델을 텐서플로우 서빙용으로 export 한 후 프레임워크에서 모델을 서빙합니다. 프레임워크와 연동하고 서빙을 하기 위해 파이썬 기반 텐서플로우 모델을 코딩하는 방법은 <a href="https://etrioss.kr/thkimetri/ksb19.03-manual/blob/master/manual1903/2.7.2.KSB_TfPyCoding_Guide.md" >KSB 프레임워크와 연동을 위한 tensorflow 학습코드 작성하기</a> 를 참고합니다.
사용자가 작성한 Python 모듈은 프레임워크에서 제공하는 KSB Dockerize (<a href="https://etrioss.kr/thkimetri/ksb19.03-manual/blob/master/manual1903/2.7.1.KSB_Dockerize.md" >참고자료 바로가기</a>) 를 이용하여 REST API로 만들고 서비스 합니다. KSB Dockerize 라이브러리는 사용자가 프로그래밍한 Python 함수를 Docker 이미지로 자동 변환할 뿐만 아니라 REST API 기능을 자동으로 추가하여, 사용자 Python 함수로 입력 데이터를 보내고 결과를 받을 수 있게 합니다.
또한 내부적으로 여러 개의 REST API 를 파이프라인하여 새로운 융합 REST API 를 만드는 것이 가능합니다. 사용자 (클라이언트) 는 프레임워크 외부에서 융합서빙 엔진으로 한번만 쿼리를 요청하면, 내부적으로 여러 개의 REST API 로 쿼리를 보내고 응답받은 결과를 총계처리 하여 사용자 (클라이언트) 에게 보내줍니다. 또는 REST API 로 쿼리를 보내고 응답받은 결과에 따라 다음 REST API 주소를 결정하여 (라우팅 기능) 쿼리를 보내고 응답받은 결과를 사용자 (클라이언트) 에게 보내줍니다.
온디맨드방식 처리 엔진은 계속해서 쿼리 요청을 대기하고 있으므로 사용자가 종료 명령을 내릴 경우 종료됩니다. 종료는 **KSB 웹툴킷** 의 모니터링 화면에서 할 수 있습니다. 따라서 온디맨드방식 처리 엔진들은 한번 실행할 수 있습니다 (엔진의 RUNTYPE 속성 지정).
온디맨드 방식 처리 엔진들이 두 개 이상 포함된 워크플로우의 경우, 워크플로우의 속성 값 중 Batch 를 반드시 false 로 설정하셔야 합니다. Batch 를 true 로 설정할 경우 앞의 엔진이 종료되기 전까지 뒤에 엔진이 실행되지 않습니다.
## 기타 엔진
엔진 타입 | 설명 | 사용 예제
--|--|--
**External** | 외부 실행플랫폼을 연동하기 위한 엔진컨테이너로서, BatchReader, BatchWriter, 하나 이상의 BatchOperator, BatchRunner, BatchController로 구성. <br>대표적으로 파이썬 기반 딥러닝학습용 엔진컨테이너의 경우 이 엔진을 활용 |<a href="https://etrioss.kr/thkimetri/ksb19.03-manual/blob/master/manual1903/2.5.4.BatchMLTrainInSingleEngine.md" > • ML 모델 학습하기 </a> <br> <a href="https://etrioss.kr/thkimetri/ksb19.03-manual/blob/master/manual1903/2.5.5.BatchAutoMLTrainInSingleEngine.md" > • AutoML 학습하기 </a>
**Generic** | 사용자가 정의할 수 있는 모든 요소를 이용 가능한 엔진컨테이너로서, 모든 종류의 Reader, Writer, Operator, Runner, Controller로 구성. <br>Generic 타입이므로 자유도가 높은 반면, 개발자가 오류를 범하지 않도록 응용을 만들때 신중히 구성해야 함.