ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • Naver Deview 2020 시청 및 정리
    개발하면서/타인글보면서 2021. 1. 11. 09:42
    반응형

    Deview 2020에서 개인적으로 흥미가 있는 영상들을 보고 정리했다..
    발표에서 어떤 방법으로 얼마큼의 이득을 얻었는지 얘기한 것도 좋았지만
    과거에 갖고 있던 문제들을 설명하고 대안들을 나열하며 여러 대안들 중 현재 상황에서
    균형 잡힌 선택을 하는 일련의 과정들이 재밌고 고마웠다.

    문제를 해결하는 것의 다음 단계는 문제를 정의하고 해결하는 거라고 회사 어느 분이 얘기해준 게 갑자기 생각나네... 허허허

     

     

    손쉽게 ML 라이프사이클을 다룰 수 있는 MLOps

    https://tv.naver.com/v/16970565
    . AI 연구자와 엔지니어의 관점 차이와 모델 표준화의 장점
    Saved Model(TF), ONNX(Pytorch)
    . Model Registry
    모델의 부가정보(meta)를 저장, 모델 파일은 HDFS에 저장
    AI 연구자와 엔지니어를 연결해주는 도구
    자체 개발한 InferenceClient를 이용하여 서빙(모델 서버 찾아주고 에러 처리 및 LB 기능)
    argument는 Model name, version, environment
    Inference Server(모델 파일 서빙)와 Inference Manager(모델 부가 정보)

    . Validation
    모델 변경 시 인퍼런스가 잘못되는 것을 방지하기 위해
    사람의 개입 없이, 그리고 잘못되었다는 판단은 production과 staging의 인퍼런스 비교
    Inference Client와 Inference Server 사이에 Validator를 추가한 후 비교

     

     

    Kubernetes를 이용한 효율적인 데이터 엔지니어링
    (Airflow on Kubernetes VS Airflow Kubernetes Executor)

    https://tv.naver.com/v/16969998/list/657024

    . Airflow의 전반적인 설명
    . Airflow on K8S의 장/단점
    쉬운 deploy, docker가 키메라가 된다 ㅋㅋ, pod 상주(모니터링)

    . K8sExecutor & K8sOperator
    일반 Operator와 K8sOperator 차이 설명
    일반 Operator는 Airflow Worker Pod에서 실행
    K8sOperator는 Airflow Worker Pod에서 개발자가 정의한 CustomPod을 실행

    . Tip CeleryExecutor와 K8sExecutor 차이, Dag Volume은 외부(S3, NFS 등)로 마운트 추천
    . 오픈소스에 KST timezone 반영!!, ssh secret variable contribute
    CustomPod 공통 로직 (커버로스 인증, 정책[/etc/hosts)&비즈니스로직 실행, Argument cli 실행)
    . Spark ClientMode에서 Docker HostNetwork 활성화하여 사용

     

     

    Luft:10초 만에 10억 데이터를 쿼리 하는 데이터스토어 개발기

    https://tv.naver.com/v/16969997/list/657024

    . Go로 개발되었고 마스터/히스토리/리얼타임 노드로 구성 Lambda architecture
    . 유저와 이벤트 발생 시각으로 partition
    . 우리의 문제를 해결할 수 있는 기존 솔루션 차용 -> 우리 문제를 왜 못 푸는가? -> 이젠 무엇이 바뀌어 풀 수 있냐?
    어떠한 선택을 하기까지의 흐름 공유가 좋았음
    . TrailDB
    높은 압축률, User 이벤트 특성을 반영, delta-encoding, dictionary-encoding, edge-encoding, 허프만 코드 효율 UP(row-based), 수정 불가(immutability), Simplicity(sharding, query 기능 없음)
    . LLVM jit으로 쿼리 엔진, LRMR(M/R을 Go로 작성, pull-based event stream)
    . sharding = 히스토리 노드
      Lev1 Vanilla Sharding Round Robin 문제점. Rebalance, Time Decay, Eviction 등의 정책 니즈가 제기됨
      Lev2 Cost Function을 사용.
        Cost가 제일 낮은 노드에 파티션 배치. 두 날짜 범위가 가깝고 겹칠수록 코스트를 높게 하면 된다. Druid 공식 차용
    . etcd liveness Probe 패턴과 S3에 파티션 저장, DynamoDB에 파티션 목록 저장/관리 Availability 유지,
    . To-be
      고도화된 Group, Join Query 기능, Support Spark, Luft Open Source!!!
      TrailDB 대체할 자체 Column Store, 우리 데이터에 최적화된 데이터 스토어 설계, Bitmap Index, Bloom Filter, SIMD

    반응형

    댓글

Designed by Tistory.