Data Eng Wiki

Knowledge Graph Infrastructure

8 min read

Knowledge Graph Infrastructure

엔티티 간 관계를 그래프로 모델링·저장·질의하는 대규모 프로덕션 인프라

핵심 개념

Knowledge Graph Infrastructure는 사용자·콘텐츠·도로 세그먼트 등 엔티티와 그 관계를 정점(vertex)·엣지(edge)로 모델링하고, 저지연·대규모로 다중 hop 순회 쿼리를 서빙하는 플랫폼이다. Knowledge Representation(온톨로지·택소노미가 무엇을 의미하는가)가 의미론 층이라면, 이 페이지는 그 그래프를 어떻게 저장·질의·스케일하는가라는 인프라 층을 다룬다.

관계가 본질인 시스템 — 신원 해결(identity resolution), 사기 탐지, 데이터 리니지, 추천, 교통 예측 — 에서 그래프는 관계형 조인보다 자연스럽고 강력하다. 그러나 high-fanout 노드와 4~8 hop 쿼리는 long-tail 지연을 폭발시키므로, 인프라 설계가 성패를 가른다.

그래프 도입의 안티패턴 (Airbnb)

중앙 관리 인프라 이전, 팀들이 빠지는 4가지 안티패턴:

안티패턴문제
관계형 “그래프”SQL 테이블로 노드/엣지 모델링 → 순회 시 비싼 조인
오프라인 그래프데이터 웨어하우스에 구축 → 일일 스냅샷으로 신선도 제한
DIY 오픈소스커뮤니티 버전 자체 운영 → 높은 운영 부담
Managed PaaS서드파티 벤더 → 벤더 락인, 성능 병목, long-tail 지연

→ 해법: paved-path 멀티테넌트 인프라로 모든 use case를 단일 지원 인프라에 통합. 각 테넌트(identity graph 등)는 격리된 namespace에서 운영.

온라인 그래프 DB 스택 (JanusGraph + DynamoDB)

Airbnb는 4가지 요건(온라인 쿼리 확장성, 표현력 있는 스키마/쿼리, 인프라 적합성, 확장 가능한 코드베이스)으로 선정:

  • JanusGraph(Apache TinkerPop 기반 분산 그래프 DB) + labeled property graph 모델 + Gremlin 순회 쿼리
  • DynamoDB를 스토리지 백엔드로(pluggable storage) → 스토리지 분리: 분산 스토리지 운영을 재발명하지 않고 그래프 로직 레이어만 제어, 향후 스토리지 진화 여지
  • OpenSearch로 인덱싱

엔진 최적화

  • 경량 트랜잭션: 기본 locking이 무거움 → DynamoDB 조건부 쓰기/트랜잭션 API로 데이터 무결성 확보
  • 병렬 쿼리 실행: getMultiSlices를 병렬화 → high-fanout 쿼리 지연 감소
  • 관측성: 분산 트레이싱을 내부 fork에 통합
  • 클라이언트 측 쿼리 재작성: Path step 제거(배치 안 되는 느린 쿼리) → 조건부 쿼리, side-effect step 최소화

그래프를 “고정 입력”으로 흡수하기 (Uber DeepETT)

동적 그래프(GNN/시퀀스 모델)는 표현력이 높지만, 예제당 가변적 원시 관측을 materialize해야 해 대규모에서 공격적 다운샘플링을 강요한다. Uber는 반대로 갔다:

  • 사전 집계된 고정 크기 입력: 각 세그먼트의 spatiotemporal view(세그먼트/그래프 이웃/지역 × 정적/과거/실시간)를 토큰으로 Transformer에 입력 → 다운샘플링 없이 모든 관측 활용, 상수 시간 추론
  • 그래프 임베딩은 별도 message-passing 단계에서 사전 계산 → 추론 경로에서 그래프 순회 비용 제거
  • 효과: “GNN의 이점 대부분 + 프로덕션 친화적 상수 시간 추론”

두 접근의 대비: Airbnb는 온라인 순회가 본질(신원 해결은 실시간 다중 hop)이라 그래프 DB를 최적화했고, Uber는 예측 추론이 본질이라 그래프를 피처로 사전 계산해 흡수했다. “그래프 DB가 필요한가, 그래프 피처가 필요한가”가 갈림길.

”Taller on top” — 기존 추상화 위에 쌓기 (Netflix Graph Abstraction)

Netflix는 그래프 DB를 통째로 채택하는 대신, 이미 검증된 데이터 추상화 위에 그래프 레이어만 쌓았다. OLTP 그래프(초당 1천만 연산, 650TB, 밀리초 순회)에 특화:

  • KV Abstraction(실시간 인덱스) + TimeSeries Abstraction(과거 뷰) + EVCache(밀리초 지연) 위에 구축 — 페르시스턴스/캐시를 재발명하지 않음
  • Property Graph + 명시적 스키마: 시작 시 in-memory 메타데이터 그래프 빌드 → 데이터 품질(비순응 거부), 쿼리 플래닝, 불가능 관계 제거
  • 엣지 저장 분리: links(인접 리스트)와 properties를 분리 → property upsert 효율 + wide row 방지(Cassandra), 단 네임스페이스 간 비원자적 쓰기. forward/reverse 인덱스 + 방향 무관 식별자(소스·목적지 ID 사전식 정렬·연결)
  • 캐싱: write-aside(엣지 링크, write amplification↓) + read-aside(properties, read amplification↓). 일관성: Kafka 엔트로피 복구 + 비동기 노드 삭제 + LWW
  • OLAP vs OLTP 구분: 알고리즘적 대규모 탐색(SPARQL/Gremlin)은 OLAP, 초당 수백만 연산·밀리초·제약 수용은 OLTP — Graph Abstraction은 OLTP 전용

Airbnb가 “범용 그래프 DB(JanusGraph)를 paved-path로 제공”했다면, Netflix는 “사내 KV/TS 추상화 위에 OLTP 그래프만 얇게 쌓아” 기존 운영 자동화·캐시·provisioning을 그대로 재사용했다. 둘 다 멀티테넌트 namespace 모델을 공유한다.

언제 무엇을 쓰는가

  • 실시간 다중 hop 순회·관계 질의가 핵심 → JanusGraph류 그래프 DB (Airbnb identity/fraud)
  • 초당 수백만 OLTP 연산 + 기존 KV/TS 추상화 보유 → “taller on top” (Netflix Graph Abstraction)
  • 그래프 구조를 ML 예측의 피처로만 활용 → 그래프 임베딩 사전 계산 + 일반 모델 (Uber 교통 예측)
  • 일일 배치 분석으로 충분 → 데이터 웨어하우스의 그래프 모델(신선도 트레이드오프 수용)

연관 개념

Source: Scaling Airbnb Identity Graph with Unified Knowledge Graph Infrastructure, Uber DeepETT - Real-Time Traffic Forecasting with Graph-Aware Transformer, High-Throughput Graph Abstraction at Netflix Part I

그래프 뷰

백링크