2022년 1월 25일 화요일

Multi-datasource를 위한 SQL Engine

클라우드 트렌드, 그리고 데이터의 시대로 인해 데이터베이스 측면에서 가장 많이 변한 것은 더 이상 하나의 큰 DBMS를 사용하는 일이 대세가 아니라는 것이다. 클라우드 측면에서는 MSA(Microservice Architecture)를 이야기를 한지 상당한 시간이 흘렀으나, 데이터에 관련되어서는 이제사 Data Mesh1 등의 이야기가 나오고 있는 형국이다.

[Netflix의 Cloud 여정 (출처: Pivotal)]

여기에 Data Science 트렌드까지 등장하여 데이터 플랫폼이 갖추어야 할 요건들이 많아지고 복잡해진 상황에서, 쉽게 정의할 수 있는 이상적인 아키텍처는 당장 등장하지 않을 것으로 보인다. (사실, 등장하지 않을 가능성도 상당히 높다고 본다.) 다만, 그 과정의 일환으로, 다수의 DBMS에 존재하는 데이터를 동시에 보고 싶은 Data Federation에 대한 관심은 상당히 높은 상황이다.

[BI Tool의 Data Federation (출처: Tableau)]

기존에 다수의 DBMS에 대한 동시 분석은 BI/OLAP 툴의 영역이었다. 전통적인 MSTR, Power BI 부터 최근의 Tableau, Qilk 등 많은 기술이 여기에 포진해 있다. 특히 BI/OLAP 툴들은 현업 파트에서 SQL을 모르거나 낮은 SQL의 이해도를 바탕으로 빠르고 쉽게 직관적인 리포트 및 대시보드를 구성하는데 아주 큰 강점이 있다는 점에서, 지속적으로 사랑받는 기술일 것이다. 하지만, 데이터 많아짐에 따라, 시각화나 화면보다는 다수의 위치에 존재하는 여러 데이터 소스의 데이터를 동시에 접근하기 위한 기술에 대한 필요성이 증대되었고, 이 특징을 지원하기 위한 솔루션들이 등장하게 된다.

대표적인 기술이 Presto 이다. Hadoop이 등장하면서 SQLH (SQL on Hadoop)이라는 개념으로 SQL엔진을 데이터베이스와 분리하려는 시도는 2010년 초반부터 있었으나, 여러 데이터베이스를 Source로 범용 SQL 엔진을 제공하려고 한 기술은 Presto가 가장 빠르게 등장했다. 특히, Facebook에서 여러 데이터베이스를 쓰면서 느낀 불편한 점을 해결하고자 만들었다는 기술이라는 점에서 시장에서 빠르게 주목을 받으며 확산되었다. 상대적으로 속도가 느리다는 점은 여전히 큰 단점이지만, AWS Athena, S3 Select 서비스 등에 직간접적으로 영향을 주었다는 점에서 가장 널리 쓰이는 기술이라고 말할 수 있다. 그리고 아마, 여러 데이터베이스에 연결하기 위한 기술로는 거의 유일하게 발전하지 않을까 추측하고 있다.

[Presto 최초 아키텍처]

또 다른 분류의 SQL Engine도 존재하는데, 특정 데이터베이스 기술에 종속되어 기능을 제공하는 경우이다. 대표적인 것이 MySQL 기반의 수많은 데이터베이스 혹은 서비스들을 대상으로 종합적으로 SQL을 수행하도록 하기 위한 ProxySQL2이 이에 해당한다. 약간은 목적이 다르지만, Teradata의 독특한 문법을 직접 수정하지 않고 Redshift 로 이관할 수 있도록 하는 목적을 가진 Datometry3라는 회사도 미국에서는 상당히 유명하다. (이 회사는 Data Federation 쪽에도 많은 투자를 하고 있다.)

왜 이런 기술들이 지속적으로 등장하는지 생각해보면 크게 두 가지 이유일 것이다.

  • 기존의 데이터가 데이터베이스에 있어서
  • SQL로 데이터를 다루는 것이 편한 방법이기 때문에

최근에는 SQL을 직접 튜닝하지 않고 AI기법을 이용해서 성능을 빠르게 하도록 만들겠다는 기술들도 등장하고 있다. (예: EverSQL) 개인적인 생각으론 좀 과하다고 생각하긴 하지만, 데이터 저장 구조를 잘 이해하고 SQL을 튜닝할 수 있는 인력이 줄고 있다는 점을 감안하면 어느 정도 이해되는 일이기는 하다.

결론적으로, MSA 혹은 데이터레이크 트렌드로 인하여 데이터가 여러 곳에 파편화 되어 존재하는 것은 피할 수 없는 일일 것으로 보인다. 이 상황에서 데이터의 이동 없이 데이터를 SQL로 다루기 위한 기술들은 계속 등장할 것으로 보이며, 지속적인 개선이 이루어질 것으로 짐작한다. 이 복잡한 상황에서 얻어낼 수 있는 최소한의 결론은, SQL을 다루는 것은 향후 데이터 저장 방식이 변하는 상황에서도 계속 중요할 것이라는 점이다.

  1. How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh
  2. A High Performance MySQL Proxy
  3. Move from Teradata to a Modern Cloud Data Warehouse Without Changing Your SQL

    Related Posts

    Stored Procedure에 대한 단상
    Public Cloud Data Lake – Part I SQL을 이용한 Object Storage Data 분석
    DW의 Re-Platform to Cloud – Part III 에코시스템

    Leave a Reply