빅데이터를 지탱하는 기술 독후감

데이터를 다루는 조직으로 옮긴 뒤, 화면에 값을 표시하는 것만으로는 제품을 충분히 이해하기 어렵다고 느꼈습니다. 어떤 데이터가 어디에서 왔고, 무엇과 연결되며, 어떤 과정을 거쳐 화면의 숫자가 되는지 알고 싶어 《빅데이터를 지탱하는 기술》을 읽었어요.

기존 네 편의 장별 노트는 기술 이름이 많이 나열돼 있었습니다. 이번에는 수집에서 시각화까지 데이터가 이동하는 순서로 다시 묶었습니다.

데이터는 한곳에 모인 뒤에도 일이 남는다

빅데이터 환경은 단순히 저장 공간을 크게 만드는 문제가 아니었습니다. 업무 시스템의 정형 데이터, 로그와 파일 같은 비정형 데이터가 서로 다른 속도와 형식으로 들어옵니다. 분석하려면 원본을 보존하면서도 질문에 맞는 형태로 가공해야 해요.

데이터 레이크는 다양한 원본을 받아두는 곳, 데이터 웨어하우스는 분석 가능한 구조와 품질을 갖춘 곳, 데이터 마트는 특정 목적에 맞게 좁힌 결과로 이해했습니다. 실제 시스템에서는 경계가 더 복잡할 수 있지만 역할을 구분하면 문제의 위치를 찾기 쉬워집니다.

분석 화면에서 자주 보는 행과 열의 집계도 그 전에 준비가 필요합니다. 이벤트나 거래에 속성을 붙이기 위해 룩업 테이블을 결합하고, 필요한 단위로 집계한 뒤, 시각화 도구가 빠르게 읽을 수 있는 데이터 마트를 만듭니다.

이 과정에서 중요한 것은 차트를 먼저 고르는 일이 아니라 지표의 정의를 고정하는 일입니다. 같은 “매출”도 취소·환불, 세금, 집계 시점에 따라 값이 달라질 수 있어요. 데이터 마트는 계산을 빠르게 하는 동시에 조직이 같은 정의를 보게 만드는 계약이 됩니다.

업무 시스템은 한 행의 여러 값을 함께 읽고 쓰는 일이 많지만, 분석은 많은 행에서 몇 개 열만 읽어 합계나 평균을 계산하는 경우가 많습니다. 열 지향 저장소는 같은 열의 값을 모아 읽고 압축하기 때문에 이런 분석 접근에서 디스크 I/O를 줄일 수 있습니다.

MPP 데이터베이스는 처리를 여러 노드로 나눠 병렬 실행합니다. 성능은 노드 수만 늘린다고 선형으로 좋아지지 않아요. 데이터가 어떻게 분산됐는지, 특정 키에 값이 몰리는지, 노드 사이 이동이 얼마나 발생하는지가 함께 영향을 줍니다.

원문에는 Hadoop, Impala, Presto와 Spark가 등장했습니다. 개별 제품의 최신 위치를 설명하기보다 당시 책에서 구분한 역할만 남깁니다.

도구 이름보다 데이터의 양, 처리 지연 허용치, 질의 패턴, 운영 인력이 선택을 좌우합니다. 작은 데이터에는 단순한 데이터베이스와 배치가 더 적합할 수도 있어요.

화면의 숫자가 이상할 때 렌더링 코드만 보면 원인을 놓칠 수 있습니다. 수집이 늦었는지, 집계 기준이 달라졌는지, 데이터 마트가 갱신되지 않았는지, 시각화에서 단위를 잘못 표시했는지 단계별로 질문해야 해요.

이 책을 읽고 얻은 가장 큰 변화는 기술 목록이 아니라 데이터 계보를 묻는 습관이었습니다. “이 숫자는 어디에서 왔고, 어떤 정의와 시간 기준으로 만들어졌으며, 다시 계산할 수 있는가?” 이 질문이 데이터 제품을 이해하는 출발점이 됐습니다.