background

objective

Self-data-serve 환경을 위한 데이터 도구들을 제공합니다.

howto

flowchart TB
    subgraph data["Storage Layer"]
        external_data[(외부데이터)]
        bigquery[(BigQuery)]
        subgraph rds["내부 데이터"]
            instance1[("exchange")]
            instance2[("account")]
            instance3[("wallet")]
        end
    end

    subgraph platform["Self Serve Layer"]
        direction TB
        mageai[MAGE]
        airbyte[Airbyte]
        datahub[Datahub]
    end

    %% single node %%
    user

    %% external_data --> |extract| airbyte %%
    %% rds --> |insgest| datahub %%
    user --> |use| platform
    platform --> |load & transform| data
    %% mageai -.- bigquery %%
Airbyte 도입 배경 (Airfow 와 비슷하지 않아요?)

  • 배경: Airflow / 자체 구현한 수집 엔진으로 ELT 파이프라인을 구성했습니다. 대상은 거래소 서비스에서 발생한 데이터 였어요. 그러다 전사에서 외부 데이터를 보고 싶은 니즈가 생겼습니다. 예를 들어, 국내 5대 거래소의 거래대금이나 혹은 CMC 로 각 가장자산별 볼륨 등이요.
  • Airbyte?: Open-Source Data Integration Platform 이라고 설명합니다. 맞아요. 정작 사용해보면 엄청나게 많은 기능을 제공합니다(Source/Target 지정한 커넥션의 스케줄 지정 -> 실행하면 파이프라인 생성). 그 중에 Python Connector Development Kit, CDK 에 대한 인터페이스가 훌륭했어요. 그 중에서도 HTTP-API-based Connector 가 눈에 띄었고, 확인해보니 잘 설계되었고 금방 외부데이터를 수집할 수 있을거라 기대했어요.
  • 그럼 왜?: 내부 거래소 데이터가 아닌 외부 데이터라 자체 엔진을 개발하면 신뢰성 높은 파이프라인을 제공하기 어려웠습니다. 우리 파이프라인은 문제 없지만 외부 데이터 프로바이더에서 문제라도 생기면? 완벽히 제공하는 건 불가능하다 생각했어요. 빠른 시일내에 딜리버리해야 했습니다. 기간을 맞추기에는 수집기를 직접 개발한다면 로직에 허점이 많을거라 판단했어요. (그만큼 HTTP API based Connector 가 견고하게 디자인되었구요!)
  • 결론: 주어진 기한내에 견고한 외부 데이터 수집을 위해 HTTP API 기반 커넥터를 쉽게 구성할 수 있는 Airbyte 를 이용했습니다.

result

keytakeaway

more

Airbyte 차트 구성하기 (oauth2 & 커넥터 관리)