머리말
그런 다음 마지막 장에서는 대용량 데이터 개발 지식 맵을 구축하고 ,이 교사는 "실제 개발을위한 오프라인 및 실시간 빅 데이터"의 상태를 계속 공유 할 수 있습니다. 빅 데이터 플랫폼이라고 할 수있는 플랫폼은 무엇입니까? 이 질문으로 오늘의 내용을 시작하겠습니다 (• ̀ ω •) ✧
데이터 플랫폼이란? 아니면 더 유행하는 빅 데이터 플랫폼이란 무엇입니까? 현재 업계는 데이터 플랫폼에 대한 정확한 정의를 갖고 있지 않지만 일반적으로 데이터 플랫폼이라고하는 데는 주로 다음 세 부분이 포함됩니다.
- 데이터 관련 도구, 제품 및 기술 : 일괄 데이터 수집 및 전송을위한 Sqoop, 오프라인 데이터 처리 Hadoop 및 Hive, 실시간 스트림 처리 Storm, Spark, 데이터 분석 R 등
- 데이터 자산 : 회사의 비즈니스 자체에서 생성 및 보관하는 데이터뿐만 아니라 회사 운영 (예 : 재무, 관리)에서 생성 된 데이터 및 외부에서 구매, 교환 또는 크롤링 된 데이터도 포함됩니다.
- 데이터 관리 : 데이터 도구에는 데이터 자산도 있지만 데이터의 가치를 극대화하고 위험을 최소화하기 위해 관리해야합니다. 따라서 데이터 플랫폼에는 일반적으로 데이터웨어 하우스 및 데이터와 같은 데이터 관리 관련 개념 및 기술이 포함됩니다. 모델링, 데이터 품질, 데이터 사양, 데이터 보안 및 메타 데이터 관리 등
위는 플랫폼의 데이터 영역을 논리적으로 구분 한 것이며, 플랫폼은 실제로 각도 데이터 처리 적시성에서 얻은 데이터이거나 일반적으로 인터넷 데이터 와 실시간 데이터 플랫폼 으로 구분 됩니다 .
-
오프라인 데이터 플랫폼은 일반적으로 일반적인 데이터 처리 주기로 며칠이 걸리며 데이터 지연도 날짜를 기준으로합니다. 오프라인 데이터 플랫폼의 데이터 적용은 주로 "보기"에 기반을두고 있으며, 업계의 현재 데이터 상태에서 오프라인 데이터 플랫폼은 여전히 데이터 플랫폼의 주요 전쟁터입니다.
-
그러나 빅 데이터의 적용이 심화되고 인공 지능의 물결이 증가함에 따라 지능형 제품의 추세가 점점 더 분명 해지고 있으며, 실시간 및 온라인 데이터 또한 데이터 플랫폼의 실시간 성능에 대한 요구 사항이 점점 더 높아지고 있습니다. 분 지연의 시작부터 현재 초 또는 밀리 초 지연까지 실시간 데이터 플랫폼은 점점 더 많은 관심을 받고 있으며 과제는 점점 더 커지고 있습니다. 물론 점점 더 주류가되고 있습니다. Spark, Flink 및 Beam 기술의 개발로 인해 언젠가는 오프라인 데이터 플랫폼의 기술과 아키텍처가 중단 될 수 있습니다.
다음 단계는 데이터 플랫폼을 도입하여 명확한 논리 및 기술 관련 고려 사항을 주로 오프라인 데이터 플랫폼, 실시간 데이터 플랫폼 및 데이터 관리 개념 및 기술에서 플랫폼과 관련된 데이터의 세 가지 측면을 소개합니다.
1. 오프라인 데이터 플랫폼의 아키텍처, 기술 및 설계
회사 관리자와 일선 비즈니스 직원의 경우 자주 대답해야하는 질문은 다음과 같습니다. 현재 및 지난 분기 또는 월 판매 추세는 무엇입니까? 어떤 제품이 잘 팔리고 있습니까? 잘 팔리지 않는 제품은 무엇입니까? 우리 제품을 구매하는 고객은 누구입니까? 관리자와 비즈니스 직원은 이러한 비즈니스 지표를 지속적으로 모니터링하고 이러한 지표를 기반으로 목표에 따라 비즈니스 전략 및 플레이 방식을 조정해야합니다.이를 반복하여 폐쇄 루프를 형성합니다. 이것이 디지털 운영의 기본 아이디어입니다.
그리고 이러한 종류의 분석 및 "보기"요구는 오프라인 데이터 플랫폼이 잘하는 것입니다. 이러한 종류의 분석 요구에 대해서는 데이터의 적시성이 강한 요구가 아닙니다. 그날의 데이터를 사용할 수 있더라도 그렇지 않더라도 영향은 적을 것입니다. , 오프라인 데이터 기술과 도구는 수년간 개발되어 왔으며 이러한 문제를 매우 성숙하게 해결할 수있는 많은 오픈 소스 솔루션과 상용 솔루션이 있습니다.
오프라인 데이터 플랫폼은 기업 및 기업 데이터 플랫폼 구축의 토대이자 기반이며 현재 데이터 플랫폼의 주요 전쟁터이기도합니다.
1.1 오프라인 데이터 플랫폼의 전체 아키텍처
오프라인 데이터 플랫폼은 일반적으로 Hadoop Hive, 데이터웨어 하우스, ETL, 차원 모델링, 데이터 공통 레이어 등과 연결됩니다.
Hadoop이 등장하기 전에 데이터웨어 하우스의 주요 처리 기술은 Microsoft의 SQL Server, Oracle의 Oracle 및 IBM DB2와 같은 상용 데이터베이스였습니다. 빅 데이터의 증가와 데이터 볼륨의 지속적인 폭발 및 기하 급수적 인 증가로 인해 Hadoop, MapReduce, Hive 및 기타 빅 데이터 처리 기술이 점점 더 널리 사용되고 수용되고 있습니다.
1.2 데이터웨어 하우스 기술
1. OLTP와 OLAP
데이터웨어 하우스는 데이터 분석의 필요성에 따라 점진적으로 개발되고 있으며, 초기 데이터 분석 및 보고서는 상용 Oracle, MS SQL Server 및 오픈 소스 MySQL과 같은 OLTP 데이터베이스 인 비즈니스 시스템의 데이터베이스를 기반으로합니다. 데이터 베이스.
OLTP 의 전체 이름은 온라인 트랜잭션 처리입니다. 이름에서 알 수 있듯이 OLTP 데이터베이스는 주로 주문 추가, 주문 수정, 주문 질의, 주문 취소와 같은 트랜잭션 처리에 사용됩니다. OLTP 데이터베이스의 핵심 요구 사항은 단일 레코드의 효율적이고 빠른 처리이며, 색인 기술, 하위 데이터베이스 및 하위 테이블과 같은 가장 기본적인 요구 사항은이 문제를 해결하는 것입니다.
- 이는 데이터 분석에 대한 요구와는 정반대입니다. 데이터 분석에는 일반적으로 많은 양의 데이터에 대한 액세스가 필요합니다. 단일 데이터 분석은 아무 의미가 없습니다. 데이터 분석에는 많은 양의 데이터에 대한 액세스뿐만 아니라 빈번한 통계 및 쿼리도 필요합니다. 빠른 데이터베이스 관리자는 이러한 통계 분석 요청이 많은 데이터베이스 리소스를 차지하여 프로덕션 시스템의 성능에 심각한 영향을 미친다는 사실을 발견했습니다.
- 따라서 이러한 데이터 분석 요청을 별도의 대기 데이터베이스로 격리하거나 데이터 분석가가 사용할 수 있도록 새 데이터베이스를 완전히 복사하는 것은 자연스러운 선택입니다.
프로덕션 데이터베이스에 미치는 영향 문제를 해결 한 후 OLTP 데이터베이스 관리자는 대기 데이터베이스와 복제 데이터베이스가 특히 성능 측면에서 여전히 데이터 분석가의 요구를 충족 할 수 없다는 것을 빠르게 발견했습니다. 대량의 데이터 액세스에는 일반적으로 전체 테이블 스캔이 필요합니다. 빈번하고 일반적으로 동시 전체 테이블 스캔으로 인해 OLTP 데이터베이스가 비정상적으로 느리게 응답하거나 심지어 다운 타임이 발생합니다. 이러한 분석 요청을 충족하려면 새로운 이론적 지원과 기술적 혁신이 필요합니다.
그래서 OLAP 데이터베이스는 분석가의 통계 분석 요구를 충족시키기 위해 개발 된 전문 분석 데이터베이스입니다.
- OLAP 데이터베이스 자체는 많은 양의 데이터를 처리하고 계산할 수 있으며, OLTP 데이터베이스와 달리 데이터 추가, 삭제, 수정, 검사 및 동시성 잠금 제어를 고려해야합니다. OLAP 데이터는 일반적으로 데이터 질의 요청 만 처리하면되고 일괄 적으로 데이터를 가져 오기 때문에 컬럼 저장, 컬럼 압축, 비트 맵 인덱싱 등의 기술을 통해 요청에 대한 응답 속도를 크게 높일 수 있습니다.
2. 분석 데이터베이스
분석 데이터베이스는 주로 분석가와 비즈니스 분석가에 의한 대규모 데이터 세트의 통계 및 집계 작업에 직면합니다. 그 아키텍처, 디자인 및 원칙은 기존 데이터베이스 제품 (OLTP 데이터베이스)과 완전히 다릅니다. 일반적으로 데이터웨어 하우스 제품은 배포되어야하지만 해결해야 할 문제는 OLTP 데이터베이스의 분산 문제와는 분명히 다릅니다. 분산 OLTP 데이터베이스 (예 : 하위 데이터베이스 및 테이블 및 기타 기술)는 주로 많은 단일 데이터 요청의 압력을 해결하기위한 것입니다. 주요 목적은 모든 사용자 요청을 각 노드에 균등하게 분배하는 것입니다. 분산 OLTP는 사용자를 분할하는 것입니다. 대규모 데이터 세트를 요청하는 작업은 독립적 인 계산을 위해 각 노드에 할당 된 다음 집계되어 사용자에게 반환됩니다.
또한 OLAP 데이터베이스는 일반적으로 열 저장소를 사용하는 반면 OLTP는 일반적으로 행 저장소를 사용합니다.
- 소위 열 저장은 행 저장과 같은 행에 모든 필드를 함께 저장하는 대신 테이블의 각 열을 하나씩 저장하는 것입니다.
- 데이터베이스 테이블의 경우 열 유형이 고정되어 있으므로 열 저장소는 압축 및 압축 해제에 높은 압축률 알고리즘을 쉽게 사용할 수 있으며 디스크 I / O가 크게 감소합니다.
- 컬럼 스토리지는 대용량 통계 쿼리 애플리케이션 시나리오에 매우 적합합니다. 분석 및 통계는 특정 컬럼 또는 특정 컬럼에 대한 경우가 많기 때문에 컬럼 스토리지 데이터베이스 제품은 전체 테이블을 모두 읽는 대신 해당 컬럼을 읽고 처리하기 만하면됩니다. 처리 라인.
3. Hadoop 데이터웨어 하우스
수년에 걸친 Hadoop의 개선과 Hadoop 생태계의 부상으로 Hadoop 기반 데이터웨어 하우스는 불과 몇 년 만에 메인 트랙을 완전히 점유했습니다. 특히 인터넷 회사에서는 Hadoop 기반 데이터웨어 하우스가 기본적으로 표준입니다.
Hadoop의 고유 한 기술적 유전자는 Hadoop을 기반으로하는 데이터웨어 하우스 솔루션을 결정합니다 (현재 주로 Hive는 확장이 매우 쉽습니다 (노드를 쉽게 추가하고 데이터 처리 용량을 GB, TB에서 PB 또는 EB로 확장 할 수 있음). 비용도 매우 낮습니다 (상업용 고가의 서버와 스토리지는 일반 하드웨어 만 필요하며 Hadoop 프레임 워크는 내결함성 처리를 수행합니다.이 두 가지 사항은 인터넷 회사에서 Hadoop의 인기를 높이는 주요 요인이기도합니다.
- Hadoop, 특히 Hive를 기반으로하는 데이터웨어 하우스 솔루션은 데이터 쿼리 대기 시간이라는 가장 큰 문제에 직면합니다 (Hive의 대기 시간은 일반적으로 Hive SQL의 복잡성과 처리 할 워크로드에 따라 몇 분 정도입니다. 대부분의 경우 여러 번 실행해야하는 경우도 있습니다. 시간. 물론 단순하고 작은 데이터 Hive SQL의 경우 결과가 몇 초 안에 반환 될 수 있습니다.)
그러나 빅 데이터와 클라우드 컴퓨팅은 미래이며 미래의 비즈니스 시스템은 프라이빗 클라우드, 퍼블릭 클라우드 또는 하이브리드 클라우드이든 상관없이 클라우드에서도 실행될 것입니다. 클라우드는 또한 미래 아키텍처가 분산되어야하고 거의 선형 적으로 확장 될 수 있다고 판단합니다.이를 기반으로 저자는 인터넷 기업이든 상관없이 Hadoop 및 Hadoop과 유사한 데이터웨어 하우스 솔루션이 향후 주류 및 표준이 될 것이라고 믿습니다. , 또는 전통적인 기업.
1.3 데이터웨어 하우스 모델링 기술
데이터웨어 하우스 개념이 탄생 한 이래 데이터웨어 하우스 분야에서 널리 알려진 데이터웨어 하우스 구축 방법은 두 가지입니다. 이 두 파벌의 대표자는 Bill Inmon과 Ralph Kimball이며 Bill Inmon은 "데이터웨어 하우스의 아버지", Ralph Kimball은 "비즈니스 인텔리전스의 아버지"라고 불립니다.
이 두 가지 관점이 탄생 한 이래 "어떤 아키텍처가 최고인가"에 대한 논쟁은 멈추지 않았습니다. 사람들은 자신의 의견을 표명했지만 "어떤 프로그래밍 언어가 최고의 프로그래밍 언어인가"처럼 통일 된 결론에 도달하지 못했습니다. 데이터웨어 하우스 분야에서는 "종교 전쟁"이라고 할 수 있습니다.
1. Ralph Kimball 모델링 방법론
데이터웨어 하우스에 대한 Kimball의 이론적 기여는 모두 차원 설계 및 모델링과 관련이 있습니다. 차원 모델링은 객관적인 세계를 측정과 맥락으로 나눕니다.
- 메트릭은 조직의 비즈니스 프로세스와이를 지원하는 소스 시스템에 의해 캡처되며, 종종 숫자 형식 (예 : 주문 금액, 재고 수량 등)으로 표시되며 차원 모델링 이론에서는이를 사실이라고합니다.
- 사실은 수많은 텍스트 컨텍스트로 둘러싸여 있으며 이러한 컨텍스트는 종종 직관적으로 여러 개의 독립적 인 논리 블록으로 나뉩니다. 차원 모델링을 차원이라고하며 차원은 5W (When, Where, What, Who)를 설명합니다. , 이유) 정보 (예 : 주문시기, 주문 방법, 구매 항목, 고객이 누구인지 등)
차원 모델링 이론에 의해 모델링 된 Kimball 데이터웨어 하우스는 종종 별 모양의 구조로 표현되며, 별 모양 구조의 중간에는 팩트 테이블이 있고 팩트 테이블의 주변은 다양한 각도의 차원 테이블입니다.
차원 모델링에서 스타 패턴은 비즈니스 프로세스를 밀접하게 따르고 매우 직관적이고 비즈니스 직원의 관점에 부합하기 때문에 널리 사용되고 널리 사용되고 있으며 스타 패턴은 데이터웨어 하우스 모델링에 대한 Kimball의 주요 공헌이기도합니다.
데이터웨어 하우스 모델링 이론에 대한 Kimball의 두 번째 주요 공헌은 차원 기반 " 버스 아키텍처 "입니다. 실제 프로젝트에서 기업의 비즈니스 프로세스는 일반적으로 다양하고 복잡하며 여러 비즈니스 주제에 존재합니다. 함께 버스 아키텍처와 일관성 차원은 여러 주제의 팩트 테이블과 차원 테이블을 최종적으로 통합하여 일관성을 제공 할 수 있도록합니다. 그리고
비즈니스 직원에게 유일한 구경입니다.
Kimball 모델링 이론을 사용하는 데이터웨어 하우스 시스템 아키텍처가 그림에 나와 있습니다.
Kimball 차원 모델링의 주제는 스타 아키텍처를 기반으로하며, 데이터웨어 하우스의 통합과 일관성을 보장하기 위해 주제와 주제간에 일관성 차원과 엔터프라이즈 버스 아키텍처가 사용됨을 알 수 있습니다.
2. Bill Inmon 모델링 방법론
데이터웨어 하우징 분야에서 Bill Inmon은 처음으로 OLAP 및 데이터웨어 하우징 개념을 제안했기 때문에 데이터웨어 하우징의 아버지라고 불립니다. Bill Inmon은 자신의 데이터웨어 하우징 방법을 소개하는 많은 기사를 작성했습니다. 그는 데이터웨어 하우징이 "라고 생각합니다. 기업 관리 및 의사 결정에서 주제 지향적이고 통합 된 시간 관련 수정 불가능한 데이터 모음입니다. "
다른 데이터베이스 응용 프로그램과 달리 데이터웨어 하우스는 구매할 수있는 제품이 아니라 기업 전체에 분산 된 비즈니스 데이터의 통합, 처리 및 분석 프로세스 인 프로세스와 비슷합니다. 이것이 그가 "엔터프라이즈"라고 부르는 것입니다. 정보 화학 공장 ".
Inmon의 엔터프라이즈 정보 팩토리에는 소스 시스템, 준비 영역, ETL, 엔터프라이즈 데이터웨어 하우스, 데이터 마트 등이 포함되며 엔터프라이즈 데이터웨어 하우스는 엔터프라이즈 정보 팩토리의 허브입니다. 킴볼과는 달리 기업이 원자 데이터웨어 하우스를 통합해야하는 인몬 데이터웨어 하우스는 팩트 및 차원 테이블의 차원 모델링이 아닌 제 3 정규 형식 과 ER 이론 을 사용하여 모델링해야합니다.
Inmon의 기업 정보 플랜트에는 "데이터 마트"라는 개념이 포함되며, 소위 "마트"는 부서 수준의 데이터웨어 하우스입니다. 데이터 마트의 경우 Inmon은 데이터의 일관성을 보장하기 위해 엔터프라이즈 데이터웨어 하우스에서 필요한 데이터를 추출하는 것을 옹호합니다. 이로 인해 발생하는 문제는 부서 수준 데이터 마트를 구축하기 전에 엔터프라이즈 데이터웨어 하우스를 구축해야한다는 것입니다. 이것은 Inmon 데이터웨어 하우스 아키텍처와 Kimball 데이터웨어 하우스 아키텍처의 두 번째 주요 차이점입니다. 동시에 Inmon은 Kimball의 차원 모델링 이론을 사용하여 데이터 마트를 구축해야한다고 믿습니다.
3. 데이터웨어 하우스 모델링 실습
위에서 소개 한 두 가지 데이터 아키텍처를 통해 인몬의 방식은 하향식 데이터웨어 하우스 구축 방식임을 알 수 있습니다. 엔터프라이즈 데이터웨어 하우스의 전체 계획을 먼저 수행해야하고 OLTP 데이터는 주제 지향, 통합, 비 휘발성 및 시간에 따라 변하는 엔터프라이즈 데이터웨어 하우스에 집중되어 있습니다. 데이터 마트는 데이터웨어 하우스의 하위 집합이어야하며 각 데이터 마트는 독립된 부서를 위해 특별히 설계되었습니다.
Kimball 방법은 그 반대입니다. Kimball은 데이터웨어 하우스가 일련의 데이터 마트의 모음이라고 믿으며 기업은 일관된 차원 테이블과 "엔터프라이즈 버스 아키텍처"를 통해 다양한 데이터 마트를 점진적으로 통합하여 전체 엔터프라이즈를위한 데이터웨어 하우스를 구축 할 수 있습니다.
차이점을 한 문장으로 요약하십시오.
Kimball : 사람들이 원하는 것을 원하는 때에 만들 수 있도록
하세요. 필요할 때 모든 것을 통합 할 것입니다.
인몬 : 모든 것을 디자인하기 전까지는 아무것도하지 마세요.
Inmon의 방법은 배포 및 개발주기가 길지만 유지 관리가 쉽고 고도로 통합 된 반면 Kimball의 방법은 비즈니스 요구에 신속하게 대응하고 데이터웨어 하우스를 신속하게 구축 할 수 있지만 나중에 통합 및 유지 관리가 더 까다 롭습니다. 둘 사이에는 절대적인 옳고 그름이 없으며, 다른 단계와 다른 시나리오의 장단점 만 있습니다.
4. 데이터웨어 하우스 논리 아키텍처 설계
오프라인 데이터웨어 하우스는 일반적으로 차원 모델링 이론을 기반으로 구축되지만 오프라인 데이터웨어 하우스는 일반적으로 논리적으로 계층화됩니다. 데이터웨어 하우스의 논리적 계층화도 업계에서 가장 좋은 방법입니다.
오프라인 데이터웨어 하우스의 논리적 계층화는 주로 다음 고려 사항을 기반으로합니다.
격리 : 사용자는 비즈니스 시스템의 원본 데이터가 아닌 데이터 팀에서 신중하게 처리 한 데이터를 사용해야합니다. 이것의 이점 중 하나는 사용자가 비즈니스 관점에서 신중하게 준비되고 표준화되고 깨끗한 데이터를 사용한다는 것입니다. 이는 이해하고 사용하기 매우 쉽습니다. 두 번째 이점은 업스트림 비즈니스 시스템이 변경되거나 심지어 리팩터링 (예 : 테이블 구조, 현장 비즈니스 의미 등), 데이터 팀은 다운 스트림 사용자에게 미치는 영향을 최소화하기 위해 이러한 모든 변경 사항을 처리 할 책임이 있습니다.
성능 및 유지 보수성 : 전문인은 전문적인 작업을 수행하고 데이터 레이어링은 기본적으로 데이터 팀에서 데이터 처리를 수행하므로 동일한 비즈니스 로직을 반복 할 필요가 없으므로 해당 스토리지 및 컴퓨팅 오버 헤드를 절약 할 수 있습니다. 결국 빅 데이터는 그렇지 않습니다. 비용은 없습니다. 또한 데이터의 계층화는 데이터웨어 하우스의 유지 보수를 명확하고 편리하게 만들어줍니다. 각 계층은 자체 작업만을 담당합니다. 특정 계층의 데이터 처리에 문제가있는 경우 계층 만 복구하면됩니다.
규범 성 : 기업과 조직에있어 데이터의 수준은 매우 중요합니다. 지표에 대해 이야기 할 때는 명확하고 인정 된 수준을 기반으로해야하며 표, 필드, 지표도 표준화해야합니다.
데이터웨어 하우스는 일반적으로 다음 계층으로 나뉩니다.
ODS 계층 : 데이터웨어 하우스 소스 시스템의 데이터 테이블은 일반적으로 그대로 저장됩니다.이를 ODS (Operation Data Store) 계층이라고합니다. ODS 계층은 종종 스테이징 영역이라고하며 후속 데이터입니다. 처리 데이터의웨어 하우스 계층 (즉, Kimball 차원 모델링을 기반으로 생성 된 사실 테이블 및 차원 테이블 계층과 이러한 사실 테이블 및 일정을 기반으로 처리 된 요약 계층 데이터) 소스 및 ODS 계층은 기록 증분 또는 전체 데이터도 저장합니다. .
OWD 및 DWS 계층 : 데이터웨어 하우스 세부 정보 (DWD) 및 데이터웨어 하우스 요약 (데이터웨어 하우스 요약, DWS)은 데이터 플랫폼의 주요 콘텐츠입니다. DWD 및 DWS의 데이터는 ODS 레이어 데이터의 ETL 정리, 변환 및로드를 통해 생성되며 일반적으로 Kimball의 차원 모델링 이론을 기반으로 구성되며 일관된 차원 및 데이터 버스를 통해 각 하위 주제의 차원이 보장됩니다. 일관성.
ADS 계층 : 애플리케이션 계층은 주로 DWD 및 DWS를 기반으로 다양한 비즈니스 당사자 또는 부서에서 구축 한 데이터
마트 (Data Mart, 이하 DM) 이며 , 데이터 마트 DM은 DWD / DWS에 상대적인 데이터웨어 하우스 (Data Warehouse, 이하 DW 라 함)입니다. ) 그것을 위해. 일반적으로 애플리케이션 계층의 데이터는 DW 계층에서 가져 오지만 원칙적으로 ODS 계층에 대한 직접 액세스는 허용되지 않습니다. 또한 DW 계층과 비교하여 애플리케이션 계층에는 부서 또는 비즈니스 측에서 관심을 갖는 세부 계층 및 요약 계층 데이터 만 포함됩니다.
위의 ODS 계층 → DW 계층 → 애플리케이션 계층을 사용하는 데이터웨어 하우스의 논리적 계층 구조가 그림에 나와 있습니다.
2. 실시간 데이터 플랫폼의 아키텍처, 기술 및 설계
오프라인 데이터 플랫폼에 의해 출력되는 데이터주기는 일반적으로 며칠입니다. 즉, 오늘 보는 것은 어제의 데이터입니다. 대부분의 분석 및 데이터 "보기"시나리오에서이 T + 1 오프라인 데이터는 비즈니스 분석이 필요하지만 비즈니스 운영이 더욱 세분화됨에 따라 데이터의 적시성에 대한 요구 사항이 점점 더 높아지고 있으며, 점점 더 많은 비즈니스 시나리오에서 특히 비즈니스 프로모션 활동 (일반적으로 다음과 같은)에서 비즈니스 효과를 즉시 확인해야합니다. 더블 11 빅 프로모션, 618 빅 프로모션 등).
더 중요한 것은 인공 지능 물결의 부상으로 실시간 데이터가 더 이상 최고가 아니라 필수라는 것입니다. 데이터는 분석하고 "보는 것"일뿐만 아니라 알고리즘과 함께 생산 비즈니스 시스템의 일부가됩니다.
2.1 실시간 데이터 플랫폼의 전체 아키텍처
실시간 데이터 플랫폼의 지원 기술은 주로 실시간 데이터 수집 (예 : Flume), 메시지 중간 (예 : Kafka), 스트림 컴퓨팅 프레임 워크 (예 : Strom, Spark, Flink, Beam 등) 및 실시간 데이터 저장소 (예 : 열 패밀리)의 4 가지 측면을 포함합니다. 저장된 HBase). 현재 주류 실시간 데이터 플랫폼은이 네 가지 관련 기술을 기반으로 구축되었습니다.
실시간 데이터 플랫폼은 먼저 데이터 소스의 실시간 특성을 보장해야합니다. 데이터 소스는 일반적으로 데이터베이스와 로그 파일의 두 가지 범주로 나눌 수 있습니다. 전자의 경우 업계에서 가장 좋은 방법은 데이터베이스에 직접 액세스하여 데이터를 추출하는 것이 아니라 데이터베이스 변경 로그를 직접 수집하는 것입니다.
MySQL의 경우 데이터 변경 전후의 상태를 포함하는 MySQL의 데이터베이스 변경 로그인 binlog입니다.
데이터 수집 도구 (예 : Flume)에서 수집하는 binlog 이벤트의 속도와 빈도는 일반적으로 소스 시스템에 따라 다릅니다. 데이터 처리 속도와 다운 스트림 실시간 데이터 처리 도구 (예 : Storm, Spark, Flink 및 기타 스트림 컴퓨팅 프레임 워크 및 플랫폼)는 일반적으로 일치하지 않습니다. 또한 실시간 데이터 처리는 일반적으로 특정 과거 시점에서 다시 시작하여 실시간 작업을 위해 동일한 소스 데이터를 사용해야하므로 메시지 미들웨어는 일반적으로 실시간 데이터 수집 및 처리를위한 버퍼로 사용됩니다. 시합.
실시간 데이터 저장소는 일반적으로 다운 스트림 데이터 사용 방법에 따라 다른 데이터 저장소에 배치됩니다. 서비스중인 데이터 (즉, 데이터 소비자가 특정 비즈니스 ID를 전달한 다음이 ID의 모든 관련 필드를 가져옴)의 경우 일반적으로 HBase에 배치됩니다. ; 실시간 데이터의 큰 화면의 경우 일반적으로 일종의 관계형 데이터베이스 (예 : MySQL)에 배치됩니다. 때로는 성능을 향상시키고 기본 데이터베이스에 대한 부담을 줄이기 위해 캐시 데이터베이스 (예 : Redis)도 사용됩니다.
2.2 스트림 컴퓨팅 기술
스트림 컴퓨팅의 인기와 수용은 2011 년경에 탄생 한 Storm에서 시작되었습니다. Stοrm은 빠르게 알려졌고 "실시간 Hadoop"으로 받아 들여졌습니다.
그렇다면 스트림 컴퓨팅이란 무엇입니까? 그것과 오프라인 일괄 처리의 차이점은 무엇입니까? 오프라인 일괄 처리 (예 : Hadoop Map Reduce)와 달리 스트림 컴퓨팅에는 다음과 같은 일반적인 특성이 있습니다.
Unbounded : 하천 컴퓨팅을위한 데이터 소스는 지속적으로 흐르는 강물과 같이 연속적이므로 하천 컴퓨팅 작업은 항상 실행되어야합니다.
트리거 : Hadoop 오프라인 작업은 예약 된 스케줄링에 의해 트리거되는 것과 달리 스트림 컴퓨팅 작업의 각 계산은 소스 데이터에 의해 트리거됩니다. 트리거링은 스트림 컴퓨팅의 매우 중요한 개념입니다. 일부 비즈니스 시나리오에서는 메시지 트리거 논리가 더 복잡하여 스트리밍 컴퓨팅에 큰 도전이됩니다.
지연 시간 : 스트림 컴퓨팅은 데이터를 효율적이고 빠르게 처리 할 수 있어야합니다. 오프라인 Hadoop 작업의 처리 지연 (최소 몇 분 또는 몇 시간)과 달리 스트림 컴퓨팅의 지연은 일반적으로 몇 초 또는 심지어 밀리 초 단위이며 분 수준의 지연은 일부 특수한 상황에서만 허용됩니다.
과거 데이터 : Hadoop 오프라인 작업이 특정 과거 날짜의 데이터에 문제가 있음을 발견하면 일반적으로 문제를 해결하고 작업을 다시 실행하는 것이 쉽지만, 첫째, 실시간 스트리밍 메시지가 일반적으로 저장되지 않기 때문에 스트리밍 컴퓨팅 작업에 기본적으로 불가능하거나 비용이 많이 듭니다. 오랜 시간 (보통 며칠)이고, 기본적으로 현장에 이력을 완전히 저장하는 것이 불가능하므로 실시간 스트리밍 컴퓨팅은 일반적으로 문제가 발견 된 순간부터 데이터를 복구 할 수 있으며, 과거 데이터는 스트리밍으로 보완 할 수 없습니다.
근본 원인에서 스트림 컴퓨팅의 구현 메커니즘에는 현재 두 가지 처리 방법이 있습니다. 하나는 오프라인 일괄 처리를 모방하는 것이고, 이는 마이크로 일괄 처리 (즉, 미니 일괄 처리)를 사용하는 것입니다. 마이크로 배치 처리는 처리량을 증가 시키지만 해당 데이터 지연도 기본적으로 2 분 및 1 분 수준에서 증가합니다. 일반적인 기술은 Spark Streaming입니다. 다른 하나는 기본 메시지 데이터입니다. 즉, 처리 장치는 단일 데이터입니다. 초기 기본 스트림 컴퓨팅 기술은 대기 시간이 짧지 만 (일반적으로 수십 밀리 초) 데이터 처리량이 제한됩니다. 일반적으로 기본 Storm 프레임 워크이지만 Flink를 사용합니다. 기술의 출현과 발전으로 인해 처리량은 더 이상 문제가되지 않습니다.
2.3 메인 스트림 컴퓨팅 오픈 소스 프레임 워크
셋, 데이터 관리
회사와 조직의 경우 데이터 전용 기술로는 충분하지 않으며 데이터를 관리해야합니다. 데이터 관리의 범위는 매우 광범위하지만 주로 데이터 탐색, 데이터 통합, 데이터 품질, 메타 데이터 관리 및 데이터 보호가 포함됩니다.
3.1 데이터 탐색
이름에서 알 수 있듯이 데이터 탐색은 필수 데이터를 사용할 수 있는지 여부, 어떤 필드가 있는지, 필드의 의미가 표준화되고 명확한 지 여부, 필드의 분포 및 품질을 포함하되 이에 국한되지 않는 데이터 자체의 내용과 관계를 분석하는 것입니다. 데이터 탐색에 일반적으로 사용되는 분석 기술에는 기본 및 외래 키, 필드 유형, 필드 길이, null 값 비율, 열거 형 값 분포, 최소값, 최대 값, 평균 등이 있습니다.
데이터 탐색은 전략과 전술로 구분됩니다.
- 전략적 데이터 탐색은 데이터를 사용하기 전에 데이터 소스에 대한 가벼운 데이터 분석을 통해 사용 가능 여부와 데이터의 안정성을 확인하여 데이터 플랫폼에서 사용할 수 있는지 여부를 결정합니다. 전략적 데이터 탐색은 데이터 플랫폼을 구축하기 전에 수행해야 할 첫 번째 작업입니다. 자격이없는 데이터 소스는 가능한 한 빨리 제거해야합니다. 나중에 데이터 소스가 자격이없는 것으로 확인되면 데이터 플랫폼 구축에 큰 영향을 미칩니다.
- 전술적 데이터 탐색은 기술적 수단으로 데이터를 상세하게 분석하여 가능한 한 많은 데이터 품질 문제를 발견하고이를 비즈니스 담당자에게 피드백하거나 개선을 위해 소스 시스템에 알리는 것을 말합니다.
3.2 데이터 통합
데이터웨어 하우스의 데이터 통합은 데이터 플랫폼 구축의 핵심 인 ETL (추출 : 추출, 변환 : 변환,로드 :로드)이라고도하며 데이터 플랫폼 구축 과정에서 가장 많은 시간과 에너지를 소비하는 단계이기도합니다.
ETL은 일반적으로 데이터 원본에서 데이터를 추출하고, 정리, 변환 및 연결과 같은 변환을 수행하고, 미리 디자인 된 데이터 모델에 따라 데이터를 데이터웨어 하우스에 최종적으로로드하는 프로세스를 말합니다.
데이터 플랫폼 사용자 및 비즈니스 담당자의 경우 일반적으로 데이터 소스 (예 : 주문)가 얼마나 많이 사용되는지, 어떤 데이터베이스에서 필드 정의가 일관성이 있는지 (예 : 주문을 대신하는 주문 시스템 1)에 대해 알지 못합니다. 성공, 0은 주문 실패를 의미하고 시스템 2는 성공을 사용하여 주문의 성공을 나타내고 실패를 나타내지 않음) 관련 데이터 테이블 (예 : 주문 고객의 초상화 정보, 제품 범주) 및 사용자가 원하는 데이터 마지막으로 볼 수있는 것은 모든 관련 주문 정보가 포함 된 표준화되고 표준화 된 와이드 테이블입니다.이 와이드 테이블에는 사용할 수있는 모든 주문 정보와 이러한 모든 백엔드 추출, 정리, 변환 및 연결, 그리고 최종 요약이 포함되어 있습니다. 연관과 같은 복잡한 프로세스는 모두 ETL에 의해 완료되며, 이는 데이터웨어 하우스가 데이터 사용자에게 가져올 수있는 중요한 가치 중 하나이기도합니다.
3.3 데이터 품질
데이터 품질은 주로 다음 네 가지 측면에서 측정됩니다.
완전성 : 완전성은 데이터 정보가 부족한지 여부를 말하며, 데이터 부족 상황은 전체 데이터 레코드가 부족하거나 데이터의 특정 필드에 대한 레코드 일 수 있습니다. 불완전한 데이터가 배울 수있는 가치는 크게 줄어들 것이며 데이터 품질에 대한 가장 기본적인 평가 기준이기도합니다.
일관성 : 일관성은 데이터가 표준을 준수하는지 여부와 데이터 수집이 균일 한 형식을 유지하는지 여부를 나타냅니다. 데이터 품질의 일관성은 주로 데이터 레코드의 사양과 데이터가 논리를 준수하는지 여부에 반영됩니다. 예를 들어, IP 주소는 0에서 255까지의 4 개의 숫자와 "."로 구성되어야합니다.
정확성 : 정확성은 데이터에 기록 된 정보에 이상이나 오류가 있는지, 비즈니스 기대치를 충족하는지 여부를 나타냅니다.
적시성 : 적시성은 데이터의 출력 시간이시기 적절하고 정확한지, 기대치에 부합 하는지를 나타냅니다.
3.4 데이터 마스크
데이터웨어 하우스는 기업의 모든 데이터를 저장하며, 그중 일부는 사용자의 신용 카드 정보 및 ID 카드 정보와 같이 매우 민감한 데이터입니다. 이 정보가 유출되면 기업이나 회사에 치명적인 결과를 초래할 수 있지만,이 정보를 완전히 배제하면 개발, 테스트, 분석 및 통계에 영향을 미칠 것입니다.
데이터 마스킹은 데이터를 비가 역적으로 처리하는 방법에 대한 것이므로 처리 된 데이터는 정보를 공개하지 않고 개발, 테스트, 분석 및 통계에 사용할 수 있습니다. 암호화, 교체, 삭제 / 스크램블링 등과 같은 일반적인 방법
네, 요약
오늘은 주로 데이터 플랫폼의 콘텐츠 카테고리를 소개했는데, 오프라인과 실시간 측면에서 데이터 플랫폼의 아키텍처, 주요 개념 및 기술을 배웠습니다.
오프라인 데이터 플랫폼은 현재 데이터 플랫폼의 주요 전쟁터입니다. 관련 개념 기술 (데이터웨어 하우스, 차원 모델링, 논리적 계층화, Hadoop 및 Hive 등)은 상대적으로 성숙하고 다양한 회사에서 널리 사용되고 있습니다.
데이터와 인공 지능의 적시성이 높아짐에 따라 실시간 데이터 플랫폼이 점점 더 주목을 받고 전략적 위치에 자리 잡고 있습니다. 또한 Storm, Flink, Beam과 같은 실시간 데이터 플랫폼 관련 기술도 지속적으로 개발 및 개선되고 있습니다. 이러한 부정적인 측면에 어느 정도의 관심을 유지하고 이러한 기술을 적극적으로 수용 할 필요가 있습니다.
인생은 남을 능가하는 것이 아니라 자신을 능가하는 것입니다.
윤기입니다. 다음에 뵙겠습니다.
