Simplifying Data and Product Integrations with a Data Abstraction Layer (Uber)
Author: Daniel Musgrave, James Yang, Narendra Kumar (Uber) | Source: Uber Engineering Blog | Published: 2026
한 줄 요약
Uber가 쿼리를 데이터셋 구조·토폴로지에서 분리하기 위해 logical table(무엇을)과 physical table(어떻게)을 분리하는 Data Abstraction Layer(DAL)를 구축해, 새 advertiser 리포트 구축을 수 주에서 2일 미만으로 단축.
핵심 주장/내용
- 문제: 쿼리가 underlying 데이터셋 구조에 tight하게 결합 → 모델 변경이 느리고 어려움(v1 테이블 num_widgets가 v2에서 count_widgits로 이름 변경 등)
- DAL = producer와 consumer 사이의 RPC 서비스: 요청 수락 → 소스 결정 → 쿼리 오케스트레이션 → 응답 조립. 선언적 config + table resolution
- FetchData: logical table(데이터 인터페이스, where/how 없음)에 대해 table·schema·time range·filter 요청. dimension 빼면 자동 roll-up(client는 무엇을, 서비스가 어떻게)
- Table Resolution 3단계: ① schema eligibility(모든 dimension/일부 metric 없는 후보 폐기) ② dataset availability(freshness/retention 윈도우 교차 확인) ③ column continuity(time range→candidate 매핑, 요청 cardinality에 가까운 후보 선호) → physical 테이블·컬럼·time range 집합
- Query 생성·실행: 각 테이블에 DB별 쿼리 생성·실행(OLAP, Docstore, Hive 혼합 가능), 병렬 실행
- Result Assembly: concatenation(시간 인접) + joins(상보적 metric) + rollups + scalar transform
주요 수치 / 사실
- 새 advertiser 리포트: 수 주~수 개월 → 2일 미만
- 예시: realtime 2개(최근 3일) + daily 1개(나머지 4일) = 3개 쿼리 병렬 실행 후 조립
- domain-agnostic 설계 → ads에서 비-ads 도메인으로 확장. async 요청·추가 DB 통합 로드맵
- Semantic Layer / Query Proxy와 유사하나 logical→physical table resolution + 시간 기반 source 선택이 특징
관련 위키
Source: 원문 보기