Data Lake의 주요 속성들

빅데이터 저장소(Big Data Repository)가 진정한 Data Lake로 분류되기 위해서는 3가지 주요 특징을 제시해야 합니다.

O. 일반적으로 HDFS(Hadoop Distributed File System)내 저장된 하나의 공유된 데이터 저장소이어야 합니다.

Hadoop Data Lake는 데이터를 원래의 형태대로 저장하고, 데이터 생명주기(Data Lifecycle)동안 데이터와 문맥적 의미 변화를 보존합니다. 이러한 접근 방법은 전통적인 EDW와는 다르게 규정 준수(compliance)와 내부 감사 활동에 특히 유용합니다. 전통적인 EDW에서는 데이터의 변환, 집계, 변경이 일어나는 경우, 필요할 때 데이터를 취합하는 것이 어렵습니다. 그리고 조직은 데이터의 기원을 찾기 위해 몸부림칩니다.

O. 오케스트레이션(Orchestration) 및 작업 스케쥴링(Job Scheduling) 기능을 포함하고 있어야 합니다.(예를 들면, YARN을 통해서)

Workload 실행은 Enterprise Hadoop의 전제 조건입니다. YARN은 리소스 관리와 일관된 운영, 보안, Hadoop Cluster 전반에 대한 데이터 거버넌스 툴이 있는 중앙 플랫폼을 제공합니다. 확실한 분석 워크플로우(workflow)는 필요한 데이터와 컴퓨팅 성능에 접근할 수 있습니다.

O. 데이터를 사용하고, 처리하고, 동작하는 일련의 어플리케이션과 워크플로우들을 포함하고 있어야 합니다.

쉬운 사용자 접근은 조직이 데이터의 원래 행태대로 보존한다는 사실 때문에 Data Lake의 주요 특징 중 하나입니다. 정형/비정형/반정형에 상관없이 데이터는 로딩되고 있는 그대로 저장됩니다. 데이터 소유자들은 데이터를 공유하는데 있어서 기술적인-심지어 정책적인- 장애물(roadblock)을 제거하고 고객, 공급업체, 운영 데이터들을 쉽게 통합할 수 있습니다.

전통적인 EDW의 단점

전통적인 EDW의 schema-on-write의 주요 단점 중 하나는 데이터를 준비하기 위해 많은 시간과 비용이 들어간다는 것입니다.  주요 EDW 프로젝트를 위해서는 값비싼 데이터 모델링이 필요합니다. 많은 조직이 표준을 만족시키고 심사숙고하는 표준화위원회에 투자하고, 작업을 완료하여 손을 놓기 까지 수개월이나 수년이 걸리기도 합니다.

이 위원회는 많은 선행작업을 해야 합니다. 우선 해결하고자 하는 문제들에 대한 윤곽을 그려야 합니다. 그 후, 문제를 해결하기 위해 데이터에 필요한 질문이 무엇인지 결정해야 합니다. 그것으로부터 그 질문을 지원할 수 있는 데이터베이스 스키마를 설계합니다. 한번 스키마 설계가 끝나고 나면, 새로운 데이터 소스에서 가져오는 것이 너무 어렵기 때문에 위원회는 어떤 정보가 포함되고, 어떤 정보가 빠져야 하는지 결정하는데 굉장히 많은 시간을 보냅니다. 위원회가 특정 쟁점에 대해서 몇 주 혹은 몇 개월을 보내는 것은 드문 일이 아닙니다.

이러한 접근 방법에서는 비즈니스 분석가와 데이터 과학자는 데이터에 대해 즉각적인 질문을 할 수 없습니다. 예정보다 빨리 가설을 세워야 하고, 데이터 구조를 만들고, 이러한 가설들을 테스트하여 분석해야 합니다. 유감스럽게도 단지 분석 결과들이 데이터를 반환하도록 설계되었다는 것입니다. 이러한 이슈는 원래의 가설이 맞다면 특별히 중요하지 않습니다. 하지만, 가설이 잘못되었을 경우에는 어떨까요? 단지 끊임없이 이동하는 비즈니스 환경에서는 실용적이지 않은 가정에 맞추고 가장 숙련된 비즈니스 종사자도 놀라게 하는 폐루프 시스템(closed-loop system)을 만들었을 뿐입니다.

Data Lake는 이러한 모든 문제를 해결합니다. 데이터 모델링이나 표준화 없이 정형/비정형 데이터를 쉽게 저장할 수 있습니다. 기존 데이터베이스의 정형 데이터는 대부분 자동화된 프로세스로 Data Lake의 행에 배치됩니다. 분석가는 할당하기 위하여 일반적으로 원래 표 정보에서 가져온 태그 및 태그 그룹을 선택합니다. 같은 데이터 조각에 여러 태그를 붙일 수 있습니다. 또한 태그들은 언제든지 변경되거나 추가될 수 있습니다. 저장할 스키마가 사전에 정의될 필요가 없기 때문에 값비싸고 시간을 소모하는 모델링이 필요하지 않습니다. 

대부분의 회사에서는 Enterprise Data Warehouse(이하 EDW)에 중요한 비즈니스 데이터를 저장하고 있습니다. EDW는  

Customer Relationship Management(CRM:고객관계관리), 재고, 판매 거래 시스템과 같은 기업용 시스템으로부터 비즈니스의 정화(essence of business)를 수집하기 위해 고안되었습니다.

그리고 인사이트(insight)를 얻거나 데이터를 기반으로 중요한 사업적 의사결정을 하기 위해 분석가들과 사업 의사결정자(business user)들이 이용합니다.

하지만, Web이나 IoT로 연결된 디바이스에서 나오는 스트리밍이나 소셜 데이터를 포함하여 새로운 기술들이 훨씬 더 큰 데이터 볼륨, 더 높아진 사용자의 기대, 빠른 사업의 글로벌화를 만들고 있습니다.

전통적인 EDW 기술로는 새로운 비즈니스 요구사항들을 만족시킬 수 없다는 것을 기업들이 깨닫고 있습니다.

결과적으로 많은 기업들이 Apache Hadoop으로 돌아서고 있습니다.

전통적인 EDW에서 한가지 주요 단점은 데이터를 EDW에 넣기 위해 필요한 근본적인 extract, transform, load(ETL) 프로세스의 기반인 schema-on-write architecture입니다.(schema-on-write : 데이터를 쓰기 위해 데이터베이스에 미리 schema를 생성하는 전통적인 기술) Schema-on-write에서는 데이터를 로딩하기 전에 모델을 설계하고 분석 프레임워크를 연계해야 했습니다. 다시 말하면, 데이터를 어떻게 사용할 것인지를 사전에 파악해야 했습니다.

이에 대응하여 기업들은 타협안을 찾았습니다. 전통적인 EDW에서 필요한 첫번째 데이터 변환없이 데이터를 추출하여 Hadoop 기반 저장소에 데이터를 저장했습니다. 무엇보다도 Hadoop의 가장 좋은 점은 분석이 필요할 때 데이터를 데이터베이스로 내리면 된다는 것입니다. 모든 프레임워크는 사전에 요구되는 작업이 거의 없이 즉석에서 만들 수 있습니다.

기업들은 이제 Data Lake로 전환하고 있습니다.

우연히 무료로 풀린 Architecting Data Lake (저자 : Alice LaPlante & Ben Sharma. 출판사 : 미국의 기술서적 전문 출판사인 O'Reilly Media, 2016년)를 보게 되었습니다.

대용량 데이터 처리 시대에 Data Lake는 우리 주변에서 자주 접하는 용어입니다만, 개발자 개인이 일반 현장에서 실제로 적용하며 경험해 보기에는 쉽지 않은 영역입니다. 바로 대용량 데이터가 필요하기 때문입니다.

예나 지금이나 대용량 데이터는 수많은 고객들을 상대로 성공한 서비스나 플랫폼, 디바이스들을 보유한 회사에서나 만져볼 수 있습니다. 소위 Enterprise 환경에서나 대용량 데이터에 대한 수행 경험을 쌓을 수 있다는 뜻입니다.

마침, 최근에 IoT의 한 분야라고 할 수 있는 에너지 관련하여 람다 아키텍처가 적용된 Data Lake 시스템을 Hadoop 기반으로 설계를 한 적이 있습니다. 그때의 경험과 Architecting Data Lake라는 책을 읽으며 중요한 부분만을 요약하여 많은 분들과 공유를 해보고자 합니다.

물론 O'Reilly사에 허락을 받지는 않았습니다만, 모든 사람들 대상으로 무료 Ebook으로 풀었으니 저작권 문제가 없을 거라고 혼자서 가정을 했습니다. 저작권 문제가 있다면 지우거나 공유를 취소해야겠죠. 관련 지식을 함께 나누고자 하는 의도로 O'Reilly사에서도 무료로 전체 오픈을 한 것이라고 믿고, 저도 또한 많은 분들과 자유롭게 관련 지식을 공유하고 싶어서 시작해 봅니다.