데이터 레이크란?
데이터 레이크는 모든 유형의 데이터를 저장할 수 있는 중앙 집중식 저장소를 의미합니다.
또한 대규모로 수집, 저장, 처리할 수 있는 아키텍처를 제공합니다.
이를 통해 다양한 데이터 소스를 한곳에 통합하고, 유연하게 분석하거나 활용할 수 있습니다.
Hadoop (YARN + HDFS) vs Kubernetes
Resource Manager의 종류는 YARN, Mesos, Kubernetes가 있습니다.
주로 YARN 혹은 Kubernetes를 쓰게 되는데 요즘 추세로 보았을 때 탈 하둡을 하려는 경향이 있어 주로 Kubernetes를 쓰려는 경향이 있는 것 같습니다.
그렇다면 비교했을 때 어떤 장단점들이 있는지 살펴보도록 하겠습니다.
- 운영 효율성
Hadoop 클러스터의 관리 및 운영은 매우 복잡하여 유지보수시에도 많은 비용이 들게 됩니다.
심지어 Cloudera 유료화로 Ambari의 업데이트가 끊긴 상태에서 더욱이나 쓰기 어려워졌습니다.
그에 비해 Kubernetes의 경우 쉽게 띄울 수 있도록 Helm Chart들도 제공하고 있으며, Devops 엔지니어 분들과도 함께 협업이 가능하다는 점에서 매우 큰 장점을 갖습니다.
- 의존성
Hadoop을 사용하게 되면서 HDFS의 의존성이 커집니다.
HDFS의 NameNode가 SPOF가 될 수도 있으며, small files에 대한 이슈도 생길 수 있습니다.
또한 클라우드 네이티브 하지 못한다는 점에서도 단점을 갖고 있습니다.
- 오픈 소스 생태계
많은 오픈 소스 프로젝트가 클라우드 네이티브 환경을 더 많이 지원합니다
Migration 용을 위해 많은 오픈 소스에서 하둡 관련 옵션들도 많이 지원하지만 제약이 생기고 있고 Hadoop의 장점이 점차 희미해지고 있습니다.
그럼에도 하둡은 아직 건재하다고 할 수 있습니다.
많은 클라우드 서비스에서 SaaS를 지원할 때 여전히 하둡 클러스터를 가지고 제공하고 있습니다.
또한 Impala를 Trino와 비교해봤을 때 Impala 자체의 속도가 매우 빠르다고 합니다.
아직 레거시라고 할 정도의 수준은 아니며 많은 회사에서도 하둡으로 운영하고 있으며 하둡 에코 시스템들에서도 발전해가고 있습니다.
결론적으로, Hadoop은 여전히 건재하지만, Kubernetes의 클라우드 네이티브 기술이 점점 더 많은 주목을 받고 있습니다.
저는 Kubernetes 환경에서 데이터 레이크를 구축해보았는데, 어떤 오픈 소스들을 사용했는지 살펴보겠습니다.
수집 - SeaTunnel
“데이터 플랫폼은 춘추 전국 시대다.” 라는 말이 있습니다.
이는 데이터 기술 스택에 정답이 없으며, 각 회사가 상황에 맞게 다양한 기술을 사용하고 있다는 점에서 나온 표현입니다.
데이터 베이스라던지 파일 포맷, 테이블 포맷까지 정말 다양한 형태를 띄고 있습니다.
다양한 데이터들을 수집하는 데 있어서 SeaTunnel을 사용하게 됐습니다.
SeaTunnel은 Source → Transform → Sink 3단계를 거치는데, 어떤 데이터를 가져올 것인지 Source를 기준으로 해당 데이터를 가공할 수 있는 Transform 이후 어느 데이터로 적재를 할 것인지 Sink로 도착하게 됩니다.
Transform의 경우 join과 같은 복잡한 쿼리까지는 작동되지 않으나, 간단하게 데이터를 변환할 수 있습니다.
Source와 Sink의 경우 각각 데이터 소스 별 Connector가 존재하여 매우 다양한 데이터 소스들을 지원합니다.
CDC의 경우에도 지원을 하는데, debezium을 기반으로 구현돼 있어 DB를 추적하면서 데이터를 쌓을 수 있게 됩니다.
그리고 저는 최종 데이터인 Sink로써 Iceberg를 사용하였는데, 24년 4월 기준으로 2.3.5에 Release가 되어 Iceberg 형태로 데이터를 적재할 수 있게 됐습니다.
다양한 데이터 소스들을 처리하는데 자원이 많이 소모된다면 SeaTunnel을 사용해보는 것을 추천드립니다.
스토리지 - Ozone
On-Premise 환경이므로 클라우드 스토리지인 S3를 사용할 순 없었고, 저는 Apache Ozone 를 선택하게 됐습니다.
Ozone은 기존 HDFS Repository에서 다른 분기점으로 개발돼 현재 Object Storage로 역할을 하고 있습니다.
HDFS와도 Compatible한 ofs / o3fs 를 지원하며 S3와 Compatible한 s3g 를 지원합니다.
HDFS에서 가지고 있었던 Name Node 문제를 Ozone Manager 와 Storage Container Manager 로 기능을 분리하여 SPOF문제를 해결하였습니다.
그리고 HDFS와 다르게 Cloud-Native하며 쿠버네티스 환경에도 원활하게 동작되도록 설계돼 있습니다.
Trino에서 Ozone Native하게 코드를 작성할 수 있도록 도와주진 않았는데, Trino github에 PR까지 작성돼 있었지만, Ozone의 s3g으로도 접근이 가능하기 때문에 Closed 처리됐습니다.
그렇기 때문에 저는 Ozone을 사용할 때 다른 곳에서 모두 s3g을 접근하도록 하였습니다.
일반적으로 S3를 쓰는 추세로 s3g을 통한다면 다른 오픈 소스들과도 호환이 될 것이라 생각합니다.
테이블 포맷 - Iceberg
Iceberg는 테이블 포맷으로, parquet를 기반으로 파일을 저장합니다.
대용량 데이터 셋을 효율적으로 분석할 수 있도록 도와주며 Hadoop, Spark, Trino 등 빅데이터 처리 엔진과 함께 사용하여 대규모 데이터를 안정적으로 처리할 수 있는 기능들을 제공합니다.
Iceberg를 사용하기 위해 Catalog를 설정하는 것이 있습니다.
- REST
- JDBC
- Hive Metastore
- Nessie
- Glue, ...
Iceberg는 많은 형태의 Catalog를 지원하는데 REST, JDBC, Nessie 제외하고 웬만하면 특정 플랫폼들을 위한 설정이라고 보시면 될 것 같습니다.
Hive 같은 경우에도 기본적으로 Migration을 위한 옵션으로 아직 많은 사람들이 쓰기 때문에 존재하는 듯 합니다.
그렇기 때문에 구축을 시작하는 입장이라면, REST 혹은 JDBC를 권장하며 REST의 경우도 결국 내부적으로 무슨 Catalog를 사용할 것인지 지정하게 됩니다.
REST를 사용하는 이유는 Oauth, Load Balancing 등 추가 이점이 있기 때문입니다.
그리고 같은 기능을 하는 것으로 Hive가 있는데 비교해보도록 하겠습니다.
Hive 다른 점
- Hive는 테이블 메타데이터를 MetaStore DB (RDB) 에 저장
- Schema 구조 변경 시 전체 데이터 파일 rewrite
- HDFS와 사용시 small files issue로 namenode 부하
- 복잡한 Table 구조
Hive와 크게 다른 점은 file로 관리한다는 점입니다.
메타데이터의 경우에도 Hive는 RDB에 저장을 하지만, iceberg는 file로 관리하며 스냅샷까지 관리하기 때문에 용이성이 있습니다.
그리고 스냅샷을 적용하기 때문에 스키마 구조 변경 또한 용이한데, Hive의 경우 스키마 구조 변경시 rewrite 하지만, Iceberg의 경우 스냅샷을 저장해 필요한 부분만 고쳐쓰게 됩니다.
그리고 추가적인 Iceberg의 장점을 알아보도록 하겠습니다.
- Hidden Partitioning
- Time Travel (SCD)
- Snapshot
- ACID
- Upsert
위와 같은 기능들까지 제공을 하기 때문에 Hive를 쓰는 게 아닌 Iceberg를 쓰는 것은 선택이 아닌 권장사항으로 보여집니다.
분석 엔진 - Spark / Trino
분석 엔진으로 Spark와 Trino 2개를 쓰는 것을 선택하였습니다.
Spark의 경우 배치성을 위한 엔진이며 Trino는 Interactive 쿼리를 작성하기 위한 용도로 쓰고 있습니다.
