Amoro は、Apache Iceberg などのオープン データ レイク テーブル上に構築されたレイク ウェアハウス管理システムです。NetEase Shufan のビッグ データ チームによってオープンソース化されており、プラグイン可能なデータの自己最適化メカニズムと管理サービスのセットを提供し、ユーザーにデータの持ち出しを提供することを目的としています。 - すぐに使える胡倉体験。この記事は、Cisco WebEx データ プラットフォームのソフトウェア エンジニアである Bai Xu によるもので、Cisco クラウド ネイティブ レイク ウェアハウス シナリオにおける Amoro の実践を共有しています。
01 Webex のアモロ
Cisco Webex 製品は、オンライン会議、チーム メッセージング、ファイル共有などの機能を提供します。このスイートは、ユニファイド コミュニケーション分野における主要なコラボレーション プラットフォームと考えられており、中小企業向けの小グループ コラボレーションと、企業全体に展開する大規模なグループ ミーティングの両方を対象としています。
アモロを選ぶ理由
Webex ビッグ データ チームは当初、Hive ストレージ形式を主要な標準として採用しました。ただし、Hive ストレージ形式の制限により、顧客固有のデータの修正やデータのバックトラッキングの実行は非常に非効率になります。さらに、Hive を使用すると、メンテナンスのオーバーヘッドも増加します。これらの課題を考慮して、私たちは代替のストレージ ソリューションを見つけることに着手しました。このとき、運用と保守のコストを削減するだけでなく、中核的な業務の効率も向上させるように設計された Apache Iceberg を発見しました。したがって、私たちは Apache Iceberg に基づいてデータ レイクの構築に着手しました。昨年以来、Webex は、デフォルトのテーブル形式として Iceberg V2 形式を徐々に使用してきました。V2 の重要な機能の 1 つは行レベルの更新機能ですが、これにより重要な問題が発生します。それは、V2 テーブルを読み取るときにマージ オン リード (MOR) によって引き起こされるパフォーマンスの問題です。多数の削除ファイルが蓄積されると、Iceberg に依存するレポート クエリの適時性が大幅に低下し、使用できなくなる場合もあります。私たちはまず、Spark comapction プロシージャを使用して小さなファイルをマージし、それらをスケジューリング システムを通じて定期的かつ連続的に実行しようとしました。
ただし、この比較的原始的なメンテナンス方法には多くの欠点があります。
● 高いリソース使用量: 各 Spark ジョブは 40 コアと 300 GB のメモリを超える可能性があります
● 長い実行時間: 各環境にはマージが必要な Iceberg テーブルが多数あり、大量のデータを含むテーブルをマージすると他のテーブルがブロックされるため、各 Pocedure の実行時間が長すぎます。
● フォールト トレランスが低い: マージ タスクには複数の Iceberg テーブルが含まれる場合があり、特定のテーブルでエラーが発生すると、ジョブ全体が失敗します。
● メンテナンスの難しさ: マージに失敗したテーブルは手動で再起動して修復する必要があり、場合によっては見逃される可能性もあります。
上記の問題点のため、私たちは Iceberg テーブルの多くのメンテナンス問題を解決するためにすぐに Amoro を導入しました。外部 Flink Optimizer 登録方法を使用して、Amoro Management Service (AMS) によって生成された最適化タスクを取得して処理します。また、スナップショットの有効期限やデータの有効期限などのサービスが有効になり、ストレージ システムへの負担が軽減されます。
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 で解決すべき課題は数多くありますが、1 つはカタログとファイルシステムの切り替えなどの Iceberg AWS との統合、もう 1 つは AMS 側の適応です。
Iceberg AWS 統合
Iceberg を AWS にオンラインにした後、HiveCatalog から GlueCatalog に切り替え、ファイル システムも HDFS から S3 に切り替えました。HDFS と比較して、S3 はより完全な権限制御を備えており、バケットを分割したり、IAM アカウントごとにファイルの異なる権限を分割したりして、きめ細かい権限制御を実現できます。これは、データ レイクにおけるデータのセキュリティとプライバシーを確保するための重要な要素です。第 2 に、HDFS は通常、独自のハードウェアとメンテナンスを管理する必要があるため、初期費用と運用コストがより多くかかる可能性がありますが、S3 は使用量に基づいたコスト モデルを備えたクラウド サービスであり、ハードウェアのメンテナンス費用はかかりません。Hive Metastore はサービスとして、異なる環境に個別にデプロイする必要があり、メタデータ情報を保存するために MySQL を保守する必要があるため、Glue に比べて保守コストが増加します。例えば、実際の本番環境では、MySQLの接続数が上限に達したためにHMSの再起動ができない状況が発生しました。Glue は HMS よりもシンプルで、手動によるメンテナンスが不要で、複数の環境を個別に展開することによって引き起こされるデータアイランドの問題を軽減します。
ロックマネージャー
Iceberg の場合、S3 などの一部のファイル システムでは、メタデータのアトミック性を確保するためのファイル書き込み除外が提供されていません。HMS は排他ロックを MySQL に依存していますが、Glue ではカスタム ロックの実装が必要です。AWS では、Iceberg はテーブルの同時実行性を確保するために DynamoDBLockManager を提供しています。
1. Iceberg は新しいmetadata.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 |
●entityId は DynamoDB テーブルのキーであり、Iceberg データベース名とテーブル名で構成されます。
● リース期間はロックのハートビートタイムアウトとなり、ロックがタイムアウトすると自動的に解放されます。
● version は、ロックが現在のスレッドによって保持されるようにするために、DynomoDBHeartbeat によってランダムに更新される UUID の文字列です。
● ownerId は、書き込まれる新しいmetadata.jsonファイルです。
DynamoDB を使用して Iceberg テーブルへの同時変更を管理すると、Hive メタストア サービスで解放されていないロックによって引き起こされるジョブ ブロックを回避できます。これは、DynamoDB では、ロックを保持しているプロセスが異常終了した場合、手動でロックを解除しなくても、リース期限が切れた後にそのロックが自動的に解放されるためです。 . .
権限制御
AWS IAM アカウントは、S3、Glue、DynamoDB、およびその他の関連サービスに対して、きめ細かいアクセス許可制御を提供できます。現在、各チームに IAM アカウントを割り当てており、IAM アカウントは関連する S3 バケットへの読み取りおよび書き込み権限を付与し、Glue 権限を管理することもできます。AMS サービスと読み取りおよび書き込みジョブはすべて Kubernetes 上で実行されるため、IAM アカウントを割り当て、全員の関連する名前空間のアクセス許可を管理するためのユニットとして自然に Namespace を使用し、後で説明する Iceberg テーブルのアクセス許可制御を簡単に実装できます。 S3 と Glue の権限をより詳細に分割します。
S3 インテリジェント階層化
Iceberg への S3 の読み取りおよび書き込みのコストを調査する過程で、Webex チームは AWS S3 に非常に価値のある属性があることを発見しましたが、それはまだ Iceberg に適応されていません: storage-class。この構成を S3 Intelligent-Tiering に設定すると、さまざまなアクセス頻度に基づいてアクセス コストを最適化できます。
Amazon S3 Intelligent-Tiering ストレージ クラスは、アクセス パターンが変化したときにデータを最もコスト効率の高いアクセス層に自動的に移動することで、ストレージ コストを最適化するように設計されています。S3 Intelligent-Tiering ストレージ クラスは、オブジェクトを 3 つのアクセス層に自動的に保存します。1 つは頻繁なアクセスに最適化された層、1 つは低頻度のアクセスに最適化された低コスト層、そして 1 つはほとんどアクセスされないデータ用に最適化された非常に低コストの層です。S3 Intelligent-Tiering では、オブジェクトの監視と自動化に少額の月額料金を支払うだけで、連続 30 日間アクセスされなかったオブジェクトを低頻度アクセス層に移動し、90 日間非アクティブになった後に移動することで、40% の節約を実現できます。インスタント アクセス層をアーカイブし、68% の節約を実現します。
この変更は Iceberg コミュニティに提供され、1.4.0 https://github.com/apache/iceberg/releases/tag/apache-iceberg-1.4.0でリリースされました。
AMS AWS への適応
AWS 環境で実行するために、初期の AMS はカスタム カタログを通じて Iceberg の GlueCatalog を作成および適応させ、オブジェクト ファイル システムをサポートするために Arctic の FileIO 関連インターフェイスを再構築しました。バージョン 0.6.0 では、GlueCatalog を別のカタログ タイプとして使用し、IAM やその他の関連属性の入力を要求するなど、AWS 環境によりよく適応することが予想されます。
AMS と Optimizer の両方が Iceberg とそのファイルにアクセスする必要があります。直接的な方法は、必要なマージ テーブルの読み取りおよび書き込み権限にアクセスできる IAM アカウントを上記のコンポーネントに与えることです。IAM 関連の認証を環境変数に入れます。デフォルトDefaultAWSCredentialsProviderChain を取得すると、関連する認証情報が正しく取得され、認証が完了します。たとえば、k8s 環境の環境変数にそれを入れるだけです。
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 年にサービス アカウント用 IAM ロール (IRSA) を導入しました。これは、AWS Identity API、OpenID Connect (OIDC)、および Kubernetes サービス アカウントを使用して、Kubernetes ポッドにきめ細かいアクセス制御を適用します。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 を例として、Amoro を Kubernetes 環境にデプロイし、Helm チャートをテンプレートとして使用して 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 イメージは、次のデプロイメント リソースで参照およびデプロイされます。
ヘルム チャートを作成する
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 -}}● シークレット
SecertStore と ExternalSecret を組み合わせて機密情報を管理し、それを外部システム (Vault、Azure Key Vault など) に保存し、これらの外部キーと資格情報を参照して Kubernetes の Secert オブジェクトに注入します。
● イングレス
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 を構成し、Amoro Pod に関連するメトリクスを収集および保存するために jmx エクスポータ ポートを公開します。
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: amsHelm テンプレートを作成した後、次のコマンドを使用してインストールしてデプロイします。
-- 安装/升级amoro helm
helm upgrade -install amoro ./ --namespace amoroグルーカタログの登録
● ウェアハウスは必須であり、データ ウェアハウスのルート ディレクトリを指定します もちろん、単純なウェアハウス アドレスをプレースホルダとして使用することもできます。
● 運用環境では、metadata.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 の関連する記録とインジケーターに基づいて行われます。これらに加えて、テーブル自体の健全性状態を監視し、テーブルの読み取り/書き込みの増加を事前に予測することも必要です。
3. Kubernetes オプティマイザー: 運用環境では、常に外部 Flink オプティマイザーを使用して Iceberg の圧縮タスクを実行していますが、この方法はオプティマイザーのリソースを柔軟に調整するには不便です。LocalOptimizer と同じくらい柔軟に Pod を管理すると、外部オプティマイザーの維持コストをある程度削減でき、JobManger リソースも節約できます。
終わり〜
データレイク、レイクとウェアハウスの統合、テーブル形式、または Amoro コミュニティにご興味がある場合は、詳細なディスカッションのためにお問い合わせください。
アモロの詳細については、次のサイトを参照してください。
- 公式サイト： https: //amoro.netease.com/
- ソースコード: https://github.com/NetEase/amoro
- WeChat ID : kllnn999 を検索し、アシスタント WeChat を追加してコミュニティに参加します
著者: Bai Xu、Cisco WebEx データ プラットフォームのソフトウェア エンジニア、主にデータ レイクとウェアハウス統合の研究開発と最適化を担当する Amoro コミッター。
編集者: ビリジアン