안녕하세요, 박민재입니다. 혹시 Data Discovery에 중요성을 느껴, DataHub를 사용하려고 하시는 분이 있나요? 아마 그렇다면 DataHub를 도입한 사례를 몇 개 읽어 보셨을꺼라 생각합니다. 대표적으로 국내 기업에서는 뱅크샐러드, 소카, 베이글코드 등에서 성공적으로 도입한 사례들을 회사 사이트에 올리는 경우를 확인 할 수 있었어요.
DataHub는 구성원이 사용하기 좋게 Metadata가 잘 Ingestion 되고, 이를 구성원들이 적극적으로 잘 이용해 준다면, 조직의 Data Discovery에 있어 매우 훌륭한 툴입니다. 하지만, 실제 이를 운영하는 개발자들이 겪는 애로 사항은 전혀 다른 이야기 입니다. 저는 이번 글을 통해 On-Prem 환경에서 DataHub를 적용한 과정 중 겪은 애로사항에 대해서 설명 드리도록 하겠습니다.
DataHub는 자유도가 매우 높은 프로젝트 입니다. 개발자가 손쉽게 DataHub에서 제공하지 않는 Metadata를 추가 할 수 있고, Web UI로 수정할 수 있는 가이드를 제공 합니다. 관련 링크
우선 DataHub의 프로젝트 구성을 확인 해 보면 Metadata를 표현 하는데 있어, Dataset, DataJob과 같은 정보를 표현하는 Entity와 Entity에 Metadata 정보를 추가해 주는 Aspect의 개념으로 나뉘어 DataHub에 Push 하는 형태 입니다. 관련 링크
그런데 여기서 슬픈 사실이 있습니다. Aspect를 추가 하는데 있어 정합성을 확인 하지 않습니다.
만약, Dataset Entity에 Tag를 추가 하기 위해 GlobalTag Aspect를 추가 한다고 가정 하겠습니다. 이 과정에서 Python SDK에서 제공해 주는 Emitter 에서는 실제 Tag가 존재하는 확인 하지 않습니다. 일단 Aspect를 추가 하고, Web UI 상에서는 Tag가 추가 되지만, 해당 태그를 수정 하려고 할 때, Internal Error가 발생하는... 곤란한 상황이 펼쳐지게 됩니다.
혹은, Entity에 GlobalTag Aspect를 추가 한다고 하면, 기존에 Web UI에서 적용 했던 Tag는 삭제 되는 등의 이슈가 있었어요. 그 이유 때문에, GlobalTag를 적용하려는 Entity에 적용되어 있는 기존 Tag는 어떤 것이 있는지 비교 하며 Metadata를 적용 하여야 했어요.
DataHub와 다른 데이터 플랫폼의 Integration (Airflow, Spark, Kafka, Hive 등)을 위해, 기존 제공하는 Plugin을 사용하기가 어려울 때, Python Emitter를 직접 사용하게 되는 데요, 이를 위해서 다음과 같은 원칙을 준수하여 Emitter를 개발 하는 것이 제 경험 상 좋았습니다.
DataHub가 Star 10k가 넘어가는, 사람들이 많이 사용하는 Open Source로 여겨지기 때문에 Plugin의 안정성이 보장 되었다고 생각 할 수 있습니다. 하지만, 생각보다 자잘한 이슈들이 많습니다.
대표적으로 DataHub Airflow Plugin 관련된 이슈가 생각나는데요, DataHub Airflow Plugin은 Airflow Listener API를 사용합니다. Airflow Listener API는 Airflow Scheduler의 동작에 영향을 줄 수 있는 API라 사용에 주의 하여야 합니다.
어느날은 DataHub가 다운이 된 적이 있었는데, Airflow Listener API를 사용하는 Airflow도 Request Timeout으로 인해 함께 다운이 되었던 경험이 있었습니다. Airflow Plugin은 Airflow Task 동작 하나하나를 DataProcess Entity Type으로 DataHub에 Push 하다 보니, MySQL이 다운되고, 이에 따라서 DataHub 서버가 다운 되고, DataHub를 연동한 Airflow도 Scheduler 단에서 Request Timeout이 발생 하여 다운 된 흐름이었습니다. Kafka도 Retention을 넉넉하게 주지 않았을 때 발생 하는 문제도 있었고요.
그래서, DataHub Airflow Plugin을 비활성화 하고, Airflow의 DagBag을 직접 호출하여 Python SDK로 Ingestion 하는 DAG을 생성 하는 방법으로 임시적으로 해결 하였습니다. Airflow가 DataHub의 직접적인 영향을 받는 것을 피하기 위함이었어요.
FYI) DataHub Helm Chart는 Kubernetes Cluster에 적은 리소스로 Kafka, MySQL, ElasticSearch를 설치 합니다. 더 큰 리소스가 필요 하다면, Kubernetes Cluster 외부에 더 큰 사이즈로 DB를 생성 하여 연결 하는 것을 추천드리요. 위의 상황은 PoC를 수행하다가 발생 한 이슈인데요, 실제 Prod 환경에 배포를 하게 된다면, DB 분리 + Monitoring을 꼭 수행 해 주세요.
DataHub에서 많은 Data Platform과의 연동을 지원 해 줍니다. 하지만, 대부분 AWS, GCP와 같은 Cloud 환경에서, 혹은 DataBricks, SnowFlake 등을 사용하는 환경에서의 호환성은 잘 보장해 주지만, On-Prem 처럼 Platform Engineering 팀에서 제공하는 내부 Platform을 이용하는 경우. 호환 되지 않을 가능성이 높습니다. 그렇기 때문에, Python SDK의 사용법에 익숙해져, 주기적으로 Airflow 와 같은 Tool을 이용하여 Metadata를 Ingestion 하는 것이 좋습니다.