데이터 플랫폼에 대해 생각할 때 사용 가능한 모든 서비스와 아키텍처 옵션을 고려하는 것은 약간 어려울 수 있습니다.
엔터프라이즈 데이터 플랫폼은 데이터 웨어하우스, 데이터 모델, 데이터 레이크 및 보고서로 구성되는 경우가 많으며 각각 특정 목적과 필요한 기술 집합이 있습니다. 이와 대조적으로 지난 몇 년 동안 데이터 레이크하우스라는 새로운 디자인이 등장했습니다.
데이터 레이크의 다양성과 데이터 웨어하우스 데이터 관리는 "데이터 레이크하우스"라는 혁신적인 데이터 스토리지 아키텍처에 결합됩니다.
구성 요소, 기능, 아키텍처 및 기타 측면을 포함하여 이 게시물에서 데이터 레이크하우스를 심층적으로 조사할 것입니다.
데이터 레이크하우스란?
이름에서 알 수 있듯이 데이터 레이크하우스는 데이터 레이크와 데이터 웨어하우스를 결합하여 각각의 단점을 개별적으로 해결하는 새로운 유형의 데이터 아키텍처입니다.
본질적으로, 레이크하우스 시스템은 데이터 레이크와 마찬가지로 대량의 데이터를 원래 형태로 유지하기 위해 저렴한 스토리지를 사용합니다. 저장소 상단에 메타데이터 계층을 추가하면 데이터 구조가 제공되고 데이터 웨어하우스에서 볼 수 있는 것과 같은 데이터 관리 도구가 강화됩니다.
조직 전체에서 사용되는 다양한 비즈니스 응용 프로그램, 시스템 및 장치에서 얻은 방대한 양의 조직화, 반구조화 및 비구조화 데이터를 저장합니다.
대부분의 경우 데이터 레이크는 파일 API(응용 프로그래밍 인터페이스)와 함께 저렴한 스토리지 인프라를 사용하여 데이터를 개방형 일반 파일 형식으로 저장합니다.
이를 통해 많은 팀이 데이터 과학, 데이터 과학, 기계 학습및 비즈니스 인텔리전스.
특징
- 저렴한 스토리지. 데이터 레이크하우스는 다음과 같은 저렴한 개체 스토리지에 데이터를 저장할 수 있어야 합니다. Google 클라우드 Storage, Azure Blob Storage, Amazon Simple Storage Service 또는 기본적으로 ORC 또는 Parquet 사용.
- 데이터 최적화 기능: 데이터 레이아웃 최적화, 캐싱 및 인덱싱은 데이터 레이크하우스가 데이터의 원래 형식을 유지하면서 데이터를 최적화할 수 있어야 하는 방법의 몇 가지 예입니다.
- 트랜잭션 메타데이터 계층: 필수적인 저비용 스토리지 외에 데이터 웨어하우스 성능에 중요한 데이터 관리 기능을 가능하게 합니다.
- 선언적 DataFrame API 지원: 대부분의 AI 도구는 DataFrame을 사용하여 원시 개체 저장소 데이터를 검색할 수 있습니다. 선언적 DataFrame API에 대한 지원은 특정 데이터 과학 또는 AI 작업에 대한 응답으로 데이터의 표현 및 구조를 동적으로 개선하는 기능을 향상시킵니다.
- ACID 트랜잭션 지원: 원자성(Atomicity), 일관성(Consistency), 격리(Isolation) 및 내구성(Durability)을 나타내는 약어 ACID는 트랜잭션을 정의하고 데이터의 일관성과 신뢰성을 보장하는 중요한 구성 요소입니다. 이러한 거래는 이전에는 데이터 웨어하우스에서만 가능했지만 Lakehouse는 데이터 레이크와 함께 사용할 수 있는 옵션을 제공합니다. 또한. 동시 데이터 읽기 및 쓰기를 포함한 여러 데이터 파이프라인을 통해 후자의 낮은 데이터 품질 문제를 해결합니다.
데이터 레이크하우스의 요소
데이터 레이크하우스의 아키텍처는 높은 수준에서 두 가지 주요 계층으로 나뉩니다. 스토리지 계층의 데이터 유입은 Lakehouse 플랫폼(즉, 데이터 레이크)에 의해 제어됩니다.
데이터를 데이터 웨어하우스에 로드하거나 독점 형식으로 변환할 필요 없이 처리 계층은 다양한 도구를 사용하여 스토리지 계층의 데이터를 직접 쿼리할 수 있습니다.
그러면 BI 앱과 AI 및 ML 기술이 데이터를 사용할 수 있습니다. 데이터 레이크의 경제성은 이 설계에 의해 제공되지만 모든 처리 엔진이 이 데이터를 읽을 수 있기 때문에 기업은 다양한 시스템에서 분석을 위해 준비된 데이터에 자유롭게 액세스할 수 있습니다. 처리 및 분석에 이 방법을 사용하면 프로세서 성능과 비용이 모두 향상될 수 있습니다.
다음 ACID(원자성, 일관성, 격리 및 내구성) 기준을 준수하는 데이터베이스 트랜잭션에 대한 지원으로 인해 아키텍처는 또한 많은 당사자가 시스템 내에서 동시에 데이터에 액세스하고 데이터를 쓸 수 있도록 합니다.
- 원자 성 트랜잭션을 완료하는 동안 전체 트랜잭션 또는 트랜잭션이 모두 성공하지 않는다는 사실을 나타냅니다. 프로세스가 중단되는 경우 데이터 손실이나 손상을 방지하는 데 도움이 됩니다.
- 일관성 트랜잭션이 예측 가능하고 일관된 방식으로 발생하도록 보장합니다. 모든 데이터가 미리 결정된 규칙에 따라 합법적임을 확인함으로써 데이터의 무결성을 유지합니다.
- 절연 완료될 때까지 트랜잭션이 시스템 내의 다른 트랜잭션에 의해 영향을 받지 않도록 합니다. 이를 통해 여러 당사자가 서로 간섭하지 않고 동일한 시스템에서 동시에 읽고 쓸 수 있습니다.
- 내구성 시스템 오류가 발생한 경우에도 트랜잭션이 완료된 후 시스템의 데이터 변경 사항이 계속 존재하도록 보장합니다. 거래로 인한 모든 변경 사항은 파일에 영원히 보관됩니다.
데이터 레이크하우스 아키텍처
Databricks(Delta Lake 개념의 혁신자이자 설계자)와 AWS는 데이터 레이크하우스 개념의 두 가지 주요 옹호자입니다. 따라서 우리는 레이크하우스의 건축적 배치를 설명하기 위해 그들의 지식과 통찰력에 의존할 것입니다.
데이터 레이크하우스 시스템에는 일반적으로 XNUMX개의 레이어가 있습니다.
- 수집 계층
- 스토리지 레이어
- 메타데이터 레이어
- API 계층
- 소비층
수집 계층
시스템의 첫 번째 계층은 다양한 소스에서 데이터를 수집하여 스토리지 계층으로 보내는 역할을 합니다. 계층은 다음과 같은 일괄 처리 및 스트리밍 데이터 처리 기능을 결합하는 것을 포함하여 수많은 내부 및 외부 소스에 연결하기 위해 여러 프로토콜을 사용할 수 있습니다.
- NoSQL 데이터베이스,
- 파일 공유
- CRM 애플리케이션,
- 웹 사이트,
- 사물인터넷 센서,
- 소셜 미디어,
- SaaS(Software as a Service) 애플리케이션 및
- 관계형 데이터베이스 관리 시스템 등
이 시점에서 데이터 스트리밍을 위한 Apache Kafka 및 RDBMS 및 NoSQL 데이터베이스에서 데이터를 가져오기 위한 Amazon Data Migration Service(Amazon DMS)와 같은 구성 요소를 사용할 수 있습니다.
스토리지 레이어
Lakehouse 아키텍처는 AWS S3와 같은 저렴한 객체 저장소에 다양한 유형의 데이터를 객체로 저장할 수 있도록 하기 위한 것입니다. 열린 파일 형식을 사용하면 클라이언트 도구가 상점에서 직접 이러한 항목을 읽을 수 있습니다.
이를 통해 많은 API 및 소비 계층 구성 요소가 동일한 데이터에 액세스하고 활용할 수 있습니다. 메타데이터 계층은 구성 요소가 데이터를 읽을 때 데이터에 적용할 수 있도록 구조화 및 반구조화 데이터 세트에 대한 스키마를 저장합니다.
예를 들어 HDFS(Hadoop Distributed File System) 플랫폼은 컴퓨팅과 스토리지를 온프레미스로 분할하는 클라우드 저장소 서비스를 구성하는 데 사용할 수 있습니다. Lakehouse는 이러한 서비스에 이상적입니다.
메타데이터 레이어
메타데이터 계층은 이 디자인을 구별하는 데이터 레이크하우스의 기본 구성요소입니다. 레이크에 저장된 모든 항목에 대한 메타데이터(다른 데이터 조각에 대한 정보)를 제공하고 사용자가 다음과 같은 관리 기능을 사용할 수 있도록 하는 단일 카탈로그입니다.
- ACID 트랜잭션 덕분에 동시 트랜잭션에서 일관된 버전의 데이터베이스를 볼 수 있습니다.
- 클라우드 개체 저장소 파일을 저장하기 위한 캐싱;
- 쿼리 처리 속도를 높이기 위해 인덱싱을 사용하여 데이터 구조 인덱스를 추가합니다.
- 데이터 개체를 복제하기 위해 무복제 복제를 사용합니다. 그리고
- 특정 버전의 데이터 등을 저장하려면 데이터 버전 관리를 사용하십시오.
또한 메타데이터 계층은 스키마 관리 구현, 별/눈송이 스키마와 같은 DW 스키마 토폴로지 사용, 데이터 레이크에서 직접 데이터 거버넌스 및 감사 기능 제공을 가능하게 하여 전체 데이터 파이프라인의 무결성을 향상시킵니다.
스키마 진화 및 시행을 위한 기능은 스키마 관리에 포함됩니다. 테이블의 스키마를 충족하지 않는 쓰기를 거부함으로써 스키마 적용을 통해 사용자는 데이터 무결성과 품질을 유지할 수 있습니다.
스키마 진화를 통해 테이블의 현재 스키마를 변경하는 데이터에 맞게 수정할 수 있습니다. 데이터 레이크 위에 있는 단일 관리 인터페이스로 인해 액세스 제어 및 감사 가능성도 있습니다.
API 계층
이제 모든 최종 사용자가 작업을 보다 빠르게 수행하고 보다 정교한 통계를 얻는 데 사용할 수 있는 여러 API를 호스팅하는 아키텍처의 또 다른 중요한 레이어가 있습니다.
메타데이터 API를 사용하면 주어진 애플리케이션에 필요한 데이터 항목을 쉽게 식별하고 액세스할 수 있습니다.
기계 학습 라이브러리 측면에서 TensorFlow 및 Spark MLlib와 같은 일부는 Parquet과 같은 개방형 파일 형식을 읽고 메타데이터 계층에 직접 액세스할 수 있습니다.
동시에 DataFrame API는 최적화 가능성을 높여 프로그래머가 분산된 데이터를 구성하고 변경할 수 있도록 합니다.
소비층
Power BI, Tableau 및 기타 도구와 앱은 소비 계층에서 호스팅됩니다. 레이크하우스 설계를 통해 레이크에 보관된 모든 메타데이터와 모든 데이터는 클라이언트 앱에서 액세스할 수 있습니다.
Lakehouse는 회사 내의 모든 사용자가 모든 종류의 작업을 수행하는 데 사용할 수 있습니다. 분석 작업, 비즈니스 인텔리전스 대시보드 생성, SQL 쿼리 및 기계 학습 작업 실행을 포함합니다.
데이터 레이크하우스의 장점
조직은 데이터 레이크하우스를 만들어 현재 데이터 플랫폼을 통합하고 전체 데이터 관리 프로세스를 최적화할 수 있습니다. 다양한 소스를 연결하는 사일로 장벽을 해체함으로써 데이터 레이크하우스는 개별 솔루션의 필요성을 대체할 수 있습니다.
선별된 데이터 소스와 비교하여 이 통합은 훨씬 더 효과적인 종단 간 절차를 생성합니다. 여기에는 몇 가지 장점이 있습니다.
- 적은 관리: 원시 데이터에서 데이터를 추출하고 데이터 웨어하우스 내에서 사용할 준비를 하는 대신, 데이터 레이크하우스를 사용하면 연결된 모든 소스에서 데이터를 사용할 수 있고 활용할 수 있도록 구성할 수 있습니다.
- 비용 효율성 향상: 데이터 레이크하우스는 컴퓨팅과 스토리지를 분리하는 현대적인 인프라를 사용하여 구축되므로 컴퓨팅 파워를 높이지 않고도 스토리지를 간단하게 확장할 수 있습니다. 저렴한 데이터 스토리지를 사용하는 것만으로도 비용 효율적인 확장성을 얻을 수 있습니다.
- 더 나은 데이터 거버넌스: 데이터 레이크하우스는 표준화된 개방형 아키텍처로 구성되어 보안, 메트릭, 역할 기반 액세스 및 기타 중요한 관리 구성 요소를 더 많이 제어할 수 있습니다. 리소스와 데이터 소스를 통합하여 거버넌스를 단순화하고 강화합니다.
- 단순화된 표준: 데이터 웨어하우스가 처음 개발되던 1980년대에는 연결이 매우 제한되어 있었기 때문에 기업 내부, 심지어 부서에서도 현지화된 스키마 표준이 자주 개발되었습니다. 데이터 레이크하우스는 절차를 간소화하기 위해 중복되는 균일한 스키마가 있는 수많은 데이터 소스를 수집함으로써 많은 유형의 데이터가 스키마에 대한 개방형 표준을 갖는다는 사실을 활용합니다.
데이터 레이크하우스의 단점
데이터 레이크하우스를 둘러싼 온갖 난리에도 불구하고 이 아이디어는 여전히 매우 새롭다는 점을 명심하는 것이 중요합니다. 이 새로운 디자인에 완전히 전념하기 전에 단점을 저울질해 보십시오.
- 모놀리식 구조: 레이크하우스의 올인클루시브 설계는 여러 가지 장점을 제공하지만 몇 가지 문제점도 내포하고 있습니다. 모놀리식 아키텍처는 종종 모든 사용자에게 열악한 서비스를 제공하며 경직되고 유지 관리하기 어려울 수 있습니다. 일반적으로 건축가와 디자이너는 다양한 사용 사례에 맞게 사용자 지정할 수 있는 모듈식 아키텍처를 선호합니다.
- 아직 기술이 부족하다.: 최종 목표는 상당한 양의 머신 러닝과 인공 지능을 수반합니다. Lakehouses가 계획한 대로 작동하려면 이러한 기술이 더 발전해야 합니다.
- 기존 구조에 비해 크게 발전하지 않음: Lakehouses가 실제로 얼마나 더 많은 가치를 제공할 것인지에 대해서는 여전히 상당한 회의론이 있습니다. 일부 반대론자들은 적절한 자동화 장비와 함께 호수 창고 설계가 비슷한 효율성을 달성할 수 있다고 주장합니다.
Data Lakehouse의 과제
데이터 레이크하우스 기법을 채택하는 것은 어려울 수 있습니다. 구성 요소의 복잡성으로 인해 데이터 레이크하우스를 모든 것을 포괄하는 이상적인 구조 또는 "모든 것을 위한 하나의 플랫폼"으로 보는 것은 잘못된 것입니다.
또한 데이터 레이크의 채택이 증가함에 따라 기업은 현재의 데이터 웨어하우스를 해당 데이터 웨어하우스로 이전해야 하며 입증 가능한 경제적 이익 없이 성공에 대한 약속에만 의존해야 합니다.
전송 프로세스 전반에 걸쳐 지연 문제나 중단이 있는 경우 비용이 많이 들고 시간이 많이 걸리며 안전하지 않을 수 있습니다.
솔루션을 데이터 레이크하우스로 명시적 또는 암시적으로 마케팅하는 특정 공급업체에 따르면 비즈니스 사용자는 고도로 전문화된 기술을 수용해야 합니다. 이것들은 시스템 중앙에 있는 데이터 레이크에 연결된 다른 도구와 항상 작동하지 않을 수 있어 문제를 가중시킵니다.
또한 비용 효율적인 확장성을 갖춘 인프라가 필요한 비즈니스 크리티컬 워크로드를 실행하는 동안 연중무휴 분석을 제공하기 어려울 수 있습니다.
결론
최근 몇 년 동안 가장 새로운 다양한 데이터 센터는 데이터 레이크하우스입니다.. 정보 기술, 오픈 소스 소프트웨어, 클라우드 컴퓨팅, 분산 스토리지 프로토콜.
이를 통해 기업은 모든 위치에서 모든 종류의 데이터를 중앙 집중식으로 저장할 수 있으므로 관리 및 분석이 간소화됩니다. Data Lakehouse는 매우 흥미로운 개념입니다.
데이터 웨어하우스만큼 빠르고 효율적이며 데이터 레이크만큼 유연하면서도 올인원 데이터 플랫폼에 액세스할 수 있다면 어떤 기업이든 상당한 경쟁력을 갖게 될 것입니다.
이 아이디어는 여전히 개발 중이며 비교적 새로운 상태로 남아 있습니다. 결과적으로 무언가가 널리 퍼질 수 있는지 여부를 결정하는 데 시간이 걸릴 수 있습니다.
우리 모두는 Lakehouse 아키텍처가 향하고 있는 방향에 대해 궁금해해야 합니다.
댓글을 남겨주세요.