Data Eng Wiki

Semantic Control Plane

17 min read

Semantic Control Plane

사람은 계약이 없으면 누군가에게 물어서 우회할 수 있었다. 에이전트는 그럴 수 없고, 묻지도 않을 것이다

핵심 개념

시맨틱 레이어는 더 이상 웨어하우스와 대시보드 사이의 얇은 추상이 아니다. 회사가 비즈니스 의미, 실행 가능한 계산, 소유권, 정책, 맥락, 성능, 전달을 연결하는 자리가 되어가고 있다.

그것은 layer가 아니라 control plane — 비즈니스 질문을 하는 소비자와 답을 계산하는 교체 가능한 엔진 사이의 빠진 아키텍처다.

붙들어야 하는 다섯 가지

관심사내용
비즈니스 의미정의, 엔티티, 차원, 지표, 용어, 소유권
실행조인, 집계 로직, 쿼리 컴파일, federation, 엔진 선택
거버넌스접근, 인증, lineage, 정책, 책임, 변경 통제
지식과 맥락모델이 왜 이렇게 생겼는지 설명하는 결정·예시·관계
성능캐싱, 사전 집계, materialization, 신선도, 비용 인지 라우팅

대부분의 제품이 일부를 잘 구현하고 나머지는 시늉만 한다. 그것이 함정이다 — 하나의 control plane이 아니라, 각자 단일 도구 안에서만 권위 있는 여러 개의 부분적 control plane.

다섯 번째는 나머지와 완전히 동등하지 않다. 성능은 의미·거버넌스·실행이 만나는 지점이라 자기 상자를 갖지 못하고 캐시 키에서, 라우터에서, materialization에서 계속 다시 나타난다.

왜 지금인가

가장 어려운 데이터 문제는 쿼리가 아니라 질문에 합의하는 것이다.

  • active customer란 무엇인가?
  • MRR은 어느 날짜로 결정되나?
  • 환불은 원래 거래 월에 속하나, 환불이 일어난 월에 속하나?
  • 한 고객이 여러 제품을 쓸 때 churn은 정확히 무엇인가?

SQL은 보통 풀 수 있다. 조직적 모호성은 아니다. 이 결정들은 기업 인프라가 되도록 설계된 적 없는 곳에 산다 — 대시보드 필터, 재무 스프레드시트, 슬라이드 덱, Slack 스레드, 3년 전 정의가 왜 바뀌었는지 기억하는 한 사람.

10년간 지표의 소비자는 대시보드를 보는 사람이었고 사람은 물어봐서 모호한 숫자를 고칠 수 있었다. 이제 소비자는 점점 에이전트이고, 그럴 수 없다.

게다가 에이전트는 조합한다. 쿼리가 결정을 먹이고 그 결정이 다음 쿼리를 먹인다. stale하거나 정책 밖이거나 지난 분기 정의로 만들어진 숫자는 대시보드의 틀린 셀 하나로 드러나지 않고, 추론의 사슬을 타고 전파되어 자신만만한 권고로 도착한다.

“충분히 유능한 모델이 dbt 프로젝트와 Slack 스레드를 읽어 정의를 알아내면 되지 않나?” 종종 가능하다. 하지만 추론된 정의는 아무도 승인하지 않았고 아무도 감사할 수 없는 정의다. 대부분 맞는 것은 거버넌스 모델이 아니다. 기계 속도에서 그것은 인용을 달고 대규모로 틀리는 방법이다.

Materialization — 캐시 키는 무엇인가

두 사용자가 지난 분기 세그먼트별 net revenue를 요청한다. 하나는 모든 지역을, 다른 하나는 스위스만 볼 수 있다. 한 대시보드는 정의 4.2.0을, 다른 하나는 4.1.0을 쓴다. 기저 테이블이 새 스냅샷으로 전진했다. 일별 집계가 대시보드에는 충분히 신선하지만 규제 리포트에는 아니다.

캐시 키는 SQL 문자열도, 지표 이름도 될 수 없다.

“Arrow인가 Iceberg인가”는 사실 세 질문이 한 벌의 옷을 입은 것이다 — 어떤 포맷인가, 누가 아티팩트를 소유하나, 유효성을 어떻게 결정하나.

포맷은 수명을 따른다. Arrow는 비압축·랜덤 접근·CPU 네이티브로 이동 중인 데이터, Parquet은 압축·인코딩되어 정지 중인 데이터. 아키텍처 선호가 아니라 배치 규칙이다 — 초분은 Arrow, 시간월은 Parquet/Iceberg.

훔칠 만한 매칭 로직

사전 집계는 쿼리 텍스트 비교가 아니라 measure·차원·granularity·additivity를 추론해서 선택되어야 한다. 뷰의 멤버가 기저 cube 멤버로 해소되어 cube에 정의된 rollup이 뷰에 대해 쓰인 쿼리를 서빙한다.

materialization이 요청에 유효한 이유는 그것이 무엇을 의미하는지 때문이다.

열린 표준의 빈자리

가장 이식성을 중시하는 시맨틱 런타임(Cube)조차 사적 materialization 스토어를 발명해야 했다. Cube Store가 Parquet을 쓰지만 자체 내부 metastore가 관리하고 manifest도 스냅샷도 카탈로그도 없어 다른 엔진이 읽을 수 있는 테이블이 아니다.

이것은 Cube 비판이 아니라 가장 강한 증거다 — 시맨틱 집계가 무엇인지에 대한 열린 표준이 없다.

새로 발명할 필요는 없다. Iceberg의 View 스펙이 게시되어 있고 Materialized View 스펙이 함께 제안되어 있다(2024년 8월 개시, 여전히 논의 중). storage-table과 스냅샷 summary의 refresh-state(어느 뷰 버전에 대해 돌았는지, 언제 시작했는지, 의존한 소스들의 상태)를 정의한다. 요구되는 manifest의 대부분이 스토리지 레이어에서 도착하는 셈이고, 빠진 것은 시맨틱 절반 — 어느 거버넌스된 지표를, 어느 grain에서, 어느 정책 범위 하에, 언제까지 재사용 가능한지.

materialization이 보증을 선언한다. 요청이 요구를 선언한다. 라우터가 둘을 매칭한다.

그래프가 계약이지 반드시 데이터베이스는 아니다

net_revenue는 gross sales, 환불, 통화, 고객, 회계 정책, 소스 테이블, 소유자, 품질 테스트, 대시보드, 물리적 materialization과 연결된다. 평평한 지표 목록은 이것을 표현할 수 없고 자연스러운 모델은 그래프다.

하지만 그래프를 요구하는 것이 하나의 그래프 DB를 요구하는 것은 아니다. 그래프는 논리적 계약이어야 한다 — 안정적 identity, 타입된 관계, provenance, 버저닝, 기계 판독 순회. 표현은 실행 가능한 시맨틱 모델·카탈로그·정책 시스템·링크된 문서·열린 테이블에 federated된 채 남을 수 있다.

의미를 위한 MDM

전통 MDM이 고객·제품·공급자에게 시스템 전반의 거버넌스된 identity를 주듯, semantic MDM은 net_revenue, active_customer, churn 같은 개념에 대해 같은 일을 한다 — 정의·계산·소유자·정책·맥락·materialization·다운스트림 사용을 잇는 하나의 안정적 identity.

중앙 “golden model”이 필요한 게 아니다. 권위를 갖는 것은 identity와 그 관계와 생명주기다. golden record가 golden identity가 된다.

→ Knowledge Spine과 같은 문제의식이되, 여기서는 실행과 라우팅에 초점이 있다.

열린 데이터도, 열린 SQL도 의미를 열지 않았다

Iceberg가 데이터를 열었지 의미를 열지 않았다.

세 rung이 이미 열려 있다.

스토리지   Iceberg (스키마 · 스냅샷 · 트랜잭션 메타데이터, REST Catalog)
표현식     GoogleSQL (엔진 패밀리 전반의 표현식 시맨틱)
플랜       Substrait (SQL과 런타임 사이의 플랜)
─────────────────────────────────────────────
??         active customer가 무엇인지 아는 것

그중 어느 것도 active customer가 무엇인지, 매출이 시간에 걸쳐 additive한지, 재무가 어느 조인 경로를 승인했는지, 환불이 거래 월에 속하는지 모른다.

열린 카탈로그는 테이블 목록만이 아니라 거버넌스도 실을 수 있다(Lakekeeper 같은 Apache-2.0 REST Catalog 구현이 접근 통제·credential vending·감사를 더한다). control plane에서 이것은 물리적 상태로의 인터페이스다 — 라우터가 materialization을 위치 확인하고, 스코프된 credential을 얻고, 읽은 스냅샷을 pin하고, 그 전부를 receipt에 기록한다.

하지만 어떤 카탈로그도 semantic.net_revenue_daily가 net_revenue 버전 4.2.0을, 어느 grain에서, 누구를 위해, 언제까지 구현하는지는 말해줄 수 없다.

요청의 여정

① 소비자가 엔진이 아니라 의미를 요청     (Athena SQL이 아니라 거버넌스된 net_revenue identity)
② 레지스트리가 거버넌스된 identity 해소
③ control plane이 개념 조립               (실행 가능한 지표 + 맥락 링크 + 적용 정책)
④ 라우터가 어떻게 답할지 결정             (차원·조인 검증, 정책 범위, 신선도·비용,
                                            materialization 보증 ↔ 요청 요구 매칭
                                            → 그 다음에야 런타임 선택)
─────────── data plane 경계 ───────────
⑤ 이식 가능한 증거                        (Iceberg 스냅샷 + semantic aggregate manifest)
⑥ receipt와 함께 결과 반환                (정의 · 정책 결정 · 스냅샷 · materialization
                                            · 엔진 · conformance profile)

Athena와 Spark가 불일치하면 조직이 두 SQL 문자열에서 비즈니스 정의를 재발견하는 대신 증거를 비교한다.

4단계가 에이전틱 워크로드에서 특별한 이유

사람은 한 번에 하나를 묻는다. 에이전트는 수십 개 서브에이전트로 fan out해 각자 작고 구체적인 것을 묻는다.

사전 집계된 테이블에 대한 쿼리가 왜 분산 클러스터를 필요로 하나 — DuckDB 같은 in-process 엔진이 밀리초에 답하는데? 그 볼륨에서 클러스터 시작은 오버헤드가 아니라 레이턴시 예산 전체다.

엔진 선택이 배포 결정이 아니라 요청별 결정이 되고, 그것은 materialization 매칭과 같은 결정이다. 올바른 버전·grain·신선도·정책 범위의 유효한 집계가 있으면 단일 노드 엔진이 서빙하고, 없으면 소스 테이블로 떨어져 더 큰 것이 필요하다. 어느 materialization과 어느 엔진은 두 질문이 아니라 하나다.

그래서 실행 계약이 선택 사항으로 남을 수 없다. 소수점·NULL·시간대에 대해 의견이 다른 엔진들 사이에서 자유롭게 고르는 라우터는 부하에 따라 같은 질문에 다른 답을 반환한다.

conformance 없는 비용 인지 라우팅은 최적화가 아니라 예산이 붙은 비결정성이다.

어떻게 시작하나 — corpus가 스펙을 이끈다

conformance는 net_revenue가 무엇을 의미해야 하는지 결정할 수 없다. 그것은 비즈니스 결정이다. 두 런타임이 같은 선언된 의미를 충실히 실행하는지 테스트할 수 있을 뿐이다.

이 구분이 들리는 것보다 중요하다. 시맨틱 언어가 orders에 대한 합은 표현할 수 있지만 회계 달력이 4-4-5이고, 환불이 원래 판매 월에 귀속되고, distinct 고객 수가 근사가 아니라 정확해야 함을 진술할 수 없다면 — 두 엔진이 모든 테스트를 통과하면서 다른 숫자를 낼 수 있다. 그건 엔진 문제만이 아니라 선언 포맷의 구멍이다.

conforming 엔진들이 여전히 다르게 해석할 수 있는 모든 golden case가 선언 언어의 빠진 조각을 식별한다. 테스트가 고객이 두 임원 대시보드에서 발견하기 전에 모호성을 보이게 만든다.

시작할 케이스: 시간대, 회계 달력, NULL, 소수점, distinct count, 다대다 조인, semi-additive measure, 늦게 도착하는 데이터, 정책 의존 결과.

아무도 시작 허락을 받을 필요가 없다. 월요일에 한 팀이 어려운 net_revenue 케이스 10개를 쓰고, 현재 모델이 허용하는 만큼 표현하고, 두 엔진에 돌리고, 결과와 미해결 모호성을 함께 게시할 수 있다.

연관 개념

Source: The Semantic Layer Is Not a Layer Anymore

그래프 뷰

백링크