개요 에어플로우에서 작업이 실패했을 때 알 수 있는 방법은 Airflow 인터페이스 웹에 들어가서 확인을 하거나 email을 연동하거나 slack을 연동하는 등의 방법이 있다. 현재는 연동이 되어있지 않아서 작업에 실패하면 직접 들어가서 확인을 해야했는데, 이러면 알람이 늦어져서 조치가 어려워진다. 그래서 지금은 현재 사용하는 Slack과 연동을 해보려고 한다. - 이 문서에서 사용하는 에어플로우 버전은 2.0.0이다. Slack으로 메세지 보내는 방법 Airflow Operator 중에 slack으로 메세지를 보내주는 오퍼레이터가 있다. 자세한 내용은 이 링크를 참조하면 된다. 1. Airflow가 설치되어 있는 서버에서 apache-airflow-providers-slack 을 설치한다. python..

개요 mysql은 도커 컨테이너로 올라가있는 상태이고, 로컬에 볼륨이 공유된 상태로 사용하고 있었다. mysql에서 로그를 확인해보니 아래와 같은 로그를 확인할 수 있었다. 해결 방법 mbind는 리눅스 명령어로 메모리 범위에 대한 메모리 정책 설정을 뜻한다. mbind를 사용하는 명령어에서 권한이 없는 문제로 예상된다. 도커 공식 문서에 보면 아래와 같은 내용이 있다. --cap-add=sys_nice Grants the container the CAP_SYS_NICE capability, which allows the container to raise process nice values, set real-time scheduling policies, set CPU affinity, and other ..

개요 RDS에서 매일 생성되는 스냅샷으로 Athena에서 과거의 테이블을 사용할 수 있게 했다. 그러나 시간 문제가 두가지가 발생했다. 문제 첫 번째 문제 - 시간으로 필터할 수 없는 문제 S3에 데이터를 저장한 후 그대로 Glue로 크롤링 후 Athena에서 날짜로 필터해서 읽으려고 시도했다. 그러나 쿼리 결과가 비어있었다. Athena는 Java Timestamp 형식이 필요하다고 하는데, 데이터가 그렇지 않은 것으로 예상된다. 해결 방법은 다음과 같다. 열을 스트링으로 정의한다. YYYY-MM-DD HH:MM:SS.fffffffff 형식으로 변환한다. 쿼리에서 Presto의 날짜 및 시간 함수를 사용하여 DATE 또는 TIMESTAMP로 읽는다. https://aws.amazon.com/ko/pre..

개요 Presto는 페이스북에서 아주 많은 데이터를 빠르고 효율적으로 분석하기 위해 개발되었다. 페이스북에서는 300PB 규모의 데이터 웨어하우스에 쿼리할 때 사용하고 있으며 현재는 Airbnb와 Dropbox 등에서도 사용되고 있다. 다양한 소스를 지원해주는데 Hive, Cassandra, RDB, AWS S3 등에서 데이터를 읽을 수 있다. Hive는 처리할 때 중간 결과를 디스크에 저장하지만 Presto는 메모리에 저장하기 때문에 속도가 훨씬 빠르다. 하지만 리소스를 더 사용하게 된다. Architecture Presto는 하나의 Coordinator가 다양한 소스에서 데이터를 가져와 Worker에게 전달을 해주는 역할을 한다. 쿼리 처리 방법 클라이언트에서 Coordinator로 쿼리를 보낸다. ..

신뢰성 있는 데이터 전달 카프카는 웹 클릭 로그 수집, 신용카드 트랜잭션 등 다양한 방면에서 사용된다. 카프카는 신뢰성과 속도 등 사이에서 구성으로 유연하게 조절할 수 있다. 신뢰성 보장 1. 카프카는 메시지 순서를 보장한다. 2. 카프카에 메시지를 쓸 때 리플리카에 메시지를 복제하는 작업의 구성으로 신뢰성을 조절할 수 있다. 만약 acks 를 높게 두고 요청에 실패했다면 프로듀서에서 다시 재시도 할 수 있다. - acks = 0 메시지를 보내고 확인을 하지 않는다. - acks = 1 리더가 메시지를 썼는지 확인한다. - acks = all 모든 동기화 리플리카에 복제되었는지 확인한다. 3. 최소한 하나의 리플리카가 살아있다면 메시지는 유실되지 않는다. 4. 컨슈머는 모든 리플리카에 커밋된 메시지만 읽..

About 카프카의 내부를 다 이해할 필요는 없지만 어느정도 알아두면 좀 더 최적화하거나 문제가 발생했을 때 해결하는데 도움이 된다. 내부 매커니즘 클러스터와 주키퍼 컨트롤러 브로커 중 하나이고 리더를 선출해야하는 역할을 가지고 있다. 클러스터를 시작할 때의 첫 번째 브로커가 컨트롤러로 임명된다. 모든 브로커는 시작될 때 주키퍼에서 /controller 노드가 없으면 생성하려고 한다. 컨트롤러 브로커에 문제가 생기면 카프카의 Watch가 브로커들에게 컨트롤러가 사라졌다고 알려준다. 그러면 브로커들은 /controller 노드를 생성하려고 시도한다. 첫 번째로 생성한 노드가 컨트롤러가 되며 새로운 세대 번호를 받게 된다. 브로커들은 새로운 세대 번호를 알게 되고, 이전 세대 번호의 브로커에서 명령이 오면 ..