Snowflake로 Datalake 워크로드 확장1

데이터 레이크 아키텍처 소개

우리가 현재 살고있는 시대는 IoT, 소셜 미디어의 급속한 발전으로 생성되는 기하 급수적으로 증가하는 데이터 시대에 살고 있습니다. 이제 모든 기업 환경에서 Data Lake는 중요한 시스템 중의 하나 입니다. 하지만, “모든 기업 환경에서 데이터 레이크가 무엇인지 정확히 이해하고 활용하고 있는가?”라는 의문이 생깁니다. 데이터 레이크 플랫폼을 구축하기 전에 데이터 레이크의 기본 사상을 명확하게 이해하는 것이 도움이 될 것 같습니다.

데이터 레이크가 등장 하게 된 배경은 정보계 시스템을 출현과 발전 방향을 살펴볼 필요가 있습니다.

일반적으로 기업 환경에 존재하는 EDW 시스템은 여러 업무 시스템에서 생성되는 정형 데이터를 통합하여 배치 기반으로 분석하는 용도로 고안되었습니다. EDW 시스템은 태생적으로 정형데이터를 분석하는 용도로 구현이 되었으며, 현재 On-Premise 환경에서 공급되는 EDW 솔루션은 대용량 데이터 분석 성능을 개선하기 위한 목적으로 고가의 Appliance 형태로 제공되고 있습니다. 하지만 고가의 솔루션이 채택한 아키텍처는 오늘날 분석 요구사항을 제대로 수용하지 못하는 Side Effect를 야기하게 됩니다. 즉, 1) 대용량 데이터 분석 요구 사항(데이터 확장성 포함), 2) 사전에 정의되지 않은(Mart로 생성되지 않음) 업무 수용의 Agility(원천 데이터: RAW 데이터를 저장하는 방식이 아닌 ETL로 가공된 데이터를 저장), 3) 반정형 및 비정형 데이터를 수용 불가

때문에, 웹로그 기반으로 구현 가능한 추천 시스템,제조 라인과 같은 IoT 디바이스에서 생성되는 머신 데이터 분석 활용 및 오늘날 다양한 업무시스템에서 생성되는 JSON과 같은 반정형 데이터를 분석 용도로 활용하기 위해서는 빅 데이터 기술(Hadoop)을 기반으로 한 Data Lake 시스템을 별도로 구축을 할 필요가 생겼습니다.

데이터 레이크의 정의는 “데이터의 고정된 제한 없이 많은 양의 정형, 반정형 및 비정형 데이터를 기본 형식(RAW Data)으로 저장하고, 원천 데이터를 기반으로 급변하는 다양한 비즈니스 요구사항에 맞게 데이터를 가공하여 사용하는 플랫폼"으로 정의할 수 있을 것 같습니다.

데이터 레이크의 기본 특성은 다음과 같습니다:

1. 데이터 레이크에는 기업 내의 모든 데이터를 저장할 수 있는 충분한 데이터 저장 용량이 필요합니다.
2. 데이터 레이크는 정형, 반정형 및 비정형 데이터를 포함하여 모든 유형의 데이터를 저장할 수 있습니다.
3. 데이터는 비즈니스 시스템에서 수집된 원시 데이터(RAW Data)입니다.
4. 데이터 레이크에는 배치 처리, 스트리밍 처리, 대화형 분석 및 AI/ML 분석과 같은 다양한 워크로드가 혼용되어 처리될 수 있습니다.

데이터 레이크가 기업 환경에 공격적으로 도입이 되면서, 대부분의 기업 환경에 분석 데이터 플랫폼은 다음과 같은 Hybrid Architecture로 구축되어 운영되고 있습니다. 이 아키텍처의 특성은 다음 두 가지로 정의됩니다:

1. 정형 데이터는 EDW로 통합 및 Data Lake에서 생성되는 반/비정형 데이터를 기반으로 생성된 Model 데이터를 EDW 업무로 수용
2. 반/비정형 데이터는 Data Lake로 통합 및 반/비정형 데이터 가공을 위해 필요한 참조 데이터(정형 데이터)는 EDW로 부터 동기화

오픈 소스 진형에서 주도 했던 1세대 빅 데이터 기반의 데이터 레이크 플랫폼은 불과 10년 전에 불가능하게 간주 되었던 대 용량의 데이터 분석, 정형 데이터가 아닌 데이터(반 정형 및 비정형)를 분석 용도로 활용할 수 있게 했다는 점은 분명히 높게 평가되어야 합니다.

하지만 지금은 On Premise(1세대 데이터 레이크)/ Public Cloud(2세대 데이터 레이크)에서 논의되는 데이터 레이크가 올바른 방향으로 진화되고 있는지 살펴볼 시점이 된 것 같습니다.

2006년 더그 커팅과 마이크 캐퍼렐라가 구글의 논문에 영감을 얻어 개발한 HDFS / Map Reduce 기술은 대 용량 데이터를 활용할 수 있다는 확신을 갖게 했습니다. 하지만 MapReduce와 같이 프로그램을 통해 처리 가능한 제약사항 및 엔터프라이즈 환경의 요구사항들을 충족하기 위한 목적으로 오른쪽 그림과 같이 다양한 하둡 에코 시스템들을 출시하게 되었습니다. 엔터프라이즈 수준의 요구사항은 충족할 수 있게 되었지만, 여러 에코 프로젝트간의 호환성 이슈, 시스템 아키텍처 복잡도 증가, 특정 기술-셋을 가진 전문가에 의존적인 시스템 등의 해결지 못한 여러 과제들을 남긴 것도 사실입니다.

때문에 대체제가 존재하지 않기 때문에 불변할 것 같은 시스템도 10년간의 성장 과정을 거치면서 2018년 이후로 사장되고 있습니다.

지금 우리는 Public Cloud 환경의 2세대 데이터 레이크 환경에 살고 있습니다.

Public Cloud 기반의 2세대 데이터 레이크 아키텍처에서 주목해야 하는 점은 1) Storage와 Computing이 밀겹합되어 있었던 아키텍처가 Storage와 Computing이 분리된 아키텍처와 2) 과거 On-Premise 환경에서 데이터 저장소 역할을 담당했던 HDFS가 S3, Blob Storage, GCS와 같은 Object Storage로 변경된 것입니다. 이 변화로 데이터 가용성을 위해 필요 3 copy replication과 데이터 노드 증설을 위해 필요 했던 스토리지 모니터링 및 Cluster Resizing & Relanacing 작업이 불 필요해졌습니다. 이와 같은 개선은 굉장히 진보된 것으로 평가해야 합니다.

하지만, 과거 On-Premise 환경에서 존재했던 다음과 같은 이슈들이 해결 되는지 살펴볼 필요가 있습니다.

1. 동일한 사용자 경험을 제공하는가? 아니면 아직도 여러 에코 시스템(Public Cloud에서는 여러 Plug-in 서비스)을 그대로 활용하고 있는가?
2. 특정 전문가들에게 의존적인 시스템이 아닐까?
3. Small File Problem는 해결되었나?
4. Hive Metastore에 제약 사항(메타 정보가 많아 지고 File Block 정보가 많아지는 경우): Hive Metastore의 Repository 성능 제약 사항으로 메타 정보가 많아 지면 기하 급수적으로 성능 저하 현상이 발생

노트: Hive Metastore는 분석을 위해 생성된 파일(일반적으로 Parquet / ORC 데이터 포멧으로 생성)들에게 SQL 기반으로 분석을 가능하게 하기 위해 정형화(테이블 스키마)하기 위해 필요. Hive Metastore의 Repository DB로 일반적으로 MySQL과 같은 데이터 베이스를 활용

동일한 사용자 경험 및 에코 프로젝트간 복잡도를 AWS Data Lake Stack을 참조하여 살펴보도록 하겠습니다. 다음 표와 같이 복잡도가 해결 되었나요? 아니면 서비스의 이름만 변경되고 그대로 유지가 되는 것은 아닌가요?

첫째, 위와 같이 다양한 Service Stack으로 데이터 레이크를 구성되었다는 것은 Public Cloud 환경으로 마이그레이션을 하더라도 클라우드의 데이터 레이크 아키텍처는 여전히 복잡하며, 특정 전문가들에 의존적인 시스템일 수 밖에 없습니다.

둘째, 가장 해결하기 어려운 데이터 규모가 커질 수록 빈번하게 발생되는 Small File Issue 및 Hive Metastore 성능저하 현상은 여전히 해결하기 여러운 과제입니다.

셋째, EDW와 Data Lake 시스템 간의 데이터 동기화 이슈(참조 데이터: EDW => Data Lake, 모델 데이터: Data Lake => EDW)는 Public Cloud 환경에서도 동일하게 발생합니다.

마지막으로, Databricks에서 논의하는 레이크 하우스를 살펴보도록 하겠습니다.

Apache Spark는 기존 Big Data 에코 프로젝트에서 가장 진보된 기술-셋트로 대용량 데이터를 메모리 기반으로 빠르게 처리 가능하며, 그 영역이 Spark Streaming, Spark SQL 및 Spark Mllib 기반의 AI/ML 영역으로 확대 적용하고 있습니다. 오랜 기간 동안 다양한 업무 영역에 적용을 하면서, 1) 대용량 데이터 처리가 필요한 Data Engineering 분야 및 2) MLFlow와 같은 다양한 서비스 기능이 추가된 AI/ML 영역에는 어느 정도 그 효용성이 입증 되었습니다. Lakehouse는 Apache Iceberg와 유사하게 기존 파일 기반의 대용량 데이터 처리 방식에서 SQL 기능이 강화된 DW 영역으로 발전을 원하고 있습니다.

개인적인 의견은 “파일 기반의 대용량 데이터 솔루션이 EDW의 복잡한 요구 사항을 완벽하게 대체할 수 있을까?”라는 의구심을 가지고 있습니다. 파일 기반의 처리 시스템은 태생 자체가 DBMS가 아니기 때문입니다. 극단적인 비유 일 수도 있겠지만, 1층 주택을 기초 공사를 하지 않고 바로 10층 짜리 빌딩으로 리모델링 한 것 같은 효과가 아닐까요? 앞으로 Lakehouse가 어떤 방향으로 발전 되는지 주의 깊게 관찰할 필요가 있을 것 같습니다.

지금까지 1세대 및 2세대 Data Lake의 발전 방향과 도전 과제에 대해서 알아 봤습니다. 다음에는 Snowflake의 Data Lake 전략을 살펴보도록 하겠습니다.