우리가 보는 데이터 레이크
iQiyi의 데이터 센터 팀으로서 우리의 핵심 임무는 회사 내의 수많은 데이터 자산을 관리하고 서비스하는 것입니다. 데이터 거버넌스를 구현하는 과정에서 우리는 계속해서 새로운 개념을 흡수하고 최첨단 도구를 도입하여 데이터 시스템 관리를 개선합니다.
'데이터 레이크'는 최근 데이터 분야에서 폭넓게 논의되는 개념으로, 기술적인 측면 역시 업계에서 폭넓은 관심을 받고 있다. 우리 팀은 데이터 레이크가 데이터 관리에 대한 새로운 관점일 뿐만 아니라 데이터 통합 및 처리를 위한 유망 기술이라고 믿습니다.
데이터 레이크는 데이터 거버넌스의 아이디어
데이터 레이크를 구현하는 목적은 데이터의 사용 편의성과 가용성을 새로운 차원으로 끌어올리는 효율적인 저장 및 관리 솔루션을 제공하는 것입니다.
혁신적인 데이터 거버넌스 개념으로서 데이터 레이크의 가치는 주로 다음 두 가지 측면에 반영됩니다.
1. 데이터의 사용 여부와 관계없이 모든 데이터를 종합적으로 저장할 수 있는 능력은 필요할 때 필요한 정보를 쉽게 찾을 수 있도록 보장하고 업무 효율성을 향상시킵니다.
2. 데이터 레이크의 데이터는 과학적으로 관리, 정리되어 있어 사용자가 스스로 쉽게 데이터를 찾고 이용할 수 있습니다. 이 관리 모델은 데이터 엔지니어의 개입을 크게 줄여 사용자가 스스로 데이터 검색 및 사용 작업을 완료할 수 있으므로 많은 인적 자원을 절약할 수 있습니다.
모든 유형의 데이터를 보다 효과적으로 관리하기 위해 데이터 레이크는 다양한 특성과 요구 사항에 따라 데이터를 원래 영역, 제품 영역, 작업 영역 및 민감한 영역의 네 가지 핵심 영역으로 나눕니다.
Raw 영역
: 데이터 엔지니어, 전문 데이터 사이언티스트의 요구사항을 충족하는데 중점을 두고 있는 영역으로, 처리되지 않은 원시 데이터를 저장하는 것이 주요 목적입니다. 필요한 경우 특정 액세스 요구 사항을 지원하기 위해 부분적으로 열 수도 있습니다.
제품 영역
: 제품 영역의 대부분의 데이터는 데이터 엔지니어, 데이터 사이언티스트, 비즈니스 분석가에 의해 처리되고 처리되어 표준화 및 높은 수준의 데이터 관리를 보장합니다. 이러한 유형의 데이터는 일반적으로 비즈니스 보고, 데이터 분석, 기계 학습 및 기타 분야에서 널리 사용됩니다.
작업 영역
: 작업 영역은 주로 다양한 데이터 작업자가 생성한 중간 데이터를 저장하는 데 사용됩니다. 여기에서 사용자는 다양한 사용자 그룹의 요구 사항을 충족하기 위한 유연한 데이터 탐색 및 실험을 지원하기 위해 데이터를 관리할 책임이 있습니다.
민감 영역
: 민감 영역은 보안에 중점을 두고 개인 식별 정보, 금융 데이터, 법규 준수 데이터 등 민감한 데이터를 저장하는 데 주로 사용됩니다. 이 영역은 최고 수준의 접근 제어 및 보안으로 보호됩니다.
이러한 분할을 통해 데이터 레이크는 다양한 유형의 데이터를 더 잘 관리하는 동시에 다양한 요구 사항을 충족하기 위해 편리한 데이터 액세스 및 활용을 제공할 수 있습니다.
데이터 센터에 데이터 레이크 데이터 거버넌스 아이디어 적용
데이터 센터의 목표는 일관되지 않은 통계 수준, 반복적인 개발, 지표 개발 요구에 대한 느린 응답, 낮은 데이터 품질, 데이터 급증 및 비즈니스 확장으로 인한 높은 데이터 비용 등의 문제를 해결하는 것입니다.
데이터 센터와 데이터 레이크의 목표는 일관됩니다. 데이터 레이크 개념을 결합해 데이터 시스템과 데이터센터 전체 아키텍처를 최적화하고 업그레이드했다.
데이터센터 구축 초기 단계에서는 기업의 데이터 웨어하우스 시스템을 통합하고, 사업에 대한 심도 있는 연구를 진행하여 기존 분야 및 차원 정보를 정리하고 일관성 차원을 요약하여 통일된 지표 시스템을 구축하고 데이터 웨어하우스 구축을 공식화하였습니다. 명세서. 본 사양에 따라 통합 데이터 웨어하우스의 원본 데이터 레이어(ODS), 세부 데이터 레이어(DWD), 집계 데이터 레이어(MID)를 구축하고, 축적된 디바이스 라이브러리와 신규 디바이스를 포함한 디바이스 라이브러리를 구축했습니다. 도서관. 데이터 팀은 통합 데이터 웨어하우스를 기반으로 다양한 분석 및 통계 방향과 비즈니스 요구를 기반으로 테마 데이터 웨어하우스와 비즈니스 시장을 구축했습니다. 주제 데이터 웨어하우스 및 비즈니스 시장에는 추가 처리된 세부 데이터, 집계 데이터 및 애플리케이션 계층 데이터 테이블이 포함됩니다. 데이터 애플리케이션 계층은 이러한 데이터를 사용하여 사용자에게 다양한 서비스를 제공합니다.
통합 데이터 웨어하우스 시스템에서는 원본 데이터 레이어 이하
는
공개되지 않습니다. 사용자는 데이터 엔지니어를 통해서만 처리된 데이터를 처리할 수 있으므로 일부 데이터 세부 정보가 손실되는 것은 불가피합니다.
일상 업무에서 데이터 분석 기능을 갖춘 사용자는 개인화된 분석이나 문제 해결을 수행하기 위해 기본 원시 데이터에 액세스하려는 경우가 많습니다.
데이터 레이크의 데이터 관리 개념은 이 문제를 효과적으로 해결할 수 있습니다. 데이터 레이크의 데이터 거버넌스 아이디어를 도입한 후 기존 데이터 리소스를 정리 및 통합하고, 데이터 메타데이터를 강화 및 확장했으며, 메타데이터 관리를 위한 전용 데이터 메타데이터 센터를 구축했습니다.
데이터 거버넌스를 위한 데이터 레이크 개념을 도입한 후 원본 데이터 영역에 원본 데이터 레이어와 기타 원본 데이터(예: 원본 로그 파일)를 배치했습니다. 데이터 처리 기능이 있는 사용자는 이 영역에서 데이터 사용 권한을 신청할 수 있습니다.
통합 데이터 웨어하우스의 세부 레이어, 집계 레이어, 테마 데이터 웨어하우스, 비즈니스 마트 등이 제품 영역에 배치됩니다. 이러한 데이터는 데이터 팀의 데이터 엔지니어에 의해 처리되어 최종 데이터 제품으로 사용자에게 제공됩니다. 이 영역에서는 데이터 관리를 통해 처리되었으므로 데이터 품질이 보장됩니다.
또한 민감한 데이터에 대한 민감한 영역을 정의하고 액세스 권한 제어에 중점을 두었습니다.
사용자와 데이터 개발자가 매일 생성하는 임시 테이블 또는 개인 테이블은 임시 영역에 배치됩니다. 이러한 데이터 테이블은 사용자 자신의 책임이며 조건에 따라 다른 사용자에게 공개될 수 있습니다.
각 데이터의 메타데이터는 테이블 정보, 필드 정보, 해당 필드에 해당하는 차원과 지표 등을 포함하여 메타데이터 센터를 통해 유지됩니다. 동시에 테이블 수준 및 필드 수준 계보 관계를 포함하여 데이터 계보도 유지합니다.
데이터 자산센터를 통해 데이터 수준, 민감도, 권한 관리 등 데이터의 자산 특성을 유지합니다.
사용자가 스스로 데이터를 더 잘 사용할 수 있도록 하기 위해 사용자가 데이터 사용량, 차원, 지표 및 계보와 같은 메타데이터를 포함하여 데이터를 쿼리할 수 있도록 애플리케이션 계층의 데이터 디렉터리로 데이터 맵을 제공합니다. 동시에 플랫폼은 허가 신청을 위한 포털로도 사용될 수 있습니다.
또한 데이터 사용자에게 셀프 서비스 분석 기능을 제공하기 위해 셀프 서비스 분석 플랫폼도 제공합니다.
데이터 시스템을 최적화하는 동시에 데이터 레이크 개념을 기반으로 데이터 미들 플랫폼 아키텍처도 업그레이드했습니다.
맨 아래 계층은 데이터 계층으로 , 주로 사용자 행동을 수집하는 데 사용되는 핑백 데이터와 같은 다양한 데이터 소스를 포함합니다. 비즈니스 데이터는 다양한 관계형 데이터베이스 및 NoSQL 데이터베이스에 저장됩니다.
이러한 데이터는 전송 계층의 다양한 수집 도구를 통해 스토리지 계층에 저장됩니다.
데이터 계층 위에는 저장 계층이 있는데
주로 분산 파일 시스템인 HDFS를 기반으로 원본 파일을 저장한다. 기타 정형 또는 비정형 데이터는 Hive, Iceberg 또는 HBase에 저장됩니다.
더 나아가 컴퓨팅 계층은
주로 오프라인 엔진 Pilot을 사용하여 오프라인 계산을 위해 Spark 또는 Trino를 구동하고 예약된 워크플로 예약을 위해 예약 엔진 Gear 오프라인 워크플로 엔진을 사용합니다. RCP 실시간 컴퓨팅 플랫폼은 스트림 컴퓨팅 예약을 담당합니다. 여러 차례의 반복을 거친 후 현재 플로우 컴퓨팅은 주로 Flink를 컴퓨팅 엔진으로 사용합니다.
컴퓨팅 계층 위의 개발 계층은
컴퓨팅 계층과 전송 계층의 각 서비스 모듈을 추가로 캡슐화하여 오프라인 데이터 처리 워크플로 개발, 데이터 통합, 실시간 처리 워크플로 개발, 기계 학습 엔지니어링 도구 모음 및 중간체 개발을 위한 기능을 제공합니다. 개발 작업을 완료하는 서비스입니다. 데이터 레이크 플랫폼은 데이터 레이크에 있는 각 데이터 파일과 데이터 테이블의 정보를 관리하고, 데이터 웨어하우스 플랫폼은 데이터 웨어하우스의 데이터 모델, 물리적 모델, 차원, 지표 및 기타 정보를 관리합니다.
동시에 다양한 관리 도구와 서비스를 수직적으로 제공합니다. 예를 들어 전송 관리 도구는 핑백에 저장된 사양, 필드, 사전 및 메타데이터 센터, 리소스 센터 및 기타 모듈과 같은 메타 정보를 관리합니다. 데이터 테이블 또는 데이터 파일을 유지하고 데이터 보안을 보장하는 데 사용됩니다. 데이터 품질 센터 및 링크 관리 플랫폼은 데이터 품질 및 데이터 링크 생산 상태를 모니터링하고 관련 팀에 보호 조치를 신속하게 알리고 온라인 문제 및 장애에 신속하게 대응합니다. 기존 계획을 기반으로 합니다.
기본 서비스는 프라이빗 클라우드와 퍼블릭 클라우드 지원을 제공하기 위해 클라우드 서비스 팀에서 제공합니다.
아키텍처의 상위 계층에서는 사용자가 필요한 데이터를 찾을 수 있도록 데이터 디렉토리로 데이터 맵을 제공합니다. 또한 셀프 서비스 데이터 작업에 대한 다양한 수준의 사용자 요구를 충족하기 위해 Magic Mirror 및 Beidou와 같은 셀프 서비스 애플리케이션을 제공합니다.
전체 아키텍처 시스템을 변환한 후에는 데이터 통합 및 관리가 더욱 유연하고 포괄적이 됩니다. 셀프 서비스 도구를 최적화하여 사용자 임계값을 줄이고, 다양한 수준의 사용자 요구를 충족하며, 데이터 사용 효율성을 향상하고, 데이터 가치를 향상시킵니다.
데이터센터에 데이터 레이크 기술 적용
넓은 의미에서 데이터 레이크는 데이터 거버넌스의 개념입니다. 좁은 의미에서 데이터 레이크는 데이터 처리 기술을 의미하기도 합니다.
데이터 레이크 기술은 데이터 테이블의 저장 형식과 레이크에 들어간 후 데이터를 처리하는 기술을 다룹니다.
업계의 데이터 레이크에는 Delta Lake, Hudi 및 Iceberg의 세 가지 주요 스토리지 솔루션이 있습니다.
종합적인 고려 끝에 데이터 테이블의 저장 형식으로 Iceberg를 선택했습니다.
Iceberg는 기본 파일 시스템이나 개체 저장소에 데이터 파일을 구성하는 테이블 저장소 형식입니다.
Iceberg와 Hive의 주요 비교는 다음과 같습니다.
Hive 테이블과 비교할 때 Iceberg 테이블은 행 수준 업데이트를 더 잘 지원할 수 있고 데이터 적시성이 분 수준으로 향상될 수 있다는 점에서 상당한 이점을 가지고 있습니다.
데이터 적시성의 향상은 데이터 처리 ETL의 효율성을 크게 향상시킬 수 있기 때문에 이는 데이터 처리에서 매우 중요합니다.
따라서 기존 Lambda 아키텍처를 쉽게 변환하여 스트리밍 배치 통합 아키텍처를 달성할 수 있습니다.
데이터 레이크 기술이 도입되기 전에는 오프라인 처리와 실시간 처리를 결합하여 오프라인 데이터 웨어하우스와 실시간 데이터 웨어하우스를 제공했습니다.
전량의 데이터는 전통적인 오프라인 분석 및 처리 방식을 통해
데이터 웨어 하우스 데이터로 구축되며,
Hive 테이블 형태로 클러스터에 저장됩니다.
실시간 요구사항이 높은 데이터에 대해서는 실시간 링크를 통해 별도로 제작하여 Kafka에서 Topics 형태로 사용자에게 제공합니다.
그러나 이 아키텍처에는 다음과 같은 문제가 있습니다.
-
실시간 및 오프라인의 두 채널은 서로 다른 두 가지 코드 논리 세트를 유지해야 합니다. 처리 논리가 변경되면 실시간 채널과 오프라인 채널을 동시에 업데이트해야 합니다. 그렇지 않으면 데이터 불일치가 발생합니다.
-
오프라인 링크가 매시간 업데이트되고 약 1시간 지연된다는 것은 00:01의 데이터가 02:00까지 쿼리되지 않을 수 있음을 의미합니다. 실시간 요구 사항이 높은 일부 다운스트림 서비스의 경우 이는 허용되지 않으므로 실시간 링크를 지원해야 합니다.
-
실시간 링크의 실시간 성능은 두 번째 수준에 도달할 수 있지만 비용이 높습니다. 대부분의 사용자에게는 5분 업데이트이면 충분합니다. 동시에 Kafka 스트림을 사용하는 것은 데이터 테이블을 직접 운영하는 것만큼 편리하지 않습니다.
이러한 문제는 Iceberg 테이블과 스트리밍 배치의 통합 데이터 처리 방법을 사용하여 더 잘 해결할 수 있습니다.
최적화 과정에서는 주로 ODS 레이어와 DWD 레이어 테이블에 대해 Iceberg 변환을 수행하고, 구문 분석 및 데이터 처리를 Flink 작업으로 재구성했습니다.
변환 과정에서 데이터 생성의 안정성과 정확성이 영향을 받지 않도록 하기 위해 우리는 다음과 같은 조치를 취했습니다.
1. 핵심이 아닌 데이터로 전환을 시작합니다. 실제 사업상황을 바탕으로 QOS 전달과 맞춤형 전달을 시범사업으로 활용하고 있습니다.
2. 오프라인 구문 분석 논리를 추상화하여 통합 Pingback 구문 분석 저장소 SDK가 형성되어 실시간 및 오프라인의 통합 배포를 실현하고 코드를 더욱 표준화합니다.
3. 아이스버그 테이블과 새로운 생산 프로세스가 배포된 후 2개월 동안 듀얼 링크 병렬 작업을 실행하고 데이터에 대한 정기적인 비교 모니터링을 수행했습니다.
4. 데이터 및 제작에 문제가 없음을 확인한 후 상위 레이어로 눈에 띄지 않는 전환을 수행합니다.
5. 핵심 데이터와 관련된 기동 및 재생 데이터에 대해서는 전반적인 검증이 안정된 후 통합 스트리밍 및 일괄 변환을 수행할 예정입니다.
1. Qos 및 맞춤형 배송 데이터 링크가 전체적으로 거의 실시간으로 구현되었습니다. 1시간 단위로 지연되는 데이터는 5분 단위로 업데이트가 가능합니다.
2. 특별한 상황을 제외하고 통합 스트리밍 및 일괄 처리 링크는 실시간 요구를 충족할 수 있습니다. 따라서 기존의 실시간 링크와 QOS 및 커스터마이징 관련 오프라인 분석 링크를 오프라인화할 수 있어 자원을 절약할 수 있습니다.
데이터 처리의 변환을 통해 우리의 데이터 링크는 앞으로 아래 그림과 같이 될 것입니다.
후속 계획
데이터 센터의 데이터 레이크 적용에 대한 후속 계획에는 두 가지 주요 측면이 있습니다.
아키텍처 수준에서 우리는 데이터 센터에서 제공하는 데이터와 서비스를 보다 포괄적이고 사용하기 쉽게 만들기 위해 각 모듈의 개발을 계속 개선하여 다양한 사용자가 편리하게 사용할 수 있도록 할 것입니다.
기술적인 측면에서는 데이터 링크를 스트림-배치 통합으로 지속적으로 전환하는 동시에 적절한 데이터 기술을 적극적으로 도입하여 데이터 생산 및 사용 효율성을 향상하고 생산 비용을 절감할 것입니다.
6. 알렉스 고렐릭. 엔터프라이즈 빅 데이터 레이크.
이 기사는 WeChat 공개 계정인 iQIYI 기술 제품 팀(iQIYI-TP)에서 공유되었습니다.
침해가 있는 경우 [email protected]에 연락하여 삭제를 요청하세요. 이 글은 " OSC 소스 생성 계획
" 에 참여하고 있습니다 . 이 글을 읽고 계신 여러분의 많은 참여와 공유 부탁드립니다.
