Campaign FFDA 배포 gs-ac-ffda
Adobe Campaign Enterprise FFDA(Full Federated Access) 배포는 클라우드 데이터베이스 기술인 Snowflake을(를) 활용함으로써 그 규모와 속도를 크게 향상시키며, 훨씬 더 많은 수의 고객 프로필을 관리할 수 있을 뿐만 아니라 시간당 훨씬 더 높은 게재율과 트랜잭션을 처리할 수 있습니다.
이점 ffda-benefits
Campaign v8 Enterprise(FFDA)는 타깃팅에서 최종 보고에 이르기까지 프로세스의 모든 단계에서 엔드 투 엔드 크기 조절을 제공합니다.
- 처리할 수 있는 데이터 볼륨의 크기 조절(8TB까지)
- 세분화 및 타겟팅 외에도 데이터 수집 및 가져오기를 위한 쿼리 성능의 크기 조절
- 게재 준비 단위 조절(시간 ~ 분)
소프트웨어 아키텍처의 근본적인 변화입니다. 이제 데이터는 원격지에 있으며 Campaign은 프로필을 포함한 전체 데이터를 통합합니다. 이제 Campaign 프로세스가 타기팅에서 메시지 실행에 이르기까지 전체 프로세스를 확장합니다. 데이터 수집, 세분화, 타기팅, 쿼리, 게재는 이제 일반적으로 몇 분 내에 실행됩니다. 이 새로운 버전은 동일한 수준의 유연성과 확장성을 유지하면서 크기를 조절해야 하는 문제 전체를 해결합니다. 프로필 수는 거의 제한이 없으며 데이터 유지율을 확장할 수 있습니다.
클라우드 스토리지는 Snowflake 에서 수행됩니다. Snowflake는 새로운 기본 제공 외부 계정 으로 클라우드 데이터베이스와의 연결을 보장합니다. 이는 Adobe에서 구성하며 수정해서는 안 됩니다. 자세히 알아보기
클라우드 데이터베이스에서 이동하거나 복제해야 하는 내장 스키마/테이블은 xxl 네임스페이스 아래에 내장된 스키마 확장과 함께 제공됩니다. 이 확장에는 내장된 스키마를 Campaign 로컬 데이터베이스에서 Snowflake 클라우드 데이터베이스로 이동하고 그에 따라 새로운 UUID, 업데이트된 링크 등 해당 구조를 조정하는 데 필요한 수정 사항이 모두 포함됩니다.
Campaign Enterprise(FFDA) 아키텍처 ffda-archi
엔터프라이즈(FFDA) 배포에서 Adobe Campaign v8은(는) 두 개의 데이터베이스를 사용합니다. 하나는 사용자 인터페이스 실시간 메시지 보내기와 API를 통한 단일 쿼리 및 쓰기를 위한 로컬 Campaign 데이터베이스이고, 다른 하나는 캠페인 실행, 쿼리 일괄 처리 및 워크플로우 실행을 위한 클라우드 Snowflake 데이터베이스입니다.
Campaign v8 Enterprise는 FFDA(Full Federated Data Access) 개념을 도입했습니다. 이제 모든 데이터는 클라우드 데이터베이스에서 원격으로 사용할 수 있습니다.
로컬 및 클라우드 데이터베이스 간에 데이터를 관리하는 데 특정 API를 사용할 수 있습니다. 이 페이지에서는 이 새로운 API의 작동 방식과 사용법을 알아봅니다.
서버와 프로세스 간의 일반적인 통신은 다음 스키마에 따라 수행됩니다.
- 실행 및 바운스 관리 모듈은 인스턴스에서 비활성화됩니다.
- SOAP 호출을 사용하여 구동되는 원격 "중간 소스" 서버에서(HTTP 또는 HTTPS를 통해) 메시지를 실행하도록 애플리케이션이 구성됩니다.
마케팅 측의 Snowflake 데이터베이스는 다음 작업을 수행하는 데 사용됩니다.
- 프로필, 거래, 제품, 위치 등과 같은 사용자 지정 데이터 등 모든 고객 데이터를 저장합니다.
- 게재 로그, 추적 로그, 푸시 등록 등과 같이 Campaign에서 생성하거나 수집한 모든 이벤트 및 동작 데이터를 저장합니다.
- 위의 모든 데이터 합계를 저장합니다.
- 참조 테이블(예: 게재, 열거형, 국가 등)의 사본(h+1)을 저장합니다. 워크플로우, 캠페인 및 보고서에서 사용됩니다.
- 모든 일괄 처리 프로세스 및 작업 로드 실행
마케팅 인스턴스의 PostgreSQL 데이터베이스를 사용하여 다음과 같은 작업을 수행할 수 있습니다.
-
낮은 볼륨 API와 같은 특정 워크로드를 실행합니다.
-
게재 및 캠페인 설정, 워크플로우 및 서비스 정의를 포함하여 모든 캠페인 데이터를 저장합니다.
-
모든 기본 제공 참조 테이블(열거형, 국가 등) 저장 Snowflake에 복제됩니다.
단, 다음과 같은 작업은 수행할 수 없습니다.
- 고객 데이터에 대한 사용자 정의를 만듭니다. 예를 들어 PostgreSQL에서 가정용 테이블을 만들지 않고 Snowflake에서만 가정용 테이블을 만듭니다
- 게재 로그, 추적 로그 등을 저장합니다. FFDA 타겟팅 차원에서.
- 대량의 데이터를 저장합니다.
중간 소싱 인스턴스의 PostgreSQL 데이터베이스를 사용하여 다음과 같은 작업을 수행할 수 있습니다.
- 배치 및 실시간(RT) 게재를 실행합니다.
- 게재 및 추적 로그 보내기 - 게재 및 추적 로그 ID는 UUID이며 32비트 ID가 아닙니다.
- 추적 데이터를 수집하고 저장합니다.
영향 ffda-impacts
Campaign API 스테이징 메커니즘 staging-api
Campaign 클라우드 데이터베이스의 경우 성능(지연 및 동시 실행)으로 인해 단일 호출이 폭발하지 않는 것이 좋습니다. 전송 볼륨이 아무리 많아도 API의 최적의 성능을 보장하기 위해 일괄 처리 작업을 사용해야 합니다. Campaign은 로컬 데이터베이스 수준에서 API 호출을 계속 처리합니다.
API 스테이징 메커니즘은 이 페이지에 자세히 설명되어 있습니다.
새 API new-apis
Campaign 로컬 데이터베이스와 클라우드 데이터베이스 간의 데이터 동기화를 관리하는 데 새 API를 사용할 수 있습니다. 지연을 방지하고 전체 성능을 높이기 위해 로컬 데이터베이스 수준에서 API 호출을 처리하는 새로운 메커니즘도 도입되었습니다.
데이터 복제 data-replication
특정 기술 워크플로는 양쪽(Campaign 로컬 데이터베이스와 클라우드 데이터베이스)에 모두 표시되어야 하는 테이블 복제를 처리합니다. 이 워크플로는 매 시간마다 트리거되며 새로운 내장 JavaScript 라이브러리를 사용합니다.
일부 테이블은 실시간으로 복제되고 다른 테이블은 시간별로 복제됩니다. 일부 테이블에는 증분 업데이트가 적용되고 다른 테이블에는 전체 업데이트가 적용됩니다.
ID 관리 id-mgt-ffda
이제 Campaign v8 개체에는 데이터를 식별하는 데 제한 없는 고유 값을 사용할 수 있는 UUID(범용 고유 ID) 이(가) 사용됩니다.
이 ID는 문자열 기반이며 순차적이 아님에 유의하세요. 기본 키는 Campaign v8에서 숫자 값이 아니므로 스키마에서 autouid 및 autok 속성을 사용해야 합니다.
Campaign Classic v7 및 이전 버전에서 스키마(즉 테이블) 내의 키 독자성은 데이터베이스 엔진 수준에서 처리됩니다. 일반적으로 PostgreSQL, Oracle 또는 SQL Server와 같은 클래식 데이터베이스 엔진에는 기본 키 및/또는 고유 인덱스를 통해 열 또는 열 세트를 기반으로 중복 행 삽입을 방지하는 기본 메커니즘이 포함되어 있습니다. 이 버전에서는 데이터베이스 수준에서 적절한 인덱스 및 기본 키를 설정한 경우 중복 ID가 존재하지 않습니다.
Adobe Campaign v8에는 핵심 데이터베이스로 Snowflake가 포함되어 있습니다. 쿼리 크기가 크게 증가함에 따라 Snowflake 데이터베이스의 분산 아키텍처는 이와 같이 테이블 내에서 키 독자성을 관리하는 메커니즘을 제공하지 않습니다. 따라서 Adobe Campaign v8에서는 테이블에서 중복 키를 수집하는 것을 방지하는 장치가 없습니다. 이제 Adobe Campaign 데이터베이스 내의 키 독자성을 유지할 책임은 최종 사용자에게 있습니다. 자세히 알아보기
기능 가용성 feature-availability
Campaign의 엔터프라이즈(FFDA) 배포 컨텍스트에서는 일부 기능을 사용할 수 없습니다. 예:
- 마케팅 리소스 관리
- 쿠폰
- 웹 추적
- 설문 조사
관련 항목