ABOUT ME

-

인기 태그


kafka elastic_search redis
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

    댓글 0

Designed by Tistory.