Please enable JavaScript.

Coggle requires JavaScript to display documents.

빅파이 운영 (정규처리 (신규채널 추가하기 (채널이 추가되는 순간부터 ETL 시에 nlog/channel_name 경로에 데이터 생성…

- - - - 신규 채널인 경우 채널 포맷 추가
      - 타임존 설정 추가 (kst인 경우 패스),
        타임존 설정을 추가할 때 regdatetime에 대한 클렌징 룰도 추가되어야 함
      - 클렌징 룰 추가 (default와 동일한 경우 패스)
      - 채널 설정 추가 (전달하고자 하는 채널의 서버/계정 정보 기입)
      - 플랫 룰 추가 (default와 동일한 경우 패스)
    - - 스케줄매니저 커맨드 수행 :
        /etl/scheduleManager.sh -command create -type etl -path /home/web_admin/airflow/dags -start 2019,3,26 -gameCode banana
      - 기본 생성되는 스케줄 스크립트에는 메시지 알람 / 재시도 설정이 없으므로, 수동으로 추가해준다.
        contacts:"kjh3477@netmarble.com,magefister@netmarble.com",
        default_settings:{retries:2,retry_delay:300,trigger_rule:"all_success"},
  - - - https://wiki.nmn.io/pages/viewpage.action?pageId=98206037
- - - - extract - cleanse - validate - filter/flat/mapping - formatting(tsv, json, orc..) - save
    - - 위 단계 각각은 인터페이스로 연결되어 있고,
        각 단계 별 인터페이스를 구현하여 기능 확장 가능함
  - - - transfer : nlog를 채널 스토리지로 전송
      - load : 전송한 파일을 임시 테이블에 로드
      - append : 임시 테이블의 데이터를 메인 테이블에 추가
      - clean : 전송한 파일을 삭제 또는 그외 정리 작업 진행
    - - 새로운 채널/스토리지로 전달 시 위 인터페이스를 구현하면 됨
      - ChannelDao, DeliveryService 인터페이스로 동작함
      - 각 단계는 별도의 프로세스로 수행되며
    - - transfer - load - append - clean 단계로 구성됨
  - - - 코드는 순수한 프레임워크 상태를 유지
      - 안바뀌는 코드라도 최소한 베이스 코드랑은 분리하자
      - strategy pattern으로 대부분 구현되었으므로 참조하여 진행할 것 (if else 떡칠 노노)
      - 목적 달성에 필요한 기능 모듈은 최대한 잘게 쪼개고, 플러거블한 상태를 유지하며
      - 위 모듈을 조립한 서비스 클래스를 별도로 제공한다. (facade pattern 참조)
    - - ETL 작업에 필요한 절차들을 최대한 쪼개고 추상화시킴
      - 최종 목적을 달성하기 위한 특정 절차는 인풋 소스 / 아웃풋 채널에 따라 달라질 수 있으므로
        동일한 플로우에 대해 세부적인 전략만 변경되어 수행될 수 있는 구조를 가져감
      - 메타 데이터에 대한 관리도 전체 요구사항을 포괄할 수 있는 일반적인 용어로 정의하고 관리하기 위해 주의를 기울임
        ex) 빅쿼리, MSSQL, MySQL, Hive 등 여러 채널의 공통점 -> 테이블 및 DB에 대한 설정 / 파일 및 스토리지에 대한 설정으로 나뉨
  - - - snapshot, create, remove, check, merge 기능으로 구성됨
      - snapshot : mconsole에 정의된 스키마 정보의 스냅샷을 TB_GameLogDailySnapshot 테이블에 생성
      - create : 채널에 테이블을 생성 / remove : 채널에 생성된 테이블을 제거
      - check : 스냅샷을 갱신하고, 테이블을 생성 (default : 스냅샷이 있으면 갱신 안하고, 테이블은 없으면 생성)
  - - - Simplicity :
        Make it easy for new engineers to understand the system,
        by removing as much as complexity as possible from the system.
        (Note this is not the same as simplicity of the user interface.)
      - Evolvability :
        Make it easy for engineers to make changes to the system in the future,
        adpating it for unanticipacted use cases as requirements change.
        Also known as extensibility, modifiability, or plasticity.
      - https://www.amazon.com/Designing-Data-Intensive-Applications-Reliable-Maintainable/dp/1449373321
      - Operability :
        Make it easy for operations teams to keep the system running smoothly.
      - Good operability
        
        Good operability means making routine tasks easy,
        allowing the operations team to focus their efforts on high-value activities.
        Data systems can do various things to make routine tasks easy, including:
        
        • Providing visibility into the runtime behavior and internals of the system, with good monitoring
        
        • Providing good support for automation and integration with standard tools • Avoiding dependency on individual machines (allowing machines to be taken down for maintenance while the system as a whole continues running uninterrupted)
        
        • Providing good documentation and an easy-to-understand operational model (“If I do X, Y will happen”)
        
        • Providing good default behavior, but also giving administrators the freedom to override defaults when needed
        
        • Self-healing where appropriate, but also giving administrators manual control over the system state when needed
        
        • Exhibiting predictable behavior, minimizing surprises
- - - - 시스템 안정화 및 리소스 확보 후 재시도
    - - 로그 분석 후 원인 규명
        파싱 실패인 경우 로직 개선
    - - 채널 안정화 이후 재시도
      - 알려진 케이스
        1) bi dw (mssql) disk full
        2) bigquery slot full
    - - 스토리지 안정화 이후 재시도
- - - - 각 채널 별 어떤 게임을 어떤 서버로 넣을 것인지 설정
    - - 각 채널 별 어떤 게임의 어떤 로그/필드를 제공받을 것인지 설정 (별도 필터링 안할 경우 설정 안해도 됨)
    - - 각 채널 별로 데이터를 어떤 포맷으로 제공받을 것인지 설정
    - - 각 게임 별로 어떤 타임존으로 데이터를 제공받을 것인지 설정
      - datalake에는 수집기에서 기록한 kst 시간을 기준으로 적재됨
      - utc로 제공받도록 설정할 경우 0~8시 데이터는 이전날 테이블로 전달됨
    - - nlog 생성 시 원본에서 key 를 변형하는 규칙을 설정
    - - nlog 생성 시 원본에서 value 를 변형하는 규칙을 설정
  - - - 공통 로그 항목 / 게임 별 기본 상세 로그 항목 설정
    - - 채널 / 게임 별 mconsole에 정의된 상세 로그 항목에 대한 일자별 스냅샷 저장
  - - - 게임 무관하게 공통으로 수행되어야 하는 스케줄을 설정
    - - 각 게임 별 스냅샷/테이블 생성 - nlog 생성 - 채널 별 전달 등의 스케줄을 설정
    - - 각 게임 별 재처리 스케줄을 설정
- - - - 고도화 포인트 : 재처리 스케줄도 스케줄매니저를 통해 생성할 수 있는 기능 추가하기 (재처리 방식은 다양할 수 있으므로 사실 의미가 약하여 미진행함)
        /etl/scheduleManager.sh -command reprocess -path /home/web_admin/airflow/dags/reprocessing -gameCode banana -s 2018-05-01T00:00:00 -e 2018-05-25T23:50:00 -reprocStartStep nlog_create -reprocChannels -reprocHourly true
      - 고도화 포인트 : 모니터링 대상 서버의 상태를 체크하여 스케줄 생성을 제한하는? (최대한 단순하게.. 복잡해질 것 같으면 안하는게 낫다)
      - 주의 : concurrency, max_active_runs 설정할 때 아래 작업 병행
        airflow 장비, submit 장비, yarn cluster, bigquery slot 리소스 모니터링
      - 처리 대상 기간의 기존 테이블 삭제 (있다면) + 스냅샷 갱신 / 테이블 생성 일괄 수행
        주의 : 박파이 커맨드에서 넘기는 일자/시간 파라미터는 무조건 datalake 적재 기준 즉, kst 기준이고, (nlog 가공 전 단계의 regdatetime 값)
        이 값을 기반으로 설정값을 읽어오게 되므로 게임별 타임존에 맞게 입력해주어야 함 "아래 구문의 의미는 20180518 09 00 데이터를 적재할 테이블을 제거/생성 한다." 정도로 이해할 수 있음
        /etl/deliveryManager.sh -command remove -yyyymmdd 20180518 -hh 09 -mm 00 -srcType hdfs -gameCode banana -channels bigquery
        /etl/deliveryManager.sh -command check -yyyymmdd 20180518 -hh 09 -mm 00 -srcType hdfs -gameCode banana -channels bigquery
  - - - 그냥 airflow clear -cdf -s start_datetime -e end_datetime -t taskid dagid
      - 대부분의 채널 타입 별 연산들은 연산의 전처리/후처리 과정에서 idempotence 를 보장
    - - 1주일 이내의 테이블 재처리 시 아래 절차로 수행 가능 (bigquery temp dataset 보관 기한이 7일)
        1) 일자별 테이블 삭제
        2) 일자별_temp 테이블 문제 구간 재적재
        3) 일괄 머지하여 일자 테이블 생성
      - 빅쿼리 케이스는 파티션 스위치가 안되어 append 재실행시 중복 적재됨