목록Data Engineering & DataOps (35)
without haste but without rest
DAG Runs — Airflow Documentation airflow.apache.org 에어플로우 스케줄러는 마지막 데이터 간격 이후에 실행되지 않았거나 지워진 데이터 간격부터 DAG를 실행한다. 이 컨셉을 Catchup이라고 부른다.
환경 MacOS: Monterey 12.1 IntelliJ: 2021.03.01 Java: 8 sbt: 1.6.0 Scala: 2.12.0 Spark: 3.1.2 1. Intellij 플러그인에서 스칼라 설치 scala 플러그인을 설치한다. (맥 os 기준으로 인텔리제이에서 쉬프트를 두번 누르면 검색 탭이 나타나는데 plugins를 검색해서 진입할 수도 있다. ) 2. 스칼라 프로젝트 생성 구글링 해보니 메이븐으로 생성하기도 하던데 스칼라 공식 도큐먼트에서는 sbt 기준으로 설명을 해서 sbt로 진행했다. sbt란 무엇인가? sbt (software) - Wikipedia From Wikipedia, the free encyclopedia Jump to navigation Jump to search Op..
https://zeppelin.apache.org/docs/0.10.0/quickstart/docker.html
빅데이터를 지탱하는 기술, 니시다 케이스케 데이터 중복과 멱등한 조작 빅데이터를 다루는 시스템에서는 어느정도 중복을 허용하는 경향이 존재한다. 데이터 센터와 같은 안정된 회선의 경우 99% 이상의 신뢰성을 확보할 가능성이 높다. 따라서 이 정도의 오차는 허용하고, 멱등한 조작에 유의해서 중복 데이터가 생기더라도 문제가 되지 않는 시스템을 설계한다. (다만 과금 처리 같이 오차가 허용되어서는 안되는 경우는 트랜잭션 처리를 지원하는 데이터베이스를 사용하고, 이후에 벌크로 데이터를 전송해서 중복과 결손을 확실하게 피한다.) Exactly-once 의 단점 데이터 전송을 주고 받는 두 노드가 분산 코디네이터에 의존한다. 그러나 코디네이터에 장애가 발생하는 경우도 있으며, 이에 의존하기 때문에 성능과 트레이드하게..
빅데이터를 지탱하는 기술, 니시다 케이스케 Workflow Management 데이터 관리를 자동화하고 안정된 배치 처리를 실행하기 위해 워크 플로우 툴을 사용한다. 워크 플로우 툴은 정기적으로 태스크를 실행하고 비정상적인 상태를 감지하여 해결을 돕는 것이 목적이다. 워크로드 오류로부터 복구하는 방법 2가지 재시도 - 단순한 재실행 백필(backfill) - 일정 기간의 플로우를 연속해서 실행하는 구조 백필은 주어진 날짜 파라미터를 기준으로 일정 기간의 플로우를 다시 실행한다. 오류로 인해 태스크를 재실행 해야하거나 혹은 새롭게 만든 워크플로를 과거로 거슬러 올라가 실행해야할 때 사용한다. 만약 태스크가 업데이트가 되어서 한 달 전 데이터 부터 오늘 만든 새로운 태스크를 적용해야 한다고 가정해보자. 이전..
아파치 카프카 애플리케이션 프로그래밍 with 자바 Kafka Connect 카프카에 기본적으로 포함되어 있는 애플리케이션이다. 프로듀서, 컨슈머 애플리케이션을 직접 개발할 필요없이 템플릿 기반으로 사용할 수 있다. source, sink에 대한 플러그인은 confluent hub에서 검색해서 찾을 수 있다. 1. 아키텍처에 대한 간단한 요약 유저가 커넥트에 커넥터 생성을 요청하면 커넥트는 내부에 커넥터와 태스크를 생성한다. 커넥터는 태스크를 관리하고, 태스크는 커넥터에 종속되는 개념으로, 데이터를 처리를 담당 한다. 유저는 Converter와 Transform 기능을 옵션으로 추가할 수 있다. 컨버터는 데이터 처리를 하기 전에 스키마를 변경하도록 돕는다. JsonConverter, StringConve..
아파치 카프카 애플리케이션 프로그래밍 with 자바 MirrorMaker2 서로 다른 두 개의 카프카 클러스터 간 토픽을 복제하는 애플리케이션이다. (카프카 binary 디렉토리 내에 mirrormaker를 확인할 수 있다.) 프로듀서, 컨슈머 단에서 미러링을 구현할 수도 있지만, 파티셔닝 정보가 변경되는 등의 로직을 직접 구현하는 것이 쉽지 않다. 미러메이커2는 토픽의 데이터를 복제하고 설정까지도 복제해서 파티션의 변화, 토픽 설정값의 변화도 동기화하는 기능을 제공한다. + 미러메이커1은 복제하기 전 데이터와 복제된 데이터의 파티션 정보가 달랐으며 복제하는 토픽이 달라지면 수정하기 위해 애플리케이션을 재시작해야 했다. 또한 exactly-once 를 보장하지 못했다.
Message Key 카프카 브로커에 메세지를 전송할 때 Topic, Key, Value 값을 보내게 된다. 이때 토픽과 밸류는 직관적이지만 키가 굳이 필요한 이유에 관해서 궁금했다. 왜 쓰는 걸까? Key는 메시지의 종류를 나타날 때 사용하고, 데이터의 처리 순서와 밀접한 관련이 있다. 동일한 키를 동일한 파티션으로 보내는 것이 주요한 목적이다. 간단한 예시로, 토픽의 파티션 개수가 2개 이상이 되는 순간 오프셋의 순서를 보장할 수가 없다. 따라서 트랜잭션 데이터의 순서가 뒤바뀔 수 있는 위험이 존재한다. 이때 레코드의 Primary와 같은 고유값을 키로 이용한다면 동일한 파티션으로만 전송하게 되므로 특정 파티션의 바틀넥 현상에 의해서 순서가 역전되는 문제를 회피할 수 있다. 예를 들어서 uuid가 0..