데이터 레이크
한글화 프로젝트
한글화 프로젝트는 지앤선과 국내 커뮤니티들이 함께 해외의 다양한 주제의 유익한 문서 등을 번역하여 영어를 읽는데 어려움이 있는 여러 사람에게 도움을 드리고자 진행 중인 프로젝트이다. 이 글은 KSUG의 오치문 님이 번역을 진행해주신 것으로 지앤선의 블로그를 통해 공개되었던 것을 재정리하여 브런치로 옮겨왔다.
데이터 레이크
데이터 레이크(Data Lake)는 빅데이터(Big Data) 세계에서 데이터 분석 파이프 라인의 중요한 구성 요소 중 하나를 설명하기 위해 최근 10년간 등장한 용어입니다. 이것은 조직에서 누구나 분석할 때 필요한 모든 원시 데이터를 저장하는 단일 저장소를 갖는 것을 의미합니다. 일반적으로 사람들은 레이크(단일 저장소)의 데이터를 처리하기 위해서 하둡을 사용하지만, 데이터 레이크의 개념은 하둡보다 광범위합니다.
조직에서 분석하고자 하는 모든 데이터를 한 곳에 모은다고 들었을 때, 저는 바로 데이터 웨어하우스(그리고 데이터 마트[1])의 개념이 생각났습니다. 그러나 데이터 레이크와 데이터 웨어하우스 간에는 중요한 차이점이 있습니다. 데이터 레이크는 그것이 어떤 형태든, 데이터 소스가 제공하는 그대로의 원시 데이터를 저장합니다. 데이터 스키마에 대한 가정은 없으며 각 데이터 소스는 원하는 스키마를 사용할 수 있습니다. 따라서, 자신의 목적에 맞게 데이터를 이해하는 것은 데이터 소비자에게 달려있습니다.
이것은 기존에 비해 진일보한 것인데, 많은 데이터 웨어하우스들은 스키마 문제로 인해 멀리 가지 못했습니다. 데이터 웨어하우스는 모든 분석 요구에 대해 하나의 스키마 개념을 사용하는 경향이 있습니다. 저의 견해는 이런 단일 통합 데이터 모델은 아주 작은 조직을 제외하면 비현실적이라는 것입니다. 조금이라도 복잡한 도메인을 모델링하려면 각각의 데이터 모델과 함께 여러 개의 BoundedContext가 필요합니다. 분석 측면에서 보면, 자신이 수행 중인 분석에 적합한 모델을 사용하는 여러 분석가들이 필요합니다. 원시 데이터만 저장하도록 전환하면 데이터 분석가가 이 책임(각 컨텍스트에 맞게 이해하고 모델링하는 것)을 지게 됩니다.
데이터 웨어하우스의 또 다른 문제점은 데이터 품질을 보장하는 것입니다. 데이터에 대해서 신뢰할 수 있는 하나의 소스를 얻으려면, 다른 시스템에서 어떻게 데이터를 수집하고 사용하는지에 대해 많은 분석이 필요합니다. 어떤 데이터에는 시스템 A가 좋고, 다른 데이터에는 시스템 B가 좋을 수 있습니다. 예를 들면, 시스템 A는 더 최근의 주문에 대해 좋을 수 있지만, 반품이 포함되지 않은 조건에서 한 달 또는 그 전의 주문에 대해서는 시스템 B가 더 좋을 수 있습니다. 무엇보다도, 데이터 품질은 종종 주관적인 문제이며, 각 분석마다 데이터 품질 문제에 대해 서로 다른 허용 오차를 가집니다. 심지어 무엇이 좋은 품질이냐에 대한 개념도 다릅니다.
이것은 데이터 레이크에 대한 흔한 비평을 야기합니다. 단지 광범위한, 다양한 품질의 데이터 쓰레기장이라는 것, 좋게 말해 데이터의 늪이라는 비평입니다. 비평은 타당하면서도 부적절합니다. 새로운 분석론에서 화제가 되고 있는 명칭이 ‘Data Scientist’입니다. 비록 이것이 남용되고 있는 명칭이지만, 여기에 속한 많은 사람들이 과학 분야에서 견고한 배경을 가지고 있습니다. 그리고 어떤 훌륭한 데이터 과학자는 데이터 품질 문제에 대해 모든 것을 알고 있습니다. 시간이 지남에 따라 온도 판독 값을 분석하는 간단한 문제를 생각해 봅시다. 측정치에 미묘하게 영향을 미치거나, 장비의 문제로 인한 이상, 센서가 작동하지 않는 기간 등의 이유로 일부 기상 관측소의 이전을 고려해야만 합니다. 하지만 많은 정교한 통계 기술이 데이터 품질 문제를 해결하기 위해 만들어졌기 때문에 이런 문제를 해결할 수 있습니다(즉, 어느 정도 오차가 있어도 관측소를 이전하지 않아도 됩니다). 데이터 과학자들은 항상 데이터 품질에 회의적이며, 의심스러운 데이터를 다루는 데 익숙합니다. 그래서 그들에게 데이터 레이크는 중요합니다. 왜냐하면 그들은 원시 데이터로 작업을 하고, 불명료한 데이터를 정제하는 메커니즘보다는, 데이터를 이해하기 위해서 더 나은 분석기술을 적용하는 것을 신중하게 고려해볼 수 있기 때문입니다.
(역자 주. 간단히 정리하면, 저자는 데이터 쓰레기장이라는 비평에 대해서, 데이터 레이크에 다양한 품질의 데이터가 섞여있는 것은 인정하지만 데이터 분석 기술로 커버할 수 있다는 것을 이야기하고 싶은 것 같습니다.)
일반적으로 데이터 웨어하우스는 단순히 데이터를 정제하는 것뿐만 아니라 분석하기 용이한 형태로 모읍니다. 그러나 이 과정에서 데이터의 일부가 버려질 수 있기 때문에 데이터 과학자들은 이점에 대해서도 반대하는 경향이 있습니다. 데이터 레이크는 반드시 모든 데이터를 저장하고 있어야 하는데, 그 이유는 어떤 사람이 오늘 혹은 2년 내의 데이터에서 가치를 찾아낼지 모르기 때문입니다.
저의 동료 중 한 명이 최근의 한 사례를 들어 이 점에 대해 설명했습니다.
“우리는 우리의 자동 예측 모델과 회사의 계약 관리자들이 작성한 수동 예측을 비교하려고 했습니다. 그러기 위해서 우리의 모델을 당시의 데이터로 학습시키고, 우리의 예측 결과와 그 당시 관리자들의 예측 결과를 비교하려고 했습니다. 우리는 지금 정답을 알고 있기 때문에, 이 방법은 정확도 시험에 적합했습니다. 이 시험을 시작했을 때, 관리자들의 예측은 끔찍했고 불과 2주 만에 만들어진 우리의 단순한 모델조차도 그들의 예측보다 나았습니다. 우리는 이 엄청난 성과를 사실로 받아들이기에는 의심스럽다고 생각했습니다.
많은 테스트와 분석 후에 우리는 관리자의 예측들과 관련된 타임 스탬프가 잘못되었다는 것을 알게 되었습니다. 이 값들은 월 말 처리 보고서에 의해 수정되었던 것입니다. 간단히 말해서, 데이터 웨어하우스에 저장된 예측 값들은 쓸모가 없었습니다. 우리는 예측 비교를 수행할 방법이 없을 것이라고 우려했습니다. 더 많은 분석 후에 우리는 이 보고서가 저장되어 있는 것을 발견했고, 그 당시의 실제 예측을 추출할 수 있었습니다. (우리는 다시 관리자들의 예측보다 나은 결과를 얻었지만, 여기에 많은 시간이 필요했습니다).”
원시 데이터의 복잡성은 데이터를 보다 관리하기 쉬운 구조로 조정할 수 있는 여지가 있음을 의미합니다(또한 상당한 양의 데이터를 줄일 수 있습니다). 데이터 레이크에는 직접 접근하도록 해서는 안됩니다. 데이터 레이크에 저장된 가공되지 않은 데이터(원시 데이터)를 이해하기 위해서는 많은 기술이 필요합니다. 데이터 레이크를 이용해서 일하는 비교적 적은 사람들이 레이크에 있는 데이터로 일반적으로 유용한 뷰를 발견합니다. 또한 그들은 많은 양의 데이터 마트들을 만들어내는데, 각각의 데이터 마트는 하나의 bounded context에 맞는 특정한 모델을 갖습니다. 그렇게 되면 많은 다운스트림 사용자들이 이런 레이크쇼어 마트들을 각 컨텍스트에 맞는 신뢰성 있는 데이터 소스로 취급할 수 있습니다.
지금까지 저는 데이터 레이크를 기업 전체의 데이터를 통합하는 단일 지점으로 설명했지만, 이것이 원래 의도된 것은 아니라는 점을 이야기해야겠습니다. 데이터 레이크는 James Dixon이 2010년에 처음으로 쓴 표현인데, 그의 의도는 데이터 레이크가 하나의 데이터 소스로 사용되는 것이고, 여러 개의 데이터 소스가 ‘water garden’으로 형성되는 것이었습니다. 이런 기원에도 불구하고, 지금은 일반적으로 데이터 레이크가 많은 데이터 소스들을 통합하는 것으로 사용되고 있습니다. [2]
데이터 레이크를 분석 목적으로만 사용하고 운영 시스템들 간의 연동을 위해 사용해서는 안됩니다. 운영 시스템과의 연동은 이 목적으로 설계된 RESTful HTTP 호출이나, 비동기 메시징 같은 서비스들을 이용해야 합니다. 데이터 레이크는 운영용 통신망으로 사용 하기에는 너무 복잡합니다. 데이터 레이크의 분석으로 인해 새로운 운영 통신 경로가 만들어질 수 있지만, 이런 것들은 데이터 레이크를 통해서 하기보다는 직접 구축해야 합니다.
데이터 레이크로 유입되는 모든 데이터가 장소와 시간에 대해 명확한 출처를 가져야 한다는 것은 매우 중요합니다. 모든 데이터에는 데이터가 어떤 시스템으로부터 유입되었는지, 그리고 언제 데이터가 생성되었는지에 대한 명확한 흔적이 있어야 합니다. 그러므로 데이터 레이크는 역사적인 기록을 포함합니다. 이런 기록들은 아마도 Event Sourced 시스템과 자연스럽게 어울리는 도메인 이벤트들을 데이터 레이크에 저장할 때 발생할 것입니다. 하지만, 현재의 상태를 데이터 레이크로 정기적으로 덤핑 하는 시스템에서도 역시 발생할 수 있습니다(소스 시스템에 시간과 관련된 것은 없지만, 시간에 따른 데이터 분석이 필요할 때 유용한 접근방식). 이에 따른 결과로, 데이터 레이크에 입력된 데이터는 변경되지 않고, 한 번 기술된 기록은 삭제될 수 없으며(나중에 잘못된 것으로 판별될 수는 있지만), Contradictory Observations(모순된 관찰)를 예상해야만 합니다(예를 들어, 같은 id로 처음에 들어온 값과 나중에 들어온 값이 달라질 수 있는 문제).
데이터 레이크는 스키마가 없으므로, 어떤 스키마를 사용할지는 소스 시스템에 달려 있고, 스키마가 없음으로 인해 발생하는 혼란을 처리하는 방법은 데이터 소비자가 결정해야 합니다. 게다가 소스 시스템은 자신이 유입시키는 데이터 스키마를 자유롭게 변경할 수 있으며, 소비자는 이에 대처해야 합니다. 당연히 우리는 가능한 한 최소한의 영향을 미치는 변화를 선호하지만, 데이터 과학자들은 데이터를 잃어버리는 것보다는 차라리 지저분한 데이터를 선호합니다.
데이터 레이크는 매우 커질 것이고, 저장소의 대부분은 스키마 없는 큰 규모의 구조를 지향합니다. 이것이 일반적으로 사람들이 데이터 레이크를 구현하는 기술로 하둡과 HDFS를 사용하는 이유입니다. 레이크쇼어 마트들의 중요한 작업 중 하나는 처리해야 하는 데이터의 양을 줄이는 것입니다. 그렇게 함으로써 대용량 데이터 분석에서는 많은 양의 데이터를 처리할 필요가 없게 됩니다.
원시 데이터의 범람에 대한 데이터 레이크의 욕망은 개인정보와 보안에 관해 난처한 질문을 야기합니다. Datensparsamkeit(독일어. 데이터를 캡처하고 저장하는 방법에 대한 자세로서 우리가 실제로 필요한 데이터만 처리해야 한다는 내용)의 원칙은 모든 데이터를 캡처하려는 데이터 과학자들의 욕구와 대치됩니다. 데이터 레이크는 공개된 바다를 선택하는 것을 좋아하는 크래커들에게 유혹의 대상이 됩니다. 소규모 데이터 과학 그룹에 한해서 데이터 레이크에 직접 접근하도록 제한하면 이 위협이 줄어들지만, 이 그룹이 항해 중인 데이터의 개인 정보 보호에 대해 어떻게 책임을 질 수 있는지에 대한 질문을 피할 수 없습니다.
Note
1 : 데이터 마트는 조직에서 단일 부서를 위한 것인 반면, 데이터 웨어하우스는 전 부서를 아우르는 통합을 위한 것이 일반적인 구분입니다. 데이터 웨어하우스가 모든 데이터 마트의 조합이 되어야 하는지, 아니면 데이터 마트를 데이터 웨어하우스에 존재하는 데이터의 논리적 하위 집합(뷰)으로 볼 것인지에 대해서는 서로 다른 의견들이 존재합니다.
2 : 이후의 블로그 포스트에서 Dixon은 데이터 레이크와 ‘water garden’의 구별을 강조하지만, (주석에서) 그것은 사소한 변화라고 말합니다. 제가 생각할 때 핵심은 데이터 레이크가 많은 양의 데이터를 가공되지 않은 상태로 저장한다는 것이고, 피더 스트림의 수는 별로 중요하지 않다는 것입니다.
감사 인사
Danielo Sato, David Johnston, Derek Hammer, Duncan Cragg, Jonny Leroy, Ken Collier, Shripad Agashe 및 Steven Lowe에게 내부 메일링 리스트에서 이 게시물의 초안을 논의한 것에 대해 감사의 말을 전합니다.
보다 빨리 지앤선의 여러 프로젝트 소식을 접하고 싶다면 https://www.facebook.com/JiandSon/을 팔로우 해 놓으면 된다. 아울러, http://jiandson.co.kr/를 통해 뉴스레터를 신청하여 소식을 접할 수도 있다.
