해당 스터디에서 다루지 않았지만 추가적으로 스터디 가능할 부분을 아래와 같이 정리한다
떠오르는 순서대로고, 우선순위 순은 아니다.
spark작업 설정과 사용법은 빅데이터를 위해 기본인데, spark를 설정하고 이 스파크 엔진을 airflow와 연결하는 작업에 호환 에러가 생기기 쉽다. 문서에는 없지만 EMR을 띄우고 airflow와 연동하는 시도도 있었지만, 충분히 깊이가 없게 느껴져 자세히 남기지 않았다
앞에 간단히 소개했지만, 서비스용 airflow는 kubernetes를 기반으로 돌게된다.
현재 docker에서 도는것을 넘어 kubernetes로 직접 구현할 수 있다면 데이터엔지니어로 스팩에 한줄 적을 수 있을 정도가 되지만, 스터디 목적으로는 (비용적으로도, 깊이로도) 과해서 다루지 않는다.
현재 데이터는 S3에 순수 파일로 올라가있다. 비유자하면 바탕화면에 .txt파일 하나를 올려둔 것이다
이를 최소한 mysql의 DB 형태로 올리면 좋고, 분산처리 테이블인 hive를 띄우고 설정해서 올릴 수 있다면 더욱 좋을 것이다.
Hive에 올리고, S3데이터를 연동하는 것은 어렵지 않은데, AWS glue를 사용하면 된다.
AWS glue에 hive table 이름, AWS S3에 상위 디렉터리 경로와 데이터 형태, 스키마를 넣어두면 알아서 hive 테이블에 데이터가 업로드 된다
또한 hive에서는 데이터에 제한을 두고 알아서 삭제하는 기능도 있다. 지금 형태로는 데이터 양이 과하게 적재될 수 있는데, 이를 지속적으로 비워주는 방식으로 관리할 수 있다
마찬가지로 S3 데이터도 cron/ lambda/ airflow 로 정기적으로 비워주는 작업이 필요하다
raw 파일을 DB에 올려서 관리하면 훨씬 잘 관리할 수 있지만, 역색인(inverted indexing)을 통해 특정 키값으로 더 데이터를 빠르게 호출하는 방법이 있다. 서버 설정이 훨씬 더 복잡하지만, 실시간으로 데이터를 빠르고 안정적으로 조회해서 고객에게 제공하기 위해서는 역색인 엔진이 필요하다. 이를 검색엔진이라고 한다.
위 스터디의 마지막 단계에서 유저가 직접 입력하는 부분 외에 데이터베이스에서 정보를 가져와서 모델에 넣어야 하거나 미리 계산해둘 수 있는 값이 있다면 이를 검색엔진에 넣어두고 활용할 수 있다.
실제 서비스에서는 유저 입력값과 검색엔진에서 가져올 사전검색된 값을 모델에 넣어서 결과를 출력해준다.
보통 hive DB에만 올려두면 백엔드 전문가가 서비스에 넣어주는게 일반적이다.