머리말
데이터없이 할 수있는 모든 온라인 시스템은 일부 데이터가 같은 계정, 암호, 컨텐츠의 페이지 표시의 시스템으로, 비즈니스 시스템 자체가 필요합니다. 데이터의 일부는 같은 구매 주문 비즈니스 시스템 로그와 같은 사용자 생성 실시간 비즈니스 시스템 또는이며, 시스템, 지불 정보, 회원의 개인 정보에 액세스 할 수있는 사용자의 브라우저를 기록합니다. 대부분의 기업은 내부 및 외부 이러한 데이터는 사물의 핵심에 사업 개발, 의사 결정과 혁신을 주도하고, 많은 온라인 시스템이 있습니다. 이러한 데이터는 더 나은 온라인 지원 시스템은 데이터베이스 및 데이터 분석 플랫폼입니다 수 있습니다.
데이터베이스 데이터가 미리 정의 된 요구 사항에 대한 시스템 및 온라인 쿼리에 기록 된 실시간 주로 담당하고, 엄밀하게 말하면, 데이터베이스 유형의 OLTP 데이터베이스입니다. 이러한 데이터베이스는 가장 잘 알려진입니다 오라클과 MySQL을 그. 데이터베이스에 대한 비즈니스 시스템 요구 사항은 다양 할뿐만 아니라되는 NoSQL 데이터베이스와 NewSQL 전통적인 관계형 데이터베이스에 최근 몇 년 동안 수 있습니다. 상기 서비스 시스템에 직접 관련 데이터베이스에 축적 된 데이터 스토리지 서비스뿐만 아니라, 데이터 시스템 모니터 방대한 있는데,이 시스템은 서비스 로그를 생성한다. 우리는 이러한 데이터를보다 내구성이 저장 될 수 원하는 몇 가지 실시간 또는 오프라인 분석을 할 경우, 우리는 비즈니스 및 시장 보고서는 많은 기업들이 자신의 데이터 분석 플랫폼을 구축 할 것입니다 제공, 비즈니스 의사 결정을 지원합니다. 즉 오늘날의 "빅 데이터"플랫폼의 기원이다. 이러한 플랫폼은 다음과 같은 문제를 해결하기 위해 주로 :
1. 다양한 데이터 소스와 데이터 형식은 런타임에 바인딩 지원
이 데이터 분석 플랫폼이기 때문에 리치 데이터 소스는 우리 비즈니스 데이터의 모든 종류의 데이터 소스 등등, MySQL과, MongoDB의 다양한 데이터베이스에서 오는 소스를 기록하고, 수있는 위치를 요약 한 것입니다. 플랫폼은 데이터 소스의 모든 종류의 편리한 저장을 용이하게 할 수 있어야합니다, 예를 들어, 일반적으로 큰 데이터 아키텍처 카프카가 있음을 발견 할 것이다, 다양한 유형의 데이터 원본이 처음 카프카를 입력합니다, 카프카는 큰 저장 시스템 데이터 다시 밀었다. 카프카 여기서 큰 플랫폼 디커플링 상향 데이터 저장 인터페이스와 데이터 소스의 역할을 가정한다. 지연 바인딩 데이터 형식은 매우 중요한 개념, TP 클래스 데이터베이스는 종종 비즈니스 요구에 따라 미리 정의 된 스키마를 요구, 그것은 종종 쓰기 스키마, 데이터 필드의 엄격한 타입 검사를 할 것입니다 데이터를 쓸 때의 말한다. 그러나, 분석 시스템은 제한하거나 보통 스키마 판독 형 채용 스키마 데이터 저장을 제한하지 않기 때문에, 즉 지연 바인딩은 데이터 분석에 대응하는 데이터의 종류에 따라 처리 될 위치.
2. 스토리지 탄성 연장 컴퓨팅
스토리지 확장 및 대형 데이터 시스템을 지원할 수있는, 상기 탄성 수단을 계산하는 것은 대량의 데이터를 필요로하며, 판독 및 기록의 높은 스루풋을 유지한다. 시간이 지남에 따라 데이터가 축적되는 동안 데이터 분석 플랫폼 집계는 온라인 시스템의 다양한 유형의 모든 유형의 데이터에 동의합니다. 대용량 데이터 저장을 지원할 수있는 빅 데이터 분석 플랫폼이 필요하지만,이 크기는 미리 정의되지 않고, 데이터의 축적은 저장 용량이 레벨 TB 레벨, 심지어 수백 PB있다 탄력성을 증가하여 PB. 한편 전력을 전체 구조는 탄성과 동일합니다 컴퓨팅, 직관적 인 예제를 제공, 우리가 처리의 전액, 20 분 소요 TB 수준에서 할 수는 백 개 PB 수준, 매일 분석 결과 몇 배를 뒤적 거리다 할 수있는 처리 시간에 아닙니다 빅 데이터 플랫폼의 값이 크게 감소 때문에 결과는 사업의 신속한 개발을 제한, 시간에 생성 할 수 없습니다.
3. 대규모 저비용
처음부터 설계된 대부분의 빅 데이터 플랫폼은 주로 오픈 소스 프로그램과의 친숙 함을 기반으로 비용을 인식하지 않을 수 있습니다, 스케일 데이터 분석 및 프로그램의 효과의 비즈니스 측면이 선정되었다. 트래픽이 정말로입니다 때, 어려운 문제는 빅 데이터 플랫폼의 비용에 직면했다. 심지어 플랫폼 아키텍처 또는 데이터 마이그레이션의 변화로 이어질가있을 수 있습니다. 처음부터 설계된 대규모 엔터프라이즈 데이터 플랫폼 그래서, 우리는 우리의 전체 비용 구조가 고려 넣을 필요가있다. 이것은 해당 계산 엔진 계층화 스토리지 및 데이터 저장을 선택하는 것이다. 요즘 빅 데이터 클라우드 플랫폼은 결국 클라우드 알리 S3에 OSS 또는 AWS와 같은 확장 성, 저비용 스토리지 플랫폼 최종 착륙 데이터를 선택하는 경향이, 스토리지 플랫폼 자체도 더 계층 형 스토리지를 지원합니다. 저장 탄성 MapReduce의 방식 상술 이러한 컴퓨팅 플랫폼을 선택할 수있다. 전체 아키텍처 요즘 핫 "데이터의 호수"프로그램의 형성에. 사용자 온라인 하둡 클러스터를 자체 내장하고, 이러한 데이터 요약을 저장 한 다음 자신의 큰 데이터웨어 하우스를 구축 HDFS를 사용 할 수 있습니다.
4. 온라인 비즈니스 분석 및 사업 분리
비즈니스 분석은 종종 분석을 위해 더 많은 데이터를 스캔해야 큰 흐름을 스캔 이러한 유형의 온라인 라이브러리에서 발생하는 경우는 SLA 온라인 서비스에 영향을 미칠 수 있기 때문에 격리입니다. 동시 액세스 분석 시스템에 적합하지 않을 수 온라인 모드, 저장 및 유통 형식의 온라인 라이브러리 데이터와 반드시 동일한 트래픽 패턴 및하지를 분석합니다. 스토리지, 데이터 배포, 형식과 인덱스 지향 분석이 따라 최적화 필요가의 복사본이있을 것이다 빅 데이터 플랫폼의 일반적 전형이다. 예를 들면, 열 분석으로 변환한다 종종 전형적인 클래스 TP 엔진 라인 메모리 저장 형식이 존재한다.
여기에 소개 된, 우리는 기존의 데이터웨어 하우스 또는 구름 호수의 데이터, 우리는 결국 효율적으로 비즈니스 데이터 저장 및 분석의 문제를 해결하기 위해 희망 여부를 질문에 대해 생각하는 사람들을 안내하도록하겠습니다. 그게 정확히 어떤 비즈니스 요구, 우리는 데이터 소스에 대한 데이터베이스, 구조화 된 또는 반 구조화 된 데이터의 유형을 모니터링 로그입니다 분석 할 때 특히 빅 데이터 플랫폼이되어 필요한 사항 ? 나는 구조화 된 데이터 저장 및 분석을위한 큰 수요를 요약 돌아와 우리는, 우리가 될 것입니다에 대해 생각하기 시작하고 우리는 오늘날의 주류 오픈 소스 프로그램의 일부를 살펴보고 클라우드에 솔루션을 구축하고, 여기에 생각합니다.
오픈 소스 빅 데이터 스토리지 플랫폼 아키텍처 분석
앞서 우리는 실시간 데이터 읽기 및 쓰기 달성하기 위해 지원 OLTP 데이터베이스없이 온라인 비즈니스를 달성 언급했다. 이 장에서 우리는 몇 가지 주요 데이터베이스 및 빅 데이터 분석 플랫폼 아키텍처의 조합에 오픈 소스 및 클라우드를보십시오.
하둡 빅 데이터 솔루션
우리가 예를 들어 큰 데이터 아키텍처에 동네 짱은 그림은 카프카에 의해 다양한 데이터베이스, 결과 세트가 스토리지 엔진의 여러 종류를 다시 기록됩니다 계산 하둡 클러스터 전체 보조금 금액에 푸시 보여줍니다 쿼리의 결과.
기존의 하둡 아키텍처, 이러한 파이프 라인에 카프카에 의해 수집 된 로그 데이터와 같은 구조화 된 데이터의 다양한 유형, 클러스터의 HDFS에 기록 카프카 실시간 소비 데이터를 스파크. RDS를의 데이터가 전체 금액의 불꽃을 사용하는 데이터베이스와 같은 정기적으로, HDFS에 일반적으로 하루에 한 번주기를 테이블 동기화를 쓸어 비즈니스 피크 시간을 동기화 할 수 있습니다. HDFS 스토리지의 사용은 사용자의 데이터를, 관련 데이터베이스 데이터가 실제로 일반 스냅 샷 요약 한 것입니다. 예를 들어, 하루 방문의 요약을 포함 초, 공동 분석의 사용자 행동 정보를 기록 오늘의 분석 보고서를 생성 할 데이터베이스에서 아침에 매일 같은 사용자의 성향 사용하는 의사 결정의 머리에, 보고서 및 기타 데이터를 소비합니다. 아키텍처는 HDFS 자체는 단지 분산 파일 저장, 갱신, 친절한없는 기록적인 수준을 삭제 주로 인해, 전체 RDS 데이터 저장 볼륨 이유. 따라서, 이러한 데이터베이스의 통합이 삭제 논리를 수정 단순화하기 위해, 소규모 데이터의 경우에 검사의 전체 양에 의해 선택됩니다. HDFS를 기반으로 같은 동네 짱 아키텍처와 같은 대용량 데이터베이스의 데이터는, 수정 및 삭제를 지원하는 스토리지 엔진을 개발했다합니다.
이 패키지의 특징 데이터가 정적 분석 높은 동시성 하둡 클러스터에 의해,되었음을되는 데이터 청크 HDFS에 저장하면서,보다 쉽게 백 PB TB의 순서 오프라인 계산 및 데이터 동작들의 처리를 수행 할 수있다 통합 스토리지 비용은 상대적으로 낮다. 유일한 단점은 데이터 기억 정기적으로 데이터의 적시성 전형적 T + 1을 계산된다는 것이다. 비즈니스 측면 실시간 수요 근처 추천 한 경우, 인프라는 계산 오프라인에서 업그레이드 할 것 "람다 아키텍처를." 다음도 아키텍처이다
람다 아키텍처
상세 수있는 참조 람다 설명 .
오프라인 및 실시간 컴퓨팅 증분 저장 및 카프카의 HDFS 전액을 통해 스토리지의 두 가지 유형을 필요로 달성하기 위해. 기본적으로 메모리의 전체 양이 여전히 T + 1 개 유형을 HDFS. 그러나 카프카 도킹 흐름에 의해 계산 된 실시간 컴퓨팅 요구를 만회한다. 즉, 저장 및 실시간 서비스를 달성하기 위해 계산 로직에 대한 수요가 더 많은 것이다.
전통적인 오프라인 분석 아키텍처 람다 아키텍처 여부 결과 집합은 여전히 상대적으로 클 수 있고, 구조화 저장 시스템에 유지하는 것이 필요하다. 이 시점에서 결과로 주요 스토리지 등등 실시간 시장,보고, 임시 쿼리 BI 비즈니스 의사 결정자와 같은 쿼리를 설정합니다. 그래서 주류 접근 방식은 결과 RDS를 작성하는 것입니다 다음 Elasticsearch 또는 ES의 주요 수단이 강력한 전체 텍스트 검색 및 여러 필드 조합을 조회 할 수있는 기능을 희망 Elasticsearch에 직접 작성하는 동기화.
NoSQL에 분산 데이터베이스 스키마
하고 일괄 계산이 필요 RDS 우리가 쉽게 찾을 수있는 아키텍처 전에는 정적 HDFS 데이터가 일괄 계산을 형성하기 위해 동기화 할 수 있습니다. 이 아키텍처는 적시성이 자원이 어떻게이 문제를 최적화하는 마무리, 동기화되지 않은 경우에도 가난, 장면, 많은 양의 데이터를 하루 종일, 동기화의 전체 금액이 발생할 수 있습니다? 우리는 자체 데이터베이스, CRUD 작업을위한 직접 지원되는 데이터웨어 하우스 생각할 수 있다면, 그 어떤 동기화 전액을 의미하지 않을 것이다! 심지어 일부 온라인 데이터가이 거대한 데이터베이스에 직접 기록 될 수 많은 오픈 소스 프로그램 바로 산업이 인프라를 구축하는 등 HBase와 같은 분산 형 NoSQL 데이터베이스를 기반으로합니다. 이는도의 간단한 예이다. HBase를 스키마 무료 CRUD 작업 및 실시간 지원은 크게 데이터 소스 데이터 동기화 문제에 기록되어 실시간을 단순화합니다. 동시에, 넓은 테이블에서 대용량 데이터 소스를 만들 큰 폭의 계산을 통해 완벽한 데이터 테이블을 구축의 복잡성이 크게 감소 될 것입니다 가입 할 수 있습니다. 한편 HBase를 조합 카프카도 달성 될 수 람다 배치 및 흐름 요구 사항의 두 가지 유형을 지원한다. 이 아키텍처는 완벽한하는지? 당신은 할 수 완전히 프로그램 교체 ?
대답은 분명하지 않다 한편 HBase를 데이터가 기록되는 좋은 실시간을 지원하기에, LSM 스토리지 엔진의 사용은 새로운 데이터웨어 하우징 방법, 데이터 업데이트를 추가함으로써, 및 병합 최적화 의존 배경 작업을 읽을 줄 병합합니다. 데이터 읽기 및 정적 파일을 직접 읽고 HDFS 쓰기보다 엔진의 이러한 유형의 비용이 더 높다 지원하기 위해 데이터를 기록. 행으로 구성되어 디스크 저장 형식 오프 반면 HBase와 데이터, 즉, 우리는 보통 라인 스토리지 말한다. 스캔 된 데이터의 압축 및 지지체에 일괄 처리 능력 행 훨씬 적은 메모리 칼럼이며, 프로그램은 그러한 HDFS 마루 오크 또는 열 저장소를 선택하는 경향이있다. 데이터의 양이 수백 또는 PB PB로 성장 때, 배치 분석을 위해 전체 금액 HBase를 저장, 그것은 성능 병목 현상을 발생합니다 비용 측면에서 가능하다. 그래서 주류 HBase를 프로그램은 프로그램의 조합 전체 인프라 비용을 제어하고 확장 성을 향상시킬 수 있도록 구조화 된 다양한 유형의 데이터를 저장하는 HDFS HBase와 방법의 사용을 촉진 할 것이다. 그러나,이 조합은 또한 문제, 작업을 생성하고 유지 관리 구성 요소는 어려움이 증가 증가했다. 동시에 비즈니스 요구에 따라 분할 또는 HDFS HBase를 냉온수 계층화 데이터의 개수. 장면이 계층의 경우, 얼마나 편리 유입 HDFS의 데이터를 HBase를, 이들은 진짜 문제입니다.
AP 분석 데이터베이스 엔진 프로그램과 결합
데이터 임시 쿼리 결과 집합의 문제를 해결하지 않는 NoSQL에의 솔루션의 측면에서, HBase를,하지만 임시 쿼리 지원보다 다중 필드 노력 자체를 기반으로 Rowkey 쿼리를 지원할 수 있습니다. 일부 수석 플레이어 제조업체는 쿼리 속도를 HBase와 도킹 SOLR 또는 사용자 정의 인덱스의 다양한 종류의 자신의 차 개발을 기반으로하고 피닉스는 분산 컴퓨팅 파워를 구현하는 도킹됩니다. 이 복잡한 개발이다, 다중 구성 요소 통합 기능은 기본적으로 인 TP 데이터베이스 AP를주고 싶다. 그것은 또한 완전한 분석 프레임 워크를 달성하기 위해 TP AP 엔진의 도입과 함께 우리의 엔진 아키텍처 당연하다.
상호 작용 분석은 클러스터 기반 ClickHouse 분석 엔진, 분석 엔진에 동기화 된 구조화 된 각종 데이터의 세트를 구성하여, 상기 한 바와 후 예에서는 편리 할 수있다. 그 자체가 또한 데이터베이스와 같은 읽기와 쓰기 능력을 제공하지만 엔진이 유형의 포괄적 인 분석 엔진을 제공 주로하기 때문에 이전 아키텍처에 비해이 아키텍처 보인다는 단계의 수를 간소화합니다.
쿠두 - AP는 주류 엔진을 사용할 수 있습니다 산업, 등 드루이드, ClickHouse, Piont, Elasticsearch 또는 열 저장소 버전 HBase를 분산. 이러한 시스템은 또한 데이터의 사전 중합 좋은 추가] 현장 재분석는 드루이드로 지원하기로 서로 다른 강조점을 가지고, 직접 쿠두처럼 Elasticsearch의 분석 속도를 IO 강력한 필터 기능 인덱스의 수를 줄임으로써, 달성하기 위해 인덱스의 모든 종류가있다 최적화 HBase를 일괄 스캔 기능을 하나의 라인을 운영 할 수있는 능력을 유지하면서, 영구 저장소 형식은 컬럼에 돌았 다. 이러한 시스템이 공통적으로 가지고있는 것은 데이터가 열 예금을 기반으로한다는 것입니다, 엔진의 일부 역 색인을 도입, 비트 맵 인덱싱은 더 쿼리 속도. 이 아키텍처의 장점은 스토리지 엔진을 희망하는 실시간 배치 컴퓨팅, 결과를 보여주는 실시간 좋은 저장 및 계산 푸시 형식 자체를 지원, 직접 옆 전통적인 오프라인 빅 데이터 아키텍처입니다. 이전 아키텍처에 비해 100TB GB 수준이 아키텍처에서 크게이 시간이 실시간으로 계산되며 오프라인 배치 컴퓨팅의 경계가 흐려 될 경우에도에서 개선 된 데이터 집합의 TB 수준은 분 초에있을 수 있습니다 응답, 더 이상 기존의 빅 데이터 아키텍처와 같은 BI 직원은 크게 데이터를 속도, 몇 분 또는 몇 시간 오프라인 컴퓨팅 클래스를 최종 결과를 얻기 위하여의 행위 후 T + 1 개 데이터 동기화 지연을 기다려야 비즈니스에 가치를 제공 속도. 이 아키텍처는 터미네이터 큰 데이터를 처리하는 구성 될 것이라고? 이 아키텍처가 좋은 확장 성을 가지고 있지만 있기 때문에 물론, 짧은 시간을 생각하지 않지만, 오프라인 처리 백 PB는 확장 성, 복잡한 컴퓨팅 시나리오와 스토리지 비용은 여전히 상대적으로 약한 하둡 솔루션에 비해. 이러한 Elasticsearch의 전체 지표로, 지수 자체는 일반적으로 세 번 저장 공간의 확장을 가져올 것이다, 일반적으로는 SSD 저장 매체에 의존 할 필요가있다. 구조를 계산하는 데 필요한 데이터의 이러한 종류의 모든 다른 측면은 실시간 계산을 위해 메모리에로드됩니다, 또한 계산의 적시성에 영향을 미칠 수있는 무거운 계산 논리가있는 경우 두 개의 큰 테이블, 현장 참여를 지원하기는 어렵다. ETL 장면 TB 수준이나 데이터의 수준 이상은 엔진의이 유형에 좋지 않다.
구름 호수 Datalake 프로그램 데이터
호수 AWS 데이터가 기존의 하둡 클라우드 바닥 계획 및 업그레이드, 기본 스토리지 엔진 S3 구름의 도움으로 이해 될 수있는이 기법, 분산 자기 HDFS 클러스터를 유지하면서 모든 종류의 데이터가 추가 스토리지 비용 및 운영과 기존 솔루션의 유지 보수를 감소 호수에 빠르고 쉽게 데이터를 달성하기 위해 같은 운동성 파이어 호스 및 접착제 등의 강력한 파이프 라인 기능을 이용하여 외부 저장 안정성 및 높은 처리량. 이 아키텍처는 또한 사용자가 다른 사용 시나리오, 사용 데이터 분석의 복잡성과 다를 수 적시성에 대한 구별하고 정의를 만들기 위해 빅 데이터 플랫폼의 예입니다, 이것은 우리가 언급 한 프로그램은 또한 이전과 바이 같은 상황. 물론,이 데이터 솔루션 호수 자체는 데이터웨어 하우징 자성을하거나 효율적으로 데이터 업데이트를 지원하고 삭제하는 방법과 같은 호수의 데이터 품질을 보장하는 방법으로 기존의 프로그램의 모든 고통 포인트가 해결되지 않습니다.
델타 호수
云上希望通过数据湖概念的引入，把数据进行汇总和分析。同时借助于云上分布式存储的技术红利，在保证数据的可靠性前提下大幅降低汇总数据持久化存储的成本。同时这样一个集中式的存储也使得我们的大数据分析框架自然演进到了存储计算分离的架构。存储计算分离对分析领域的影响要远大于OLTP数据库，这个也很好理解，数据随着时间不断累积，而计算是根据业务需求弹性变化，谷歌三驾马车中的GFS也是为了解决这个问题。数据湖同时很好的满足了计算需要访问不同的数据源的需求。但是数据湖中的数据源毕竟有不同，有日志类数据，静态的非结构化数据，数据库的历史归档和在线库的实时数据等等。当我们的数据源是数据库这类动态数据时，数据湖面临了新的挑战，数据更新如何和原始的数据合并呢？当用户的账号删除，我们希望把数据湖中这个用户的数据全部清除，如何处理呢？如何在批量入库的同时保证数据一致性呢。Spark商业化公司Databricks近期提出了基于数据湖之上的新方案『Delta Lake』。Delta Lake本身的存储介质还是各类数据湖，例如自建HDFS或者S3，但是通过定义新的格式，使用列存来存base数据，行的格式存储新增delta数据，进而做到支持数据操作的ACID和CRUD。并且完全兼容Spark的大数据生态，从这个角度看Databricks希望引入Delta Lake的理念，让传统Hadoop擅长分析静态文件进入分析动态数据库源的数据，离线的数据湖逐步演进到实时数据湖。也就是方案二和三想解决的问题。
介绍了这些结构化数据平台的架构后，我们再来做一下总结，其实每套架构都有自己擅长的方案和能力：
| 适合场景 | 数据规模 | 存储格式 | 数据导入模式 | 成本 | 计算方式 | 方案运维复杂度 | 数据变更性 | |
|---|---|---|---|---|---|---|---|---|
| 传统Hadoop | 海量数据离线处理 Append为主的场景 |
大 | 列存 | 批量离线 | 低 | MapReduce | 较高 | 不可更新 静态文件 |
| 分布式NoSQL数据库 | 海量数据，支持实时CRUD 批量离线处理，可以部分做方案一的结果存储集 |
中上 | 行存 | 实时在线 | 中 | MapReduce | 中 | 可更新 |
| 分布式分析型数据库 | 实时/近实时入库，即席查询分析，经常做为方案一的结果存储集 | 中 | 行列混合 | 实时/近实时 | 高 | MPP | 中 | 可更新 |
| 数据湖/DeltaLake | 海量数据离线处理，实时流计算 具备ACID和CRUD能力 |
大 | 行列混合 | 批量离线/近实时 | 低 | MapReduce | 中 | 可更新 |
通过上面对比我们不难看出，每套方案都有自己擅长和不足的地方。各方案的计算模式或者计算引擎甚至可以是一个，例如Spark，但是它们的场景和效率确相差很大，原因是什么呢？区别在于存储引擎。这里我们不难看出大数据的架构抛开计算引擎本身的性能外，比拼的根本其实是存储引擎，现在我们可以总结一下大数据分析平台的需求是什么：在线和分析库的隔离，数据平台需要具备自己的存储引擎，不依赖于在线库的数据，避免对线上库产生影响。有灵活的schema支持，数据可以在这里进行打宽合并，支持数据的CRUD，全量数据支持高效批量计算，分析结果集可以支持即席查询，实时写入支持实时流计算。
综上所述，架构的区别源自于存储引擎，那是否有一些解决方案可以融合上面的各类存储引擎的优点，进一步整合出一套更加全面，可以胜任各类业务场景，也能平衡存储成本的方案呢？ 下面我们就来一起看看构建在阿里云上的一款云原生结构化大数据存储引擎：Tablestore如何解决这些场景和需求。
Tablestore的存储分析架构
Tablestore是阿里云自研的结构化大数据存储产品，具体产品介绍可以参考官网以及权威指南。Tablestore的设计理念很大程度上顾及了数据系统内对结构化大数据存储的需求，并且基于派生数据体系这个设计理念专门设计和实现了一些特色的功能，也通过派生数据能力打通融合了各类存储引擎。Tablestore的基本设计理念可以参考这篇文章的剖析。
大数据设计理念
- 存储计算分离架构：采用存储计算分离架构，底层基于飞天盘古分布式文件系统，这是实现存储计算成本分离的基础。
- CDC技术：CDC即数据变更捕获，Tablestore的CDC技术名为Tunnel Service，支持全量和增量的实时数据订阅，并且能无缝对接Flink流计算引擎来实现表内数据的实时流计算。基于CDC技术可以很便捷的打通Tablestore内的各类引擎以及云上的其他存储引擎。
- 多存储引擎支持：理想的数据平台希望可以拥有数据库类的行存，列存引擎，倒排引擎，也能支持数据湖方案下的HDFS或者DeltaLake，热数据采用数据库的存储引擎，冷全量数据采用更低成本数据湖方案。整套数据的热到冷可以做到全托管，根据业务场景定制数据在各引擎的生命周期。Tablestore上游基于Free Schema的行存，下游通过CDC技术派生支持列存，倒排索引，空间索引，二级索引以及云上DeltaLake和OSS，实现同时具备上述四套开源架构方案的能力。
- 최종 방문 데이터는 데이터 호수 OSS를 보관해야합니다 시간이 지남에 따라 우리의 뜨거운 데이터가 차가운 데이터가 될 때 물론, 여기에 이해, 데이터 보관이 점차 OSS, OSS, 심지어 아카이브 저장소를 입력 수밖에 없다. 이것은 우리가 PB 수준의 데이터 고 가용성 스토리지의 가장 낮은 비용을 달성 할 수 있습니다. 동시에 얼굴에서 분석 시나리오의 아주 가끔 전액은 또한 처리량의 상대적으로 안정적인 속도를 원하는 파일에서 효과적 일 수있다. Tablestore에 따라서 빅 데이터 플랫폼은 결국 우리는 OSS에 신고를 추천 할 것입니다.
우리는 특정 아키텍처 선택이 비즈니스 시나리오와 결합 될 수있다 Tablestore에 따라보다 쉽게 이러한 아이디어의 4 개 세트 다음과 같은 인프라를 구축 말할 수있는, 쉽게 동적 스위칭 솔루션을 얻을 수 있습니다 :
- 고 부가가치 데이터 , 높은 동시성 포인트 쿼리를 갖고 싶어, 임시 쿼리 및 분석 기능 (9 월 출판) :
저가의 스토리지와 결합 된 높은 처리량의 넓은 테이블, 임시 쿼리 및 분석 TB 수준의 데이터를 제공 할 수있는 동안 넓은 테이블의 Tablestore 조합이 아키텍처를 통합 CDC 기술 지수 분석 엔진의 Tablestore 터널, 옵션 2, 3과 유사 용량. 이 아키텍처의 가장 큰 장점은 효율적인 실시간 분석 기능을 달성하기 위해 별도의 컴퓨팅 엔진에 이상 의존 할 필요가 없다.
- 엄청난 양의 데이터, 고주파 업데이트되지 않은 데이터는 EMR은 (그래서 계속 지켜봐 주시기 곧) 클라우드 클러스터를 가지고 :
Tablestore 다양한 조합 테이블은, 터널 Tablestore CDC 유도 기술 데이터, 및 스트리밍 스파크 DeltaLake은 반응식 1과 유사한 개방형 아키텍처를 구축 4. CDC 기술에 의해, EMR 클러스터 스파크 스트리밍 실시간 가입 증분 데이터 Tablestore 터널 호수를 지원하는 데이터 CRUD를 병합 DeltaLake 능력, 데이터 수정, 데이터 삭제에 의해, EMR 클러스터 DeltaLake 기록됩니다. 배치는 높은 처리량 분석 기능 스파크 클러스터의 수단 계산합니다.
- 대규모 데이터, 적은 데이터 업데이트, 데이터 파티션 크게 차원 속성 (예를 들어, 데이터 계층 타임 스탬프에 해당하는 속성) :
Tablestore 조합 넓은 테이블, CDC, OSS와 DLA, 완벽하게 관리 아키텍처의 저렴한 비용으로 건설 방식의 Tablestore 터널 기술. 실시간 데이터는 주기적으로 동기의 Tablestore, CDC 기술에 의해, Tablestore 충분히 관리 할 데이터를 기록하거나 OSS로 푸시 상기 OSS 데이터 처리량은 연산 처리부 배치 스파크에 의해 달성 될 수있다. 이 프로그램의 가장 큰 장점은 저장하고 운영 및 유지 보수 비용이 상대적으로 낮은 것입니다.
- 전체 엔진 통합 프로그램 :
Tablestore 조합 넓은 테이블은 CDC 기술, 다변량 분석 엔진, 자동 DeltaLake / OSS 보관 감기 데이터입니다. 이 열 데이터는 넓은 테이블 구조 병합, 두 번째 수준의 임시 쿼리 및 분석 기능을 달성 오프라인 대량 처리량 컴퓨팅 파워 차가운 데이터를 제공합니다. 이러한 아키텍처는 냉장 보관 비용의 균형을 가지고 지연 데이터를 계산할 수 있습니다.
总结一下，基于Tablestore的大数据架构，数据写入都是Tablestore的宽表行存引擎，通过统一写来简化整个写入链路的一致性和写入逻辑，降低写入延时。大数据的分析查询的需求是多样化的，通过数据派生驱动打通不同引擎，业务可以根据需求灵活组合派生引擎是势不可挡的趋势。同时强调数据的冷热分层，让热数据尽可能的具备最丰富的查询和分析能力，冷数据在不失基本批量计算能力的同时尽可能的减少存储成本和运维成本。这里说的大数据架构主要说批计算和交互分析这部分，如果是实时流计算需求，可以参考我们的云上Lambda Plus架构。
存储引擎方面Tablestore，基于分布式NoSQL数据库也就是行存做为主存储，利用数据派生CDC技术整合了分布式分析型数据库支持列存和倒排，并结合Spark生态打造Delta Lake以及基于OSS数据湖。在计算查询方面，Tablestore自身通过多维分析引擎或者DLA支持MPP，借助于Spark实现传统MapReduce大数据分析。未来我们也会规划在查询侧打通计算引擎的读取，可以做到基于查询语句选取最佳的计算引擎，例如点查命中主键索引则请求访问行存，批量load分析热数据则访问数据库列存，复杂字段组合查询和分析访问数据库列存和倒排，历史数据定期大批量扫描走DeltaLake或者OSS。我们相信一套可以基于CDC技术统一读写的融合存储引擎会成为未来云上大数据方案的发展趋势。
总结和展望
이 문서에서 우리는 빅 데이터 아키텍처를 구성 일반적인 오픈 소스에 대해 이야기하고, 각 세트 아키텍처의 특성을 분석한다. 요약 및 강수량의 기존 구조를 분석함으로써, 클라우드 플랫폼 Tablestore 구성 저장 및 향후 빅 데이터 분석 지원을 할 수있는 능력에 우리를 이끈다. 이 CDC 기반의 빅 데이터 플랫폼 TP AP 클래스를 수행 할 수 있으며, 다양한 데이터를 가장 완벽하게 관리 통합을 필요로 희망, 전체 서버를 사용하지 않는 아키텍처는, 우리의 컴퓨팅 및 스토리지 자원을 충분히 활용 될 수 있습니다 데이터 중심의 사업 개발 때문에 더 나아가.
대용량 데이터 스토리지를 기반으로 Tablestore 분석 프레임 워크에 관심있는 친구들이 우리의 기술 교류 그룹 (손톱 : 23307953 또는 11789671)에 가입 할 수 있다면, 우리와 함께 논의합니다.