Amoro + Apache Iceberg를 기반으로 클라우드 네이티브 레이크 웨어하우스를 구축하는 Cisco의 사례

Amoro는 Apache Iceberg와 같은 개방형 데이터 레이크 테이블을 기반으로 구축된 레이크 창고 관리 시스템입니다. NetEase Shufan의 빅 데이터 팀이 오픈 소스로 제공하고 플러그형 데이터 자체 최적화 메커니즘과 관리 서비스 세트를 제공하여 사용자에게 가져오기 기능을 제공하는 것을 목표로 합니다. - 즉시 사용 가능한 Hucang 경험. 이 기사는 Cisco WebEx 데이터 플랫폼의 소프트웨어 엔지니어인 Bai Xu가 작성한 것이며 Cisco 클라우드 네이티브 레이크 웨어하우스 시나리오에서 Amoro의 사례를 공유합니다.

01 Webex의 Amoro

Cisco Webex 제품은 온라인 미팅, 팀 메시징, 파일 공유를 포함한 기능을 제공합니다. 이 제품군은 통합 커뮤니케이션 분야의 선도적인 협업 플랫폼으로 간주되며 중소기업을 위한 소그룹 협업은 물론 전사적 배포를 위한 대규모 그룹 회의에도 적합합니다.

아모로를 선택하는 이유

Webex 빅 데이터 팀은 처음에 Hive 스토리지 형식을 기본 표준으로 채택했습니다. 그러나 Hive 스토리지 형식의 한계로 인해 고객별 데이터를 수정하고 데이터 역추적을 수행하는 것은 매우 비효율적입니다. 또한 Hive를 사용하면 유지 관리 오버헤드도 늘어납니다. 이러한 과제를 해결하기 위해 우리는 대체 스토리지 솔루션을 찾기 시작했습니다. 이때 우리는 운영 및 유지 관리 비용을 절감할 뿐만 아니라 핵심 비즈니스 운영의 효율성을 향상시키도록 설계된 Apache Iceberg를 발견했습니다. 따라서 우리는 Apache Iceberg를 기반으로 데이터 레이크를 구축하기 시작했습니다. 작년부터 Webex는 점진적으로 Iceberg V2 형식을 기본 테이블 형식으로 사용했습니다. V2의 중요한 기능 중 하나는 행 수준 업데이트 기능이지만 V2 테이블을 읽을 때 MOR(Merge-on-Read)로 인해 발생하는 성능 문제라는 핵심 문제가 발생합니다. 삭제 파일이 많이 누적되면 Iceberg를 사용하는 보고서 쿼리의 적시성이 크게 줄어들며 사용하지 못할 수도 있습니다. 먼저 Spark 압축 절차를 사용하여 작은 파일을 병합하고 스케줄링 시스템을 통해 정기적 및 순차적으로 실행하려고 했습니다.

그러나 상대적으로 원시적인 이 유지 관리 방법에는 다음과 같은 많은 단점이 있습니다.

● 높은 리소스 사용량: 각 Spark 작업은 코어 40개와 메모리 300GB를 초과할 수 있습니다.

● 긴 실행 시간: 각 환경에는 병합해야 할 Iceberg 테이블이 많으며, 많은 양의 데이터가 포함된 테이블을 병합할 경우 다른 테이블이 차단되므로 각 Pocedure의 실행 시간이 너무 길어집니다.

● 낮은 내결함성: 병합 작업에는 여러 개의 Iceberg 테이블이 포함될 수 있으며, 특정 테이블에 오류가 발생하면 전체 작업이 실패합니다.

● 유지 관리의 어려움: 병합에 실패한 테이블은 수동으로 다시 시작하고 복구해야 하며 누락될 수도 있습니다.

위에서 언급한 문제점으로 인해 우리는 Iceberg 테이블의 많은 유지 관리 문제를 해결하기 위해 Amoro를 신속하게 도입했습니다. Amoro Management Service(AMS)에서 생성된 최적화 작업을 가져와 처리하기 위해 외부 Flink Optimizer 등록 방법을 사용합니다. 그리고 스냅샷 만료 및 데이터 만료와 같은 서비스가 활성화되어 스토리지 시스템에 대한 부담을 줄일 수 있습니다.

Amoro는 기존의 예약된 Spark 작업의 많은 문제점을 해결하고 여러 가지 이점을 제공합니다.

● 높은 자원 활용도: 가장 많은 자원을 차지하는 환경 관점에서 Flink Optimizer를 사용하면 자원 사용량을 약 70% 절약할 수 있습니다.

● 높은 내결함성: 실패한 최적화 프로세스/작업은 다음 스캔 후 최적화를 다시 시도할 수 있습니다.

● 적시성: 지속적인 병합 최적화를 통해 Iceberg 테이블의 쿼리 효율성이 제어 가능한 범위 내에서 유지되고 보고서의 쿼리 효율성이 보장됩니다.

● 자체 관리: Amoro는 테이블 속성을 기반으로 최적화 활성화 여부만 결정하고, 테이블 수준 최적화 켜기/끄기 및 관련 전략을 제어할 수 있습니다.

● 시각화: Amoro는 최적화 상태, 테이블 기본 정보 등을 개발자에게 제공하기 위해 WebUI를 제공합니다.

용법

Amoro(이전 Arctic) 프로젝트가 오픈 소스로 공개된 직후 Cisco Webex는 이를 사용하여 Iceberg의 작은 파일 병합 및 스냅샷 만료 정리 등 다양한 데이터 레이크 관리 문제를 해결하려고 했습니다. 오늘부터 Amoro는 Webex에서 특정 규모의 실행을 달성했습니다.

●다중 데이터 센터, 다중 클러스터 배포: 최대 7개의 서로 다른 데이터 센터, Hadoop 클러스터 환경

● 다중 환경: Amoro를 사용하여 Hadoop 환경에서 Iceberg 테이블을 관리할 뿐만 아니라 최근에는 AWS 환경에 배포하고 AWS에서 Iceberg 테이블을 최적화했습니다.

● 1000+ Iceberg Table 그러나 회사의 실제 상황에 따라 점차적으로 Hadoop 환경을 AWS 환경으로 마이그레이션할 예정이며, 이 기간 동안 발생한 실제 문제와 해결 방법은 이 기사에서 논의할 수 있습니다.

02 AWS의 아모로

AWS에서 해결해야 할 문제가 많은데, 첫 번째는 Catalog와 FileSystem 간 전환 등 Iceberg AWS 통합이고, 다른 하나는 AMS 측의 적응입니다.

아이스버그 AWS 통합

Iceberg를 AWS에 온라인으로 가져온 후 HiveCatalog에서 GlueCatalog로 전환하고 파일 시스템도 HDFS에서 S3으로 전환했습니다. HDFS에 비해 S3는 더 완전한 권한 제어 기능을 갖추고 있으며, 버킷을 나누고 파일에 대한 다양한 권한을 IAM 계정별로 나누어 세분화된 권한 제어를 달성할 수 있습니다. 이는 데이터 레이크에서 데이터 보안과 개인정보 보호를 보장하는 핵심 요소입니다. 둘째, HDFS는 일반적으로 자체 하드웨어 및 유지 관리를 관리해야 하므로 초기 및 운영 비용이 더 많이 필요할 수 있습니다.S3는 비용 모델이 사용량에 따라 결정되고 하드웨어 유지 관리 비용이 없는 클라우드 서비스입니다. 서비스로서 Hive Metastore를 다양한 환경에 별도로 배포해야 하며, 메타데이터 정보를 저장하기 위해 MySQL을 유지해야 하므로 Glue에 비해 자체 유지 관리 비용이 증가합니다. 예를 들어, 실제 프로덕션 환경에서 MySQL 연결 수가 상한에 도달하여 HMS를 다시 시작할 수 없는 상황이 발생했습니다. Glue는 HMS보다 간단하고 수동 유지 관리가 필요하지 않으며 여러 환경의 별도 배포로 인해 발생하는 데이터 아일랜드 문제를 줄입니다.

잠금 관리자

Iceberg의 경우 S3와 같은 일부 파일 시스템은 메타데이터 원자성을 보장하기 위해 파일 쓰기 제외를 제공하지 않습니다. HMS는 단독 잠금을 위해 MySQL을 사용하는 반면 Glue는 사용자 지정 잠금 구현이 필요합니다. AWS에서 Iceberg는 테이블 동시성을 보장하기 위해 DynamoDBLockManager를 제공합니다. 수정

1. Iceberg는 새 메타데이터.json 파일을 수정하고 LockManager 서비스에서 잠금을 얻으려고 시도합니다.

2. 다른 프로세스가 잠금을 획득하면 다시 시도합니다. 시도 횟수와 간격은 관련 매개변수로 구성할 수 있습니다.

3. 잠금을 획득한 후 현재 메타데이터 파일의 위치를 새로 작성된 Metadata-v2.json 주소로 바꿉니다.

4. 여러 번 시도한 후에도 잠금을 획득할 수 없는 경우 커밋이 실패하고 다시 시도될 수 있습니다.

5. Metadata.json 파일을 성공적으로 제출한 후 Iceberg는 마침내 잠금을 해제합니다.

DynamoDB 잠금 테이블의 데이터 모델은 다음과 같습니다.

기본 키	속성
엔터티 ID 잠금	임대 기간(밀리초)	버전	소유자 ID 잠금
pda.주문	15000	d3b9b4ec-6c02-4e7e-9570-927ba1bafa67	s3://wap-bucket/orders/metadata/d3b9b4ec-6c02-4e7e-9570-927ba1bafa67-metadata.json
pda.고객	15000	0f50e24d-e7da-4c8b-aa4b-1b95a50c7f38	s3://wap-bucket/customers/metadata/0f50e24d-e7da-4c8b-aa4b-1b95a50c7f38-metadata.json
pda.제품	15000	2dab53a2-7c63-4b95-8fe1-567f73e58d6c	s3://wap-bucket/products/metadata/2dab53a2-7c63-4b95-8fe1-567f73e58d6c-metadata.json

● 엔터티Id는 DynamoDB 테이블의 키이며 Iceberg 데이터베이스 이름과 테이블 이름으로 구성됩니다.

● 임대 기간은 잠금 하트비트 시간 초과이며, 잠금 시간이 초과되면 자동으로 해제됩니다.

● 버전은 현재 스레드에서 잠금을 유지하도록 DynomoDBHeartbeat에서 무작위로 업데이트하는 UUID 문자열입니다.

● ownerId는 작성될 새 메타데이터.json 파일입니다.

DynamoDB를 사용하여 Iceberg 테이블에 대한 동시 수정을 관리하면 Hive Metastore 서비스에서 해제되지 않은 잠금으로 인해 발생하는 작업 차단을 방지할 수 있습니다. 왜냐하면 DynamoDB에서 잠금을 보유한 프로세스가 비정상적으로 종료되는 경우 수동 잠금 해제 없이 임대가 만료된 후 해당 잠금이 자동으로 해제되기 때문입니다. ...

권한 제어

AWS IAM 계정은 S3, Glue, DynamoDB 및 기타 관련 서비스에 대한 세분화된 권한 제어를 제공할 수 있습니다. 현재 각 팀에 IAM 계정을 할당하고 있는데, IAM 계정은 해당 S3 버킷에 대한 읽기 및 쓰기 권한을 부여하고 Glue 권한도 관리할 수 있습니다. 우리의 AMS 서비스와 읽기 및 쓰기 작업은 모두 Kubernetes에서 실행되므로 자연스럽게 네임스페이스를 하나의 단위로 사용하여 IAM 계정을 할당하고 모든 사람의 관련 네임스페이스 권한을 관리한 다음 나중에 논의할 Iceberg 테이블의 권한 제어를 쉽게 구현할 수 있습니다. S3 및 Glue 권한을 보다 세부적으로 구분합니다.

S3 지능형 계층화

S3를 Iceberg에 읽고 쓰는 비용을 조사하는 과정에서 Webex 팀은 AWS S3에 상당히 가치 있는 속성이 있지만 아직 Iceberg에 적용되지 않은 속성인 스토리지 클래스가 있음을 발견했습니다. 이 구성을 S3 Intelligent-Tiering으로 설정하면 다양한 액세스 빈도에 따라 액세스 비용을 최적화할 수 있습니다.

Amazon S3 Intelligent-Tiering 스토리지 클래스는 액세스 패턴이 변경될 때 데이터를 가장 비용 효율적인 액세스 계층으로 자동으로 이동하여 스토리지 비용을 최적화하도록 설계되었습니다. S3 Intelligent-Tiering 스토리지 클래스는 빈번한 액세스에 최적화된 계층, 자주 액세스하지 않는 데 최적화된 저비용 계층, 거의 액세스하지 않는 데이터를 위한 계층의 세 가지 액세스 계층에 객체를 자동으로 저장합니다. 최적화된 초저비용 계층입니다. 객체 모니터링 및 자동화에 대한 소액의 월 요금으로 S3 Intelligent-Tiering은 30일 연속으로 액세스하지 않은 객체를 자주 액세스하지 않는 계층으로 이동한 다음 90일 동안 활동이 없으면 이동하여 40%의 비용 절감을 실현할 수 있습니다. Instant Access 계층을 보관하고 68%의 비용 절감을 실현합니다.

이 수정 사항은 Iceberg 커뮤니티에 기여되었으며 1.4.0 https://github.com/apache/iceberg/releases/tag/apache-iceberg-1.4.0 에서 릴리스되었습니다 .

AMS AWS 적응

AWS 환경에서 실행하기 위해 초기 AMS는 Custom Catalog를 통해 Iceberg의 GlueCatalog를 생성 및 적용했으며 Arctic의 FileIO 관련 인터페이스를 재구성하여 개체 파일 시스템을 지원했습니다. 버전 0.6.0에서는 IAM 및 기타 관련 속성을 입력하도록 요구하는 등 별도의 카탈로그 유형으로 GlueCatalog를 사용할 것으로 예상되며, 이는 AWS 환경에 더 잘 적응할 것입니다.

AMS와 Optimizer 모두 Iceberg와 해당 파일에 액세스해야 합니다. 직접적인 방법은 위 구성 요소에 필요한 병합 테이블 읽기 및 쓰기 권한에 액세스할 수 있는 IAM 계정을 제공하는 것입니다. IAM 관련 인증을 환경 변수에 넣습니다. 기본값 read DefaultAWSCredentialsProviderChain을 가져온 후 관련 인증 정보를 올바르게 획득하여 인증을 완료합니다. k8s 환경의 env 변수에 넣으십시오. 예를 들면 다음과 같습니다.

apiVersion: apps/v1kind: Deploymentmetadata:  labels:    app.kubernetes.io/name: ams  name: amsspec:  ...  template:    metadata:      labels:        app.kubernetes.io/name: ams    spec:      ...      containers:        - env:            - name: AWS_ACCESS_KEY_ID              value: AKIXXXXXXXXXXXXXXXX            - name: AWS_SECRET_ACCESS_KEY              value: fjHyrM1wTJ8CLP13+GU1bCGG1RGlL1xT1lXyBb11

또한 AWS는 2019년에 AWS Identity API, OpenID Connect(OIDC) 및 Kubernetes 서비스 계정을 사용하여 Kubernetes 포드에 세분화된 액세스 제어를 적용하는 서비스 계정용 IAM 역할(IRSA)을 도입했습니다. IAM 역할은 서비스 계정에 바인딩됩니다. 이는 AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY와 같은 매개변수를 구성하는 것보다 더 간단하고 안전하며 인증 일반 텍스트 정보를 직접 노출하지 않습니다.

IRSA: https://aws.amazon.com/cn/blogs/containers/diving-into-iam-roles-for-service-accounts/

03 배포실습

이 기사에서는 Amoro 0.6.0 버전을 예로 들어 Helm 차트를 템플릿으로 사용하여 Kubernetes 환경에 Amoro를 배포하고 Iceberg 최적화를 활성화하는 프로세스를 대략적으로 정리합니다. Helm Chart를 사용한 배포는 비교적 간단하며, 보다 자세한 클라우드 배포 방법은 이전 기사인 Apache Iceberg + Arctic의 클라우드 네이티브 레이크 웨어하우스 구축 실제 사례를 참조하세요 . Amoro와 Helm에 일부 변경 사항을 적용했다는 점은 주목할 가치가 있으므로 Amoro 커뮤니티의 Helm 차트와 약간 다를 수 있지만 일반적인 프로세스는 동일합니다.

포장 이미지

수동 포장:

mvn clean install -DskipTests -am -e -pl dist

그런 다음 패키지된 zip 패키지를 Dockerfile이 있는 디렉터리에 넣고 Docker 이미지를 패키지합니다.

docker build docker/ams/ --platform amd64 -t xxx/amoro && docker push xxx/amoro

패키지된 Docker 이미지는 다음 배포 리소스에서 참조되고 배포됩니다.

Helm 차트 작성

Values에 배치될 기본 구성 정보 외에도 기밀 속성 및 데이터베이스 계정 비밀번호가 포함된 IAM 인증 정보가 Secrets에 저장됩니다. bin/config.sh 및 conf/config.yaml과 같은 AMS 구성 정보를 ConfigMap으로 추출하고 각각 env 및 VolumeMounts에 마운트합니다. 공간 제한으로 인해 여기에 모든 구성 파일이 나열되지는 않습니다.

● 이미지, 라벨 등 사전 정의된 기본 정보가 포함된 _helpers.tpl 템플릿

{{- define "udp.amoro.image.fullname" -}}
{{ .Values.image.repository }}/{{ .Values.image.component }}:{{ .Values.image.tag | default .Chart.AppVersion }}
{{- end -}}

{{- define "udp.amoro.common.labels" -}}
app.kubernetes.io/instance: {{ .Release.Name }}
app.kubernetes.io/managed-by: {{ .Release.Service }}
{{- end -}}

{{- define "amoro.home" -}}
{{ .Values.amoroHome | default "/usr/local/amoro" }}
{{- end -}}

● 포드 장착 등을 위한 구성 파일을 정의하는 _pod.tpl 템플릿.

{{- define "amoro.pod.container.mounts" }}
- name: logs
  mountPath: {{ include "amoro.home" . }}/logs
- name: conf
  mountPath: {{ include "amoro.home" . }}/conf/config.yaml
  readOnly: true
  subPath: "config.yaml"
{{- if or .Values.amoroConf.log4j2 }}
{{- /* log4j2.yaml from config-map*/ -}}
- name: conf
  mountPath: {{ include "amoro.home" . }}/conf/log4j2.xml
  readOnly: true
  subPath: "log4j2.xml"
{{- end }}
{{- if or .Values.jvmOptions }}
- name: conf
  mountPath: {{ include "amoro.home" . }}/conf/jvm.properties
  readOnly: true
  subPath: "jvm.properties"
{{- end -}}
{{- end -}}
{{- /* define amoro.pod.container.mounts end */ -}}

{{/* defined volumes for pod */}}
{{- define "amoro.pod.volumes" -}}
- name: conf
  configMap:
    name: config.yaml
- name: logs
  emptyDir: {}
{{- end -}}
{{- /* define "amoro.pod.volumes" end */ -}}

● 배포

커뮤니티와 다르게 IRSA나 IAM 인증을 환경 변수에 넣어 통일된 관리와 업데이트를 진행하고 있으며, 또한 Optimizer는 외부 모드를 사용하여 AMS와 Optimizer 간의 연결성에 좀 더 주의를 기울이기 때문에 livenessProbe 프로브는 TCP를 최적화하는 것으로 변경되었습니다. 포트.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/name: ams
  name: ams
spec:
  replicas: {{ .Values.replicas }}
  selector:
    matchLabels:
      app.kubernetes.io/name: ams
  strategy:
    type: {{ .Values.strategy.type | quote }}
    rollingUpdate:
      maxSurge: {{ .Values.strategy.rollingUpdate.maxSurge | quote }}
      maxUnavailable: {{ .Values.strategy.rollingUpdate.maxUnavailable | quote }}
  template:
    metadata:
      labels:
        app.kubernetes.io/name: ams
    spec:
      {{- if .Values.affinity }}
      affinity:
        {{- toYaml .Values.affinity | nindent 8 }}
      {{- end }}
      {{- if .Values.nodeSelector }}
      nodeSelector:
        {{- toYaml .Values.nodeSelector | nindent 8 }}
      {{- end }}
      {{- if .Values.tolerations }}
      tolerations:
        {{- toYaml .Values.tolerations | nindent 8 }}
      {{- end }}
      {{- if .Values.image.pullSecret }}
      imagePullSecrets:
        - name: {{ .Values.image.pullSecret }}
      {{- end }}
      serviceAccountName: {{ .Values.serviceAccount.name }}
      containers:
        - env:
            - name: AMS_DATABASE_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: udp-amoro-externaldb-secret
                  key: database-password-udp
          image: {{ include "udp.amoro.image.fullname" .}}
          imagePullPolicy: {{ .Values.image.pullPolicy }}
          name: ams
          ports:
            - containerPort: {{ .Values.ports.amoroServer }}
              name: "amoro-server"
            - containerPort: {{ .Values.ports.optimizing }}
              name: "optimizing"
            - containerPort: {{ .Values.ports.jmxExporter }}
              name: "jmx-exporter"
          {{- if .Values.livenessProbe.enabled }}
          livenessProbe:
            tcpSocket:
              port: {{ .Values.ports.optimizing }}
            initialDelaySeconds: {{ .Values.livenessProbe.initialDelaySeconds }}
            periodSeconds: {{ .Values.livenessProbe.periodSeconds }}
            timeoutSeconds: {{ .Values.livenessProbe.timeoutSeconds }}
            failureThreshold: {{ .Values.livenessProbe.failureThreshold }}
            successThreshold: {{ .Values.livenessProbe.successThreshold }}
          {{- end }}
          {{- if .Values.readinessProbe.enabled }}
          readinessProbe:
            httpGet:
              path: /versionInfo
              port: amoro-server
            initialDelaySeconds: {{ .Values.readinessProbe.initialDelaySeconds }}
            periodSeconds: {{ .Values.readinessProbe.periodSeconds }}
            timeoutSeconds: {{ .Values.readinessProbe.timeoutSeconds }}
            failureThreshold: {{ .Values.readinessProbe.failureThreshold }}
            successThreshold: {{ .Values.readinessProbe.successThreshold }}
          {{- end }}
          resources:
            {{- toYaml .Values.resources | nindent 12 }}
          volumeMounts:
            {{- include "amoro.pod.container.mounts" . | nindent 12}}
          securityContext:
            {{- toYaml .Values.podSecurityContext | nindent 12 }}
      dnsPolicy: ClusterFirst
      restartPolicy: {{ .Values.image.restartPolicy }}
      schedulerName: default-scheduler
      terminationGracePeriodSeconds: 30
      volumes:
        {{- include "amoro.pod.volumes" . | nindent 8}}

● 서비스

Amoro Pod가 액세스하는 포트 정의

apiVersion: v1
kind: Service
metadata:
  labels:
    {{- include "udp.amoro.labels" . | nindent 4 }}
  name: ams
spec:
  ports:
    - name: amoro-server
      port: {{ .Values.ports.amoroServer }}
      protocol: TCP
    - name: optimizing
      port: {{ .Values.ports.optimizing }}
      protocol: TCP
    - name: jmx-exporter
      port: {{ .Values.ports.jmxExporter }}
      protocol: TCP
  selector:
    {{- include "udp.amoro.labels" . | nindent 4 }}

● 서비스 계정

{{- if .Values.serviceAccount.create -}}
apiVersion: v1
kind: ServiceAccount
metadata:
  name: {{ .Values.serviceAccount.name }}
  labels:
    {{- include "udp.amoro.labels" . | nindent 4 }}
  annotations:
    eks.amazonaws.com/role-arn: {{ .Values.serviceAccount.iamRoleARN }}
{{- end -}}

● 비밀

우리는 민감한 정보를 관리하고 이를 외부 시스템(예: Vault, Azure Key Vault 등)에 저장하고 이러한 외부 키와 자격 증명을 참조하여 Kubernetes의 Secert 개체에 주입하기 위해 SecertStore와 ExternalSecret을 결합합니다.

● 인그레스

Ingress는 Kubernetes 클러스터 내에서 HTTP 및 HTTPS 라우팅을 관리하고 외부 트래픽을 클러스터 내의 서비스로 라우팅하므로 Ingress를 구성한 후 호스트를 통해 WebUI에 액세스할 수 있습니다.

{{- if .Values.ingress.enabled -}}
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: amoro
  labels:
    {{- include "udp.amoro.labels" . | nindent 4 }}
  {{- with .Values.ingress.annotations }}
  annotations:
    {{- toYaml . | nindent 4 }}
  {{- end }}
spec:
  rules:
    - host: {{ .Values.ingress.host }}
      http:
        paths:
          - path: {{ .Values.ingress.path }}
            pathType: {{ .Values.ingress.pathType }}
            backend:
              service:
                name: ams
                port:
                  number: {{ .Values.ports.amoroServer }}
{{- end }}

● 서브 모니터

AMS 상태를 쉽게 모니터링하기 위해 Docker 이미지에 Prometheus를 구성하고 jmx 내보내기 포트를 노출하여 Amoro Pod와 관련된 메트릭을 수집하고 저장합니다.

apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
  labels:
    app.kubernetes.io/name: amoro-monitor
  name: amoro-monitor
spec:
  namespaceSelector:
    any: true
  podMetricsEndpoints:
    - interval: 60s
      port: jmx-exporter
  selector:
    matchLabels:
      app.kubernetes.io/name: ams

Helm 템플릿을 작성한 후 다음 명령을 통해 설치 및 배포합니다.

-- 安装/升级amoro helm
helm upgrade -install amoro ./ --namespace amoro

RegisterGlue카탈로그

● 웨어하우스는 필수이며 데이터 웨어하우스 루트 디렉터리를 지정합니다.물론 간단한 웨어하우스 주소를 자리 표시자로 사용할 수도 있습니다.

● 프로덕션 환경에서는 메타데이터.json 파일 수정의 원자성을 보장하기 위해 lock-impl 및 lock.table을 구성하는 것이 좋습니다.

● IRSA 인증을 사용하는 AMS의 경우 올바른 인증 정보를 얻으려면 client.credentials-provider 매개변수를 Software.amazon.awssdk.auth.credentials.WebIdentityTokenFileCredentialsProvider로 설정해야 합니다.

04 미래계획

1. 증분 SORT/ZORDER SORT : 데이터 건너뛰기는 Iceberg의 쿼리 효율성을 크게 향상시킬 수 있으며, 특히 상대적으로 고정된 쿼리 조건이 있는 보고서의 경우 더욱 그렇습니다. 또한 보다 효율적인 파일 건너뛰기는 테이블을 읽을 때 파일의 IO를 줄이고 S3에 대한 외부 액세스로 인해 발생하는 트래픽 오버헤드를 줄일 수도 있습니다. 클러스터링의 최적화 방법은 다양한 테이블의 지능적인 최적화도 가능하게 합니다.

2. 모니터링 및 경보 개선 : 현재 모니터링은 시간 초과 경보 최적화/보류/커밋, 포드 상태 모니터링 등과 같은 Amoro의 관련 기록 및 지표를 기반으로 합니다. 이 외에도 테이블 자체의 Health 상태를 모니터링하고 테이블의 읽기/쓰기 증폭을 사전에 예측하는 것도 필요합니다.

3. Kubernetes Optimizer : 프로덕션 환경에서는 Iceberg의 압축 작업을 수행하기 위해 항상 외부 Flink Optimizer를 사용했는데, 이 방법은 옵티마이저의 리소스를 유연하게 조정하는 데 편리하지 않습니다. Pod를 LocalOptimizer만큼 유연하게 관리하면 외부 Optimizer 유지 비용을 어느 정도 줄일 수 있고 JobManger 리소스도 일부 절약할 수 있습니다.

끝~

데이터 레이크, 레이크-웨어하우스 통합, 테이블 형식 또는 Amoro 커뮤니티에 관심이 있으시면 저희에게 연락해 심도 있는 논의를 해보세요.

Amoro에 대한 자세한 내용은 다음에서 확인할 수 있습니다.

공식 홈페이지: https://amoro.netease.com/
소스 코드: https://github.com/NetEase/amoro
WeChat ID : kllnn999를 검색하고 커뮤니티에 가입하려면 WeChat 도우미를 추가하세요.

작성자: Bai Xu, Cisco WebEx 데이터 플랫폼의 소프트웨어 엔지니어, 주로 데이터 레이크 및 웨어하우스 통합의 R&D 및 최적화를 담당하는 Amoro Committer.

편집자: 비리디안