자동 업그레이드: 레이크하우스 테이블을 위한 모범 사례 기능

이제 Unity Catalog(UC) 관리형 테이블이 스스로 알아서 개선됩니다. 자동 업그레이드(Auto Upgrades)는 레이크하우스 업계 최초의 기능입니다. 클라이언트의 호환성을 자동으로 확인한 다음, 테이블이 준비되는 즉시 Row Tracking과 같은 모범 사례 기능을 수동 작업 없이 자동으로 적용합니다.

오픈 테이블 포맷은 빠르게 혁신하며 다양한 새로운 테이블 기능을 도입하고 있습니다. 하지만 지금까지 새로운 테이블 기능을 도입하려면 대상 테이블을 식별하고, 클라이언트 호환성을 확인하고, 수천 개의 테이블에 대해 ALTER TABLE을 실행해야 했습니다. 대부분의 팀은 그럴 시간이 없기 때문에 이러한 기능이 제공할 수 있는 성능 향상, 안정성, 상호 운용성, 비용 절감 등의 이점을 누리지 못합니다. 자동 업그레이드(Auto Upgrades)는 이러한 격차를 해소하는 동시에 사용자가 제어권을 유지할 수 있도록 지원합니다. 모든 변경 사항은 테이블별로 되돌릴 수 있습니다.

정신적 부담을 덜어주는 것은 무엇이든 환영입니다. 모든 테이블의 모든 새로운 기능을 계속 파악하는 것은 매우 힘든 일인데, 자동 업그레이드(Auto Upgrades)가 대신 유지 관리를 처리해 준다니 정말 기대됩니다! —Audrey Boslego, 데이터 플랫폼 엔지니어링 매니저

자동 업그레이드 작동 방식

자동 업그레이드(Auto Upgrades)는 기존 테이블에 액세스하는 방식을 관찰하고, 모든 워크로드가 준비되었는지 확인한 다음, 사용자를 대신하여 기능을 적용하는 방식으로 작동합니다.

1. 관찰(Observe): 기존의 모든 UC 관리형 테이블에 대해, 자동 업그레이드(Auto Upgrades)는 롤링 관찰 기간(observation window) 동안 해당 테이블에 액세스하는 클라이언트를 관찰합니다.

2. 확인(Verify): 각 기능에 대해, 자동 업그레이드(Auto Upgrades)는 동일한 관찰 기간 동안 다음 조건이 모두 충족되는지 확인합니다.

• 관찰 기간 동안 테이블에 액세스한 모든 Databricks 클라이언트가 해당 기능을 지원하는 Databricks Runtime 버전을 사용하고 있어야 합니다
• 테이블 자체가 활성 상태여야 합니다(완전히 유휴 상태인 테이블은 건너뜁니다)
• (현재 기준) 관찰 기간 동안 외부 클라이언트가 테이블에 액세스하지 않았어야 합니다

3. 업그레이드(Upgrade): 테이블이 조건을 충족하면, 자동 업그레이드(Auto Upgrades)는 가벼운 백그라운드 작업을 통해 ALTER TABLE을 실행하여 기능을 안전하게 적용합니다.

새 테이블로 확장: 스키마의 모든 기존 테이블이 특정 기능과 호환되는 것으로 확인되면, 자동 업그레이드(Auto Upgrades)는 해당 기능을 스키마의 기본값으로 설정하여 새로 생성되는 모든 테이블이 해당 기능을 자동으로 상속받도록 합니다. 생성 시 명시적으로 설정한 테이블 속성이 항상 우선적으로 적용됩니다.

향후 자동 업그레이드(Auto Upgrades)는 외부 클라이언트가 액세스하는 테이블이 특정 기능과 호환되는지 감지하여 해당 기능을 활성화하는 것을 목표로 하고 있습니다. 저희는 이러한 클라이언트의 호환성을 감지하기 위해 적절한 메타데이터를 제공하는 표준에 대해 커뮤니티와 협력하고 있습니다.

수동 업그레이드보다 더 철저한 관리

신중한 수동 업그레이드에는 상당한 노력이 필요합니다. 적절한 기능을 선택하고 프로덕션 준비가 되었는지 확인하고, 모든 클라이언트가 이를 지원하는지 검증하고, 롤백할 방법이 있는지 확인해야 합니다. 자동 업그레이드(Auto Upgrades)는 모든 테이블에 대해 이러한 철저한 검증 과정을 자동으로 적용합니다.

✅ 성능이나 비용의 실질적인 저하가 없는 GA 전용 기능만 적용. 기능이 정식 출시(GA) 단계에 도달하고 성능을 실질적으로 저하시키거나 비용을 증가시키지 않는 경우에만 자동 업그레이드(Auto Upgrades) 대상이 됩니다. 많은 기능이 성능을 향상시키거나 비용을 절감하지만, 성능을 악화시키는 기능은 없습니다.

✅ 포괄적인 관찰 기간. 모든 데이터 워크로드가 매일 실행되는 것은 아닙니다. 월간 배치 작업, 분기별 보고서, 임시 분석 등은 나타나는 데 몇 주가 걸릴 수 있습니다. Databricks는 이러한 롱테일을 포착하기 위해 100일의 관찰 기간을 선택하여, 결정을 내리기 전에 테이블이 실제로 어떻게 사용되는지 전체적인 그림을 파악합니다.

✅ 엄격한 호환성 검증. 액세스하는 모든 클라이언트가 해당 기능을 지원하기 전까지는 기능을 활성화하지 않습니다. 기존 테이블과 새 테이블을 규정하는 스키마 기본값 모두에 대해, 지원되지 않는 클라이언트가 단 하나라도 있다면 지원될 때까지 대기합니다.

✅ 검증할 수 없는 경우 작업 제외. 자동 업그레이드(Auto Upgrades)는 완전히 검증할 수 있는 테이블에 대해서만 작동합니다. 외부 클라이언트가 작업한 테이블은 대상에서 제외되며, 30일 이상 비활성 상태인 테이블은 건너뜁니다.

✅ 사용자의 결정을 존중합니다. 자동 업그레이드(Auto Upgrades)로 활성화된 모든 기능은 언제든지 테이블별로 비활성화하거나 제거할 수 있습니다. 테이블에서 기능을 한 번 비활성화하면 자동 업그레이드(Auto Upgrades)는 나중에 이를 다시 활성화하지 않습니다.

자동 업그레이드가 제공하는 이점

자동 업그레이드(Auto Upgrades)는 검증된 모범 사례 기능을 UC 관리형 테이블에 제공합니다. 여기에는 대부분의 팀이 원하지만 수동 작업의 번거로움 때문에 활성화하지 못했던 기능들이 포함됩니다.

자동 업그레이드가 실행됨에 따라 테이블은 점차 다음과 같이 개선됩니다:

더 빠르고 비용 효율적인 테이블. 테이블 쿼리 속도가 빨라지고, 저장 비용이 저렴해지며, 변경 비용이 줄어듭니다.

• 스키마 기본값으로 설정된 새 테이블에 Automatic Liquid Clustering이 적용되어, 실제로 실행하는 쿼리에 따라 데이터 레이아웃을 최적화하고 워크로드 변화에 맞춰 조정되므로 ZORDER나 수동 클러스터링 키가 필요하지 않습니다.
• Deletion Vectors는 전체 데이터 파일을 다시 쓰는 대신 행을 삭제됨 또는 업데이트됨으로 표시하므로 삭제 및 업데이트가 더 빠르고 저렴하게 실행됩니다.
• Column Mapping을 사용하면 데이터를 다시 쓰지 않고도 열의 이름을 바꾸거나 즉시 삭제할 수 있습니다.
• Parquet V2는 데이터를 더 효율적으로 압축하여 스토리지 비용을 낮추고 스캔 속도를 높입니다.

엔진 간의 개방형 상호 운용성. 테이블이 더 많은 포맷과 엔진에 개방되며, Unity Catalog의 거버넌스가 이 모든 엔진에 걸쳐 적용됩니다.

• Catalog Commits를 사용하면 UC가 여러 엔진에 걸쳐 관리형 테이블을 조정하는 시스템이 될 수 있습니다. 이를 통해 UC 관리형 테이블에 대한 외부 엔진 쓰기가 가능해지고, 외부 엔진에 ABAC 정책을 적용할 수 있으며, 다중 테이블 및 다중 문(multi-statement) 트랜잭션이 가능해집니다.
• Row Tracking은 고유한 행 수준 식별자를 추가하여 Iceberg 및 Delta 전반에서 Automatic Change Data Feed, Vector Search, Lakebase를 사용할 수 있는 길을 열어줍니다. 또한 구체화된 뷰(Materialized Views)를 전체 뷰를 다시 계산하는 대신 점진적으로 새로 고칠 수 있도록 하여 새로 고침 비용을 크게 낮춰줍니다.

부하 상황에서의 더 높은 안정성. 테이블이 커지고 쓰기 볼륨이 증가해도 안정적으로 유지됩니다.

• Checkpoint V2는 테이블 메타데이터를 더 확장 가능한 형식으로 유지하여 동시 쓰기가 많은 상황에서 커밋 실패를 줄여줍니다.

자동 업그레이드(Auto Upgrades)는 더 많은 기능을 포함하고 구체화된 뷰(Materialized Views) 및 스트리밍 테이블(Streaming Tables)과 같은 추가적인 UC 관리형 테이블 유형을 지원하도록 계속 확장될 예정입니다.

포괄적인 관찰 가능성(Observability)

자동 업그레이드(Auto Upgrades)가 추가하는 모든 기능은 사용자가 시작한 변경 사항과 구분할 수 있는 방식으로 테이블의 DESCRIBE HISTORY 출력 및 Catalog Explorer 기록 탭에 표시됩니다. 자세한 내용은 활성화된 기능 관찰을 참조하세요.

계정 전체의 가시성을 위해 시스템 테이블을 쿼리하여 테이블, 기능 및 타임스탬프별로 모든 자동 업그레이드(Auto Upgrades) 이벤트를 볼 수 있습니다. 예를 들어 특정 테이블의 모든 기능에 대해 발생한 모든 자동 업그레이드 작업을 보려면 다음과 같이 합니다:

시작하기

자동 업그레이드(Auto Upgrades)는 UC 관리형 테이블에서 작동합니다. 따라서 시작하기 위해 취할 수 있는 가장 효과적인 단계는 테이블이 이 유형의 테이블로 변환되었는지 확인하는 것입니다.

어떤 테이블이 Unity Catalog에 의해 관리되는지 확실하지 않으신가요? Catalog Explorer에서 테이블 유형을 확인하거나 테이블에서 DESCRIBE EXTENDED를 실행해 보세요.

테이블을 대량으로 감사하려면 자동 업그레이드(Auto Upgrades) 시스템 테이블을 사용하여 어떤 테이블에 어떤 기능이 언제 활성화되었는지 확인할 수도 있습니다:

가져오고 싶은 외부 테이블이 있는 경우, 단 한 번의 SET MANAGED 명령으로 전환할 수 있으며, 그 이후는 Auto Upgrades가 알아서 처리합니다.

Auto Upgrades의 작동 방식, 지원되는 기능, 활동 모니터링 방법에 대해 자세히 알아보려면 문서를 확인해 보세요.

Auto Upgrades를 사용하면 관리형 테이블이 스스로 관리됩니다. Databricks가 새로운 기능을 출시함에 따라, 번거로운 ALTER TABLE 작업, 호환성 감사 또는 마이그레이션 프로젝트 없이도 테이블이 계속해서 개선됩니다. 더 빠르고, 더 안정적이며, 상호 운용성이 더 뛰어난 테이블을 자동으로 확보할 수 있습니다.

자주 묻는 질문

Auto Upgrades는 테이블을 안전하게 업그레이드할 수 있는지 어떻게 보장하나요?

Auto Upgrades는 성능을 실질적으로 저하시키거나 비용을 인상하지 않는 정식 출시(GA) 기능만 적용합니다. 100일간의 관찰 기간을 거치고, 액세스하는 모든 클라이언트가 호환되어야 하며, 완전히 검증할 수 없는 테이블은 건너뛰고, 언제든지 테이블별로 기능을 비활성화할 수 있도록 지원합니다.

테이블이 변경된 경우, Auto Upgrades에 의해 변경된 것인지 어떻게 확인할 수 있나요?

Auto Upgrades가 수행하는 모든 변경 사항은 테이블의 DESCRIBE HISTORY 출력 및 Catalog Explorer 기록 탭에 표시되며, 사용자가 직접 변경한 사항과 명확히 구분됩니다. 계정 전체의 가시성을 확보하기 위해 system.storage.table_auto_upgrade_operations_history를 쿼리하면 어떤 기능이 언제 어떤 테이블에 추가되었는지도 확인할 수 있습니다.

외부 도구나 OSS 도구에서 읽는 테이블이 Auto Upgrades로 인해 손상될 수 있나요?

아닙니다. 외부 또는 OSS 클라이언트가 액세스하는 테이블은 현재 대상에서 제외됩니다. Auto Upgrades는 테이블에 액세스하는 모든 클라이언트가 해당 기능을 지원하는지 확인할 수 있는 경우에만 작동합니다. 향후 Auto Upgrades가 해당 클라이언트의 호환성을 확인할 수 있게 되면 외부 또는 OSS 액세스가 있는 테이블까지 대상을 확대할 예정입니다.

Auto Upgrades는 유료인가요? DBU나 스토리지 요금이 인상되나요?

현재 제한된 공개 미리 보기(Gated Public Preview) 단계에서는 Databricks가 Auto Upgrades 자체(백그라운드 ALTER TABLE 작업)에 대해 비용을 청구하지 않으며, 앞으로도 계속 무료로 제공하고자 합니다. 가장 최신 정보는 Auto Upgrades 문서를 확인해 보세요.

테이블이 업그레이드될 때까지 얼마나 걸리나요? 변경 사항은 언제 확인할 수 있나요?

Auto Upgrades는 작업을 수행하기 전에 자주 실행되지 않는 워크로드(예: 월별 배치 작업, 분기별 보고서, 임시 분석)를 감지하기 위해 100일간의 관찰 기간을 사용합니다. 테이블의 호환성이 확인되면 백그라운드 작업을 통해 곧 기능이 적용됩니다. 또한 기능이 처음 배포될 때는 고객 및 테이블 비율에 따라 점진적으로 진행되므로, 호환되는 워크로드가 있는 테이블에 도달하는 데 최대 3~5개월이 걸릴 수 있습니다.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)