수 백 테라바이트의 데이터를 가진 큰 회사부터, 비교적 작은 사이즈의 데이터를 이제 쌓기 시작한 회사까지 많은 회사들이 데이터 웨어하우스 및 데이터 레이크를 구축하고 있다. 사실 데이터의 중요성은 말할 것도 없을 듯. 가만히 있어도 여기저기 빅 데이터, 마이 데이터 이야기가 들리고 AI나 머신러닝 등의 기술들을 쓰기 위해서는 데이터 필수 요소이다.
데이터를 쌓았으면 활용을 해야한다. 많은 유즈케이스들이 있는데, 보통 비즈니스 의사결정에 필요한 지표를 뽑는 것으로 시작을 한다. 좀 더 고도화 된 곳들은 쌓아 놓은 데이터를 조회하는 것에 그치지 않고 머신러닝 관련 기술들을 활용해서 프로덕트에 새로운 피쳐로 적용하고, 인하우스 툴들로써 활용하고, 그 외 다양한 방법으로 비즈니스에 적용할 수 있다.
좀 더 개인적인 이야기를 덧붙이자면, 지금 내가 있는 회사는 빅쿼리 기반으로 데이터 웨어하우스를 구축하고 사용한 지 만 3년이 되어간다. 그 동안 많은 히스토리컬 데이터가 빅쿼리에 쌓여있는 상황이고, 이를 이용해서 머신러닝을 통해 많은 문제들을 해결하고 있다.
하지만 많은 데이터가 쌓여있는 곳에 다양한 사용처가 생겨남에 따라 그로 인해 문제점들이 스멀스멀 생겨나기 마련이다.
데이터 퀄리티
데이터도 시간이 지남에 따라 지속적으로 변화할 수 있고, 그에 따라 데이터 퀄리티가 떨어지는 경우를 만나게 된다. 크게 두 가지 경우가 있을 수 있는데, 1) 자연스러운 데이터 shift, 2) 잘못된 로직, 핸들링하지 못한 외부 요소 등에 의한 오류 이다. 보통 많은 경우 2번 처럼 사람의 예상 범주 안에 없는 Edge Case가 생기거나 단순한 휴먼 에러로 인해 데이터 오염되는 경우가 많다.
데이터 버전 관리
위에서 말한 것 처럼, 데이터가 지속적으로 변화함에 따라 데이터 파이프라인들에도 변화가 생긴다. Spark 기반의 데이터 파이프라인을 구성하는 코드는 보통 git으로 관리가 되는데, 이로 인해서 생겨나는 데이터에 대한 관리는 쉽지 않다 (DW 쪽에서 테이블 label 또는 테이블 컬럼으로 버전을 보통 관리하는 듯). SQL 기반의 파이프라인은 더 더욱 어렵다. SQL을 코드로 관리하지 않는 한, 변경 사항을 추적하기 힘들고 또한 SQL 특성상 복잡한 파이프라인을 만들때 500 라인이 넘어가는 SQL 코드를 한 줄 한 줄 읽어가면서 피어 리뷰를 받기도 쉽지 않다.
데이터 오너쉽
데이터는 사내 모두의 것이 아닌가? 하는 의문이 생길 수 있지만 현실은 그렇지 않다. 중요한 데이터일 수록, 데이터에 문제점이 생겼을 때 누군가는 관련 사항을 고쳐야하고, 코드와 같이 누군가 로직을 변경했을 때 리뷰를 하고 새로운 버전을 배포할 오너십을 가질 사람이 꼭 필요해진다.
데이터 의존성 파악
가지고 있는 데이터가 늘어나면 늘어날 수록 팩트/디멘션 테이블과의 조인이나 다른 테이블의 업데이트 상태에 따라서 다음 테이블이 생겨나게 되는 (보통 DAG로 표현 가능한) 로직들이 많이 생겨난다. 때문에 누군가가 기존에 있는 테이블 및 데이터세트들을 지우거나 변경하게 될 떄 사이드 이펙트가 생길 수 있다. 이와 같은 데이터 간의 디펜던시를 파악하기 어려운 환경이라면 안전하게 데이터를 다루기 힘들다.
위와 같은 문제를 해결하기 위해서 나오고 있는 데이터 관련 용어들이 몇 가지 있다.