실무자를 위한 확장 가능한 로깅의 궁극적인 가이드

소개: 로깅이 중요한 이유

수십 개의 작업에서 수백 개로 확장하는 것은 관찰 가능성 등 여러 가지 이유로 도전적입니다. 관찰 가능성은 로그, 메트릭, 트레이스와 같은 구성 요소를 분석하여 시스템을 이해하는 능력입니다. 이는 몇 개의 파이프라인만 모니터링하는 작은 데이터 팀에게도 마찬가지로 중요하며, Spark와 같은 분산 컴퓨팅 엔진은 신뢰성 있게 모니터링하고, 디버깅하고, 성숙한 에스컬레이션 절차를 만드는 것이 어려울 수 있습니다.

로깅은 이러한 관찰 가능성 구성 요소 중에서 가장 간단하고 가장 큰 영향을 미칩니다. 로그를 클릭하고 스크롤하여 한 번에 하나의 작업 실행을 확인하는 것은 확장성이 없습니다. 이는 시간이 많이 소요되며, 해석하기 어렵고, 종종 워크플로우의 주제 전문가가 필요합니다. 당신의 데이터 파이프라인에 성숙한 로깅 표준을 구축하지 않으면, 오류나 작업 실패를 문제 해결하는 데 상당히 오랜 시간이 걸리게 되어, 비용이 많이 드는 중단, 비효율적인 에스컬레이션 단계, 그리고 경고 피로를 초래합니다. 

이 블로그에서는 다음을 안내해 드리겠습니다:

• 기본 print 문장에서 벗어나 적절한 로깅 프레임워크를 설정하는 방법.
• Spark log4j 로그를 JSON 형식으로 사용하도록 설정할 시기.
• 그래서 클러스터 로그 저장소를 중앙화하여 쉽게 파싱하고 쿼리할 수 있습니다.
• Databricks에서 사용자 정의 로그 분석을 위해 자신의 작업 공간에 설정할 수 있는 중앙 AI/BI 대시보드를 만드는 방법.

주요 아키텍처 고려사항

다음과 같은 고려사항들은 이 로깅 권장사항을 귀사에 맞게 맞추는 데 중요합니다:

로깅 라이브러리

• 파이썬과 스칼라 모두에 대한 여러 로깅 라이브러리가 존재합니다. 우리의 예제는 Log4j 와 표준 Python logging 모듈을 사용합니다.
• 로깅 라이브러리나 프레임워크의 설정은 다르며, 표준이 아닌 도구를 사용하는 경우 각각의 문서를 참조해야 합니다.

클러스터 유형

• 이 블로그의 예제는 주로 다음 컴퓨팅에 초점을 맞춥니다:
  • Jobs Classic Compute (AWS | Azure | GCP)
  • 만능 클래식 컴퓨트 (AWS | Azure | GCP)
• 이 글을 쓰는 시점에서, 다음과 같은 컴퓨트 유형들은 로그 전달에 대한 지원이 덜 되어 있지만, 로깅 프레임워크에 대한 권장사항은 여전히 적용됩니다:
  • Lakeflow 선언적 파이프라인 (이전의 DLT): 이벤트 로그만 지원합니다
  • 서버리스 작업: 로그 전달을 지원하지 않습니다
  • 서버리스 노트북: 로그 전달을 지원하지 않습니다

데이터 거버넌스

• 데이터 거버넌스는 클러스터 로그까지 확장되어야 합니다. 로그는 실수로 민감한 데이터를 노출할 수 있습니다. 예를 들어, 로그를 테이블에 작성할 때, 어떤 사용자들이 테이블에 접근할 수 있는지 고려하고 최소 권한 접근 설계를 사용해야 합니다.
• 우리는 클러스터 로그를 Unity Catalog 볼륨으로 전달하는 방법을 보여줄 것입니다. 이를 통해 접근 제어와 계보를 더 간단하게 할 수 있습니다. 로그 전달은 Public Preview 에서 사용 가능하며 Unity Catalog가 활성화된 컴퓨팅에서만 지원되며, 사용자에게 표준 액세스 모드 또는 전용 액세스 모드가 할당되어야 합니다.
• 이 기능은 그룹에 할당된 전용 접근 모드를 가진 컴퓨트에서는 지원되지 않습니다.

기술 솔루션 분석

 표준화는 생산 수준의 로그 관찰 가능성에 있어 핵심입니다. 이상적으로는, 솔루션은 수백 개 또는 수천 개의 작업/파이프라인/클러스터를 수용할 수 있어야 합니다.

이 솔루션의 전체 구현을 위해 이 저장소를 방문하십시오: https://github.com/databricks-industry-solutions/watchtower 

중앙 로그 전달을 위한 볼륨 생성

먼저, 로그를 위한 중앙 파일 저장소로 사용할 Unity Catalog Volume 을 생성할 수 있습니다. DBFS 는 동일한 수준의 데이터 거버넌스를 제공하지 않으므로 권장하지 않습니다. 각 환경(예: 개발, 스테이지, 프로덕션)에 대한 로그를 다른 디렉토리 또는 볼륨으로 분리하여 접근을 더 세밀하게 제어하는 것이 좋습니다. 

이를 UI에서 생성하거나, Databricks Asset Bundle (AWS | Azure | GCP) 내부에서, 또는 우리의 경우에는 Terraform을 사용하여 생성할 수 있습니다:

볼륨에 대한 READ VOLUME 및 WRITE VOLUME 권한이 있는지 확인하십시오 (AWS | Azure | GCP). 

클러스터 로그 전달 설정

이제 로그를 넣을 중앙 장소가 생겼으니, 클러스터가 로그를 이 목적지로 전달하도록 설정해야 합니다. 이를 위해, 클러스터에서 컴퓨트 로그 전달을 설정하십시오 (AWS | Azure | GCP).

다시 말해, UI, Terraform 또는 다른 선호하는 방법을 사용하면 됩니다; 우리는 Databricks Asset Bundles (YAML)을 사용할 것입니다:

클러스터나 작업을 실행한 후 몇 분 안에, 우리는 Catalog Explorer에서 볼륨을 찾아 파일이 도착하는 것을 볼 수 있습니다. 클러스터 ID (즉, 0614-174319-rbzrs7rq)로 폴더를 볼 수 있고, 각 로그 그룹에 대한 폴더를 볼 수 있습니다:

• driver: 우리가 가장 관심이 있는 드라이버 노드에서의 로그.
• executor: 클러스터 내 각 Spark executor에서의 로그.
• eventlog: 클러스터 시작, 클러스터 종료, 크기 조정 등 클러스터의 "이벤트 로그" 탭에서 찾을 수 있는 이벤트 로그입니다.
• init_scripts: 이 폴더는 클러스터에 초기 스크립트가 있을 경우 생성됩니다. 우리의 경우에는 그렇습니다. 클러스터의 각 노드에 대한 하위 폴더가 생성되고, 그런 다음 노드에서 실행된 각 초기 스크립트에 대한 stdout 및 stderr 로그를 찾을 수 있습니다.

표준 강제: 클러스터 정책

워크스페이스 관리자는 가능한 한 표준 구성을 강제해야 합니다. 이는 클러스터 생성 접근을 제한하고, 사용자에게 클러스터 로그 구성이 아래와 같이 고정 값으로 설정된 클러스터 정책을 제공하는 것을 의미합니다 (AWS | Azure | GCP): 

이러한 속성을 “고정” 값으로 설정하면 올바른 볼륨 목적지가 자동으로 구성되고 사용자가 속성을 잊어버리거나 변경하는 것을 방지합니다.

이제, asset bundle YAML에서 cluster_log_conf를 명시적으로 설정하는 대신, 사용할 클러스터 정책 ID를 간단히 지정할 수 있습니다:

단순히 print() 문장 이상의 것

print() 문은 개발 중 빠른 디버깅에 유용할 수 있지만, 여러 가지 이유로 생산 환경에서는 부족합니다:

• 구조 부재: Print 문은 구조화되지 않은 텍스트를 생성하여, 로그를 대규모로 파싱, 쿼리, 분석하는 것을 어렵게 합니다.
• 제한된 컨텍스트: 그들은 종종 타임스탬프, 로그 레벨 (예: INFO, WARNING, ERROR), 원래 모듈, 또는 작업 ID와 같은 필수적인 컨텍스트 정보를 부족하게 합니다. 이는 효과적인 문제 해결에 필수적입니다.
• 성능 오버헤드: 과도한 print 문은 Spark에서 평가를 트리거하므로 성능 오버헤드를 초래할 수 있습니다. Print 문은 버퍼링이나 최적화된 처리 없이 표준 출력(stdout)에 직접 쓰게 됩니다.
• 출력 문장의 세부 정보 제어 불가능: 출력 문장의 세부 정보를 제어하는 내장 메커니즘이 없어, 로그가 너무 많거나 세부 정보가 부족합니다.

적절한 로깅 프레임워크, 예를 들어 Scala/Java (JVM)의 Log4j 또는 Python의 내장된 logging 모듈은 이러한 문제들을 모두 해결하고, 생산 환경에서 선호됩니다. 이러한 프레임워크들은 로그 레벨 또는 상세성을 정의하고, JSON과 같은 기계 친화적인 형식을 출력하고, 유연한 목적지를 설정할 수 있게 해줍니다.

또한 Spark 드라이버 로그에서 stdout와 stderr와 log4j 사이의 차이점을 주의하십시오:

• stdout: 드라이버 노드의 JVM에서의 표준 출력 버퍼. 이곳은 기본적으로 print() 문과 일반 출력이 작성되는 곳입니다.
• stderr: 드라이버 노드의 JVM에서의 표준 오류 버퍼. 일반적으로 예외/스택 트레이스가 작성되며, 많은 로깅 라이브러리도 stderr를 기본으로 사용합니다.
• log4j: log4j 로거로 작성된 로그 메시지를 특별히 필터링합니다. 이러한 메시지들은 stderr에서도 볼 수 있습니다.

Python

Python에서는 표준 로깅 모듈을 가져와서 JSON 형식을 정의하고 로그 레벨을 설정하는 것을 포함합니다.

Spark 4 또는 Databricks Runtime 17.0+부터는 PySpark에 간소화된 구조화된 로거가 내장되어 있습니다: https://spark.apache.org/docs/latest/api/python/development/logger.html. 다음 예제는 로거 인스턴스를 pyspark.logger.PySparkLogger 인스턴스로 교체함으로써 PySpark 4에 적용할 수 있습니다.

이 코드의 대부분은 Python 로그 메시지를 JSON으로 포맷하는 것입니다. JSON은 반정형적이며, 사람과 기계 모두에게 읽기 쉬워, 이후에 이 로그를 수집하고 쿼리할 때 이를 더욱 감사하게 될 것입니다. 이 단계를 건너뛰면, 로그 레벨인지 타임스탬프인지 메시지인지 등을 추측하기 위해 복잡하고 비효율적인 정규 표현식에 의존하게 될 수 있습니다.

물론, 이것은 모든 노트북이나 Python 패키지에 포함시키기에는 상당히 장황합니다. 중복을 피하기 위해, 이 보일러플레이트는 유틸리티 코드로 패키지화되어 여러 가지 방법으로 작업에 로드될 수 있습니다:

• 보일러플레이트 코드를 워크스페이스의 파이썬 모듈에 넣고, 워크스페이스 파일 가져오기를 사용하여 메인 노트북의 시작 시 코드를 실행하십시오 (AWS | Azure | GCP).
• 보일러플레이트 코드를 Python 휠 파일로 빌드하고 라이브러리로서 클러스터에 로드합니다 (AWS | Azure | GCP).

scala

같은 원칙이 Scala에도 적용되지만, 대신 Log4j를 사용하거나, 더 구체적으로는 SLF4j 추상화를 사용할 것입니다:

UI에서 드라이버 로그를 보면, Log4j 아래에서 INFO와 WARN 로그 메시지를 찾을 수 있습니다. 이는 기본 로그 레벨이 INFO이기 때문에 DEBUG와 TRACE 메시지는 작성되지 않습니다.

그러나 Log4j 로그는 JSON 형식이 아닙니다! 다음에 이를 어떻게 수정하는지 살펴보겠습니다.

Spark 구조화된 스트리밍을 위한 로깅

스트리밍 작업에 유용한 정보, 예를 들어 스트리밍 소스 및 싱크 메트릭 및 쿼리 진행 상황을 캡처하기 위해, 우리는 또한 Spark의 StreamingQueryListener를 구현할 수 있습니다.

그런 다음 쿼리 리스너를 Spark 세션에 등록하십시오:

Spark 구조화된 스트리밍 쿼리를 실행하면, 이제 log4j 로그에서 다음과 같은 것을 볼 수 있습니다 (참고: 이 경우에는 Delta 소스와 싱크를 사용합니다; 상세 메트릭은 소스/싱크에 따라 다를 수 있습니다):

Spark Log4j 로그 설정

지금까지, 우리는 우리 자신의 코드의 로깅에만 영향을 미쳤습니다. 그러나, 클러스터의 드라이버 로그를 보면, 실제로는 Spark 내부에서 많은 로그가 더 많이 보입니다. 우리가 코드에서 Python 또는 Scala 로거를 생성하더라도 이것은 Spark 내부 로그에 영향을 주지 않습니다.

이제 우리는 드라이버 노드의 Spark 로그를 표준 JSON 형식을 사용하도록 설정하는 방법을 검토할 것입니다. 이 형식은 우리가 쉽게 파싱할 수 있습니다.

Log4j는 로컬 설정 파일을 사용하여 포맷팅과 로그 레벨을 제어하며, 우리는 클러스터 초기화 스크립트를 사용하여 이 설정을 수정할 수 있습니다 (AWS | Azure | GCP). DBR 11.0 이전에는 Log4j v1.x가 사용되었으며, Java Properties (log4j.properties)를 사용하였습니다. 파일을 참조하세요. DBR 11.0+는 Log4j v2.x를 사용하며 XML (log4j2.xml)을 사용합니다. 파일 대신 사용합니다.

Databricks 드라이버 노드의 기본 log4j2.xml 파일은 기본 로그 형식에 대한 PatternLayout을 사용합니다:

우리는 다음 초기화 스크립트를 사용하여 이를 JsonTemplateLayout으로 변경할 것입니다:

이 초기화 스크립트는 단순히 PatternLayout을 JsonTemplateLayout로 교체합니다. 초기화 스크립트는 클러스터의 모든 노드에서 실행되며, 이에는 작업자 노드도 포함됩니다; 이 예에서는 우리는 단지 상세성을 위해 드라이버 로그를 구성하고 나중에 드라이버 로그만 수집할 것이기 때문입니다. 그러나, 설정 파일은 또한 작업자 노드에서 /home/ubuntu/databricks/spark/dbconf/log4j/executor/log4j.properties.에서 찾을 수 있습니다.

필요에 따라 이 스크립트에 추가하거나, 원본 파일의 전체 내용을 더 쉽게 수정하기 위해 cat $LOG4J2_PATH 를 사용하여 볼 수 있습니다.

다음으로, 우리는 이 초기 스크립트를 Unity Catalog Volume에 업로드할 것입니다. 조직화를 위해, 우리는 이전의 원시 로그 볼륨을 재사용하는 대신 별도의 볼륨을 생성할 것이며, 이는 Terraform에서 다음과 같이 수행할 수 있습니다:

이것은 볼륨을 생성하고 초기화 스크립트를 자동으로 업로드합니다. 

하지만 우리는 여전히 이 초기화 스크립트를 사용하도록 클러스터를 설정해야 합니다. 이전에는 클러스터 정책을 사용하여 로그 전달 대상을 강제하였고, 이 초기화 스크립트에 대해서도 동일한 유형의 강제를 할 수 있어, 우리의 Spark 로그가 항상 구조화된 JSON 형식을 가지도록 할 수 있습니다. 다음을 추가하여 이전의 정책 JSON을 수정할 것입니다: 

여기서 고정값을 사용하면 초기화 스크립트가 항상 클러스터에 설정되도록 보장합니다.

이제, 우리가 이전에 실행한 Spark 코드를 다시 실행하면, Log4j 섹션의 모든 드라이버 로그가 JSON으로 잘 포맷되어 있는 것을 볼 수 있습니다!

로그 수집

이 시점에서, 우리는 기본적인 print 문을 구조화된 로깅으로 대체하고, 그것을 Spark의 로그와 통합하고, 우리의 로그를 중앙 볼륨으로 라우팅했습니다. 이것은 이미 카탈로그 탐색기나 Databricks CLI를 사용하여 로그 파일을 찾아보고 다운로드하는 데 유용합니다: databricks fs cp dbfs:/Volumes/watchtower/default/cluster_logs/cluster-logs/$CLUSTER_ID . --recursive.

그러나, 이 로깅 허브의 진정한 가치는 우리가 로그를 Unity Catalog 테이블로 수집할 때 볼 수 있습니다. 이로써 루프가 닫히며, 우리는 표현력 있는 쿼리를 작성하고, 집계를 수행하며, 심지어 일반적인 성능 문제를 감지할 수 있는 테이블을 얻게 됩니다. 이 모든 것은 곧 다룰 예정입니다!

로그를 취득하는 것은 Lakeflow Declarative Pipelines 덕분에 쉽고, 우리는 Auto Loader를 사용하여 데이터를 점진적으로 로드하는 메달리온 아키텍처를 사용할 것입니다. 

Bronze 로그

첫 번째 테이블은 단순히 원시 드라이버 로그 데이터를 로드하는 브론즈 테이블로, 파일 이름, 크기, 경로, 마지막 수정 시간 등의 추가 열을 추가합니다.

Lakeflow 선언적 파이프라인의 기대치를 사용하면 (AWS | Azure | GCP), 우리는 또한 기본 데이터 품질 모니터링을 얻을 수 있습니다. 다른 테이블에서 이러한 데이터 품질 검사를 더 많이 볼 것입니다.

Silver 로그

다음 (실버) 테이블은 더 중요합니다; 로그의 각 행을 파싱하여 로그 레벨, 로그 타임스탬프, 클러스터 ID, 로그 소스 (stdout/stderr/log4j) 등의 정보를 추출하고자 합니다. 

참고: 가능한 한 JSON 로깅을 구성했지만, 시작 시에 실행되는 다른 도구로부터의 원시 텍스트를 일정 정도로 가지고 있을 것입니다. 이들 대부분은 stdout에 있을 것이며, 우리의 실버 변환은 메시지를 JSON으로 파싱하려고 시도하고, 필요할 때만 regex로 대체하는 등 파싱을 유연하게 유지하는 한 가지 방법을 보여줍니다.

컴퓨트 ID들

파이프라인의 마지막 테이블은 Databricks 시스템 테이블 위에 구축된 머티리얼라이즈드 뷰입니다. 각 작업 실행에 사용된 컴퓨트 ID를 저장하고, 특정 로그를 생성한 작업 ID를 검색하려 할 때 미래의 조인을 단순화할 것입니다. 단일 작업이 여러 클러스터를 가질 수 있으며, 작업 클러스터가 아닌 웨어하우스에서 실행되는 SQL 작업이 있을 수 있으므로, 이 참조를 사전 계산하는 것의 유용성에 유의하십시오.

파이프라인 배포

파이프라인은 UI, Terraform, 또는 우리의 에셋 번들 내에서 배포될 수 있습니다. 우리는 자산 번들을 사용하고 다음의 리소스 YAML을 제공할 것입니다:

AI/BI 대시보드로 로그 분석

마지막으로, 우리는 작업, 작업 실행, 클러스터, 작업 공간을 통해 로그 데이터를 쿼리할 수 있습니다. Unity Catalog 관리 테이블의 최적화 덕분에, 이 쿼리들은 빠르고 확장 가능할 것입니다. 몇 가지 예를 살펴봅시다.

상위 N개의 오류

이 쿼리는 가장 흔히 발생하는 오류를 찾아, 오류 처리를 우선순위화하고 개선하는 데 도움을 줍니다. 이는 가장 일반적인 문제를 다루는 런북을 작성하는 데 유용한 지표가 될 수도 있습니다.

오류별 상위 N개의 작업

이 쿼리는 관찰된 오류의 수에 따라 작업을 순위를 매겨, 가장 문제가 많은 작업을 찾는 데 도움을 줍니다.

AI/BI 대시보드

이 쿼리들을 Databricks AI/BI 대시보드에 넣으면, 모든 로그를 검색하고 필터링하며, 일반적인 문제를 감지하고, 문제를 해결하는 중앙 인터페이스를 갖게 됩니다. 

이 예제 AI/BI 대시보드는 GitHub에서 이 솔루션에 대한 모든 다른 코드와 함께 사용할 수 있습니다.

실제 시나리오

참조 대시보드에서 보여준 것처럼, 이런 종류의 로깅 솔루션은 다음과 같은 많은 실용적인 사용 사례를 지원합니다:

• 단일 작업에 대한 모든 실행 로그 검색
• 모든 작업에 대한 로그 검색
• 가장 흔한 오류에 대한 로그 분석
• 가장 많은 오류를 가진 작업 찾기
• 성능 문제 또는 경고 모니터링:
  • GC 오버헤드
  • Spark spill
• 로그에서 PII 감지

현실적인 시나리오에서는, 실무자들이 오류를 이해하기 위해 한 작업 실행에서 다음 작업 실행으로 수동으로 이동하고, 어떤 경고를 우선 순위에 두어야 하는지 모릅니다. 강력한 로그를 설정하는 것뿐만 아니라 이를 저장할 표준 테이블을 설정함으로써, 실무자들은 가장 흔한 오류를 우선 순위에 두어 로그를 간단히 쿼리할 수 있습니다. 메모리 부족 오류로 인해 1개의 작업 실행이 실패했는데, SELECT가 무심코 서비스 주체에서 철회되어서 발생한 권한 오류로 인해 10개의 작업이 실패했다고 가정해 봅시다. 당직 팀은 일반적으로 경보의 급증으로 피곤하지만, 이제 권한 오류가 더 높은 우선 순위라는 것을 빠르게 인지하고, 10개의 작업을 복구하기 위해 문제를 해결하기 시작합니다.

마찬가지로, 실무자들은 종종 같은 작업의 여러 번의 실행 로그를 확인하여 비교해야 합니다. 실제 예로는, 작업의 각 배치 실행에서 특정 로그 메시지의 타임스탬프를 다른 메트릭이나 그래프 (예: "배치 완료"가 로그되었을 때 vs. 호출한 API의 요청 처리량 그래프)와 연관시키는 것입니다. 로그를 수집하면 이를 단순화하여, 작업 ID와 선택적으로 작업 실행 ID 목록에 필터를 적용하여 테이블을 쿼리할 수 있으며, 각 실행을 한 번에 하나씩 클릭할 필요가 없습니다.

운영 고려사항

• 클러스터 로그는 선택한 목적지에서 매 5분마다 전달되며, 매시간 gzip으로 압축됩니다.
• 테이블에서 최상의 성능을 얻기 위해 Predictive Optimization과 Liquid Clustering을 사용한 Unity Catalog-managed 테이블을 사용하는 것을 잊지 마십시오.
• 원시 로그는 무한정 저장할 필요가 없으며, 이는 클러스터 로그 전달이 사용될 때의 기본 동작입니다. 우리의 선언적 파이프라인에서, Auto Loader 옵션 cloudFiles.cleanSource 를 사용하여 지정된 보존 기간 후에 파일을 삭제하도록 설정하며, 이는 cloudFiles.cleanSource.retentionDuration으로도 정의됩니다. 또한 클라우드 스토리지 수명주기 규칙을 사용할 수도 있습니다.
• Executor 로그도 설정하고 취득할 수 있지만, 대부분의 오류는 어차피 드라이버로 전파되므로 일반적으로 필요하지 않습니다.
• 수집된 로그 테이블을 기반으로 자동 알림을 위해 Databricks SQL 알림 (AWS | Azure | GCP)을 추가하는 것을 고려하십시오.
• Lakeflow Declarative Pipelines는 자체 이벤트 로그를 가지고 있으며, 파이프라인 활동을 모니터링하고 검사하는 데 사용할 수 있습니다. 이 이벤트 로그는 Unity Catalog에도 작성될 수 있습니다.

통합 및 해야 할 작업

고객들은 또한 로그를 Loki, Logstash, 또는 AWS CloudWatch와 같은 인기 있는 로깅 도구와 통합하길 원할 수도 있습니다. 각각은 자신만의 인증, 구성, 연결 요구사항을 가지고 있지만, 이들 모두는 클러스터 초기화 스크립트를 사용하여 구성하고 대부분의 경우 로그 전달 에이전트를 실행하는 매우 유사한 패턴을 따를 것입니다.

주요 학습 내용

요약하면, 주요 교훈은 다음과 같습니다:

• 프로덕션에서는 출력 문장이 아닌 표준화된 로깅 프레임워크를 사용하세요.
• Log4j 설정을 사용자 정의하기 위해 클러스터 범위의 초기 스크립트를 사용하십시오.
• 로그를 중앙화하기 위해 클러스터 로그 전달을 설정합니다.
• 최상의 테이블 성능을 위해 예측 최적화와 Liquid 클러스터링을 사용한 Unity 카탈로그 관리 테이블을 사용하세요.
• Databricks는 로그를 수집하고 풍부하게 만들어 더 큰 분석을 가능하게 합니다.

다음 단계

오늘부터 로그를 생산화하기 시작하십시오. 이 전체 솔루션에 대한 GitHub 저장소를 여기에서 확인하십시오: https://github.com/databricks-industry-solutions/watchtower!

Databricks Delivery Solutions Architects (DSAs) 는 조직 전반의 데이터 및 AI 이니셔티브를 가속화합니다. 그들은 구조적 리더십을 제공하며, 플랫폼을 비용과 성능에 최적화하며, 개발자 경험을 향상시키고, 프로젝트 실행을 성공적으로 이끕니다. DSAs는 초기 배포와 생산 수준의 솔루션 사이의 간극을 메우며, 데이터 엔지니어링, 기술 리드, 임원, 그리고 다른 이해관계자를 포함한 다양한 팀과 긴밀하게 협력하여 맞춤형 솔루션과 더 빠른 가치 창출을 보장합니다. 맞춤형 실행 계획, 전략적 지침, 그리고 DSA로부터의 데이터 및 AI 여정에 대한 지원을 받기 위해서는 Databricks 계정 팀에 연락하십시오.

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