[Datalake] 20210427 - Datalake의 한계 및 극복 방안
:lake:
앞서 데이터 레이크가 무엇이고 데이터 레이크가 가져야 하는 특성들을 매~우 간략하게 확인해 보았다. 책에는 상세하게 데이터 레이크가 가져야 할 특성들이 나열되어 있다. 이것을 그냥 옮기는 것은 크게 의미가 없을 것으로 생각되어 데이터 레이크의 구축 절차(로드맵)에서 그 항목들을 녹여볼까 한다.
데이터 레이크 구축절차
- 인프라 구축 (Hadoop 클러스터 / public, private 클라우드 기반 아키텍쳐 구성)
- 데이터 레이크 구조화 (다양한 조직/프로젝트를 위한 영역 설정과 데이터 적재)
- 셀프 서비스가 가능하도록 데이터 레이크 설정 (카탈로그, 권한, 데이터 보안, 데이터 탐색 등)
- 사용자에게 데이터 레이크 공개(오픈!!)
1. 인프라 구축
이미 많은 기업에서 데이터 레이크를 가지고 있다. 그 모습은 매우 다양한데 오픈소스 또는 상용버전(Cloudera 등)의 하둡 클러스터를 구성하여나 클라우드 기반으로 데이터 레이크를 구축한다. 그 용도와 모습(아키텍쳐)가 매우 다양한데 무엇이 옳은 데이터 레이크고 어느 것이 옳지 않은 데이터 레이크라고 이야기 할 수 없다. 그렇기 때문에 최근에 이러한 것을 논리 데이터 레이크 라고 개념화 한다.
- 논리 데이터 레이크 : 복수의 다차원 시스템에 구성된 가상 데이터 레이크 레이어를 통합하여 일컫는다.
- 온프라미스 데이터 레이크 : Hadoop 또는 대량의 데이터 저장소를 기반으로 데이터 레이크를 구성한 경우. 데이터 레이크 저장소가 하둡으로 구성
- 클라우드 데이터 레이크 : 클라우드 기반으로 데이터 레이크로 데이터 레이크 저장소가 클라우드 스토리지로 구성
2. 데이터 레이크 구조화
모든 경우에 동일하게 적용될 수는 없겠지만 일반적으로 데이터 레이크는 아래와 같은 특성을 고려하여 구조화 되어 있다.
- 초기에 적재되는 진입/Stage영역 원천 데이터는 데이터를 가공없이 원래 상태와 동일하게 유지한다.
- 그 다음 생산/Gold영역 에서는 처리되고 정화된 데이터를 보관한다.
- 진입 영역에서 민감 데이터는 별도의 민감/Secure영역으로 분리하여 저장한다.
- 개발/작업Work 영역에서 데이터 과학자나 데이터 엔지니어가 작업할 수 있도록 한다. 이 영역은 사용자별, 프로젝트별, 내용별 등의 각 비즈니스에 맞추어 나눈다. 작업영역에서 분석 작업이 끝나고 나면 데이터는 다시 골드 영역으로 옮겨진다.
(각 영역의 명칭은 책의 내용과 경험을 참고하여 설정하였다. 책에서는 진입,골드,민감,작업으로 구분한다)
비즈니스 및 조직구조에 따라 다르겠지만 사용자 집단 별로 서로 다른 영역을 활용하게 된다.
- 데이터 엔지니어는 주로 [ 진입영역 ➡️ 생산영역 ] 에서 데이터 가공처리 작업을 수행하게 된다. (일반적으로 ETL 도구 등을 통해 배치로 등록한다.)
- 비즈니스 분석가/과학자는 주로 [ 생산영역 ➡️ 개발/작업 영역 ] 에서 작업을 수행하게 된다. (과학자는 실제로 모든 영역을 활용할 수 있지만, 현 시점의 역할을 반영하여 이렇게 정리하였다. )
- 데이터 관리자는 주로 [ 생산영역, 민감영역] 에서 사내/정부의 보안 정책 등을 검토한다.
3. 셀프 서비스
셀프는 우리나라 사람에게는 매우 익숙한 외국어 일 것이다. 많은 식당에서 ‘물을 셀프입니다’를 찾아 볼 수 있듯이 데이터 분야에서의 셀프 서비스는 ‘데이터는 셀프입니다’ 를 의미하는 것이다. 즉, 분석가가 데이터를 찾고 전처리해서 분석에 활용할 수 있도록 서비스를 제공하는 것이다.
데이터 분석은 일반적으로 아래와 같이 4 단계의 프로세스로 이루어진다.
- 데이터 검색 및 이해
- 데이터 확보
- 데이터 전처리
- 데이터 분석
과거에는 (3.데이터전처리) 와 (4.데이터분석) 그리고 더 나아가 (2.데이터 확보)에 중점을 두어 작업을 진행하였다. 하지만 많은 데이터가 확보되고 난 뒤 실제로 데이터를 활용하고자 했을 때 앞서 이야기한 데이터 늪에 빠져버릴 수 있다. 따라서 저장된 데이터를 효율적으로 검색하고 그 데이터에 대한 이해를 도와주는 것이 데이터 레이크의 핵심 기능으로 떠올랐다. 실제로 1,2,3 단계에서 분석가들이 전체 시간 중 80%를 소비한다는 연구 결과도 있었다. 그리고 1단계에서 가장 많은 60%의 시간을 사용하는 것으로 나타났다. ( Boost Your Business Insights by Converging Big Data and BI - Boris Evelson)
예를들어 이미 수천개의 DB를 가진 기업이 있고 각 DB에 100개의 테이블이 존재하며, 각 테이블은 또 10개가 넘는 필드 값들을 가지고 있다고 가정하자. 이런 경우 분석가들은 이 DB들로부터 적재되어 데이터 레이크에 구성된 ‘데이터셋’이 뭘 의미하는지 찾기 거의 불가능이다. 결국 많은 시간을 들여 스스로 데이터를 이해해야 하고 그 정보들은 가까이 있는 또 다른 분석가들에게만 전파되게 된다. 이러한 정보를 부족지식(tribal knowledge) 이라고 한다. 그 옛날의 게임 퀘스트를 하는 것 처럼 분석가들은 데이터셋에 대한 정보를 여기저기 돌아다니며 찾아내야 한다.
이런 문제를 해결하기 위해 크라우드소싱 분석(analyst crowdsourcing) 를 하기 위한 도구들이 등장하고 있다. 이것은 분석가가 비즈니스 용어로 이루어진 간단한 문구를 가지고 데이터셋을 설명하기 위한 메타정보를 작성하여 데이터셋 탐색에 도움을 줄 수 있는 도구를 말한다. 데이터를 처리하고 저장할 때 이러한 메타정보를 같이 입력할 수 있도록 제안한다. 이러한 분석 방법을 사용하는 경우 이미 데이터를 처리하는 사람 모두가 데이터 분석가의 역할을 수행할 수 있다. 이러한 방법을 사용하는 기업은 구글, 링크드인과 같은 비교적(?) 신생 기업이다.
전통적인 기업들은 메타가 없는 이미 많은 데이터셋이 만들어져 있기 때문에 기존 데이터에 대해 크라우드소싱 분석을 하기 어렵다. 따라서 신규 데이터에 대한 크라우드 소싱 방법과 기존 데이터에 대한 메타 추천 시스템 등을 도입하고, 데이터셋에 대한 메타 부여 제안의 수락 여부를 학습하여 또 다시 추천 시스템을 개선하는 방법 등을 사용한다. 이러한 방법은 Informatica 등에서 상용 솔루션으로 제공하고 있다.
📘 책의 방대한 지식을 잘 녹여서 전달하는 것은 무리이지만, 그래도 내 나름대로의 언어로 풀어 설명하려고 노력중이다. 쉽지가 않지만 그래도 재미있다.