2020년 Databricks는 C++ 기반 SQL 실행 엔진 Photon을 공개했습니다.먼저 Databricks는 왜 C++ 기반 실행 엔진을 만들었고, 왜 C++이어야만 하는지 간단히 설명합니다.Spark SQL을 사용하기 위해 사용자가 입력한 쿼리는 다음의 단계를 거쳐 Code Gen이 되어 byte code로 변환되고, 각 executor에서 실행됩니다.JVM으로 실행하는 Spark Executor는 아무리 잘 포장해도 Java가 C++/Rust 등에 비해 부족한 약점을 보완하기 어렵습니다.가장 대표적인 부분 몇 가지만 나열하면 다음과 같습니다.• None 메모리 제어의 유연성 부족으로 인한 최대 성능 제약• None 네이티브 SIMD 지원 부족으로 최신 장비의 성능 극대화 방안 부족• None SIMD를 위한 표준 라이브러리 부족과 JNI를 통해서만 호출할 수 있는 SIMD 사용 복잡성• None SIMD 명령을 실행하기 위한 자동 벡터화(비록 최신 SDK에서 Vector API 등을 지원하지만 JVM을 통한 실행으로 성능과 확장성 제약) 불가능주요 약점들이 대규모 병렬 서비스 개발에는 치명적인 제약으로 다가올 수 있습니다.JIT 컴파일러 기반의 Vector화된 코드는 C++ 컴파일러가 제공하는 수준의 정교한 최적화가 어렵기 때문에여전히 고성능 서비스 개발에서 JVM 기반 언어는 C++과 Rust와의 경쟁이 어렵습니다.Spark SQL을 실행하는 구조에서 어떤 부분을 고성능 모듈로 바꾸면 좋을지 생각해볼 수 있습니다.Spark Catalyst Optimizer에서 완성된 code gen 바이트 코드를 Spark Executor에 전달하는 과정까지는 C++, Java무엇으로 개발하든 성능 차이가 안 나는 영역입니다.빅데이터에 대한 병렬처리의 장점을 극대화할 수 있는 구간이 아니기 때문이죠.SQL을 Parsing하고 실행계획을 만드는건 단일 노드에서도 얼마든지 빠르게 처리할 수 있고, 이는 java application이 C++ 보다 경쟁 우위에 있을 수 있는 분명한 영역입니다.하지만 완성된 code gen이 실행되는 병렬 컴퓨팅 영역은 C++이 압도적인 성능 우위를 얻어낼 수 있는 구간입니다.그래서 Spark Executor에서 실행을 담당하는 엔진을 C++로 새롭게 개발한 서비스가 Databricks Photon Engine입니다.Photon 엔진은 위에서 언급한 JVM 기반 Spark Executor가 가진 단점을 모두 해결해줍니다.• None Native SIMD 명령어 처리를 통한 대규모 데이터 세트의 처리 속도 향상• None 최신 HW 최적화를 지원하여 CPU와 메모리 활용도 획기적인 증가• None 벡터화된 쿼리 처리와 메모리 사용으로 쿼리 성능 압도적인 개선• None HW 가속의 확장성으로 특정 연산을 더욱 빠르게 튜닝• None 기존 Spark API와의 호환성 부여로 기존 Spark SQL의 수정없이 그대로 사용Spark 환경의 성능적인 약점을 모두 해결하면서 기존 사용자들의 Spark SQL을 그대로 사용할 수 있게 해준 획기적인 개발이었습니다.Photon 엔진으로 인해 Databricks의 플랫폼은 Apache Spark와는 확실한 차별점을 부여할 수 있었고, 강력한 무기가 되었습니다.보통 선구자가 이렇게 좋은 기술을 개발하면 그 동네에 있는 누군가는 비슷하거나 더 좋은 기술을 만드는게 IT 바닥의 흐름 같습니다.Databricks와 같은 동네에 살고 있는 IT업계의 큰 형님 중 한 명인 Meta는 Data Platform 관련 기술에 진심인 회사 중 하나입니다.요즘은 G.AI가 모든 이슈를 가리고 있지만 Meta는 빅데이터 처리와 관련된 다양한 open source를 개발하고 공유하는 큰 열정을 보여주고 있습니다.요즘은 llama를 주로 얘기하지만 React, PyTorch, Presto(현 PrestoDB), GraphQL 등 훌륭한 open source 포트폴리오를 가지고 있고 지속적인 지원을 하고 있습니다.Meta도 유례없는 큰 데이터를 처리하는 회사이고, 핵심 분석 플랫폼의 고성능화에도 많은 투자를 하고 있습니다.Meta의 핵심 쿼리 엔진인 Presto는 Java로 구현되어 있습니다.Java는 사용하기 편하고, 웹기반 서비스 개발에도 좋지만, 결국 위에서 언급한 JVM 기반 Spark의 약점을 그대로 가지고 있습니다.Presto나 Trino는 C++ 기반 MPP엔진에 비교했을 때 동시성, CPU 사용률, 병렬처리 등 Spark와 유사한 단점을 보유하고 있습니다.Meta는 이를 해결하기 위해 전체 아키텍처 관점에서 해결책을 사용했었습니다.여러 개의 Presto 클러스터를 구축하고, 가장 앞단에 Gateway를 배치하여 다양한 라우팅 전략을 부여하여 안정적인 빅데이터 서비스를 만들고자 했습니다.Scale Out 구조가 좋아도 하나의 노드에서 처리하는 최대 성능이 모여서 전체 클러스터 성능을 결정하기 때문에Meta도 Presto의 분산 처리 영역을 C++ 기반의 엔진으로 바꾸는 Open Source를 개발합니다.Velox는 C++기반 실행 엔진이기 때문에 C++이 가진 경쟁우위 요소를 그대로 상속받습니다.Presto의 실행 엔진 영역을 C++ 기반 고성능으로 개선, 벡터 처리 모델을 사용하여 SIMD 극대화와 메모리 최적화,이로인한 데이터 접근 시간 단축, 컴파일된 표현식 사용으로 런타임 오버헤드 감소를 달성할 수 있습니다.Databricks Photon이라는 선례가 있기 때문에 Velox 개발자들은 Photon 대비 더 나은 경쟁력을 가질 수 있는 설계를 합니다.더욱더 광범위한 벡터화된 처리와 SIMD 명령어 활용과 최적화, 다양한 데이터 형식을 유연하게 지원하여 Spark나 Presto 전용 실행 엔진이 아닌 다양한 서비스에 적용할 수 있는 확장성을 가집니다.이는 플러그인 아키텍처를 적용한 구조에서도 극명하게 들어납니다. 그리고 Open Source 생태계와의 통합으로 더 많은 프로젝트에서의 활용이 가능합니다.Velox를 사용하여 Presto용 실행엔진을 플러그인 형식으로 확장했습니다.PrestoDB와 C++ 실행엔진의 조합은 Ap

우리는 여러 가지 이유로, 여러 가지 용도에 사용하기 위해 데이터를 조회합니다. 많은 경우 SQL기반의 데이터 처리 엔진에 SQL 을 사용해서 데이터를 조회하게 됩니다. 이 때, 기본적으로 문법에 맞춰서 데이터를 조회하면 데이터가 잘못 나올 일은 극히 드뭅니다. 하지만 간혹 생각과 다른 데이터가 나온다거나, 잘 돌아가는 지를 확인하고 싶은데 쿼리가 무거울 것 같아서 무조건 돌려보기 애매하다거나, 별 것 아닌 쿼리라고 생각했는데 데이터 조회가 오래 걸리거나 하는 일이 발생합니다. 정말 어쩔 수 없는 경우도 있지만, 상당수의 경우는 쿼리를 좀 더 예쁘게 짜면 전반적인 쿼리 성능을 높일 수 있습니다. 이를 위한 작업을 흔히 쿼리 튜닝이라고 합니다. 쿼리 튜닝하는 법 이런 쿼리 튜닝을 위해 우선적으로 선행되어야 할 작업은 쿼리가 어떻게 실행되는 지를 아는 것입니다. 대부분의 SQL처리 엔진에서는 SQL 문장을 받으면 이를 어떤 식으로 수행할 지에 대한 계획을 세우는데, 이를 쿼리 실행 계획(Query Plan) 이라고 합니다. 그리고 대부분의 SQL처리 엔진에서는 이런 쿼리 실행 계획을 확인할 수 있습니다. 이를 확인할 때는 일반적으로 원하는 쿼리 문 앞에 EXPLAIN을 사용해서 다음과 같은 방식으로 나타냅니다. EXPLAIN query_statement 그리고 이 EXPLAIN을 사용하는 방식은 Presto(프레스토)에서도 동일하게 사용 가능합니다. 하지만 프레스토의 경우 다양한 데이터 소스 위에서 동작하는 분산 처리 SQL엔진이므로 다른 데이터베이스에서의 실행 계획과 다소 다릅니다. 사내에서 데이터에 접근할 때는 대부분 제플린에서 프레스토에 연결해서 사용하므로, 프레스토의 쿼리 실행 계획을 이해할 줄 알면 데이터를 조회하는 데에 큰 도움이 됩니다. 하지만 GUI가 잘 되어 있는 SQL 클라이언트에 익숙해진 사람들이 보기에는 그다지 보기 좋지 않습니다(). 또한 예전에 CLI로 SQL을 사용하던 사람들에게는 용어가 그다지 익숙하지 않아서 역시나 그다지 보기 좋지 않습니다. (예는 사내에서 사용하는 제플린+프레스토 에서의 실제 실행 결과로, 테이블 이름은 숨겼습니다.) 하지만 최소한 계단 형태라도 나오는 게 어디인가 싶습니다(). 그리고 천천히 뜯어보면 그다지 어렵지 않습니다. 특히, 프레스토의 최소한의 실행 구조와 용어를 알고 뜯어보면 DB 실행 계획 만큼 쉽습니다. 프레스토의 쿼리 실행 형태는 기본적으로 다음과 같습니다. ANSI-SQL로 작성된 프레스토에서 실행 가능한 쿼리 문을 받습니다. 프레스토 워커에서 실행할 수 있는 쿼리 형태로 내부적으로 변환합니다. 실행 단계별로 나눕니다. 각 단계마다 분할해서 수행 가능한 업무 단위로 할 일을 쪼갭니다. 각 일은 입력 데이터와 출력 데이터가 존재하는 블랙박스 형태로 만들어져서 fragment(프레스토의 단일 노드 혹은 여러 노드로 만들어진 일하는 단위. 각 부분/각각의 곳 정도로 나타냈다)에서 실행됩니다. 부분 간에 필요시 데이터를 교환할 수 있는 연결고리를 구성합니다. 위의 내용을 기억해

빅데이터 분석을 위한 인프라 구축에 대한 경험을 공유하고자 합니다. 최근 데이터 분석을 위한 데이터 처리 시간의 증가로 기존 데이터 처리방법의 한계를 경험하였습니다. 결국 빅데이터 프레임워크를 검토하고 최종적으로 기술을 선정하 여 도입하게 되었습니다. 이 과정에서의 경험이 비슷한 고민을 하는 사람들에게도 도움이 될 것으로 여겨 글을 작성하고 공유하게 되었습니다. 많은 회사에서 그렇듯이 데이터를 기반으로 현재 서비스의 현황을 정확하게 파악하고 합리적인 의사결정을 할 수 있도록 여러 지표를 만들고 이를 정기적으로 모니터링 합니다. 때에 따라서는 가설을 세우고 이를 확인하기 위해 데이터를 이용하여 분석을 합니다. 가설을 세우고 데이터를 만들어 분석하는 전담 부서를 두기도 하지만 업무에 대한 지식과 관련 데이터는 업무 담당자가 가장 잘 알 수 있는 부분이므로 데이터를 분석하는 것은 모두에게 필요한 부분이라 생각합니 다. 하지만 전체 데이터의 구조나 관련 기술이 부족한 업무 담당자가 분석을 위한 데이터를 처음부터 찾아서 보는 것은 매우 어려운 작업입니다. 저는 이러한 사람들이 좀 더 쉽게 데이터를 통해 원하는 분석 결과를 얻을 수 있도록 데이터 추출과 분석을 지원하는 업무를 하고 있습니다. 사내에서는 이를 ‘Data Intelligence’라고 부르고 있으며, 타 팀에서 데이터를 효과적으로 분석 할 수 있도록 저장된 데이터를 가공하여 추출하며, 경우에 따라서는 데이터를 수집하는 업무를 하고 있습니다. 무엇이 문제인가? 데이터 사이즈의 크기가 늘어나면서 더 높은 처리 속도가 필요하였고, API 로그 등의 데이터를 DB 데이터와 연동해서 봐야하는 Needs가 증가했습니다. 데이터 추출 작업을 생각해보면, 데이터가 DB 테이블에 저장 되었을 경우 간단히 SQL 쿼리를 통해 원하는 데이터를 찾을 수 있습니다. 이 경우 데이터 기준을 요청자와 논의하면서 적절한 쿼리를 작성 후 엑셀로 추출하여 요청자에게 전달 하게 됩니다. 이때 데이터 조회 속도가 너무 오래 걸린다면 날짜와 같은 키로 쿼리로 나누어서 조회하기도 하고 인덱스 등을 조정하기도 합니다. 만약 데이터 추출이 쿼리로 불가능하거나 처리 속도를 높일 필요가 있을 경우 Python, Java 등의 언어로 프로그램을 만들어 추출하기도 합니다. 때에 따라서는 중복된 데이터 처리를 피하기 위해 중간 과정의 데이터를 만들어 활용하기도 하며, 서버 사양을 높이거나 병렬 처리를 통해 최종 데이터 생성의 속도를 높이는 시도를 하기도 합니다. 많은 노력에도 불구하고 어떤 데이터의 경우는 이틀 이상 소요되는 경우가 많아 졌습니다. 또한 API로그를 통해서만 볼 수 있는 분석에 대한 요청도 있었습니다. 앱에서 버그가 발생하여 동일 API가 여러 번 호출 되는 경우가 있었는데 이 버그의 영향이 어느 정도 영향을 미쳤는지 파악하기 위해 API 로그를 살펴보아야 했습니다. 이러한 케이스의 로그 데이터 분석은 ELK, AWS Cloud Watch에서는 살펴보기에는 어려움이 있었습니다. 이러한 과거 데이터 처리, 추출

클라우드Martin Heller이 글은 IDG의 아티클을 전재하여 제공합니다.[원문보기] : https://www.itworld.co.kr/insider/엔터프라이즈 데이터 웨어하우스(EDW)는 전사적으로 모든 역사적 데이터를 저장하는 통합 데이터베이스로 분석에 최적화돼 있다. 최근, 데이터 웨어하우스를 구축하는 기업은 온프레미스보다 클라우드에 데이터 웨어하우스를 구축하는 경우가 많다. 또한, 전통적인 데이터 웨어하우스 대신 쿼리를 지원하는 데이터 레이크를 활용한다. 이밖에 역사적 데이터와 스트리밍 라이브 데이터의 결합 여부도 EDW 프로젝트에서 중요한 결정 사항이다.ⓒ Getty Images Bank데이터 웨어하우스(Data warehouse)는 일반적으로 역사적 데이터를 저장하기 위해 2개 이상의 데이터 소스로 만든 분석(관계형) 데이터베이스다. 페타바이트급까지 크기가 커지기도 한다. 데이터 웨어하우스는 복잡한 쿼리를 실행시키고 보고서를 생성하는 상당한 컴퓨팅 및 메모리 리소스를 갖춘 경우가 많으며, 종종 비즈니스 인텔리전스(BI) 시스템과 머신러닝의 데이터 소스 기능을 한다.트랜잭션 운영 데이터베이스의 쓰기 처리량 요건은 생성할 수 있는 인덱스의 종류와 수를 제한한다(인덱스가 많을 수록 추가되는 레코드당 쓰기와 업데이트가 많아지며 경합이 증가할 수 있음). 이로 인해 운영 데이터베이스에 대한 분석 쿼리가 느려진다. 데이터를 데이터 웨어하우스로 내보낸 후, 별개 OLTP(Online Transaction Processing) 데이터베이스의 쓰기 성능에 영향을 주지 않고 상당히 좋은 분석 쿼리 성능으로 데이터 웨어하우스에서 필요한 모든 것을 인덱스 처리할 수 있다.데이터 마트에는 특정 비즈니스 라인을 대상으로 한 데이터가 포함돼 있다. 데이터 마트는 데이터 웨어하우스에 종속적일 수도, (운영 데이터베이스나 외부 소스에서 가져오는 형태로) 독립적일 수도 있다. 또는 둘이 혼합될 수도 있다.자체 형식으로 데이터 파일을 저장하는 데이터 레이크는 ‘읽기 스키마(Schema on read)’다. 레이크에서 데이터를 읽는 애플리케이션은 데이터에 독자적인 유형과 관계를 적용해야 한다는 의미이다. 반면 전통적인 데이터 웨어하우스는 ‘쓰기 스키마(Schema on write)’다. 데이터 유형과 인덱스, 관계가 데이터 웨어하우스에 저장된 대로 데이터에 적용된다.현대적인 데이터 웨어하우스는 구조화된 데이터, 반구조화 된 데이터를 처리하고 동시에 쿼리할 수 있는 경우가 많다. 또한, 역사적 데이터와 스트리밍 된 최근 데이터를 동시에 쿼리할 수 있다.클라우드 데이터 웨어하우스 vs. 온프레미스 데이터 웨어하우스기업은 온프레미스, 클라우드, 또는 하이브리드로 데이터 웨어하우스를 구현할 수 있다. 과거 데이터 웨어하우스는 항상 온프레미스였다. 그러나 온프레미스 서버의 확장성 부족과 자본 비용이 문제가 되자, 관련 업체가 데이터 웨어하우스 어플라이언스를 제공하기 시작하면서 온프레미스 EDW 도입이 늘어났다. 다시 지금은 데이터 웨어하우스의 일부나 전부를 클라우드