BigQuery에서 SAP 데이터 모델링 시 설계 고려사항

* 본 아티클의 원문은 2021년 7월 26일 Google Cloud 블로그(영문)에 게재되었습니다.  

지난 몇 년 동안 많은 조직이 SAP 솔루션을 Google Cloud로 마이그레이션하여 이점을 경험했습니다. 이러한 마이그레이션은 IT 유지보수 비용을 절감하고 데이터 보호를 강화하는 것 외에도 많은 이점을 제공합니다. SAP 고객은 BigQuery를 활용하여 기업 데이터를 통합하고 Google의 강력한 데이터 세트와 머신러닝을 통해 간편하게 확장하여, SAP 투자를 보완하고 최신 통계를 확보할 수 있습니다. 

선도적인 클라우드 데이터 웨어하우스인 BigQuery는 완전 관리형 서버리스 서비스로, 페타바이트급 대형 쿼리를 고속으로 지원할 수 있습니다. SAP 데이터를 Google Analytics나 Salesforce 같은 추가 데이터 소스와 간편하게 결합할 수 있고 내장 머신러닝을 통해 비교적 저렴한 비용으로 표준 SQL을 사용하는 머신러닝 모델을 운영할 수 있습니다. 

BigQuery의 장점을 활용하여 분석 역량을 향상하려는 SAP 기반 조직이라면 SAP 데이터 모델링 시 고려사항 및 권장사항에 대해 알아보세요. 본 가이드라인은 고객에게 실제 구현한 경험을 기반으로 작성되었으며 기업에 필요한 분석 역량을 구축하기 위한 로드맵 역할을 할 수 있습니다.

데이터 복제 시 고려사항

대부분의 기술 여정과 마찬가지로 데이터 복제도 비즈니스 목표부터 시작해야 합니다. 설계 프로세스 초기 단계에 적절한 결정을 내리기 위해서는 의도한 비즈니스 가치와 목표를 염두에 두어야 합니다.

SAP 시스템에서 BigQuery로 데이터를 복제하는 방법은 여러 가지가 있습니다. 다음 질문에 답하여 조직에 가장 적합한 방법을 결정하세요.

• 기업에 실시간 데이터가 필요한가요? 과거 데이터를 활용해야 하나요?

• 복제된 데이터에 어떤 외부 데이터 세트를 조인해야 하나요?

• 소스 구조나 비즈니스 로직이 변경될 가능성이 있나요? 조만간 SAP 소스 시스템을 마이그레이션할 예정인가요? 예를 들어 SAP ECC에서 SAP S/4HANA로 마이그레이션할 계획인가요?

아울러 테이블별로 복제할지 아니면 팀이 사전 빌드된 로직에서 데이터를 복제할 수 있는지도 판단해야 합니다. 이에 대한 결정과 더불어 라이선스 같은 기타 고려사항에 따라 어떤 복제 도구를 사용해야 하는지가 정해집니다. 

테이블별 복제

특히 원시 형태 표준 테이블의 경우 테이블을 복제하면 소스를 재사용하고 소스 구조 및 기능 출력의 안정성을 개선할 수 있습니다. 예를 들어 판매 주문 헤더(VBAK)용 SAP 테이블은 SAP 버전에 따라 구조가 바뀔 가능성이 매우 낮으며, 테이블에 작성하는 로직이 복제된 테이블에 영향을 미치는 방식으로 변경될 가능성도 낮습니다. 

추가 고려사항: 윈시 테이블을 비교할 때 소스 시스템과 BigQuery의 랜딩 테이블 사이의 조정이 선형이기 때문에 기말 마감과 같은 중요 비즈니스 프로세스 중 통합 문제를 방지하는 데 유용합니다. 복제된 테이블은 집계되거나 프로세스 전용 데이터 변환에 영향을 받지 않기 때문에 동일한 복제된 열이 다른 BigQuery 뷰에서 재사용될 수 있습니다. 예를 들어 MARA 테이블(자료 마스터)을 한 번 복제하면 필요한 만큼 많은 모델에서 사용할 수 있습니다. 

사전 빌드된 로직 복제

SAP 추출기나 CDS 뷰와 같이 사전 빌드된 모델을 복제하는 경우 기존 로직을 사용하기 때문에 BigQuery에 로직을 빌드하지 않아도 됩니다. 일부 추출 객체에서 델타 메커니즘을 삽입하여 델타를 처리할 수 없는 복제 도구를 보완할 수 있습니다. 이에 따라 초기 개발 시간이 절약되지만 새 열을 만들거나 맞춤설정 또는 업그레이드로 추출용 로직이 변경되면 문제가 발생할 수 있습니다. 

또한 다양한 추출 프로세스가 동일한 소스 열을 여러 번 변환하고 로드함에 따라 BigQuery에 중복이 발생하고 유지보수 필요성과 비용이 증가할 수 있습니다. 하지만 사전 빌드된 모델을 복제하면 계층 구조 평면화 같이 변경 불가능한 로직이나 매우 복잡한 로직에 특히 유용할 수 있으므로 여전히 좋은 선택이 될 수 있습니다.

복제 방식은 장기 계획과 더불어 개발자의 가용성(및 호기심)과 개발자가 새로운 데이터 웨어하우스에 SQL 지식을 적용하는 데 쏟을 수 있는 시간이나 노력 같은 다른 핵심 요소에도 좌우됩니다. 

BigQuery는 상시 추가하는 데이터베이스로 고안되었기 때문에 복제 프로세스를 설계할 때 어느 복제 방식을 선택하더라도 데이터 후처리와 변경이 필요하다는 것을 명심해야 합니다. 

데이터 변경사항 처리

어떤 복제 도구를 선택하는지에 따라 변경 데이터 캡처(CDC)로 알려진 데이터 변경사항 캡처 방식도 달라집니다. SAP SLT에서와 같이 복제 도구에서 허용되는 경우 BigQuery를 통한 CDC 문서에 설명된 동일한 패턴이 SAP 데이터에도 적용됩니다. 

트랜잭션 같은 일부 데이터는 마스터 데이터 같은 다른 데이터보다 덜 정적으로 알려져 있기 때문에 실시간으로 스캔해야 할 대상, 즉시 일관성이 필요한 대상, 비용 관리를 위해 일괄 처리할 수 있는 대상을 결정해야 합니다. 이 결정은 기업의 보고 수요에 따라 달라집니다.

비즈니스 파트너용 마스터 데이터 샘플이 포함된 SAP 테이블 BUT000을 살펴보세요. 여기에 SAP ERP 시스템의 변경사항이 복제되어 있습니다.

BigQuery는 복제 데이터를 상시 추가하기 때문에 모든 업데이트가 새 레코드로 수신됩니다. 예를 들어 소스에서 레코드를 삭제하면 BigQuery에 삭제 플래그와 함께 새 레코드로 표시됩니다. 이는 BUT000 같은 원시 테이블의 레코드든 BW 추출기 또는 CDS 뷰 같이 사전 합산 데이터든 관계없이 적용됩니다.

파트너 'LUCIA'와 'RIZ'의 데이터를 자세히 살펴보겠습니다. 작업 플래그를 통해 BigQuery의 새 레코드 유형이 삽입(I), 업데이트(U) 또는 삭제(D)인지 알 수 있고 타임스탬프를 통해서는 비즈니스 파트너의 최신 버전을 확인할 수 있습니다.

파트너 LUCIA와 RIZ에 대한 최신 업데이트된 레코드를 찾으려면 다음과 같이 쿼리를 작성해야 합니다.

결과는 다음과 같습니다.

'LUCIA'와 'RIZ' 비즈니스 파트너의 비활성 레코드를 확인한 후 기록을 유지하지 않으려는 경우 'LUCIA'의 모든 비활성 레코드를 삭제하면 됩니다. 이 예시에서는 비교를 위해 동일한 복제가 이루어진 다른 테이블을 사용하여 선택에 따라 비활성 레코드가 모두 삭제되고 최신 업데이트된 레코드만 유지되었는지 확인합니다. 예를 들면 다음과 같습니다.

또한 다음과 같은 쿼리를 사용하여 'LUCIA' 파트너에 대한 비활성 레코드를 검색한 후 삭제를 진행할 수 있습니다.

그러면 최신 업데이트를 제외한 모든 레코드가 생성됩니다.

파티션 나누기 및 클러스터링

쿼리에서 스캔되는 레코드 개수를 제한하고, 비용을 절감하고, 최고의 성능을 내려면 파티션을 결정하고 클러스터를 만드는 두 가지 중요한 단계를 진행해야 합니다. 

파티션 나누기

파티션을 나눈 테이블은 파티션이라는 세그먼트로 구분되어 데이터 관리와 쿼리가 용이한 테이블입니다. 큰 테이블을 작은 파티션으로 나누면 쿼리에서 읽는 바이트 수가 줄어 쿼리 성능이 향상되고 비용을 관리할 수 있습니다.

다음을 기준으로 BigQuery 테이블을 여러 파티션으로 나눌 수 있습니다.

• 시간 단위 열: '타임스탬프,' '날짜' 또는 '일시' 열에 따라 테이블이 파티션으로 구분됩니다.
• 수집 시간: BigQuery가 데이터를 수집할 때 기록되는 타임스탬프를 기준으로 테이블이 파티션으로 구분됩니다.
• 정수 범위: 정수 열을 기준으로 테이블이 파티션으로 구분됩니다.

아래 예시와 같이 테이블이 생성될 때 파티션이 사용 설정됩니다.  쿼리 왼쪽에 표시된 것처럼 파티션 필터를 항상 포함시키는 것이 좋습니다.

클러스터링

클러스터링은 필터링에 사용될 수 있는 필드를 적용하여 파티션을 나눈 테이블에 추가로 만들 수 있습니다. BigQuery에서 클러스터링된 테이블을 만들 때, 테이블 데이터는 테이블 스키마에 있는 1개 이상의 열에 있는 콘텐츠를 기준으로 자동 정렬됩니다. 지정하는 열은 관련 데이터를 배치하는 데 사용됩니다.

클러스터링은 절을 필터링하는 데 사용하는 쿼리나 데이터를 집계하는 쿼리와 같은 특정 유형의 쿼리 성능을 개선할 수 있습니다. SAP S/4HANA의 회계 문서용 테이블인 ACDOCA 같은 대형 테이블에 적용하면 매우 편리합니다. 이 경우 타임스탬프를 이용하여 파티션을 나누고 원장, 기업 코드, 회계 연도 같은 일반 필터링 필드를 사용하여 클러스터를 정의할 수 있습니다.

BigQuery의 또 다른 유용한 기능으로는 정기적으로 데이터를 자동 재클러스터링하는 기능이 있습니다.

구체화된 뷰

BigQuery에서 구체화된 뷰는 성능 및 효율성 향상을 위해 쿼리 결과를 주기적으로 캐시하는 미리 계산된 뷰입니다. BigQuery는 구체화된 뷰로부터 미리 계산된 결과를 사용하고, 가능한 모든 경우에 기본 테이블에서 델타 변경사항만 읽어 최신 결과를 빠르게 계산합니다. 구체화된 뷰는 직접 쿼리될 수도 있고, 기본 테이블 쿼리 처리를 위해 BigQuery 옵티마이저에 사용될 수도 있습니다.

구체화된 뷰를 사용하는 쿼리는 일반적으로 기본 테이블에서 동일한 데이터만 검색하는 쿼리보다 속도가 빠르며 리소스 소비도 적습니다. 워크로드 성능이 문제인 경우 구체화된 뷰는 일반적인 반복 쿼리가 포함된 워크로드의 성능을 크게 개선할 수 있습니다. 현재 구체화된 뷰는 단일 테이블만 지원하지만 재고 수준이나 주문 처리와 같이 일반적으로 자주 사용되는 집계에 매우 유용합니다.

특정 구문을 작성하면서 성능을 최적화하는 방법에 대한 자세한 팁은 쿼리 계산 최적화 문서를 참조하세요.

배포 파이프라인 및 보안

BigQuery에서 실행하는 대부분의 작업의 경우 최소한 두 가지의 전송 파이프라인을 실행하게 됩니다. 하나는 BigQuery의 실제 객체용이고 또 다른 하나는 변경 데이터 캡처 흐름 내에서 의도된 바에 따라 데이터 스테이징, 변환, 업데이트를 유지하기 위한 것입니다. 지속적 통합/지속적 배포(CI/CD) 파이프라인에 기존 도구의 대부분을 사용할 수 있으며 이는 BigQuery 같은 오픈 시스템을 사용할 때 누릴 수 있는 이점 중 하나입니다. 하지만 조직이 CI/CD 파이프라인을 처음 사용하는 경우 점차 경험을 확장할 수 있는 좋은 기회입니다. 우선 데이터 처리 워크플로용 CI/CD 파이프라인 설정에 대한 가이드부터 읽어보시기 바랍니다.  

액세스와 보안 면에서 대부분의 최종 사용자는 BigQuery 뷰의 최종 버전에만 액세스할 수 있습니다. SAP 소스 시스템에서처럼 행 및 열 수준 보안을 적용할 수 있지만 다양한 Google Cloud 프로젝트와 BigQuery 데이터 세트에서 데이터를 분할하여 분리 작업을 한 단계 업그레이드할 수 있습니다. 데이터 세트에서 데이터와 구조를 간편하게 복제할 수 있지만 설계 프로세스 초기에 요구사항과 이름 지정 규칙을 규정하여 처음부터 올바로 설정하는 것이 바람직합니다. 

보다 빠르게 더 유용한 정보를 제공하는 분석을 시작

무엇보다도 직접 해보는 것이 좋습니다. SQL 지식이 있다면 누구나 BigQuery 무료 등급을 사용할 수 있습니다. 신규 고객에게는 처음 90일 동안 Google Cloud에 사용할 수 있는 $300의 무료 크레딧이 제공됩니다. 모든 고객에게 매월 10GB의 스토리지와 최대 1TB의 쿼리가 무료로 제공됩니다. 대규모 처리 기능, 내장 머신러닝, 다양한 통합 도구, 비용상의 이점과 더불어 BigQuery가 어떻게 분석 작업을 간소화하는지는 곧 알게 될 것입니다.