중요한
Lakeflow Connect의 관리형 커넥터는 다양한 릴리스 상태입니다.
이 페이지에서는 SaaS 애플리케이션 및 데이터베이스에서 데이터를 수집하기 위한 Databricks Lakeflow Connect의 관리되는 커넥터에 대한 개요를 제공합니다. 결과 수집 파이프라인은 Unity 카탈로그에 의해 제어되며 서버리스 컴퓨팅 및 Lakeflow Spark 선언적 파이프라인에 의해 구동됩니다. 관리형 커넥터는 효율적인 증분 읽기 및 쓰기를 활용하여 데이터 수집을 더 빠르고 확장 가능하며 비용 효율적으로 만드는 한편, 다운스트림 사용을 위해 데이터가 최신 상태로 유지됩니다.
SaaS 커넥터 구성 요소
SaaS 커넥터에는 다음과 같은 구성 요소가 있습니다.
| 구성 요소 | 설명 |
|---|---|
| 연결 | 애플리케이션에 대한 인증 세부 정보를 저장하는 Unity 카탈로그 보안 개체입니다. |
| 데이터 수집 파이프라인 | 애플리케이션에서 대상 테이블로 데이터를 복사하는 파이프라인입니다. 수집 파이프라인은 서버리스 컴퓨팅에서 실행됩니다. |
| 대상 테이블 | 데이터를 수집 파이프라인이 작성하는 테이블입니다. 증분 데이터 처리를 추가로 지원하는 델타 테이블인 스트리밍 테이블입니다. |
데이터베이스 커넥터 구성 요소
데이터베이스 커넥터에는 다음과 같은 구성 요소가 있습니다.
| 구성 요소 | 설명 |
|---|---|
| 연결 | 데이터베이스에 대한 인증 세부 정보를 저장하는 Unity 카탈로그 보안 개체입니다. |
| 데이터 수집 게이트웨이 | 원본 데이터베이스에서 스냅샷, 변경 로그 및 메타데이터를 추출하는 파이프라인입니다. 게이트웨이는 클래식 컴퓨팅에서 실행되며, 변경 로그가 원본에서 잘리기 전에 변경 내용을 캡처하기 위해 지속적으로 실행됩니다. |
| 스테이징 스토리지 | 대상 테이블에 적용되기 전에 추출된 데이터를 일시적으로 저장하는 Unity 카탈로그 볼륨입니다. 이렇게 하면 게이트웨이가 변경 내용을 지속적으로 캡처하는 경우에도 원하는 일정에 관계없이 수집 파이프라인을 실행할 수 있습니다. 또한 오류 복구에도 도움이 됩니다. 게이트웨이를 배포할 때 자동으로 스테이징 스토리지 볼륨을 만들고 카탈로그와 스키마가 있는 위치를 사용자 지정할 수 있습니다. 데이터는 30일 후에 스테이징에서 자동으로 제거됩니다. |
| 데이터 수집 파이프라인 | 준비 스토리지에서 대상 테이블로 데이터를 이동하는 파이프라인입니다. 파이프라인은 서버리스 컴퓨팅에서 실행됩니다. |
| 대상 테이블 | 데이터를 수집 파이프라인이 작성하는 테이블입니다. 증분 데이터 처리를 추가로 지원하는 델타 테이블인 스트리밍 테이블입니다. |
오케스트레이션
하나 이상의 사용자 지정 일정에 따라 수집 파이프라인을 실행할 수 있습니다. 파이프라인에 일정을 추가할 때마다 Lakeflow Connect에서 자동으로 해당 일정에 대한 작업을 만듭니다. 수집 파이프라인은 작업 내의 과제입니다. 필요에 따라 작업에 더 많은 작업을 추가할 수 있습니다.
데이터베이스 커넥터의 경우, 데이터 수집 게이트웨이는 자신의 작업 내에서 지속적인 작업으로 수행됩니다.
점진적 데이터 적재
Lakeflow Connect는 데이터 파이프라인의 효율성을 높이기 위해 증분 수집 방식을 사용합니다. 파이프라인의 첫 번째 실행 시 원본에서 선택한 모든 데이터를 수집합니다. 병렬로 원본 데이터의 변경 내용을 추적합니다. 파이프라인의 후속 실행마다 변경 내용 추적을 사용하여 가능한 경우 이전 실행에서 변경된 데이터만 수집합니다.
정확한 방법은 데이터 원본에서 사용할 수 있는 항목에 따라 달라집니다. 예를 들어 SQL Server에서 변경 내용 추적 및 CDC(변경 데이터 캡처)를 모두 사용할 수 있습니다. 반면 Salesforce 커넥터는 옵션 집합 목록에서 커서 열을 선택합니다.
일부 원본 또는 특정 테이블은 현재 증분 수집을 지원하지 않습니다. Databricks는 증분 지원에 대한 적용 범위를 확장할 계획입니다.
네트워킹
SaaS 애플리케이션 또는 데이터베이스에 연결하는 몇 가지 옵션이 있습니다.
- SaaS 애플리케이션용 커넥터는 원본의 API에 연결합니다. 또한 서버리스 이그레스 컨트롤과 자동으로 호환됩니다.
- 클라우드 데이터베이스용 커넥터는 Private Link를 통해 원본에 연결할 수 있습니다. 또는 작업 영역에 데이터베이스를 호스팅하는 VNet 또는 VPC와 피어링된 VNet(Virtual Network) 또는 VPC(Virtual Private Cloud)가 있는 경우 그 안에 수집 게이트웨이를 배포할 수 있습니다.
- 온-프레미스 데이터베이스용 커넥터는 AWS Direct Connect 및 Azure ExpressRoute와 같은 서비스를 사용하여 연결할 수 있습니다.
배치
Databricks 자산 번들을 사용하여 수집 파이프라인을 배포할 수 있습니다. 이를 통해 소스 제어, 코드 검토, 테스트 및 CI/CD(지속적인 통합 및 배달)와 같은 모범 사례를 사용할 수 있습니다. 번들은 Databricks CLI를 사용하여 관리되며 개발, 스테이징 및 프로덕션과 같은 다른 대상 작업 영역에서 실행할 수 있습니다.
오류 복구
완전히 관리되는 서비스인 Lakeflow Connect는 가능한 경우 문제에서 자동으로 복구하는 것을 목표로 합니다. 예를 들어 커넥터가 실패하면 지수 백오프를 사용하여 자동으로 다시 시도합니다.
그러나 오류에는 사용자의 개입이 필요할 수 있습니다(예: 자격 증명이 만료되는 경우). 이러한 경우 커넥터는 커서의 마지막 위치를 저장하여 누락된 데이터를 방지하려고 합니다. 그런 다음 가능하면 파이프라인의 다음 실행 시 해당 위치에서 다시 선택할 수 있습니다.
모니터링
Lakeflow Connect는 파이프라인을 유지 관리하는 데 도움이 되는 강력한 경고 및 모니터링을 제공합니다. 여기에는 이벤트 로그, 클러스터 로그, 파이프라인 상태 메트릭 및 데이터 품질 메트릭이 포함됩니다.
릴리스 상태
| Connector | 릴리스 상태 |
|---|---|
| Dynamics 365 | Public Preview |
| Google Analytics | 일반 공급 |
| MySQL | Public Preview |
| NetSuite | Public Preview |
| PostgreSQL | Public Preview |
| Salesforce | 일반 공급 |
| ServiceNow | 일반 공급 |
| 셰어포인트 | 베타 |
| SQL 서버 | 일반 공급 |
| 근무일 | 일반 공급 |
기능 가용성
다음 표에서는 관리되는 각 수집 커넥터의 기능 가용성을 요약합니다. 추가 기능 및 제한 사항은 특정 커넥터에 대한 설명서를 참조하세요.
Google Analytics
| 특징 | Availability |
|---|---|
| UI 기반 파이프라인 작성 | 예 |
| API 기반 파이프라인 작성 | 예 |
| Databricks 자산 번들 | 예 |
| 점진적 데이터 적재 | 예 |
| Unity 카탈로그 거버넌스 | 예 |
| Databricks 워크플로를 사용한 오케스트레이션 | 예 |
| SCD 형식 2 | 예 |
| API 기반 열 선택 및 선택 취소 | 예 |
| API 기반 행 필터링 | 예 |
| 자동화된 스키마 진화: 새로 만들기 및 삭제된 열 | 예 |
| 자동화된 스키마 진화: 데이터 형식 변경 | 아니오 |
| 자동화된 스키마 진화: 열 이름 바꾸기 | 예 - 새 열(새 이름) 및 삭제된 열(이전 이름)으로 처리됩니다. |
| 자동화된 스키마 진화: 새 테이블 | 예 - 전체 스키마를 수집하는 경우 파이프라인당 테이블 수에 대한 제한 사항을 참조하세요. |
| 파이프라인당 최대 테이블 수 | 250 |
MySQL
| 특징 | Availability |
|---|---|
| UI 기반 파이프라인 작성 | 예 |
| API 기반 파이프라인 작성 |
|
| Databricks 자산 번들 |
|
| 점진적 데이터 적재 |
|
| Unity 카탈로그 거버넌스 |
|
| Databricks 워크플로를 사용한 오케스트레이션 |
|
| SCD 형식 2 |
|
| API 기반 열 선택 및 선택 취소 |
|
| API 기반 행 필터링 | 아니오 |
| 자동화된 스키마 진화: 새로 만들기 및 삭제된 열 |
|
| 자동화된 스키마 진화: 데이터 형식 변경 |
|
| 자동화된 스키마 진화: 열 이름 바꾸기 |
새 열(새 이름) 및 삭제된 열(이전 이름)으로 처리됩니다. |
| 자동화된 스키마 진화: 새 테이블 |
전체 스키마를 수집하는 경우 파이프라인당 테이블 수에 대한 제한 사항을 참조하세요. |
| 파이프라인당 최대 테이블 수 | 250 |
NetSuite
| 특징 | Availability |
|---|---|
| UI 기반 파이프라인 작성 | 예 |
| API 기반 파이프라인 작성 | 예 |
| Databricks 자산 번들 | 예 |
| 점진적 데이터 적재 | 예 |
| Unity 카탈로그 거버넌스 | 예 |
| Databricks 워크플로를 사용한 오케스트레이션 | 예 |
| SCD 형식 2 | 예 |
| API 기반 열 선택 및 선택 취소 | 예 |
| API 기반 행 필터링 | 아니오 |
| 자동화된 스키마 진화: 새로 만들기 및 삭제된 열 | 예 |
| 자동화된 스키마 진화: 데이터 형식 변경 | 아니오 |
| 자동화된 스키마 진화: 열 이름 바꾸기 | 예 - 새 열(새 이름) 및 삭제된 열(이전 이름)으로 처리됩니다. |
| 자동화된 스키마 진화: 새 테이블 | 예 - 전체 스키마를 수집하는 경우 파이프라인당 테이블 수에 대한 제한 사항을 참조하세요. |
| 파이프라인당 최대 테이블 수 | 200 |
Salesforce
| 특징 | Availability |
|---|---|
| UI 기반 파이프라인 작성 |
|
| API 기반 파이프라인 작성 | 예 |
| Databricks 자산 번들 | 예 |
| 점진적 데이터 적재 | 예 - 기본적으로 수식 필드에는 전체 스냅샷이 필요합니다. 수식 필드에 증분 수집을 사용하도록 설정하려면 Salesforce 수식 필드를 증분 방식으로 수집하는 방법을 참조하세요. |
| Unity 카탈로그 거버넌스 | 예 |
| Databricks 워크플로를 사용한 오케스트레이션 | 예 |
| SCD 형식 2 | 예 |
| API 기반 열 선택 및 선택 취소 | 예 |
| API 기반 행 필터링 | 예 |
| 자동화된 스키마 진화: 새로 만들기 및 삭제된 열 | 예 |
| 자동화된 스키마 진화: 데이터 형식 변경 | 아니오 |
| 자동화된 스키마 진화: 열 이름 바꾸기 | 예 - 새 열(새 이름) 및 삭제된 열(이전 이름)으로 처리됩니다. |
| 자동화된 스키마 진화: 새 테이블 | 해당 없음(N/A) |
| 파이프라인당 최대 테이블 수 | 250 |
근무일
| 특징 | Availability |
|---|---|
| UI 기반 파이프라인 작성 | 예 |
| API 기반 파이프라인 작성 | 예 |
| Databricks 자산 번들 | 예 |
| 점진적 데이터 적재 | 아니오 |
| Unity 카탈로그 거버넌스 | 예 |
| Databricks 워크플로를 사용한 오케스트레이션 | 예 |
| SCD 형식 2 | 예 |
| API 기반 열 선택 및 선택 취소 | 예 |
| API 기반 행 필터링 | 아니오 |
| 자동화된 스키마 진화: 새로 만들기 및 삭제된 열 | 예 |
| 자동화된 스키마 진화: 데이터 형식 변경 | 아니오 |
| 자동화된 스키마 진화: 열 이름 바꾸기 | 아니요 - DDL 개체를 사용하도록 설정하면 커넥터에서 열 이름을 바꿀 수 있습니다. DDL 개체를 사용하도록 설정하지 않으면 커넥터는 이를 새 열(새 이름) 및 삭제된 열(이전 이름)으로 처리합니다. 두 경우 모두 전체 새로 고침이 필요합니다. |
| 자동화된 스키마 진화: 새 테이블 | 예 - 전체 스키마를 수집하는 경우 파이프라인당 테이블 수에 대한 제한 사항을 참조하세요. |
| 파이프라인당 최대 테이블 수 | 250 |
SQL 서버
| 특징 | Availability |
|---|---|
| UI 기반 파이프라인 작성 | 예 |
| API 기반 파이프라인 작성 | 예 |
| Databricks 자산 번들 | 예 |
| 점진적 데이터 적재 | 예 |
| Unity 카탈로그 거버넌스 | 예 |
| Databricks 워크플로를 사용한 오케스트레이션 | 예 |
| SCD 형식 2 | 예 |
| API 기반 열 선택 및 선택 취소 | 예 |
| API 기반 행 필터링 | 아니오 |
| 자동화된 스키마 진화: 새로 만들기 및 삭제된 열 | 예 |
| 자동화된 스키마 진화: 데이터 형식 변경 | 아니오 |
| 자동화된 스키마 진화: 열 이름 바꾸기 | 아니요 - DDL 개체를 사용하도록 설정하면 커넥터에서 열 이름을 바꿀 수 있습니다. DDL 개체를 사용하도록 설정하지 않으면 커넥터는 이를 새 열(새 이름) 및 삭제된 열(이전 이름)으로 처리합니다. 두 경우 모두 전체 새로 고침이 필요합니다. |
| 자동화된 스키마 진화: 새 테이블 |
전체 스키마를 수집하는 경우 파이프라인당 테이블 수에 대한 제한 사항을 참조하세요. |
| 파이프라인당 최대 테이블 수 | 250 |
PostgreSQL
| 특징 | Availability |
|---|---|
| UI 기반 파이프라인 작성 | 예 |
| API 기반 파이프라인 작성 |
|
| Databricks 자산 번들 |
|
| 점진적 데이터 적재 |
|
| Unity 카탈로그 거버넌스 |
|
| Databricks 워크플로를 사용한 오케스트레이션 |
|
| SCD 형식 2 |
|
| API 기반 열 선택 및 선택 취소 |
|
| API 기반 행 필터링 | 아니오 |
| 자동화된 스키마 진화: 새로 만들기 및 삭제된 열 |
|
| 자동화된 스키마 진화: 데이터 형식 변경 |
|
| 자동화된 스키마 진화: 열 이름 바꾸기 | 예 - 새 열(새 이름) 및 삭제된 열(이전 이름)으로 처리됩니다. |
| 자동화된 스키마 진화: 새 테이블 | 예 - 전체 스키마를 수집하는 경우 파이프라인당 테이블 수에 대한 제한 사항을 참조하세요. |
| 파이프라인당 최대 테이블 수 | 250 |
ServiceNow
| 특징 | Availability |
|---|---|
| UI 기반 파이프라인 작성 | 예 |
| API 기반 파이프라인 작성 | 예 |
| Databricks 자산 번들 | 예 |
| 점진적 데이터 적재 | 예 - 테이블에 커서 필드가 없는 경우는 예외입니다. |
| Unity 카탈로그 거버넌스 | 예 |
| Databricks 워크플로를 사용한 오케스트레이션 | 예 |
| SCD 형식 2 | 예 |
| API 기반 열 선택 및 선택 취소 | 예 |
| API 기반 행 필터링 | 예 |
| 자동화된 스키마 진화: 새로 만들기 및 삭제된 열 | 예 |
| 자동화된 스키마 진화: 데이터 형식 변경 | 아니오 |
| 자동화된 스키마 진화: 열 이름 바꾸기 | 예 - 새 열(새 이름) 및 삭제된 열(이전 이름)으로 처리됩니다. |
| 자동화된 스키마 진화: 새 테이블 | 예 - 전체 스키마를 수집하는 경우 파이프라인당 테이블 수에 대한 제한 사항을 참조하세요. |
| 파이프라인당 최대 테이블 수 | 250 |
셰어포인트
| 특징 | Availability |
|---|---|
| UI 기반 파이프라인 작성 |
|
| API 기반 파이프라인 작성 | 예 |
| Databricks 자산 번들 | 예 |
| 점진적 데이터 적재 | 예 |
| Unity 카탈로그 거버넌스 | 예 |
| Databricks 워크플로를 사용한 오케스트레이션 | 예 |
| SCD 형식 2 | 예 |
| API 기반 열 선택 및 선택 취소 | 예 |
| API 기반 행 필터링 | 아니오 |
| 자동화된 스키마 진화: 새로 만들기 및 삭제된 열 | 예 |
| 자동화된 스키마 진화: 데이터 형식 변경 | 아니오 |
| 자동화된 스키마 진화: 열 이름 바꾸기 | 아니요 - 전체 새로 고침이 필요합니다. |
| 자동화된 스키마 진화: 새 테이블 | 예 - 전체 스키마를 수집하는 경우 파이프라인당 테이블 수에 대한 제한 사항을 참조하세요. |
| 파이프라인당 최대 테이블 수 | 250 |
Dynamics 365
| 특징 | Availability |
|---|---|
| UI 기반 파이프라인 작성 | 예 |
| API 기반 파이프라인 작성 | 예 |
| Databricks 자산 번들 | 예 |
| 점진적 데이터 적재 | 예 - Azure Synapse Link에서 VersionNumber를 통해 |
| Unity 카탈로그 거버넌스 | 예 |
| Databricks 워크플로를 사용한 오케스트레이션 | 예 |
| SCD 형식 2 | 예 |
| API 기반 열 선택 및 선택 취소 | 예 |
| API 기반 행 필터링 | 아니오 |
| 자동화된 스키마 진화: 새로 만들기 및 삭제된 열 | 예 |
| 자동화된 스키마 진화: 데이터 형식 변경 | 아니오 |
| 자동화된 스키마 진화: 열 이름 바꾸기 | 아니요 - 전체 새로 고침이 필요합니다. |
| 자동화된 스키마 진화: 새 테이블 | 예 - 전체 스키마를 수집하는 경우 파이프라인당 테이블 수에 대한 제한 사항을 참조하세요. |
| 파이프라인당 최대 테이블 수 | 250 |
인증 방법
다음 표에서는 관리되는 각 수집 커넥터에 대해 지원되는 인증 방법을 나열합니다. Databricks는 가능한 경우 OAuth U2M 또는 OAuth M2M을 사용하는 것이 좋습니다. 커넥터가 OAuth를 지원하는 경우 기본 인증은 레거시 방법으로 간주됩니다.
Dynamics 365
| 인증 방법 | Availability |
|---|---|
| OAuth U2M |
|
| OAuth M2M |
|
| OAuth(수동 새로 고침 토큰) |
|
| 기본 인증(사용자 이름/암호) |
|
| 기본 인증(API 키) |
|
| 기본 인증(서비스 계정 JSON 키) |
|
Google Analytics
| 인증 방법 | Availability |
|---|---|
| OAuth U2M |
|
| OAuth M2M |
|
| OAuth(수동 새로 고침 토큰) |
|
| 기본 인증(사용자 이름/암호) |
|
| 기본 인증(API 키) |
|
| 기본 인증(서비스 계정 JSON 키) |
|
MySQL
| 인증 방법 | Availability |
|---|---|
| OAuth U2M |
|
| OAuth M2M |
|
| OAuth(수동 새로 고침 토큰) |
|
| 기본 인증(사용자 이름/암호) |
|
| 기본 인증(API 키) |
|
| 기본 인증(서비스 계정 JSON 키) |
|
NetSuite
| 인증 방법 | Availability |
|---|---|
| OAuth U2M |
|
| OAuth M2M |
|
| OAuth(수동 새로 고침 토큰) |
|
| 기본 인증(사용자 이름/암호) |
|
| 기본 인증(API 키) |
|
| 기본 인증(서비스 계정 JSON 키) |
|
Salesforce
| 인증 방법 | Availability |
|---|---|
| OAuth U2M |
|
| OAuth M2M |
|
| OAuth(수동 새로 고침 토큰) |
|
| 기본 인증(사용자 이름/암호) |
|
| 기본 인증(API 키) |
|
| 기본 인증(서비스 계정 JSON 키) |
|
ServiceNow
| 인증 방법 | Availability |
|---|---|
| OAuth U2M |
|
| OAuth M2M |
|
| OAuth(수동 새로 고침 토큰) |
|
| 기본 인증(사용자 이름/암호) |
|
| 기본 인증(API 키) |
|
| 기본 인증(서비스 계정 JSON 키) |
|
셰어포인트
| 인증 방법 | Availability |
|---|---|
| OAuth U2M |
|
| OAuth M2M |
|
| OAuth(수동 새로 고침 토큰) |
|
| 기본 인증(사용자 이름/암호) |
|
| 기본 인증(API 키) |
|
| 기본 인증(서비스 계정 JSON 키) |
|
SQL 서버
| 인증 방법 | Availability |
|---|---|
| OAuth U2M |
|
| OAuth M2M |
|
| OAuth(수동 새로 고침 토큰) |
|
| 기본 인증(사용자 이름/암호) |
|
| 기본 인증(API 키) |
|
| 기본 인증(서비스 계정 JSON 키) |
|
근무일
| 인증 방법 | Availability |
|---|---|
| OAuth U2M |
|
| OAuth M2M |
|
| OAuth(수동 새로 고침 토큰) |
|
| 기본 인증(사용자 이름/암호) |
|
| 기본 인증(API 키) |
|
| 기본 인증(서비스 계정 JSON 키) |
|
외부 서비스에 대한 종속성
Databricks SaaS, 데이터베이스 및 기타 완전 관리형 커넥터는 연결하는 애플리케이션, 데이터베이스 또는 외부 서비스의 접근성, 호환성 및 안정성에 따라 달라집니다. Databricks는 이러한 외부 서비스를 제어하지 않으므로 변경, 업데이트 및 유지 관리에 대한 영향이 제한됩니다(있는 경우).
외부 서비스와 관련된 변경, 중단 또는 상황이 커넥터 작동을 방해하거나 비실용적으로 렌더링하는 경우 Databricks는 해당 커넥터의 유지 관리를 중단하거나 중단할 수 있습니다. Databricks는 해당 설명서에 대한 업데이트를 포함하여 고객에게 유지 관리 중단 또는 중단을 알리기 위해 합리적인 노력을 기울일 것입니다.