[Cloudera 블로그 번역] 2014/01/07 Impala 와 Hive 전략에 관해서

 

일어 원문 : http://www.cloudera.co.jp/blog/20140107-impala-v-hive.html - 일본 Cloudera Blog

영어 원문 : http://vision.cloudera.com/impala-v-hive/ - 미국 Cloudera Blog

 

- 본 글은 위 일어 원문 링크의 글을 번역하였습니다.

- 일어 원문 글은 위 영어 원문 글을 번역한 글입니다. 번역투가 많아 영어 원문도 살짝 참조하였습니다.

 


 


 새해 복 많이 받으세요. 여러분들 덕분에 올해도 무사히 새로운 한 해를 맞이할 수 있게 되었습니다.

 

 자 그럼, 올해 첫 블로그 기사는 작년말에 CSO (Chief Strategy Officer) Mike Olson(@mikeolson)이 공개한 블로그 포스트, Impala v Hive를 소개하려 합니다. 2014년도 잘 부탁 드립니다.

 

 


 

 저희 회사는 일 년여 전에 Cloudera Impala를 공개 했습니다. 회사에게 있어 좋은 런칭 이었죠. 플랫폼에서 고객들이 중요하게 여기는 몇 가지 점들이 더욱 좋아졌고, 사업면에서 큰 성과를 거둘 수 있게 되었습니다. 이전의 제품은 대화형 SQL 처리량에 대응하지 못 했거든요.

 

 Impala 공개의 영향으로 Apache Hadoop 에코시스템에서 SQL 시장의 공유를 바라는 벤더들 간의 격한 경쟁에 불을 붙여 여러 주장과 반론이 난무했습니다. 성능 면에서 과장된 말들이 자주 보이는데 (저희는 저희의 성능 평가 결과가 꽤 마음에 들었습니다만) 여기서는 다른 방향에서 이 문제에 대해 접근 하려 합니다.


 저는 기존 Apache Hive 프로젝트 개선에 의한 것이 아니라, 새로운 프로젝트로 처음부터 Impala를 개발하게 된 Cloudera의 결정에 대해 자주 질문을 받습니다. 사람들은 기존의 코드가 있다면 거기서부터 출발 하는 것이 최선이라고 생각하니까요.

 

 하지만 그것은 틀립니다. 저희는 그 문제에 대해 장기간 진지하게 생각 했고, 최선의 방법은 Hive와는 다른 원리를 기반으로 새로운 오픈소스 프로젝트를 설계하는 것이라고 결론 내렸습니다. 그게 바로 Impala 입니다. 작년 1년간 저희의 경험은 이 전략에 대한 확신을 강하게 만들었습니다.
 어떤 것인지 한 번 보시죠.

 

Pig와 Hive 의 기원

 

 Hadoop 초창기 버전은 데이터를 다루기 위한 방법으로는 오직 한가지, MapReduce만 지원 했습니다. 이 플랫폼은 대량 데이터를 저장, 처리, 분석 할 목적으로 Yahoo! 와 Facebook 에서 넓게 사용 되었습니다. 두 회사 모두 이 플랫폼의 가치를 잘 이해했지만, 시스템에서 유용한 성과를 얻기 위해 MapReduce에서 동작하는 Java 코드를 짜는데 많은 시간이 필요 했습니다.

 

 두 회사는 보다 빠르게 동작하고, 비개발자가 데이터를 직접 다룰 수 있기를 원했습니다. Yahoo!는 이를 위해 Apache Pig란 명칭의 독자 언어를 만들어 냈습니다. Facebook은 사람들에게 새로운 기술을 교육하는 것 보다 기존 기술을 활용하는 방안을 생각하여 Hive 라는 명칭의 SQL 시스템을 구축 했습니다.


 이 두 가지는 매우 흡사한 원리로 동작합니다. 유저는 Pig 나 Hive 중 하나로 쿼리를 날립니다. 파서(parser)는 쿼리를 읽어 들여 유저가 무엇을 바라는지를 이해하고, 일련의 MapReduce Job을 실행하여 동작하게 합니다. MapReduce를 사용함으로써, Pig와 Hive를 쉽게 구축 할 수 있었기 때문에 Yahoo! 와 Facebook의 엔지니어는 다른 새로운 기능에 시간을 쓸 수 있었습니다.


역사의 대상

 

 보통 Hadoop에 대한 비판은 MapReduce가 배치(batch) 데이터 처리 엔진이란 것입니다. Hadoop은 데이터 매니지먼트 업계를 근본적으로 변화 시키는, 굉장히 유용한 배치 데이터 처리 엔진임은 분명합니다. 하지만 설계상 MapReduce는 매우 무거운데다, 하이 레이턴시(high-latency) 실행 플레임워크입니다. 또, job 개시가 느리고 여러 종류의 오버헤드를 갖고 있다는 것은 공정한 비판이라고 생각합니다.
 Pig와 Hive는 이들 특성을 이어 받고 있습니다.

 

 초기에 이런 것들은 별 문제 되지 않았습니다. 분석이나 보고를 위해 자신의 BI 툴을 Hadoop과 연결하는 사람은 없었습니다. Yahoo!와 Facebook은 보다 많은 유저가 데이터를 직접 다룰 수 있기를 원했습니다. 그 유저들이 동작이 실행 되고 있는 사이에 컴퓨터 화면을 보면서 잠시 가만히 앉아 있어야 해도 그리 큰 문제는 아니었습니다. 느린 쿼리라도 쿼리가 없는 것 보다는 나으니까요. 이런 초기 워크로드의 대부분은 데이터 변환 처리일 뿐 쿼리도 분석도 아닙니다. 배치는 이 부분에 대해서는 문제 없었습니다.


 관계형 데이터 베이스에 데이터를 전송 하기 위해 ODBC나 JDBC를 이용하는 툴은 많은 벤더를 통해 입수 할 수 있습니다. 하지만 이런 툴을 Hadoop에서 동작 하도록 하는 것은 정말 큰 문제입니다. 데이터를 이런 방법으로 쉽게 다루고 싶어하는 비즈니스 유저는 굉장히 많습니다.


 이에 저희는 먼저 광범위하게 이용 가능한 Hive용 ODBC 드라이버를 릴리즈 했습니다. 대형 벤더들은 보고용 툴을 저희 플랫폼에 연결 하기 위해 그 드라이버를 사용하였습니다. 하지만 이런 툴을 사용하는 것은 정말 참기 힘든 일이었죠. 유저는 쿼리를 작성하고 버튼을 누른 후 기다리고, 기다리고, 또 기다립니다. 몇 십 년에 걸친 경험에 의해 사람들은 데이터베이스에 실시간 반응을 기대하게 되었습니다. MapReduce 상에 구축된 Hive는 기대에 따른 결과를 낼 수 없었습니다.

 

 실제로 Hive 성능은 일부 벤더의 툴이 전혀 동작하지 않는 것을 의미 했습니다. 툴은 응답이 빨리 오지 않았을 때에 데이터베이스가 고장 났다고 여겨 유저에게 에러를 보냈습니다.
 이에 많은 유저들이 화를 냈습니다.


Impala 개발

 

 저희 회사에서는 Hadoop 에코시스템에서 SQL의 활용성에 중점을 두었고 차분히 대체 방안에 대한 작업을 시작했습니다.


 데이터베이스 업계에서는 스케일아웃 분산쿼리 실행 엔진의 구축에 관해 수십 년의 경험이 있습니다. 이는 학술 및 상용 연구가 활발한 분야입니다. 매우 우수하고 빠른 분산 SQL 시스템이 다수 존재 하지만, 그 중 어느 것도 MapReduce형 아키텍처를 사용하지 않습니다.

 

 여기서 저희는 Hadoop 아키텍처를 처음 만들어 낸 Google에 눈을 돌렸습니다. Google은 빅데이터로의 SQL 액세스를 얻기 위해, MapReduce 를 기반으로 하지 않는 독자적인 새로운 분산 쿼리 실행 엔진을 개발하고 있었습니다.


 저희는 모든 선택지를 깊이 생각한 후, Google과 완전 똑같은 일을 해보기로 선택했습니다.  성능에 대해서는 낙관적이었기 때문에 Impala라고 명명했습니다.


 동시에 프로젝트 리더로 Marcel Kornacker를 고용했습니다. Marcel은 한 때 Google에서 일한 적이 있었고, 또 1990년대에 캘리포니아 대학 버클리 캠퍼스 대학원에서 데이터베이스 시스템에 대한 연구를 했던 인물입니다. Marcel은 분산 시스템 및 데이터베이스 커널에 관해 숙련된 엔지니어 팀을 편성하여 개발에 착수했습니다.


 Cloudera 클러스터 내의 모든 노드에는 Impala 코드가 들어가 있어 SQL 쿼리가 실행 되는 것을 기다립니다. 그 코드는 각 노드 상에서 바로 MapReduce 엔진과 함께 - 그리고 Apache HBase 엔진 (MapReduce 를 기반으로 하지 않는), 검색엔진 (MapReduce를 기반으로 하지 않는) 및 고객이 선택해서 디플로이(deploy) 할 수 있는 SAS 및 Apache Spark 와 같은 서드파티 제품 엔진과 함께 동작합니다. 이들 엔진은 모두 완전 동일한 데이터로 접근 가능하며, 유저는 해결하려는 문제에 따라, 그 중 어떤 것을 사용할지 선택 할 수 있습니다.


 Impala는 SQL 쿼리를 오늘날 Hive가 의존하고 있는 map/shuffle/reduce 등의 다른 처리 플레임워크로 번역할 필요가 없습니다. 이 때문에 Impala는 그들 단계에서 받는 레이턴시의 영향을 받지 않습니다. Impala 쿼리는 바로 결과를 돌려줍니다. Impala는 MapReduce와 같은 범용 분산 처리 시스템과는 달라, SQL 쿼리 실행에 관해서 처음부터 설계 되어 있기 때문에 그 특정 워크로드에 대해서는 굉장히 우수한 성능을 제공할 수가 있는 것입니다.

 

왜 Hive를 개선하지 않는가?

 

 

 단도직입적으로 말해, Hive는 리얼타임 분산 SQL 처리에 있어서는 틀린 아키텍처이기 때문에 저희는 Impala 개발을 선택했습니다. 병렬 SQL 데이터베이스 업계는 포화 상태입니다. 어느 전통적인 관계형 데이터베이스 벤더도 (즉 IBM, Oracle, Microsoft, ParAccel, Greenplum, Teradata, Netezza, Vertica) MapReduce와 같은 것은 사용하지 않습니다.

 

 shared nothing 으로 스케일 아웃 하는 시스템의 차세대 (지명도가 높은 것은 Google의 F1 이지만, 이 외에도 그렇게 알려지지는 않은 NuoDB 등의 선택지도 있습니다) 는 모두 MapReduce 기반이 아닌 네이티브 분산 쿼리 실행에 의존하고 있습니다.

 

 

 Facebook은 초기에 MapReduce 상에 Hive를 구축했지만, 그건 Hadoop SQL 로 최단의 길이었기 때문입니다. 시간 요건을 전제로 했을 때에 현명한 결단이었죠. 하지만 이 회사는 최근 SQL 을 통한 데이터로의 리얼 타임 접근을 위한 차세대 쿼리 실행 엔진인 Presto 를 발표 했습니다. Presto는 Impala와 같이 분산 쿼리 실행 엔진으로써 새로 처음부터 구축 되었습니다.

 

 

 Hive를 개선, MapReduce 튜닝 외 고속화 및 레이턴시 단축은 확실히 가능합니다. 하지만 Hive는 설계상 항상 오버헤드가 존재합니다. 또 네이티브 분산 SQL 엔진으로써 구축된 후속 시스템이 회피하는, 성능에 불리한 조건이 발생합니다.

 

 

 Hive를 잘 실행하기 위해 MapReduce를 튜닝 하는 것은 잘못된 일입니다. MapReduce는 범용 배치 처리 워크로드에 뛰어나며, MapReduce를 특정 쿼리 워크로드로 특수화 하는 대책은 SQL을 쓰지 않는 유저에게 있어 부담을 더하는 일이 될 수 있습니다. 초기에는 단일 엔진이 Hadoop상에서 모든 작업을 실행한다는 생각은 의미가 있었습니다. 오늘날에는 (Hbase, Apache Accumulo, Search, Myrrix, Spark 그 외의) 전용 엔진이 급증하고 있습니다. 이것은 대체로 각 엔진이 특별히 튜닝 되어 있는 다른 워크로드를 희생 시키는 일 없이 플랫폼 기능을 확장합니다.

 

Impala 커뮤니티

 

 Cloudera에서는 2012년 후반 Apache 소프트웨어 라이센스에서 발표하기 전까지 거의 2년간 Impala에 몰두 해 왔습니다. 저희가 그렇게 한 것은 Hadoop 상에서의 리얼 타임 SQL이 중요한 문제라고 생각 했기 때문입니다. 그리고 저희는 실제로 제품을 전달 할 수 있기 전까진 저희의 의도를 나타내고 싶지 않았습니다. 저희 회사에는 Impala 개발에 전념하는 중요한 팀이 있습니다.


 Hive는 리얼타임 SQL용의 최신 분산 쿼리 엔진과 성능 면에서 경쟁할 수는 없습니다. 하지만 Hive 에코시스템에는 MapReduce에 의존하지 않는 구성요소가 있습니다. 저희 회사는 그것들을 Impala와 통합 하는 일에 전념 해 왔습니다. 그리고 이런 성과로 Hive 기능 강화에 계속 공헌하고 있습니다.

 


 예를 들면 메타데이터 레파지토리로써 HCatalog나 Hive 메타스토어 커뮤니티와 협력하고 있습니다. 다수의 다른 엔진 간에서 데이터를 공유하는 것은 그것을 기술하는 메타데이터 공유를 필요로 하며, HCatalog는 저희 회사의 엔터프라이즈 데이터 허브 전략의 핵심 부분을 이룹니다. 저희 회사에 따른 Hive 메타스토어나 HCatalog의 이용은 Hive, Impala, MapReduce, Pig 및 REST의 각 어플리케이션이 테이블을 공유 할 수 있는 것을 의미합니다.


 Twitter 사, Cloudera 및 Criteo 사는 Impala가 애널리틱스 데이터베이스 워크로드를 훨씬 빠르게 실행 할 수 있도록 하는 Columnar format 인 Parquet(파케이) 로 협력하고 있습니다. 기여하고 있는 사람들은 Parquet 를 Cascading, Pig, Hive 까지와도 통합하려 하고 있습니다.


 데이터베이스 어플리케이션에서 유저 베이스 및 롤 베이스 인가와 접근 제어는 중요합니다. Cloudera는 Impala를 위한 보안 정책을 정의하고 적용하기 위해 Sentry 프로젝트를 만들어 Oracle이나 그 외 벤더와 협력하고 있습니다. Sentry가 없으면 각 Hive 유저는 다른 여러 Hive 유저에 속하는 모든 테이블과 모든 레코드를 참조 해 버릴 수 있게 됩니다. 저희 회사는 Sentry를 Hive 에 통합하기 위한 코드에 기여 해 왔습니다. 하지만 아직 상용 배포에는 포함되어 있지 않습니다.

 

누가 Impala를 제공하는가?

 

 오픈 소스는 엔터프라이즈 유저가 소프트웨어와 서비스의 최고의 조합을 최선의 가격으로 제공하는 기업과 함께 일할 수 있는 것을 의미 하는 것으로 훌륭한 일입니다. 엔터프라이즈 유저는 단일 벤더에게 구애받지 않습니다.


 Impala가 성공하기 위해선 다수의 기업이 제공하고 지원 해야만 합니다.

 


 물론 여러분은 Impala를 Cloudera에서 받을 수 있습니다. Impala는 저희 회사 플랫폼의 중요 핵심이자, 저희 회사 엔터프라이즈 데이터 허브 전략의 중요 부분입니다. Impala는 저희 회사의 재판매업자로부터도 구입 가능합니다. Oracle은 Big Data Appliance에 있어서 Impala를 포함하는 Cloudera의 완전한 엔터프라이즈 데이터 허브 소프트웨어 세트를 제공하고 있습니다. IBM의 Softlayer 자회사 Verizon Business Systems, CenturyLink Savvis, T-Systems 그 외를 포함하는 클라우드 벤더가, 각 회사가 관리하는 클라우드 내에서의 '서비스형 엔터프라이즈 데이터 허브'를 제공하고 있으며 그 안에는 Impala가 포함되어 있습니다.


 Amazon은 Elastic MapReduce 또는 EMR 이라 불리는 독자적인 빅데이터 서비스를 제공하고 있습니다. 마침 지난주 Amazon은 MapReduce 및 HBase와 함께 그 회사의 EMR 제품의 일부로써 포함되는 서드파티 제품 엔진으로 Impala 제공을 발표 했습니다. Amazon의 지지는 저희 회사에겐 정말 멋진 일이었습니다. 이는 저희 회사의 아키텍쳐를 신뢰하고 있다고 여기는 증거이며, 잠재 유저를 새로 얻을 수 있는 일입니다. 마찬가지로 보다 많은 어플리케이션 및 툴 벤더가 Impala와 통합할 것을 의미합니다.


 제 견해로 가장 흥미 깊은 것은 Cloudera의 경쟁 상대가 지금은 고객에게 Impala를 제공하고 있다는 사실입니다. MapR의 고객은 그 회사의 상용 제품으로 Impala를 이용할 수 있습니다.


 5년 이상에 걸쳐 Cloudera는 Hadoop 에코시스템에 있어서 새로운 오픈 소스 코드를 구축하고 서비스하고 있습니다. 저희 회사는 아주 광범위한 프로젝트에 걸쳐 일하고 있는 공헌자와 커미터를 거느리고 있습니다. 저희 회사는 경쟁 상대에게 그 제품의 일부로 거론된 프로젝트 - Apache Flume, Apache Sqoop, Hue, Apache Bigtop - 을 생산 해 왔습니다.


 Impala는 그 리스트에 이어진 새로운 하나의 예에 지나지 않습니다. 또, 저희 회사 오픈 소스 플랫폼과의 관계가 깊고, 진짜라는 증거의 한 측면에 지나지 않습니다. 말로만 그런 것이 아니라, 저희는 초창기 때부터 스스로의 발언에 따라 살아 왔습니다. 여러분이 오늘날 저희 회사의 파트너와 경쟁 상대 양 쪽을 포함하는 8개 이상의 서로 다른 벤더로부터 Impala를 손에 넣을 수 있다는 사실은 저희 회사 오픈 소스 전략을 틀림없이 증명 하고 있습니다.

 

왜 이렇게 많은 SQL 엔진이 있는가?

 

 이 업계를 잘 보세요. 시장에 존재하는 벤더 수와 적어도 같은 수의 Hadoop에서 동작하는 SQL 엔진이 존재하고 있다는 걸 알게 될 겁니다. Cloudera는 Impala를 제공합니다. IBM은 그 회사의 BigSQL 제품을 좋아 하겠죠. Pivotal은 오로지 HAWQ에 커밋하고 있습니다. Hortonworks는 Hive에 충성을 선언 했습니다. 초기 참가자인 Hadapt은 NoSQL 워크로드도 받아 들이는 방향으로 야심을 확대 하였지만, 여전히 Hadoop 플레임워크 상의 SQL을 제공하고 있습니다. 이 외에도 아직 더 있습니다.


 이것은 기존의 관계형 데이터베이스 기업을 수십 년에 걸쳐 내몰아 온 것과 같은 원동력입니다. 모두가 표준 언어 구조를 구현하고 모든 벤더가 성능과 서비스 확대 면에서 경쟁합니다. 시장에는 이들 제품을 뭉개고 단일 제품으로 만들 수 있는 수 보다도 훨씬 많은 수의 기존 제품이 존재 합니다. 솔직히 말해서 너무 많은 액수의 자금을 벌어 들이고 있어 투자 공유를 내모는 것까지는 다다르지 않았습니다.

 


 그렇다고는 해도 좋은 소식이 있습니다. 이들 SQL, JDBC 및 ODBC 엔진에 데이터를 전송하는 어플리케이션은 이식 가능하며, 유저에게 어려운 일이 아닙니다. 저희는 오픈 소스는 기본 원칙이며 Impala가 승리한다고 믿고 있습니다. 그럼에도 언어 표준의 존재에 따라 자사제품과 연계하는 서드파티 제품에 의한 최고의 에코시스템과 결합된 성능 및 순수한 계산 능력, 이 두 관점에서 경쟁을 하지 않을 수 없다고 인식하고 있습니다. 이 경쟁의 원동력은 저희 회사의 고객에게 있어서도, 시장 전체에 있어서도 최선일 것입니다.

 

Pig 와 Hive는 어디로 가는가?

 

 Yahoo!가 작성한 데이터 플로우형 언어인 Pig는 기존 벤더와의 경쟁이 없습니다. 그 언어는 강력하지만 그 유저 기반은 대체가 되는 구현을 제공할 수 있는 대형 벤더의 주목을 모으기에는 너무 작습니다. Pig 쿼리를 실행하는데에 MapReduce 보다 뛰어난 방법은 존재 하겠지만, 그것이 지원하는 워크로드 (거의 대부분은 변환입니다) 를 기본으로 했을 때에 그것은 중요하지 않습니다. 이 소프트웨어는 현행의 형식으로 충분히 좋으며, Pig 커뮤니티는 그 기능을 계속 강화하고 있습니다.


 다른 한 편으로 Hive는 SQL 이고, SQL은 우주에서 가장 사용되고 있는 데이터베이스 언어입니다. 모두가 그것을 알고 있죠. 모두가 Hive가 빨라지는 것을 기대하고 있고 많은 기업이 Hive를 지원하고 있습니다.

 


 따라서, Hive는 확실히 치열한 경쟁 압력 아래에 놓여지게 됩니다. 보다 많은 대형 벤더가 시장에 참가함에 따라 그것은 착실히 악화 되어 갈 겁니다 저희 회사는 Hive 구현이 높은 성능의 대화형 쿼리 및 애널리틱스의 수요에 따라 갈 수 있을 거라고는 생각하지 않습니다. 아무리 엄하게 채찍질을 가한대도 말은 그만큼 빨리 나아갈 수 없습니다. 유저나 툴이나 어플리케이션을 제공하는 벤더는 보다 좋은 제품으로 옮겨 가겠죠.


 Hive는 데이터 처리 job을 잘 다룹니다. 또한 그 목적으로만 Cloudera의 고객이 넓게 사용하고 있습니다. 무엇보다 Hive는 과거 5년간, Cloudera의 상용 제품의 일부가 되어 왔으므로, Hive는 인스톨 하면 그대로 쓸 수 있기 때문에 저희 회사는 계속해서 Hive를 지원 할 것입니다. 특히 Impala와의 중복 영역을 위에 기재한 Hive Sentry 및 Parquet과의 통합의 장으로 만들려고 생각하고 있습니다.


 하지만 저희는 저희 회사의 엔터프라이즈 데이터 허브에 최상급 리얼 타임 오픈 소스 SQL 엔진을 보유할 필요가 있습니다. 데이터 분석, 리얼타임 쿼리 및 높은 성능의 SQL 어플리케이션에 관한 저희 회사의 장래를 향한 확신은 틀림없이 Impala에 있습니다. 물론 편향된 측면이 있었을지 모르지만, 그래도 저희는 Impala는 이미 Hadoop 에코 시스템에서 이용 가능한 SQL 제품으로서는 실로 최고의 제품이 되었다고 확신하고 있습니다. 고객이나 시장에 있어서 다른 기업이 Impala를 도입하는 것은 매우 기쁜 일 입니다. 또 앞으로 몇 몇 릴리즈로 공개될 서비스나 신기능을 기대 해 주시기 바랍니다.


 


 

Posted by 이슈타르네스

[LINE 블로그 번역] ‘캐쥬얼’한 규모의 데이터 클러스터상의 데이터 분석 처리

by just_do_neet on 2012.9.11

원문 출처 : http://tech.naver.jp/blog/?p=2127  - LINE Engineer's Blog

- 본 글은 위 링크의 LINE Engineer's Blog 를 번역 하였습니다.


LINE 서비스의 통계 분석 기반

 

 현재 저는 LINE의 통계 분석 기반 개발을 담당하고 있습니다. 기반자체는 일년도 전부터 운영되고 있으며, 저는 근래 작업으로 최근 1,2개월 정도는 주로 기반 데이터 구조 재검토와 튜닝을 담당하고 있습니다.

 

 LINE의 통계 분석 기반은, 많은 회사에서 이와 같은 시스템은 존재하겠지만, LINE의 로그 데이터나 RDB 데이터 등을 사용하여 주로 KPI에 참고되는 다양한 통계적 수치를 산출하여 표시 해 주는 시스템 입니다. 그 외에 서비스 운용을 위한 보조적인 기능 등도 몇 가지 있습니다.

 

 시스템 아키텍처에 관해, 특히 통계 처리에 관련한 처리 부분을 뽑아보면 아래와 같습니다.

Input

 

  • 유저의 조작 이력 로그

    • Redis Queue에서 취득 (Streaming)

  • 마스터 데이터 (유저 데이터, 스탬프 정보 등)

    • MySQL 에서 (Batch)

Processing 


Output

 

  • 각종 통계 결과

    • MySQL에 보존 (Batch)

 LINE 서비스는 일반적인Web 어플리케이션과는 아키텍처가 다르기 때문에 접속 로그와 같은 것은 존재 하지 않습니다. 그러므로 유저의 조작 이력 로그를 Redis Queue를 통해서 비동기로 취득하여, 그 쪽을 분석 대상으로 삼고 있습니다.
 또한 분석 처리는 주로 쓰는 조합입니다만, Hadoop과 Hive를 사용하고 있습니다.

직면 해 있던 문제
 감사하게도 많은 분들이 LINE 서비스를 사용하고 있습니다. 유저 증가에 비해서 백엔드 분석 기반으로 처리해야만 하는 데이터 사이즈도 크게 증가하고 있습니다.
 예를 들면, 유저 조작 이력 로그는 최근에는 하루에 약 700 GB 정도 사이즈를 차지합니다.

 

 

 이들 로그 데이터와 마스터 데이터를 합쳐서, 날마다 수십 종류 항목의 분석 처리를 실시하고 있습니다.


 이런 상황 때문에, 날마다 실시하는 데이터 분석 처리도 갈수록 시간이 걸리게 되어, 예를 들어 하루 한 번 실시하고 있는 큰 daily batch process는 최대 11시간반 정도의 시간이 걸리게 된 상태였습니다.

 

 

 거기서 이러한 문제를 해결 하기 위해서, 가능한 한 처리를 빨리 끝내도록 하는 분석 처리 튜닝을 실시할 필요가 있었던 것입니다.

 

튜닝에 앞서
 자 튜닝이다! 라고 단단히 마음 먹는 것은 좋습니다만, 실제 상황을 이야기 하자면 저는 팀에 막 합류한 시기로, 시스템에 뭐가 문제고 뭐가 느린건지를 정확히 파악하지 못하고 있었습니다. 이 때문에, 시작점으로서 우선은 정보를 눈으로 바로 확인 할 수 있게 하는 작업을 실행하였습니다.

 기존의 분석 기반에서는, 분석 처리의 거의 전부가 Python으로 쓰여 있어서, Python에서 Hive Thrift Server를 통해 HQL을 날리는 것으로 분석 처리를 실시하고 있었습니다. 물론 처리 로그 같은 건 비교적 제대로 출력, 보존 되고 있었습니다만, 예를 들어 각 분석 처리의 처리 시간이나 발생한 에러 등을 확인 하기 위해서는 서버에 로그인 할 필요가 있었습니다.
 이것들을 한시라도 빨리 눈으로 확인 할 수 있게 하기 위한 수단으로서 Hadoop과 친화성이 높은 워크 플로우 엔진으로 유명한 ‘Azkaban’을 채용하여 그 쪽에서 분석 처리 컨트롤을 행하도록 하였습니다.

 

 

 Azkaban에 대한 자세한 설명에 대해서는 이 글에서는 생략하지만, 본래 목적인 워크 플로우의 제어 이외에도 각각의 처리 실행 시간이 그래프로 가시화 되기 때문에 어느 처리가 느린 것인지를 특정하기가 편리합니다.
 그러므로, 기존의 분석 처리를 모두 Azkaban상에서 컨트롤 하도록 변경 하고, 처리 내용이나 소요된 처리 시간을 가시화 하여, 이것을 시작으로 튜닝 포인트를 찾기로 하였습니다.

 

튜닝 포인트
 처리 속도 상의 문제점으로 나타난 것은 아래와 같습니다.

  • 마스터 데이터 (MySQL)의 Hadoop, Hive 로의 import 처리가 느림

  • MapReduce 태스크의 가동수가 capacity(용량)을 넘고 있음

    • Hadoop 상의 데이터 구조에 문제

    • 애시당초 서버 리소스 부족

 우선, 데이터 import 처리입니다만, 마스터 데이터의 내용을 Hive에 반영하기 위해 정기적으로 데이터 갱신을 하고 있었습니다만, 그 처리가 single process로 동작하도록 되어 있어, 데이터 급증에 따른 처리 시간이 늘어나 있었습니다. 또한, Hadoop Cluster 대수를 늘리는 등의 방식으로 해결되지 않는 조정하기 어려운 구조였기 때문에 개선 작업이 급선무였습니다.


 근본적으로는 서버 증설 밖에는 대책이 없었습니다만, Hadoop 상에 보존되어 있는 데이터 구조에 몇 가지 개선 가능한 포인트가 있었기 때문에 그 부분을 손보았습니다.


Import 처리의 개선 (Sqoop)
 데이터 import에 대해서는Sqoop이라는 OSS를 채용 하였습니다.
 Sqoop은 현재는 Apache의 Top-Level Project 로서 개발이 진행되고 있는 OSS로, 주로 RDB와 Hadoop, Hive 간에 효율적으로 데이터 import, export를 실행하기 위한 툴입니다.
 기본적인 구조에 관한 그림은 Cloudera 블로그에서 인용하였습니다.

 

(출처 : http://www.cloudera.com/blog/2012/01/apache-sqoop-highlights-of-sqoop-2/

 Sqoop은 기본적으로 커맨드라인으로 동작하는 툴입니다. 몇 가지 옵션을 지정하면 꽤 괜찮게 RDB와 Hadoop, Hive 간의 import, export 처리를 해 줍니다.
 (참고 : Sqoop의 import 커맨드 옵션 일람)


 Sqoop에서 import 처리를 실행하면, MapReduce 의 Job (정확히는 Map Only) 이 기동하여, Map Task 중에 설정 내용에 따라 원래 데이터를 가지는 데이터베이스에 접속하여 dump를 하고, 그 결과를 직접 HDFS에 써넣는 방식으로 작동합니다.

 

 

(출처 : https://blogs.apache.org/sqoop/entry/apache_sqoop_overview
Import 처리 효율화 관점에서 말하자면, 아래 2가지가 고속화에 기여하고 있습니다.

  • 병렬적 import 처리가 가능

  • dump한 데이터를 직접 HDFS에 써넣을 수 있음

 Hadoop을 사용하여 비교적 간단히 병렬 import가 가능한 것도 편리하구요. 이러한 import 처리를 자신의 스크립트에 써두면 우선 로컬 파일상의 dump를 보존하여 이를 HDFS에 put하는 여러 단계의 처리를 거치는 경우가 많아, 특히 HDFS로 큰 파일을 put 하는 것은 아무래도 시간이 걸리는 작업이기 때문에 이러한 부분에서 시간을 절약합니다.
 그런 의미로, Hadoop이나 Hive에서 사용하는 데이터 import에는 Sqoop은 비교적 적합하다고 생각합니다.

튜닝 결과 (Sqoop)
 이번 Sqoop 도입에 의해 처리가 2시간 정도 고속화 되었습니다.

 

 

데이터 구조 개선
 이어서 데이터 구조 개선입니다.

 

 

 LINE의 통계 분석 기반에서는 Hive Table에서 다루는 데이터는 기본적으로는 TextFile 형식으로 보존되고 있었습니다. 물론 Text 형식인 편이 운용면에서는 여러가지 편리한 면도 있고, 이전에는 이걸로 성능적인 문제는 없었습니다만, 이 정도로 데이터가 커지고 나니 좀 더 효율적인 데이터 형식으로 변경할 필요가 있었습니다.
 또한, 다루는 데이터가 크기 때문에 데이터 압축에 대해서도 신경 쓸 필요가 있었습니다.
 이 외에도 데이터에 따라서는 한 파일 당 사이즈가 너무 작은 (HDFS의 한 블록 사이즈 보다도 극단적으로 작은) 것이 존재하고 있어 퍼포먼스에 악영향을 주고 있었습니다.

 이러한 몇가지 점을 착실히 개선 해 보았습니다.

 

TextFile->RCFile로의 마이그레이션
 우선은 Hive 처리에 적합하면서 또한, 데이터 사이즈를 가능한 한 작게 할 수 있는 파일 포맷을 선정합니다. 여러가지로 조사한 결과, 이번 케이스에서는 RCFile이라는 데이터 형식을 채용하는 것이 좋지 않을까 라는 결론이 나왔습니다.
 RCFile은 Hadoop (HDFS) 상에서, 예를 들어 Hive와 같이 구조적인 데이터를 다룰 때에 적합한 파일 포맷입니다. 자세한 내용은 아래 논문을 참조 바랍니다.

RCFile: A Fast and Space-efficient Data Placement Structure in MapReduce-based Warehouse Systems (ICDE’11)

 

 

 특히 개인적으로 좋았던건, 데이터 사이즈를 가능한 한 작게 만들기 위한 고민이 여기저기 녹아 있는 점입니다. 메타데이터의 run length 부호화도 그렇고, 동일한 컬럼 단위로 데이터가 보존되어 있기 때문에 연속해서 같은 경향의 데이터가 출현할 확률이 높아, 압축 알고리즘에 따른 압축을 쉽게 할 수 있습니다.
  실제로 다른 데이터 형식 (TextFile, SequenceFile) 과 비교해도, RCFile이 데이터 사이즈면에서는 가장 우수 했습니다. 아래는 완전 동일한 데이터군을 각각의 파일 형식으로 '압축하지 않은 것'과 '압축 상태인 것'으로 저장하여 어느 정도 사이즈 차이가 나는지를 비교한 것입니다.

 

 

 

 기존의 데이터 중에는 TextFile이면서 압축하지 않은 상태로 저장되어 있는 것도 있었기 때문에, 이번에는 Hive Table의 데이터는 전부 'RCFile + GZIP' 형식으로 저장하도록 변경 했습니다.

※ 실제로는 아직 일부 마이그레이션 중입니다.

 

너무 자잘한 파일의 merge
 Hadoop HDFS 상에서는 블럭 사이즈보다도 극단적으로 작은 파일이 많이 있으면 별로 효율적으로 처리를 하지 못합니다. 이 부분은 매우 유명한 이야기로, Cloudera의 'The Small Files Problem' 이란 블로그 기사가 매우 쉽게 쓰여 있어 참고 할 만 합니다. 


 자잘한 파일의 merge는 일반적으로는 HAR를 사용하는 경우가 많은 것 같습니다만, 이번에는 Hive merge와 관련된 옵션을 사용했습니다.

 

 

 'hive.merge.mapfiles', 'hive.merge.mapredfiles' 로 출력 파일의 merge 처리 on/off 설정을 합니다. 사이즈 조정은 'hive.merge.size.per.task', 'hive.merge.smallfiles.avgsize' 에서 처리 합니다. 이것들을 조합하여, 블록을 유효하게 쓸 수 있는 사이즈로 조정해서 파일을 출력할 수 있습니다.

 아래는 약간 실무와는 좀 별개의 수치이긴 합니다만, 실제 merge 전후에 어느 정도의 처리시간 차이가 나는지, count 문과 select 문 (where hoge=xxx)를 발행 해 본 비교 결과 입니다.

 

 

튜닝 결과 (데이터 구조 변경)
 이번에 측정한 시점에서는 모든 데이터 마이그레이션 아직 끝나지 않았기에 효과는 어중간 했지만, 그래도 1시간 정도 처리 속도가 개선 되었기 때문에, 위에서 얘기한 수법은 튜닝 방향으로서는 틀리지 않았다고 생각합니다.

 

 

서버 증설
 자, 주저리주저리 길게 썼는데요. 튜닝 작업에는 한계가 있어, 마지막에는 서버 증설 (돈)에 의지해야만 하는 경우도 있습니다.
 이번 같은 경우에도 본질적으로는 그런 상황이었기 때문에, 기존의 Hadoop Cluster의 DataNode/TaskTracker 대수를 2배로 늘렸습니다.

 

 

 

 단번에 6시간이나 단축...
 어쨌든 뭐랄까, 최종적으로는 돈이 중요하다는 현실에 직면하게 되었네요.

 실제로 데이터 구조 튜닝에 의해 잠재적으로 처리는 효율화 되었지만, 그래도 아직 남아있었던 용량 부족 문제는 서버 증설 작업으로 해결되었습니다. 아무것도 하지 않았던 때보다 처리속도 개선 효과가 컸다고 생각합니다.

 

정리
 어쨌든지 간에 다양한 수단을 구사하여 분석 시간을 9시간 정도 단축 할 수 있었습니다.

 

 

 마지막으로, 이번 튜닝 과정 중 느낀 점을 정리하는 측면에서 적고 이 글을 마치고자 합니다.

 

 

 

 이상으로, '캐쥬얼'한 규모의 데이터 클러스터에서의 분석 처리 튜닝 과정에 대해 적어 보았습니다.
 이 블로그 내용이 여러분에게 조금이라도 도움이 된다면 기쁠 것입니다.


Appendix.
 통계분석 기반에서 현재 다루고 있는 데이터는 기껏해야 PB 클래스의 '캐쥬얼'한 사이즈의 데이터입니다만, 이후 데이터 사이즈 증가를 고려 했을 땐 현재 상황 보다 효율적인 데이터 구조를 검토할 필요가 있습니다.
 또한, 현재는 거의 Daily 혹은 Hourly 분석이 중심이지만, 좀 더 빠른 데이터 분석을 하고 리얼타임에 가까운 형태로 분석 결과를 표시하는 구조도 필요하게 될겁니다.

 

 데이터 구조에 대해서는, 현재 개인적으로 관심을 가지고 있는 것이 'CIF(ColumnInputFormat)' 이라 불리는 것입니다. 데이터 로컬리티에 신경을 써서 같은 데이터 스키마를 동일한 DataNode로 나눠 할당하는 방법이나, 시리얼라이즈(serialize)나 데이터 압축 등을 고안해서 처리 고속화를 실현하는 수법이라 합니다. 
 아직 실제로 실험 해 보지는 않았지만, 논문 베이스로는 데이터를 읽어 들이는 속도가 RCFile보다 38배 빠르다고 합니다.
Column-Oriented Storage Techniques for MapReduce(VLDB ’11)
Sandeep’s Research Notes: RCFile and CIF


 또, 실 서비스 예로는, Treasure Data 에서는 내부 데이터 구조에 MessagePack을 이용하여 높은 압축률을 실현하고 있다고 합니다.
Five Criteria of Next Generation Data Warehouse | Treasure Data Blog

 Check. We achieve a 5-10x compression ratio. Columnar data storage helps with compression considerably, but our secret sauce is a binary serializer called MessagePack. MessagePack is space-efficient and incredibly fast to serialize and deserialize. One of our co-founders is the original author of MessagePack, and we use it extensively throughout our stack.

 

 이런 실사례를 참고하면서, 보다 효율적인 데이터 구조 채용을 검토 해 나가고 싶습니다.

 데이터의 준 리얼타임 분석에 관해서는 이른바 Streaming Processing의 개념과 이를 실현할 미들웨어 필요 해 집니다.
 가장 유명한 것으로는 Twitter 회사가 도입하고 있다는 'Storm' 일까요.
 또, 로그 콜렉터로 유명한 'Fluentd' 에관해서도, Aggregation을 실행하는 플러그인 등도 있고, 생각하기에 따라 Streaming Processing이 가능 해 질 거라 생각합니다.

 이것들도 여러가지로 실험 해 보고 싶습니다.


 잘나가는 서비스의 뒷면에는, 잘나가는 데이터 분석 기반이 존재한다는 것이 통설(?)이기에, 저희들도 가능한 그 경지에 가까이 다가갈 수 있도록 노력 해 나가고자 합니다.

 

 

 

Posted by 이슈타르네스