2.4 ETL과 데이터 웨어하우스와의 관계
데이터 웨어하우스 : 분석 용도로 구조화된 순수한 통합 데이터 저장소
데이터 웨어하우스 방법론 : 데이터베이스에서 주기적으로 덷이터를 추출하여 사람이 이해할 수 있는 형태로 변환 후 중앙 데이터 웨어하우스에 적재
중앙 데이터 웨어하우스 : 모든 데이터의 순수한 사본을 취합하므로 집약적인 분석과 처리를 위한 엄청난 가치를 지닌 자산
데이터 웨어하우스는 경이로운 자산 But 시대에 조금 뒤떨어져 있음
순수한 통합 데이터와 데이터 웨어하우스 간 결합도가 높은 것이 문제!
데이터 웨어하우스 : 배치 쿼리 인프라의 한 부류로 갖가지 유형의 리포팅, 애드혹 분석, 단순한 카운팅, 집합, 필터링에는 잘 맞는다. 하지만 실시간 피드(실시간처리, 검색 인덱싱, 모니터링 시스템)에는 배치 시스템이 완전시 순수 데이터를 보관하는 유일한 저장소는 될 수 없음
ETL은 2가지 역할
- 사내 시스템 곳곳에 묶여있는 데이터를 끌어내서 시스템에 특정한 무의미함을 제거하는 데이터 추출과 정리 프로세스
- 관계형 데이터베이스의 타입 체계에 맞춰진 스타 스키마,눈 송이 스키마로 강제 변환된 고 성능 컬럼 포맷으로 나뉜 데이터 웨어하우스 쿼리에 맞게 데이터 구조를 조정한다.
문제는 2가지 역할을 융합하는 것
다른 실시간 저장소 시스템의 인덱싱과 신속한 처리를 위해 순수한 통합 데이터의 저장소는 실시간적으로 사용할 수 있어야 한다.
2.5 ETL과 조직 확장성
데이터 웨어하우스 팀의 고질적인 문제 : 다른 팀에서 만들어진 데이터를 모두 취합해서 정제해야 할 책무가 따른다는 점
데이터를 추출하여 구조화된 형식으로 변환 후 중앙 파이프라인에 전송하는 문제를 시스템 설계/구현 일부분으로서 반드시 고려해야 한다
이렇게 하면 통합의 구심점을 형성할 수 있어 웨어하우스 팀원들은 저장 시스템의 신규 추가 업무에서 벗어날 수 있고, 단지 중앙 로그에서 구조화된 데이터 피드를 적재하고 특정 시스템에 맞는 변환 작업 등을 처리하면 됨
이런 확장성은 전혀 다른 개념의 데이터 시스템을 추가할 때 특히 좋음
2.6 어느 시점에서 데이터 변환을 수행하는가
데이터 변환 시점 3가지
- 데이터 생성 측에서 전사 로그에 데이터를 추가하기 전 수행한다
- 로그에서 실시간으로 수행한다(변환된 로그를 새로 생성)
- 목적지 데이터 시스템에 적재하는 과정의 일부로 수행
젤 좋은 방법은 데이터를 로그에 내보내기 전, 만들어낸 부서에서 처리
실시간 환경에서 값이 부가되는 변환은 원천 로그 피드를 후처리 하는 식으로 이루어져야 한다. 이를테면 이벤트 데이터를 세션화한다든지, 다른 이랍ㄴ 파생 필드를 추가할 수도 있을 것. 원래 로그는 그대로 남아있는 상태에서 이렇게 실시간으로 처리하면, 증강된 데이터가 포함된 파생 로그가 만들어진다.
어떤 목적지 시스템에만 해당되는 데이터 통합은 적재 프로세스의 일부로 수행되어야 한다. 데이터 웨어하우스에서 분석과 리포팅을 하려고 특정한 스타 스키마나 눈송이 스키마로 데이터 변환을 하는 것. 전통적인 ETL 처리와 자연스레 겹치는 이 단계는 훨씬 순수하고 더욱 균일한 스트림 세트에 대해 수행되며, 아주 단순화되어야 함
2.7 시스템 간 결합도를 낮춤
결합도가 낮은, 이벤트 구동 시스템의 부수적인 효과 : 읽고 정리하기
웹 업꼐에서는 보통 텍스트 파일로 로그를 남겨두고 이를 데이터 웨어하우스에서 퍼갈 수 있게 하거나 하둡으로 통합 쿼리를 하는 식으로 활동 데이터에 접근
이럴 경우 문제는 데이터 흐름이 데이터 웨어하우스의 능력과 처리 스케줄에 영향을 받는다는 점
카프카 : 로그 중심적인 방식으로 이벤트 데이터 처리 시스템.
카프카를 사용해 중앙의 다중 구독자 이벤트 로그로 삼았고, 특정 유형의 액션에 대한 고유 속성을 담고 있는 수백가지 이벤트를 정의 함.
이럴 때의 장점은 채용 정보 표시 페이지는 단지 채용 정보를 보여주고 관련 속성 및 기타 유용한 정보를 기록하는 데 전념하면 됨. 다른 유관 시스템들은 피드를 구독해서 각자의 역할에 충실한다. 채용 정보 표시 페이지의 코드는 이 시스템들의 존재를 신경 쓸 필요가 없고, 새로운 데이터 소비 시스템을 추가할 때에도 전혀 변경되지 않음
2.8 로그 확장
다의 구독자가 실시간으로 바라보는 기록 장치로써 로그를 유지하려고 할 때, 확장성이라는 중대한 문제애 봉착함. 실제 사용할 만한 정도로 빠르고, 비용이 적게 들고, 확장성이 좋은 로그를 구축할 수 없다면 로그를 만병통치약쯤으로 생각하는 건 우아한 환성에 지나지 않는다.
분산 시스템을 하는 사람들의 분산 로그에 대한 생각 : 느리고 무거운 추상체
하지만 대량의 데이터 스트림을 이록하는 데 초점을 두고 세심하게만 구현한다면 꼭 그렇지 않음.
카프카에서 대용량 로그를 위한 트릭
- 로그 파티셔닝
- 읽기/쓰기를 한꺼번에 처리함으로써 throughput 최적화
- 불필요한 ‘데이터 복사’ 제거
수평적 확장을 위한 로그를 파티션으로 나눔
각 파티션은 완전히 정렬된 로그지만 파티션들 간의 전역 정렬은 하지 않음.
작성자는 메시지 할당의 제어권을 특정 파티션에게 넘김, 대부분은 유저 ID 같은 데이터를 키로하여 파티션을 고름. 샤드 사이에 별도의 조정 없이도 파티셔닝으로 로그를 추가할 수 있고, 시스템 스루풋은 샤드 키 내에서 정렬이 유지되는한 카프카 클러스터의 크기에 선형 비례하여 확장
각 파티션은 설정 가능한 개수의 사본 전부로 복제되어 파티션 로그와 같은 사본을 갖음. 단일 파티션이 리더로 작동하다가 장애가 발생하면 언제대로 다른 사본 중 하나가 바통을 이어 받음(엘라스틱서지 클러스터랑 같네)
전역 정렬이 없는 것이 한계일 수 있으나 그리 중요한 문제는 아님. 실상 로그와의 상호 작용은 대게 수백, 수천 개의 프롤세스에서 일어나므로 이들의 행위를 순서에 따라 나열하는 건 큰 의미가 없다. 대신 각 파티션별로는 확실한 순서가 유지되기 때문에 카프카에서 같은 송신자로부터 전송된 메시지는 반드시 전송된 순서 그대로 특정 파티션에 추가됨
로그는 파일 시스템과 같이서 선형적인 읽기/쓰기 패턴에 대해서는 최적화하기 쉬움. 로그는 작은 읽기/쓰기를 묶어서 더욱 큰 규모의 대용량 처리 프로세스로 통합 가능. 카프카는 이런 최적화를 아주 공격적으로 수행. 1. 클라이언트에서 서버 방향으로 데이터를 보내거나 디스크에 쓸 때, 2. 서버간 복제가 이루어지거나 사용자에게 데이터가 전송될 때, 3. 커밋된 데이터 수신을 확인하는 과정은 배치로 처리
마지막으로, 카프카는 인-메모리 로그, 온-디스크 로그, 인-네트워크 데이터의 전송 과정에서 유지되는 간단한 바이너리 포맷을 사용함. 그러므로 비복사 데이터 전송 등 여러가지 최적화 기법을 활용할 수 있음
