(출처 : http://www.comworld.co.kr/news/articleView.html?idxno=49535)
| [컴퓨터월드] 전통적인 관계형DB는 비정형 데이터를 담을 수 없다. 하지만 기업 입장에서는 비정형 데이터 관리를 위해 섣불리 데이터 저장소를 확대 및 다양화한다는 결정을 내리기 어렵다. 데이터 저장소가 다양화될수록 필요한 데이터를 찾기 어려워지고 이는 오히려 기업의 데이터 역량에 나쁜 영향을 미칠 수도 있기 때문이다. 그렇다고 이러한 데이터 프로세스들을 관리하기 위해 추가적인 역량을 투자하는 것도 쉽지 않다. 이에 업계 전문가들은 기업의 모든 데이터들에 대해 손쉽게 접근하고 관리할 수 있는 단일한 플랫폼 전략을 가져야 한다고 조언한다. 데이터 저장소가 나뉘어 있더라도 필요한 타이밍에 원하는 데이터에 접근할 수 있는 단 하나의 접점을 마련한다면 기업의 데이터 역량을 강화할 수 있다는 설명이다. 새로운 데이터 전략을 준비하라 비정형 데이터를 효과적으로 저장하고 활용하기 위해서 기업은 기존과 다른 전략을 준비해야 한다. 데이터 한 줄을 검색하기 위해서도 기존의 정형데이터를 찾을 때와는 다른 방법이 필요하다. 가령 모 대학교의 2019년 신입생 중 20살 미만인 사람을 찾고자 할 경우, 신입생들의 신상정보가 저장돼 있는 관계형DBMS(RDBMS)에 SQL로 작성된 몇 줄의 쿼리를 날려서 손쉽게 검색하고 조회할 수 있다. 하지만 신입생들의 입시원서에 붙은 사진을 확인해 안경을 쓴 사람만을 리스트업하려면 어떻게 해야 할까? 텍스트 데이터나 이미지와 같은 비정형 데이터를 저장하고 검색하기 위해서는 기존의 RDB와 SQL이 아닌 새로운 방법이 필요하다. 비정형 데이터를 저장할 수 없는 RDB를 대체하는 방법 중 가장 부각되는 것은 ‘몽고DB(MongoDB)’나 ‘카산드라(Cassandra)’와 같은 NoSQL일 것이다. NoSQL은 RDB의 핵심 중 하나인 SQL을 사용하지 않는다(No SQL) 혹은 SQL 이외의 방법도 사용할 수 있다(Not only SQL)는 것을 의미한다. RDB보다 융통성있는 데이터 모델을 사용함으로써 데이터의 저장 및 검색에 보다 최적화된 구조를 갖고, 데이터의 속성이나 스키마를 다양하게 정의할 수 있다. 특히 분산 환경에 특화된 구조를 갖는데, 데이터를 하나 이상의 서버로 분산시킴으로써 네트워크 및 디스크 부하를 경감하고 전체적인 처리 속도를 향상시킬 수 있다. 분산돼 있는 서버 중 하나가 정지되더라도 나머지 서버들이 나누어 부담하므로 서비스 가용성을 확보할 수 있는 것은 물론이다. 하지만 기존에 운영하던 RDB를 NoSQL로 전환한다고 해서 비정형 데이터와 관련된 모든 문제를 해결할 수 있는 것은 아니다. 특히 NoSQL은 대부분의 경우 벤더사의 공급 없이 오픈소스로 제공되기에 기업 측에서 고려해야 할 사항이 많다. NoSQL을 바탕으로 비정형 데이터를 저장 및 처리할 수 있다고 해도 폭발적으로 유입되는 데이터를 감당하기 위해서는 충분한 처리 성능과 스토리지 공간이 필수적이다. 벤더사의 지원을 받을 수 있는 상용 RDB라면 컨설팅이나 교육 등을 통해 도움을 받을 수 있지만 오픈소스는 그렇지 않다. 운영 중 문제가 발생했을 때 오픈소스 커뮤니티에서 해결책을 찾는 것보다 벤더사의 확실한 지원을 받는 것이 필요할 경우도 있다. 또한 제각각 다른 특색을 가진 NoSQL 중 자사의 시스템과 가장 잘 맞는 제품을 선택하는 것 역시 기존 RDB에 익숙한 개발자들에게는 어려운 일일 수 있다.
또한 비정형 데이터를 처리하기 위해 NoSQL과 같은 DB를 도입할 경우, 기업에서는 관리해야 할 데이터 저장소가 늘어난다는 점이 부담으로 작용할 수 있다. 그렇다고 해서 기존에 RDB로 운영하던 것들을 모두 NoSQL 환경으로 옮기는 것은 합리적이지 않다. 전통적인 RDB가 비정형 데이터를 담기에 적합하지 않은 것처럼, ERP나 CRM과 같이 정형 데이터를 생산하는 시스템에 굳이 NoSQL을 연동할 필요는 없다. 정확한 데이터 처리가 필요한 영역에서는 여전히 RDB의 안정적인 환경이 요구된다. 따라서 기업은 자연스럽게 기존 시스템들을 운영하기 위한 안정적인 DB와 비정형 데이터 처리를 위한 DB를 별도로 구축하게 된다. 양질의 인사이트를 얻기 위해서는 많은 종류의 데이터들을 복합적으로 살필 필요가 있다. 가령 한 기업이 자사 특정 제품의 판매 현황을 파악하고자 판매 이력만을 확인한다면, 이는 데이터를 충분히 활용하고 있다고 보기 어렵다. 판매 이력과 함께 사용자가 제품을 접한 채널, 콜센터를 통해 유입된 피드백, 경쟁사 제품의 특징과 판매량, 기타 판매량에 영향을 미친 요소 등을 종합적으로 고려한다면 보다 가치있는 인사이트를 생산할 수 있다. 따라서 기업은 자사의 데이터가 여러 플랫폼에 나뉘어 저장돼 있다고 하더라도 모든 데이터에 손쉽게 접근할 수 있어야 한다. 만약 각각의 데이터에 접근할 수 있는 플랫폼과 채널이 다양하다면, 기업 입장에서는 각각의 플랫폼을 관리하고 상호간의 데이터를 일치시키기 위해 위한 별도의 자원을 소모해야 한다. 데이터가 어디에 있는지 찾지 못해 시간을 낭비할 수도, 특정 데이터가 있다는 사실을 알지 못해 분석의 정확도를 떨어트릴 위험도 있다. 반복적으로 사용된 데이터의 경우에는 원본이 소실될 수도 있다. 이를 방지하기 위해 각각의 데이터마다 주석을 추가하더라도 일부 SW는 이를 인식하지 못할 수도 있다. 이를 해결하기 위해 대다수의 벤더사들이 내놓는 답변은 단일한 데이터 접점을 구축하는 것이다. 사용자들은 자신이 원하는 것이 무엇이든 단일한 접점에서 필요한 데이터에 접근할 수 있어야 한다. 이는 다양한 DB 솔루션을 보유한 벤더를 선택해 모든 데이터를 맡기거나, 모든 데이터셋에 접근 및 관리가 가능한 단일 아키텍처를 마련하는 방법으로 이뤄진다. 단일한 데이터 접점 구축해야 빅데이터 분석을 위한 플랫폼을 구축할 경우 다양한 비즈니스 요구에 맞추기 위해서는 단일한 데이터웨어하우스(Data Warehouse, DW)에 모든 데이터를 저장하는 것은 바람직하지 않다. DW는 필요에 따라 정형 데이터를 빠르게 적재하고 분석하기 위한 공간이며, 대신 목적에 맞게 특화된 시스템 구축을 통해 높은 성능과 사용성을 확보할 수 있다. 아마존웹서비스(AWS)는 데이터에 접근할 수 있는 단일 아키텍처를 만드는 방법으로써 데이터 레이크(Data lake)와 데이터 카탈로그(Data Catalog) 전략이 유효하다고 말한다. 기존에 운영하던 DW를 그대로 유지한 채 IoT 디바이스나 웹, SNS에서 생산되는 데이터를 데이터 레이크에 저장하고, 그 위에 데이터 카탈로그 레이어를 생성해 운영하는 식이다. 데이터에 접근해 분석이나 머신러닝 등을 수행하는 것은 모두 데이터 카탈로그와 연동해 이뤄진다. 데이터 레이크는 시스템이나 저장소 내에 모든 데이터들을 그대로(raw data) 저장한다. 하나의 중앙 저장소에 모든 소스로부터 오는 데이터가 저장되기에 누락될 일이 없다. 또한 별도의 스키마 정의 없이 다양한 수집 도구를 활용해 신속하게 데이터를 저장할 수 있으며, 저장 공간과 분석을 위한 컴퓨팅 리소스를 분리해 확장성을 높인다. 아울러 데이터를 사용하는 시점에 원하는 형태로 정의(schema on read)함으로써 활용도를 높이고 관리상의 어려움을 줄일 수 있다.
데이터 레이크에 숨어있는 데이터를 찾기 위해서는 데이터 카탈로그를 사용할 수 있다. 데이터 카탈로그는 기업이 보유한 모든 데이터에 대한 모든 정보를 담고 있으며, 사용자가 필요로 하는 데이터를 검색하고 원본을 찾아낼 수 있는 단일 접점이다. 데이터 원본이 등록된 날짜와 위치, 지속적으로 갱신되는 메타데이터를 고려해 사용자가 원하는 데이터를 찾는다. 이 메타데이터는 사용자들에 의해 지속적으로 갱신되며, 연동 가능한 솔루션들끼리 공유할 수 있다. 또한 사용자는 이미 등록된 데이터 원본에 태그를 지정하거나 관련 문서를 작성해 데이터 카탈로그의 수준을 높일 수 있다. 새로운 데이터 원본을 등록해 기업 내 사용자 커뮤니티의 이해를 돕는 것도 가능하다. AWS는 ‘아마존 글루(Amazon Glue)’, MS는 ‘애저 데이터 카탈로그’로 이러한 기능을 지원한다. 데이터 생태계의 중심에 서는 하둡 비정형 데이터 저장에 있어 빼놓을 수 없는 것이 바로 하둡이다. 아파치 그룹의 프로젝트로 시작된 하둡은 대용량 데이터 처리를 위한 분산처리 프레임워크로 데이터 생태계에서 중요한 역할을 하고 있다. 하둡 분산 파일 시스템(Hadoop Distributed File System)은 페타바이트급 데이터를 메가바이트, 경우에 따라서는 키로바이트 단위의 데이터 블록으로 쪼개 분산된 HW 클러스터로 처리한다. 이는 파일 단위 혹은 볼륨 기반으로 파일을 적재하는 일반적인 파일 시스템과는 다른 부분이다. 따라서 서버의 디스크 용량보다 큰 대용량 파일도 처리할 수 있으며, 하나의 클러스터를 수백~수천 대의 서버를 통해 구성하므로 네트워크의 병목현상을 없애고 가용성을 높일 수 있다. 이는 방대한 규모를 자랑하는 비정형 데이터를 수집하고 분석하는 데에 매우 유용하다. 또한 데이터 리밸런싱 기능을 통해 기존 서버들에 적재돼 있는 데이터들을 신설한 서버들에 분배할 수 있어 손쉬운 증설이 가능하며, 서버를 증설할 때마다 선형적인 성능 향상 역시 기대할 수 있다. 특히 3.0 이후 버전에 탑재된 이레이저 코딩(Erasure Coding) 기능을 활용하면 원본 데이터의 1.4~1.5배 수준의 저장공간만으로도 3개의 복사본(replica)을 다른 블록에 저장할 수 있어 데이터 유실을 방지할 수 있다. 하둡 생태계를 구성하는 컴포넌트 중 하나인 비정형 데이터 수집도구 플럼(FLUME)을 사용하면 IoT 디바이스의 로그 데이터 등을 손쉽게 HDFS에 적재 가능하다. 최근의 하둡 배포판 벤더들은 앞서 AWS나 MS가 주장하는 바와 같이 단일한 데이터 접점의 중요성을 강조한다. 대표적인 글로벌 하둡 배포판 벤더인 클라우데라는 단일한 데이터 접점을 제공하는 ‘클라우데라SDX(Cloudera Shared Data eXperience)’를 제공하고 있다. 클라우데라SDX는 데이터가 어떤 저장소에 적재돼 있든 동일한 애플리케이션을 적용할 수 있는 오픈 플랫폼으로 제공된다. HDFS, HBASE, 쿠두(kudu) 등 하둡 생태계에 포함돼 있는 스토리지 컴포넌트들은 물론, 아마존 S3이나 MS 데이터 레이크와 같은 상용 제품들과도 연동할 수 있다. 수년 전까지만 해도 하둡 컴포넌트들은 RDB를 보조하는 서브 데이터 저장소로 활용되는 경우가 많았지만, 이제는 클라우데라SDX와 같은 하둡 배포판 벤더의 솔루션을 중심으로 RDB나 DW에 저장된 데이터를 연동함으로써 엔터프라이즈 데이터 플랫폼 전략의 중심에 설 수 있게 됐다.
파일럿 프로젝트부터 시작하라 방대한 비정형 데이터를 저장하고 그 사이에서 필요한 인사이트를 찾아내는 것은 기업들에게 새로운 과제로 떠오르고 있다. 이미 많은 기업들이 비정형 데이터에 접근하고자 다양한 기술과 솔루션들을 활용한 시도에 나서고 있지만, 적절한 계획을 세우지 못해 새로운 시스템이 애물단지로 남기도 한다. 이에 대해 데이터 플랫폼 벤더들은 작은 프로젝트부터 전환하라고 권한다. 각 산업 분야의 특징과 기업 문화에 따라서 필요한 데이터 전략이 달라질 수 있으므로, 중요도가 낮은 부분에서 파일럿 프로젝트를 수행한 후 차츰차츰 중요한 영역으로 넓혀가야 한다는 설명이다. 오늘날 데이터가 기업의 비즈니스 성패에 미치는 영향을 고려한다면, 모든 시스템을 하루아침에 전면적으로 전환하는 것은 합리적이지 못한 선택이다. 데이터의 흐름에 배를 띄웠다가 거센 급류에 삼켜지지 않도록 분명한 데이터 전략과 비즈니스 결정이 필요한 시점이다. | ||||||||||||||||||
| ||||||||||||||||||
댓글 없음:
댓글 쓰기