너무 큰 빅 데이터 생태계
Big Data Encosystem is damn too big
현재로서는 빅 데이터 생태계는 너무 크고 복잡하고 중복돼있다. 빅 데이터에 구현하려고 기업에게 이미 혼란스러운 시장이다. 기업들이 빅 데이터 수많은 기술 스택들과 너무 많은 의사 결정을 직면하게 될 때 더욱 어려움에 처하게 된다.
빅 데이터 생태계에는 너무 많은 표준이 있다. 너무 많은 엔진이 있다. 너무 많은 공급 업체가 있다. 현재 존재하는 생태계는 고객을 소외시키고 고객 프로젝트의 기금을 억제하며 조직 내에서 정첵적 지원받는 것을 힘들게 한다. 그렇다면, 사용자는 무엇을 할 수 있을까?
The Big Data Ecosystem: Too Many Choices
• BI/분석: 빅 데이터 스택의 상단에 있으며, 끝없이 많은 선택이 있다. 엔터프라이즈 BI 지지자, BI 2.0 도전자, 또 빅 데이터 분석 플레이어, 많은 공급 업체의 수와 그럼에도 불구하고 유사한 기능은 고객이 BI/분석 툴을 결정하는 것을 정말 어렵게 한다.
• 배포판: 스택에서 아래로 이동하여 하둡 및 스파크 배포 계층에서 선택할 것 역시 많다. 그것은 Cloudera, Hortonworks 그리고 MapR로 대변되는 빅 쓰리는 Spark 통합된 각각 자신의 하둡 분포를 제공한다. 거기에다 IBM의 다른 제품에 추가하고, 클라우드 플레이어, 크고 작은 빅 데이터 베포 회사들은 빅 데이터 선택에 있어서 사용자를 조금 미치게 한다.
• 실행 엔진: 너무 많은 실행 엔진이 있다. 하둡 MapReduce에서 Tez로 이동하고 있다. 그리고 Spark 자체도 자리를 잡고 있다. 아파치 Flink도 부상하기를 기다리고 있다. 스트리밍 측면에서 아파치 Storm, NiFi, Spark 그리고 kafka, 그 외 다양한 조합이 있다. 그리고 대규모 데이터 머신 러닝이 Apache mahout으로 시작하여 Spark mllib으로 이동하는 것으로 보인다. Spark는 YARN에서 실행될 수 있으며 Hadoop 2.0의 리소스 관리자에서 이용할 수 있는 것처럼 또 어떤 리소스 관리자를 써야 할지 하는 선택이 있다.
• sql, 데이터 집합 및 실시간: sql은 빅 데이터 문의 시 기존 활용 스킬 세트를 사용하는 것을 가능하게 하는 반면, 너무 많은 sql이 존재한다. 예를 들면, Hive를 사용해야 할까? 당신은 Hive를 사용하는 경우, MapReduce, 또는 Tez 중 어떤 걸 사용할까? 또한, Impala를 잊지 마라. 또는 HAWQ, 아파치 Drill, Presto 및 테라 데이터, HP, 마이크로 소프트, 오라클 및 IBM을 포함 한 빅 데이터베이스 공급 업체의 모든 SQL-하둡 브리지를 쓸 수 있다, SQL을 사용 하는는 것이 하둡이 제공하는 고유한 혜택에 상반될 수 있다는 것도 명심하자. 또 다른 혼란은, 적은 수의 구성 요소를 가진 잘 정의된 스택 내 에서도 분열화가 만연 할 수 있다는 것이다. Spark 세계에서 RDDs(Resilient Distributed datasets), DataFrames 또는 데이터 집합을 사용할 수 있다. 그리고 스파크 개발자 들은 스트림 데이터를 위해 새로운 spark 구조화된 스트림을 사용할 수 있다. 하지만 Kafka 스트림은 어떤까?
• 코딩을 할까 말까?: 프로그래밍 언어에 관해서, R 또는 Python에서 코드 할까? Scala는 어떨까? Java와 c#을 사용 하 여 빅 데이터 코드를 작성하지 않는 이유는 무엇인가?
현시대에서 빅 데이터를 수집하고, 저장하고, 관리하고, 분석하며 활용하지 않을 수 없다. 그러면 어떻게 빅 데이터 시스템을 구축할 것인가?
1) 항상 사용 사례로 시작
빛나는 기술에 의해 현혹되지 말라. 최근 Gartner 설문 조사에서 응답자들이 인용한 가장 큰 빅 데이터 도전 과제는 "빅 데이터에서 가치를 얻는 방법 결정" (응답자의 58%)이었다. 어떻게 그것을 해결할까? 항상 사용 사례를 정의하고 이를 지원하는 기술을 찾는 방향으로 작업하라. 모든 제품이 다 같은 것은 아니다. 제품마다 장단점이 있다. Spark를 이용하기 위해선 Python이나 Scala를 쓸수 있다. Hadoop를 이용할 수 있고 없이 쓸수도 있다. 빅 데이터 문의 툴도 수 없이 많다. 먼저 툴을 고르지 말고, 어떤 데이터를 어떻게 처리하고 어떤 식으로 이용할지에 대한 분명한 정의가 되야 하고 그 바탕위에 적당한 툴들을 고르면 된다.
2) 변한한 툴을 골라라. 어떤 경우는 Spark에서 Python을 쓰든 Scala를 쓰든 성능면에서 크게 차이 나지 않을 때도 있다. 그렇다면 개발자과 Python에 익숙하면 Python을 쓰면 된다.
3) 어느 정도 제어할 것인가?
위에서 암시된 것처럼 코드를 사용할 수 있는 도구를 사용하여 자신/팀에게 상세 수준 컨트롤을 제공하는 것이 좋다. 그러나 얼마나 많은 컨트롤이 실제로 필요한 지 조심해야 한다. 이는 셀프서비스 툴 링을 사용 하 여 조직의 더 많은 사람들에 게 데이터를 제공하는 것이 더 좋은 방법 일까? 적정한 균형을 찾아야 한다.
4) 미래 대비를 위한 생각
산업은 수축과 확장을 반복하는 것을 우리는 목격해 왔다. 따라서 기술 구매를 평가할 때 모듈식 "플러그형" 아키텍처를 통해 기술 자체의 "미래 지향적" 또는 "미래 대비"를 나타내는 징후를 찾는 것이 매우 중요하다. 다음에 빛나는 새 프로젝트나 표준에 따라 도약 하 고 싶지 않을 수도 있기 때문에, 그렇게 하는 것이 신중 해지면 이 옵션으로 마이그레이션 하는 옵션이 필요할 것이다.
Note: 이 글은 2018년 2월 23일에 "The Big Data Ecosystem is Too Damn Big"란 제목으로 Datameer 블로그에 실린 글을 번역하고 일 부는 개인의 의견을 첨부한 것이다.
원본은 다음 링크에서 볼 수 있다.
https://www.datameer.com/blog/big-data-ecosystem/
