56. 데이터 가상화 및 연방 쿼리 (Federated Query) 엔진

⚠️ 이 문서는 오라클, MySQL, AWS S3, MongoDB 등 사방에 흩어진 각기 다른 데이터베이스들의 데이터를 한곳으로 모으는 비용(ETL)을 지불하지 않고, **데이터는 제자리에 그대로 둔 채 오직 하나의 거대한 투명 장막(쿼리 엔진)을 띄워놓고 "단 한 줄의 SQL로 이종 DB들을 동시에 조인(Join)해서 결과를 뽑아내는 마법"인 '연방 쿼리 엔진(Presto, Trino)'**을 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: 데이터의 '물리적 이동'을 금지하고 '논리적 연결'로 대체하는 데이터 가상화(Data Virtualization) 기술의 끝판왕이다. 쿼리 엔진 자체가 데이터를 1바이트도 저장하지 않는 '순수 연산 전용(Compute-only) 노드'로 동작한다.
  2. 가치: "PostgreSQL의 고객 테이블과 S3의 서버 로그 텍스트 파일을 조인해 줘!"라는 불가능해 보이는 요청을 1초 만에 수행하여, 데이터 늪(Data Swamp) 현상과 ETL 파이프라인 개발에 며칠을 허비하는 엔지니어의 피로를 혁명적으로 구원한다.
  3. 기술 체계: 페이스북이 300페타바이트의 하둡 데이터를 뒤지기 위해 만든 **Presto(프레스토)**에서 출발하여, 현재는 그 창시자들이 독립해 만든 **Trino(트리노, 구 PrestoSQL)**가 초고속 분산 인메모리 쿼리 엔진의 글로벌 표준으로 자리 잡았다.

Ⅰ. ETL의 종말: 데이터 복사의 무거운 대가

데이터를 모으는 것 자체가 거대한 짐이 된 시대다.

  1. 전통적 데이터 웨어하우스의 고통:
    • 기존에는 분석을 위해 오라클(영업팀), 몽고DB(로그팀)의 데이터를 매일 밤 배치(Batch) 스크립트를 짜서 중앙의 하둡(Hadoop)으로 복사(ETL)해 왔다.
    • 복사하느라 네트워크 비용이 터지고, 스크립트 짜느라 일주일이 걸리며, 복사된 데이터는 이미 하루가 지난 과거 데이터(Stale Data)가 되어 실시간 분석이 불가능했다.
  2. 데이터 가상화 (Data Virtualization)의 역발상:
    • "데이터를 옮기지 말고, 질문(Query)을 쪼개서 각자의 DB로 배달시켜 주면 어떨까?"
    • 가상화 엔진은 데이터를 담는 그릇(디스크)이 아니라, 질문을 해석하고 분배하는 '똑똑한 콜센터' 역할을 맡게 되었다.

📢 섹션 요약 비유: 전국의 100개 도서관 책을 서울 중앙 도서관으로 몽땅 트럭으로 퍼 나른(ETL) 뒤에야 책을 읽을 수 있었던 과거를 버리고, 내가 검색창에 질문을 넣으면 검색 엔진(연방 쿼리)이 전국 100개 도서관 컴퓨터에 실시간으로 접속해 알아서 답만 쪽 빼와서 화면에 하나로 합쳐서 보여주는 텔레파시 초능력입니다.

Ⅱ. 연방 쿼리 (Federated Query) 엔진의 작동 원리

하나의 SQL 문장이 여러 나라의 언어로 동시에 번역된다.

  1. 커넥터 (Connector) 플러그인 아키텍처:
    • Trino/Presto 엔진에는 수십 개의 커넥터(RDBMS, NoSQL, S3, Kafka 등)가 꽂혀 있다. 각 커넥터는 엔진이 지시하는 표준 SQL을 해당 벤더의 방언(Dialect)으로 1초 만에 번역해 준다.
  2. 연방 조인 (Federated Join) 실행 과정:
    • 분석가: SELECT * FROM mysql.고객 JOIN s3.클릭로그 ON 고객.id = 로그.id
    • 엔진 코디네이터(Coordinator)가 이 쿼리를 받아서 쪼갠다. "MySQL아 너는 고객 정보 100명만 뽑아와. S3 커넥터야 넌 하둡에 가서 파일 좀 뒤져와."
    • MySQL과 S3가 각자 계산한 작은 덩어리의 결과물만 엔진의 수백 대의 워커 노드(Worker Node) 메모리로 슝 쏴준다.
    • 워커 노드들이 허공(인메모리)에서 이 두 데이터를 찰칵 조인(Join)하여 분석가 화면에 띄워준다. 디스크에 쓰는 과정이 없으므로 속도가 미친 듯이 빠르다.

📢 섹션 요약 비유: 한국인 사장님(분석가)이 "미국 지사(MySQL)의 재무 데이터와 중국 지사(S3)의 영업 데이터를 합쳐와!"라고 통역관(연방 쿼리 엔진)에게 말하면, 통역관이 동시에 미국과 중국으로 전화를 걸어 데이터를 받아낸 뒤, 공중에 홀로그램을 띄워(인메모리 조인) 사장님 눈앞에서 하나로 겹쳐서 보여주는 완벽한 동시통역 비서입니다.

Ⅲ. Trino/Presto의 트레이드오프와 쿼리 푸시다운

마법 같지만, 네트워크를 태우는 한계는 여전히 존재한다.

  1. 인메모리 터짐 현상 (OOM, Out of Memory):
    • 두 데이터를 엔진 메모리에서 조인할 때, 그 크기가 엔진의 남은 메모리 용량보다 크면 엔진 서버가 폭발(OOM 에러)하며 쿼리가 죽어버린다. (따라서 최근에는 디스크로 잠시 빼주는 Spilling 기능을 지원하기 시작했다.)
  2. 푸시다운 (Predicate Pushdown) 최적화의 생명선:
    • 만약 WHERE 나이 > 30 이라는 조건이 있을 때, 이 필터링을 Trino 엔진 메모리까지 데이터를 다 끌고 와서 처리하면 수 테라바이트의 네트워크 폭탄이 터진다.
    • 따라서 영리한 연방 엔진은 "야, 데이터 보내기 전에 네 쪽(MySQL) DB에서 미리 30세 이상만 필터링 싹 다 해서 그것만 엑기스로 보내!"라고 하위 DB로 필터링 연산의 책임을 밀어내어(Push-down) 네트워크를 통과하는 데이터양을 1/100로 줄여버리는 최적화 꼼수를 쓴다.

📢 섹션 요약 비유: 통역관 비서가 미국 지사에 전화를 걸어 "있는 서류 10만 장 다 보내주시면 제가 여기서 100장만 추려낼게요"라고 하면 국제 배송비(네트워크)가 터져버립니다. 그래서 똑똑한 비서는 "미국 지사 직원분, 거기서 1990년생 자료 100장만 미리 추려서(푸시다운) 팩스로 딱 1장만 보내세요!"라고 지시하여 팩스비와 시간을 극단적으로 아끼는 고도의 밀당 전술을 씁니다.