엔터프라이즈 빅데이터 레이크.md

서평

• 
• Kimball의 다차원 모델링에 대해 공부하던 중 DW에 관심을 가지게 되었고 DW와 Data Lake, Data Fabric의 차이에 대해서 공부를 하게 되었습니다. 공부를 하면서 데이터 레이크에 대해 조금 더 자세하게 알아보고자 이 책을 선택하게 되었습니다.
• 이 책은 데이터 레이크의 아키텍처와 장점, 데이터 레이크를 도입할 때의 어려움과 그런 어려움을 극복하는 방법에 대해 설명하고 있습니다.
• 이 책은 데이터 레이크를 데이터 웅더이(분석적인 샌드박스)나 데이터 연못(큰 데이터 웨어하우스)을 바탕으로 확장할 때 활용할 수 있는 여러 접근법뿐만 아니라 아예 바닥부터 구축하는 방법까지 다룸. 사내, 클라우드 기반, 가상 등 다양한 데이터 레이크 아키텍처의 장단점을 살펴보고 있습니다. 미가공, 처리되지 않은 데이터에서부터 잘 관리되고 요약된 데이터까지 유형별로 저장하는 개별 영역을 설정하는 방법과 그런 영역의 접근 권한을 관리하는 방법을 다루고 있으며, 사용자가 스스로 데이터를 찾고 이해하고 준비할 수 있도록 하는 셀프서비스를 가능하게 하는 방법, 사용자의 기술 수준에 따라 적합한 인터페이스를 제공하는 방법, 이 모든 과정을 기업의 데이터 관리 정책을 준수하면서 진행하는 방법 등을 설명하고 있습니다.
• 데이터레이크를 구축하기까지 역사적인 관점에서 데이터웨어하우스와, 데이터 레이크를 다루고 있어서 좋았고 셀프서비스에 대해서도 소개를 해주고 있어서 읽는데 많은 도움이 되었습니다.

데이터 레이크 소개

• 데이터 레이크 성숙도
  • 데이터 웅덩이(data puddle)란 빅데이터 기술을 활용해서 구축한 단일 목적이나 단일 프로젝트용 데이터 마트. 데이터 웅덩이의 데이터는 단일 프로젝트나 팀의 목적을 위해 사용됨
  • 데이터 연못(data pond) : 데이터 웅덩이 여러 개를 모아 놓은 것, 데이터 마트를 모아 놓기만한 모습. 기존에 있던 데이터 웨어하우스에서 사용하지 않는 부분을 모아 놓은 모습. 낮은 기술 비용과 높은 확장성이라는 명확한 장점은 있지만, 여전히 IT에 많이 의존함
  • 데이터 레이크(data lake)는 데이터 연못과는 두 가지 주요 측면에서 차이가 있음. 셀프서비스를 지원하다는 점. 비즈니스 사용자가 IT 부서의 도움 없이 필요한 데이터 세트를 찾아 사용할 수 있음. 당장 어떤 데이터를 요구하는 프로젝트가 없더라도 차후에 비즈니스 사용자가 필요할 수 있는 데이터를 저장하는 것을 목표로 한다는 점
  • 데이터 오션(data ocean)은 해당 데이터가 데이터 레이크에 저장됐는지 여부와 상관없이 데이터가 어디에 있든 기업의 모든 데이터가 셀프서비스와 데이터 주도 결정 과정에 활용될 수 있게 됨
  • 데이터 연못과 데이터 레이크의 주요 차이는 무엇을 목표로 하는가. 데이터 연못은 원래 있던 데이터 웨어하우스나 데이터 마트를 상대적으로 비용이 저렴하고 확장성이 좋은 방법으로 대체함. 데이터 레이크는 일상적인 생산에 사용할 준비가 완료된 쿼리를 목표로 함. 데이터 레이크는 비즈니스 사용자가 다양한 데이터와 도구를 사용해서 즉흥적인 분석이나 실험을 통해 데이터를 활용해서 스스로 결정할 수 있게 해줌
• 데이터 웅덩이
  • 데이터 웅덩이는 주로 소규모 팀이나 특수한 사용 사례를 목적으로 구축함
  • 단일팀에게 작업 공간을 제공해서 데이터 과학자가 실험할 수 있게 하려고 사용하는 경우도 많음. 이런 작업 공가능ㄴ 샌드박스(sandbox)라고 부름
  • 데이터 운덩이는 목적이 한정적이고 저장하는 데이터 유형도 제한적. 크기도 작은 전용 데이터 스트림(data stream)으로 구성되며 구축하고 유지 보수하려면 기술 수준이 높은 팀이나 IT의 적극적인 지원이 필요함
• 데이터 연못
  • 데이터 연못은 데이터 웅덩이 여러 개를 모아 놓은 것
  • 데이터 연못은 빅데이터 기술로 구축한 데이터 웨어하우스로 생각할 수 있음
• 성공적인 데이터 레이크 구축
  • 올바른 플랫폼
    • 데이터 레이크를 도입하는 데 가장 많이 활용하는 기술로는 하둡과 같은 빅데이터 기술, 아마존 웹 서비스, 마이크로소프트 애저, 구글 클라우드 플랫폼과 같은 클라우드 솔루션이 있음
    • 용량
      • 스케일 아웃(scale out)하도록 설계됨. 성능의 특별한 저하 없이 스케일(즉 규모)을 무한정에 가깝게 늘릴 수 있음
    • 비용
      • 테이프, WORM 디스크, 하드디스크 드라이브 등을 활용해서 많은 데이터를 비교적 저렴한 저장 장치에 보관할 능력은 예전부터 있었음
    • 다양성
      • 다양한 파일 형태를 저장할 수 있게 해주는 파일 시스템(file system)이나 오브젝트 스토어(object store)를 사용함. 하둡 HDFS, MapR FS, AWS 등의 단순 저장 서비스(S3, Simple Storage Service) 등이 여기에 해당됨.
      • 데이터 구조가 사전에 정의돼야 하는 (저장 시점 스키마 적용) 관계형 데이터베이스와는 달리 파일 시스템이나 오브젝트 스토어는 데이터를 어떻게 쓰든 상관하지 않음. 읽는 시점 스키마 적용, 마찰 없는 주입이 간으하게 함
      • 데이터를 스키마에 맞게 데이터베이스가 기대하는 형태로 전환하기 전까지는 데이터를 저장할 수 없는 관계형 데이터베이스와는 달리 데이터를 아무런 처리 없이 저장할 수 있음
    • 미래 대비
      • 하둡과 기타 빅데이터 플랫폼은 모듈 형태로 활용하기 매우 용이함
  • 올바른 데이터
  • 올바른 인터페이스
• 데이터 늪(data swamp)
  • 데이터 늪은 데이터 레이크만큼 커진 데이터 연못이지만 분석가에게 매력적으로 다가가는 데 실패한 경우. 셀프서비스와 관리 시설의 부족 때문
• 성공적인 데이터 레이크 로드맵
  • 인프라 구축(하둡 클러스터를 설치하고 실행)
  • 데이터 레이크 구조화(다양한 사용자 집단을 위한 영역 설정과 데이터 삽입)
  • 셀프서비스가 가능하도록 데이터 레이크 설정(데이터 자산 카탈로그를 만들고, 권한을 설정하고, 분석가가 쓸 수 있는 도구 제공)
  • 사용자에게 데이터 레이크 공개
• 데이터 레이크 구축
  • 논리 데이터 레이크란 복수의 다차원 시스템에 구성된 가상 데이터 레이크 레이어(data lake layer)
  • 근간이 되는 시스템은 하둡, 관계형, NoSQL 데이터베이스고, 사내 혹은 클라우드에 존재할 수 있음
• 데이터 레이크 구조화
  • 다중 모델 IT란 간단히 말해 관리는 데이터 사용 방법과 사용자 집단의 요구 사항을 반영할 필요가 있다는 생각
• 셀프 서비스를 위한 데이터 레이크 설정
  • 데이터 검색과 이해
    • 부족 지식(tribal knowledge) : 해당 지식이 있기는 하지만 지식이 부족 전체에 퍼져 있어 고토으럽고, 오래 걸리고, 잘못된 가능성이 높은 발견 과정을 거쳐 재결합돼야 함
    • 크라우드소싱 분석(analyst crowdsourcing) : 분석가가 비즈니스 용어로 이뤄진 간단한 문구를 갖고 데이터 세트 관련 문서를 작성하고 필요한 것을 찾는 데 도움이 되는 검색 인덱스(search index)를 만들면서 부족이 가진 지식을 수집할 수 있게 해줌
    • 워터라인 데이터(Waterline Data) : 분석가가 자신의 데이터 세트를 갖고 일할 때 만드는 정보를 크라우드소싱으로 받아 관련 문서가 없는 다른 데이터 세트에 적용할 수 있게 해줌. 이런 과정을 핑거프린팅(finger printing)
  • 데이터 접근과 권한 설정
    • 모든 사람에게 모든 데이터에 관한 권한을 주거나 분석가가 필요성을 증명할 수 있는 경우를 제외하고는 모든 접근 권한을 막는 방법
    • 메타데이터(metadata) 카탈로그로 모든 데이터 세트에 관한 정보를 공개해서 분석가가 필요한 데이터 세트를 찾고 필요한 접근 권한을 요청하게 하는 것. 권한 요청에는 일반적으로 권한이 왜 필요한지, 데이터를 어떤 프로젝트에 쓸지, 권한이 필요한 기간은 언제인지 등을 명시함
  • 데이터 준비
    • 트리팩타(Trifacta)와 같은 일부 도구는 변환 방법을 추천하고 분석가가 데이터를 준비하는 과정을 지원하고자 정교한 머신러닝 기술을 적용하고 있음
• 데이터 레이크 아키텍처
  • 데이터 자주권 규정(ex- 독일에서는 데이터를 갖고 나갈수 없음)과 회사의 압박 등 여러 가지 상황상 복수의 데이터 레이크를 사용하는 것이 더 좋은 방법이라는 것이 받아들여지게 됐음
  • 대규모 병령 클러스터를 지원하는 것이 얼마나 복잡한지, 경험이 있는 하둡이나 기타 빅데이터 플랫폼 관리자를 찾는 것이 얼마나 어려운지 느끼면서 회사들은 대부분의 하드웨어와 플랫폼 요소를 전문가가 관리해주는 클라우드 기반 데이터 레이크를 사용하기 시작함
• 상용 클라우드 데이터 레이크
  • 빅데이터 전문성과 짧은 배포 시간뿐만 아니라 낮은 비용과 클라우드가 갖는 탄력성 등의 장점 때문에 클라우드는 매우 매력적
• 논리 데이터 레이크
  • 나중에 누군가가 필요할 경우를 대비해 데이터 레이크에 모든 데이터를 저장하는 대신 카탈로그나 데이터 시각화 소프트웨어를 통해 데이터를 분석가에게 제공함
  • 완전성과 중복 문제
    • 완전성 문제를 위해서는 모든 데이터 자산을 다루는 카탈로그를 만들어 분석가가 기업이 가진 어떤 데이터 세트라도 찾고 요청할 수 있게 함
    • 중복 문제는 다른 곳에 저장되지 않은 데이터를 데이터 레이크에 저장함. 다른 시스템에 저장된 데이터는 필요할 때 데이터 레이크에 옮겨오고, 사용하는 동안 서로 싱크(sync)를 맞춤
    • 각 데이터 세트는 모든 사용자를 위해 한 번만 옮겨옴
• 시각화와 카탈로그 기반 논리 데이터 레이크
  • 시각화는 연방(federation)또는 기업 정보 통합(EII, Enterprise Information Integration)이라고 불리기도 함. 물리적 테이블의 위치와 구현 상황을 숨기는 가상 뷰(virtual view) 혹은 테이블을 만드는 것
  • 기업 전체 카탈로그는 분석가가 기업의 모든 데이터를 찾고 접근할 수 있게 해줄 뿐만 아니라 접근,관리,감시용 단일 접근 통로의 역할도 할 수 있음.
  • 전체 카탈로그가 없다면 데이터 자산 접근이 여러 군데에서 이뤄져 관리하고 추적하기가 어려움. 또한 전체 카탈로그를 쓰면 모든 접근 요청이 카탈로그를 통해 이뤄짐. 접근 요청은 필요에 따라 특정 기간 동안 허가되며 시스템의 감시를 받음

역사적 관점

• 셀프서비스 데이터 욕구: 데이터 베이스의 탄생
  • 데이터는 주의해서 관리하고, 일관성을 유지해야 하며, 정기적으로 백업해야 함
  • 데이터베이스 관리 시스템(DBMS, DataBase Management Systems)이라는 별도의 시스템을 통해 제공하게 됌
  • 관계형 데이터베이스 관리 시스템(RDBMS, Relational DataBase Management Systems)은 사용자가 데이터베이스 데이터를 명확하게 설명할 수 있게 해줌. 사용자는 사람이 읽을 수 있는 형태의 테이블과 필드의 집합인 스키마를 만들게 됨
  • 저장장치에 데이터를 쓰거나 읽는 것은 메모리에서 하는 것보다 훨씬 느리기 때문에 정규화(normalization)라는 스키마 설계 기법을 사용함. 정규화는 데이터를 가능한 한 작은 단위로 나눠서 데이터베이스 업데이트 때 최소한의 데이터만 저장해도 되도록함
  • 정규화는 정보를 중복해서 입력하는 것을 피하고자 테이블을 더 작은 테이블로 나누는 방법
• 반드시 해야 하는 분석: 데이터 웨어하우스의 탄생
  • 큰 데이터 웨어하우스를 데이터 마트(data mart)단위로 분할하거나 쿼리 처리에 사용되는 하드웨어의 최적 활용이 가능하게 하는 기기의 발명, 열 기반, 인메모리 데이터베이스 등이 여기에 해당함
    • ETL(추출, 변환, 로드) 도구와 ELT(추출, 로드, 변환) 도구
    • 데이터 품질(DQ,Data Quality)과 프로파일 도구
    • 데이터 모델링 도구
    • 비즈니스 용어 사전
    • 메타데이터 저장소
    • 데이터 관리 도구
    • 마스터 데이터 관리(MDM, Master Data Management) 시스템
    • 기업 정보 통합(EII), 데이터 연방, 데이터 가상화 도구
  • 보고서와 분석 결과서 생성을 지원하는 도구
    • 보고용 도구
    • 온라인 분석 처리(OLAP, OnLine Analytical Processing) 도구
    • 비즈니스 지능(BI, Business Intelligence) 도구
    • 데이터 시각화 도구
    • 고급 분석 도구
• 데이터 웨어하우스 생태계
  • 데이터 웨어하우스 생태계(ecosystem)에서 데이터가 어떻게 흘러가는지 보여줌
  • 최종 사용자가 필요한 보고와 분석을 받을 수 있도록 나머지 도구는 ETL 개발자, 데이터와 시스템 아키텍트, 데이터 모델 전문가, 데이터 관리자, 보고 및 BI 개발자, 데이터베이스 관리자 등 여러 IT 전문가가 사용함
• 데이터 저장과 쿼리
  • 차원 모델링과 스타 스키마
    • 정규화된 데이터 모델은 중복과 필드 수가 작은 테이블을 만들다 보니 업데이트가 매우 빠르게 이뤄짐
    • 데이터 웨어하우스에서는 일반적으로 정규화하지 않는 데이터 모델을 선호함. 정규화하지 않은 모델에서는 각 테이블에 가능한 한 많은 관련 특성을 저장함. 그러면 필요한 모든 정보를 취합할 때도 데이터를 한 번만 처리해도 됨
    • 스타 스키마(star schema) : 1996년에 발간된 랄프 킴벌, 마기 로스 공저의 The Data Warehouse Toolkit(wiley,2004)1판에서 처음 소개됨. 이 스키마는 몇 개의 차원과 팩트 테이블 집하으로 구성됨
      • 차원 테이블은 분석 대상 요소로 구성됨
      • 팩트 테이블에는 각 차원과 관련된 모든 활동이 기록됨.
      • 거래 팩트 테이블에는 각 주문 건의 개별 항목 각각을 대변하는 레코드들이 있을 것. 각 기록에는 주문한 고객이 나오는 고객 차원 테이블에서 해당 고객의 고객 키 값, 주문이 이뤄진 시간이 포함된 시간 차원 테이블에서 해당 시간 키 값, 주문한 제품이 포함된 제품 차원 테이블에서의 제품 키 값 뿐만 아니라 거래 자체의 특성(주문과 세부 항목 번호 식별자, 수량, 지불한 가격 등)이 있을 것
    • 느린 변경 차원
      • 정확한 데이터 분석을 하려면 시간에 따른 개인의 상태를 추적할 필요가 있음
      • 특수한 구성 개념(construct), 느린 변경 차원이 개발됨
      • 느린 변경 차원의 목적은 시간에 따른 차원 엔티티(예,개인)의 상태를 추적해서 거래에서 발생한 정보(혹은 팩트)가 당시의 상태를 반영하게 하고, 결국 장기적으로 분석의 정확도를 높이는 것
      • 느린 변경 차원을 적용하면 ETL 잡(job)과 분석 쿼리 모두 상당히 복잡해지기 때문에 가장 중요한 특성의 이력만 추적하는 것이 좋음
    • 고도 병렬 처리(MPP)
      • 스타 스키마를 사용하지 않고 고도 병렬 처리 컴퓨터 여러 대를 사용하는 방법
      • 고도 병렬 처리(MPP, Massively Parallel Processing) 기술을 개발했기 때문에 테라데이터(Teradata)는 대규모 데이터 웨어하우스들이 가장 많이 사용하는 데이터베이스가 될 수 있었음. 전용 하드웨어, 소프트웨어, 네트워크 프로토콜 사용을 통해 테라데이터 데이터 웨어하우스는 하둡 등장 전까지는 업계에서 독보적이었던 확장성을 가질 수 있었음
      • 테라데이터는 여러 컴퓨터를 병렬로 운영할 수 있었기 때문에 사용자가 데이터를 특정 형태로 모델링하지 않아도 됐음
    • 데이터 웨어하우스(DW) 기기
      • 데이터 웨어하우스 기기는 전용 하드웨어와 소프트웨어에서 실행되는 고성능 데이터베이스를 표준적인 상용 데이터베이스보다 배포와 관리가 쉽게 하려고함. IBM 네티자(Netezza)
    • 열 기반 가게
      • 관계형 데이터베이스는 데이터를 행(row, 레코드라고도 함)과 열(column, 필드라고도 함)로 구성된 테이블로 모델링함
      • 실제로는 기록이 디스크 블록 단위에 딱 맞지 않고, 데이터 구조아 색인 정보도 공간을 차지하기 때문에 더 많이 필요함
      • 열 기반(columnar) 데이터베이스는 각 행의 모든 데이터를 묶어 저장하지 않고 각 열의 모든 데이터를 묶어 저장함
      • 어떤 사용자의 모든 정보(300개 열 모두)를 묻는 쿼리라면 행 기반 데이터베이스는 하나의 블록만 읽으면 되지만 열 기반 데이터베이스는 블록 300개를 읽어야 함. 일반적인 관계형 데이터베이스와는 달리 열 기반 데이터베이스는 매우 특수한 쿼리 패턴을 위해 사용함
      • 많이 알려진 수직적 데이터베이스로는 사이베이스 IQ(Sybase IQ)와 버티카(Vertica)가 있음
    • 인메모리 데이터베이스
      • 디스크 접근 최적화, 캐싱과 사전 캐싱, 블록 읽기 횟수를 줄이기 위한 색인 생성 등 블록 읽기 횟수를 최소화하는 데 상당한 노력이 필요함
      • 메모리의 가격이 내려가면서 메모리에 더 많은 데이터를 저장하는 것이 가능해졌고, 메모리에 데이터를 저장하고 처리하는 데이터 베이스 시스템이 출현(타임스텐,TimesTen)
      • SAP에서 공급하는 HANA 시스템, 아파치 스파크 프로젝트 외에도 여러 프로젝트가 추진 중
• 데이터 로딩: 데이터 통합 도구
  • ETL
    • 오랫동안 테라데이터와 다른 고급 데이터베이스 공급사들은 필요한 변환 작업에 ETL 도구 대신 자신의 데이터베이스 엔진을 사용하도록 고객을 설득해 왔음. 자신이 제공하는 확장성 좋은 시스템만이 자신의 데이터 웨어하우스를 로딩하는 데 필요한 정도의 용량과 복잡도를 처리할 수 있다고 주장해 왔음
    • ELT(추출,로딩,변환), 데이터는 처리 없이 데이터 웨어하우스에 로딩하고 이후 데이터베이스 엔진을 통해 적절한 표현으로 변환하는 방식
  • 연방, EII, 데이터 가상화 도구
    • 데이터가 여러 시스템에서 만들어지고 있다면 데이터 웨어하우스 접근 방식은 모든 데이터를 한군데로 일단 모으고 하나의 순응 스키마로 통합한 다음, 거기에 분석 쿼리를 사용하는 것
    • 다른 접근 방식은 여러 시스템을 통합하는 논리 혹은 가상 스키마를 만들어 가상 스키마로 쿼리를 처리하는 것
    • 연방, 기업 정보 통합, 데이터 가상화. 데이터 웨어하우스보다 좋은 대표적인 사례
      • 변화에 따라 데이터를 항상 최신 상태로 유지해야 할 경우, 원래 소스에 쿼리를 하다 보니 결과가 항상 가장 최근의 정보를 반영하는 반면 데이터 웨어하우스는 얼마나 자주 갱신하느냐에 따라 어느 정도의 지연이 발생할 가능성이 높음
      • 데이터 접근이 드문 경우, 비용이 많이 드는 데이터 웨어하우스를 1년에 한 번 또는 그보다 더 드물게 사용하는 데이터를 위해 구축하는 것은 비용적인 측면에서 효율적이지 않음
      • 규칙이나 데이터 전속 규정으로 데이터를 한곳에서 다른 곳으로 복사할 수 없는 경우
    • 단점
      • 노동 집약적 수동 과정 - 대상 시스템 모두에 가상 테이블을 직접 정의해야 함
      • 스키마와 논리 변경 - 스키마가 바뀌면 데이터 웨어하우스를 로딩하는 ETL 잡이 깨질 수도 있지만, 영향을 받는 범위는 가장 최근의 데이터로 한정되기 때문에 대부분의 데이터는 여전히 분석에 사용할 수 있음. 데이터 가상화 도구를 썼을 때는 스키마가 바뀌게 되면 쿼리 자체가 깨져 쿼리를 수정하기 전까지는 모든 데이터에 접근할 수 없게 됨
      • 성능 - 복수의 시스템에 걸친 쿼리(연방 쿼리) 중에는 성능에 상당한 부담을 주는 것. 데이터 웨어하우스는 색인 추가와 튜닝을 통해 분석에 더 최적화할 수 있지만, 운영 시스템은 설계된 목표 기능을 방해하지 않으면서 분석 쿼리에 최적화할 방법이 없음
      • 빈도 - 쿼리를 실행할 때마다 전체 통합 작업이 수행됨. 가상 스키마를 대상으로 한 쿼리가 여럿 생기면 데이터를 한 번 추출하고 데이터 웨어하우스에 저장했다가 거기서 쿼리를 하는 것이 훨씬 경제적
• 데이터 정리와 관리
  • 데이터 품질 도구
    • 품질 규칙을 정의하고 데이터에 이런 규칙을 적용해서 위반 사례, 즉 예외(exceptions)를 찾아 수정하는 과정으로 이뤄짐
    • 스칼라 - 특정 값에 적용. Name은 필수 필드며 값을 가져야 함. Salary는 숫자. Age는 0과 150 사이의 값
    • 필드 수준 - 특정 필드의 모든 값에 적용, 가장 널리 사용하는 예는 필드 고유성, 필드 밀도, Income은 X와 Y사이의 값이어야 한다 처럼 다른 형태의 규칙도 있을 수 있음
    • 기록 수준 - 특정 기록의 모든 필드에 적용
    • 데이터 세트(테이블/파일) 수준 - 전체 데이터 세트에 적용, 일반적이지는 않으며, 사용하면 레코드의 수와 연관돼서 사용하는 경우가 대부분
    • 복수 데이터 세트 수준 : 복수 데이터 세트에 적용, 참조 무결성 규칙은 관계형 시스템에서 매우 일반적
    • 데이터 프로파일 기법은 데이터 품질 규칙이 없는 경우 데이터의 통계적 수치를 자동으로 수집해 데이터의 품질을 확인할 수 있는 기법
    • 장점은 데이터 규칙을 설계하지 않아도 된다는 점과 분석가가 결과를 갖고 현재의 프로젝트에 맞게 데이터의 품질을 확인할 수 있다는 점
    • 떼이터 품질 도구로는 IBM 정보 분석(Information Analyzer), 인포매티카 DQ, SAS 데이터플럭스(DataFlux)등 여러 가지가 있음
  • MDM 시스템
    • 마스테 데이터 관리(Master Data Management,MDM) 시스템이라고 불리는 특수한 형태의 데이터 품질 도구는 다양한 엔티티의 마스터 목록을 만드는데 사용함
    • 여러 시스템에서 데이터를 가져와 공통적인 스키마와 표현(측정, 단위, 코드, 기타)으로 맞춘 후 엔티티 결의(entity resolution)라고 불리는 작업을 수행하는 매우 정교한 시스템
    • 엔티티 결의란 동일한 엔티티에 관한 서로 다른 기록을 찾는 과정을 말함
    • 다른 값을 서로 조화시키는 것은 MDM 시스템의 역할
    • 같은 엔티티에 관한 기록을 전부 찾아내면 주소가 다르거나 이름의 철자가 약간 다르거나 서로 상충하는 정보를 발견하는 경우가 많음. MDM 시스템의 또 다른 역할을 이렇게 상충하는 정보를 자동적으로든 사용자에게 직접 수정을 요청하든 해서 해당 엔티티에 가장 정확하면서 모두가 사용할 가장 완벽한 레코드를 만들어내는 것
    • MDM 공급사로부터 IBM, 오라클, 인포매티카와 같은 전통적인 회사 외에도 테이마(Tamr)와 같은 새롭게 등장한 공급사도 있음. 테이마에서는 머신러닝을 적용해서 이런 과정을 자동화하고 있음
  • 데이터 모델링 도구
    • 데이터 모델링 도구는 관계 스키마를 만드는 데 사용함
    • 운영 스키마면 정규화가 잘되고 작은 단위의 거래에 적합하게 최적화돼야 함. 데이터 웨어하우스를 위해서라면 분석 쿼리에 적합하게 다차원적인 설계를 해야 함
    • 스키마 설계자는 이해 가능성과 확장 가능성도 고려할 필요가 있음. 잘 설계한 스키마는 새로운 열을 추가해서 수정하기 쉽지만, 잘못 설계한 스키마를 수정하려면 상당한 비용이 들어가는 재설계까 필요한 경우가 많음
  • 메타 데이터 저장소
    • 메타데이터 저장소는 모든 데이터 자산의 기술적 메타데이터(데이터에 관한 데이터)를 갖고 있음
    • 데이터 자산 검색 - 데이터 아키텍트가 어떤 데이터베이스의 어떤 테이블에 Customer_ID가 포함돼 있는지를 알고 싶을 수 있음
    • 이력 추적(유래) - 기업이 데이터 자산의 이력, 즉 각 자산의 데이터가 어디서 왔고 어떻게 만들어지거나 전환됐는지 기록으로 남기게 하는 여러 가지 규정이 있음
    • 영향도 평가 - 개발자는 무언가를 바꾸기 전에 특정 필드나 통합 잡(job)에 영향을 받는 모든 데이터 자산을 확인할 수 있음
    • IBM, 인포매티카, ASG 로하드(ASG Rochade)외 여러 곳이 있음. 이런 도구는 데이터 카탈로그라고 하는 새로운 부류의 제품으로 빠르게 대체되고 있음
  • 데이터 관리 도구
    • 데이터 관리 도구는 데이터 관리 정책을 기록, 문서화, 또는 때에 따라 관리함
    • 각 데이터 자산의 데이터 관리자가 누구인지 정의된 경우가 많음. 데이터 관리자는 데이터 자산이 정확한지 확인하고 목적과 이력을 문서로 남기며, 해당 데이터에 대한 접근과 수명주기 관리 정책을 정의하는 책임을 짐
    • 접근 권한 제어와 민감 데이터 규정 준수 여부
    • 문서화 또는 메타데이터 관리
    • 데이터 수명주기 관리 - 보관 정책, 백업 정책
    • 데이터 품질 관리 - 수용 가능한 품질 수준과 적용할 데이터 품질 규칙
    • 비즈니스 용어 사전 - 데이터가 대변하는 다양한 용어

빅데이터와 데이터 과학 소개

• 빅데이터의 인기는 2004년에 제프리 딘과 산자이 게마왓이 발표한 한 편의 논문 <맵리듀스: 대규모 클러스터에서의 데이터 처리 단순화(MapReduce: Simplified Data Processing on Large Clustgers)>에서 시작됌. 13쪽자리 이 논문에서 구글 엔지니어 2명은 대규모의 병렬 처리 클러스터에서 실행되는 새로운 알고리즘을 통해 어떻게 구글에서 필요로 하는 방대한 색인 작업을 현실적으로 처리할 수 있는 수준까지 떨어뜨릴 수 있었는지 설명함
• 맵리듀스의 기본 개념은 작업을 병렬로 연결된 매퍼와 그 결과를 받아 처리하는 리듀서로 나눠 처리하는 것. 매퍼에서 하는 기능을 매핑이라고 부르는 이유는 입력 데이터의 각 요소를 특정 함수와 매핑하고 결과는 리듀서가 처리하게 남겨 놓기 때문
• 하둡 파일 시스템
  • 맵리듀스에 데이터를 효율적으로 전달하려면 특별한 파일 시스템이 필요하며, 가장 많이 사용하는 것은 하둡 파일 시스템(HDFS)
  • HDFS는 병렬 처리 성능이 우수하며, 쉽게 구할 수 있고 자가 치료가 가능한 파일 시스템. 하지만 관계형 모델 지원을 고려해서 만들어지진 않았음
  • HDFS는 각 블록의 복사본을 만들어(기본적으로 원본 포함 3개) 각각을 다른 노드에 저장함. 하나의 노드에 문제가 생겨도 여전히 2개의 복사본이 남아 있고, 장애를 인식하면 바로 다른 노드에 3번째 복사본을 다시 만들어 전체 개수를 유지함
  • 복사본을 갖고 있으면 필요한 데이터가 있는 노드 중 가장 한가한 노드에 작업을 의뢰할 수 있으므로 부하를 균일하게 유지하는 데도 도움이 됨
• 멥리듀스 잡에서 처리와 저장의 상호작용 방법
  • 잡 관리자는 각 블록에 대한 필요한 작업을 해당 블록을 저장하고 있는 노드 중 가장 부하가 적게 걸린 노드에 보내 전체 클러스터의 부하를 균등하게 유지함. 물론 이런 파일 명단을 만들려면 블록 단위로 흩어진 파일을 다시 모아야 함
  • 특정 파일의 모든 블록에 관한 정보를 같은 리듀서가 받을 수 있게 하려면 맵리듀스에서는 셔플이라고 부르는 단계를 활용함. 셔플 단계란 키와 값으로 구성된 매퍼의 결과에 같은 키를 가진 모든 작업이 같은 리듀서에게 보내질 수 있도록 키에 특정 셔플 함수를 적용하는 것을 얘기함
  • 순차 파일이란 키/값 조합의 집합으로 여러 개의 작은 파일을 하나의 큰 파일에 저장하고 사용됨. 작은 파일의 이름을 키로 하고 내용은 값으로 저장함
• 읽는 시점 스키마 적용
  • 관계형 데이터베이스에서는 테이블의 스키마(열, 각 열의 이름, 각 열의 유형으로 구성된 목록)를 테이블로 만들 때 정의함
  • 데이터를 테이블에 저장할 때 사전에 정의된 구조에 맞게 넣어야 함
  • 읽는 시점 스키마 적용. 데이터를 읽어야 할 때 스키마를 적용함
• 하둡 프로젝트
  • 하둡과 HDFS 관련 인기 설치형 도구

  • 	아파치 하둡	클라우데라	호튼웍스(IBM,마이크로소프트애저,피보탈 포함)	맵알
    모으기	스쿱,플룸	나이파이
    관계형 인터페이스/DB	하이브	하이브,임팔라	하이브	하이브,드릴
    NoSQL	HBase	HBase,쿠두	HBase	맵RDB(HBase의 일종)
    보안	레인저	센트리	레인저
    거버넌스	아틀라스	내비게이터	아틀라스	리세일즈 워터라인
    파일 시스템	HDFS	HDFS	HDFS	맵알-FS

  • 하둡과 HDFS 관련 인기 클라우드 기반 도구

  • 	AWS	애저	구클 클라우드 플랫폼
    모으기	Kinesis	이벤트 허브	클라우드 게시자/구독자
    통합	글루	ADF	클라우드 데이터플로우
    관계형 인터페이스/DB	하이브,프레스토,레드시프트,오로라	하이브	클라우드 스패너
    NoSQL	다이나모DB	애저NoSQL	빅테이블
    보안		보안 센터
    거버넌스	글루	애저 거번넌스
    파일 시스템	EBS,EFS	ADLS	ECFS
    오브젝트 스토어	S3	개체 스토리지	GCS

  • 스파크의 핵심 개념은 다수의 컴퓨터로 구성된 클러스터 전체에 걸친 대규모 인메모리 데이터 세트를 구축하는 것. HDFS가 클러스터 전체에 걸친 단일 파일 시스템을 만들고자 했다면 스파크는 효율적으로 전체 클러스터를 포함하는 하나의 큰 메모리 공간을 만들게 됨. 스파크를 사용하는 프로그램에게 하나의 데이터 세트로 보이게 되는 탄력 분산 데이터 세트(RDD<Resilient Distributed Dataset)가 스파크의 중심에 있음
  • 스파크는 원래의 맵리듀스 모델을 좀 더 일반화함. 매퍼,셔플러,리듀서로 구성된 단일 파이프라인을 (동시에 여러 개) 사용하는 대신 복합적인 파이프라인을 쓰면 데이터를 같은 단계에 해당하는 여러 곳에 보낼 수 있음. 예를 들어 스파크에서는 한 리듀서의 결과를 다른 리듀서에 쉽게 전달할 수 있음. 하둡에서 이렇게 하려면 복잡하고 번거로운 코딩 작업과 시간이 오래 걸리는 디스크 읽기/쓰기 작업이 필요함
• 데이터 과학
  • 데이터 과학이 하려는 것은 실제 정보, 즉 데이터를 바타응로 앞으로 어떤 행동을 하는 것이 좋을지 조언을 하는 것
  • 대규모 기업에서 데이터 과학을 어떻게 시작하는 것이 좋은지 컨설팅을 한 경험이 있는 베이지코 쿠르니크(vejiko Krunic)의 논문을 인용함
    • 데이터 과학 팀과 만난 후 다음과 같은 질문을 명확하고 간결하게 대답할 수 있다면 경영자로서 당신은 성공할 수 있는 제품을 만들기 위한 올바른 방향으로 가고 있다고 볼 수 있음
      • 그들이 얘기하는 데이터 과학이라는 개념이 당신의 비즈니스와 어떤 관계를 갖는가?
      • 당신의 조직은 분석 결과에 따라 행동할 준비가 돼 있는가?(분석을 완료했다고 해서 비즈니스 결과가 마법처럼 나타나지는 않는다. 분석 결과를 바탕으로 필요한 비즈니스적인 행동을 했을 때 나타난다. 프로젝트를 시작할 때와 진행 중일 때 모두 조직이 수행할 수 있는 비즈니스적인 행동은 어떤 것들이 있는지 분명하게 이해하고 있어야 함)
      • 가장 좋은 투자 대비 가치를 얻으려면 머신러닝 시스템의 어디에 투자 해야 하는가?
      • 앞의 질문에 답을 하기 위해 팀이 추가 조사를 해야 한다면 정확하게 어떤 조사를 해야 하고, 구체적으로 얻을 수 있는 답은 무엇이고, 조사를 끝내려면 무엇이(기법을 시도해볼 시간, 추가적인 데이터 등)필요한가?
    • 데이터에 맞는 접근 방식을 찾고 적용하는 것은 시스템 엔지니어링의 핵심이며, 프로젝트를 시작하면서 올바른 방향으로 가고 있는지 확인하고자 접근 방식을 평가해볼 필요가 있음
• 모델 드리프트(model drift)
  • 모델을 훈려했을 시점에서의 조건이 바뀌었다면 더 이상 모델을 사용하지 못할 수도 있음
  • 사람들이 살아가는 세상이 똑같이 유지되는 경우는 드물기 때문에 특정 시기의 실제 생활을 제대로 반영했던 모델도 결국에는 예측 능력을 상실하기도 함

데이터 레이크 시작

• 하둡
  • 하둡은 대규모 병령 저장소이자 확장성과 가용성이 높은 클러스터를 구축할때 나타나는 여러 어려운 과정을 자동화하는 실행 프랫폼. 자체 분산 파일 시스템(HDFS)를 갖고 있음
  • HDFS는 클러스터에 있는 데이터의 복사본을 자동으로 만들기 때문에 높은 병행성(parallelism)과 가용성(availability)을 가짐
  • 스케줄러는 각 노드에서 실행되는 다른 잡이 무엇인지, 해당 노드에 저장된 다른 데이터는 어떤 것인지 등을 고려해서 어떤 노드를 사용할지 결정함
  • 매퍼는 병렬로 실행되면서 각자 데이터를 처리한 결과를 리듀서에게 보내고, 리듀서는 받은 데이터를 조합해서 최종 결과물을 출력함
  • 리듀서는 각 매퍼에서 글자 수를 받아 특정 파일을 구성하는 모든 블록의 글자 수를 더해 최종 글자 수를 결과로 리턴함. 함께 실행되는 서비스인 정렬과 셔플은 특정 파일에 관한 글자 수 정보가 모두 같은 리듀서로 갈 수 있게 해줌
  • 하둡의 좋은 점은 데이터의 위치, 각 노드에 어떤 함수를 실행하는 것이 좋을지, 어떤 노드가 문제가 있어 현재 복원 중인지 등은 개별 맵리듀스 잡이 신경 쓰지 않아도 된다는 점
  • 모든 하둡 배포판에 포함된 아파치 스파크는 여러 노드에 걸쳐 많은 데이터를 메모리상에서 바로 처리할 수 있게 하는 실행 엔진을 제공함. 맵리듀스보다는 스파크가 프로그램을 작성하기 더 효율적이면서 쉬움, 즉흥 처리나 근실시간 처리에 더 적합하며, 맵리듀스와 마찬가지로 HDFS가 주는 데이터 인접성을 활용해 최적의 처리가 가능함
  • 얀 : 분산 자원 관리자
  • 주키퍼 : 분산 관리 동기화
  • 암바리 : 관리
  • 매력적인 특징
    • 극단적인 확장성 - 하둡은 노드만 추가하면 계속 확장되도록 설계됨(스케일링 아웃)
    • 비용 효과성 - 하둡은 상대적으로 저렵한 기성 하드웨어에서 동작하게 설계됐으며, 운영체제도 리눅스를 사용하고, 별도의 비용이 없는 여러 오픈소스 프로젝트를 활용함
    • 모듈 방식
      • 전통적인 데이터 관리 시스템은 분리할 수 없는 하나의 시스템. 전통적인 관계형 데이터베이스는 관계형 쿼리를 통해서만 데이터에 접근할 수 있으며, 누군가 더 좋은 데이터 처리 도구나 더 빠른 쿼리 엔진을 개발했어도 기존 데이터 파일을 활용할 수 없음. RDBMS에서는 스키마를 철저하게 지켜야 함. 데이터를 추가하기 전에 해당 데이터의 구조(스키마)를 먼저 정의해야 하고, 데이터가 변한다면 조심스럽게 구조를 바꿔야 함 (저장 시점 스키마 적용)
      • 하둡은 처음부터 모듈화를 고려해서 설계됐기 대문에 모든 애플리케이션이 같은 파일을 사용할 수 있음. 새로운 데이터 관리 기술도 공개된 인터페이스를 통해 하둡 데이터에 접근할 수 있기 때문에 하둡은 데이터 관리를 위한 장기적인 플랫폼으로 상당히 매력적임
    • 약한 스키마 결함, 읽는 시점 스키마 적용
      • 하둡은 데이터를 저장하는 시점에 어떠한 스키마도 강요하지 않음. 마찰 어븐 주입(frictionless ingest)이 가능해짐 , 아무런 확인이나 처리 없이 데이터를 모으는 것이 가능해짐
      • 저장하는 시점에는 아픙로 데이터가 어떻게 사용될지 모를수도 있기 때문에 이런 마찰 없는 주입 방식은 사용하지 않을 데이터를 처리하거나 정형화는 데 쓰는 비용을 줄이고, 나중에 나올 신규 애플리케이션에 적합하지 않은 형태로 데이터를 처리하는 오류를 피할 수 있게 해줌. 데이터를 원래 미가공 상태로 보관하다가 나중에 요구 사항과 사용 방법이 확정되고 나서 필요한 작업을 하는 것이 훨씬 효과적
  • 데이터를 위한 장기 저장과 분석 시스템을 구축하고 있다면 당연히 비용 효율적이면서 확장성과 접근성이 좋은 시스템을 구축하길 원함. 데이터를 추가하는 데 필요한 작업은 최소화하면서 시스템이 나중에 나올 기술, 애플리케이션, 프로젝트를 지원할 수 있는 확장성도 갖길 원할 것
• 데이터 웅덩이 확산 방지
  • 오픈소스 기술의 아쉬운점
    • 확산에 부합할 만큼 아직 안정적이거나 표준적이지 않을 수 있다는 점
    • SI 업체가 떠나고 나서 처음으로 주요 기술적 어려움이 나타나면서 잡은 실행되지 못하고, 라이브러리는 업그레이드돼야 하며, 기술이 더는 호환되지 않고 만들어진 데이터 웅덩이는 결국 버려지거나 IT팀에게 다시 떠맡겨짐. 데이터 웅덩이는 독립적인 저장소를 만들기 때문에 하나의 웅덩이에 있는 데이터나 데이터에 대해 작업한 결과를 다시 사용하기 어려움
• 거버넌스는 정부와 기업 규정을 잘 준수하는 데이터를 사용자에게 보안과 관리가 잘된 형태로 제공하는 것을 목표로함. 주로 민감한 개인정보 관리, 데이터 품질, 데이터 수명주기, 메타데이터, 데이터 이력 등과 관련 있음
  • 일관적인 데이터 품질 기술과 데이터 품질 규칙으로 데이터를 분류하고 처리할 수 있음
  • 같은 데이터 보안 도구들로 민감한 데이터를 식별하고 처리할 수 있음
  • 시스템 전반에 걸쳐 동일한 방법으로 보유하고 전자 디스커버리(eDiscovery) 기능을 실행할 수 있음
  • 하나의 시스템을 기준으로 준수 보고서를 작성할 수 있음
• 데이터 레이크 전략 결정 트리
  • 데이터 웅덩이가 있는지 파악함(각 비즈니스 팀이 자체적으로 하둡 클러스터를 사용하고 있는가?)
    • 있다면 일원화된 클러스터로 옮기는 것에 찬성할 프로젝트가 있는가?
      • 그런 프로젝트가 있다면 일원화된 중앙 클러스터를 만드는 근거로 해당 프로젝트의 예산을 활용하라
      • 그런 프로젝트가 없다면 데이터 웅덩이 확산 방지를 데이터 레이크의 근거로 삼아라. 기존 확산 사례(데이터 마트, 보고용데이터베이스)를 예제로 활용하라. 승인받지 못하면 데이터 웅덩이에 문제가 생길 때까지 기다려라. 오래 걸리지 않을 것이다.
    • 데이터 웅덩이가 없다면 빅데이터나 데이터 과학을 요청한 부서가 있는가? 없다면 스폰서가 돼 달라고 설득할 수 있는 부서가 있는가?
  • 결과를 얻기가 상대적으로 수월한 프로젝트를 찾아라. 리스크는 낮으면서 가시성은 높은 프로젝트를 식별하라
  • 팀당 둘 이상의 프로젝트, 또한 팀도 둘 이상 찾아 성공 확률을 높여라
  • 데이터 과학/분석 전략을 따르라
    • 빅데이터 프로젝트의 스폰서를 맡아 줄 만한 부서가 없다면 데이터 거버넌스는 필요한가? 필요가 있다면 일원화된 거버넌스 지점으로부터 승인받아라
    • 모든 것이 없다면 진행되고 있는 주요 프로젝트를 검토해서 대규모 병렬 처리나 대규모 데이터 세트가 필요하고 하둡을 사용했을 때 비용적인 측면에서 이득을 볼 수 있는 프로젝트를 식별하라
  • 마지막으로 데이터 레이크로 옮길 수 있는 작업을 찾아내라

데이터 연못/빅데이터 웨어하우스에서 데이터 레이크로

• 데이터 웨어하우스의 핵심 기능
  • 데이터 아키텍트 고려 사항
    • 데이터는 고성능 분석이 가능하도록 정리돼 있어야 하는데, 주로 차원 모델을 구성해서 정리하며 그 결과 스타스키마가 만들어짐. 비용이나 성능과 관련된 제약으로 인해 데이터웨어하우스에 과거 데이터를 모두 보관하기 어렵기 때문에 오래된 데이터는 압축하거나 별도의 아카이브(archive)에 보관함
    • 차원 통일,조화,정규화 등의 방법을 통해 여러 시스템의 데이터를 일관된 형태로 전환해서 달성함
    • 과거 분석의 정확성을 유지하는 방법으로 변경을 관리해야 함
    • 데이터가 깨끗하고 일관적인지 확인해야 함. 데이터 품질 도구와 기법을 활용해 달성함
  • 데이터 웨어어하우스가 겪었던 어려움
    • 분석용 데이터 모델 구성
    • 여러 시스템의 데이터를 일관된 형태로 전환
    • 데이터 이력을 잃어버리지 않고 변경 관리
• ETL 오프로딩 : 데이터 웨어하우스 스키마를 만들기 위한 변환 작업
• 분석용 차원 모델링
  • 운영 시스템은 작은 단위의 읽기와 쓰기 작업을 여러 번 나눠서 하는 경향이 있음. 정규화된 데이터 모델을 사용하는 이유 중 하나. 정규화된 데이터 모델은 최소한의 중복과 필드 개수를 유지하려 함. 정규화는 데이터 갱신과 읽기 속도를 매우 빠르게 할 뿐만 아니라 데이터가 일관되지 않을 위험성을 줄여줌
  • 대부분의 데이터 웨어하우스는 모든 테이블이 가능한 한 많은 관계 특성을 저장하는 비정규화 데이터 모델을 선호함. 분석 애플리케이션은 필요한 모든 데이터를 한 번에 처리할 수 있음. 일반적으로 데이터 웨어하우스에는 서로 스키마가 다른 다양한 소스와 애플리케이션의 데이터를 저장하다 보니 모든 소스의 데이터를 공통적인 스키마로 바꿔야 함
  • 스타 스키마는 분석 대상 요소(고객,시간,제품)를 대변하는 차원 테이블과 그런 차원과 관련된 활동(주문 내역)을 대변하는 하나 이상의 팩트테이블로 구성됨
  • 문제가 되는 점은 데이터 소스에 따라 같은 정보를 표현하는 방법이 다른 경우가 많다는 점
  • 순응(conforming) 테이블 : 모든 소스 시스템에서 데이터를 기대하는 것과 동일한 차원 테이블에 같은 형태로 보관하고 있느 테이블
• 다양 한 소스의 데이터 통합
  • ETL 도구는 다양한 운영 시스템과 서로 다른 스키마와 유형의 데이터를 하나의 공통 스키마로 전환하려는 목표로 만들어졌음. ETL 도구들이 가장 먼저 해결하고자 했던 문제는 운영 시스템이 선호하는 정규화된 스키마로 된 각 레코드를 데이터 웨어하우스가 기대하는 비정규화 스키마로 전환하는 것, 여러 운영 프로그램의 데이터를 하나의 공통 스키마와 형태로 전환하는 문제, 데이터가 순응하게 하는 것
• 느린 변경 차원을 통한 이력 보존
  • 과거 데이터의 차원 변경을 대변하고자 느린 변경 차원(slowly changing dimensions)이라는 특수한 구성 개념이 만들어졌음
  • 어떤 데이터 변경 사항(결혼 상태, 취업 상태, 주소 등)이 발생하더라도 분서 과정에서 올바른 상태를 반영할 수 있게 됐음
• 데이터 연못
  • 데이터 연못에 이력 보관
    • 데이터 연못에서는 데이터를 모을 때 주로 복수의 파일이나 파티션에 보관함
    • 하둡에서는 병렬 처리가 많으므로 하나의 파일에 여러 번 동시 접근 하는 것을 막고자 /transactions/Year=2016/Month=3/Day=2 폴더에 여러 개의 파일을 만듬
  • 스냅샷을 활용한 상태 보존
    • 매일 최신 데이터를 모으는 것. 특정 날짜의 폴더에 데이터 세트의 일부 데이터만 보관(파티션)하지 않고 전체 데이터 세트의 모든 데이터가 매일 해당 날짜의 폴더에 저장(스냅샷)되도록 차원 데이터 폴도 구조를 설계함
    • 전체 고객 데이터를 매일 저장하다 보니 변경 사항을 추적하려면 상당히 비싼 방법일 수 있지만 느린 변경 차원을 사용하는 데 비해 여러 가지 장점이 있음
      • 모으는 과정이 직관적이기 때문에 스쿱과 같은 비교적 간단한 도구를 사용할 수 있음
      • 스냅샷은 고객의 모든 특성에 관한 이력을 보존할 수 있게 해줌(느린 변경 차원은 일부 특성만 추적할 수 있음)
    • 미래에 저장 용량을 늘리는 것이 너무 비싸진다면 전체 스냅샷 구조를 느린 변경 차원을 사용하는 데이터 세트로 전환할 수 있다는 점
• 데이터 연못을 데이터 레이크로 키우기 : 데이터 웨어하우스에 없는 데이터 가져오기
  • 미가공 데이터
    • 데이터 웨어하우스는 정화되고 정규화된 데이터만 보관함. 불행한 점은 정규화 과정 중에 주요 정보의 상당 부분이 유실된다는 점
    • 문제
      • 데이터 폭
      • 원본이나 미가공 데이터
        • 데이터 웨어하우스는 모든 데이터를 같은 방식으로 처리해서 같은 형태로 변환함
      • 표가 아닌 형태
        • 빅데이터 중 상당수(트위터 피드와 같은 소셜 미디어 데이터)는 표 형태가 아닌 문서(JSON,XML), 열 단위(파켓), 로그 파일(아파치 로그), 또는 기타 여러 가지 특수한 형태를 가짐
        • 관계형 데이터 웨어하우스 스키마로는 쉽게 전환할 수 없음
• 실시간 데이터 레이크
  • 람다 아키텍처
    • 보편적이면서 확장성은 높고 오류에 강한 데이터 처리 아키텍처
    • 하드웨어와 사용자 오류에 강하면서 다양한 수준의 부하를 견딜 수 있고 저지연 읽기와 업데이트가 필요한 여러 사용 사례를 지원하는 강건한 시스템을 목표로 함
    • 모든(과거)팩트를 다루는 배치 레이어(batch layer)와 실시간 데이터용 스피드 레이어를 함께 사용함(http://lambda-architecture.net)
  • 카파 아키텍처
    • 람다 아키텍처와 유사하지만 중심에 분산 로그를 갖고 있음
    • 실시간 데이터 레이크 설계 아키텍처의 추가적인 정보는 마틴 켈프맨의 Designing Data-Intensive Applications
  • 데이터 가게 : HDFS, HBase, 카산드라, 카프카
  • 처리 엔진 : 스파크, 플링크, 빔
  • 상호작용 : 제플린/스파크 노트북, 태블로/데이터미어
• 람다 아키텍처
  • HDFS가 마스테 데이터 세트를 저장하는 데 사용되고 스파크나 스톰으로 스피드 레이어를 만들 수 있으며, 서비스 레이어로는 HBase를 사용하고 쿼리를 할 수 있는 뷰 생성에는 하이브를 쓸 수 있음
  • 나단 마즈, 제임스 워렌의 Big Data: Principles and Best Practices of Scalable Realtime Data Systems
• 데이터 변환
  • 조화(Harmonization)
    • 여러 소스의 데이터를 공통 형태나 스키마로 전환함
  • 엔티티 구별과 결합
    • 여러 시스템 소스에서 보내는 같은 에티티(고객)에 대한 서로 다른 데이터가 같은 엔티티에 관한 것이라는 것을 인식해야 함
  • 성능 최적화
    • 관계형 데이터베이스와 같은 시스템에서는 스키마 유형에 따라 분석 쿼리에 더 빠르게 응답할 수도 있음
  • 하둡은 워낙 강력한 변환 엔진이기 때문에 분석에 상당한 변환이 필요한 대규모 쿼리를 효과적으로 실행할 수 있으므로 성능 때문에 데이터를 분석에 적합한 스키마로 변환해야할 필요성이 상대적으로 낮아짐
• 운영 데이터 스토어(ODS, Operational data stores)
  • 데이터를 통합, 정화, 정규화하는 데 사용함
  • ETL 접근 방식의 단점, 즉 ETL 잡이 분석 잡을 방해하거나 성능을 떨어뜨리는 것을 해결하고자 사용함
  • 모든 처리 과정을 별도의 ODS로 옮겨 기업은 분석 쿼리가 ETL 잡 때문에 느려지는 것을 막을 수 있음
  • 하둡이나 기타 빅데이터 플랫폼을 ODS로 사용하는 것은 여러 측면에서 ETL 오프로딩이 자연스럽게 확장된 모습이라고 볼 수 있음

셀프서비스용 최적화

• 셀프서비스의 시작
  • 셀프서비스 : 데이터를 스스로 찾고 이해하고 사용하기를 원함
  • 예전의 각 분야별 전무간의 롤
    • 데이터 웨어하우스에 필요한 스키마는 데이터 모델링 전문가가 설계함
    • 소스 애플리케이션에 데이터를 추출하고, 변환해서 데이터 웨어하우스에 로드하는 ETL 잡은 ETL 개발자가 만들었음
    • 데이터의 정확성을 확인하는 검증 잡은 데이터 품질 분석가가 만들었음
    • 보고서 작성과 사용자의 데이터 분류에 사용할 수 있는 온라인 분석 처리(OLAP,Online Analytical Processing) 큐브(cube)는 BI 개발자가 만들었음
    • 각 데이터 요소가 무엇을 의미하는지 묘사하기 위한 비즈니스 용어집과 기업의 데이터를 추적하는 데 필요한 메타데이터 저장소는 메타데이터 분석가가 만들었음
  • 비즈니스 오브젝트 유니버스는 최종 사용자가 실제 데이터 가공 과정의 복잡성은 걱정하지 않고 사전에 구성된 상위 수준 구성 개념(고객이나 주문과 같은 비즈니스 오브젝트)을 통해 데이터를 조합할 수 있게 해줌
  • 분석가는 엑셀, 트리팩타(Trifacta), 팍사타(Paxata)와 같은 셀프서비스 데이터 준비 도구를 사용해 원하는 형태로 데이터를 가공할 수 있음
• 데이터 식별과 이해 : 기업을 문서로 기록
  • 많은 기업에서 비즈니스 용어와 태그를 데이터 세트나 필드명과 연결해주는 데이터 카탈로그에 투자하고 있음
  • 분석가는 이런 태그로 데이터 세트를 빠르게 찾을 수 있고, 필드명과 관련된 태그를 보고 데이터 세트를 이해할 수 있음
  • 부족 지식(tribal knowledge) : 이터가 어디에 있고, 어떤 데이터 세트를 어디에 써야 할지, 데이터가 가진 의미는 무엇인지 등과 같은 지식은 많은 기업에서 사람들의 머릿속에만 있기 때문.
  • 구글,엘프,위키피디아의 예를 통해 알 수 있듯이 지금은 크라우드소싱(crowdsourcing)을 통해 지식을 저장하는 데 익숙한 시대
  • 문제
    • 필수 데이터 요소(CDE, Critical Data Elements)라고 하는 가장 중요한 데이터에 관한 정보만 문서로 남겨지는 경우가 많음, 고객,제품 특성과 같은 마스터 데이터 목록에서 찾을 수 있는 설명 필드, 주문 번호, 날짜, 금액과 같은 핵심 거래 필드가 주로 여기에 포함됨
    • CDE만 저장한다고 하더라도 데이터 세트, 비즈니스 프로세스(process), 규칙 등이 바뀌고 기술이 발전함에 따라 이런 저장소는 빠른 속도로 채워짐
  • 해결 방법
    • 모든 부족 지식을 크라우드소싱해서 모두에게 제공
    • 데이터 세트 주석 처리 자동화
• 신뢰 구축
  • 신뢰의 일반적인 3가지 기반
    • 데이터 품질 : 데이터 세트가 얼마나 완전하고 깨끗한가?
    • 이력(또는 유래) : 데이터가 어디에서 왔는가?
    • 관리 : 데이터 세트를 누가 만들었고 왜 만들었는가?
  • 데이터 품질
    • 실무에서 품질은 데이터의 관련 규칙 준수 정도로 정의할 수 있음
    • 데이터 품질 규칙
      • 완전성 : 필드는 비어 있지 않음
      • 데이터 유형 : 필드가 올바른 유형(나이는 숫자)
      • 범위 : 필드의 값은 특정 범위에 속해야 함 (나이는 0과 125 사이)
      • 포맷 : 필드가 특정 포맷으로 돼 있어야 함(미국 우편번호는 5자리,9자리,5자리-4자리여야함)
      • 집합의 크기 : 필드에 포함된 고윳값의 개수가 특정한 수여야 함
      • 선택성 : 필드의 값은 고유한 값이어야 함
      • 참조 무결성 : 필드 값이 참조 값 리스트에 있음
    • 데이터 품질을 확인하는 가장 일반적인 방법은 데이터 프로파일링(data profiling), 각 필드의 데이터를 읽어 비어 있는 필드 수(완전성), 고유한 값 개수(집합 크기), 고유한 값 비율(선택성)과 같은 측정 지표뿐만 아니라 데이터 유형, 범위 등을 확인하고 참조 무결성 검사까지 진행하는 것이 데이터 프로파일링 , 프로파일링의 장점은 모든 필드를 대상으로 자동 실행할 수 있다는 점
  • 이력(유래)
    • 데이터 이력을 표현하는 데는 여러 가지 어려움이 있음. 특히 시스템 정체(system identity)나 변환 로직(transformation logic)으로 인해 어려운 경우가 많음. 데이터가 많은 시스템과 도구를 거침으로써 서로 다른 도구가 같은 시스템을 얘기하고 있는지, 아니면 다른 시스템을 참조하는지 알기 어려운 경우가 많음
    • 기술 이력에 관해서는 밀도와 변환 표현 등 2가지 측면을 고려해야 함
      • 데이터 세트 수준 밀도
        • 여러 데이터 세트 간의 이력 관계는 일반적으로 방향성 있는 그래프 형태로 포착하고 편함. 데이터를 수집하고 변환한 각 단계는 노드나 박스로 표현하고, 이런 노드 간에 데이터의 흐름은 화살표료 표현함
      • 필드 수준 밀도
        • 각 필드의 이력은 방향성 있는 그래프의 형태로 포착하고 표현하는데, 이때 각 변환 작업은 별도의 노드로 표현하는 경우가 많음
      • 정규화된 표현 방법
        • 모든 변환을 공통 형태로 표현함
      • 원래대로 표현 방법
        • 모든 변환을 원래 언어나 스크립트로 표현하는 방법
• 프로비저닝(provisioning)
  • 적절한 데이터 세트를 식별하고 나면 분석가는 그것을 사용할 수 있게 해야함, 프로비저닝 해야함
  • 데이터를 사용할 권한을 확보해야 하고, 데이터에 대한 물리적인 접근을 확보해야 함
  • 데이터 레이크에서 가장 어려운 문제의 하나는 어떤 분석가에게 무슨 데이터에 대한 접근 권한을 줄지 결정하는 것
• 분석용 데이터 준비
  • 데이터 준비나 데이터 랭글링(data wrangling) 도구는 분석가가 전문 기술 없이도 분석에 적합한 형태로 미가공 데이터를 전환하기가 쉬워지고 있음
• 데이터 레이크의 데이터 랭글링
  • 데이터 랭글링이라는 용어는 비즈니스 분석가, 데이터 분석가, 데이터 과학자와 같은 비즈니스 전문가가 데이터를 분석에 적합한 형태로 변환하기 위해 하는 기본적인 준비 행위를 지칭하고자 사용함
  • 데이터 랭글링은 비즈니스 지능, 통계 모델링 도구, 머신러닝, 비즈니스 애플리케이션에 데이터를 공급하고자 여러 곳의 데이터를 미가공 상태에서 구조화된 소비가 가능한 형태로 변환하는 과정을 얘끼함
• 셀프 서비스
  • 셀프서비스 도구는 일반적으로 데이터에 대한 보고,조인,통합,정화를 하기 위한 간닪나 마법사, 스크립트, 또는 시각적 인터페이스를 제공함. 이 단계를 데이터 블랜딩(data blending) 또는 더 우아한 표현으로는 데이터 랭글링이라고 함
  • 분석 작업 전에 소스의 데이터 모델을 우선 로드했던 전통적인 ETL과 다리 블랜딩과 랭글링은 분석 과정 전이나 과정 진행 중 이뤄짐. 때에 따라(분석 프로그램을 소스로 사용할 경우) 과정이 끝난 후에 이뤄질 수도 있음

데이터 레이크 설계

• 데이터 레이크 구조화
  • 데이텊 활용 속도가 빨라지면서 기업은 바이모달 데이터 거번스 개념을 적용하기 시작함. 바이모달이란 서로 다르지만 연관성 있는 2가지 유형의 작업을 관리하는 방법. 2가지 작업 유형이랑 예측을 목표로 하는 작업과 탐색을 목표로 하는 작업을얘기함
  • 일반적인 데이터 레이크 클러스터 아키텍처
    • 외부 소스의 데이터는 먼저 미가공(raw) 혹은 진입(landing) 영역으로 들어오고, 거기서 별도의 처리 없이 데이터의 특성(시간이나 소스) 을 반영한 폴더로 분류됨
    • 필요에 따라 데이터는 골드 영역, 작업 영역, 민감 영역으로 복사됨. 골드 영역에서는 데이터를 정화, 분류, 집계함. 작업 영역에서는 사용자가 프로젝트를 실행하며, 민감 영역에서는 보호해야 할 데이터를 암호화해서 보관함
• 진입 영역 또는 미가공 영역
  • 미가공 영역 또는 대기 영역이라고 부르기도 하는 진입 영역은 주입된 미가공 데이터를 저장하는 데 사용함
• 골드 영역
  • 골드 영역은 진입 영역과 비슷하게 구성된 경우가 많지만, 대신 상대적으로 정화되고 부가 설명이 많거나 그 외의 방법으로 미가공 데이터를 어느 정도 처리한 상태로 보유함
  • 이 영역을 생산(prod) 영역이라고 부르기도 하는데, 포함된 데이터가 생산에 사용되기 적합한 상태, 데이터 품질 도구와 정화 과정을 거쳐 데이터 품질 문제가 해결된 상태이기 때문
  • 데이터를 적절한 차원이나 마스터 리스트로 조화시키고 정규화함. 마스터 리스트로는 마스터 고객 리스트, 마스터 제품 리스트 등이 있음
  • 골드 영역 접근을 쉽게 하고자 IT 부서는 하이브, 임팔라, 드릴, 기타 수십 가지 시스템 중 하나를 사용해서 골드 영역 각 파일에 대한 SQL 뷰를 만듬
  • IT 팀에 관리되고 폴더 구조와 명명법, HCatalog(하이브 메타스토어를 기바능로 개발된 데이터 딕셔너리로 점점 많은 프로젝트에 사용되고 있음)와 같은 방법으로 관련 설명도가 가장 잘 갖춰진 경우가 많음
• 비식별화 : 데이터의 원래 특성을 유지하면서 민감한 데이터는 유사한 가상 데이터로 대체하는 과정을 말함

데이터 레이크 카탈로그화

• 하둡의 휴처럼 파일의 일부를 사용자가 볼 수 있게 해주는 유용한 프로그램
• XPATH : XML 문서의 특정 영역에 접근하기 위한 쿼리 언어
• 데이터 프로파일링
  • 집합의 크기 : 필드별로 고유한 값이 몇 개 있는지
  • 선택 가능성 : 필드별로 특정 값이 얼마나 자주 등장하는지, 필드의 집합 크기를 열 수로 나눠 계산함
  • 밀도 : 행렬로 NULL(또는 비어있는 값)이 몇 번 등장하는지지
  • 범위,평균,표준 편차 : 수치 필드에 대해서는 최솟값과 최댓값뿐만 아니라 평균과 시그마 또는 표준 편차도 계산됨
  • 포맷 빈도 : 데이터에 따라 포맷이 매우 독특한 것이 있음
  • 기술 메타데이터(technical metadata) : 프로파일링을 통해 얻는 통계 정보와 필드명, 테이블명, 파일명과 같은 기타 메타데이터를 합친 기술
• 비즈니스 메타데이터
  • 용어집(glossaries), 분류 체계(taxonomies), 온톨로지(ontologies)
    • 비즈니스 용어집은 비즈니스 용어와 정의를 담고 있는 매우 공식적인 목록(주로 계층적)
    • 분류 체계는 자식 클래스가 부모 클래스의 하위 클래스가 되는 오브젝트 계층, is-a(이자)
    • 온톨로지는 분류 체계보다 일반적으로 좀 더 우아하며 대상 간의 임의적인 관계를 지원함. is-a 관계 외에도 대상과 특성 간의 has-a 관계도 표현할 수 있음
  • 포코소노미(Folksonomies)
    • 온톨로지보다 훨씬 유연한 접근 방식으로, 직원들이 자신의 데이터에 대해 어떻게 생각하는지를 표현함. 포크소노미는 현재 사용하는 용어를 수집해서 연관된 계층별로 정리하고 그것을 비즈니스 메타데이터로 사용함
• 태깅
  • 태깅(tagging) : 용어집, 분류 체계, 포크소노미, 온톨로지를 확보하고 그것을 데이터 세트에서 찾을 때 사용하려면 데이터 세트에 적절한 용어와 개념을 할당해야 함
  • 비즈니스 용어와 연관된 데이터를 가진 필드나 데이터 세트에 할당함
• 민감 데이터 관리와 접근 제어
  • 아파치 레인저(Apache Ranger), 클라우데라 센트리(Cloudera Sentry) 등과 같은 현재의 보안 시스템은 태그 기반 보안이라는 것을 사용함. 개별 데이터 세트와 필드에 관한 데이터 접근과 데이터 마스킹 정책을 정의하지 않고 특정 태그를 대상으로 하는 정책을 정의해서 해당 태그를 가진 모든 데이터 세트나 필드에 그 정책을 적용함
• 데이터 품질
  • 태그 기반 데이터 품질 규칙
    • 최신 카탈로그, 특히 자동 태깅을 지원하는 카탈로그는 데이터 품질 전문가와 데이터 관리자가 태그 단위로 데이터 품질 규칙을 정의하고 적용할 수 있게 함
  • 주석 품질 : 데이터 세트에 주석이 어느 정도 붙여져 있는지를 얘기함
  • 큐레이션 품질 : 태그 중 어느 정도가 사람에 의해 승인되거나 큐레이션됐느지를 얘기함
  • 데이터 세트 품질 : 태그 기반 데이터 품질, 주석 품질, 큐레이션 품질 등 3가지 유형의 품질을 요약함
• 이질적 데이터 연관 짓기
  • 기본키와 외래키
    • 관계형 데이터베이스는 키를 통해 테이블을 서로 연결함. 기본키-외래키(PKFK,Primary Key-Foreign Key)또는 참조 무결성 관계
• 이력 수립
  • 데이터의 이력 또는 유래 : 카탈로그가 분석가에게 제공해야 하는 중요한 정보 중 하나는 데이터의 신뢰 가능 여부인데, 여기서 해당 데이터가 어디에서 왔는지가 중요한 요소.
  • 이력 정보의 틈을 시스템 로그를 분석해서 메우는 도구(클라우데라 내비게이터, Cloudera Navigator), 오픈소스 시스템으로 이력을 보고(아파치 아틀라스,Apach Atlas), 사용자에게 작성하는 잡마다 직접 이력 정보를 넣게 하는 것(아파치 팔콘, Apache Falocn), 파일 내용(IBM 인포스피어 디스커버리, 워터라인 데이터)이나 SQL 로그(만타, 얼레이시언)를 분석해서 추측하는 도구도 있음
• 카탈로그 구축 도구
  • 데이터 카탈로그 도구를 제공하는 회사. 워터라인 스마트 데이터 카탈로그, 인포매티카 엔터프라이즈 데이터 카탈로그, 얼레이시언, IBM 왓슨 지식 카탈로그, AWS 글루, 아파치 아틀라스(호튼웍스와 그 파트너들이 개발) 등이 대표적
  • 주요한 기능을 고려해야함
    • 성능과 확장성을 위한 플랫폼 내의 빅데이터 처리
    • 자동 데이터 발견과 분류
    • 다른 엔터프라이즈 메타데이터 자장소와 단일 플랫폼 카탈로그와의 통합
    • 사용성
  • 하둡이나 스파크와 같은 플랫폼 내의 빅데이터 처리 도구 지원 여부. 데이터 레이크는 기업의 데이터 시스템 중 가장 규모가 큰 것으로 그곳의 데이터를 처리하고 카탈로그화하는 데는 많은 노드로 구성된 대규모 클러스터의 처리 능력이 필요함. 하둡의 목적은 단순히 데이터를 저장할 수 있는 비용 효율적인 장소를 제공하는 것이 아니라 데이터를 비용 효율적으로 처리할 수 있는 장소도 제공하는 것
• 도구 비교
  • 기업의 모든 데이터를 카탈로그화하는 엔터프라이즈 카탈로그 도구
  • 특정 플랫폼을 대상으로 하는 단일 플랫폼 카탈로그 도구
  • 플랫폼 내의 빅데이터 처리를 지원하지 않는 과거/관계형 카탈로그 도구
  • 카탈로그 도구 비교

    • 	빅데이터 지원	태깅	엔터프라이즈 수준	비즈니스 분석가 대상 UI
      엔터프라이즈
      워터라인 데이터	플랫폼 내	자동	예	예
      인포매티카 엔터프라이즈 데이터 카탈로그	플랫폼 내	수동	예	예
      단일 플랫폼
      클라우데라 내비게이터	플랫폼 내	수동
      아파치 아틀라스	플랫폼 내	수동
      AWS 글루	플랫폼 내	수동
      IBM 왓슨 카탈로그	플랫폼 내	자동		예
      과거/관계형
      얼레이시언	하이브에서만 수동	예	예
      콜리브라	하이브에서만 수동	예	예

• 데이터 오션 : 모든 데이터를 카탈로그화

데이터 접근 관리

• 데이터 레이크가 전통적인 데이터 저장소와 다른점
  • 부하 : 데이터 세트, 사용자, 수정 사항 수가 매우 많음
  • 마찰 없는 주입 : 데이터 레이크는 아직 정해지지 않은 미래의 분석을 위한 데이터를 저장하기 때문에 일반적으로 데이터를 처리하지 않거나 하더라도 최소한의 처리를 한 상태에서 주입함
  • 암호화 : 민감한 정보나 개인정보를 보호하게 하는 정부와 사내 규정은 많지만, 분석을 하려면 이런 데이터가 필요함
  • 작업의 탐색적 특성
• 태그 기반 데이터 접근 정책
  • 하둡 파일 시스템(HDFS)은 보편적인 리눅스 접근 제어 목록(ACL,Access Control Lists)을 지원함. 파일 접근 제어 목록 세트(-setfacl) 명령은 특정 파일이나 폴더에 대한 권한을 어느 사용자나 사용자 그룹에게 줄지 관리자나 파일 소유주가 지정할 수 있게 해줌
• 민감 정보 비식별화
  • 적용할 수 있는 암호화 형태
    • 투명 암호화(Transparent encryption)
      • 클라우데라 내비게이터의 방식은 데이터가 디스크에 써지면 자동으로 암호화하고, 읽을 때 자동으로 해독함
    • 명시적 암호화(Explicit encryption)
      • 민감 데이터를 완전히 사용할 수 없게 함
    • 비식별화
      • 익명화, 민감한 정보를 원래 데이터의 주요 특성은 보존한 무작위 값으로 대체함
• 셀프서비스 접근 관리
  • 접근 제어란 민감 데이터 외에도 필요한 경우가 많고, 조직의 누가 어떤 데이터에 대한 접근 권하을 가져야 하는지 고려하는것도 포함돼어 있음
  • 여러 가지 분명한 특성과 효과
    • 분석가는 가용한 모든 데이터 세트의 메타데이터를 탐색(검색하고 둘러보기)할 수 있음
    • 분석가는 데이터 소유주에게 특정 데이터 세트의 접근을 요청할 수 있음
    • 데이터 소유주는 그것을 누가 어떻게 얼마나 오랫동안 접근할 수 있는지 결정할 수 있음
    • 모든 요청, 근거, 허가에 관한 정보는 보안 감사 목적으로 추적함
  • 셀프서비스 접근 관리와 데이터 권할 설정
    • 데이터 소유주가 카탈로그에 데이터 자산을 게재함. 이 시점에서 분서가는 데이터를 찾을 수는 있지만, 데이터를 읽거나 수정할 권한은 없음
    • 데이터 분석가는 카탈로그에서 데이터 세트를 찾음. 분석가는 데이터 접근 권한이 없기 때문에 검색은 메타데이터로 해야 함
    • 분석가가 데이터 소유주에게 접근 권한을 요청함. 분석가는 카탈로그를 사용해 데이터를 찾을 수는 있지만 접근할 수는 없음. 데이터 소유주에게 사용 권한을 요청해야 함. 이렇게 하면 데이터 소유주는 데이터를 누가 왜 사용하는지 완벽하게 제어할 수 있음
    • 데이터 소유주가 요청을 승인함
    • 데이터 세트가 분석가에게 제공, 즉 확보됨
  • 셀프 서비스 과정은 데이터 소유주에게 데이터를 누가 사용하는지 통제할 수 있게 하며, 분석가에게는 데이터 세트를 탐색하고 접근 권한을 빠르게 획득할 수 있게함. 기간을 설정해서 데이터에 대한 권한을 부여하다 보니 이런 접근 방식은 모든 가용한 데이터 세트에 대한 권한을 관리하는 것과 프로젝트가 끝난 다음에도 혹시나 필요할 때를 대비해서 분석가가 불가피하게 계속 보유하고 있는 접근 권한의 관리 문제도 해결해줌. 분석가는 필요할 때 다시 요청해서 권한을 빠르게 다시 확보할 수 있음
  • 접근 권한을 부여하는 데 많이 사용하는 방법은 데이터 세트에 대한 외부 하이브 테이블을 만드는 방식
• 데이터 확보
  • 파일 요청 - 요청 검토 - 요청 승인 - 데이터 확보
  • 서비스나우(serviceNow) 또는 지라(Jira)와 같은 표준 요청 추적 시스템에 작성하거나 폐가시스템(Pegasystmes)또는 에센테크(Eccentex)와 같은 BPM/워크플로우/요청 관리 시스템을 사용해서 이뤄짐