데이터 품질에 관한 이슈는 그다지 특별한 것이 아니었다. 저품질 데이터(여기선 잘못된 정보가 담긴 나쁜 데이터와 다른 개념)로 인하여 심하게는 남극의 위치를 잘못 계산하거나, NASA에서 화성 기후 궤도선 사고가 발생하거나 하는 문제가 있었다.
데이터 품질은 데이터의 신뢰성(reliability), 완전성(completeness), 정확성(accuracy)를 측정하는 기능적 측면부터 구체화되기 시작했다. 이 책에서는 데이터 품질을 데이터 라이프 사이클에 따라 단계별 상태로 정의한다.
많은 기업들이 기존의 시스템에서 적용하였던 데브옵스(DevOps), 신뢰성 엔지니어링(SRE), 지속 통합배표(CI/CD) 및 마이크로서비스 기반 아키텍처 등을 데이터에도 적용시켰다. 요즘엔 데브옵스의 개념을 데이터에 적용하여, 데이터 옵스(DataOps)라고 명명하기도 하였다. 현재 많은 빅테크들이 데이터의 높은 품질을 유지하고자 많이 투자를 하고 있다.
데이터 다운 타임이란 데이터가 수집되지 않아 누락되거나 부정확하게 측정되는 등의 데이터 손실로 인해 소프트웨어 혹은 서비스의 가동이 중지되는 상황을 말하는데, 이 책에서는 몇 가지 사례로 데이터 다운 타임을 야기시키는 요소에 대해 제시한다. 물론, 데이터 다운 타임과 반대로 다양한 기술 혁신으로 인해 데이터 환경을 변화시키는 사례도 제시한다.
그중 하나가 데이터 메시다. 데이터 메시는 마이크로서비스 아키텍처의 데이터 플랫폼 버전이다. 에릭 에반스의 '도메인 주도 설계(DDD)' 이론을 활용하여, 도메인별로 데이터가 편재성을 갖도록 하는 개념이다. 단일 중앙 집중형 데이터 레이크에서 소비, 저장, 변환, 출력을 처리하는 방식과 달리 데이터 메시는 자체 파이프라인을 통해 '프로덕트형 데이터(data-as-a-product)' 관점에서 분산된 도메인별로 데이터 소비자가 활용할 수 있도록 처리하고 지원한다. 도메인 주도 설계의 이론에서 활용한 것으로 알 수 있듯이 범용적 상호운영 레이어를 통해 데이터에 동일한 표준을 적용하고, 개별 도메인과 데이터가 연결될 수 있도록 한다. 데이터 메시는 데이터를 프로덕트로 제공할 책임이 있는 도메인 이해관계자들이 데이터 소유권을 공유할 수 있도록 하는 동시에, 도메인 내외의 분산된 데이터 간의 커뮤니케이션을 원활하게 한다. 데이터 메시의 맹점은 '범용적 상호운용성'이 도메인 간에 적용될 때만 성공적이며, 데이터를 신뢰할 수 있는 유일한 방법은 테스트하고 모니터링하는 것이다.
그 외에도 데이터를 실시간으로 흐르게 하는 스트리밍 데이터, 데이터 레이크하우스가 있다.
데이터를 가장 크게 구분하자면 운영 데이터와 분석데이터가 있다. 운영데이터는 특정시점의 인벤토리 스냅샷, 고객 인상 및 거래 기록 등의 일상적으로 서비스 운영을 통해 생성된 데이터이다. 분석데이터는 마케팅 전환율, 클릭률 등 데이터 기반 의사결정에 활용되는 데이터이다. 간단히 말해, 운영데이터는 시스템 및 프로세스의 신속한 업데이트를 위해 실제 비즈니스 프로세스의 데이터를 기록하는 반면 분석데이터는 좀 더 강력하고 효율적인 분석을 하는 데 사용된다.
운영데이터와 분석데이터의 차이가 중요한 이유 중 하나는 처리량과 대기시간의 균형 때문이다. 일반적으로 처리량은 일정 단위 시간 내에 처리되는 데이터의 양을 의미하며, 대기 시간은 데이터 처리가 끝날 때까지의 지연을 의미한다. 아쉽게도 이 두가지 데이터 처리의 성능 척도는 양립할 수 없다. 많은 처리량과 짧은 대기 시간은 서로 트레이드오프 관계이기 때문이다.
또한, 데이터 레이크하우스가 언급 되었는데 각각 자세히 보자면 다음과 같다.
데이터 웨어하우스는 '쓰기 스키마' 액세스 권한이 필요하다. 즉, 데이터 웨어하우스에 데이터가 들어오는 즉시 데이터의 구조를 설정한다는 의미다. 이 같은 데이터의 추가 변환에 따라 모든 단계에서 명시적으로 새로운 구조를 만들어야 한다. 데이터 웨어하우스는 완벽하게 통합되고 관리되는 솔루션으로 즉시 구축하고 운영할 수 있으며, 더 많은 구조와 스키마가 필요하므로 데이터 위생(데이터가 정확하고 일관되며 오류가 없는지 확인하는 데 사용되는 관행이나 프로세스)이 개선된다. 또한 데이터를 읽고 사용할 때의 복잡성이 줄어든다.
데이터 웨어 하우스는 보통 쓰기 스키마와 아키텍처, 루커(Looker), 태블로(Tableau)와 같은 비즈니스 인텔리전스 도구(BI)를 통합하여 방법 실현한다. 다시 말해, 데이터 웨어하우스의 데이터는 존재의 이유가 있으며 그 이유는 비즈니스 목표와 일치해야 한다. 하지만 데이터 품질 관점에서 볼 떄 몇 가지 약점이 있다. 그중 하나는 명확한 스키마로 인한 낮은 확장성에 있다는 것이다.
데이터 레이크는 '읽기 스키마'에서 접근할 수 있다. 데이터를 사용할 준비가 되어 있을 때 데이터 구조를 추론한다. 데이터 레이크는 데이터 웨어하우스의 DIY 버전으로, 팀의 시스템 요구 사항에 따라 다양하게 선택할 수 있다. 데이터 레이크는 한없이 유연하고 사용자 정의가 자유로우며 민첩성이 뛰어나서 광범위하게 사용을 할 수 있다. 하지만 데이터 구성 및 거버넌스와 관련된 다른 문제가 발생하기도 한다.
데이터 조직이 데이터 레이크 환경에서 반드시 데이터의 무결성, 데이터의 늪지화, 엔드 포인트 증가를 고려해야 한다. 파일 레벨에서 조작되는 데이터 레이크의 리소스는 데이터 스키마에 대한 보장이 없으며, 시간이 지남에 따라 데이터 레이크가 기술적 부채와 암묵적 지식을 발생할 가능성은 높아진다. 또한 데이터를 수집, 조작, 변환할 수 있는 방법이 다양하기 때문에 데이터 파이프라인의 단계가 많아질수록 오류 발생의 가능성이 커지며 데이터의 안정성이 문제가 되기도 한다.
최근엔 데이터 레이크와 데이터 하우스의 차이가 좁혀지고 한 패키지에서 둘의 장점을 누릴 수 있다. 이렇게 생긴 것이 데이터 레이크하우스이다. 기존 데이터 웨어하우스에 대한 요약 및 ETL 없이 데이터 레이크가 분석 및 탐색 요구를 직접 처리할 수 있거나, 데이터 레이크 테이블에 더 엄격한 스키마를 도입하거나, 혹은 관리형 메타 데이터 서비스를 활용하는 등을 통해 두 기술 사이의 경계는 점점 모호해지고 있다.
서로 다른 데이터 웨어하우스와 데이터 레이크는 데이터 통합 레이어로 연결되어, 서로 다른 소스에서 데이터를 수집하고 데이터를 통합한 후 업스트림 소스로 변환한다. ETL은 데이터 통합 내에서 잘 알려진 프로세스로 하나 이상의 데이터 자장소에서 데이터를 먼저 추출하고, 새로운 구조 또는 형식으로 변환한다음, 최종적으로 대상 데이터 저장소에 적재하는 통합 단계를 말한다.
데이터 품질지표로는 데이터 다운 타임 관점으로 할 수도 있고, 혹은 데이터의 신선도와 볼륨 관점에서도 할 수 있다. 데이터의 신선도와 볼륨의 경우 업데이트 빈도와 각 업데이트에서 예상되는 데이터 양을 가늠할 수도 있다. 또한 작업 기록을 살피고 데이터가 어떻게 적재되고 이동했는지를 확인할 수 있으며, 일부 중요한 테이블의 경우 데이터 품질 검사를 실행하여, 시간 경과에 따른 상태 메트릭을 추적하고 이를 과거 배치와 비교하여 다양한 데이터 품질 문제가 나타났는지 즉시 확인을 할 수도 있다.
데이터 웨어하우스나 데이터 레이크의 경우 메타 데이터를 활용하면 데이터 품질에 대한 이해를 돕는 데이터 스택으로 활용할 수 있다. 다른 핵심 요소는 데이터 카탈로그다. 데이터 카탈로그의 핵심 질문은 다음과 같다
- 데이터르 ㄹ어디에서 찾아야 하는가?
- 데이터는 중요한가?
- 이 데이터는 무엇을 나타내는가?
- 이 데이터가 관련성 있고 그 관련성은 중요한가?
- 이 데이터를 어떻게 사용할 수 있는가?
데이터 카탈로그는 직접 만들다보면 문제가 발생하기 쉽다. 대형 데이터 웨어하우스에 수만 개 테이블이 있을 수도 있으며, 오늘날 저장되는 데이터에는 비정형적이고 유동성이 매우 높은 데이터가 많기 때문이다.
만약 데이터 카탈로그를 처음부터 구축한다고 가정을 할 경우, 운영 및 분석 팀의 다운스트림 이해관계자와 협력하여 비즈니스에 가장 중요한 데이터가 무엇인지 파악하고 문서화 및 카탈로그화하는 것이 중요하다. 가장 기본적인 데이터 카탈로그는 데이터 위치, 소유권, 잠재적인 사용 사례에 대한 맥락과 통찰력을 제공하는 메타데이터의 모음이다. 기본적인 데이터 카탈로그를 작성하기 위하여, 데이터 조직은 모든 테이블을 수동으로 검색하거나 자동화된 SQL 파서(parser)를 사용하여 작업을 수행한다. 데이터 카탈로그를 밑바닥부터 구축할 경우에는 오픈 ELK 스택, PostgreSQL과 같은 오픈소스 데이터베이스를 선택하는 것도 좋다.
명확한 모델을 사용하는 경우 데이터 카탈로그가 제대로 동작하지만, 데이터 파이프라인이 점점 복잡해지고 비정형 데이터가 표준이 됨에 따라 데이터가 무엇을 하는지, 누가 사용하는지, 어떻게 사용하는지 등 데이터에 대한 이해는 현실을 반영하지 못하고 있다.
데이터 관리 전략은 데이터 카탈로그화 외에도 데이터 메시 모델을 활용한 데이터 검색이 있다. 데이터 검색은 서로 다른 데이터 소유자가 자신의 데이터를 프로덕트로서 책임지고, 서로 다른 위치에 분산된 데이터 간의 통신을 촉진한다고 가장한다. 주어진 데이터가 제공되고 변환되면 도메인 데이터 소유자는 운영 똔느 분석 요구사항에 맞추어 데이터를 활용할 수 있다. 데이터 검색의 경우 특정 소비자가 데이터를 수집, 저장, 집계, 사용하는 방식을 기반으로 데이터에 대한 도메인별 동적인 이해를 제공함으로써 데이터 카탈로그의 필요성을 대체하기도 한다.
'공부하는삶 > DataOps' 카테고리의 다른 글
[TIL] 데이터 품질의 비밀 3. 데이터 수집, 정제, 변환, 테스트 (0) | 2024.05.25 |
---|