Apache Atlas

Apache Atlas 는 회사 데이터가 어디서 와서 어디로 가는지 기록해 두는 도구입니다. 하둡에 쌓인 테이블과 파일마다 설명과 꼬리표를 붙여 둡니다. 이 기록 덕분에 필요한 데이터를 찾고 민감한 데이터를 가려낼 수 있습니다.

상세

Apache Atlas 는 Apache 소프트웨어 재단이 관리하는 오픈 소스 프로젝트입니다. 하둡 위에 쌓인 데이터에 대한 기록을 한곳에 모읍니다. 하둡은 큰 데이터를 여러 서버에 나눠 저장하고 처리하는 오픈 소스 도구 묶음입니다.

이 절은 데이터가 많아질 때 생기는 질문에서 출발합니다. Atlas 가 그 질문에 답하려고 기록을 어떤 모양으로 쌓는지 봅니다. 타입과 엔티티, 계보, 분류, 용어집, 검색 순서입니다.

이어서 Atlas 를 이루는 부품을 봅니다. 끝으로 Atlas 를 고르는 경우와 치르는 값을 봅니다.

데이터가 많아지면 생기는 질문

회사가 커지면 하둡에 테이블이 수천 개 쌓입니다. 팀마다 제 테이블을 만듭니다. 남의 테이블을 읽어 새 테이블을 만들기도 합니다. 얼마 지나면 전체를 아는 사람이 없어집니다.

그러면 아래 같은 질문에 답하기 어려워집니다.

세 질문 모두 데이터 자체가 아니라 데이터에 대한 정보를 묻습니다. 이런 정보를 메타데이터라고 부릅니다. 테이블 이름, 열 목록, 만든 사람, 어디서 왔는지가 모두 메타데이터입니다.

데이터 거버넌스는 회사가 가진 데이터를 누가 어떻게 쓰는지 정하고 지키는 일입니다. 개인정보를 아무나 못 읽게 막는 것이 그 한 예입니다. 무엇이 어디 있는지 모르면 이 일을 시작할 수 없습니다.

Atlas 는 이 메타데이터를 모아 두는 저장소입니다. 데이터 자체는 하둡에 남습니다. Atlas 는 그 데이터에 대한 기록만 갖습니다.

데이터를 찾고 이해하도록 메타데이터를 모아 둔 곳을 데이터 카탈로그라고 부릅니다. Atlas 는 하둡 둘레의 데이터 카탈로그입니다.

타입과 엔티티

Atlas 는 기록을 적기 전에 기록의 틀부터 정합니다. 이 틀이 타입입니다. 어떤 대상이 어떤 속성을 갖는지 정합니다.

예를 들어 Hive 테이블의 타입이 있습니다. Hive 는 하둡에 쌓인 파일을 SQL(Structured Query Language)로 조회하게 해 주는 도구입니다. Hive 테이블 타입은 「테이블은 이름과 열 목록과 소속 데이터베이스와 주인을 갖는다」고 정합니다.

Atlas 는 하둡 둘레의 흔한 대상에 쓸 타입을 미리 갖고 있습니다. Hive 테이블을 뜻하는 hive_table, Hive 열을 뜻하는 hive_column 같은 것입니다.

파일 경로에 쓰는 타입도 있습니다. 하둡은 파일을 HDFS(Hadoop Distributed File System)에 담습니다. HDFS 는 파일을 여러 서버에 나눠 담는 하둡의 파일 시스템입니다. 그 경로 하나를 뜻하는 타입이 hdfs_path 입니다.

회사가 쓰는 다른 대상이 있으면 타입을 새로 정의해 더할 수 있습니다. 사내 대시보드나 머신러닝 모델을 기록하고 싶을 때 이렇게 합니다.

엔티티는 타입에 맞춰 적은 기록 하나입니다. sales 데이터베이스의 orders 테이블이 hive_table 타입의 엔티티 하나입니다. 타입이 클래스라면 엔티티는 그 클래스로 만든 객체입니다.

엔티티마다 이름표가 둘 붙습니다. 하나는 Atlas 가 매기는 GUID(Globally Unique Identifier, 전역 고유 식별자)입니다. 엔티티를 만들 때 정해집니다. 그 뒤로는 바뀌지 않습니다.

클러스터는 한 덩어리로 묶여 함께 도는 서버 무리입니다. 회사는 클러스터를 여럿 굴리기도 합니다. 그러면 같은 이름의 테이블이 클러스터마다 하나씩 있을 수 있습니다.

다른 하나의 이름표는 qualifiedName 속성입니다. 사람이 읽는 이름에 클러스터 이름까지 붙여 회사 전체에서 겹치지 않게 만든 이름입니다.

Atlas 는 기록을 웹 주소로 읽고 쓰게 해 줍니다. 이런 방식을 REST(Representational State Transfer)라고 부릅니다.

JSON(JavaScript Object Notation)은 이름과 값을 중괄호로 묶어 적는 데이터 형식입니다. 아래는 orders 엔티티를 REST 로 읽었을 때 돌아오는 JSON 의 일부입니다. 속성은 몇 개만 남겼습니다.

{
  "typeName": "hive_table",
  "attributes": {
    "qualifiedName": "sales.orders@prod",
    "name": "orders",
    "owner": "order-team"
  },
  "classifications": [
    { "typeName": "PII" }
  ]
}

typeName 이 이 엔티티의 타입입니다. qualifiedName 끝의 @prod 는 이 테이블이 prod 라는 클러스터에 있다는 뜻입니다. 맨 아래 classifications 는 뒤의 「분류와 전파」에서 봅니다.

계보

데이터 계보는 데이터가 어디서 와서 어디로 갔는지 이은 기록입니다. 데이터 리니지라고도 부릅니다. 앞에서 본 「이 숫자는 어느 테이블에서 왔나」에 답하는 기록입니다.

Atlas 는 계보를 두 종류의 엔티티로 적습니다. 테이블이나 파일처럼 데이터를 담는 엔티티가 한쪽입니다. 데이터를 읽어 다른 데이터를 만드는 작업이 다른 쪽입니다.

Atlas 에는 두 쪽을 나타내는 위 타입 DataSet 과 Process 가 있습니다. 다른 타입들은 둘 중 하나를 물려받습니다. 앞의 클래스 비유로 말하면 둘은 부모 클래스입니다. hive_table 은 DataSet 을 물려받습니다.

작업 엔티티에는 입력과 출력이 붙습니다. 무엇을 읽어 무엇을 썼는지가 이 둘에 적힙니다.

예를 들어 Hive 에서 아래 질의를 돌렸다고 합시다. orders 를 읽어 날짜별 매출을 모은 daily_sales 테이블을 채웁니다.

INSERT INTO sales.daily_sales
SELECT order_date, sum(amount)
FROM sales.orders
GROUP BY order_date;

Atlas 에는 이 질의를 뜻하는 작업 엔티티가 하나 생깁니다. 입력은 orders 이고 출력은 daily_sales 입니다. daily_sales 를 다시 읽어 monthly_report 테이블을 만드는 질의가 있으면 그 아래로 한 칸 더 이어집니다. 아래 그림이 그렇게 이어진 모습입니다.

flowchart TD
    A["orders 테이블"] -->|입력| P["작업 엔티티 · 날짜별 매출 질의"]
    P -->|출력| B["daily_sales 테이블"]
    B -->|입력| Q["작업 엔티티 · 월간 보고서 질의"]
    Q -->|출력| C["monthly_report 테이블"]

이렇게 이어 두면 두 방향으로 따라갈 수 있습니다. monthly_report 에서 위로 올라가면 숫자가 어디서 왔는지 나옵니다. orders 에서 아래로 내려가면 이 테이블을 바꿨을 때 흔들리는 테이블이 나옵니다. 아래로 따라가며 바꿀 때의 피해를 가늠하는 일을 영향 분석이라고 부릅니다.

Hive 질의에서는 열 단위 계보도 남습니다. daily_sales 의 매출 열이 orders 의 amount 열에서 왔다는 것까지 적힙니다.

분류와 전파

분류(classification)는 엔티티에 다는 꼬리표입니다. 「개인정보」「재무」「삭제 예정」 같은 이름을 붙입니다. 데이터를 어떤 규칙으로 다룰지 가르려고 답니다.

앞의 JSON 에 있던 PII 가 분류 하나입니다. PII(Personally Identifiable Information, 개인 식별 정보)는 이메일이나 전화번호처럼 사람을 알아볼 수 있는 정보입니다.

분류도 타입의 한 종류입니다. 그래서 속성을 가질 수 있습니다. 「개인정보」 분류에 「보존 기한」 속성을 두는 식입니다.

분류는 계보를 따라 퍼집니다. orders 에 PII 를 달면 orders 를 읽어 만든 daily_sales 에도 PII 가 붙습니다. 그 아래 monthly_report 에도 붙습니다. 이것을 분류 전파라고 부릅니다.

퍼뜨리는 까닭은 사람 손이 못 따라가기 때문입니다. 새 테이블이 생길 때마다 꼬리표를 직접 다는 일은 금방 밀립니다. 퍼뜨리면 원천 테이블 하나에만 달아도 그 아래가 다 덮입니다.

대신 지나치게 퍼지기도 합니다. daily_sales 에는 날짜와 매출 합계만 있어서 고객 이메일이 없습니다. 그래도 PII 가 붙습니다.

그래서 분류를 달 때 전파를 끌 수 있습니다. 계보의 특정 연결에서만 전파를 막을 수도 있습니다.

용어집

비즈니스 용어집은 회사 안에서 쓰는 업무 낱말과 그 뜻을 모아 둔 목록입니다. 「활성 고객」이 30일 안에 주문한 고객인지 90일 안에 접속한 고객인지를 적어 두는 식입니다.

Atlas 에서는 용어 하나를 여러 엔티티에 붙일 수 있습니다. 「매출」 용어를 daily_sales 의 매출 열에 붙이면, 그 열을 보는 사람이 뜻을 바로 찾습니다.

분류와 비슷해 보여도 쓰임이 다릅니다. 분류는 다루는 규칙을 가르려고 답니다. 용어는 뜻을 알려 주려고 붙입니다.

검색

쌓인 기록은 찾을 수 있어야 쓸모가 있습니다. Atlas 는 찾는 방법을 셋 둡니다. 그중 하나가 Atlas 전용 질의 언어로 찾는 방법입니다.

DSL(Domain-Specific Language)은 한 가지 일에만 쓰려고 만든 작은 언어입니다. Atlas 의 질의 언어도 기록을 찾는 일 하나에만 씁니다. 그래서 이 방법을 DSL 검색이라고 부릅니다.

기본 검색은 화면에서 고르기만 하면 됩니다. 「PII 가 붙은 hive_table」 같은 조건이 여기에 맞습니다.

DSL 검색은 타입 이름 뒤에 조건을 붙여 씁니다.

hive_table where name = "orders"

이 줄은 이름이 orders 인 Hive 테이블 엔티티를 찾습니다. 기본 검색으로 못 거는 조건을 적을 때 씁니다.

Atlas 를 이루는 부품

Atlas 서버는 기록을 그래프로 다룹니다. 그래프는 점과 그 점들을 잇는 선으로 이루어진 구조입니다. 엔티티는 점이 됩니다. 계보와 소속 관계는 점 사이의 선이 됩니다.

그래프 데이터베이스는 점과 선을 저장하고 선을 따라 찾아가도록 만든 데이터베이스입니다. 계보를 위아래로 몇 칸씩 따라가는 일이 여기에 맞습니다.

Atlas 는 JanusGraph 라는 그래프 데이터베이스를 서버 안에 품고 있습니다. JanusGraph 는 디스크를 직접 다루지 않습니다. 다른 저장소 둘에 기댑니다.

HBase 는 하둡 위에서 큰 표를 여러 서버에 나눠 담는 데이터베이스입니다. 점과 선은 여기에 저장됩니다.

Solr 는 낱말로 문서를 찾게 해 주는 검색 엔진입니다. 이름이나 속성으로 찾는 데 쓰는 인덱스는 여기에 둡니다.

기록은 Kafka 로도 드나듭니다. Kafka 는 메시지를 차례대로 쌓아 두고 여러 쪽이 나눠 읽게 하는 메시지 시스템입니다. 다른 도구가 보낸 알림이 Kafka 를 거쳐 Atlas 로 들어옵니다. Atlas 가 바뀐 기록을 알리는 것도 Kafka 로 나갑니다.

알림을 보내는 쪽은 훅입니다. 훅은 다른 도구 안에 끼워 넣어 그 도구가 일할 때마다 함께 도는 작은 코드입니다.

바뀐 기록을 받아 가는 쪽으로는 접근 권한을 관리하는 Ranger 가 대표적입니다. 훅과 Ranger 는 둘 다 아래 「맞물림」에서 자세히 봅니다.

아래 그림은 지금 본 부품들이 이어진 모습입니다. 사람은 웹 화면이나 REST 로 Atlas 서버에 직접 묻습니다. JanusGraph 는 서버 안쪽에 그렸습니다.

flowchart TD
    H["다른 도구 안의 훅"] -->|알림| K["Kafka"]
    subgraph A["Atlas 서버"]
        S["기록을 받고 내보내는 부분"] --> J["JanusGraph"]
    end
    K --> S
    U["사람 · 웹 화면과 REST"] --> S
    S -->|바뀐 기록| K
    K --> R["Ranger"]
    J --> HB["HBase · 점과 선"]
    J --> SO["Solr · 검색 인덱스"]

그림에서 Atlas 서버는 기록을 받고 내보내는 일만 합니다. 기록을 오래 쥐는 일은 HBase 와 Solr 가 맡습니다.

Atlas 를 고르는 경우

Atlas 는 하둡을 중심으로 데이터를 쌓는 회사에 맞습니다. Hive 로 테이블을 만들고 HBase 와 Kafka 를 이미 굴린다면 Atlas 가 기대는 부품이 거의 다 갖춰져 있습니다. Ranger 로 권한을 관리한다면 Atlas 의 분류를 권한 규칙에 바로 쓸 수 있습니다.

하둡이 없는 곳에서는 치르는 값이 커집니다. Atlas 하나를 띄우려고 HBase, Solr, Kafka 를 따로 세워 굴려야 합니다. 클라우드의 분석용 데이터베이스를 중심으로 일하는 회사라면 DataHub 나 OpenMetadata 같은 다른 데이터 카탈로그가 같은 일을 맡습니다.

계보는 훅이 보낸 만큼만 남습니다. 훅이 없는 도구로 만든 테이블은 연결이 비어 있습니다. 파이썬 스크립트가 파일을 읽어 다른 파일을 쓰면, 누가 그 연결을 API(Application Programming Interface)로 직접 적어 넣지 않는 한 Atlas 는 모릅니다. 그래서 Atlas 를 들이기 전에 쓰는 도구마다 훅이 있는지부터 봅니다.

맞물림

Atlas 는 혼자서는 빈 저장소입니다. 기록을 보내 주는 도구와 기록을 받아 쓰는 도구가 붙어야 쓸모가 생깁니다.

이 절은 하둡 둘레의 도구가 Atlas 와 어느 방향으로 붙는지 세 갈래로 봅니다. Hive 는 기록을 보냅니다. Ranger 는 기록을 받아 갑니다. HBase 와 Solr 는 기록을 맡습니다.

갈래는 셋, 도구는 넷입니다. 넷 다 Atlas 와 같은 Apache 재단의 프로젝트입니다.

Hive 안에서 도는 Atlas 훅

Hive 는 질의를 마칠 때마다 미리 등록된 훅을 부릅니다. Atlas 가 내놓은 Hive 훅이 그중 하나입니다.

훅은 방금 만든 테이블과 질의의 입력·출력을 알림으로 꾸립니다. 그리고 Kafka 의 ATLAS_HOOK 토픽에 넣습니다. 토픽은 Kafka 에서 메시지를 종류별로 나눠 담는 통입니다.

Atlas 서버는 이 토픽을 읽어 엔티티를 만들거나 고칩니다. 앞의 「계보」에서 본 작업 엔티티도 이렇게 생깁니다. 아래는 그 순서입니다.

sequenceDiagram
    participant Hive
    participant Kafka
    participant Atlas
    participant JanusGraph
    Hive->>Hive: 질의를 마치고 훅을 부른다
    Hive->>Kafka: 테이블과 입력·출력을 알림으로 넣는다
    Note over Hive,Kafka: Hive 는 Atlas 의 답을 기다리지 않는다
    Atlas->>Kafka: 알림을 읽는다
    Atlas->>JanusGraph: 엔티티와 계보를 적는다

Kafka 를 사이에 둔 덕분에 Hive 가 Atlas 에 묶이지 않습니다. Atlas 가 잠시 멈춰도 Hive 질의는 끝납니다. 알림은 Kafka 에 쌓였다가 Atlas 가 돌아오면 읽힙니다.

치르는 것은 늦음입니다. 테이블을 만든 직후 Atlas 에서 찾으면 아직 안 보일 수 있습니다. 훅을 붙이기 전부터 있던 테이블도 훅이 모릅니다. 이런 테이블은 Atlas 가 함께 내놓는 가져오기 스크립트로 한 번에 들여옵니다.

Atlas 는 HBase 나 Sqoop 같은 다른 하둡 도구에도 같은 꼴의 훅을 둡니다. Sqoop 은 관계형 데이터베이스의 표를 하둡으로 옮기는 도구입니다.

Atlas 분류로 권한을 거는 Ranger

Ranger 는 하둡 도구들의 접근 권한을 한곳에서 정하는 도구입니다. 「분석팀은 orders 를 읽을 수 있다」 같은 규칙을 둡니다. Hive 같은 도구 안에 Ranger 플러그인이 붙어서, 질의가 들어올 때마다 이 규칙을 확인합니다.

Ranger 에는 테이블 이름 대신 분류로 거는 규칙이 있습니다. 「PII 가 붙은 것은 보안팀만 읽는다」처럼 적습니다. 이 분류를 Atlas 에서 가져옵니다.

가져오는 방향은 Atlas 에서 Ranger 쪽입니다. Atlas 는 분류가 바뀔 때마다 Kafka 의 ATLAS_ENTITIES 토픽에 알립니다. 앞에서 Hive 훅이 알림을 넣던 ATLAS_HOOK 은 Atlas 가 받는 토픽입니다. ATLAS_ENTITIES 는 Atlas 가 내보내는 토픽입니다.

Ranger 쪽의 TagSync 라는 프로그램이 이 토픽을 읽어 Ranger 에 옮겨 적습니다. Ranger 는 질의마다 Atlas 를 부르지 않습니다.

이렇게 붙이면 새 테이블이 생길 때마다 권한 규칙을 고치지 않아도 됩니다. 분류가 계보를 따라 퍼지면 규칙도 그 테이블에 함께 걸립니다.

대신 분류를 단 순간과 규칙이 걸리는 순간 사이에 틈이 생깁니다. TagSync 가 멈추면 Ranger 는 마지막으로 받은 분류로 판정합니다. 분류를 잘못 떼면 그 데이터의 보호도 함께 풀립니다. 꼬리표 하나가 권한이 되므로 꼬리표를 다는 권한부터 좁게 둡니다.

Atlas 가 기록을 맡기는 HBase 와 Solr

Atlas 는 기록을 JanusGraph 를 거쳐 HBase 와 Solr 에 맡깁니다. 엔티티의 점과 선은 HBase 에 들어갑니다. 이름이나 분류로 찾는 데 쓰는 인덱스는 Solr 에 들어갑니다.

화면에서 검색하면 Solr 가 먼저 답합니다. 계보를 따라 선을 타는 일은 HBase 에서 읽습니다.

하둡을 이미 굴리는 회사라면 HBase 와 Solr 를 새로 배울 일이 적습니다. 운영 도구와 백업 절차도 하둡 쪽 것을 함께 씁니다.

치르는 것은 맞춰 살려야 할 부품의 수입니다. Atlas 가 돌려면 HBase, Solr, Kafka 가 모두 살아 있어야 합니다. HBase 와 Solr 가 어긋나면 HBase 에는 엔티티가 있어도 검색에는 안 나오는 일이 생깁니다. 그때는 HBase 의 기록으로 인덱스를 다시 만듭니다.

관련 항목

Apache Atlas 가 속하는 상위 분류

데이터 카탈로그 · 메타데이터 관리 · 데이터 거버넌스 · 데이터 엔지니어링 · 오픈 소스 · Apache Software Foundation

Apache Atlas 와 같은 역할을 두고 겨루는 데이터 카탈로그

DataHub · OpenMetadata · Amundsen · AWS Glue Data Catalog · Unity Catalog · Microsoft Purview

Apache Atlas 에 기록을 보내는 하둡 도구

Hadoop · Apache Hive · Hive 메타스토어 · HDFS · Apache Sqoop · Apache Storm · Apache Impala · Apache Spark

Apache Atlas 가 기록을 맡기는 저장소

JanusGraph · 그래프 데이터베이스 · HBase · Apache Solr · Elasticsearch · 인덱스

Apache Atlas 와 알림을 주고받는 통로

Apache Kafka · 토픽 · 훅 · 메시지 큐 · 이벤트 기반 아키텍처

Apache Atlas 분류를 받아 권한을 거는 도구

Apache Ranger · 태그 기반 접근 제어 · 접근 제어 · 속성 기반 접근 제어 · Kerberos

Apache Atlas 가 쌓는 메타데이터의 구성 요소

메타데이터 · 타입 · 엔티티 · 분류 · 비즈니스 용어집 · GUID · 스키마

Apache Atlas 가 제공하는 기능

데이터 계보 · 영향 분석 · 분류 전파 · 데이터 디스커버리 · 전문 검색 · DSL · REST · OpenLineage

Apache Atlas 로 가려내는 민감 정보

개인 식별 정보 · 개인정보 · 데이터 분류 · 감사 로그 · 보존 기간