(문제는 나중에 다룸)

첫번째 옵션은 이슈를 무시하고, Hadoop에 자유롭게 데이터를 로딩하는 많은 조직에서 선택합니다. 나중에 데이터에서 insight(통찰력)를 발견할 필요가 있을 때, 당면한 문제에 관련된 데이터를 정리하는 툴을 찾으려고 합니다.

하지만, 여기에는 실제적인 리스크가 있습니다.

우선 첫째로, 가장 지능적인 추론엔진조차도 Data Lake를 만들 수 있는 엄청난 양의 데이터를 가지고 시작해야 합니다. 이것은 필연적으로 일부 데이터를 무시해야 함을 의미합니다. 따라서 Data Lake의 일부가 정체되고 고립될 수 있으며, 가장 똘똘한 자동화 도구나 데이터 분석가일지라도 어디서부터 시작해야 하는지 알지 못하는, 거의 맥락이나 구조를 가지고 있지 않은 데이터를 포함할 수 있는 위험이 있습니다. 데이터 품질이 나빠지고, 동일한 Hadoop Cluster에서 동일한 질문에 서로 다른 답을 얻게 되는 상황에 처하게 됩니다.

(Data Lake에서의 데이터 관리 및 거버넌스)

만약 업무 요건 때문에 중요한 업무용(mission-critical) 목적으로 데이터를 사용한다면, 데이터 관리와 거버넌스를 심각하게 고려해야 합니다. 전통적으로, 조직에서는 공식적인 프로세스와 엄격한 접근 통제를 위해서 EDW를 사용했기 때문입니다. 하지만, 이미 논의한 것처럼, 증가하는 데이터 볼륨과 다양성은 EDW의 수용 용량을 압도합니다.

단순히 Data Dump를 수행하기 위해 Hadoop을 사용하는 극단적인 경우는 데이터의 중요성 때문에 불가능합니다.

초기에 Hadoop을 사용하던 때, 조직은 데이터를 어떤 식으로든 관리하지 않고 자주 로딩했습니다. 특히 빠르고 싸기 때문에, 대부분의 경우에 비록 여전히 이렇게 접근하기를 원할지라도 이러한 형태의 data dump는 최적의 경우가 아닙니다. 데이터가 표준화되어 있지 않은 경우에는 오류가 용납되지 않을 때나 데이터의 정확도가 굉장히 우선 순위가 높을 때, data dump는 데이터에서 가치를 이끌어 내고자 하는 노력에 비해 얻는 것이 없을 것입니다.

Data Lake는 중간 지점을 제공합니다. Hadoop Data Lake는 유연하고, 확장성이 있으며, 비용 효율적입니다. 하지만, 그 외에도 전통적인 EDW의 규제도 가질 수 있습니다. 단순히 Data Lake에 데이터 관리와 거버넌스를 추가하면 됩니다. 한번 이렇게 접근하기로 결정하면, 수행에 있어서는 다음 4가지 옵션이 있습니다.

(Data Lakes 비즈니스 사례)

EDW는 많은 조직에서 복잡한 분석, 보고, 운영을 수행하기 위한 주요 메커니즘이었습니다. 하지만, EDW는 거대한 데이터 볼륨과 광범위한 데이터의 다양성이 표준이 되는 빅데이터 시대에 너무 까다로워서 작업하기 어렵습니다. EDW의 데이터 모델을 변경하는 것은 어려운 일이고, 필드간 통합 매핑은 경직되어 있습니다. 또한, EDW는 비쌉니다.

아마도 더 중요한 것은, 대부분의 EDW가 데이터를 다루고, 강화하기 위해서 비즈니스 사용자들이 IT에 의존하는 것을 크게 요구한다는 것입니다. 왜냐하면 유연하지 못한 설계, 복잡한 시스템, EDW상의 Human Error에 대해 용납이 되지 않는 환경이기 때문입니다.

Data Lake는 이러한 모든 문제들을 해결합니다. 결과적으로 거의 모든 산업에서 잠재적인 data lake 사용 사례를 가지고 있습니다. 예를 들면, 조직은 더 나은 데이터 가시성을 얻기 위해서, 데이터의 Silo를 제거하고, 고객에 대한 360도 뷰를 포착하기 위해 data lake를 사용할 수 있습니다. 끝으로, data lake를 통해서 조직은 산업 전반에 걸쳐 빅데이터의 잠재력을 발휘할 수 있습니다.

Freedom from the rigidity of a single data model

(단일 데이터 모델의 엄격함으로부터의 자유함)

데이터는 구조적인 경우 뿐만 아니라, 비 구조적일 수도 있기 때문에 블로그 포스팅부터 상품 리뷰까지 모든 것을 저장할 수 있습니다. 또한, data lake에 저장된 데이터는 일관성을 유지할 필요가 없습니다. 예를 들면, 데이터를 제공하는 사람에 따라서 동일한 유형의 정보를 굉장히 다른 데이터 형태로 받을 수 있습니다. 이것은 EDW에서는 문제가 될 수 있습니다. 그러나 data lake에서는 서로 다른 데이터 셋트 사이의 통합 포인트 정의에 대한 스키마 걱정 없이 모든 종류의 데이터를 하나의 저장소에 넣을 수 있습니다.

Ability to handle streaming data

(스트리밍 데이터 처리 능력)

오늘날 데이터 세계는 스트리밍 세계입니다. 스트리밍은 IoT의 센서 데이터나 주식 시장 데이터와 같은 드문 경우에서부터 소셜 미디어의 매우 일상적인 데이터까지 발전해 왔습니다.

Fitting the task to the tool

(작업을 도구에 맞추는 것)

EDW에 데이터를 저장할 때, 특정 종류의 분석 업무를 잘 수행할 수 있습니다. 그러나 Spark, MapReduce나 다른 새로운 모델을 사용하는 경우에는 EDW에서 분석할 데이터를 준비하는 것이 실제 분석을 수행하는 것보다 더 많은 시간이 걸릴 수 있습니다. Data lake에서는 과도한 사전 작업 없이 이러한 새로운 패러다임 도구들을 사용하여 데이터를 효율적으로 처리할 수 있습니다. Data lake가 엄격한 메타데이터 스키마를 적용하지 않기 때문에 더 적은 단계로 데이터를 통합할 수 있습니다. 사용자는 Schema-on-read를 통해 쿼리 실행 시에 수행되는 쿼리에 사용자 지정 스키마를 적용할 수 있습니다.

Easier accessibility

(더 손쉬운 접근성)

Data lake는 EDW를 괴롭히는 데이터 통합과 접근성 문제를 해결합니다. Big Data Hadoop 인프라를 사용하면, 분석을 위해 보다 더 큰 데이터 볼륨을 사용할 수 있고, 나중에 사용하기 위해 아직 미확인 상태로 그 데이터를 간단히 저장할 수 있습니다. 단일 엔터프라이즈 차원의 데이터 모델에 대한 monolithic 뷰와는 달리, data lake는 실제로 데이터를 사용할 때까지 모델링을 미룰 수 있으므로 더 나은 운영 통찰력과 데이터 검색 기능을 가질 수 있습니다. 이러한 장점은 데이터 볼륨과 다양성, 메타데이터의 풍부함이 증가할수록 커집니다.

Reduced costs

(비용 절감)

규모의 경제 때문에 일부 Hadoop 사용자들은 Hadoop Cluster로 인해 테라바이트 당 1000달러 미만을 지불한다고 주장합니다. 비록 숫자는 다를 수 있지만, 비즈니스 사용자들은 모든 데이터를 저장하는데 들어가는 비용이 그렇지 비싸지 않기 때문에 나중에 분석하고 검색하기 위해서 모든 데이터 복사본을 Hadoop에 간단히 저장할 수 있음을 이해하고 있습니다.

Scalability

(확장성)

빅데이터는 일반적으로 볼륨, 다양성, 속도 사이의 교차점으로 정의됩니다. EDW는 아키텍처의 제한 사항으로 인해 특정 볼륨 이상으로 확장이 어려움은 익히 알려져 있습니다. 데이터 처리 시간이 너무 오래 걸리기 때문에 조직에서 데이터를 최대한 활용하는데 제한이 있습니다. Hadoop을 사용하면 페타바이트 크기의 Data Lake를 비용 효율적이고 상대적으로 간단히 구축할 수 있고, 원하는 규모가 무엇이건 유지할 수 있습니다.

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의 행에 배치됩니다. 분석가는 할당하기 위하여 일반적으로 원래 표 정보에서 가져온 태그 및 태그 그룹을 선택합니다. 같은 데이터 조각에 여러 태그를 붙일 수 있습니다. 또한 태그들은 언제든지 변경되거나 추가될 수 있습니다. 저장할 스키마가 사전에 정의될 필요가 없기 때문에 값비싸고 시간을 소모하는 모델링이 필요하지 않습니다.