구글이 개발해 오픈소스로 내놓은 데이터 주도 프로그래밍 모델 ‘빔’이 아파치소프트웨어재단의 톱레벨 프로젝트로 승격됐다.
아파치 빔은 실시간, 배치 등의 데이터 처리 엔진을 단일 프로그래밍 모델로 처리할 수 있게 하는 프레임워크다.
스파크, 스톰, 에이펙스, 플링크 등의 실시간 데이터처리 엔진과 변환 함수, 연산 엔진, 소스, 타깃 등의 구성요소로 이뤄지는 데이터파이프라인을 추상화해 만들고, 어떤 엔진에서든 이동시켜 활용할 수 있게 한다.
빅데이터 처리 엔진은 저마다 다른 API를 사용하므로, 통합적인 활용이 어렵다. 예를 들어 아파치 스파크로 만들어놓은 데이터 분석 환경에서 엔진을 플링크로 변경하려면 기존의 데이터 활용 방식은 쓸 수 없다. 하둡 기반의 배치 분석 환경은 실시간 스트리밍 분석 환경과 병렬로 따로 운영해야 한다.
아파치 빔은 배치나 실시간성에 상관없이 여러 데이터 엔진을 단일한 API로 쓰게 하고, 단일 코드와 클러스터를 기반으로 운영하게 함으로써 개발자의 생산성을 높여준다.
아파치 빔은 그간 구글의 빅데이터 분야 오픈소스 전략에 중대한 변화를 보여준다는 점에서 주목된다.
구글은 그동안 내부에서 개발한 인프라 기술을 오픈소스로 내놓기보다, 기술논문 형태로 개념만 공개했었다. 오픈소스 진영의 개발자들은 구글의 논문을 참고해 직접 소프트웨어를 구현했다. 대표적인 게 하둡 생태계다.
아파치 빔은 애초부터 오픈소스로 공개됐다는 점에서 이전과 전혀 다른 발전방식을 취한다. 구글도 내부 인력에 의존하는 개발로 치열한 경쟁에서 뒤처질 수 있다 판단한 것이다.
또하나 흥미로운 사실은 아파치 빔이 실시간 분석 영역에서 대세 기술로 떠오른 스파크의 잠재적 경쟁자란 점이다.
아파치 빔은 스파크를 지원하고 있지만, 구글 클라우드 데이터플로우도 지원한다. 아파치 빔을 쓸 경우 사용자의 요구사항에 맞는 데이터 처리엔진을 골라 쓸 수 있게 된다.
구글은 약 1년 전 클라우드 데이터플로우와 아파치 빔의 조합에 아파치 스파크를 비교한 글을 올렸다. 이 글은 두 모델의 코딩 효율성과 성능을 비교하고 있는데, 은연중 클라우드데이터플로우의 우위를 강조한다.
또한 아파치 빔은 구글 클라우드 데이터플로우 서비스에서 SDK와 데이터 흐름 모델을 추출했다. 빔 프로그래밍 모델은 아파치 에이펙스, 플링크, 스파크 스트리밍 엔진 등을 70% 정도만 지원한다. 각 스트리밍 기술이 엔진에 종속적인 독자적 API를 사용하기 때문이다. 아파치 빔의 이점을 완전히 누리려면 구글 클라우드 데이터플로우를 쓰는 게 낫다는 의미다.
스파크의 경우 2.0버전의 일부로 스트럭처드스트리밍이 개발되고 있다. 스파크의 현재 스트리밍 기술은 배치 작업을 아주 짧은 시간 단위로 쪼개 수행하는데, 이를 진정한 실시간 스트리밍으로 고도화하는 것이다.
또한 스파크는 SQL로 하둡 데이터를 분석하는 임팔라나 호크에 비해 랜덤 액세스와 대화형 쿼리에서 비효율적이다. 결국 개발자는 스파크에 올인하기보다 다른 기술도 진지하게 고민하게 된다.
이에 따라 개발자는 데이터 처리 기술마다 제각각인 기법을 따로 익혀야 하는데, 아파치 빔은 이 틈을 파고 든다.
클라우드 데이터플로우가 아파치 빔을 통해 모든 데이터를 수용하는 표준으로 자리잡을 수는 없다. 그러나 아파치 스파크가 데이터 엔진의 표준 자리를 차지하는 건 저지할 수 있다.
관련기사
- 하둡의 아버지 “코어 하둡의 대체재? 상관없다”2017.01.18
- HPE-호튼웍스, 아파치 스파크 중심으로 협력 확대2017.01.18
- 하둡과 스파크는 경쟁 관계인가2017.01.18
- 구글, 내부 핵심 DB기술도 클라우드로 판다2017.01.18
만약 아파치 빔이 성공한다면, 개발자들은 스트리밍 엔진을 비롯한 데이터 엔진에 대한 도전 리스크를 해소할 수 있게 된다.
논문 하나로 빅데이터 시장을 열게 했던 구글이 새 오픈소스 전략을 앞세워 빅데이터 시장을 어떻게 바꿀지 주목할 만하다.