기존 시스템의 한계와 개편 필요성시스템 개편을 하면서 새로운 아키텍처를 구상해야 하는 과제가 있었습니다.오랫동안 DB 링크와 트리거 기반의 데이터 연계 시스템(ESB)을 운영해 왔었는데, 기존 방식은 다음과 같았습니다.Source DB → A DB 채널 → A DB target table ├── → B DB 채널 → B DB target table └── → C DB 채널 → C DB target table 해당 데이터 연계를 진행하려면 복잡한 단계를 거쳐야 했습니다:트리거 작성로직 체크(INSERT/UPDATE/DELETE 구분)비즈니스 로직 구현 (최대한 지양했지만 불가피한 경우 존재)소스 DB와 타겟 DB의 Getter/Setter 생성각 DB별 접속 및 데이터 ..

대용량 데이터를 전송할 때 사용하는 여러가지 방법이 있는데 그 중 하나가 Message Queue를 이용한 방법이 있습니다. 요즘 카프카가 대세다, 대용량 데이터를 처리하는 방법 등등 이런 헤드라인으로 시선을 사로잡는 광고들이 많이 보였습니다. (이미 현업에서도 많이 사용 중이지만...) 저도 데이터를 만지는 사람으로써 이런 기술들에 대한 니즈가 있긴 하지만 당장에 내 상황에 필요한 기술인지 아닌지에 대해 판단도 못 하겠고, 왜 MQ나, Kafka 같은 것들을 도입하여 사용하는지 어떤 상황에 맞게 쓰는 게 맞는지 근본적인 의문을 풀어보고자 이 글을 작성하게 되었습니다. 이 글은 제가 공부하면서 정리하고 적어 보는 거니 완전히 믿으시면 안 됩니다....! (밑밥깔기) Message Queue란 무엇인가? ..

9/7~9/14 1단원 나온 질문들 질문1. 데이터 수집은 벌크(bulk)형데이터, 스트리밍(Streaming)형 데이터로 구분되는데 스트리밍형 데이터 수집을 할때 Message Queue를 쓰는 Kafka 를 쓰거나, Spark Streaming을 쓰는 기업으로 구분되는것같은데 두개의 차이는 무엇일까요?? 카프카는 실제로 데이터를 저장하는 것은 아니고, 데이터를 저장을 하는데 데이터 발생하는 주기가 너무 짧은데 저장할 수 없을 경우에는 큐에 쏘아놓고, 큐에 저장하는 게 카프카가 하는 일이고 (초당 데이터가 너무 빨리 발생할 때 큐에 저장할 때) 카프카는 데이터나 형변환을 할 수 있음. 중간 단위의 처리도 가능하기 때문에 데이터가 유실이 되지 않아야 할 때 많이 씀. 주 목적은 데이터 유실을 막고 큐 형..

airflow는 파이썬으로 동작한다. airflow 설치 데이터 파이프라인을 dag라고 부른다 - ETL을 파이썬 코딩으로 구현된 코드 그 DAG는 task의 집합임. airflow는 하나의 서버로 구성되지만 job의 수가 늘어나면 서버를 더 세팅해야 함. 다수의 서버로 airflow 클러스터를 운영할 수 있음. airflow 클러스터 형태로 구성이 된 airflow를 쓰고 싶으면 클라우드 서버를 쓰는 것이 낫다. 서버가 많으면 많을 수록 그 위에서 돌릴 수 있는 dag가 많아지는 것임. 이 서버가 무슨 이슈로 안 돌아가면 airflow를 쓸 수 없어서 문제가 있을 수 있다. 내부 DB 필요함 -> history 기록용 sqlite에 dag 정보를 기록함 < 이걸 쓰면 개발하기 힘들고 보통 postgre..