데이터가 21세기 원유라구요? 그렇다면 제일 먼저 생각해야 할 것은 …

몇년전에 가트너에서 데이터는 이 시대의 원유이고 앞으로 데이터는 경쟁우위를 좌우하기 한다는 글을 본 적이 있습니다.
- 이를 인용한 기사를 찾아보니 블로터에 있네요. ^^ (http://www.bloter.net/archives/74906)
 
그러고보니  데이터를 처리하고 분석하는 쓰여지는 일부 영어 단어를 살펴보면 distilled, drill down 와 같은  표현들이 있기도 합니다.
 
데이터를 잘 수집해서 정제하고 분석에 용이한 형태로 변환해서  데이터베이스 시스템에 넣어주는 것을 보통 ETL (Extract, Tranform, Load) 라고 말하고 고가의 ETL시스템들이 여러 분야에 활용되고 있지요. 이러한 시스템이 해주는  일은 다양한 포맷을 가진 데이터 소스를 다른 포맷으로 변환하는 것에서부터 이들을 결합하고 쪼개는 일을 복잡한 프로그래밍이 아니라 GUI 기반으로 손쉽게 정의하고 상대적으로 간단한 스크립팅을 통해서 가능하게 해준다는 것입니다.  당연히 이러한 프로세싱에 필요한 스케줄러를 내장하고 있습니다.  고가의 시스템이긴 하지만 다양한 데이터 소스 (상용 ERP, 데이터베이스, FTP, HTTP, 파일시스템 등) 를 위한 입출력 어뎁터를 갖추고 있어서 매우 유용한 솔루션이라고 할 수 있습니다. 즉 이러한 시스템이 있기에 데이터베이스나 데이터웨어하우스에서 데이터를 손쉽게 분석이 가능한 것은 당연한 것이죠.
 
빅데이터쪽에서도 여러가지의 데이터 수집 프레임워크들이 오픈소스로 공개되어 있습니다 . 대표적으로 Scribe, Flume도 있지만 사실 자신들의 환경에 맞추어 최적화해야 하거나 커스터마이징을 해야하는 것은 피할 수 없다고 봅니다. 오픈 소스는 아니지만 이런 측면에서 최근 Splunk는 정말 많이 주목받는 솔루션이기도 합니다. 그러면서 ETL이 아니라 ELT 라는 말도 나오기도 했죠. 
 
그런데 제가 오늘 말하려고하는 것은 이 영역에서의 업무가 얼마나 중요성한가에 대해서 강조드리고 싶어서 포스팅을 하게 되었습니다. 
 
사실 기업내에 흩어져 있는 다양한 데이터를 수집하고 이의 정합성을 맞춘다는 것이 보통일이 아닙니다. 아무리 각각의 시스템이 잘 개발되고 문제없이 잘 구축되었다고 하여도 운영을 하다보면 데이터를 주는 쪽에서의 문제, 네트워크 환경, 예기치 않은  데이터 오류, 데이터량이 증가함에 따라서 다시 튜닝해야하고 모니터링해야 할 것이 한두가지가 아닙니다. 그리고 애시당초 이러한 데이터를 한데 모아서 분석하거나 한다는 생각으로 설계되고 구현된 것들이 아니기 때문에 더욱 어렵지요.
 
그래서 현업에서 어떤 문제가 발생했을 경우 데이터에 복구와 정합성을 다시 맞추기 위한 일은 사실 데이터를 분석하고 원하는 결과를 뽑아내는 일 이상으로 중요한 것입이다. 가장 큰 이유중 하나는 데이터 규모가 매우 커지게 되면 롤백을 하거나 정합성을 다시 맞추기 위한 일이 생각한 것만큼 만만치 않기 때문입니다. 데이터 복구도 복구지만 복구 자체에 걸리는 시간이 매우 오래걸릴 수 있기 때문입니다. 따라서 대용량 데이터를 처리함에 있어서 이러한 복구와 정합성을 빠르게 하기 위해서는 (네 100% 회피할 수 없으니까요) 초기에 데이터를 저장하는 정책과 구조에 대해서도 반드시 고려를 해야하는 것은 당연합니다. 
 
사실 이게 어떤 정답이 있는 것도 아닙니다. 상황에 따라 쌓이는 데이터의 양, 업데이트주기, 데이터의 중요성, 투자할 수 있는 인프라와 인력에 에 따라서  천차만별일 수 밖에 없는 것입니다. 그래서 이 일을 맡고 있는 개발자나 시스템운영자 입장에서는 노심초사할 수 밖에 없게됩니다. 그런데 이러한 중요성에 비해서 담당자 입장에서는 티가 나는 일도 아닙니다. 문제가 생길때에만 욕만 먹는 위치이고 역할인 것이죠. 
 
빅데이터에 대한 분석과 이를 통한 다양한 가치창출에 대해서들 많이 얘기하시지만 상대적으로 이러한 데이터를 수집하고 정제하는 일은 덜 강조되는 것 같습니다. 이 위치에서 일하는 개발자, 운영자에 대한 역량과 그 역할의 중요성에 대해서 잊지 말아야하고 이 일을 맡는 사람에게도 이점을 강조하고 필요에 따라서는 이에 맞는 대우를 해주어야 한다고 생각합니다. 
 
자동차에 들어가는 맑고 투명한 가솔린을 얻기 위해서 누군가는 사막 한가운데서 바다 한가운데서 시커먼 원유를 온몸에 뒤집어쓰고 시추하는 사람들이 있듯이 다양한 포맷으로 여기저기 저장된 여러 데이터 소스로부터 Raw 데이터를 모으고 처리하는 이 일이 단순하고 저급의 일인듯 하지만 사실상  가장 중요하고 제대로 설계되고 관리되어야 한다는 것입니다.
 
쓰다보니 중언부언이네요. ^^;
 
이러한 일이 그다지 힘들지 않고 크게 대수롭게 느끼지 않다고 생각하신다면 대용량 데이터를 다루고 있는 것이 아니실테니 이런 분은 패쑤~ :-)
카테고리: Uncategorized | 댓글 남기기

소프트웨어 개발자가 빅데이터 기술에 관심을 가져야 하는 이유

지난 주에 다음커뮤니케이션에서 주최하는 DevOn 의 구루와의 대담에 참여하면서 여러가지 얘기를 나누고 답변을 하다가  한가지는 얘기하고 넘어가야겠다는 생각을 하게 되었습니다.

주로 제 블로그의 글들이 빅데이터는 무엇이고 빅데이터는 무엇이 아닌지 그리고 이를 하기 위해서는 어떠한 기술들이 필요한 것 인지 등등 장황하게 설명을 늘어놓았지만 사실 빅데이터 분야에 뛰어들고 관련된 기술들을 배워서 써먹고 싶어하는 분들에게 필요한 글을 포스팅해야 하겠다는 생각이 들더군요.. 특히 소프트웨어 개발자분들에게 말이죠.

최근 신입 사원이나 경력직 지원자들의 이력서를 보다보면 Hadoop 을 해보았다든가 MongoDB 와 같은 데이터베이스를 사용해보았다든가 하는 내용들도 포함되어 있다보니 더욱 관련된 얘기를 써보는게 좋다는 생각이였습니다.

그런데 그전에 잠깐만 빅데이터에 대한 저의 견해에 대해서 다시한번 얘기하는 것이 필요할 것 같습니다.

저는 여전히 빅데이터는 대용량 데이터를 다루는 것을 기본이라고 생각하고 있습니다. 최근 기조를 보면 ‘빅’ 데이터는 예측 분석(Predictive Analytics) 을 의미하는 경우가 많이 있긴 하지만 이것 역시 적은 데이터를 가지고 하느냐 대용량의 데이터를 가지고 하느냐에 따라서 얻어내는 가치가  분명히 달라지기 때문이죠.

기존의 통계 분석을 기반으로 샘플링을 통한 추정과 예측 역시 데이터 분석과 이해를 위해서 매우 중요하고 필수적인 것이고 빅데이터 분석에 있어서 기본이 되는 것이기도 합니다. 하지만 이미 이러한 통계적 기법과 하드웨어, 소프트웨어, 데이터베이스, 데이터웨어 하우스와 같은 기술과 방법들이 있었는데 왜 최근에 빅데이터가 주목받고 있는지에 대해서 많은 분들이 다른 관점에서 설명하고 있는 것은 아닌지  곱씹어 보게 되었습니다.

빅데이터에에서 말하는 데이터 분석에 대한 접근과 기존 통계적인 접근과 데이터 마이닝에서의 큰 차이점은 (적어도 제 생각에는) 샘플링을 통한 통계적 분석과 추정이냐 아니면 전체 모수 데이터를 다루면서 보다 정확한 데이터 분석과 추정이 가능해진 것이 아닌가 합니다.

따라서 어느 규모 이상의 대용량 데이터를 적당한 비용을 들여서 분석할 수 있는 하둡(Hadoop) 이라는 플랫폼과 이를 바탕으로 하는 다양한 기술과 알고리즘은 빅데이터를 얘기할 때 빼먹어서는 안되는 것이죠. 그런데 몇몇 분들은 하둡은 데이터 플랫폼을 구성하는 하나의 구성요소로만 폄훼하시거나 그냥 간단히 기술적 요소로만 취급하시는 것을 보았습니다.

물론 무한대의 예산, 자원, 기술 그리고 시간이 있다면 기존의 데이터 플랫폼(고가의 하드웨어, RDBMS, 데이터웨어하우스, 통계분석 시스템) 을 가지고 빅데이터를 처리할 수 있을 수도 있겠죠. 하지만 현실적으로 우리는 한정된 예산과 자원을 가지고 문제를 해결해야 합니다.  그렇게 때문에 하둡, NoSQL (몽고DB 등등) 와 같은 각종 오픈소스 기반의 대용량 데이터 플랫폼, 데이터 프로세싱 엔진이 주목을 받게 된 것입니다.

국내에서 빅데이터 전문가라하시는 분들중 일부는 하둡은 그냥 데이터 플랫폼중 하나일뿐이야라고 폄훼할 수 있는 이유 중의 하나는 사실상 몇몇 도메인을 제외하고는 대부분 충분히 큰 대용량의 데이터를 다루고 있지 않아서가 아닐까요?

물론 이러한 곳도 하둡과 같은 플랫폼을 잘 활용하면 비용을 절감할 수도 있고 시간이나 자원을 절약할 수도 있죠. 하지만 여전히 이러한 빅데이터 기술을 가지고 있는 엔지니어나 데이터 분석가(요즘은 데이터 사이언티스트) 라고 하는 분들이 많지 않은 것도 중요한 이유이기도 합니다.

RDBMS로 충분히 할 수 있는데 굳이 하둡을 쓸 필요는 없으니까요.

각설하고 원래 하고 싶었던 말씀을 드리자면

빅데이터라는 것이 각광을 받으면서 하둡이나 NoSQL 이라는 것이 부각되면서 제가 흥미롭게 본것은 자연스럽게 기술적인 측면에서 분산 컴퓨팅 기술이라는 것이 부각되었다는 것입니다. 소프트웨어 개발자나 시스템 엔지니어 입장에서 보면 사실 이러한 영역은 또다른 도전이고 새로운 기술을 이해할 수 있는 좋은 기회가 생긴 것이라고 봅니다.

아 그전에 데이터의 처리 방법(프로세싱)들에 대해서 얘기를 좀 해보죠.

빅데이터라는 기술 트랜드로 인해서 자신들이 비록 대용량의 데이터를 가지고 있지도 않고 다루지 않고 있다하더라도 오라클이나 MySQL 과 같은 RDBMS에 데이터를 저장해서 처리만 하던 개발자 입장에서보면 매우 다양하게 데이터를 다룰 수 있는 기술들을 접할 수 기회가 늘어난 것 같습니다.

사실 관계형 데이터베이스가 다양한 분야에 폭넓게 쓰여진 것은 1995년 이후라고 저는 보고 있습니다. 그리고 이러한 관계형 모델의 강력함 때문에 기술을 모르는 사람들도 데이터 모델을 할 수 있고 컨설팅도 하게 되었고 이를 기반으로 개발자들이 개발하고 구현하는 정말 무시해서는 절대 안되는 것입니다만 너무나도 천편일률적으로 데이터에 대한 처리방식이 관계형데이터베이스로만 풀려고 하지 않았나 하는 것도 있지  않았나 생각됩니다.

2000년도 이후 웹기술이 발전하면서  HTML/XML 과 같은 데이터를 전달하고 저장하는 보다 유연한 semi-structure도 등장하고 최근에는  JSON 이 매우 폭넓게 사용되고 있고  많은 NoSQL 들이 이러한 데이터를 기본 데이터 형태로 담을 수 있도록 만들어지기도 했습니다. 더불어 CSV(comma-seprated value) 역시 데이터 원본 포맷으로 많이 활용되고 있습니다.

결국 빅데이터 빅데이터라고 하지만 여기에서 말하는 원본데이터들은 – 바이너리 포맷도 있긴 하지만 –  많은 경우 이러한 semi structured 데이터 포맷으로 저장되고 처리되고 있습니다. 즉 이러한 데이터를 처리하는 것에서부터 빅데이터 프로세싱이 시작을 하게 됩니다.

다시 말하지만 많은 소프트웨어 개발자들은 워낙에 LAMP(Linux, Apache Server, MySQL, PHP) 가 유행을 하면서 raw data을 직접 처리하는 것보다는 관계형 데이터베이스에 더 많이 익숙해있고  데이터를 다루는 역시 관계형 데이터베이스에 넣고 빼는 것을 기준으로 생각하게 설계들을 하고 있습니다. 최근에는 RubyOnRails 같은 것이 유행을 하면서 ORM(Object-Relational Mapping) 을 많이 사용하다보니 데이터베이스의 최적화에 대해서도 소흘해 지지 않았나 싶기도 하더군요.

하지만 빅데이터에서 언급되는 여러가지 데이터 형태와 이러한 데이터를 다루는 다양한 방식과 기술들이 많이 알려졌기 때문에 소프트웨어 개발자들이라면 한번쯤 들여다보고 만져볼 필요는 있다는 것입니다. 비록 대용량데이터를 다루지 않는다고 해도 말이죠. 대용량의 데이터를 배치형태로 처리하는 방식과 스트리밍 형태의 데이터를 실시간으로 처리하는 방식과 데이터 플랫폼 아키텍처는 틈틈히 살펴보면 시스템 아키텍쳐링을 하고 데이터 플로우를 설계하는 여러가지 지식이 쌓여지게 될 것이기 때문이죠.

더불어 Lucene/Solr 은 검색엔진이라고도 말할 수 있지만  텍스트데이터를 매우 효과적으로 처리하고 인덱싱할 수 있는 NoSQL 이라고 할 수 있는데 이러한 것을 접해보시면  관계형데이터베이스의 인덱스만으로 쉽게 해결할 수 없는 것들을 생각보다 빠르게 해결할 수 있는 방법을 배울 수 있게 됩니다.

그러면  프로그래밍 모델에 대해서 한번 애기를 해보겠습니다.

사실 이 부분은 저 역시 옛날 사람이라서 – 더 정확히 말하면 객체지향프로그래밍에 익숙해 있기 때문에 –  이쪽에 대해서는 잘 익숙하지도 않고 잘 모르지만 분산 컴퓨팅, 병렬 프로그래밍이 빅데이터쪽에서 많이 언급되면서 사용되는 언어들에 있어서도  함수형 언어들이 많이 등장하고 이에 대한 저변이 폭넓어지고 있습니다.

빅데이터의 대용량 실시간 프로세싱 프레임워크로 알려진 Storm은 JavaVM 기반의 Lisp 이라고 알려진 Clojure 로 구현되어 있고 여러가지 NoSQL 들은 Erlang 이라는 함수형 언어로 구현되어 있습니다. Spark 이라는 빅데이터 처리 시스템은 Scala 라고 알려진 역시 JavaVM 위에서 실행되는 함수형 언어로 구현되어 있죠. 구글의 Go 라는 언어 역시 병렬프로세싱을 보다 쉽게 구현하기 쉽게 되어 있다고 합니다. 참, Go는 함수형언어는 아닙니다.

제 생각에는 빅데이터가 아니더라도 앞으로 소프트웨어 개발자라면 Java , C/C++ 뿐만 아니라 이러한 함수형 언어정도는 하나 배워두어야 하지 않을까 생각됩니다.

기본적으로 이제 우리는 멀티코어, 멀티머신기반에서 데이터를 처리하는 시대에 살고 있고 심지어 클라우드 컴퓨팅 환경에서 손쉽게 다수의 VM을 운용하면서 프로그래밍을 하고 데이터를 다루는 시대에 살고 있습니다. 빅데이터를 다루는 기술이 기본적으로 이러한 분산 환경, 멀티코어를 극대화할 수 있는 기술들입니다. 앞으로 이러한 기술들이 매우 폭넓게 활용되고 적용될 것입니다.

물론 여러가지 프레임워크나 프로그래밍언어들이 이러한 복잡한 것들을 단순하게 표현하고 쉽게 구현할 수 있게 도와줄테지만 소프트웨어 개발자라면 빅데이터에서 언급되는 최근 기술에 대해서 관심을 가지고 익혀보는 것이 미래에 대한 투자라고 생각됩니다. 빅데이터 관련 프로젝트를 하지 않더라도 말이죠.

마지막으로 인공지능, 데이터 마이닝에 대한 것입니다.

의외로 이 분야는 통계학과 분들에게는 익숙한 얘기이긴 하지만 많은 이 분야의 분들은 SPSS, SAS 그리고 R과 같은 도구를 사용해서 데이터를 다루고 뽑아내는 것에만 익숙하지 않나 생각이 듭니다. 물론 아니신 분들도 많고 이쪽 역시 제 전공은 아닌지라 조심스럽긴 하지만요. 소프트웨어 개발자분들도 이 분야에 대해서 다시 한번 깊이 공부를 하는 것이 도움이 될 거라는 생각이 들더군요. 결국 데이터를 다루는 것이 컴퓨터를 사용하는 가장 큰 이유이기에 그렇습니다.

이 역시 우리가 데이터베이스를 가지고 데이터를 저장하고 가져오는 것에만 익숙해서 그런데 다양한 관점에서 데이터를 추출해서 분석하다보면 또다른 가치를 찾아내는 것은 굳이 통계학과를 나오지 않더라고 가능한 것이고 데이터를 다룰 수 있는 측면에서 본다면 소프트웨어 개발자들도 뒤떨어지지 않기 때문이죠.
요즘엔 워낙에 미국의 여러대학들이 공개한 오픈코스들을 통해서 손쉽게 이러한 교육을 받을 수 있습니다.   물론 본인들 노력이 수반되어야 하겠지만 분명히 배울데가 없어서가 아니라 배우고자 하는 의지가 약해서라는 것이 맞을 것 같습니다. 저 역시 의지박약이라 쉽지 않긴 합니다만 … ^^;

중요한 것은 이러한 측면에서 공부를 하고 관심을 가지시게 되면  되면 기존의 데이터베이스를 설계하는 측면 뿐만 아니라 데이터가 축적되었을 때를 고려해서 분석관점에서도 데이터 모델을 고려하게 되는 역량이 쌓여지지 않을까 생각됩니다. 특히 B2C 서비스(웹서비스, 모바일 앱/웹)를 개발하시는 분들이라면 꼭 한번 이쪽에 대해서 관심을 가지실 필요가 있지 않을까 합니다.

바빠서 먹고 살기도 힘든데 써먹지도 못할 거 뭐하러 배워라고 하신다면 …
노코멘트~

카테고리: IT | 태그: , | 댓글 4개

빅데이터가 그렇게도 중요한가?

아래의 글은 제가 페이스북의 노트에 지난 주말에 쓴 글입니다.이미 보신 분들도 있을 것이구요. 페이스북의 개인 노트는 제가 전체공개로 해놓아도 반드시 페이스북에 가입되어 있어야 볼 수 있더군요.

페이스북에 쓴 글이라서  기존 블로그에 쓰는 것과 다른 점 이해해주세요.  다시 읽어봐도 두서 없지만  그래도 가감없이 재포스팅합니다.


기회가 있어서 나름 업계의 전문가분들과 빅데이터에 대해 얘기를 나누게 되었다.

그전에 …

사실 나보고 빅데이터 전문가라고 말하는게 참으로 부담스럽다.  나는 어떠한 문제를 풀기 위해서 하둡이라는 빅데이터 플랫폼을 활용했을 뿐이다. 당시에는 어쩌면 상당히 도전적인 과제였다고 생각한다. 국내에서는 당시 참고할 만한 내용도 그렇게 많지 않았고 지금과 같이 관련 책이나 플랫폼 배포판이 안정적으로 나오고 있을때도 아니였을때니까. 하둡이 당시 문제를 해결할 수 있는 좋은 방법이었고 리서치할 수 있는 환경도 마련되어져 있었다는게 나에겐 행운이라면 행운이다. 나름 기술의 맥락을 이해하고 추진하고 실적용도 했지만  결과적으로 투자한만큼 성과를 거두었냐고 물어본다면 반반이다.

아무튼 아직도 우리는 빅데이터를 얘기하고 있다. 재미있는 것은 이제 이 녀석을 어떻게 써야 할지 사람들은 충분히 알게 되었다는 것이다.  PoC을 하고나서 본 과제를 진행하지 않기로 결정했다는 것은 어쩌면 정확하게 이 기술이 어디에 적합하고 적합하지 않은지를 이해하고 있다고 생각한다.  외부에서 봤을때는 호들갑만 떨고 안했다는 둥, 역량이 안된다는 둥, 데이터가 없다는 둥 말들이 많을 수 있겠지만  그렇게 생각하는 것은 한쪽면만 보고 말하는 것이다.

무엇이든 때가 있고 적절한 .. 즉 적재적소가 중요하다.

하둡이라고 하는 , 그리고 하둡 에코시스템이라고 하는 기술군들은 기술자들에게는 매우 매력적일 순 있지만 어느 정도 규모의 데이터를 다룬 경험이 없거나 기존 데이터 처리 기술로 충분히 해결 될 수 있다고 판단된다면,  TCO(Total Cost of Ownership, 총소유비용)을 따지자면  빅데이터를 도입하지 않는 것이 되려 합리적인 선택이 될 수 있다. 그렇기 때문에 좀더 중장기적으로 보고 이러한 기술들을 선택해야 한다.

하지만 이러한 기술이 무조건 필요한 경우도 있다. 애초에 데이터가 많고 이를 처리해야 하는데 상용 솔루션을 사용할만한 자금과 리소스가 없다면 내부의 엔지니어을 육성해서 내재화하면서 빅데이터 플랫폼을 구축하는 것이 맞을 수도 있는 것이다.

어느 데이터든 빅데이터 기술에 적용하는 것도 적합한 것이 아니다. 금융정보나 인사정보 등등의 크리티컬한 데이터를 무턱대고 이러한 하둡이나 NoSQL에 저장한다는 것 자체가 말이 안된다.  대용량의 데이터 백업이나 연산을 위하거나,  로우(raw) 데이터를 저장하는 용도로 우선적으로 활용하는 것이 맞을 것이다. 이러한 처리를 끝내고 빅데이터 플랫폼에서 처리하고 그 결과를 RDBMS에 저장해서 서비스에서 활용하는 것이 너무나도 당연하고 들어보니이미 다들 그렇게 아키텍쳐링과 데이터 플로우를 잡고 프로젝트를 하거나 현업에서 활용들을 하고 있다.

그런데…

앞서 빅데이터 전문가분들과 얘기를 나누면서 그리고 내 자신에게 묻고 싶은 것은 도대체 우리가 다루고 있는 데이터의 규모가 정말 ‘빅’ 이냐는 것이다. 고작 클러스터 100대 , 200대 해놓고 몇백 테라바이트 저장하고 프로세싱하는 수준에서 구글이 말하는 페이스북이 말하는 트위터가 말하는 빅데이터와 비견할 수 있는가 하는 것이다. 천대 , 만대 규모의 단일 클러스터에서 발생하는 물리적인 이슈들 (전력, 네트워크, 장애 등등)에 견딜 수 있는 수준의 서비스를 우리가 정말 겪어 본적이 있는가 하는 것이다.

다 … 남들의 경험을  마치 자신들이 해본것처럼 말하거나 자신들이 경험한 자그마한 도메인 지식을 가지고 빅데이터를 얘기들 하고 있는 것은 아닌가 되새겨볼 일이다. 냉정하게 이러한 규모에 대한 감이 없는데 알고리즘 최적화와 엔지니어링이 무슨 의미일까.

Apache Hadoop, Cloudera , Hortonworks 들이 내놓은 하둡 패포판들이 있다. 소프트웨어는 단순히 하나의 배포판 형태로 제공되겠지만 이것들이 다섯대 , 열대, 백대, 천대, 만대로 구성되었을때 그리고 여기에 들어가는 데이터의 형태나 흐름이 각자가 처한 상황에 따라 다 다를진대 비록 그러한 경험과 문제점들을 공유하고 얘기를 나눌 수는 있겠지만 (그나마 국내에서는 이러한 커뮤니티도 몇 없다.) 사실상 각자가 처한 문제를 남이 해결해 줄 수 없는 노릇이 아니겠는가.

감히 말하는데 빅데이터라고 말한다면 자신들이 다루는 데이터를 (남과 공유하기 매우 어려운) 자신들이 직접 다루면서 최적화하는 것이 맞다고 본다. 하둡이 아니여도 상관 없다. 수많은 NoSQL 의 등장은 바로 이러한 요구를 반영한 것이라고 생각된다.

빅데이터를 말하기전에 데이터를 말해야 하는데 우리는 빅데이터 기술을 먼저 말한다.  그리고 이를 기반으로 하는 너무나도 많은 사례 , 서비스를 말한다. 아직 가질 수 없느 갖고 싶은 그런 것들 말이다.

이제는 개발 능력을 상실했지만 여전히 소프트웨어를 사랑하고 소프트웨어 개발에 참여하고 있는 나는 이런 얘기를  들려주고 싶다.

당신들의 데이터가 무엇인지 어떻게 만들어지를 충분히 이해하시라고  그저 외주 개발사, 외주 데이터 마이너에게 맡기고 그저 개발팀 사람들에게 일을 맡겨놓고  왜 남들이 여기저기 말하는 사례를 들먹이며 왜 우리는 그런 가치를 뽑아내지 못하냐고 닥달하지 않았으면 좋겠다.

나 역시 어떠한 면에서는 편향되고 편협된 내 사고 내에서 풀어내는 얘기라는 걸 알지만 빅데이터라는 걸 너무 일반화 시키면서 생긴 문제라고 본다.

머라고 말하시든 나는 big data = large scale data 라고 생각하는 사람이다. 즉 big은 big이다.

헷갈리게 하지마시라.

오늘도 우리는 서버 한대에  최대 얼마나 많은 데이터를 넣고 저장할지 고민한다.  몇천만건 , 몇억건 데이터를 제때 쑤셔넣고 끄집어내는 걸로 골치아파하고 있다.

10대로 할 일 무엇하러 100대로 하겠나?
10대로 안되니까 100대로 하고 1000대로 하는 거다.
맘 같아선 10대로 하고 싶지만 …

big-data-kitty출처:http://wikibon.org/blog/data-scientists-a-new-field-a-new-job

빅데이터 , 빅데이터 하지 말고 그냥 하던 일 하면 된다. 필요한 일 하면 된다.  그게 본질이다.

두서없이 쓰는 글 이만 끝.

카테고리: IT | 태그: , | 댓글 한 개

코끼리등에 올라탄 데이터 솔루션 벤더들 (SQL on Hadoop)

요즘 빅데이터 기술 트렌드에서 주목할 것이 무엇이냐고 한다면 이것이겠죠?

최근에 빅데이터 솔루션 업체들이라고 나서는 기업들중에는 상당수가 기존 데이터베이스, 데이터웨어하우스의 강자들이 많이 있습니다. Oracle, EMC, IBM, Microsoft, Teradata, SAS 심지어 최근에는 Intel 들이 바로 그러한 회사들이이죠. 이 뿐만아니라 오픈소스의 데이터베이스에 있어서도 빅데이터 기술의 연동을 강조하면서 하나같이 하둡(Hadoop)과의 연동과 통합을 강조하고 있다는 것을 알 수 있습니다.

그러면서 하둡이 해결해주지 못하고 있는 실시간 OLTP 기능 , 즉 MapReduce 기반의 성능떨어지는 Hive을 대신해서 자신들이 원래 강점을 가지고 있는 SQL 기반의 데이터 분석 엔진을 하둡위에 올리거나, 통합한 데이터 분석 솔루션들을 시장에 여기저기서 내놓고 있습니다. 클라우데라의 임팔라(Impala)도 사실 시장의 니즈에 맞추어서 이러한 SQL Stack을 자체개발한 거라고 볼 수 있지만 사실 이 분야의 선수들은 따로 있었죠.

흥미로운 것은 이러한 시장 요구사항에 맞추어서 Hortonworks  역시도 Hive 자체의 성능을 개선함으로써 별도의 OLTP(SQL) 스택이 필요없다고 주장하면서 착수한 프로젝트가 바로 Stinger 라고 보시면 됩니다만 결국 이것도 내부적으로는 MapReduce 을 사용하지 않도록 프로세싱 프레임워크를 바꾸고 있습니다.

아래 첨부한 그림을 보시면 아시겠지만 대부분 자신들의 솔루션밑에 데이터 스토리지는 공통적으로 HDFS을 사용하고 자신들의 OLTP(SQL) 병렬처리 엔진을 결합한 것을 알 수 있습니다.

그런데 이런 생각을 해보았습니다. 만일 Stinger 과제가 성공적으로 완료 된다면 (현재 속도의 100배를 약속) 이러한 솔루션 벤더들이 제공하는 별도의 SQL Stack 이 필요할까? 라는 것이죠.

이렇듯 기존 데이터 솔루션 업체들이 부랴부랴 하둡과의 연동을 서둘러 발표하는 것은 새로운 고객과 시장을 찾아나서기보다는 기존에 확보한 자신들의 고객을 지키기위해서 서둘러 빅데이터 솔루션을 만들어내고 있는 것은 아닐까 생각이 들더군요.

여담이지만 국내에서도 어설픈 많은 SI 업체들이 올해 빅데이터 전문기업으로 탈바꿈(?) 하고 있다고 들었는데요. 외국 역시 머 크게 다르겠습니까? 다 먹고 살자고 하는 것이테니까요.

아무튼 Stinger 과제가 성공적으로 이루어져서 Hive의 성능을 “날”로 먹었으면 좋겠습니다. 소문에 의하면 RCFile만 적용해도 10배 빨라진다는데 …

sqlonhadoop2

 

카테고리: IT | 댓글 한 개

[광고] 플랫폼캠프 2013, 플랫폼과 비지니스 모델

제가 운영위원으로 활동하고 있는 PAG 에서 아래와 같이 플랫폼캠프를 개최합니다.
해를 거듭할 수록 내용이 점점 풍성해지네요.
관심있으신 분들은 신청하세요.

플랫폼캠프2013

플랫폼캠프 2013

카테고리: Uncategorized | 댓글 남기기

빅데이터 시대의 정보시스템, 데이터 중심으로 패러다임 쉬프트를 생각할 때

오늘은 오래 전 얘기로 시작해볼까 합니다. 제가 처음 회사 생활을 시작한 것이 90년이니까 벌써 23년이 훌쩍되어 가는 것 같네요. 당시에 제가 들어간 부서는 CAD/CAM 연구소라는 곳이였습니다. 말이 CAD/CAM이 였지만 이외에도 CAE(Computer Aided Engineering) 이라고 해서 컴퓨터를 이용해서 다양한 기계, 전자회로등에 대한 시뮬레이션 역시 하는 부서였었죠. 지금도 당시의 선배들이 여전히 그 회사에 열심히 다니시고 계시죠. 물론 하는 일들은 조금씩 달라졌지만요.

각설하고 처음 제가 하던 일은 캐드파일을 변환하고 관리하는 소프트웨어를 개발하는 것이였습니다. 실제 제품 설계를 하고 있는 엔지니어들을 지원하는 소프트웨어 지원과 구축을 도맡아 할 때였습니다. 그 때 제가 하던 말이 지금도 생각이 납니다. 당시에 여전히 제도기를 이용해서 종이에 설계도를 그리고 소위 블루프린터를 만들어서 배포하고 그러던 때였는데 그 분들한테 어떻게든 캐드 시스템으로 작성해서 컴퓨에 저장만 해놓으면 잘 정리해서 쉽게 찾고 설계변경등이 용이하게 해주겠다고 말하고 다녔습니다. 네, 여기서 핵심은 바로 “캐드 파일 형태로 만들어 컴퓨터에 제발 넣어주세요!”  이렇게 시작한 일이 도면을 관리하고 관련 정보를 데이터베이스에 저장하고 (기억에 오라클 5 인가 6인가 부터 썼던 것 같은데 암튼.) 변경관리를 하고 워크플로우를 만들고 결재 시스템과 연동하고 등등 이러한 일들을 하게 되었죠. 이게 요즘 업계에서 말하는 PLM (Product Lifecycle Management) 의 시초라 할 수 있었던 것 같습니다. ERP 하면 SAP/R3 라는 것이 등장한 것도 한참 뒤의 일입니다.

이것이 불과 20여년 전에 기업에서 일어나고 있었던 일입니다. 당시에는 대부분의 정보들이 여전히 수기로 기록되고 워드프로세스들이 사용되기는 했으나 결재시스템과 연계가 제대로 되지 못하고 있었지요. 하지만 지금은 어떤가요? 너무나도 많은 정보, 데이터들이 기업에서 만들어지고 있습니다. 웹서비스가 만들어내는 데이터에 비해서 상대적으로 작다고 말할 순 있겠지만 이미 전세계의 기업들이 온갖 IT 시스템에 의해서 만들어지는 데이터들은 어마어마하고 국내의 대기업들이 내부에서 사용하고 있는 시스템들은 수백, 수천가지에 이르고 있죠. 생산설비에서부터 마케팅, 세일즈, 고객 정보 , 제품 정보 등등해서요.

그런데 이러한 데이터들의 특징은 기업 내부의 다양한 업무 프로세스나 생산 공정 그리고 체계적인 보고와 예측을 위해서 사전에 잘 정의된 체계 아래에서 저장되고 관리된다는 점입니다. 다시 말하면 각 시스템 자체가 분명한 목적과 틀을 가지고 만들어 졌으며 그 목적에 부합되도록 꾸준히 업그레이드 되거나 유지보수가 되는 그러한 시스템들이 만들어내는 데이터들이라는 것입니다. 이러한 시스템 통합을 위해서도 역시 잘 정의한 프로세스와 규약 아래에서 데이터베이스의 스키마가 정의되고 비지니스 로직이 적용되고 이를 위한 다양한 프레임워크나 플랫폼등이 도입되고 적용되는 것이죠. 그렇기 때문에 사전에 기존 업무를 분석하거나 이를 바탕으로 프로세스를 시스템 하기도 하고 새로운 업무 프로세스나 혁신 업무를 지원(보통 PI , Process Innovation 라고도 하죠) 하기 위해서 시스템이 함께 고려되고 구축되는 경우가 많습니다. 참고로 EP(Enterprise Portal),  메세징 허브 , SOA (Service Oriented Architecture) 이러한 것들은 바로 기업내의 복잡한 시합과 연동을 위해서 제안된 기술 또는 아키텍처라고 할 수있습니다.

소위 레거시 시스템이라고 하는 이러한 정보 시스템에 빅데이터라고 하는 것을 도입하고자하면 어떻게 해야 할까요? 하둡을 적용해서 ? NoSQL 을 적용해서? 이미 이러한 시스템들이 다루고 있는 많은 데이터들은 RDBMS 에 잘 저장되고 관리되고 있는데 여기에 어떤 여지가 있을까요? 여기서 무언가를 해야 할까요? 아무튼 데이터가 무지무지 많으니까 빅데이터 아니냐 할 사람도 있을 것 같고. 빅데이터이고 머고 다 과장된 마케팅 용어라 말하고 이미 우리는 어마어마한 데이터를 이러한 시스템에 담고 있다고 말하는 분들도 있을테지요. 머 간혹 CRM 을 하는 분들이 이거 예전에 한 거랑 머가 다른데 하는 분들도 당연히 계실 것 같네요. (이 말은 G사 대표님이 늘 해주시던 말이라서 살짝 인용하겠습니다. ^^)

사실 많은 기업, 특히 대기업들이 빅데이터를 도입할 때의 딜레마는 이러한 점에서 오지 않을까 생각해봅니다. 즉 체계적인 업무 정의와 이를 바탕으로 구현된 시스템이 만들어내는 데이터를 기반으로 요즘 말하는 빅데이터의 가치를 찾아 낼 수 있을 것인가 하는 것이죠.

단적으로 말하면 사실상 어려울 것입니다. 단순히 대용량 데이터를 처리하는 기술을 도입해서 이를 통해서 찾을 수 있는 비용절감 이 외의 부가 가치를 만들어낼 수 있느냐 하는 질문에 자신있게 답을 할 수 없다는 얘기입니다. 제가 왜  장황하게 제 과거의 한 일들과 기업의 정보 시스템에 대해서 간단히 언급을 한 것은 이 점을 강조하기 위해서 입니다. 기존의 정보시스템이라는 프레임 안에서 교육을 받고 개발을 하고 운영을 하던 많은 사람들의 사고체계와 시스템 체계 안에서는 쉽사리 빅데이터라는 것을 제대로 받아들이고 수용해서 새로운 가치를 찾기가 어렵다는 말입니다. 이 점에 있어서는 저 역시 이러한 관성을 크게 가지고 있는 사람이여서 마찬가지라고 생각이 듭니다만…

다시한번 간단히 정리하면 이렇습니다. 대부분의 기업 데이터들은 필요한 업무 프로세스를 지원하기 위해서 정의된 정보 시스템에서 만들어진것이다. 데이터가 어떻게 생성되고 어떤 프로세스에 의해서 만들어지는가가 명확합니다. 그 만들어지는 데이터의 범위와 양도 충분히 예측이 가능하죠.

제 블로그나 기타 빅데이터에 대한 글을 보신 분은 3V(Volume, Velocity, Variaty 또는 4V(+ Value) 이런 얘길 많이 들어보셨을테지만 정말 중요한 것은 바로 데이터가 어디에서 어떻게 만들어지는가입니다. 공교롭게 빅데이터라고 하는 대용량의 데이터들은 앞서 말한 잘 정의된 프로세스와 스키마 안에서 만들어지는 데이터들이 아닙니다. 오히려 구글은 온갖 웹상의 문서를  크롤(자신들이 정의하지도 직접 만들지도 않은) 해서 거대한 빅데이터 플랫폼을 바탕으로 검색 서비스와 검색 광고 시장을 잡고 있습니다. 페이스북이나 트위터 역시 데이터를 만들어내는 플랫폼만을 제공하지 그 안에서 만들어내는 데이터와 친구관계라는 정보는 사용자들에 의해서 생성되고 이를 바탕으로 역시 광고나 새로운 서비스를 선보이고 있구요. 페이스북이나 트위터 역시 사용자들의 행태를 보고 서비스를 바꾸어나가는 것이지 꽉 짜여진 틀안에서만 데이터를 입력하게 하고 있지 않습니다. 오히려 더 다양한 데이터를 담을 수 있도록 노력하고 있다는 것을 알 수 있을 것입니다. 아마존이나 네플릭스와 같은 추천 엔진들 역시 고객들의 거래 정보를 바탕으로 이루어지는 것이고 이 정보 역시 원래 서비스가 제공하는 프로세스와는 별도로 저장되던 고객의 거래 정보를 활용해서 적용된 것입니다. (아마존의 추천 시스템을 적용한 엔지니어에게 제프 베조스가 무릎을 꿇고 경의를 표했다는 얘기도 들리던데..) 그래서 빅데이터에 많이들 강조하는 것이 데이터에서 그 가치를 찾아내는 것이라고 말하기도 하고 ‘오일’ 이라고도 표현하기도 하죠.

미묘하지만 바로 여기서 패러다임의 전환이 필요합니다. 미리 잘 정의된 프로세스와 데이터 스키마에서 만들어지는 데이터라는 것은 이미 그 가치가 프로세스가 잘 돌아가게 만들어진 그 시스템에 부여된 것이지만 빅데이터라고 하는 것은 그게 무엇이든 데이터로 시작해서 그 데이터를 기반으로 가치를 찾아내는 것이라고 생각하면 됩니다.

좀더 쉽게 이해하기 위해서 다른 예를 들어보겠습니다.  전파망원경이나 입자가속기에 대해서 들어보셨을텐데요.  이러한 측정 장비들은 하루에 수PB 의 데이터를 생성하고 있습니다. 그런데 이러한 기기와 데이터를 처리하고 연구하는 50여명의 몇 안되는 과학자들을 위해서 천명이 넘는 소프트웨어 엔지니어들이 이런 데이터를 저장하고 분석할 수 있는 소프트웨어 개발을 합니다. 비록 극단적인 예가 될 수 있겠지만 바로 엄청난 데이터 속에서 가설을 정의하고 이 가설을 뒷받침하는 정보를 찾아내기도 하지만  이제는 더 나아가 이러한 소프트웨어 프레임워크와 도구를 이용 대용량 데이터를 다양하고 빠르게  분석함으로써 새로운 이론을 이끌어내고 있다는  것입니다.

과학계쪽의 기존 방법론은 우선 이론을 정립하고 식을 만들고 이를 뒷받침하는 실험이나 관찰을 통해서 입증하는 것이였다면 이제는 엄청난 측정 장비와 대용량 데이터를 기반으로 거꾸로 새로운 이론이나 가치를 찾아내고 있는 것입니다. 그리고 이를 지원하는 소프트웨어라는 것이 데이터를 잘 수집하고 분석하고 시각화 할 수 있는 도구라는 점이 기존의 프로세스 중심의 시스템과 큰 차이가 있습니다.

여전히 많은 사람들이 빅데이터가 무엇인가에 대해서 혼란스러워하고 각기 다르게 해석하는 큰 이유가 기존의기업시스템이나 정보시스템의  패러다임에 고착되어 있어서가 아닐까 생각됩니다.

이러한 관점에서 본다면 빅데이터라고 하는 (사실 data-driven , data-intensive 라는 말이 더 정확한 표현이 아닐까 생각 합니다만) 것은 이제 시작일지 모릅니다. 하둡(Hadoop_ 이라는 것이 이제 비로소 이러한 패러다임 전환을 뒷받침할 수 있도록 상대적으로 저렴한 비용으로 빅데이터를 처리하는 데이터 플랫폼의 시초가 되는 것은 아닐까 하는 생각이 드는 것이죠.  여전히 대용량 데이터에 대한 분석 도구, 분석 알고리즘,  시각화 도구들이 여전히 부족합니다. 당연하지만 이러한 기술과 전문 인력을 가진 구글, 아휴, 페이스북과 같은 회사들이 이 분야에서 크게 두각을 나타내고 있습니다.

이러다보니 많은  기업들이 이들을 쫒아가려하지만 근본적인 역량 확보와 접근에 있어서 한계를 가질 수 밖에 없다고 봅니다. 또한 고객의 사용 정보나 센서 정보들이 충분히 축적되어 있지 않다보니 플랫폼이나 빅데이터 분석 도구에 대한 니즈에 대해서 깊이 고민할 기회도 없었을 것입니다. 최근 빅데이터의 트랜드에 편승해 서둘러 빅데이터 플랫폼을 구축하지만 분석은 커녕 충분히 저장된  데이터는 하나도 없을 수도 있을 겁니다.

그래서 웹서비스 기업(포털, 게임회사 등) 들 ,  통신회사들은 하둡과 같은 빅데이터 기술 도입을  빠르게 진행하고 나름 수혜를 받고 있는 반면에 전통적인 일반 기업에서의 빅데이터 도입은 쉽지 않을 뿐더러 그 사례를 찾기가 쉽지 않은 이유이기도 합니다.

아무튼 프로세스 중심(Process-Driven)의 정보시스템에서  이제 데이터 중심의(Data-Driven) 정보시스템으로 바뀌는 시대가 되었습니다

여러분들은 갈아 탈 준비되셨나요?

덧,  The Fourth Paradigm 이 책 한번 읽어 보세요. 이번 포스팅을 쓰게 된 동기가 되었는데요.  다 볼 필요는 없고 샘플을 킨들로 받아서 서문만 읽어봐도 좋을 듯 싶습니다.

The Fourth Paradigm

카테고리: Books, IT | 댓글 한 개

에버노트에 쓰여져 있던 빅데이터(Big Data) 에 대한 단상…

오늘 에버노트를 정리하다가 적혀 있는 빅데이터에 대한 이것저것 작성해 놓은 것이 있어서 공유합니다.  보통은 제가 경어체를 쓰는데 저 혼자 정리한 것이다 보니 말투가 좀 그렇습니다. 이해해주시길 바랍니다. 제 블로그를 통해서 했었던 말들이고 중언부언이지만. 아마 발표자료 준비를 하다가 생각나는데로 적어 놓았던 것 같은데요.

 

올해 혹시나 빅데이터 프로젝트 하시는 분들 다시 한번 잘 생각해보세요. 정말 해야 하는 프로젝트인지 말이죠. ^^

  • 빅 데이터는 솔루션으로 해결할 수 있는가?
    • 기존의 IT 기술과 차이점은 어떤 것이 있는가?
      • 당연히 기업의 가장 은밀하고 중요한 내부 데이터를 함부로 외부에 공개할 수가 없다
      • 외부의 전문가 , 개발자들이 프로젝트로 참여해서 이러한 데이터를 다루고 처리하는 것이 쉬운 일이 아니다.
        • 역량이 쌓이지도 않는다. 기술 내재화가 필요한 것이다.
      • 데이터를 쉽게 수집하고 저장하기 위해서 하둡이라는 것이 규모가 커지기 시작하면 생각보다 그렇게 간단치 않다
      • 끓임없는 시행착오와 최적화 작업이 필요한 것이다. 소프트웨어, 하드웨어, 프레임워크, OS 모두를 고려한 엔지니어링이 필요하다
      • 그래서! 여건이 된다면 잘 알려진 오라클, DB2 등과 같은 고가의 상용 데이터베이스 시스템과 관련 솔루션등을 구매해서 활용한다
      • 매우 잘 표준화되어 있고 관련 기술 교육도 용이하고 인력 확보도 상대적으로 쉽다. 벤더들이 열심히 교육도 시켜준다.
    • 하둡과 빅데이터 기술은
      • 소프트웨어 기술과 시스템 기술이 결합되어서 활용될 수 밖에 없다
      • 이러한 인력이 국내에는 많지 않다
      • 너무나도 잘 분업화되어 있다보니 양쪽을 이해하고 최적화할 수 있는 DevOps 역할을 할 수 있는 인력이 적다
      • 특히 국내에서는 시스템 엔지니어에 대한 대우나 평가가 소프트웨어 엔지니어어 비해서 더욱 좋지 않고
      • 좋은 인력 양성도 되어 있지 않다. 많은 시스템 엔지니어들이 매우 단순한 작업에 매진하고 있다
      • 이러다보니 표준화되어 있는 데이터베이스, 운영체계에 익숙한 인력들만 있고
      • 빅데이터 기술을 최적화하고 엔지니어링할 수 있는 인력 확보는 매우 어려운 것이 현실이다
      • 실제 현업에서 더욱 이러한 문제에 많이 부딪히고 있다
      • 그래서 포털회사나 게임회사에는 이러한 경험과 기술을 가지고 있는 고급 인력들이 있으나 그 외에는 찾기가 쉽지 않다.
      • 최근에 이러한 기술 인력들에 대한 대우들이 좋아지고는 있다.
      • 빅데이터에 대한 기술은 외부에서 가져오는 것이 아니라 내부에서 역량을 쌓고 노하우를 쌓아야 하는 것이다.
      • 대용량 데이터가 없다면 역량이 쌓일리가 없다. 그냥 좋은 컴퓨터와 스토리지로 해결하는 것이 훨씬 낫다.
      • 이러한 점을 간과하면 프로젝트를 실패하기 쉽게 국내의 많은 벤더들이 이러한 기술을 갖추고 있는 엔지니어들을 확보하지 못해서 실제 빅데이터 비지니스를 하지 못하고 있다.
  • 국내에 페타급 데이터를 보유하고 처리할 니즈가 있는 곳이 얼마나 될 것인가?
    • 앞으로는 빅데이터 트랜드에 따라서 늘어나겠지만 실제 페타바이트를 처리할 니즈가 있는 곳은 별로 없다
    • 이것이 바로 빅데이터 트랜드에서의 함정이라고 할 수 있다
    • 많은 데이터 분석 솔루션 업체들은 데이터의 크기보다는 데이터의 특성을 잘 활용해서 분석하고 예측하는데 그 노력을 기울이고 있다. 하지만 … 이것 역시 한계가 있다
    • 빅데이터는 역시나 빅데이터이다. 대용량 데이터를 가지고 있고 이를 통해서 가치있는 정보를 찾아내고 이를 이용해서 기업활동에 활용할 수 있어야 하는 것이다
    • 빅데이터는 기존 통계, 예측해서 말하는 샘플링이 아니라 ‘모수’ 그 자체를 다루는 기술이라고 말할 수 있기 때문이다
    • 데이터가 많지 않다면 차라리 기존의 데이터베이스 솔루션과 분석 솔루션을 활용하는 것이 바람직하다
    • 어설프게 빅데이터 기술을 적용하면 오히려 시스템은 복잡해지고 비용만 급증하게 되는 애물단지가 될 수밖에 없다
  • 작은 기업에서의 빅데이터 활용
    • MySQL 과 같은 오픈소스 데이터베이스와 함께 운영되는 데이터 분석 플랫폼. 그런데 MySQL 보다 더 큰 규모의 데이터를 가지고 있는 경우 검토.
    • 너무 큰 규모의 클러스터 구축은 피해야 한다. 차라리 클라우드 컴퓨팅 서비스를 이용할 생각해야 한다.
    • 글로벌 서비스를 준비하는 스타트업들에 있어서는 고려해볼 필요가 있다
  • 작게 그리고 단계적인 접근이 필요하다
    • 내재화 할 수 있는 인력을 갖추고 있지 않으면 시작하지 마라
    • PILOT 과 실제 적용은 크게 다를 수 있다
    • 시스템의 규모가 커지면 분산컴퓨팅과 규모에 따른 다양한 문제점에 부딪히게 된다.
    • 기술이 아니라 노하우다
    • 그것은 바로 각 기업이 다루는 데이터의 규모와 특성에 따라 달라질 수 밖에 없기 때문이다.
    • RDBMS 와의 연동, 병행을 반드시 생각해야 한다.
    • 레거시 시스템은 늘 고민거리다
  • SQL은 영원하다
    • 빅데이터 솔루션들은 그 위에 SQL 을 지원하도록 진화하고 있다
    • TABLE 이라고 하는 로지컬 모델은 여전히 강력한 도구이다
    • 기존의 분석 인력들이 손쉽게 활용이 가능하게 되었다
    • 하지만 호수의 백조처럼 그 아래의 DevOps 의 역할은 최적화를 위해서 더욱 커지게 된다.
    • Tools
      • Apache Hive
      • Cloudera Impala
      • Teradata Aster’s SQL-H
      • EMC Pivotal HD , HAWQ
      • Informatica
      • 이 밖에도 참 많다.
카테고리: IT | 태그: , | 댓글 남기기