안정성 이해

이 문서에서는 가용성, 내구성, 데이터 일관성, 성능 일관성, 데이터 복구, 오류 처리 고려 사항 검토와 같은 BigQuery 신뢰성 기능에 대해 설명합니다.

이 소개는 3가지 주요 고려사항을 해결하는 데 도움이 됩니다.

• BigQuery가 해당 작업에 적합한 도구인지 확인합니다.
• BigQuery 신뢰성의 측정기준을 이해합니다.
• 특정 사용 사례의 구체적인 신뢰성 요구사항을 파악합니다.

BigQuery 선택

BigQuery는 대규모 데이터 세트를 저장하고 분석하도록 설계된 완전 관리형 엔터프라이즈 데이터 웨어하우스입니다. 기본 인프라를 관리하지 않고도 메가바이트에서 페타바이트 단위의 데이터를 일관된 성능으로 수집, 저장, 읽기, 쿼리할 수 있는 방법을 제공합니다. BigQuery의 기능과 성능 덕분에 BigQuery는 다양한 솔루션에 적합합니다. 그 중 일부를 참조 패턴으로 자세히 설명하였습니다.

일반적으로 BigQuery는 대량의 데이터가 수집 및 분석되는 워크로드에 매우 적합합니다. 특히 실시간 및 예측 데이터 분석(스트리밍 수집 및 BigQuery ML), 이상 감지, 예측 가능한 성능으로 대량의 데이터를 분석하는 것이 핵심인 기타 사용 사례에 효과적으로 배포할 수 있습니다. 그러나 온라인 트랜잭션 처리(OLTP) 스타일 애플리케이션을 지원하는 데이터베이스를 찾고 있다면 해당 사용 사례에 더 적합한 Spanner, Cloud SQL 또는 Bigtable과 같은 다른 Google Cloud 서비스를 고려해야 합니다.

BigQuery의 신뢰성 측정기준

가용성

가용성은 BigQuery에서 데이터를 읽거나 BigQuery에 데이터를 쓰는 사용자 기능을 정의합니다. BigQuery는 99.99% SLA를 통해 이 두 가지 기능 모두 가용성이 높도록 설계되었습니다. 이 두 작업에는 2가지 구성요소가 모두 포함됩니다.

• BigQuery 서비스
• 특정 쿼리를 실행하는 데 필요한 컴퓨팅 리소스

서비스의 신뢰성은 데이터를 검색하는 데 사용되는 특정 BigQuery API의 함수입니다. 컴퓨팅 리소스의 가용성은 쿼리가 실행되는 시점에 사용자에게 제공되는 용량에 따라 달라집니다. BigQuery의 기본 컴퓨팅 단위와 결과 슬롯 리소스 절약 모드에 대한 자세한 내용은 슬롯 이해를 참조하세요.

내구성

내구성은 SRE 통합문서의 SLO 구현 챕터에 설명되어 있으며 '성공적으로 읽을 수 있는 데이터 비율'로 설명되어 있습니다.

데이터 일관성

일관성은 데이터가 작성되거나 수정된 후 데이터를 쿼리할 수 있는 방법에 대한 사용자의 기대치를 정의합니다. 데이터 일관성의 한 가지 측면은 데이터 수집을 위해 '딱 한 번' 시맨틱스를 보장하는 것입니다. 자세한 내용은 데이터 로드의 예시 사용 사례 및 실패한 작업 삽입 재시도의 '솔루션 안정성'을 참조하세요.

성능 일관성

일반적으로 성능은 두 가지 측정기준으로 표현할 수 있습니다. 지연 시간은 쿼리와 같은 긴 데이터 검색 작업의 실행 시간을 측정합니다. 처리량은 BigQuery가 특정 기간 동안 처리할 수 있는 데이터의 양을 측정합니다. BigQuery의 멀티 테넌트 및 수평 확장 설계 덕분에 처리량을 임의의 데이터 크기로 확장할 수 있습니다. 지연 시간 및 처리량의 상대적 중요도는 특정 사용 사례에 따라 결정됩니다.

데이터 복구

서비스 중단 후 데이터를 복구하는 기능을 측정하는 두 가지 방법은 다음과 같습니다.

• 복구 시간 목표(RTO). 이슈 이후 데이터를 사용할 수 없는 기간입니다.
• 복구 지점 목표(RPO). 이슈 발생 전에 수집된 데이터 중 손실해도 되는 양입니다.

이러한 고려사항은 영역 또는 리전에 여러 날에 걸친 중단 또는 파괴적인 중단이 발생하는 드문 경우와 관련이 있습니다.

재해 복구 계획하기

'재해 발생' 시 자연 재해의 비전을 호출할 수 있지만 이 섹션에서는 한 리전 내에서의 치명적인 손실까지 이어지는 개별 머신의 손실에 따른 특정 장애를 다룹니다. 전자는 BigQuery가 자동으로 처리하는 일상적인 작업이지만, 후자는 필요한 경우 고객이 아키텍처에서 처리하도록 설계해야 할 수 있습니다. 따라서 재해 복구 계획이 고객 책임에 적용되는 범위를 이해하는 것이 중요합니다.

BigQuery는 업계 최고의 99.99% 업타임 SLA를 제공합니다. 이는 서로 다른 두 영역에 데이터를 쓰고 중복 컴퓨팅 용량을 프로비저닝하는 BigQuery의 리전 아키텍처를 통해 가능합니다. BigQuery SLA는 리전(예: us-central1)과 멀티 리전(예: US)에서 동일하다는 점을 염두에 두어야 합니다.

자동 시나리오 처리

BigQuery는 리전 서비스이므로, 머신 또는 전체 영역의 손실을 자동으로 처리하는 것은 BigQuery의 책임입니다. BigQuery는 영역 위에 구축되며 사용자로부터 분리됩니다.

머신 손실

머신 장애는 Google이 운영하는 범위에서 매일 발생하는 현상입니다. BigQuery는 포함 영역에 영향을 미치지 않고 머신 장애를 자동으로 처리하도록 설계되어 있습니다.
쿼리 실행은 여러 머신과 동시에 전달될 수 있는 소규모 태스크로 분할됩니다. 머신 성능의 갑작스러운 손실이나 성능 저하는 다른 머신에 작업을 다시 전달하는 방식으로 자동으로 처리됩니다. 이러한 접근 방식은 꼬리 지연 시간을 줄이는 데 매우 중요합니다.

BigQuery는 Reed–Solomon 인코딩을 사용하여 데이터의 영역 복사본을 효율적이고 영구적으로 저장합니다. 매우 드물게 여러 머신 장애로 인해 영역 복사본이 손실되는 경우 하나 이상의 다른 영역에 데이터가 동일한 방식으로 저장됩니다. 이 경우 BigQuery가 문제를 감지하고 중복 데이터를 복원하기 위해 데이터의 새 영역 복사본을 만듭니다.

영역 손실

특정 영역에서는 컴퓨팅 리소스의 기본 가용성이 BigQuery의 99.99% 업타임 SLA를 충족하기에 부족합니다. 따라서 BigQuery는 데이터와 컴퓨팅 슬롯 모두에 대한 자동 영역 중복을 제공합니다. 일반적이지는 않지만 단기 영역 장애가 발생합니다. 하지만 BigQuery 자동화를 통해 심각한 중단이 발생하면 1~2분 내에 다른 영역으로 쿼리를 장애 조치합니다. 이미 진행 중인 쿼리는 즉시 복구되지 않을 수 있지만 새로 실행된 쿼리는 바로 복구됩니다. 새로 실행된 쿼리는 빠르게 완료되는 반면 진행 중인 쿼리는 완료되는 데 오랜 시간이 걸릴 것입니다.

영역을 장기간 사용할 수 없게 되더라도 BigQuery에서 데이터를 두 영역에 동기식으로 쓰므로 데이터가 손실되지 않습니다. 따라서 영역 손실에도 불구하고 고객은 서비스 중단을 경험하지 않습니다.

장애 유형

장애 유형에는 소프트 장애와 하드 장애 두 가지 유형이 있습니다.

소프트 장애는 하드웨어가 파괴되지 않는 작업 결함입니다. 예시로 전원 오류, 네트워크 파티션 또는 머신 비정상 종료를 들 수 있습니다. 일반적으로 BigQuery는 소프트 장애 발생 시 데이터가 손실되면 안 됩니다.

하드 장애는 하드웨어가 파괴되는 작업 결함입니다. 하드 장애는 소프트 장애보다 더 심각한 장애입니다. 하드 장애의 예시로 홍수, 테러리스트 공격, 지진, 허리케인으로 인한 손상을 들 수 있습니다.

가용성 및 내구성

BigQuery 데이터 세트를 만들 때 데이터를 저장할 위치를 선택합니다. 이 위치는 다음 중 하나입니다.

• 리전: 아이오와(us-central1) 또는 몬트리올(northamerica-northeast1)과 같은 특정 지리적 위치
• 멀티 리전: 미국(US) 또는 유럽(EU)과 같이 두 개 이상의 지리적 장소를 포함하는 큰 지리적 영역

두 경우 모두에서 BigQuery는 선택된 위치의 단일 리전 내에 있는 두 개의 서로 다른 Google Cloud 영역에 데이터 복사본을 자동으로 저장합니다.

스토리지 중복성 외에도 BigQuery는 여러 영역에 걸쳐 중복 컴퓨팅 용량을 유지합니다. BigQuery는 여러 가용성 영역에 걸쳐 중복 스토리지와 컴퓨팅을 결합하여 고가용성과 내구성을 제공합니다.

참고: 멀티 리전 위치를 선택해도 리전 간 복제 또는 리전 중복성이 제공되지 않습니다. 데이터가 지리적 위치 내의 단일 리전에 저장됩니다.

머신 수준 장애가 발생하는 경우 BigQuery가 약간의 밀리초 지연만 있을 뿐 계속 실행됩니다. 현재 실행 중인 쿼리는 계속 처리됩니다. 소프트 또는 하드 영역 장애가 발생하는 경우 데이터 손실은 발생하지 않습니다. 그러나 현재 실행 중인 쿼리가 실패하여 다시 제출해야 할 수 있습니다. 정전, 파괴된 변압기 또는 네트워크 파티션으로 인한 소프트 영역 장애는 잘 테스트된 경로이며 몇 분 내에 자동으로 완화됩니다.

리전 전체의 네트워크 연결 손실과 같은 소프트 리전 장애로 인해 리전이 다시 온라인 상태가 될 때까지 가용성이 손실될 수 있지만 데이터는 손실되지 않습니다. 하드 리전 장애가 발생하는 경우(예: 재해로 인해 전체 리전이 파괴되는 경우) 해당 리전에 저장된 데이터가 손실될 수 있습니다. BigQuery는 다른 리전의 데이터 백업 또는 복제본을 자동으로 제공하지 않습니다. 재해 복구 전략을 향상하기 위해 리전 간 데이터 세트 복사본을 만들 수 있습니다.

BigQuery 데이터 세트 위치에 대한 자세한 내용은 위치 고려사항을 참조하세요.

시나리오: 리전 손실

BigQuery는 물리적 리전 손실이 전혀 발생하지 않으며 전례 없는 상황에서도 내구성이나 가용성을 제공하지 않습니다. 이는 '리전 및 멀티 리전' 구성 모두에 해당됩니다. 따라서 이러한 시나리오에서 내구성과 가용성을 유지하려면 고객 계획이 필요합니다. 네트워크 중단과 같은 일시적인 손실의 경우 BigQuery의 99.99% SLA가 충분하지 않다고 판단되면 중복 가용성을 고려해야 합니다.

파괴적인 리전 손실이 발생할 경우의 데이터 손실을 막으려면 데이터를 다른 지리적 위치에 백업해야 합니다. 예를 들어 데이터의 스냅샷을 지리적으로 다른 리전의 Google Cloud Storage에 주기적으로 내보낼 수 있습니다. 이를 위해서는 일괄 데이터 처리 사용 사례의 설명을 따르면 됩니다.
BigQuery 멀티 리전의 경우 멀티 리전 범위 내의 리전에 백업하지 않아야 합니다. 예를 들어 US에 있는 데이터를 us-central1 리전에 백업하지 마세요. 리전 및 멀티 리전이 장애 도메인을 공유하고 재해 발생 시 동일한 상황에 처할 수 있습니다. 대신 US 외 리전(예: northamerica-northeast1)에 데이터를 백업합니다. 데이터 상주 요구사항에 따라 미국 내에 백업을 저장해야 하는 경우 us-central1 및 us-east1과 같은 두 리전을 페어링하는 것이 좋습니다.

비가용성 확장을 방지하려면 지리적으로 별도의 BigQuery 위치 두 개에 데이터를 복제하고 슬롯을 프로비저닝해야 합니다. 위와 유사하게 리전과 멀티 리전을 혼합하여 재해 발생 시 동일한 상황에 처할 수 있습니다.

리전 중복 설정을 위한 가장 안정적인 아키텍처는 active-active라고도 하는 hot-hot을 실행하는 것입니다. 이 경우 워크로드가 기본 리전과 보조 리전 모두에서 동시에 실행됩니다. 많은 비용이 들지만 보조 리전이 지속적 확인을 받고 장애 조치해야 하는 경우에도 작동합니다. 리전 서비스 중단 시 가용성이 크게 중요하지 않은 경우 다른 리전에 데이터를 백업하면 내구성이 보장됩니다.

시나리오: 우발적 삭제 또는 데이터 손상

BigQuery에서는 BigQuery의 멀티 버전 동시 실행 제어 아키텍처를 통해 시간 여행을 지원합니다. 이 기능을 사용하면 지난 7일 동안의 특정 시점에서 데이터를 쿼리할 수 있습니다. 이렇게 하면 7일 이내에 잘못 삭제, 수정 또는 손상된 데이터를 셀프서비스로 복원할 수 있습니다. 시간 여행은 삭제된 테이블에서도 작동합니다.

BigQuery는 테이블 스냅샷 기능도 지원합니다. 이 기능을 사용하면 동일한 리전 내에서 7일 이상의 이동 기간 동안 데이터를 명시적으로 백업할 수 있습니다. 스냅샷은 전적으로 메타데이터 작업이므로 추가 스토리지 바이트가 없습니다. 이 경우 실수로 인한 삭제로부터 데이터를 보호할 수 있지만 데이터의 내구성은 증가하지 않습니다.

사용 사례: 실시간 분석

이 사용 사례에서는 스트리밍 데이터가 엔드포인트 로그에서 BigQuery로 지속적으로 수집됩니다. 전체 리전에 BigQuery 비가용성이 확장되는 것을 막으려면 지속적으로 데이터를 복제하고 다른 리전에 슬롯을 프로비저닝해야 합니다. 수집 경로에 Pub/Sub 및 Dataflow를 사용하기 때문에 아키텍처가 BigQuery 비가용성에 대해 복원력이 우수하면 이렇게 높은 수준의 중복성에 비용을 투자할 가치는 없을 것입니다.

사용자가 us-central1의 Archive Storage 클래스 아래의 Cloud Storage로 내보내기 작업을 사용하여 야간에 내보내도록 us-east4의 BigQuery 데이터를 구성했다고 가정해 보겠습니다. 이렇게 하면 us-east4에서 치명적 데이터 손실이 발생하는 경우 내구성 있는 백업을 제공합니다. 이 경우 최악의 경우 마지막으로 내보낸 백업에 최대 24시간이 걸릴 수 있으므로 복구 지점 목표(RPO)는 24시간입니다. Cloud Storage 백업에서 us-central1의 BigQuery로 데이터를 복원해야 하므로 복구 시간 목표(RTO)는 잠재적인 일 수입니다. 백업이 배치되는 리전과 다른 리전에서 BigQuery를 프로비저닝하려면 먼저 데이터를 이 리전으로 전송해야 합니다. 또한 복구 리전에서 사전에 중복 슬롯을 구매하지 않은 경우 요청된 수량에 따라 BigQuery 용량 프로비저닝이 추가적으로 지연될 수 있습니다.

사용 사례: 일괄 데이터 처리

이 사용 사례에서는 정해진 기한까지 일일 보고서를 작성하여 규제 기관에 전송하는 것이 비즈니스에 중요합니다. 전체 처리 파이프라인의 개별 인스턴스 2개를 실행하여 중복성을 구현하는 것은 비용을 투자할 가치가 있는 일입니다. 2개의 개별 리전(예: us-west1 및 us-east4)을 사용하면 리전의 비가용성이 확장되거나 드물지만 영구적인 리전 손실이 발생하는 경우를 대비한 지리적 분리와 2개의 독립적인 장애 도메인이 제공됩니다.

보고서를 한 번만 전달해야 한다고 가정할 경우 두 파이프라인이 모두 성공적으로 완료될 것으로 예상되는 사례를 조정해야 합니다. 적절한 전략은 성공적으로 완료할 경우 Pub/Sub 주제에 알리는 등의 방법을 통해 먼저 완료되는 파이프라인의 결과를 선택하는 것입니다. 또는 결과를 덮어쓰고 Cloud Storage 객체의 버전을 되돌립니다. 나중에 완료된 파이프라인에서 손상된 데이터를 작성하는 경우 Cloud Storage에서 먼저 완료된 파이프라인이 쓴 버전을 복원하여 복구하면 됩니다.

오류 처리

다음은 신뢰성에 영향을 미치는 오류를 해결하기 위한 권장사항입니다.

실패한 API 요청 재시도

클라이언트 라이브러리 및 파트너 도구를 포함한 BigQuery 클라이언트는 API 요청 실행 시 잘린 지수 백오프를 사용해야 합니다. 즉, 클라이언트가 시스템 오류 또는 할당량 오류를 수신한 경우 일정 횟수까지(무작위의 증가하는 백오프 간격으로) 요청을 재시도해야 합니다.

이 재시도 방법을 사용하면 오류 발생 시에 더욱 강력한 애플리케이션을 만들 수 있습니다. 정상적인 작동 상황에서도 BigQuery의 99.99% 가용성 SLA에 설명된 대로 요청 10,000개 중 1개 정도는 실패할 것으로 예상할 수 있습니다. 비정상적인 상황에서는 이 오류율이 증가할 수 있지만 오류가 무작위로 분산되면 지수 백오프 전략을 통해 최악의 경우는 어렵겠지만 거의 모든 상황을 완화할 수 있습니다.

5XX 오류로 요청이 지속적으로 실패하는 시나리오가 발생하면 Google Cloud 지원팀에 에스컬레이션해야 합니다. 문제가 올바르게 분류될 수 있도록 실패가 비즈니스에 미치는 영향을 명확하게 전달해야 합니다. 반면 4XX 오류로 요청이 지속적으로 실패하는 경우 애플리케이션을 변경하여 문제를 해결할 수 있습니다. 자세한 내용은 오류 메시지를 참조하세요.

지수 백오프 로직 예시

지수 백오프 로직은 재시도 간 대기 시간을 최대 백오프 시간까지 늘려 쿼리 또는 요청을 재시도합니다. 예를 들면 다음과 같습니다.

1. BigQuery에 요청합니다.

2. 요청이 실패하면 1 + random_number_milliseconds초 대기한 후 요청을 재시도합니다.

3. 요청이 실패하면 2 + random_number_milliseconds초 대기한 후 요청을 재시도합니다.

4. 요청이 실패하면 4 + random_number_milliseconds초 대기한 후 요청을 재시도합니다.

5. maximum_backoff 시간까지 이를 반복합니다.

6. 최대 재시도 횟수까지 계속 대기하고 재시도하지만 재시도 간 대기 시간을 늘리지는 않습니다.

다음에 유의하세요.

• 대기 시간은 min(((2^n)+random_number_milliseconds), maximum_backoff)이고, n은 반복(요청)할 때마다 1씩 증가합니다.

• random_number_milliseconds는 1,000밀리초 이하의 임의 숫자입니다. 이러한 무작위 순서 지정은 많은 클라이언트가 동기화되고 모두 동시에 재시도되어 일련의 동기화된 작업으로 요청을 보내는 상황을 피하는 데 도움이 됩니다. random_number_milliseconds 값은 각 재시도 요청 후 다시 계산됩니다.

• 최대 백오프 간격(maximum_backoff)은 일반적으로 32 또는 64초입니다. maximum_backoff의 적절한 값은 사용 사례에 따라 다릅니다.

클라이언트가 최대 백오프 시간에 도달한 후에도 계속 재시도할 수 있습니다. 이후 재시도는 백오프 시간을 계속 늘릴 필요가 없습니다. 예를 들어 클라이언트가 최대 백오프 시간으로 64초를 사용하는 경우 이 값에 도달한 후 클라이언트가 64초마다 계속 재시도할 수 있습니다. 특정 시점에서 클라이언트가 무한정 재시도하지 못하게 해야 합니다.

재시도 간 대기 시간과 재시도 횟수는 사용 사례 및 네트워크 조건에 따라 달라집니다.

실패한 작업 삽입 재시도

애플리케이션에 정확히 한 번의 삽입 시맨틱스가 중요한 경우 작업을 삽입할 때 추가적인 고려사항이 있습니다. 최대 1회 시맨틱스를 달성하는 방법은 지정한 WriteDisposition에 따라 다릅니다. 쓰기 처리는 테이블에 기존 데이터가 있을 때 수행해야 하는 작업(실패, 덮어쓰기 또는 추가)을 BigQuery에 알려줍니다.

WRITE_EMPTY 또는 WRITE_TRUNCATE 처리를 사용하면 실패한 작업 삽입 또는 실행을 간단히 재시도하여 이를 구현할 수 있습니다. 작업에서 수집하는 모든 행이 테이블에 원자적으로 기록되기 때문입니다.

WRITE_APPEND 처리를 사용하는 경우 클라이언트에서 동일한 데이터를 다시 추가하는 재시도를 방지하기 위해 작업 ID를 지정해야 합니다. BigQuery가 이전 작업의 ID를 사용하려고 시도하는 작업 생성 요청을 거부하기 때문에 가능한 방법입니다. 이렇게 하면 지정된 작업 ID에 대해 최대 1회 시맨틱스를 달성합니다. 그런 다음 이전의 모든 시도가 실패했음을 BigQuery에서 확인한 후 예측 가능한 새 작업 ID로 재시도하면 1회만 실행되는 시맨틱스를 달성할 수 있습니다.

일시적인 문제나 네트워크 중단으로 인해 작업이 삽입되었다는 확인 메시지가 API 클라이언트 또는 HTTP 클라이언트에 전송되지 않을 수도 있습니다. 삽입을 재시도하면 status=ALREADY_EXISTS(code=409 및 reason="duplicate")와 함께 요청이 실패합니다. 기존 작업 상태는 jobs.get을 호출하여 검색할 수 있습니다. 기존 작업의 상태가 retrieved가 되면 호출자는 새 작업 ID로 새 작업을 만들어야 하는지 확인할 수 있습니다.

사용 사례 및 신뢰성 요구사항

BigQuery는 다양한 아키텍처의 핵심 구성요소일 수 있습니다. 배포된 사용 사례 및 아키텍처에 따라 다양한 가용성, 성능 또는 기타 신뢰성 요구사항을 충족해야 할 수 있습니다. 이 가이드에서는 두 가지 기본 사용 사례와 아키텍처를 선택하여 자세히 설명합니다.

실시간 분석

첫 번째 예시는 이벤트 데이터 처리 파이프라인입니다. 이 예시에서는 엔드포인트의 로그 이벤트가 Pub/Sub를 사용하여 수집됩니다. 여기에서 스트리밍 Dataflow 파이프라인은 Storage Write API를 사용하여 BigQuery에 데이터를 쓰기 전에 데이터에 대한 일부 작업을 수행합니다. 이 데이터는 예를 들어 특정 엔드포인트 결과로 이어질 수 있는 이벤트 시퀀스를 다시 만들고 거의 실시간 대시보드를 제공하여 시각화를 통해 데이터의 트렌드 및 패턴을 감지하기 위한 임시 쿼리에 모두 사용됩니다.

이 예시에서는 신뢰성의 여러 측면을 고려해야 합니다. 엔드 투 엔드 데이터 최신 상태 요구사항이 매우 높으므로 수집 프로세스의 지연 시간이 중요합니다. 데이터가 BigQuery에 작성되면 신뢰성은 사용자가 일관되고 예측 가능한 지연 시간으로 임시 쿼리를 실행하고 데이터를 활용하는 대시보드가 사용 가능한 최신 정보를 반영하도록 보장하는 기능으로 간주됩니다.

일괄 데이터 처리

두 번째 예시는 금융 서비스 업계의 규정 준수를 기반으로 하는 일괄 처리 아키텍처입니다. 핵심 요구사항은 고정된 야간 기한까지 규제 기관에 일일 보고서를 제공하는 것입니다. 보고서를 생성하는 야간 일괄 프로세스가 이 기한까지 완료되면 충분히 빠른 것으로 간주됩니다.

데이터를 BigQuery에서 사용할 수 있어야 하고 대시보드, 분석, 궁극적으로 PDF 보고서 생성을 위해 데이터를 다른 데이터 소스와 결합해 합니다. 이러한 보고서를 오류 없이 적시에 제공하는 것이 중요한 비즈니스 요구사항입니다. 따라서 필요한 기한을 충족하는 일관된 기간 내에 데이터를 수집하고 올바른 보고서를 생성하는 신뢰성을 보장하는 것이 핵심입니다.

다음 단계