[DE] Idea for good Data Warehousing (KR)

Last updated Jul 3, 2023 - Edit Source

• Idea
• Data engineering
• Kr

Go to English Edition Idea for good Data Warehousing (EN)

저는 좋은 데이터 엔지니어는 데이터 웨어하우스를 잘 관리할 수 있어야 한다고 생각합니다. 왜냐하면, 비록 많은 사람들이 데이터 엔지니어가 해야 하는 영역이 너무 넓다고 말하지만, 그 중에서도 데이터를 저장하고 다루는 공간을 잘 구축하는 것이 가장 중요한 임무라고 생각하기 때문입니다. 오늘은 데이터 웨어하우스를 구축하고 관리하면서 꼭 신경써야 한다고 생각하는 것들에 대해서 몇 가지 적어보았습니다.

가장 먼저 데이터 웨어하우스의 정의부터 살펴봅니다.

1992년 Inmon W.H의 책 (Building the Data Warehouse)에서 처음 소개된 데이터 웨어하우스란 회사의 운영 방향 대신 특정 주제에 맞는 데이터를 지니고 있으며 (Subject Oriented), 여러 가지 데이터 소스로부터 수집된 데이터들이 모이는 곳입니다 (Integrated). Inmon은 또한, 데이터 웨어하우스는 모든 데이터가 각각 특정 시간 구간에서 식별될 수 있어야 하며 (Time-variant), 데이터가 추가될 수 있으면서 지워지지 않아 일관된 목적을 유지할 수 있는 비휘발성 (Non-volatile)을 갖춰야 한다고 말합니다.

저는 이것이 가장 일반적인 범위에서 정의된 데이터 웨어하우스이기 때문에 현 시대에 역할을 수행하는 데이터 웨어하우스들과는 분명히 차이가 존재한다고 생각합니다. 현재의 데이터 웨어하우스에는 데이터의 목적과, 저장 및 처리 비용을 포함하는 다른 다양한 외부 요인들까지 포함하여 완성되기 때문입니다.

저는 이 정의에 덧붙일 수 있는, 데이터 웨어하우스를 설계할 때 중요하게 고려해야 하는 것들을 몇 가지 이야기하려고 합니다.

저는 데이터 엔지니어가 잘 갖춰진 논리에 근거해 데이터를 다뤄야 한다고 생각하기 때문에 도메인 지식은 굉장히 중요하다고 생각합니다. 데이터 엔지니어가 데이터가 쓰이는 곳에 대한 배경지식이 없다면, 각각의 데이터가 가진 상관관계와 인과관계를 제대로 구분하지 못하게 됩니다. 이는 논리에 근거해 데이터를 다루는 것이 아니라 보기 좋게 꾸며진 데이터 가공이 되어 어떤 효용도 없게 만들 것입니다. 저는 그렇기 때문에 데이터 엔지니어라면 도메인 지식을 잘 갖추고, 다뤄야 할 데이터들이 어떤 형태로 존재하는 지, 그리고 어떤 방향으로 쓰이는 지까지 전부 이해하려고 노력해야 한다고 생각합니다.

도메인 주도 설계와 비슷한 관점으로 보일 수 있지만, 조금은 다른 점이 있다고 생각합니다. 도메인 주도 설계를 채택하면 일반적으로 높은 생산성과 낮은 복잡도, 쉬운 커뮤니케이션을 달성할 수 있다고 잘 알려져 있습니다. 도메인 지식을 갖춘 데이터 웨어하우스는 데이터의 활용 범위를 가능한 한 최대로 유지할 수 있으면서, 현재 데이터 특성을 가장 잘 반영하면서 다양한 성능 최적화를 달성할 수 있습니다.

도메인 지식을 잘 이해한 데이터 엔지니어에게 또 하나 남은 과제가 있다면, 수요 예측이라고 생각합니다. 수요 예측은 데이터 웨어하우스에서 소비자들이 분석 목적으로 자주 사용할 데이터의 수요를 예측하여 그 데이터를 사용하기 좋은 형태로 준비하는 과정을 의미합니다.

데이터 프로덕트를 만드는 과정에서는 여러 가지 데이터 포인트로부터 인사이트를 도출해야 합니다. 데이터 엔지니어는 가장 데이터 소스와 밀접한 위치에서 일하는 사람이기 때문에, 이 데이터들에 가장 먼저 접근할 수 있고, 가장 기본적인 분석을 쉽게 해낼 수 있는 역할에 위치해 있습니다. 대부분의 데이터는 다차원 데이터 형태를 갖고 있습니다. 같은 데이터라도 여러 차원으로 분리되어 분석에 사용될 수 있다는 의미입니다. 다차원 데이터를 다룬다면, 그 속에서 여러 차원에 대한 분석을 통해 다양한 상관관계를 파악할 수 있어야 합니다. 그렇지만 모든 상관관계가 유의미한 인과관계 분석으로 이어지지 않습니다. 그렇기 때문에 데이터 엔지니어는 자신이 만든 데이터를 사용하는 소비자와 많은 대화를 나눌 수 있어야 합니다.

대개 이 경우에 소비자는 데이터 분석가, 백엔드 엔지니어, 프로젝트 매니저, 프로덕트 매니저처럼 다양한 기능의 역할을 수행하는 사람들일 것입니다. 결국 이 모든 구성원은 같은 목적을 갖고 데이터를 다루는 사람들이라는 공통점이 있기 때문에, 잘 설정된 목표를 넓게 이해한 상태여야 하겠습니다.

이를 통해 데이터 파이프라인이 어떤 식으로 데이터를 저장하고, 업데이트 되어야 하는 지를 파악할 수 있어야 합니다.

위에서 설명했듯이 데이터 엔지니어는 잘 갖춰진 도메인 지식을 바탕으로 가장 먼저 데이터의 전반적인 이해를 갖추고, 소비자의 수요를 이해한 다음에 이에 따라 데이터 웨어하우스 아키텍쳐를 설계할 수 있어야 한다고 생각합니다. 이 과정을 세심하게 따르지 않는다면, 당신은 여러 가지 데이터 수요에 대응하거나, 수시로 데이터 스키마를 변경하는 작업을 진행하는 등의 데이터 웨어하우스 아키텍쳐 리팩토링을 하느라 귀한 시간을 소모하게 될 것이라고 생각합니다.

이에 따라, 만일 제가 데이터 웨어하우스 아키텍쳐를 처음부터 설계한다면, 어떤 것들을 고려하고자 하는 지 아래에 적어보려고 합니다.

책상 위에 펼쳐진 데이터들을 충분히 이해하지 못한 상태에서 설계한 데이터 웨어하우스 아키텍쳐는 수명이 짧다고 생각합니다. 위에서 말한 것 처럼 보유한 데이터를 이해하고, 이 데이터의 소비자들과의 커뮤니케이션을 통해 달성해야 하는 목표를 이해할 시간이 꼭 필요합니다.

저는 모든 데이터 아키텍쳐에는 비즈니스 타당성이 포함되어 있다고 생각합니다. 모든 가능성을 고려한 간결하고 유지보수하기 좋은 아키텍쳐는 현실에 존재하지 않습니다. 가장 먼저 달성해야 하는 목표를 달성할 수 있는 방법을 고려해야 합니다. 그리고 이 과정에서 최대한 쉽고 적은 비용의 테크 스펙과 구현 방식을 채택해야 합니다. 비즈니스 로직은 당연하게도 더 복잡해질 것이기 때문입니다.

이 과정에서 제가 고려하고자 하는 것들은 아래와 같습니다.

데이터 파이프라인의 결과물을 소비할 Data Analyst, Backend Engineer들과 커뮤니케이션을 통해 요구사항을 파악해야 합니다. 필수적으로 포함되어야 하는 정보와, 데이터 형식, 데이터 업데이트 주기에 대해서 합의가 이뤄져야 합니다. 그것은 SLA의 형태일 수도 있습니다. 다만, 이상적으로 완벽한 구현이 요구된다면, 비즈니스 타당성을 고려해 달성 가능한 목표를 세분화해서 일정을 산출하고 작업을 수행할 수 있어야 합니다.

구현을 위해서 테크 스펙을 선정해야 합니다. 이 때 고려해야 하는 것은,

1. 데이터 인프라 아키텍쳐

2. 데이터 인프라에 대한 팀원들의 기술 친화도

3. 데이터 인프라에 대한 주/월 단위 비용 예측

4. 구현에 필요한 시간 예측이 있습니다.

등이 있습니다.

모든 요소가 불확실성이 높으면서도 중요도의 순서를 결정하기 어렵다는 문제가 있습니다. 풀고자 하는 문제가 모든 회사의 모든 팀에서 각기 다른 모습을 하고 있기 때문입니다.

저는 이런 상황에서는 가장 먼저 팀원들과 함께, Pre-Mortem을 진행해보는 것도 좋은 방법이 될 수 있다고 생각합니다. 대니얼 카너먼은 책 ‘생각에 관한 생각’에서 계획 오류라는 개념을 언급하며, 많은 사람들이 과신에 빠진 나머지 계획을 세울 때, 비현실적으로 최상의 시나리오를 짜거나, 비슷한 다른 상황의 사례를 찾아보는 외부 관점을 무시해 계획을 수행하는 것에 실패한다고 말합니다. 저는 이런 문제를 해결하기 위해, Pre-Mortem을 아래와 같이 진행해볼 수 있다고 생각합니다. 그는 원인이 되는 지나친 낙관주의를 해결하기 위해, Pre-Mortem을 제안합니다. 이 개념을 우리 문제에 적용해보면, 아래와 같이 진행해볼 수 있다고 생각합니다.

1. 팀원들과 모여서 1,3,6개월 뒤에 이 테크 스펙이 참담하게 실패하는 이유들을 각자 적어본다.

2. 각 실패 이유들에 대해 계획 과정에서 예방할 방법을 확인한다.

3. 각 실패 이유들을 해결한 외부 사례를 간단히 탐색한다.

이렇게 되면, 해당 팀이 집단적으로 결정에 순응하는 것을 방지할 수 있으며, 박식한 사람들이 바람직한 방향으로 상상력을 펼쳐내 위험 요소를 파악해볼 수 있다는 장점이 있습니다. 이 과정을 거친 다음에, 다시 위의 4가지 고려사항을 최대한 만족하는 테크 스펙을 선정한다면, 훨씬 신뢰도 높은 테크 스펙을 선정할 수 있을 것이라고 생각합니다.

각 Stage별 실행되는 ETL 작업의 목적을 정의하고, 결과 데이터의 역할을 정의하는 과정이 필요합니다.

예를 들어 data source를 적재하는 data lake와, 가공된 데이터들이 포함되는 data warehouse, 실제 product 또는 분석에 사용될 data mart로 stage를 구분해 계획하는 방법이 있습니다. 각 stage에서 데이터를 처리하는 pipe의 역할이 명확할수록 추후에 구조 개선을 할 때에 개선 지점을 파악하기 좋을 것이라고 생각합니다.

기본적으로 세운 원칙은 아래와 같습니다.

1. 데이터 저장 규칙:

   각 stage는 데이터 저장 규칙을 명확하게 정해야 합니다. 이를테면, 모든 stage가 non-volatile할 필요는 없지만, Source는 Non-volatile을 꼭 지켜야 한다는 규칙을 세울 수 있습니다.

2. 데이터 분류 규칙:

   각 stage의 데이터 분류 규칙을 명확하게 정해야 합니다. 이를테면, data mart의 데이터 성격은 여러 개의 data source를 통해 새로운 정보가 생성된 데이터일 수도 있고, pipeline 외부의 사용처가 명확히 정해진 데이터일 수도 있습니다. 성격을 명확하게 분류하지 않아 data mart에 포함되어야 할 데이터가 다른 stage에 포함되지 않는 문제가 발생하지 않도록 해야 합니다.

3. 데이터 가공 규칙:

   각 stage의 데이터 가공 규칙을 명확하게 정해야 합니다. 이를테면, data mart 이전의 stage의 데이터를 다루는 pipeline은 멱등성을 보장하는 로직을 강제할 수 있습니다. 또는, data lake의 데이터를 가공할 때에는 데이터 타입 변경, 칼럼 이름 변경 등만 허용하는 규칙을 강제할 수 있습니다.

4. 예외 처리 규칙:

   a,b,c에 관한 예외는 비즈니스 타당성에 맞게 대응하되 모든 예외 사항은 re-architecturing point로 기록해 revisit 가능하게 해야 합니다.

이 규칙들 중에서 가장 까다로운 지점은 데이터 분류 규칙이라고 생각합니다. 예를 들어 data mart의 테이블들은 그대로 Product에 사용되기도 하지만, mart 테이블 여러 개를 join해서 새로운 테이블로 만들어 분석에 활용할 수 있다고 생각합니다. 이러한 경우에 대응하기 위해서 우리는 다음과 같은 판단을 할 수 있다고 생각합니다.

1. source들을 최대한 활용하여 분석 목적 용도로 사용할 데이터를 생산 가능한 지를 고려해볼 수 있어야 합니다.

2. 분석 목적으로 사용할 data mart 테이블을 source로 하는 분석 목적의 data warehouse를 새롭게 구축할 수 있는 지 고려해볼 수 있어야 합니다.

이 외에도 비즈니스 상황에 따라 다른 고려할 수 있는 옵션들이 있겠습니다. 많은 경험과 공부를 통해 데이터 엔지니어가 성장하는 지점이라고 생각합니다.

비즈니스 로직이 복잡해질수록, 최초에 데이터 아키텍쳐를 계획한 작업자들으로 인해 single point of failure가 발생할 확률이 높아진다고 생각합니다. 따라서 누구나 학습할 수 있는 Lineage 관리 방법을 고민해야 합니다. 누구나 학습하기에는 어려운 구조라고 생각이 들었다면, 결국 이는 SPF를 발생시키게 될 것입니다.

데이터 Lineage가 생산성을 해치지 않는 선에서 구성되려면 아래의 상황은 최대한 피하는 것이 좋다고 생각합니다.

1. 한 data warehouse 내에서 cyclic 구조가 생겨야 하는 경우

2. 서로 다른 data stage에 포함된 source를 참조해 데이터를 가공하는 경우

위 두 가지 상황은 3번에서 계획한 데이터 stage의 정의를 해치게 됩니다. 이러한 문제들은 도메인 지식과 비즈니스 목표, 이해당사자들과의 커뮤니케이션을 잘 활용해 문제를 해결해야 한다고 생각합니다. 복잡도가 높은 데이터 lineage는 결국 나중에 데이터 생산성의 병목 요인이 될 것이기 때문입니다.

저는 여기에서 꼭 피해야 하는 선택들이 있다고 생각합니다.

1. 데이터 분석가 또는 데이터 백엔드 엔지니어의 처리 방식을 변경하는 해결책:

   이 해결책은 결국 다시 같은 문제를 직면하게 할 것입니다.

2. 불가피하게 복잡도를 선택한 경우에, 해당 선택의 결과 데이터를 이후 데이터의 source로 활용하는 경우:

   복잡도를 피할 수 없는 구조라는 이유로 예외 허용을 택했다면, 허용된 예외가 downstream에서 복잡도를 높이지 못하게 통제해야 합니다.

좋은 데이터 아키텍쳐를 설계했다고 하더라도, 늘 우리는 예상치 못한 예외 데이터를 마주해야 합니다. 이러한 예외는 할당된 리소스 범위를 초과하는 복잡한 로직 때문에 발생할 수도 있고, 비즈니스 임팩트를 주지 못하는 outlier에 해당하는 Input으로 인해 발생할 수도 있으며, 데이터 source의 스키마 변경 또는 버전 업그레이드로 인해 발생할 수도 있습니다.

데이터 엔지니어에게 어떤 것보다 중요한 것은 데이터 퀄리티라고 생각합니다. 그렇기 때문에 데이터 엔지니어는 모든 데이터를 다루는 파이프라인들에 대해서 가능한 예외를 가장 먼저 파악하고 대응할 수 있어야 합니다. 따라서 좋은 데이터 아키텍쳐를 완성하기 위해서는 Validation과 Verification을 어떻게 구성할 지, 그리고 이를 어떻게 Monitoring할 지 결정해야 합니다.

제가 Validation / Verification에 대해서 중요하게 생각하는 것은 아래와 같습니다.

1. Stage의 정의를 따르는 지 확인할 수 있어야 합니다.

2. data lineage에 따라, Validation을 통해 특정 point에 대해 각 Validation이 데이터를 Verification 할 수 있게끔 보장해야 합니다. 동일한 목적의 Validation이 여러 stage에서 수행될 필요가 없어야 합니다.

3. Validation 과정에서 파악된 예외 데이터들은 별도로 기록되어, Verification Rule에 활용되어야 합니다.

4. Monitoring은 개발 과정에서 가장 예외가 많이 발생한 지점을 파악해서 진행하되, 운영 과정에서 발생하는 Issue들을 통해 Grey Area가 발생하지 않도록 발전시켜야 합니다.

좋은 데이터 아키텍쳐에 대한 정답은 없다고 생각합니다. 계속해서 더 좋은 기술들이 세상에 소개되고 있고, 더 창의적인 해결책이 제시될 수 있기 때문입니다. 저는 그 정답을 만들어내는 과정에서 놓치지 않아야 하는 것들에 대해서 늘 주의해야 한다고 생각합니다. 달성한 결과물이 최선이 아니라 Second Best일 수도 있습니다. 그렇지만 Worst가 아닌 Best Practice를 지향하고 이를 위해 고려할 사항들을 잊지 않아야 Another Best를 만들어 낼 수 있다고 생각합니다.