You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@doris.apache.org by mo...@apache.org on 2026/10/15 07:35:25 UTC
(doris-website) branch master updated: docs(i18n): translate 100 Japanese pages for T09-4X-082 (#4304)
This is an automated email from the ASF dual-hosted git repository.
morningman pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/doris-website.git
The following commit(s) were added to refs/heads/master by this push:
new 8b2246dc8b2 docs(i18n): translate 100 Japanese pages for T09-4X-082 (#4304)
8b2246dc8b2 is described below
commit 8b2246dc8b28ee330e90ddab838ea164d7ef8325
Author: Mingyu Chen (Rayner) <mo...@gmail.com>
AuthorDate: Thu Oct 15 15:35:17 2026 +0800
docs(i18n): translate 100 Japanese pages for T09-4X-082 (#4304)
## Summary
Translate 100 Japanese pages for `T09-4X-082` from merged master
`618b88463542c388ef5d477f53e4f17162fd5eb7`. 81 pages reused a validated
same-source translation from the other version; 19 required new Japanese
work. All pages have machine-reviewed state records.
## Pages
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/getting-started/intro.mdx`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/getting-started/quick-start.mdx`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/getting-started/before-you-start-the-poc.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/features-architecture/intro.mdx`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/features-architecture/system-architecture.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/features-architecture/product-concepts.md`
- `i18n/ja/docusaurus-plugin-content-docs/version-4.x/install/intro.mdx`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/install/choosing-deployment-mode.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/install/preparation/env-checking.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/install/preparation/cluster-planning.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/install/preparation/os-checking.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/install/deploy-manually/intro.mdx`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/install/deploy-manually/integrated-storage-compute-deploy-manually.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/install/deploy-manually/separating-storage-compute-deploy-manually.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/install/deploy-on-kubernetes/intro.mdx`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/install/deploy-on-kubernetes/doris-operator/intro.mdx`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/install/deploy-on-kubernetes/doris-operator/doris-operator-overview.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/install/deploy-on-kubernetes/doris-operator/architecture.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/install/deploy-on-kubernetes/doris-operator/resource-model.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/install/deploy-on-kubernetes/doris-operator/lifecycle.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/install/deploy-on-kubernetes/doris-operator/status-and-troubleshooting.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/install/deploy-on-kubernetes/doris-operator/preparation.mdx`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/install/deploy-on-kubernetes/doris-operator/on-alibaba.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/install/deploy-on-kubernetes/doris-operator/on-aws.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/install/deploy-on-kubernetes/integrated-storage-compute/intro.mdx`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/install/deploy-on-kubernetes/integrated-storage-compute/install-doris-operator.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/install/deploy-on-kubernetes/integrated-storage-compute/install-config-cluster.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/install/deploy-on-kubernetes/integrated-storage-compute/install-doris-cluster.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/install/deploy-on-kubernetes/integrated-storage-compute/access-cluster.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/install/deploy-on-kubernetes/integrated-storage-compute/cluster-operation.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/install/deploy-on-kubernetes/separating-storage-compute/install-doris-cluster.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/install/deploy-on-kubernetes/separating-storage-compute/install-fdb.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/install/deploy-on-kubernetes/separating-storage-compute/config-ms.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/install/deploy-on-kubernetes/separating-storage-compute/config-fe.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/install/deploy-on-kubernetes/separating-storage-compute/config-cg.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/install/deploy-on-kubernetes/separating-storage-compute/config-cluster.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/install/deploy-on-kubernetes/separating-storage-compute/install-prometheus-and-grafana.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/install/deploy-on-cloud/doris-on-aws.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/compute-storage-decoupled/intro.mdx`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/compute-storage-decoupled/managing-compute-cluster.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/compute-storage-decoupled/managing-storage-vault.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/compute-storage-decoupled/recycler.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/compute-storage-decoupled/upgrade.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/compute-storage-decoupled/file-cache/file-cache.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/compute-storage-decoupled/file-cache/file-cache-internals.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/compute-storage-decoupled/file-cache/file-cache-peer-read.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/compute-storage-decoupled/rw/read-write-separation.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/compute-storage-decoupled/rw/file-cache-rw-compute-group-best-practice.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/mysql-proto.mdx`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/arrow-flight-sql.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/intro.mdx`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/automq.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/beats.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/cloudcanal.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/clouddm.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/datagrip.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/datax.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/dbeaver.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/dbt-doris-adapter.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/doris-kafka-connector.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/doris-streamloader.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/finebi.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/flink-doris-connector.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/fluentbit.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/hive-udf.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/kettle.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/kyuubi.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/langfuse.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/logstash.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/loongcollector.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/metabase.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/opentelemetry.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/powerbi.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/quickbi.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/quicksight.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/seatunnel.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/smartbi.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/spark-doris-connector.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/superset.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/tableau.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/vector.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/table-design/overview.mdx`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/table-design/data-model/intro.mdx`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/table-design/data-model/duplicate.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/table-design/data-model/unique.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/table-design/data-model/merge-on-write.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/table-design/data-model/aggregate.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/table-design/data-model/tips.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/table-design/data-type.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/table-design/data-partitioning/basic-concepts.mdx`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/table-design/data-partitioning/manual-partitioning.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/table-design/data-partitioning/dynamic-partitioning.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/table-design/data-partitioning/auto-partitioning.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/table-design/data-partitioning/data-bucketing.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/table-design/data-partitioning/common-issues.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/table-design/index/index-overview.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/table-design/index/prefix-index.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/table-design/index/bloomfilter.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/table-design/index/ngram-bloomfilter-index.md`
-
`i18n/ja/docusaurus-plugin-content-docs/version-4.x/table-design/index/inverted-index/overview.md`
## Validation
- Bundled protected-structure and state validator: 100/100 passed.
- `git diff --check`: 0 source-inherited trailing-space notices; EOF
blank-line notices ignored.
- Only the listed Japanese targets and their independent page-state
files changed.
- No local site build was run for this translation-only batch; PR CI
checks the build.
Passing pages use `reviewStatus=machine`; failed pages use
`reviewStatus=unverified`. All pages use `ownership=machine`; no human
Japanese proofreading is claimed.
Co-authored-by: morningman <mo...@apache.org>
---
.../file-cache/file-cache-internals.md | 238 ++++
.../file-cache/file-cache-peer-read.md | 347 ++++++
.../file-cache/file-cache.md | 615 +++++++++++
.../compute-storage-decoupled/intro.mdx | 77 ++
.../managing-compute-cluster.md | 319 ++++++
.../managing-storage-vault.md | 299 ++++++
.../compute-storage-decoupled/recycler.md | 286 +++++
.../file-cache-rw-compute-group-best-practice.md | 222 ++++
.../rw/read-write-separation.md | 621 +++++++++++
.../compute-storage-decoupled/upgrade.md | 279 +++++
.../connection-integration/arrow-flight-sql.md | 778 ++++++++++++++
.../data-integration/automq.md | 174 +++
.../data-integration/beats.md | 369 +++++++
.../data-integration/cloudcanal.md | 64 ++
.../data-integration/clouddm.md | 85 ++
.../data-integration/datagrip.md | 87 ++
.../data-integration/datax.md | 316 ++++++
.../data-integration/dbeaver.md | 271 +++++
.../data-integration/dbt-doris-adapter.md | 754 +++++++++++++
.../data-integration/doris-kafka-connector.md | 684 ++++++++++++
.../data-integration/doris-streamloader.md | 297 +++++
.../data-integration/finebi.md | 106 ++
.../data-integration/flink-doris-connector.md | 1136 ++++++++++++++++++++
.../data-integration/fluentbit.md | 406 +++++++
.../data-integration/hive-udf.md | 352 ++++++
.../data-integration/intro.mdx | 254 +++++
.../data-integration/kettle.md | 122 +++
.../data-integration/kyuubi.md | 119 ++
.../data-integration/langfuse.md | 354 ++++++
.../data-integration/logstash.md | 484 +++++++++
.../data-integration/loongcollector.md | 388 +++++++
.../data-integration/metabase.md | 379 +++++++
.../data-integration/opentelemetry.md | 416 +++++++
.../data-integration/powerbi.md | 240 +++++
.../data-integration/quickbi.md | 84 ++
.../data-integration/quicksight.md | 188 ++++
.../data-integration/seatunnel.md | 216 ++++
.../data-integration/smartbi.md | 89 ++
.../data-integration/spark-doris-connector.md | 655 +++++++++++
.../data-integration/superset.md | 173 +++
.../data-integration/tableau.md | 161 +++
.../data-integration/vector.md | 537 +++++++++
.../connection-integration/mysql-proto.mdx | 171 +++
.../version-4.x/features-architecture/intro.mdx | 45 +
.../features-architecture/product-concepts.md | 346 ++++++
.../features-architecture/system-architecture.md | 274 +++++
.../getting-started/before-you-start-the-poc.md | 343 ++++++
.../version-4.x/getting-started/intro.mdx | 95 ++
.../version-4.x/getting-started/quick-start.mdx | 269 +++++
.../install/choosing-deployment-mode.md | 103 ++
.../integrated-storage-compute-deploy-manually.md | 388 +++++++
.../version-4.x/install/deploy-manually/intro.mdx | 27 +
.../separating-storage-compute-deploy-manually.md | 475 ++++++++
.../install/deploy-on-cloud/doris-on-aws.md | 125 +++
.../doris-operator/architecture.md | 70 ++
.../doris-operator/doris-operator-overview.md | 107 ++
.../deploy-on-kubernetes/doris-operator/intro.mdx | 43 +
.../doris-operator/lifecycle.md | 149 +++
.../doris-operator/on-alibaba.md | 199 ++++
.../deploy-on-kubernetes/doris-operator/on-aws.md | 162 +++
.../doris-operator/preparation.mdx | 47 +
.../doris-operator/resource-model.md | 148 +++
.../doris-operator/status-and-troubleshooting.md | 230 ++++
.../integrated-storage-compute/access-cluster.md | 141 +++
.../cluster-operation.md | 440 ++++++++
.../install-config-cluster.md | 1028 ++++++++++++++++++
.../install-doris-cluster.md | 55 +
.../install-doris-operator.md | 53 +
.../integrated-storage-compute/intro.mdx | 37 +
.../install/deploy-on-kubernetes/intro.mdx | 33 +
.../separating-storage-compute/config-cg.md | 313 ++++++
.../separating-storage-compute/config-cluster.md | 398 +++++++
.../separating-storage-compute/config-fe.md | 405 +++++++
.../separating-storage-compute/config-ms.md | 207 ++++
.../install-doris-cluster.md | 348 ++++++
.../separating-storage-compute/install-fdb.md | 167 +++
.../install-prometheus-and-grafana.md | 243 +++++
.../version-4.x/install/intro.mdx | 51 +
.../install/preparation/cluster-planning.md | 60 ++
.../install/preparation/env-checking.md | 115 ++
.../version-4.x/install/preparation/os-checking.md | 145 +++
.../table-design/data-model/aggregate.md | 187 ++++
.../table-design/data-model/duplicate.md | 87 ++
.../version-4.x/table-design/data-model/intro.mdx | 134 +++
.../table-design/data-model/merge-on-write.md | 99 ++
.../version-4.x/table-design/data-model/tips.md | 201 ++++
.../version-4.x/table-design/data-model/unique.md | 93 ++
.../data-partitioning/auto-partitioning.md | 345 ++++++
.../data-partitioning/basic-concepts.mdx | 444 ++++++++
.../data-partitioning/common-issues.md | 100 ++
.../data-partitioning/data-bucketing.md | 283 +++++
.../data-partitioning/dynamic-partitioning.md | 229 ++++
.../data-partitioning/manual-partitioning.md | 256 +++++
.../version-4.x/table-design/data-type.md | 65 ++
.../version-4.x/table-design/index/bloomfilter.md | 135 +++
.../table-design/index/index-overview.md | 141 +++
.../table-design/index/inverted-index/overview.md | 246 +++++
.../table-design/index/ngram-bloomfilter-index.md | 303 ++++++
.../version-4.x/table-design/index/prefix-index.md | 151 +++
.../version-4.x/table-design/overview.mdx | 257 +++++
.../file-cache/file-cache-internals.json | 20 +
.../file-cache/file-cache-peer-read.json | 20 +
.../file-cache/file-cache.json | 20 +
.../4.x/compute-storage-decoupled/intro.json | 20 +
.../managing-compute-cluster.json | 20 +
.../managing-storage-vault.json | 20 +
.../4.x/compute-storage-decoupled/recycler.json | 20 +
.../file-cache-rw-compute-group-best-practice.json | 20 +
.../rw/read-write-separation.json | 20 +
.../4.x/compute-storage-decoupled/upgrade.json | 20 +
.../connection-integration/arrow-flight-sql.json | 20 +
.../data-integration/automq.json | 20 +
.../data-integration/beats.json | 20 +
.../data-integration/cloudcanal.json | 20 +
.../data-integration/clouddm.json | 20 +
.../data-integration/datagrip.json | 20 +
.../data-integration/datax.json | 20 +
.../data-integration/dbeaver.json | 20 +
.../data-integration/dbt-doris-adapter.json | 20 +
.../data-integration/doris-kafka-connector.json | 20 +
.../data-integration/doris-streamloader.json | 20 +
.../data-integration/finebi.json | 20 +
.../data-integration/flink-doris-connector.json | 20 +
.../data-integration/fluentbit.json | 20 +
.../data-integration/hive-udf.json | 20 +
.../data-integration/intro.json | 20 +
.../data-integration/kettle.json | 20 +
.../data-integration/kyuubi.json | 20 +
.../data-integration/langfuse.json | 20 +
.../data-integration/logstash.json | 20 +
.../data-integration/loongcollector.json | 20 +
.../data-integration/metabase.json | 20 +
.../data-integration/opentelemetry.json | 20 +
.../data-integration/powerbi.json | 20 +
.../data-integration/quickbi.json | 20 +
.../data-integration/quicksight.json | 20 +
.../data-integration/seatunnel.json | 20 +
.../data-integration/smartbi.json | 20 +
.../data-integration/spark-doris-connector.json | 20 +
.../data-integration/superset.json | 20 +
.../data-integration/tableau.json | 20 +
.../data-integration/vector.json | 20 +
.../4.x/connection-integration/mysql-proto.json | 20 +
.../default/4.x/features-architecture/intro.json | 20 +
.../features-architecture/product-concepts.json | 20 +
.../features-architecture/system-architecture.json | 20 +
.../getting-started/before-you-start-the-poc.json | 20 +
.../pages/default/4.x/getting-started/intro.json | 20 +
.../default/4.x/getting-started/quick-start.json | 20 +
.../4.x/install/choosing-deployment-mode.json | 20 +
...integrated-storage-compute-deploy-manually.json | 20 +
.../default/4.x/install/deploy-manually/intro.json | 20 +
...separating-storage-compute-deploy-manually.json | 20 +
.../4.x/install/deploy-on-cloud/doris-on-aws.json | 20 +
.../doris-operator/architecture.json | 20 +
.../doris-operator/doris-operator-overview.json | 20 +
.../deploy-on-kubernetes/doris-operator/intro.json | 20 +
.../doris-operator/lifecycle.json | 20 +
.../doris-operator/on-alibaba.json | 20 +
.../doris-operator/on-aws.json | 20 +
.../doris-operator/preparation.json | 20 +
.../doris-operator/resource-model.json | 20 +
.../doris-operator/status-and-troubleshooting.json | 20 +
.../integrated-storage-compute/access-cluster.json | 20 +
.../cluster-operation.json | 20 +
.../install-config-cluster.json | 20 +
.../install-doris-cluster.json | 20 +
.../install-doris-operator.json | 20 +
.../integrated-storage-compute/intro.json | 20 +
.../4.x/install/deploy-on-kubernetes/intro.json | 20 +
.../separating-storage-compute/config-cg.json | 20 +
.../separating-storage-compute/config-cluster.json | 20 +
.../separating-storage-compute/config-fe.json | 20 +
.../separating-storage-compute/config-ms.json | 20 +
.../install-doris-cluster.json | 20 +
.../separating-storage-compute/install-fdb.json | 20 +
.../install-prometheus-and-grafana.json | 20 +
.../state/ja/pages/default/4.x/install/intro.json | 20 +
.../4.x/install/preparation/cluster-planning.json | 20 +
.../4.x/install/preparation/env-checking.json | 20 +
.../4.x/install/preparation/os-checking.json | 20 +
.../4.x/table-design/data-model/aggregate.json | 20 +
.../4.x/table-design/data-model/duplicate.json | 20 +
.../default/4.x/table-design/data-model/intro.json | 20 +
.../table-design/data-model/merge-on-write.json | 20 +
.../default/4.x/table-design/data-model/tips.json | 20 +
.../4.x/table-design/data-model/unique.json | 20 +
.../data-partitioning/auto-partitioning.json | 20 +
.../data-partitioning/basic-concepts.json | 20 +
.../data-partitioning/common-issues.json | 20 +
.../data-partitioning/data-bucketing.json | 20 +
.../data-partitioning/dynamic-partitioning.json | 20 +
.../data-partitioning/manual-partitioning.json | 20 +
.../pages/default/4.x/table-design/data-type.json | 20 +
.../4.x/table-design/index/bloomfilter.json | 20 +
.../4.x/table-design/index/index-overview.json | 20 +
.../index/inverted-index/overview.json | 20 +
.../index/ngram-bloomfilter-index.json | 20 +
.../4.x/table-design/index/prefix-index.json | 20 +
.../pages/default/4.x/table-design/overview.json | 20 +
200 files changed, 27852 insertions(+)
diff --git a/i18n/ja/docusaurus-plugin-content-docs/version-4.x/compute-storage-decoupled/file-cache/file-cache-internals.md b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/compute-storage-decoupled/file-cache/file-cache-internals.md
new file mode 100644
index 00000000000..dae2b05a10b
--- /dev/null
+++ b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/compute-storage-decoupled/file-cache/file-cache-internals.md
@@ -0,0 +1,238 @@
+---
+{
+ "title": "ファイルキャッシュの内部動作：キャッシュの分割、複数キューの管理、エビクション、ウォームアップ",
+ "sidebar_label": "ファイルキャッシュの内部動作",
+ "language": "ja",
+ "description": "Doris のファイルキャッシュにおける分割、複数キューの管理、LRU エビクションポリシー、ウォームアップの仕組みを詳しく説明します。キャッシュヒット率の最適化とスケーリングのベストプラクティスを理解するための資料です。",
+ "keywords": ["Doris ファイルキャッシュ", "キャッシュの分割", "複数キュー LRU", "キャッシュのウォームアップ", "コンピュートとストレージの分離", "キャッシュのエビクション", "キャッシュヒット率"]
+}
+---
+
+<!-- Knowledge type: Architecture principle -->
+<!-- When to use: Performance tuning / Troubleshooting / Scaling planning -->
+
+## 基本原理
+
+<!-- Knowledge type: Operations -->
+
+### キャッシュの分割とプリフェッチの仕組み
+
+Doris は対象ファイルを **1 MB** 境界に揃えたスライスに分割します。各スライスはダウンロードが完了すると、独立したブロックファイルとしてローカルファイルシステムに保存されます。この細かい分割により、大きなファイル全体をキャッシュすることによる容量の浪費を避け、頻繁にアクセスされるデータのヒット状況の追跡とエビクションをより正確に行えます。
+
+### ローカルファイルのディレクトリ構成
+
+<!-- Knowledge type: Configuration reference -->
+
+キャッシュデータは、複数のディスク上にある複数のディレクトリに分散できます。Doris は対象ファイルのパスのハッシュを計算し、そのハッシュをブロックファイルのパスの最下層ディレクトリ名として使用します。そのディレクトリ内では、各ブロックファイルに対象ファイル内の **offset** を名前として付け、データを複数のディレクトリに均等に分散します。
+
+**例：** 対象ファイルのパスが `/remote/data/datafile1` で、計算されたハッシュが `12345` の場合、対応するブロックファイルのパスは次のとおりです。
+
+```
+/cache/123/12345/<offset>
+```
+
+ここで `<offset>` は、元のファイル内におけるそのブロックのデータのオフセットです。
+
+### 複数キューの仕組み
+
+<!-- Knowledge type: Configuration reference -->
+
+Doris は、キャッシュの汚染を防ぎヒット率を高めるために、キャッシュデータを種類ごとに異なるキューへ振り分けます。以下に、優先度の高い順にキューを示します。
+
+| キュー | 内容 | 優先度 | 備考 |
+|-------|------|--------|------|
+| TTL キュー | TTL 属性が設定されたデータ | 最高 | TTL が期限切れになるまではエビクションされません。TTL はテーブルレベルの属性です。たとえば 3600 に設定すると、データは取り込み後最大 1 時間キャッシュに保持されます。ローカルに保持する必要がある、小さく頻繁にアクセスされるテーブルに適しています。 |
+| Index キュー | インデックスデータ（転置インデックスを除く） | 高 | クエリのフィルタリングを高速化するために使用します。転置インデックスはサイズが大きいため、Normal キューに配置されます。 |
+| Normal キュー | 通常のデータ（TTL 属性なし） | 中 | 大半のデータが格納されるキューです。 |
+| Disposable キュー | 一時データ（Compaction 中に読み取られるデータなど） | 最低 | 使用後、最初にエビクションされます。 |
+
+### エビクションの仕組み
+
+<!-- Knowledge type: Operations -->
+<!-- When to use: Troubleshooting / Performance tuning -->
+
+#### エビクションが発生する条件
+
+| トリガー | 説明 |
+|----------|------|
+| 空き容量不足による受動的なエビクション | ローカルディスクの空き容量または inode がなくなった場合や、キャッシュ使用量が設定された容量上限に達した場合に発生します。 |
+| 高ウォーターマークでの能動的なエビクション | キャッシュ使用量が高ウォーターマークに達すると、Doris は古いキャッシュエントリを事前に非同期で削除し、同期エビクションによって書き込みがブロックされるのを防ぎます。 |
+| ガベージコレクションによるエビクション | Compaction と Schema Change の元データ、インポートのコミット失敗後にロールバックされたデータ、`DROP TABLE` または `DROP PARTITION` 操作による残存データを能動的に削除します。 |
+| TTL 期限切れによる降格 | TTL エントリが期限切れになると Normal キューへ移され、通常の LRU エビクションの対象になります。 |
+
+#### エビクション対象の選択方法
+
+**容量配分比率：** 複数のキューでディスク容量を共有し、各キューには使用できる容量の割合について独立した上限があります（たとえば、Normal キューの上限は総容量の 40%）。ほかのキューが割り当て分を使い切っていない場合、あるキューは残りの容量をすべて使用できます。各種類のデータが増えるにつれて、使用割合は設定値に徐々に近づきます。
+
+**エビクションの順序：** キューに書き込み用の十分な空き容量がない場合、Doris は次の順序で配分比率を超えたデータをエビクションします（各キュー内では、LRU によって先にエビクションするエントリを決定します）。
+
+```
+Disposable → Normal → Index → TTL
+```
+
+ほかのキューからエビクションしても容量が不足する場合は、対象キュー自身のエントリを LRU に従ってエビクションします。
+
+#### 頻繁にアクセスされるデータのエビクションを避けるための推奨事項
+
+- **十分なディスク容量を確保する：** キャッシュのクリーンアップには多少の遅延があるため、常に余裕を持たせてください。経験上、ファイルキャッシュの容量を頻繁にクエリされるデータ量の約 **1.5 倍** に設定すると、高いヒット率が得られます。
+- **大規模なクエリを分離する：** 大規模なクエリを専用クラスターに振り分け、キャッシュを占有してほかのクエリのヒット率を下げることを防ぎます。
+
+### ウォームアップの仕組み
+
+<!-- Knowledge type: Operations -->
+<!-- When to use: Pre-deployment check / Performance tuning -->
+
+キャッシュのウォームアップは、後続のクエリがローカルキャッシュに直接ヒットして性能が向上するよう、データを事前にキャッシュへ読み込みます。Doris には次の三つのウォームアップ方法があります。
+
+#### 手動ウォームアップ
+
+指定したテーブルまたはパーティションのウォームアップを開始できます。また、別のクラスターのキャッシュ内容を参照して開始することもできます。データの取得元は常にリモートストレージであり、ほかの BE ノードではありません。クエリ処理中にほかの BE のキャッシュから読み取る機能は、別途 [ピアキャッシュ読み取り](./file-cache-peer-read) によって提供されます。ウォームアップの流れは次のとおりです。
+
+1. ウォームアップコマンドを実行します。システムは対象を一連のタブレットに変換し、対応する BE に振り分けます。
+2. 各 BE は担当するタブレットのすべてのデータファイルを順次読み取り、ローカルファイルキャッシュへ書き込みます。
+3. タスクは最大 **20 GB** のバッチに分けて実行されます。各バッチの完了後にチェックポイントが保存されるため、中断後に再開できます。
+4. BE が停止した場合、またはジョブを手動でキャンセルした場合、すべての BE がダウンロードを停止し、ウォームアップが終了します。
+
+タスクの状態（`FINISHED` / `CANCELLED` / `RUNNING`）と全体の進捗は、`SHOW WARM UP JOB` で確認できます。同じテーブルとパーティションを再びウォームアップすると、Doris は既存のデータを自動的に検出し、キャッシュ済みデータを再ダウンロードせずに **増分更新** を行います。
+
+#### データのリバランスを契機とするウォームアップ
+
+負荷のリバランス（スケーリングやノード障害によるもの）でタブレットが新しい BE に移行すると、新しい BE は古い BE に RPC を送信してキャッシュのメタデータを取得し、そのメタデータに基づいてデータをローカルファイルキャッシュに再ダウンロードします。古いノードのキャッシュデータは、タブレット情報がクリーンアップされる際に能動的にエビクションされ、容量が解放されます。
+
+> **注：** 移行が完了してからキャッシュのダウンロードが完了するまでの間は、ファイルキャッシュミスが発生する場合があります。デフォルトで有効な [ピアキャッシュ読み取り](./file-cache-peer-read) を使うと、この間、新しい BE はリモートストレージへ戻らずに、欠けているブロックを移行元 BE のキャッシュから直接取得できます。
+
+#### コンピュートクラスター間の自動ウォームアップ（バージョン 3.1+）
+
+<!-- Knowledge type: Architecture principle -->
+
+コンピュートとストレージを分離したデプロイメントでは、複数のコンピュートクラスター間でファイルキャッシュを自動的に同期できます。Doris は二つの同期方法を提供します。
+
+| 方法 | 使用する場面 | 説明 |
+|------|--------------|------|
+| 定期的なウォームアップ | リアルタイムのデータ鮮度が重要ではない場合 | `WARM UP` SQL ステートメントで同期間隔を指定します。ジョブは、指定したテーブルとパーティションの増分データを対象クラスターへ定期的に同期します。 |
+| 取り込みまたは Compaction を契機とするウォームアップ | リアルタイムのデータ鮮度が必要な場合 | 取り込みジョブがコミット段階に入ると、ソースクラスターの BE が対象クラスターの対応する BE に通知し、新たにアップロードされたデータをダウンロードさせます。Compaction の完了時にも同様の通知が行われます。FE は対象クラスターのタブレット配置情報を管理します。 |
+
+---
+
+## シナリオ別の動作
+
+<!-- Knowledge type: Operations -->
+
+### クエリ時
+
+<!-- When to use: Performance tuning / Troubleshooting -->
+
+クエリ時のファイルキャッシュ処理の流れは次のとおりです。
+
+1. **Scanner の読み取り要求：** クエリを受け取ると、Scanner コンポーネントが必要なデータファイルの読み取りを準備します。
+2. **ローカルキャッシュの確認：** Scanner はまずローカルファイルキャッシュを調べ、ファイルパスとオフセットでキャッシュのメタデータを照合します。
+3. **キャッシュヒット：** 一致するキャッシュデータが見つかると、システムは BlockFile ハンドルの集合を返し、Scanner はリモートストレージにアクセスせずにローカルでデータを読み取ります。
+4. **キャッシュミス：** キャッシュにない範囲については、Scanner がリモートストレージからデータをダウンロードし、ファイルキャッシュに書き込んでから返します。容量はエビクションポリシーに従って解放されます。[ピアキャッシュ読み取り](./file-cache-peer-read) が有効な場合（デフォルト）、Scanner はまずほかの BE のファイルキャッシュを試し、どの BE にもデータがない場合にのみリモートストレージからダウンロードします。
+
+### データ取り込み時
+
+<!-- When to use: Performance tuning -->
+
+データ取り込み時のファイルキャッシュ処理の流れは次のとおりです。
+
+1. **リモートストレージへのアップロード：** 取り込んだデータは最初にリモートストレージへ書き込まれます。
+2. **ローカルキャッシュへの非同期書き込み：** Doris は同時にデータをローカルファイルキャッシュへ非同期で書き込みます。そのため、取り込み直後のクエリはキャッシュに直接ヒットできます。
+3. **キャッシュキューへの割り当て：** データの種類と TTL 属性に基づき、対応するキュー（TTL キュー、Index キュー、Normal キュー）へデータを書き込みます。
+
+### Compaction 時
+
+<!-- When to use: Performance tuning -->
+
+Doris には二種類の Compaction があります。
+
+- **Cumulative Compaction：** 増分データのセグメントをマージします。
+- **Base Compaction：** ベースとなるデータバージョン（バージョン 0 から始まるもの）と増分データのバージョンをマージします。
+
+二種類の Compaction では、異なるキャッシュ書き込み方法を使用します。
+
+| Compaction の種類 | キャッシュへの書き込み方法 |
+|-------------------|----------------------------|
+| Cumulative Compaction | 後続のクエリを高速化するために、取り込み時と同様に、出力データをリモートストレージへアップロードすると同時にファイルキャッシュにも書き込みます。 |
+| Base Compaction | デフォルトでは、大量のコールドデータによるキャッシュ汚染を避けるため、十分なキャッシュ容量がある場合にのみデータをキャッシュへ書き込みます。BE パラメーター `enable_file_cache_keep_base_compaction_output = true` を設定すると書き込みを強制できますが、ほかの頻繁にアクセスされるデータがエビクションされる可能性があります。 |
+
+ローカルキャッシュの容量が限られている場合は、インデックスのみを書き込むポリシーを有効にし、Compaction の出力に含まれる Segment データが大量のキャッシュ容量を能動的に消費するのを防げます。
+
+- `enable_file_cache_write_index_file_only=true`：Compaction を含む、コンピュートとストレージを分離したモードのすべての rowset 書き込みに適用されます。Segment データは能動的にキャッシュされませんが、Segment のフッターと内部インデックスの範囲、および独立した転置インデックスファイルは引き続きキャッシュへ書き込まれます。
+- `enable_file_cache_write_base_compaction_index_only=true` または `enable_file_cache_write_cumu_compaction_index_only=true`：本来キャッシュへ書き込まれる、対応する Compaction の出力だけを制限します。Segment ファイルはスキップし、独立した転置インデックスファイルは保持しますが、Segment のフッターと内部インデックスの範囲は事前に読み込まれません。
+
+パラメーターの優先順位、設定例、制限事項については、[ファイルキャッシュの設定](./file-cache.md) を参照してください。
+
+> **今後の予定：** Doris の将来のバージョンでは、過去のクエリ統計に基づく適応的な書き込み方法が提供される予定です。
+
+### 再起動後のキャッシュの読み込み
+
+<!-- When to use: Troubleshooting -->
+
+バージョン 3.1 より前は、再起動後に LRU キューの順序を復元できず、頻繁にアクセスされるデータがエビクションされてヒット率が低下することがありました。
+
+**バージョン 3.1 では LRU 情報の永続化が導入されました。** 読み込みの流れは次のとおりです。
+
+1. **定期的なダンプ：** 各 LRU キューの順序情報を定期的にディスクへ永続化します。
+2. **再起動時の読み込み：** ノードの再起動時にディスクからダンプデータを読み取り、キャッシュキューの状態を復元します。
+3. **完全性を確保するためのディスク全体のスキャン：** ダンプの時間差によって生じるメタデータとディスクの不整合を解消するため、再起動後にディスク全体をスキャンしてデータの整合性を確保します。
+4. **クエリを契機とする並行非同期読み込み：** ディスク全体のスキャン中も、BE はクエリを処理できます。まだスキャンされていないデータがクエリの対象になった場合、システムはそのデータを先行して読み込み、クエリのレイテンシーを抑えます。
+
+### スケーリング時
+
+<!-- Knowledge type: Configuration reference -->
+<!-- When to use: Scaling planning -->
+
+#### 水平スケールアウト
+
+Doris はリバランスによってタブレットを新しい BE ノードへ移行します。移行先の BE は移行元 BE のキャッシュメタデータに基づいてデータをローカルストレージに再ダウンロードするため、新しいノードで実行するクエリもファイルキャッシュにヒットできます。[ピアキャッシュ読み取り](./file-cache-peer-read) を使用すると、ダウンロードが完了する前でも、移行先 BE での最初の読み取り時に移行元 BE のキャッシュからブロックを直接取得できます。
+
+#### 水平スケールイン
+
+タブレットのリバランス後、クラスター全体のファイルキャッシュ容量が実際のキャッシュデータ量を下回る場合、エビクションの仕組みによって超過分のデータが自動的に削除されます。
+
+#### 垂直スケールアウト
+
+| スケールアウトの方法 | 手順 |
+|----------------------|------|
+| 単一ディスクの容量を増やす | 次のコマンドを実行して容量の変更を BE に通知します：`curl http://<BE_IP>:<WEB_PORT>/api/file_cache?op=reset&capacity=<new capacity in bytes>` |
+| ディスクを追加する | **推奨しません。** Doris は現在、再ハッシュを実装しておらず、ディスク間のリバランスもサポートしていません。キャッシュディレクトリの数を変更すると、キャッシュの検索に失敗する可能性があります。ディスクを追加する必要がある場合は、キャッシュをクリアし、必要に応じて再度ウォームアップしてください。 |
+
+#### 垂直スケールイン
+
+ディスク容量を減らす場合も、上記の `reset` コマンドを実行する必要があります。キャッシュ容量が実際のキャッシュデータ量を下回ると、エビクションが発生してデータが自動的に削除されます。
+
+#### スケーリング後のウォームアップに関する注意事項
+
+水平スケールアウトと水平スケールインでは、タブレットのリバランスが行われます。ウォームアップを有効に機能させるため、**移行が安定してからウォームアップを実行してください**。移行の完了は、FE メトリクス `doris_fe_tablet_num` を監視して判断できます。曲線が変動せず、平坦で安定していれば、移行が完了しており、ウォームアップを実行できます。
+
+---
+
+## よくある質問
+
+<!-- Knowledge type: Troubleshooting -->
+<!-- When to use: Troubleshooting / Performance tuning -->
+
+**Q：キャッシュヒット率が低く、クエリ性能が改善しません。どのように調査すればよいですか？**
+
+- ファイルキャッシュ用ディスクに十分な空き容量があるか確認します。推奨されるキャッシュ容量は、頻繁にアクセスされるデータ量の少なくとも 1.5 倍です。
+- 大規模なクエリによって、頻繁にアクセスされるデータが繰り返しエビクションされていないか確認します。大規模なクエリの分離を検討してください。
+- 再起動直後に短時間ヒット率が低くなるのは正常です（LRU の復元には時間がかかります）。事前に手動ウォームアップを実行できます。
+
+**Q：スケールアウト後にクエリがキャッシュにヒットしません。どうすればよいですか？**
+
+- タブレットのリバランスが完了したことを確認します（`doris_fe_tablet_num` の曲線が平坦で安定していること）。
+- 対象のテーブルとパーティションに対して手動ウォームアップコマンドを実行します。
+- 水平スケールアウト後、新しい BE でのデータのダウンロードには時間がかかります。この間にキャッシュミスが起きるのは想定どおりです。デフォルトで有効な [ピアキャッシュ読み取り](./file-cache-peer-read) は、この期間の影響を短縮します。無効にされていないことを確認してください。
+
+**Q：Base Compaction によって、頻繁にアクセスされるデータがエビクションされますか？**
+
+- デフォルトでは、Base Compaction は十分な空き容量がある場合にのみキャッシュへ書き込み、頻繁にアクセスされるデータを能動的にエビクションしません。
+- `enable_file_cache_keep_base_compaction_output = true` を有効にすると、Base Compaction のデータがキャッシュへ強制的に書き込まれるため、頻繁にアクセスされるデータがエビクションされる可能性があります。実際のワークロードに基づいて、このトレードオフを評価してください。
+
+**Q：TTL が期限切れになると、データは直ちに削除されますか？**
+
+- いいえ、直ちには削除されません。TTL が期限切れになると、データは Normal タイプに降格し、Normal キューに入って通常の LRU エビクションの対象になります。最終的にいつデータが削除されるかは、エビクションの仕組みによって決まります。
+
+**Q：手動ウォームアップでは、キャッシュ済みデータの再ダウンロードを避けられますか？**
+
+- はい。ウォームアップの実行時、Doris はキャッシュ済みデータを自動的に識別し、新規または変更されたデータのみを増分ダウンロードします。
diff --git a/i18n/ja/docusaurus-plugin-content-docs/version-4.x/compute-storage-decoupled/file-cache/file-cache-peer-read.md b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/compute-storage-decoupled/file-cache/file-cache-peer-read.md
new file mode 100644
index 00000000000..16eccadf85b
--- /dev/null
+++ b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/compute-storage-decoupled/file-cache/file-cache-peer-read.md
@@ -0,0 +1,347 @@
+---
+{
+ "title": "ピアキャッシュ読み取り: 他の BE やコンピュートグループの File Cache を読み取る（コンピュートとストレージの分離）",
+ "sidebar_label": "ピアキャッシュ読み取り",
+ "language": "ja",
+ "description": "ローカル File Cache にないデータを、オブジェクトストレージにフォールバックする前に、別のコンピュートグループを含む他の BE から取得する方法。デフォルト設定、キャッシュへの格納、パラメータ、トラブルシューティングを説明します。",
+ "keywords": ["ピアキャッシュ読み取り", "ピア読み取り", "コンピュートグループ間のキャッシュ", "File Cache のミス", "キャッシュミス時のフォールバック", "コールドリード", "低速なコールドクエリ", "コンピュートグループのスケーリング", "peer_read_async_warmup", "enable_cache_read_from_peer", "peer_cache_fill_compute_group_id", "グループ間のキャッシュへの格納", "ピアと S3 の競合", "AZ 間トラフィック", "コンピュートとストレージの分離"]
+}
+---
+
+<!-- Knowledge type: Architecture decision -->
+<!-- Applicable scenarios: Cold read optimization in compute-storage decoupled mode / Compute group scaling / Cache reuse across compute groups -->
+
+ピアキャッシュ読み取りは、コンピュートとストレージを分離した構成で、File Cache にデータがない場合の読み取り方法です。BE のローカル File Cache にブロックがないとき、同じコンピュートグループまたは別のコンピュートグループにある他の BE の File Cache に問い合わせます。どのピアにもブロックがなければ、オブジェクトストレージから読み取ります。この機能が影響するのはコールドリードの経路だけで、ローカルキャッシュにヒットする読み取りは変わりません。
+
+:::caution 実験的な機能
+
+ピアキャッシュ読み取りは Doris 4.2.0 から利用できる実験的な機能で、デフォルトで有効です。無効にするには、BE で `enable_cache_read_from_peer = false` を設定します。
+
+:::
+
+## ユースケース
+
+<!-- Knowledge type: Architecture decision -->
+
+| シナリオ | ピア読み取りの動作 | 利点 |
+|---|---|---|
+| コンピュートグループ内でのスケーリング | スケールアウトまたはタブレットのリバランス後、新しい BE の最初の読み取りでは、オブジェクトストレージではなく、以前そのタブレットを処理していた BE からキャッシュ済みブロックを取得します | リバランス後の性能低下を短縮し、オブジェクトストレージへのアクセスを減らせます |
+| コンピュートグループ間のコールドリード | このコンピュートグループにキャッシュがなくても、別のグループが同じデータをすでに読み取っていれば、そのグループの BE からブロックを取得します | コールドクエリのレイテンシーとオブジェクトストレージからの読み取りを減らせます |
+| グループ間のキャッシュへの格納 | 「格納先コンピュートグループ」を指定します。そのグループの BE にもブロックがない場合、その BE がオブジェクトストレージからブロックを取得し、自身の File Cache に書き込んでから、要求元の BE に返します | 指定したグループがオブジェクトストレージへのアクセス負荷を引き受け、キャッシュにコピーを保持します |
+
+## 性能の目安
+
+TPC-H の 1 TB データセットを使ったコールドリードのテストでは、ピアキャッシュ読み取りはオブジェクトストレージからの直接読み取りの約二倍の速度でした。実際の効果は、他の BE がすでにデータを保持しているかどうか、およびピア間ネットワークのレイテンシーとオブジェクトストレージのレイテンシーの差によって変わります。
+
+## 前提条件
+
+- コンピュートとストレージを分離したデプロイメント。統合モードではピア読み取りは機能しません。
+- すべての BE で File Cache が有効であること（`enable_file_cache = true`）。
+- `enable_cache_read_from_peer` をデフォルト値の `true` のままにすること。
+- グループ間のキャッシュへの格納を使う場合は、格納先コンピュートグループの ID（`compute_group_id`）。確認方法は[格納先コンピュートグループの指定](#designating-a-fill-compute-group)を参照してください。
+
+## 制限事項
+
+- Doris の内部テーブルだけをサポートします。外部テーブル（Hive、Iceberg など）のデータキャッシュではピア読み取りを使用しません。
+- ピア読み取りはローカル File Cache にデータがない場合にだけ実行されます。ウォームアップジョブによる読み取り、および格納先サーバーが自身のために行うオブジェクトストレージからの読み取りは、再度ピア読み取りを経由しません。
+- `enable_cache_read_from_peer` は、同じグループ内とグループ間の両方のピア読み取りを制御します。**現在、同じグループ内のピア読み取りを有効にしたまま、グループ間のピア読み取りだけを無効にすることはできません。** 候補は FE から取得され、他のコンピュートグループの BE も含まれます。
+- 格納先サーバーは、小さいファイルのマージによって生成されたファイル（Packed File）にまだ対応していません。これらの要求は通常どおりオブジェクトストレージにフォールバックします。
+- 複数の AZ にまたがるデプロイメントでは、グループ間のピア読み取りによって AZ 間のネットワークトラフィックが発生し、追加料金がかかる場合があります。
+- ピア読み取りはベストエフォートです。ピアから読み取るかどうか、どの BE から読み取るかは、候補リスト、タイムアウト、フォールバックのロジックによって決まります。
+
+## 動作の仕組み
+
+<!-- Knowledge type: Architecture principle -->
+<!-- Applicable scenarios: Performance analysis / Expected behavior -->
+
+
+
+### 読み取り経路
+
+1. クエリがブロックを読み取る際、まずローカル File Cache を確認し、ヒットすればそのデータを返します。
+2. キャッシュミスの場合、BE はそのタブレットのピア候補をすでに保持しているか確認します。候補がなければ、この読み取りはオブジェクトストレージに直接進み、BE はバックグラウンドで FE に候補を問い合わせます。現在の要求は候補の取得を待ちません。
+3. 候補がある場合、ピアからの読み取りとオブジェクトストレージからの読み取りを競わせます（`enable_peer_s3_race` はデフォルトで有効です）。BE は先にピア読み取りを送信し、`peer_race_hedge_delay_ms`（デフォルト 20 ms）だけ先行させます。この時間内にピアが応答すれば、オブジェクトストレージへの読み取りは送信されません。
+4. 先に結果を返した方が採用されます。どちらの場合もデータはローカル File Cache に書き込まれるため、以降の読み取りはローカルでヒットします。
+5. ピア読み取りが失敗した場合、オブジェクトストレージにフォールバックし、クエリはエラーになりません。失敗には、候補がブロックを持っていない場合、RPC エラー、同時実行枠が満杯の場合、タイムアウトが含まれます。
+
+`enable_peer_s3_race` が無効の場合、または同時に競合する読み取りの数が `max_concurrent_peer_races`（デフォルト 64）を超えた場合、BE は代わりに順次読み取ります。候補を一つずつ試し、すべて失敗した後にだけオブジェクトストレージから読み取ります。
+
+通常、コールドクエリは多数の読み取りを並行して実行します。セグメントフッターの最初の読み取りで候補の取得がすでに始まるため、同じクエリ内で同じタブレットを後から読み取るときは、ピア読み取りを使用できます。最初のコールドリードがオブジェクトストレージに進むのは想定どおりの動作です。
+
+### 候補の取得元
+
+| 取得元 | 説明 | 優先順位 |
+|---|---|---|
+| リバランス元の BE | コンピュートグループのスケールアウトまたはタブレットのリバランス中、FE が移動先 BE に送るウォームアップ要求によって、移動元 BE が候補として記録されます。`balance_type` が `without_warmup` に設定されている場合、ウォームアップ要求は送信されず、候補も記録されません | 最高 |
+| FE が返すタブレットの配置情報 | ローカルの候補がない場合、BE は各コンピュートグループでそのタブレットを保持する BE をバックグラウンドで FE に問い合わせ、リストの末尾に追加します | 低い |
+| 手動設定 | HTTP インターフェース `/api/peer_cache?op=set` から書き込みます（[タブレットのピア情報の確認と調整](#inspecting-and-adjusting-the-peer-info-of-a-tablet)を参照）。通常、テストやトラブルシューティングにだけ使用します | 書き込んだ順序 |
+
+### 候補の選択とローテーション
+
+- BE は各タブレットを最後に正常に処理したコンピュートグループを記憶し、そのグループの候補を最初に試します。
+- ブロックを持たない候補はリストの末尾に移されるため、次の読み取りでは別の候補を試します。RPC が `peer_rpc_failure_eviction_threshold`（デフォルト 3）回連続で失敗した候補は除外されます。
+- すべての候補でキャッシュミスが発生する読み取りが `peer_all_miss_cooldown_threshold`（デフォルト 5）回連続すると、タブレットは `peer_all_miss_cooldown_duration_s`（デフォルト 300 秒）のクールダウンに入ります。クールダウン中、そのタブレットの読み取りはオブジェクトストレージに直接進みます。
+- `peer_candidate_expiry_s`（デフォルト 3600 秒）の間使われていない候補エントリはメモリから削除されます。次のキャッシュミス時に FE から再取得します。
+
+### グループ間のキャッシュへの格納
+
+要求元 BE に `peer_cache_fill_compute_group_id` が設定されていて、選ばれた候補がそのコンピュートグループに属する場合、要求には格納フラグが付けられます。受信側 BE にブロックがなく、`enable_peer_server_cache_fill` が有効（デフォルト）なら、オブジェクトストレージからブロックを読み取り、自身の File Cache に書き込んでから返します。
+
+格納処理には `max_concurrent_peer_server_fills`（デフォルト 32）と `peer_server_cache_fill_timeout_ms`（デフォルト 6000 ms）の上限があります。上限に達した場合やタイムアウトした場合、要求元 BE はオブジェクトストレージにフォールバックします。
+
+## 設定
+
+<!-- Knowledge type: Operations -->
+<!-- Applicable scenarios: BE configuration / Bringing a compute group online -->
+
+以下のパラメータはすべて BE の設定項目です。スレッドプールのパラメータを除き、実行時に変更できます。[実行時のパラメータ変更](#changing-parameters-at-runtime)を参照してください。
+
+### ピア読み取りの確認と無効化
+
+ピア読み取りはデフォルトで有効です。File Cache が有効になれば、同じグループ内とグループ間のどちらの読み取りでも動作します。FE が候補を自動的に提供します。MySQL クライアントから現在の値を確認します。
+
+```sql
+SHOW BACKEND CONFIG LIKE 'enable_cache_read_from_peer';
+```
+
+無効にするには、すべての BE の `be.conf` に次の設定を追加します。
+
+```properties
+enable_cache_read_from_peer = false
+```
+
+無効にすると、ローカルでのキャッシュミスはオブジェクトストレージに直接進み、`peer_read_async_warmup` などのピア読み取りに依存するバランス戦略は効果を失います。
+
+### 格納先コンピュートグループの指定 {#designating-a-fill-compute-group}
+
+グループ間のコールドリード時に特定のコンピュートグループがオブジェクトストレージからデータを取得し、自身のキャッシュに格納するには、次の三つの手順を実行します。
+
+1. 対象のコンピュートグループの ID を確認します。`compute_group_id` は `Tag` 列にあり、`SHOW BACKENDS` で確認できます。`compute_group_name` ではありません。
+
+ ```sql
+ SHOW BACKENDS\G
+ ```
+
+ ```text
+ *************************** 1. row ***************************
+ BackendId: 10001
+ Host: 10.0.0.1
+ ...
+ Tag: {"cloud_unique_id" : "1:xxx:yyy", "compute_group_id" : "cg_write_01", "compute_group_name" : "write_group", "compute_group_status" : "NORMAL", "location" : "default"}
+ ```
+
+2. クエリを実行するコンピュートグループのすべての BE に、次のように設定します。
+
+ ```properties
+ peer_cache_fill_compute_group_id = cg_write_01
+ ```
+
+3. 格納先コンピュートグループの BE で、`enable_peer_server_cache_fill` が `true`（デフォルト）であることを確認します。
+
+### 実行時のパラメータ変更 {#changing-parameters-at-runtime}
+
+スレッドプールのパラメータを除き、このページのすべてのパラメータは実行時に変更できます。`persist=true` を追加すると、変更が `be_custom.conf` に永続化されます。
+
+```bash
+curl -X POST "http://<be_host>:<be_webserver_port>/api/update_config?enable_cache_read_from_peer=false&persist=true"
+curl -X POST "http://<be_host>:<be_webserver_port>/api/update_config?peer_race_hedge_delay_ms=30"
+```
+
+## パラメータ
+
+<!-- Knowledge type: Configuration reference -->
+
+### 有効化と競合読み取り
+
+| パラメータ | デフォルト | 説明 |
+|---|---|---|
+| `enable_cache_read_from_peer` | `true` | ピア読み取りの主スイッチ。有効な場合、ローカル File Cache にデータがなければ、同じコンピュートグループ内と別のコンピュートグループの両方で他の BE を最初に試します |
+| `enable_peer_s3_race` | `true` | ピア読み取りとオブジェクトストレージからの読み取りを競わせるかどうか。無効な場合は順次読み取ります。候補を一つずつ試し、すべて失敗した後にだけオブジェクトストレージから読み取ります |
+| `peer_race_hedge_delay_ms` | `20` | ピア読み取りを先行させる時間（ミリ秒）。この時間内にピアが応答すれば、オブジェクトストレージへの読み取りは送信されません。`0` なら両方を同時に開始します |
+| `max_concurrent_peer_races` | `64` | 一台の BE で同時に実行できる競合読み取りの最大数。上限を超えたキャッシュミスは順次処理されます |
+
+### キャッシュへの格納の設定
+
+| パラメータ | デフォルト | 説明 |
+|---|---|---|
+| `peer_cache_fill_compute_group_id` | `""` | 要求元に設定します。格納処理を担当するコンピュートグループの ID（名前ではなく `compute_group_id`）。選ばれた候補がこのグループに属する場合、要求に格納フラグが付けられます |
+| `enable_peer_server_cache_fill` | `true` | 提供側に設定します。格納フラグ付きの要求を受け入れるかどうか。有効な場合、ブロックがローカルにキャッシュされていなければ、オブジェクトストレージから読み取り、ローカル File Cache に書き込んで返します |
+| `peer_server_cache_fill_timeout_ms` | `6000` | 提供側での一回の格納処理の最大待機時間（ミリ秒）。タイムアウトすると要求元はオブジェクトストレージにフォールバックします |
+| `max_concurrent_peer_server_fills` | `32` | 提供側で同時に実行できる格納処理の最大数。上限を超えた要求は拒否され、要求元はオブジェクトストレージにフォールバックします |
+
+### 候補の管理
+
+| パラメータ | デフォルト | 説明 |
+|---|---|---|
+| `peer_rpc_failure_eviction_threshold` | `3` | RPC がこの回数連続で失敗すると候補を除外します |
+| `peer_all_miss_cooldown_threshold` | `5` | すべての候補でキャッシュミスが発生する読み取りが何回連続すると、タブレットがクールダウンに入るかを指定します |
+| `peer_all_miss_cooldown_duration_s` | `300` | クールダウンの長さ（秒）。クールダウン中、そのタブレットの読み取りはオブジェクトストレージに直接進みます |
+| `peer_candidate_expiry_s` | `3600` | 最後に使用してから候補エントリが失効するまでの時間（秒）。失効したエントリは削除され、次のキャッシュミス時に FE から再取得されます |
+| `peer_candidate_cleanup_interval_s` | `3600` | 失効した候補を削除するバックグラウンドジョブの実行間隔（秒） |
+
+### スレッドプールとキュー
+
+| パラメータ | デフォルト | 説明 |
+|---|---|---|
+| `peer_fetch_queue_timeout_ms` | `100` | 提供側の設定。ピア読み取り要求が処理キューでこの時間（ミリ秒）を超えて待機すると拒否され、要求元はすぐにオブジェクトストレージにフォールバックします |
+| `brpc_peer_fetch_pool_threads` | `-1` | 提供側の設定。ロードなどの負荷の高い RPC とは分離して、ピア読み取り要求を処理するスレッド数。`-1` は `max(64, 2 × CPU cores)` を意味します。静的な設定で、変更には BE の再起動が必要です |
+| `brpc_peer_fetch_pool_max_queue_size` | `-1` | そのスレッドプールのキュー長。`-1` は `max(4096, 128 × CPU cores)` を意味します。静的な設定です |
+| `min_peer_race_s3_thread_num` / `max_peer_race_s3_thread_num` | `0` / `32` | 要求元の設定。競合読み取り中にオブジェクトストレージから読み取るスレッドプールのサイズ。静的な設定です |
+
+## 副作用と注意事項
+
+<!-- Knowledge type: Architecture decision -->
+<!-- Applicable scenarios: Evaluating compute group isolation / Cost evaluation -->
+
+グループ間のピア読み取りを有効にすると、コンピュートグループ間の分離が弱まります。あるグループのクエリが別のグループのネットワーク、ディスク、File Cache の読み取り容量を使います。格納処理を設定した場合は、別のグループがそのクエリのためにオブジェクトストレージの帯域幅も消費します。クエリが消費するリソースは、そのクエリ自身のコンピュートグループ内に収まらなくなります。
+
+格納処理では提供側 BE のローカル File Cache にデータを書き込むため、その BE 自身のホットデータが追い出されることがあります。
+
+競合読み取りを有効にすると、一部のキャッシュミスではピア RPC とオブジェクトストレージからの読み取りが短時間、両方発生します。20 ms の先行時間はこの重複を減らしますが、なくすことはできません。
+
+ピアへのヒットは保証されません。提供側の同時実行枠や格納処理枠が満杯の場合、ブロックがない場合、タイムアウトした場合は、いずれもオブジェクトストレージにフォールバックします。競合読み取りが有効なら、通常、コールドクエリはオブジェクトストレージからの直接読み取りより遅くなりませんが、必ず速くなるわけでもありません。
+
+複数の AZ にまたがるデプロイメントでは、グループ間のピア読み取りに AZ 間トラフィックの料金がかかります。
+
+## 観測とトラブルシューティング
+
+<!-- Knowledge type: Troubleshooting -->
+<!-- Applicable scenarios: Confirming that peer read is working / Diagnosing slow cold reads -->
+
+### クエリプロファイルのカウンター
+
+ピア読み取りのカウンターは、プロファイルの `SegmentIterator` ノードで、他の File Cache カウンターの隣に表示されます。プロファイルの取得方法と読み方は、[クエリプロファイル](../../query-acceleration/query-profile)を参照してください。
+
+| カウンター | 意味 | 確認できること |
+|---|---|---|
+| `NumPeerIOTotal` | ピアから提供された読み取りの回数 | クエリがピア読み取りを使用したかどうか |
+| `PeerIOUseTimer` | ピア読み取り経路にかかった合計時間 | ピア読み取り経路自体が遅いかどうか |
+| `SameCGPeerIOTotal` / `SameCGPeerBytesRead` / `SameCGPeerIOTime` | 同じグループ内のピア読み取りの回数、バイト数、時間 | ピア読み取りの大半がコンピュートグループ内に収まっているかどうか |
+| `CrossCGPeerIOTotal` / `CrossCGPeerBytesRead` / `CrossCGPeerIOTime` | グループ間のピア読み取りの回数、バイト数、時間 | グループ間の読み取りが発生したか、どれだけのトラフィックが生じたか |
+| `PeerRaceWin` / `S3RaceWin` | ピアまたはオブジェクトストレージが競合読み取りで勝った回数。`enable_peer_s3_race = true` の場合にだけ意味があります | `S3RaceWin` が大幅に多い場合、この環境ではピアの方が速い経路ではないことを示します |
+| `PeerLazyFetch` / `PeerLazyFetchTime` | タブレットに候補がなかったときに実行された、FE からのバックグラウンド候補取得の回数と時間 | 最初の読み取りがピアに進まなかった理由を確認できます |
+| `PeerCacheNodes` | クエリが実際に読み取ったピアノード | データの取得元 BE を確認できます |
+
+`InvertedIndexNumPeerIOTotal` / `InvertedIndexPeerIOUseTimer` と `SegmentFooterIndexNumPeerIOTotal` / `SegmentFooterIndexPeerIOUseTimer` は、転置インデックスファイル、およびセグメントフッターと内部インデックスについて、ピア読み取りの回数と時間を計測します。インデックスの読み取りでもピアにヒットしたか確認できます。
+
+### BE の bvar メトリクス
+
+`curl http://<be_host>:<brpc_port>/vars` で取得します（`brpc_port` のデフォルトは 8060）。要求元（読み取りを発行する BE）のメトリクスは次のとおりです。
+
+| メトリクス | 意味 |
+|---|---|
+| `cached_remote_reader_peer_read` | 発行されたピア読み取りの回数 |
+| `cached_remote_reader_s3_read` | 発行されたオブジェクトストレージからの読み取りの回数 |
+| `peer_race_peer_win` / `peer_race_s3_win` | ピアまたはオブジェクトストレージが競合読み取りで勝った回数 |
+| `peer_same_compute_group_read` / `peer_cross_compute_group_read` | 成功した同じグループ内またはグループ間のピア読み取りの回数 |
+| `peer_lazy_fetch_triggered` | FE からバックグラウンドで候補を取得した回数 |
+| `peer_cache_reader_peer_latency` | ピア RPC のレイテンシー |
+
+提供側（キャッシュを提供する BE）のメトリクスは次のとおりです。
+
+| メトリクス | 意味 |
+|---|---|
+| `file_cache_get_by_peer_num` / `file_cache_get_by_peer_success_num` / `file_cache_get_by_peer_failed_num` | 受信したピア読み取り要求の回数と、その成功回数および失敗回数 |
+| `file_cache_get_by_peer_queue_timeout_num` | キューで `peer_fetch_queue_timeout_ms` を超えて待機したために拒否された要求の回数 |
+| `peer_server_fill_requested` / `peer_server_fill_success` | 要求された格納処理と完了した格納処理の回数 |
+| `peer_server_fill_timeout` / `peer_server_fill_rejected` | タイムアウトした格納処理と、空き枠がないため拒否された格納処理の回数 |
+
+読み方の例:
+
+- `cached_remote_reader_peer_read` が多く、`cached_remote_reader_s3_read` が少ない: 全体としてピア読み取りが機能しています。
+- `peer_race_s3_win` が `peer_race_peer_win` を明らかに上回る: この環境ではピアの方が速い経路ではありません。`peer_race_hedge_delay_ms` を増やすか、ピア読み取りを無効にします。
+- `peer_cross_compute_group_read` が多い: グループ間のトラフィックが発生しています。分離への影響を確認してください。
+- `peer_server_fill_requested` が多い一方、`peer_server_fill_success` が少なく、`peer_server_fill_timeout` が多い: 格納先コンピュートグループが過負荷か、設定が適切ではありません。
+
+### タブレットのピア情報の確認と調整 {#inspecting-and-adjusting-the-peer-info-of-a-tablet}
+
+BE は `/api/peer_cache` を `webserver_port`（デフォルト 8040）で公開し、一つのタブレットの候補を表示・変更できます。主にトラブルシューティング用のツールです。
+
+一つのタブレットについて、候補、最後に成功したコンピュートグループ、連続キャッシュミス回数、クールダウン状態を表示します。
+
+```bash
+curl "http://<be_host>:<be_webserver_port>/api/peer_cache?op=show&tablet_id=<tablet_id>"
+```
+
+```json
+{
+ "tablet_id": 10086,
+ "candidates": [
+ {"host": "10.0.0.2", "brpc_port": 8060, "compute_group_id": "cg_write_01", "last_access_time_ms": 1758441600000, "consecutive_rpc_failures": 0}
+ ],
+ "last_successful_compute_group_id": "cg_write_01",
+ "fetching_from_fe": false,
+ "consecutive_all_miss": 0,
+ "cooldown_until_ms": 0
+}
+```
+
+この BE で候補を持つすべてのタブレットを一覧表示します。`limit` のデフォルトは 1000 です。
+
+```bash
+curl "http://<be_host>:<be_webserver_port>/api/peer_cache?op=show_all&limit=100"
+```
+
+タブレットの候補を強制的に設定します（JSON のリクエストボディ）。
+
+```bash
+curl -X POST "http://<be_host>:<be_webserver_port>/api/peer_cache?op=set&tablet_id=<tablet_id>" \
+ -H "Content-Type: application/json" \
+ -d '{
+ "candidates": [
+ {"host": "10.0.0.2", "brpc_port": 8060, "compute_group_id": "cg_write_01"}
+ ],
+ "last_successful_compute_group_id": "cg_write_01",
+ "consecutive_all_miss": 0,
+ "cooldown_until_ms": 0
+ }'
+```
+
+タブレットの候補を削除するか、クールダウンを解除します。
+
+```bash
+curl -X POST "http://<be_host>:<be_webserver_port>/api/peer_cache?op=remove&tablet_id=<tablet_id>"
+curl -X POST "http://<be_host>:<be_webserver_port>/api/peer_cache?op=reset_cooldown&tablet_id=<tablet_id>"
+```
+
+## ベストプラクティス
+
+<!-- Knowledge type: Architecture decision -->
+
+- [キャッシュのウォームアップ](./file-cache#cache-warmup)と併用します。ウォームアップは事前にオブジェクトストレージからデータを取得し、ピア読み取りはクエリの実行時に他の BE から取得します。既知のホットデータはウォームアップで準備し、ウォームアップされなかったコールドリードをピア読み取りで補います。
+- スケーリング前からピア読み取りを有効にしておきます。スケールアウトまたはタブレットのリバランス後、新しい BE は移動元 BE のキャッシュを再利用できます。`balance_type = peer_read_async_warmup` と組み合わせると、マッピングがすぐに切り替わり、ピア読み取りが移行時の性能低下を和らげます。[コンピュートグループのスケーリング](../managing-compute-cluster#scale-compute-groups)を参照してください。
+- 読み書き分離の構成では、書き込み用コンピュートグループを格納先グループにします。読み取り専用グループのコールドリードに応じて、書き込み用グループがオブジェクトストレージからデータを取得し、コピーを保持します。[読み書き分離における File Cache 最適化のベストプラクティス](../rw/file-cache-rw-compute-group-best-practice)を参照してください。
+- コンピュートグループを厳密に分離する必要がある場合、またはクラスターが複数の AZ にまたがり、AZ 間トラフィックの料金が問題になる場合は、ピア読み取りを無効にします（`enable_cache_read_from_peer = false`）。
+- 調整前にメトリクスを確認します。`PeerRaceWin` / `S3RaceWin` と bvar でピアが競合読み取りに勝っているか確認してから、`peer_race_hedge_delay_ms` を調整するか、競合読み取りを無効にするか判断します。
+
+## よくある質問（FAQ）
+
+<!-- Knowledge type: Troubleshooting -->
+
+**Q: 最初のコールドリードがオブジェクトストレージに進んだのはなぜですか？**
+
+BE がまだそのタブレットの候補を持っていない場合、現在の要求は FE からの取得を待ちません。バックグラウンドで候補を取得する間、オブジェクトストレージから読み取ります。同じクエリ内で同じタブレットを後から読み取る場合や、その後のクエリではピア読み取りを使用します。プロファイルで `PeerLazyFetch` が 0 より大きければ、このケースに該当します。
+
+**Q: クエリがピア読み取りを使用したことを確認するには？**
+
+プロファイルの `NumPeerIOTotal`、`SameCGPeerIOTotal`、`CrossCGPeerIOTotal`、`PeerCacheNodes` を確認します。BE でも `cached_remote_reader_peer_read` が増えているはずです。
+
+**Q: コンピュートグループ内のピア読み取りだけを許可し、グループ間はブロックできますか？**
+
+現在はできません。`enable_cache_read_from_peer` は両方のピア読み取りを制御し、FE が返す候補にはすべてのコンピュートグループの BE が含まれます。
+
+**Q: ピア読み取りを無効にするには？**
+
+すべての BE で `enable_cache_read_from_peer = false` を設定します。変更は実行時に適用できます。以降、ローカルでのキャッシュミスはオブジェクトストレージから直接読み取ります。
+
+**Q: `S3RaceWin` が `PeerRaceWin` より大幅に多い場合はどうすればよいですか？**
+
+この環境では、通常、ピア間ネットワークのレイテンシーが高いか、ピア BE が高負荷のため、ピアからの読み取りがオブジェクトストレージからの読み取りより速くありません。`peer_race_hedge_delay_ms` を大きくしてカウンターを確認するか、ピア読み取りを無効にします。
+
+**Q: タブレットでピア読み取りがまったく使われません。**
+
+`/api/peer_cache?op=show&tablet_id=<tablet_id>` を実行します。`candidates` リストが空なら、候補はまだ取得されていません。`cooldown_until_ms` がゼロ以外なら、そのタブレットはクールダウン中です。`op=reset_cooldown` で解除できます。
+
+**Q: グループ間のキャッシュへの格納が機能しません。**
+
+次の順に確認します。要求元の `peer_cache_fill_compute_group_id` が名前ではなくコンピュートグループの ID であること。選ばれた候補が実際にそのグループに属すること（`compute_group_id` を `op=show` の出力で確認）。格納先の `enable_peer_server_cache_fill` が `true` であること。`peer_server_fill_rejected` または `peer_server_fill_timeout` が増えていないかどうか。
diff --git a/i18n/ja/docusaurus-plugin-content-docs/version-4.x/compute-storage-decoupled/file-cache/file-cache.md b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/compute-storage-decoupled/file-cache/file-cache.md
new file mode 100644
index 00000000000..a4a1f9385b9
--- /dev/null
+++ b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/compute-storage-decoupled/file-cache/file-cache.md
@@ -0,0 +1,615 @@
+---
+{
+ "title": "ファイルキャッシュの設定と使用ガイド（コンピュートとストレージの分離）",
+ "sidebar_label": "ファイルキャッシュの設定",
+ "language": "ja",
+ "description": "コンピュートとストレージを分離した Doris で、クエリ性能の向上とオブジェクトストレージのコスト削減に役立つ、ファイルキャッシュの設定、インデックスのみのキャッシュ書き込み、クエリ単位のキャッシュ制御、キャッシュのウォームアップとエビクション、ヒット率の監視、TTL ポリシーを説明します。",
+ "keywords": ["Doris ファイルキャッシュ", "コンピュートとストレージを分離した構成のキャッシュ", "ファイルキャッシュ", "インデックスのみのキャッシュ書き込み", "キャッシュのウォームアップ", "ピアキャッシュ読み取り", "キャッシュクォータ", "file_cache_query_limit_bytes", "TTL キャッシュ", "LRU", "キャッシュヒット率", "オブジェクトストレージの高速化"]
+}
+---
+
+<!-- Knowledge type: Architecture and design decisions -->
+<!-- Applicable scenarios: Compute-storage decoupled deployment / Query performance optimization / Object storage cost optimization -->
+
+コンピュートとストレージを分離したモードでは、データはリモートのオブジェクトストレージ（S3 や HDFS など）に保存されます。Doris は BE ノードのローカルディスクをファイルキャッシュ層として使用し、複数キューの LRU（Least Recently Used）方式でキャッシュ領域を効率的に管理します。インデックスとメタデータへのアクセス経路には特別な最適化が施されており、頻繁に使われるデータのキャッシュヒット率を最大化します。
+
+複数のコンピュートグループを使用する場合、Doris は**キャッシュのウォームアップ**機能を提供します。新しいコンピュートグループの起動時に、指定したテーブルやパーティションのデータを先読みしてローカルキャッシュをすばやく構築し、初回クエリの性能を改善します。デフォルトで有効な[ピアキャッシュ読み取り](./file-cache-peer-read)は、ローカルキャッシュにないブロックをリモートストレージから読む前に、別の BE（他のコンピュートグループの BE を含む）のキャッシュから取得します。
+
+## ファイルキャッシュの役割
+
+<!-- Knowledge type: Architecture and design decisions -->
+
+コンピュートとストレージを分離したモードでは、リモートストレージへのアクセスには通常、次の二種類の問題があります。
+
+| 問題 | 説明 |
+|---|---|
+| アクセス遅延が大きい | オブジェクトストレージの遅延はローカルディスクより大幅に大きく、高い同時実行数で特に顕著になります |
+| QPS／帯域幅の制限 | オブジェクトストレージには通常、QPS の上限と帯域幅の制約があり、同時実行数の多いクエリではボトルネックになります |
+| 従量課金のコスト | オブジェクトストレージはリクエスト数とデータ転送量に応じて課金されるため、頻繁なアクセスは運用コストを増やします |
+
+使用頻度の高いデータをローカルディスクにキャッシュすることで、Doris はクエリの遅延を大幅に減らすとともに、オブジェクトストレージへの直接リクエストを減らしてコストを抑えられます。
+
+### キャッシュされるファイルの種類
+
+Doris のファイルキャッシュは、主に次の二種類のファイルをキャッシュします。
+
+- **Segment データファイル**：Doris の内部テーブルデータの基本的な格納単位です。キャッシュするとデータの読み取りが速くなり、クエリ性能が向上します。
+- **転置インデックスファイル**：クエリのフィルタ処理を高速化するために使用します。キャッシュすると、条件に一致するデータをより速く特定でき、複雑なクエリの実行にも役立ちます。
+
+## キャッシュの設定
+
+<!-- Knowledge type: Configuration parameters -->
+<!-- Applicable scenarios: Pre-deployment configuration for compute-storage decoupled mode / BE parameter tuning -->
+
+Doris は、BE 設定ファイルの次のパラメータでファイルキャッシュの動作を制御します。
+
+### ファイルキャッシュの有効化
+
+| パラメータ | デフォルト値 | 説明 |
+|---|---|---|
+| `enable_file_cache` | `true` | ファイルキャッシュ機能を有効にするかどうかを指定します。Doris 4.2 以降ではデフォルトで有効です。コンピュートとストレージを分離したモードでは、BE によって常に有効にされます |
+
+:::caution
+
+`file_cache_path` のデフォルトは、BE のデプロイ先パスにあるストレージディレクトリです。`total_size` を指定しない場合、ディスク使用率が 85%～88% に達するまでキャッシュが増える可能性があります。上限を設定するには `total_size` を指定してください。
+
+:::
+
+### インデックスのみのキャッシュ書き込みの設定
+
+ローカルキャッシュの容量が限られ、クエリ性能がインデックスと Segment メタデータにより強く依存する場合は、インデックスのみを書き込むポリシーを有効にできます。このポリシーは、データ取り込み、Schema Change、Compaction などの書き込み経路から File Cache に**能動的に書き込む**対象を制限します。キャッシュミス後にクエリ側で行うキャッシュへの格納や、キャッシュのウォームアップには影響しません。
+
+Doris には、グローバルポリシーが一つ、Compaction 専用のポリシーが二つあります。
+
+| パラメータ | 型 | デフォルト値 | 適用範囲 | 説明 |
+|---|---|---|---|---|
+| `enable_file_cache_write_index_file_only` | Boolean | `false` | データ取り込み、Schema Change、Cumulative Compaction、Base Compaction を含む、コンピュートとストレージを分離したモードでのすべての rowset 書き込み | **Doris 4.0.8 以降の 4.0 系、および Doris 4.1.4 以降の 4.1 系でサポートされます。** `true` にすると、Segment データは能動的にキャッシュされません。Segment を閉じた後、そのフッターと内部インデックスの範囲が同期的に先読みされ、独立した転置インデックスファイルは引き続き File Cache に書き込まれます。このパラメータは、Compaction 専用の両パラメータより優先されます |
+| `enable_file_cache_write_base_compaction_index_only` | Boolean | `false` | Base Compaction | 既存の Base Compaction ポリシーが出力を File Cache に書き込むと決定した場合に限り、独立した転置インデックスファイルを引き続きキャッシュしながら、Segment ファイルの能動的なキャッシュを防ぎます。本来キャッシュを経由しない Base Compaction の出力が、このパラメータによってキャッシュされることはありません |
+| `enable_file_cache_write_cumu_compaction_index_only` | Boolean | `false` | Cumulative Compaction | Cumulative Compaction の出力が File Cache に書き込まれる場合に、独立した転置インデックスファイルを引き続きキャッシュしながら、Segment ファイルの能動的なキャッシュを防ぎます |
+
+書き込み経路では、次の優先順位でキャッシュの動作を決定します。
+
+1. `enable_file_cache=false` が最優先され、Segment フッター／内部インデックスの先読みや独立した転置インデックスの書き込みを含む、File Cache へのすべての書き込みを無効にします。
+2. `enable_file_cache=true` かつ `enable_file_cache_write_index_file_only=true` の場合、グローバルなインデックスのみのポリシーが有効です。Compaction 専用の両パラメータは、最終的な動作を変更しなくなります。適応的な書き込み、Compaction の保持ポリシー、キャッシュヒット率のしきい値、リクエスト単位の `write_file_cache` 設定によって Segment データが能動的にキャッシュされることはありません。インデックス関連の内容は、上記のグローバルポリシーに従って引き続き書き込まれます。
+3. グローバルなインデックスのみのポリシーが無効な場合、Base／Cumulative Compaction 専用のパラメータは、該当する種類の出力のうち**すでにキャッシュ対象として選ばれたもの**だけを追加で制限します。その他の書き込みやクエリの読み取り経路には影響しません。
+4. インデックスのみの三つのパラメータがすべて `false` の場合、既存の能動的なキャッシュ書き込み、適応的な書き込み、Compaction 出力の保持動作は変わりません。
+
+:::caution
+
+Compaction 専用の両パラメータは、独立した転置インデックスファイルと Segment ファイルのみを区別します。グローバルなインデックスのみのポリシーで行う Segment フッター／内部インデックス範囲の先読みは実行しません。独立した転置インデックスと Segment 内部のインデックスおよびメタデータの両方を能動的に保持するには、`enable_file_cache_write_index_file_only` を使用してください。
+
+:::
+
+#### グローバルなインデックスのみのポリシーの有効化
+
+すべての BE ノードの `be.conf` に、次の設定を追加します。
+
+```properties
+enable_file_cache=true
+enable_file_cache_write_index_file_only=true
+enable_file_cache_write_base_compaction_index_only=false
+enable_file_cache_write_cumu_compaction_index_only=false
+```
+
+想定される動作は次のとおりです。
+
+| シナリオ | File Cache に能動的に書き込まれる内容 |
+|---|---|
+| データ取り込み、Schema Change、Cumulative Compaction、Base Compaction | Segment データは能動的に書き込まれません。Segment フッター／内部インデックスの範囲は同期的に先読みされ、独立した転置インデックスファイルは書き込まれます |
+| クエリによるデータページの読み取り | 動作は変わりません。キャッシュミス後、既存の読み取り経路のルールに従って Segment データがキャッシュに格納される場合があります |
+| キャッシュのウォームアップ | 動作は変わりません |
+| Packed File | パックされた小さな Segment ファイルはファイル全体としてキャッシュされません。パックされた独立した小さなインデックスファイルは、引き続きファイル全体としてキャッシュできます |
+
+グローバルなインデックスのみのポリシーでは、Segment フッター／内部インデックスの範囲は同期読み取りによってキャッシュに書き込まれ、`enable_flush_file_cache_async` の制御を受けません。独立した転置インデックスファイルには、従来どおりの直接書き込みと非同期フラッシュが適用されます。
+
+#### Compaction の出力のみを制限する
+
+データ取り込みと Schema Change からの能動的なキャッシュ書き込みを変えずに、Compaction 出力によるキャッシュ負荷を減らすには、次のように設定します。
+
+```properties
+enable_file_cache=true
+enable_file_cache_write_index_file_only=false
+enable_file_cache_write_base_compaction_index_only=true
+enable_file_cache_write_cumu_compaction_index_only=true
+```
+
+Cumulative Compaction はデフォルトで出力をキャッシュに書き込むため、対応するパラメータを有効にすると Segment ファイルを除外し、独立した転置インデックスファイルのみを保持します。Base Compaction では、まず `enable_file_cache_keep_base_compaction_output` と入力 rowset のキャッシュヒット率によって、出力をキャッシュするかどうかを決定します。Base Compaction 用のインデックスのみのパラメータは、その決定後に書き込む内容だけを制限します。
+
+#### 推奨事項
+
+- これら三つは BE パラメータです。同じコンピュートグループ内の BE ノードでキャッシュ書き込みポリシーが異ならないよう、すべてのノードで同じ値にしてください。
+- 「インデックスのみ」は、File Cache に Segment データが一切含まれないという意味ではありません。クエリ側でキャッシュミスしたデータページを読み取ると、Segment データがキャッシュに格納される場合があります。
+- このポリシーはデータ取り込みと Compaction によるキャッシュ汚染を減らせますが、書き込み直後に大量のデータをスキャンすると、リモートストレージからの読み取りが増える場合があります。本番のクエリワークロードで性能を測定し、SQL Profile の Index キューのエビクションとインデックス読み取りのメトリクスを監視してください。
+
+### キャッシュのパスとサイズの設定
+
+```plaintext
+file_cache_path Default: the storage directory under the BE deployment path
+```
+
+このパラメータは JSON 配列です。各要素でキャッシュのパスと属性を指定します。サポートされるフィールドは次のとおりです。
+
+| フィールド | 説明 |
+|---|---|
+| `path` | キャッシュファイルを保存するパス |
+| `total_size` | このパスのキャッシュ総容量（バイト） |
+| `ttl_percent` | TTL キューに割り当てる領域の割合 |
+| `normal_percent` | Normal キューに割り当てる領域の割合 |
+| `disposable_percent` | Disposable キューに割り当てる領域の割合 |
+| `index_percent` | Index キューに割り当てる領域の割合 |
+| `storage` | キャッシュのストレージ種別。`disk`（デフォルト）または `memory` |
+
+**設定例：**
+
+- 単一パスの設定：
+
+ ```json
+ [{"path":"/path/to/file_cache","total_size":21474836480}]
+ ```
+
+- 複数パスの設定：
+
+ ```json
+ [{"path":"/path/to/file_cache","total_size":21474836480},{"path":"/path/to/file_cache2","total_size":21474836480}]
+ ```
+
+- メモリストレージの設定：
+
+ ```json
+ [{"path": "xxx", "total_size":53687091200, "storage": "memory"}]
+ ```
+
+### キャッシュの自動クリア
+
+| パラメータ | デフォルト値 | 説明 |
+|---|---|---|
+| `clear_file_cache` | `false` | BE の再起動時にキャッシュデータを自動的にクリアするかどうかを指定します。`true` にすると、再起動するたびにキャッシュがクリアされます |
+
+### 事前エビクション
+
+事前エビクションは、キャッシュ使用率がしきい値に達したときに領域を先に解放し、クエリ実行中に受動的なエビクションが発生して性能が不安定になるのを防ぎます。
+
+| パラメータ | デフォルト値 | 説明 |
+|---|---|---|
+| `enable_evict_file_cache_in_advance` | `true` | 事前エビクションを有効にするかどうか |
+| `file_cache_enter_need_evict_cache_in_advance_percent` | `88` | 事前エビクションを開始する使用率のしきい値（%）。使用済みキャッシュ領域または inode 数がこの割合に達すると開始します |
+| `file_cache_exit_need_evict_cache_in_advance_percent` | `85` | 事前エビクションを停止する使用率のしきい値（%）。使用済みキャッシュ領域がこの割合まで下がると停止します |
+
+## キャッシュクォータ
+
+<!-- Knowledge type: Configuration parameters -->
+<!-- Applicable scenarios: Multi-user shared cache / Preventing large-query cache thrashing -->
+
+Doris には、クエリ単位の独立した File Cache 制御が二種類あります。クエリがすでに占有しているキャッシュ量を制限したいか、以降のキャッシュへの格納を停止したいかに応じて、パラメータを選びます。
+
+| 制御方法 | 主なパラメータ | 制限到達後の動作 | 用途 |
+|---|---|---|---|
+| キャッシュ占有率で制限 | `file_cache_query_limit_percent` | 新しいキャッシュブロックを書き込むことができます。BE はまず現在のクエリに記録された解放可能なブロックをエビクトし、必要に応じて他のキャッシュキューからエビクトします | 以降のキャッシュへの格納を許可しつつ、クエリのキャッシュ占有量を制限する |
+| バイト数のしきい値でリモートスキャンのキャッシュ書き込みを停止 | `file_cache_query_limit_bytes` | 次のキャッシュブロックで受け入れ済みのバイト数がしきい値を超える場合、その BE 上のクエリはキャッシュミス時にリモートのみを読むモードに移行します。以降のミスでは、File Cache に追加で書き込まずにリモートストレージから読み取ります | 大規模なリモートスキャンによるキャッシュ書き込みと入れ替わりを抑える |
+| TopN 遅延実体化のフェーズ 2 でキャッシュ書き込みを停止 | `enable_topn_lazy_mat_phase2_no_write_file_cache` | TopN 遅延実体化のフェーズ 2 における検索読み取りは、キャッシュミス時にリモートのみを読み、File Cache に格納しません | 再利用率の低い TopN の検索読み取りによるキャッシュ汚染を防ぐ |
+
+### キャッシュ占有率による制限
+
+> この機能はバージョン 4.0.3 以降でサポートされます。
+
+キャッシュ占有率による制限では、単一クエリが各 File Cache インスタンスで使用できる最大割合を制御します。複数ユーザーや複雑なクエリがキャッシュを共有する場合、ある大規模クエリがキャッシュを大量に占有し、他の使用頻度の高いデータをエビクトするリスクを減らします。
+
+この機能には、BE 設定、FE 設定、セッション変数という三つの設定レベルがあります。
+
+**BE 設定**
+
+| パラメータ | 型 | デフォルト値 | 説明 |
+|---|---|---|---|
+| `enable_file_cache_query_limit` | Boolean | `false` | BE 側のクエリ単位のキャッシュ制限を有効にするマスタースイッチです。有効な場合にのみ、BE は FE から渡されたクエリ制限パラメータを処理します |
+
+**FE 設定**
+
+| パラメータ | 型 | デフォルト値 | 説明 |
+|---|---|---|---|
+| `file_cache_query_limit_max_percent` | Integer | `100` | クエリクォータの最大制約値です。セッション変数の上限を検証するために使用します |
+
+**セッション変数**
+
+| 変数 | 型 | デフォルト値 | 説明 |
+|---|---|---|---|
+| `file_cache_query_limit_percent` | Integer | `-1` | 明示的に設定する場合、値は `[1, file_cache_query_limit_max_percent]` の範囲にする必要があります。単一クエリが使用できるキャッシュの最大割合を指定します。計算されたクォータが 256 MB 未満の場合、BE はログに警告を記録します |
+
+この制御を使用する前に、BE で `enable_file_cache` と `enable_file_cache_query_limit` の両方を有効にし、クエリのセッションで `enable_file_cache` が `true` であることを確認してください。
+
+**使用例**
+
+```sql
+-- Limit a single query to using at most 50% of the cache
+SET file_cache_query_limit_percent = 50;
+
+-- Execute the query
+SELECT * FROM large_table;
+```
+
+以降のキャッシュミスでも、File Cache への書き込みは可能です。クエリのキャッシュ占有量がクォータを超えると、BE はクエリ単位の LRU レコードと他のキャッシュキューを通じて領域を解放します。この制御によって、クエリが以降の書き込みを一切行わないモードに切り替わることはありません。
+
+### バイト数のしきい値によるリモートスキャンのキャッシュ書き込みの停止
+
+> この機能は Doris 4.1.x でのみサポートされます。Doris 4.0.x ではサポートされません。
+
+`file_cache_query_limit_bytes` は、単一の SELECT クエリについて、リモートスキャン時のキャッシュミスをきっかけに読み取りを通じて File Cache に書き込む際、**各 BE** で受け入れるバイト数の累計を制限します。BE で `enable_file_cache=true` のコンピュートとストレージを分離したモードでのみ有効です。`enable_file_cache_query_limit` や `file_cache_query_limit_max_percent` には依存しません。
+
+同じクエリの並列スキャナーは単一の BE 上で同じしきい値を共有しますが、クエリ全体やクラスタ全体の合計値ではありません。たとえば、10 台の BE で 1 GiB のしきい値を設定してクエリを実行すると、各 BE はそれぞれ約 1 GiB を受け入れることができ、全 BE の合計が 1 GiB に制限されるわけではありません。
+
+**パラメータ**
+
+| パラメータ | 設定場所 | 型 | デフォルト値 | 必須 | 説明 |
+|---|---|---|---|---|---|
+| `file_cache_query_limit_bytes` | セッション変数 | BigInt | `-1` | はい | 単一のクエリについて各 BE に適用する、リモートスキャンによるキャッシュ格納のしきい値（バイト）です。`0` 未満は制御を無効にし、`0` はクエリ開始時からキャッシュへの格納を無効にします。正の値の場合、受け入れたバイト数をキャッシュブロック単位で累計します |
+| `enable_file_cache_query_limit_segment_meta` | BE 設定 | Boolean | `false` | いいえ | Segment フッターと Segment メタデータのキャッシュ書き込みを同じバイト数のしきい値に算入するかどうかを指定します。動的に設定できます。この制御が有効な場合、データページと転置インデックスの書き込みには常にバイト数のしきい値が適用されます |
+
+`file_cache_query_limit_bytes` の値による動作は次のとおりです。
+
+| 値 | 動作 |
+|---|---|
+| `< 0` | この制御を無効にし、キャッシュミス時の従来のキャッシュ格納動作を維持します |
+| `= 0` | 開始時からすべての BE 上でクエリをキャッシュミス時にリモートのみを読むモードにします。要求範囲の全体がローカルキャッシュにある場合はローカルから読み取れます。全体がキャッシュにない範囲は、キャッシュに格納せずリモートストレージから直接読み取ります |
+| `> 0` | 受け入れ済みバイト数の累計がしきい値を超えない間、キャッシュブロックを受け入れます。次のブロックで超過する場合はそのブロックを拒否し、以降、その BE 上のクエリによるキャッシュミスではキャッシュに格納しません |
+
+受け入れ可否はキャッシュブロック単位で判定されるため、実際の書き込み量がしきい値と一致するとは限りません。残りの容量が次のキャッシュブロックより小さい場合、ブロック全体がスキップされ、残りの容量が後続の小さなブロックに使われることもありません。BE 上でクエリがキャッシュミス時にリモートのみを読むモードに移行すると、その BE でキャッシュへの格納は再開されません。
+
+**リモートスキャンによるキャッシュ格納の制限**
+
+次の例は、`large_table` がコンピュートとストレージを分離したクラスタにあり、すべての BE で File Cache が有効であることを前提とします。各 BE で、リモートスキャンによる最大 1 GiB のキャッシュブロックの受け入れを許可します。
+
+```sql
+SET enable_profile = true;
+SET profile_level = 2;
+SET file_cache_query_limit_bytes = 1073741824;
+
+SELECT COUNT(*) FROM large_table;
+```
+
+クエリの結果は変わりません。BE 上で次のキャッシュブロックを受け入れると累計が 1 GiB を超える場合、同じ BE 上のそのクエリによる以降のキャッシュミスでは、ローカルキャッシュに追加で書き込まずリモートデータを読み取ります。
+
+一度だけ実行するスキャンが開始時から File Cache を満たさないようにするには、しきい値を `0` に設定し、クエリ後にデフォルト値へ戻します。
+
+```sql
+SET file_cache_query_limit_bytes = 0;
+SELECT COUNT(*) FROM large_table;
+
+SET file_cache_query_limit_bytes = -1;
+```
+
+**Segment メタデータを算入するかどうか**
+
+デフォルトでは、データページと転置インデックスのキャッシュ書き込みはしきい値に算入されますが、Segment フッターと Segment メタデータの書き込みは算入されません。そのため、クエリがキャッシュミス時にリモートのみを読むモードに移行した後も、Segment フッターとメタデータが書き込まれる場合があり、Profile に表示される総書き込み量が `file_cache_query_limit_bytes` を超えることがあります。
+
+Segment フッターとメタデータの格納も停止するには、同じコンピュートグループ内のすべての BE で次のように設定します。
+
+```properties
+enable_file_cache_query_limit_segment_meta=true
+```
+
+このパラメータは、BE の動的設定 API を使ってすぐに変更できます。再起動後も維持するには、`be.conf` に追加するか、永続的な動的設定を使用します。詳細は [BE の設定](../../admin-manual/config/be-config.md)を参照してください。
+
+**Query Profile による確認**
+
+Query Profile を有効にした後、Scanner の下にある `FileCache` メトリクスグループを確認します。
+
+| メトリクス | 説明 |
+|---|---|
+| `RemoteOnlyOnMissTriggered` | 値が `1` の場合、Scanner がクエリのキャッシュミス時にリモートのみを読むモードへの移行を検出したことを示します |
+| `RemoteOnlyOnMissThresholdBytes` | クエリに設定されたバイト数のしきい値 |
+| `BytesWriteIntoCache` | File Cache に実際に書き込まれた総バイト数 |
+| `InvertedIndexBytesWriteIntoCache` | File Cache に実際に書き込まれた転置インデックスのバイト数 |
+| `SegmentFooterIndexBytesWriteIntoCache` | File Cache に実際に書き込まれた Segment フッターとメタデータのバイト数 |
+| `NumSkipCacheIOTotal` | キャッシュを経由しなかった I/O 操作の回数。このメトリクスには他のキャッシュポリシーによってスキップされた I/O も含まれる場合があるため、`RemoteOnlyOnMissTriggered` と併せて評価してください |
+
+受け入れ済みバイト数がしきい値とちょうど一致し、クエリ完了前にしきい値を超える次のキャッシュブロックの試行がない場合、`RemoteOnlyOnMissTriggered` は `0` のままになることがあります。状態が変わるのは、後続のブロックがしきい値を超えようとしたときだけです。
+
+**推奨事項と注意点**
+
+- 一度だけの全件スキャン、再利用率の低い ETL、アドホッククエリでは、小さな正のしきい値を使用するか、`0` を指定して開始時からキャッシュへの格納を無効にし、使用頻度の高いデータが再利用率の低いデータに置き換わるのを防ぎます。
+- このパラメータは、クエリ読み取り時のキャッシュミス後に File Cache に格納する量を制限します。リモートから読み取るバイト数は制限せず、クエリを終了させることも、データ取り込み、Compaction、Schema Change、明示的なキャッシュのウォームアップによるキャッシュ書き込みに影響することもありません。
+- キャッシュミス時にリモートのみを読むモードでも、要求範囲の全体がローカルキャッシュにあればローカルから読み取れます。全体がキャッシュにない範囲はリモートストレージに直接アクセスするため、オブジェクトストレージの I/O とクエリの遅延が増える場合があります。
+- 以降のキャッシュミスでもキャッシュへの格納を許可しつつ、クエリが保持するキャッシュ占有量を制限するには、`file_cache_query_limit_percent` を使用します。指定量を受け入れた後に格納を停止するには、`file_cache_query_limit_bytes` を使用します。
+- デフォルトで Segment フッターとメタデータを対象外にすると、再利用率の高いメタデータをキャッシュする利点を維持できます。しきい値到達後にこれらの書き込みも停止する必要がある場合に限り、`enable_file_cache_query_limit_segment_meta` を有効にし、Query Profile で結果を確認してください。
+
+### TopN 遅延実体化のフェーズ 2 でキャッシュ書き込みを停止する
+
+> この機能はバージョン 4.0.8 以降でサポートされます。
+
+`ORDER BY ... LIMIT` を含むクエリでは、TopN 遅延実体化を使用します。フェーズ 1 では候補行を選ぶためにソート列のみを読み取り、フェーズ 2 では行 ID を使って残りの列を取得します。フェーズ 2 の読み取りは散発的で再利用されることが少ないため、コンピュートとストレージを分離したモードで File Cache に格納すると、使用頻度の高いデータを容易に押し出してしまいます。
+
+| 変数 | 型 | デフォルト値 | 説明 |
+|---|---|---|---|
+| `enable_topn_lazy_mat_phase2_no_write_file_cache` | Boolean | `false` | 有効にすると、TopN 遅延実体化のフェーズ 2 の読み取りでは、File Cache のミス時にリモートストレージから直接読み取り、その範囲を File Cache に格納しません |
+
+**使用例**
+
+```sql
+SET enable_topn_lazy_mat_phase2_no_write_file_cache = true;
+
+SELECT * FROM large_table ORDER BY create_time DESC LIMIT 100;
+```
+
+**注意事項**
+
+- この変数はコンピュートとストレージを分離したモードでのみ有効です。コンピュートとストレージを統合したモードで設定しても効果はありません。
+- TopN 遅延実体化のフェーズ 2 の検索読み取りにのみ影響します。フェーズ 1 でのソート列の読み取り、他のクエリによるキャッシュへの格納、データ取り込み、Compaction、キャッシュのウォームアップによる書き込みには影響しません。
+- フェーズ 2 で File Cache に見つかった範囲は引き続きローカルから読み取ります。キャッシュにない範囲はリモートストレージに直接アクセスするため、オブジェクトストレージの I/O が増える場合があります。
+- TopN クエリが同じ使用頻度の高い行を繰り返し参照する場合、キャッシュへの格納を無効にするとリモート読み取りが増える可能性があります。クエリの傾向に基づいて評価してください。
+
+## キャッシュのウォームアップ
+
+<!-- Knowledge type: Operational steps -->
+<!-- Applicable scenarios: New compute group going online / Fast loading of hot data -->
+
+Doris のキャッシュウォームアップ機能を使うと、リモートストレージからローカルキャッシュにデータを事前に取り込めます。次の三つのウォームアップ方法がサポートされます。
+
+| 方法 | 説明 |
+|---|---|
+| コンピュートグループ間のウォームアップ | コンピュートグループ A で使用頻度の高いデータのキャッシュを、コンピュートグループ B にウォームアップします。Doris は各コンピュートグループのテーブル／パーティションへのアクセスが集中する箇所を定期的に収集し、その情報に基づいて選択的にウォームアップします |
+| テーブルデータのウォームアップ | 指定したテーブルの全データを対象コンピュートグループに取り込みます |
+| パーティションデータのウォームアップ | 指定したテーブルの特定のパーティションのデータを対象コンピュートグループに取り込みます |
+
+詳しい使い方は、[WARM-UP SQL のドキュメント](../../sql-manual/sql-statements/cluster-management/storage-management/WARM-UP.md)を参照してください。
+
+キャッシュのウォームアップは、リモートストレージから事前にデータを取り込みます。[ピアキャッシュ読み取り](./file-cache-peer-read)は、クエリ実行時にこれを補完します。ローカルキャッシュにないブロックは、まず別の BE から読み取り、どの BE にもない場合にのみリモートストレージから読み取ります。これにより、ウォームアップで取り込まれなかったデータの初回読み取りにも対応できます。
+
+## キャッシュのクリア
+
+<!-- Knowledge type: Operational steps -->
+<!-- Applicable scenarios: Insufficient cache space / Test environment reset / Troubleshooting -->
+
+Doris は、同期と非同期の両方のキャッシュクリア方法を提供します。
+
+| 方法 | コマンド | 説明 |
+|---|---|---|
+| 同期クリア | `curl 'http://BE_IP:WEB_PORT/api/file_cache?op=clear&sync=true'` | クリアの完了後にコマンドが返ります。Doris はローカルファイルシステムのキャッシュファイルを同期的に削除し、メモリ内のメタデータをクリアします。領域をすばやく解放できますが、実行中のクエリに影響する可能性があります。通常は迅速なテストに使用します |
+| 非同期クリア | `curl 'http://BE_IP:WEB_PORT/api/file_cache?op=clear&sync=false'` | コマンドは直ちに返ります。クリア処理は非同期に実行され、キャッシュ領域が徐々に減る様子を確認できます。Doris はメモリ内のメタデータを走査してキャッシュファイルを順に削除し、使用中のファイルの削除を後回しにします。実行中のクエリへの影響は小さくなりますが、完全なクリアにはより長い時間がかかります |
+
+## キャッシュの監視
+
+<!-- Knowledge type: Operational steps -->
+<!-- Applicable scenarios: Cache hit rate analysis / Troubleshooting / Performance tuning -->
+
+### キャッシュブロックの詳細
+
+Doris 4.1 以降では、[`information_schema.file_cache_info`](../../admin-manual/system-tables/information_schema/file_cache_info.md) をクエリして、ブロック単位のキャッシュエントリを確認し、tablet、BE、キャッシュパス、キャッシュ種別ごとのキャッシュ領域を集計できます。Doris 4.0.x はこのシステムテーブルをサポートしていません。
+
+### ホットスポット情報
+
+Doris は、コンピュートグループごとのキャッシュホットスポット情報を 10 分ごとに収集し、内部システムテーブル `__internal_schema.cloud_cache_hotspot` に書き込みます。次のクエリで使用頻度の高いデータを分析し、キャッシュ計画に役立てられます。
+
+:::info 注記
+バージョン 3.0.4 より前は、`SHOW CACHE HOTSPOT` 文でキャッシュホットスポット情報を照会できました。バージョン 3.0.4 以降、この文はサポートされていません。代わりにシステムテーブル `__internal_schema.cloud_cache_hotspot` を直接クエリしてください。
+:::
+
+#### すべてのコンピュートグループで最も頻繁にアクセスされるテーブルを表示する
+
+```sql
+-- Equivalent to SHOW CACHE HOTSPOT "/" before version 3.0.4
+WITH t1 AS (
+ SELECT
+ cluster_id,
+ cluster_name,
+ table_id,
+ table_name,
+ insert_day,
+ SUM(query_per_day) AS query_per_day_total,
+ SUM(query_per_week) AS query_per_week_total
+ FROM __internal_schema.cloud_cache_hotspot
+ GROUP BY cluster_id, cluster_name, table_id, table_name, insert_day
+)
+SELECT
+ cluster_id AS ComputeGroupId,
+ cluster_name AS ComputeGroupName,
+ table_id AS TableId,
+ table_name AS TableName
+FROM (
+ SELECT
+ ROW_NUMBER() OVER (
+ PARTITION BY cluster_id
+ ORDER BY insert_day DESC, query_per_day_total DESC, query_per_week_total DESC
+ ) AS dr2,
+ *
+ FROM t1
+) t2
+WHERE dr2 = 1;
+```
+
+#### 特定のコンピュートグループで最も頻繁にアクセスされるテーブルを表示する
+
+`cluster_name = "compute_group_name0"` を実際のコンピュートグループ名に置き換えてください。
+
+```sql
+-- Equivalent to SHOW CACHE HOTSPOT '/compute_group_name0' before version 3.0.4
+WITH t1 AS (
+ SELECT
+ cluster_id,
+ cluster_name,
+ table_id,
+ table_name,
+ insert_day,
+ SUM(query_per_day) AS query_per_day_total,
+ SUM(query_per_week) AS query_per_week_total
+ FROM __internal_schema.cloud_cache_hotspot
+ WHERE cluster_name = "compute_group_name0" -- Replace with the actual compute group name, e.g. "default_compute_group"
+ GROUP BY cluster_id, cluster_name, table_id, table_name, insert_day
+)
+SELECT
+ cluster_id AS ComputeGroupId,
+ cluster_name AS ComputeGroupName,
+ table_id AS TableId,
+ table_name AS TableName
+FROM (
+ SELECT
+ ROW_NUMBER() OVER (
+ PARTITION BY cluster_id
+ ORDER BY insert_day DESC, query_per_day_total DESC, query_per_week_total DESC
+ ) AS dr2,
+ *
+ FROM t1
+) t2
+WHERE dr2 = 1;
+```
+
+### キャッシュ領域とヒット率のメトリクス
+
+<!-- Knowledge type: Configuration parameters -->
+
+BE ノードのキャッシュ統計を取得するには、次のエンドポイントを使用します（`brpc_port` のデフォルト値は 8060）。
+
+```bash
+curl {be_ip}:{brpc_port}/vars
+```
+
+返されるメトリクス名の先頭にはディスクパスが付いています。たとえば、接頭辞 `_mnt_disk1_gavinchou_debug_doris_cloud_be0_storage_file_cache_` はパス `/mnt/disk1/gavinchou/debug/doris-cloud/be0_storage_file_cache/` に対応します。パスの接頭辞を除いた各メトリクスの意味は次のとおりです（サイズの単位はすべてバイト）。
+
+| メトリクス名（パスの接頭辞を除く） | 説明 |
+|---|---|
+| `file_cache_cache_size` | ファイルキャッシュの現在の総サイズ |
+| `file_cache_disposable_queue_cache_size` | Disposable キューの現在のサイズ |
+| `file_cache_disposable_queue_element_count` | Disposable キューの現在の要素数 |
+| `file_cache_disposable_queue_evict_size` | 起動後に Disposable キューからエビクトされたデータの累計量 |
+| `file_cache_index_queue_cache_size` | Index キューの現在のサイズ |
+| `file_cache_index_queue_element_count` | Index キューの現在の要素数 |
+| `file_cache_index_queue_evict_size` | 起動後に Index キューからエビクトされたデータの累計量 |
+| `file_cache_normal_queue_cache_size` | Normal キューの現在のサイズ |
+| `file_cache_normal_queue_element_count` | Normal キューの現在の要素数 |
+| `file_cache_normal_queue_evict_size` | 起動後に Normal キューからエビクトされたデータの累計量 |
+| `file_cache_total_evict_size` | 起動後にファイルキャッシュ全体からエビクトされたデータの累計量 |
+| `file_cache_ttl_cache_evict_size` | 起動後に TTL キューからエビクトされたデータの累計量 |
+| `file_cache_ttl_cache_lru_queue_element_count` | TTL キューの現在の要素数 |
+| `file_cache_ttl_cache_size` | TTL キューの現在のサイズ |
+| `file_cache_evict_by_heat_[A]_to_[B]` | B 型のキャッシュデータ用に領域を空けるためにエビクトされた A 型のキャッシュデータ量（有効期限に基づくエビクション） |
+| `file_cache_evict_by_size_[A]_to_[B]` | B 型のキャッシュデータ用に領域を空けるためにエビクトされた A 型のキャッシュデータ量（領域に基づくエビクション） |
+| `file_cache_evict_by_self_lru_[A]` | 新しいデータを書き込むために A 型のキューが自身からエビクトした A 型のキャッシュデータ量（LRU に基づくエビクション） |
+
+### SQL Profile のキャッシュメトリクス
+
+SQL Profile のキャッシュ関連メトリクスは、`SegmentIterator` ノードの下にあります。
+
+| メトリクス名 | 説明 |
+|---|---|
+| `BytesScannedFromCache` | ファイルキャッシュから読み取ったデータ量 |
+| `BytesScannedFromRemote` | リモートストレージから読み取ったデータ量 |
+| `BytesWriteIntoCache` | ファイルキャッシュに書き込んだデータ量 |
+| `LocalIOUseTimer` | ファイルキャッシュからの読み取りに費やした時間 |
+| `NumLocalIOTotal` | ファイルキャッシュからの読み取り回数 |
+| `NumRemoteIOTotal` | リモートストレージからの読み取り回数 |
+| `NumSkipCacheIOTotal` | ファイルキャッシュに書き込まれなかったリモートストレージからの読み取り回数 |
+| `RemoteIOUseTimer` | リモートストレージからの読み取りに費やした時間 |
+| `WriteCacheIOUseTimer` | ファイルキャッシュへの書き込みに費やした時間 |
+
+インデックスのみのキャッシュ書き込みを有効にした後は、次の分類別メトリクスを監視し、独立した転置インデックスと Segment フッター／内部インデックスのデータがキャッシュにヒットしているかどうかを確認します。
+
+| メトリクス | 説明 |
+|---|---|
+| `InvertedIndexBytesScannedFromCache` / `InvertedIndexBytesScannedFromRemote` | File Cache／リモートストレージから読み取った、独立した転置インデックスのデータ量 |
+| `InvertedIndexNumLocalIOTotal` / `InvertedIndexNumRemoteIOTotal` | 独立した転置インデックスのローカル／リモート読み取り回数 |
+| `InvertedIndexLocalIOUseTimer` / `InvertedIndexRemoteIOUseTimer` | 独立した転置インデックスのローカル／リモート読み取りに費やした時間 |
+| `SegmentFooterIndexBytesScannedFromCache` / `SegmentFooterIndexBytesScannedFromRemote` | File Cache／リモートストレージから読み取った Segment フッターと内部インデックスのデータ量 |
+| `SegmentFooterIndexNumLocalIOTotal` / `SegmentFooterIndexNumRemoteIOTotal` | Segment フッターと内部インデックスのローカル／リモート読み取り回数 |
+| `SegmentFooterIndexLocalIOUseTimer` / `SegmentFooterIndexRemoteIOUseTimer` | Segment フッターと内部インデックスのローカル／リモート読み取りに費やした時間 |
+
+クエリ性能のレポート全体は、[クエリ性能の分析](../../query-acceleration/performance-tuning-overview/analysis-tools#doris-profile)で確認できます。
+
+`NumPeerIOTotal`、`PeerIOUseTimer`、`SameCGPeerIOTotal`、`CrossCGPeerIOTotal` および関連するカウンターは、データを別の BE のキャッシュから取得したかどうか（ピアキャッシュ読み取り）を示します。[ピアキャッシュ読み取り：Query Profile のカウンター](./file-cache-peer-read#query-profile-counters)を参照してください。
+
+## TTL キャッシュポリシー
+
+<!-- Knowledge type: Operational steps -->
+<!-- Applicable scenarios: Keeping hot tables resident in cache / Preventing large queries from evicting hot data -->
+
+TTL（Time-To-Live）キャッシュポリシーでは、特定のテーブルに属するデータのキャッシュ保持期間を設定できます。これにより、小さな使用頻度の高いテーブルや最近取り込まれたデータを十分な期間キャッシュに保持し、大規模クエリによって発生する LRU エビクションで置き換えられるのを防げます。
+
+### テーブル作成時に TTL を設定する
+
+`file_cache_ttl_seconds`（秒単位）を `PROPERTIES` 句で指定して `CREATE TABLE` を実行します。
+
+```sql
+CREATE TABLE IF NOT EXISTS customer (
+ C_CUSTKEY INTEGER NOT NULL,
+ C_NAME VARCHAR(25) NOT NULL,
+ C_ADDRESS VARCHAR(40) NOT NULL,
+ C_NATIONKEY INTEGER NOT NULL,
+ C_PHONE CHAR(15) NOT NULL,
+ C_ACCTBAL DECIMAL(15,2) NOT NULL,
+ C_MKTSEGMENT CHAR(10) NOT NULL,
+ C_COMMENT VARCHAR(117) NOT NULL
+)
+DUPLICATE KEY(C_CUSTKEY, C_NAME)
+DISTRIBUTED BY HASH(C_CUSTKEY) BUCKETS 32
+PROPERTIES (
+ "file_cache_ttl_seconds" = "300"
+);
+```
+
+上記のテーブルに新しく取り込まれたデータはすべて、300 秒間キャッシュに保持されます。
+
+`file_cache_ttl_seconds` の有効範囲は `0 <= value <= 4611686018427387903`（つまり `Long.MAX_VALUE / 2`）です。バージョン 4.1.4 以降、`CREATE TABLE` と `ALTER TABLE ... SET` の両方でこの値が検証され、範囲外の値や形式が不正な値は次のエラーで拒否されます。
+
+```text
+The value <v> formats error or is out of range (0 <= integer <= 4611686018427387903). Larger values may overflow in BE and change TTL cache to normal cache; please use 4611686018427387903 or a smaller value.
+```
+
+4.1.4 より前は上限が検証されず、大きすぎる値は BE 側でオーバーフローして、TTL キャッシュが通常のキャッシュに変わっていました。
+
+### テーブルの TTL 設定を変更する
+
+```sql
+ALTER TABLE customer SET ("file_cache_ttl_seconds" = "3000");
+```
+
+:::info 注記
+更新した TTL 値はすぐには反映されず、少し時間がかかります。テーブル作成時に TTL を設定していない場合も、後から `ALTER TABLE` 文で追加できます。
+:::
+
+## 実用例
+
+<!-- Knowledge type: Operational steps -->
+<!-- Applicable scenarios: Mixed large-and-small table scenarios / TTL policy tuning -->
+
+**シナリオ：**
+
+あるユーザーは、合計データ量が 3 TB を超える複数のデータテーブルを持っていますが、使用可能なキャッシュ容量は 1.2 TB しかありません。そのうち、次の二つのテーブルに頻繁にアクセスします。
+
+| テーブル | サイズ | アクセスパターン |
+|---|---|---|
+| `dimension_table` | 200 MB | 頻繁にアクセスされ、データの変更は少ない |
+| `fact_table` | 100 GB | 新しいデータを毎日取り込み、T+1 の基準でクエリできる必要がある |
+
+その他の大きなテーブルへのアクセス頻度は低い状態です。
+
+**問題：** デフォルトの LRU ポリシーでは、大きなテーブルをクエリすると `dimension_table` のデータがキャッシュからエビクトされ、ディメンションテーブルのクエリ性能が変動する可能性があります。
+
+**解決策：** 頻繁にアクセスされる両方のテーブルに TTL を設定し、十分な期間データがキャッシュに保持されるようにします。
+
+```sql
+-- Dimension table: small data volume, infrequent changes; set a 1-year TTL to keep it resident in the cache
+ALTER TABLE dimension_table SET ("file_cache_ttl_seconds" = "31536000");
+
+-- Fact table: full load ingested daily; set a 1-day TTL aligned with the ingestion cycle
+ALTER TABLE fact_table SET ("file_cache_ttl_seconds" = "86400");
+```
+
+## よくある質問
+
+<!-- Knowledge type: Troubleshooting -->
+<!-- Applicable scenarios: Low cache hit rate / Cache configuration troubleshooting -->
+
+**Q：キャッシュヒット率が低く、クエリも遅いままです。どのように調査すればよいですか？**
+
+1. `curl {be_ip}:{brpc_port}/vars` を使い、各キューの `evict_size` メトリクスを確認して、頻繁にエビクションが発生しているかどうかを判断します。
+2. SQL Profile で `BytesScannedFromRemote` と `BytesScannedFromCache` の比率を確認し、実際のヒット率を確かめます。
+3. 大規模クエリが使用頻度の高いデータを頻繁にエビクトする場合、**Cache Query Limit** 機能（`enable_file_cache_query_limit`）を有効にするか、使用頻度の高いテーブルに **TTL ポリシー**を設定することを検討します。
+
+**Q：BE を再起動するとキャッシュデータが失われます。**
+
+`clear_file_cache` が `true` に設定されていないか確認してください。再起動時にキャッシュをクリアしたくない場合は、`false`（デフォルト値）に設定します。
+
+**Q：新しいコンピュートグループの稼働開始後、最初のクエリが非常に遅くなります。**
+
+クエリを受け付ける前に、**キャッシュのウォームアップ**機能を使って、使用頻度の高いテーブルまたはパーティションのデータをリモートストレージから新しいコンピュートグループのローカルキャッシュに事前に取り込んでください。詳しい使い方は、[WARM-UP SQL のドキュメント](../../sql-manual/sql-statements/cluster-management/storage-management/WARM-UP.md)を参照してください。別のコンピュートグループがすでにデータをキャッシュしている場合、デフォルトで有効な[ピアキャッシュ読み取り](./file-cache-peer-read)により、キャッシュミス時にそのグループの BE から読み取れます。
+
+**Q：現在のキャッシュ領域が満杯かどうかは、どのように判断できますか？**
+
+`file_cache_cache_size` メトリクスと、`total_size`（`file_cache_path` で設定）の値を比較してください。上限に近づいている場合は、容量の拡張や各キューの割り当て割合の調整が必要かどうかを確認します。
diff --git a/i18n/ja/docusaurus-plugin-content-docs/version-4.x/compute-storage-decoupled/intro.mdx b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/compute-storage-decoupled/intro.mdx
new file mode 100644
index 00000000000..26f144e3bc1
--- /dev/null
+++ b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/compute-storage-decoupled/intro.mdx
@@ -0,0 +1,77 @@
+---
+{
+ "title": "ストレージ・コンピュート分離型の運用ガイド",
+ "language": "ja",
+ "description": "Apache Doris のストレージ・コンピュート分離型アーキテクチャの運用ガイド。コンピュートグループの管理、ストレージボールトの設定、ファイルキャッシュ、読み書き分離、クラスタのアップグレードについて説明します。"
+}
+---
+
+import GettingStartedCard from '@site/src/components/getting-started-card/getting-started-card';
+
+ストレージ・コンピュート分離型アーキテクチャでは、コンピュートノードとリモート共有ストレージを分離し、コンピュートとストレージをそれぞれ独立して柔軟に拡張できます。このガイドでは、ストレージ・コンピュート分離型クラスタの設定と運用について説明します。
+
+## クラスタの運用
+
+<div className="cards-grid">
+<GettingStartedCard
+ title="コンピュートグループの運用"
+ description="1 つ以上の BE ノードをまとめてコンピュートグループを構成します。ストレージ・コンピュート分離モードで、コンピュートグループを作成、拡張、管理する方法を説明します。"
+ link="managing-compute-cluster"
+/>
+
+<GettingStartedCard
+ title="ストレージボールトの管理"
+ description="ストレージ・コンピュート分離モードで使用するリモート共有ストレージ（Storage Vault）を設定します。複数のストレージボールトの設定と、テーブルごとの保存先の指定に対応しています。"
+ link="managing-storage-vault"
+/>
+
+<GettingStartedCard
+ title="データの回収"
+ description="ストレージ・コンピュート分離型アーキテクチャで、Doris が削除済みデータの占めるストレージ領域を安全かつ効率的に回収する仕組みと、データのライフサイクルの管理方法を説明します。"
+ link="recycler"
+/>
+
+<GettingStartedCard
+ title="アップグレード"
+ description="上流のワークロードへの影響を最小限に抑えながら、ローリングアップグレードでストレージ・コンピュート分離モードの Doris クラスタをアップグレードする手順を説明します。"
+ link="upgrade"
+/>
+</div>
+
+## ファイルキャッシュ
+
+<div className="cards-grid">
+<GettingStartedCard
+ title="ファイルキャッシュの概要"
+ description="ローカルディスクのキャッシュでリモートストレージへのアクセスを高速化します。複数キューによる LRU 戦略、新しいコンピュートグループのキャッシュのウォームアップ、設定の詳細を説明します。"
+ link="file-cache/file-cache"
+/>
+
+<GettingStartedCard
+ title="ファイルキャッシュの内部構造"
+ description="ファイルキャッシュの実装を詳しく説明します。1 MB 境界に合わせた分割、プリフェッチの仕組み、ローカルファイルシステム上のブロックファイル管理を扱います。"
+ link="file-cache/file-cache-internals"
+/>
+
+<GettingStartedCard
+ title="ピアキャッシュからの読み取り"
+ description="ローカルの File Cache でミスした場合、オブジェクトストレージにフォールバックする前に、別の BE（他のコンピュートグループを含む）からブロックを読み取ります。スケールアウト時やグループ間でのコールドリードを高速化します。"
+ link="file-cache/file-cache-peer-read"
+/>
+</div>
+
+## 読み書き分離
+
+<div className="cards-grid">
+<GettingStartedCard
+ title="読み書き分離"
+ description="File Cache の能動的な増分ウォームアップ機構により、アベイラビリティゾーンをまたぐ高可用性構成と読み書き分離構成に対応します。クエリのレイテンシーを短縮し、フェイルオーバー時の応答を高速化します。"
+ link="rw/read-write-separation"
+/>
+
+<GettingStartedCard
+ title="読み書き分離におけるキャッシュ最適化のベストプラクティス"
+ description="複数のコンピュートグループを使う読み書き分離構成でキャッシュヒット率を最適化し、読み取り専用コンピュートグループがリモートオブジェクトストレージから頻繁にデータを取得するのを防ぐことで、クエリ性能を高めます。"
+ link="rw/file-cache-rw-compute-group-best-practice"
+/>
+</div>
diff --git a/i18n/ja/docusaurus-plugin-content-docs/version-4.x/compute-storage-decoupled/managing-compute-cluster.md b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/compute-storage-decoupled/managing-compute-cluster.md
new file mode 100644
index 00000000000..5bf67d71b8d
--- /dev/null
+++ b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/compute-storage-decoupled/managing-compute-cluster.md
@@ -0,0 +1,319 @@
+---
+{
+ "title": "コンピュートグループの管理：作成、権限付与、切り替え、スケーリングの操作ガイド",
+ "sidebar_label": "コンピュートグループの管理",
+ "language": "ja",
+ "description": "ストレージとコンピュートの分離アーキテクチャにおけるコンピュートグループの管理操作を説明します。作成、権限付与、デフォルトグループの設定、切り替え、スケーリングを扱います。",
+ "keywords": ["コンピュートグループ", "Compute Group", "ストレージとコンピュートの分離", "コンピュートグループの権限付与", "コンピュートグループのスケーリング", "読み書きの分離", "負荷分散"]
+}
+---
+
+<!-- Knowledge type: Operational steps -->
+<!-- Applicable scenarios: Cluster management / Resource isolation / Load distribution -->
+
+ストレージとコンピュートの分離アーキテクチャでは、一つ以上のコンピュートノード（BE）を **コンピュートグループ** にまとめることができます。このドキュメントでは、コンピュートグループの表示、追加、権限付与、デフォルトグループの設定、切り替え、スケーリングを含む一連の管理操作を説明します。
+
+:::note バージョンに関する注意
+3.0.2 より前のバージョンでは、コンピュートグループを **コンピュートクラスター** と呼んでいました。
+:::
+
+## コンピュートグループのユースケース
+
+<!-- Knowledge type: Architecture selection decision -->
+<!-- Applicable scenarios: Multi-tenant isolation / Read-write separation / Load isolation -->
+
+複数のコンピュートグループを使用する構成では、`USE @<compute_group_name>` ステートメントで特定のワークロードを指定したコンピュートグループに振り分け、異なる種類のワークロード間で物理的な分離を実現できます。
+
+以下のシナリオでは、C1 と C2 という二つのコンピュートグループを想定します。
+
+| シナリオ | 説明 | 操作方法 |
+| :--- | :--- | :--- |
+| **読み取り同士の分離** | 二つの大規模なクエリを別々のコンピュートノードで実行し、CPU やメモリのリソース競合を回避します | クエリ 1 では `USE @c1`、クエリ 2 では `USE @c2` を使用します |
+| **読み書きの分離** | データ取り込みとクエリの間のリソース競合を回避します。C1 は C2 で新たに取り込んだデータにアクセスできます | クエリでは `USE @c1`、データ取り込みでは `USE @c2` を使用します |
+| **書き込み同士の分離** | 高頻度の小規模なデータ取り込みと大規模なバッチ取り込みを分けて実行し、相互の干渉を回避します | 小規模なデータ取り込みでは `USE @c1`、バッチ取り込みでは `USE @c2` を使用します |
+
+:::caution 注意
+
+上記の分離は、CPU やメモリなどのコンピュートリソースを対象とします。[ピアキャッシュ読み取り](./file-cache/file-cache-peer-read)はデフォルトで有効です。そのため、あるコンピュートグループのクエリでローカルキャッシュミスが発生すると、別のコンピュートグループの BE の File Cache を読み取る場合があります。グループ間のキャッシュ充填を設定している場合は、そのグループに代わってオブジェクトストレージからデータを取得させることもあります。これにより、コンピュートグループ間のネットワーク、ディスク、キャッシュの分離は弱まります。厳密な分離が必要な場合は、BE でピアキャッシュ読み取りを無効にしてください。
+
+:::
+
+## デフォルトコンピュートグループの選択方法
+
+<!-- Knowledge type: System behavior description -->
+
+ユーザーが[デフォルトコンピュートグループを明示的に設定](#set-the-default-compute-group)していない場合、システムは次の条件を満たすコンピュートグループを自動的に選択します。
+
+- コンピュートグループに稼働中のコンピュートノードが一つ以上あること。
+- 現在のユーザーがそのコンピュートグループに対する USAGE_PRIV 権限を持っていること。
+
+同じセッション内では、ユーザーが明示的に変更しない限り、デフォルトコンピュートグループは変わりません。セッションをまたぐと、次のいずれかの条件が発生した場合に、システムがデフォルトコンピュートグループを自動的に切り替えることがあります。
+
+| 発生条件 | 必ず切り替わるか |
+| :--- | :---: |
+| ユーザーが、以前選択されたコンピュートグループの USAGE_PRIV 権限を失った場合 | はい |
+| コンピュートグループが追加または削除された場合 | はい |
+| 以前選択されたコンピュートグループに稼働中のコンピュートノードがなくなった場合 | 切り替わる可能性があります |
+
+## すべてのコンピュートグループを表示する
+
+<!-- Knowledge type: Operational steps -->
+
+**目的**：現在のリポジトリ内のすべてのコンピュートグループを表示します。
+
+**コマンド**：
+
+```sql
+SHOW COMPUTE GROUPS;
+```
+
+**説明**：返される結果は、ユーザーの権限レベルによって異なります。
+
+- `ADMIN` 権限を持つユーザーは、すべてのコンピュートグループを表示できます。
+- 一般ユーザーは、自分が `USAGE_PRIV` 権限を持つコンピュートグループのみを表示できます。
+- どのコンピュートグループに対しても USAGE_PRIV 権限を持たないユーザーには、空の結果が返されます。
+
+## コンピュートグループを追加する
+
+<!-- Knowledge type: Operational steps -->
+<!-- Applicable scenarios: Cluster initialization / Adding compute resources -->
+
+**前提条件**：`OPERATOR` 権限（ノード管理権限）が必要です。デフォルトでは、root アカウントのみがこの権限を持ちます。`GRANT` コマンドを使用して、ほかのアカウントにも付与できます。詳細は[権限管理](../sql-manual/sql-statements/account-management/GRANT-TO)を参照してください。
+
+**目的**：BE ノードを追加し、コンピュートグループに割り当てます。
+
+**コマンド（コンピュートグループを指定する場合）**：
+
+```sql
+ALTER SYSTEM ADD BACKEND 'host:9050' PROPERTIES ("tag.compute_group_name" = "new_group");
+```
+
+**コマンド（デフォルトコンピュートグループを使用する場合）**：コンピュートグループを指定しないと、ノードはデフォルトで `default_compute_group` に参加します。
+
+```sql
+ALTER SYSTEM ADD BACKEND 'host:9050';
+```
+
+詳細は [ADD BACKEND SQL リファレンス](../sql-manual/sql-statements/cluster-management/instance-management/ADD-BACKEND)を参照してください。
+
+## コンピュートグループへのアクセス権を付与する
+
+<!-- Knowledge type: Operational steps -->
+<!-- Applicable scenarios: Multi-user permission management -->
+
+**前提条件**：現在のユーザーが `ADMIN` 権限を持つか、admin ロールに属している必要があります。
+
+**目的**：指定したユーザーに、コンピュートグループに対する USAGE_PRIV 権限を付与します。
+
+**コマンド**：
+
+```sql
+GRANT USAGE_PRIV ON COMPUTE GROUP {compute_group_name} TO {user};
+```
+
+## コンピュートグループへのアクセス権を取り消す
+
+<!-- Knowledge type: Operational steps -->
+
+**前提条件**：現在のユーザーが `ADMIN` 権限を持つか、admin ロールに属している必要があります。
+
+**目的**：指定したユーザーから、コンピュートグループに対する USAGE_PRIV 権限を取り消します。
+
+**コマンド**：
+
+```sql
+REVOKE USAGE_PRIV ON COMPUTE GROUP {compute_group_name} FROM {user};
+```
+
+## デフォルトコンピュートグループを設定する {#set-the-default-compute-group}
+
+<!-- Knowledge type: Operational steps -->
+<!-- Applicable scenarios: User-level resource isolation -->
+
+### 現在のユーザーに設定する
+
+**前提条件**：現在のユーザーが、対象のコンピュートグループに対する USAGE_PRIV 権限をすでに持っている必要があります。
+
+```sql
+SET PROPERTY 'default_compute_group' = '{clusterName}';
+```
+
+### 別のユーザーに設定する
+
+**前提条件**：現在のユーザーが Admin 権限を持っている必要があります。
+
+```sql
+SET PROPERTY FOR {user} 'default_compute_group' = '{clusterName}';
+```
+
+### デフォルトコンピュートグループを確認する
+
+現在のユーザーのデフォルトコンピュートグループを確認します。結果に含まれる `default_compute_group` の値が、デフォルトコンピュートグループです。
+
+```sql
+SHOW PROPERTY;
+```
+
+別のユーザーのデフォルトコンピュートグループを確認します（admin 権限が必要です）。
+
+```sql
+SHOW PROPERTY FOR {user};
+```
+
+### 権限について
+
+| ユーザーロール | 操作可能な範囲 |
+| :--- | :--- |
+| 管理者ユーザー（例：`CREATE USER jack IDENTIFIED BY '123456' DEFAULT ROLE "admin"`） | 自分とほかのユーザーのデフォルトコンピュートグループを設定できます。また、自分とほかのユーザーの `PROPERTY` を表示できます |
+| 一般ユーザー（例：`CREATE USER jack1 IDENTIFIED BY '123456'`） | 自分のデフォルトコンピュートグループのみを設定でき、自分の `PROPERTY` のみを表示できます。すべてのコンピュートグループの表示はできません（`GRANT ADMIN` 権限が必要です） |
+
+:::caution 注意
+
+- 現在のユーザーにデフォルトコンピュートグループが設定されていない場合、データの読み取りまたは書き込み操作時にエラーが発生します。`USE @cluster` コマンドで現在のセッションのコンピュートグループを指定するか、`SET PROPERTY` ステートメントでデフォルトコンピュートグループを設定してください。
+- 現在のユーザーにデフォルトコンピュートグループが設定されていても、そのグループが後から削除された場合は、データの読み取りまたは書き込み操作時にエラーが発生します。`USE @cluster` コマンドでコンピュートグループを再指定するか、`SET PROPERTY` でデフォルトコンピュートグループの設定を更新してください。
+
+:::
+
+## コンピュートグループを切り替える
+
+<!-- Knowledge type: Operational steps -->
+
+**目的**：ストレージとコンピュートの分離アーキテクチャで、現在のセッションに使用するデータベースとコンピュートグループを指定します。
+
+**構文**：
+
+```sql
+USE { [catalog_name.]database_name[@compute_group_name] | @compute_group_name }
+```
+
+**説明**：データベース名またはコンピュートグループ名に予約語が含まれる場合は、該当する名前をバッククォート（`` ` ``）で囲みます。
+
+## コンピュートグループをスケーリングする
+
+<!-- Knowledge type: Operational steps -->
+<!-- Applicable scenarios: Elastic scaling / Capacity planning -->
+
+次のコマンドで BE ノードを追加または削除し、コンピュートグループをスケーリングします。
+
+- **スケールアウト**：`ALTER SYSTEM ADD BACKEND`
+- **スケールイン**：`ALTER SYSTEM DECOMMISSION BACKEND`
+
+### スケーリング後の負荷の再分散
+
+Cloud Rebalance は、Doris のストレージとコンピュートの分離アーキテクチャにおける負荷分散の仕組みです。コンピュートグループの BE ノードを増減すると（長時間オフラインのノードはスケールインとみなされます）、システムはクラスター全体の読み取りと書き込みのトラフィック分布を自動的に再調整します。
+
+#### バランス戦略の種類
+
+<!-- Knowledge type: Configuration parameters -->
+
+:::caution 対応バージョン
+
+`balance_type` 機能は **Doris 3.1.3** および **Doris 4.0.2** 以降でサポートされます。それ以前のバージョンでは、リバランス中にウォームアップタスクを実行するかどうかを制御するために、FE のグローバル設定 `enable_cloud_warm_up_for_rebalance` のみを使用できました。
+
+:::
+
+次の表では、スケールアウト時を例に四種類の戦略を説明します。
+
+| 戦略の種類 | 新しいノードが利用可能になるまでの時間 | パフォーマンスへの影響 | 技術的な仕組み | 適用シナリオ |
+| :--- | :---: | :---: | :--- | :--- |
+| `without_warmup` | 最短 | 最大 | FE が shard のマッピングを直接更新します。初回の読み取りと書き込みではファイルキャッシュがないため、S3 からデータを取得する必要があります | 新しいノードをすばやく利用可能にする必要があり、パフォーマンスの変動を許容できる場合 |
+| `async_warmup` | 短い | キャッシュミスが発生する可能性があります | ウォームアップタスクを発行し、タスクの成功またはタイムアウト後にマッピングを更新します。マッピングの切り替え時にファイルキャッシュへのデータの取り込みを試みますが、初回の読み取りの一部でキャッシュミスが発生する可能性があります | 一般的な用途で、一定のパフォーマンスへの影響を許容できる場合 |
+| `sync_warmup` | 長い | キャッシュミスはほぼ発生しません | ウォームアップタスクを発行し、完了を確認してから FE がマッピングを変更するため、キャッシュの移行が完了した状態になります | スケーリング後に高いパフォーマンスが必要で、新しいノードのファイルキャッシュを事前に準備する必要がある場合 |
+| `peer_read_async_warmup` | 最短 | 小さい | FE が shard のマッピングを直接変更し、ベストエフォートでウォームアップタスクを発行します。新しいノードでの初回の読み取りは、[ピアキャッシュ読み取り](./file-cache/file-cache-peer-read)を通じて元の BE のファイルキャッシュからデータを取得します。これには、BE で `enable_cache_read_from_peer` を有効（デフォルト）にしておく必要があります | 新しいノードをすばやく利用可能にし、S3 から直接読み取ることを避けたい場合で、元の BE が追加の読み取り負荷に対応できる場合 |
+
+#### 設定
+
+##### グローバルデフォルトのバランス戦略
+
+FE の設定ファイル（`fe.conf`）でグローバルのデフォルト値を設定します。
+
+```
+cloud_warm_up_for_rebalance_type = "async_warmup"
+```
+
+##### コンピュートグループ単位の設定
+
+コンピュートグループごとにバランス戦略を個別に設定できます。
+
+```sql
+ALTER COMPUTE GROUP cg1 PROPERTIES("balance_type"="async_warmup");
+```
+
+##### 設定の優先順位
+
+1. コンピュートグループに `balance_type` が設定されていない場合、グローバルのデフォルト値 `async_warmup` が使用されます。
+2. コンピュートグループに `balance_type` が設定されている場合、リバランスの実行時にはそのグループの設定が優先されます。
+
+## コンピュートグループの名前を変更する
+
+<!-- Knowledge type: Operational steps -->
+
+**目的**：既存のコンピュートグループを新しい名前に変更します。
+
+**コマンド**：
+
+```sql
+ALTER SYSTEM RENAME COMPUTE GROUP <old_name> <new_name>;
+```
+
+:::caution 注意
+
+名前の変更後、元のコンピュートグループ名（`old_name`）に紐付くユーザー権限とデフォルトコンピュートグループの設定は、新しい名前（`new_name`）に**自動では更新されません**。管理者権限を持つアカウントが、権限を手動で再付与する必要があります。この動作は MySQL の権限システムと同じです。
+
+:::
+
+## よくある質問
+
+<!-- Knowledge type: Troubleshooting -->
+<!-- Applicable scenarios: Troubleshooting / Permission issues / Performance tuning -->
+
+### グローバルのリバランス戦略を確認・変更するには？
+
+- **確認**：
+ ```sql
+ ADMIN SHOW FRONTEND CONFIG LIKE "cloud_warm_up_for_rebalance_type";
+ ```
+- **変更**（FE の再起動なしで反映されます）：
+ ```sql
+ ADMIN SET FRONTEND CONFIG ("cloud_warm_up_for_rebalance_type" = "without_warmup");
+ ```
+
+### コンピュートグループのバランス戦略を確認するには？
+
+`SHOW COMPUTE GROUPS;` を実行します。結果の `properties` 列には各コンピュートグループの属性が含まれ、`balance_type` の設定を確認できます。
+
+### クラスターの Tablet の状態が安定しているか確認するには？
+
+**方法 1：`SHOW BACKENDS` で確認する**
+
+BE ノード間の Tablet 数がおおむね均等かどうかを確認します。目安となる範囲は次のとおりです。
+
+```
+(total tablets in cluster / number of BEs in Compute Group) × 0.95
+~
+(total tablets in cluster / number of BEs in Compute Group) × 1.05
+```
+
+ここで、0.05 は FE の設定項目 `cloud_rebalance_percent_threshold` のデフォルト値です。BE ノード間の Tablet 分布をより均等にするには、この設定値を小さくします。
+
+**方法 2：FE のメトリクスで確認する**
+
+FE のメトリクスにある `doris_fe_cloud_.*_balance_num` 系列を確認します。値が長時間変わらない場合、コンピュートグループはバランスの取れた状態に達しています。継続的に監視できるよう、これらのメトリクスを監視ダッシュボードに設定することを推奨します。
+
+```bash
+curl "http://feip:fe_http_port/metrics" | grep '_balance_num'
+```
+
+### データの読み書き中に「No Default Compute Group Configured」エラーが発生した場合は？
+
+次のいずれかの方法で対処します。
+
+1. `USE @cluster` コマンドで、現在のセッションのコンピュートグループを一時的に指定します。
+2. `SET PROPERTY 'default_compute_group' = '{clusterName}'` で、デフォルトコンピュートグループを永続的に設定します。
+
+### デフォルトコンピュートグループの削除後にエラーが発生した場合は？
+
+コンピュートグループが削除されると、そのグループに依存するユーザーの読み書き操作でエラーが発生します。次のいずれかの方法で対処します。
+
+1. `USE @cluster` コマンドで、現在のセッションのコンピュートグループを再指定します。
+2. `SET PROPERTY` で、デフォルトコンピュートグループを別の有効なグループに更新します。
diff --git a/i18n/ja/docusaurus-plugin-content-docs/version-4.x/compute-storage-decoupled/managing-storage-vault.md b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/compute-storage-decoupled/managing-storage-vault.md
new file mode 100644
index 00000000000..5226ea50e57
--- /dev/null
+++ b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/compute-storage-decoupled/managing-storage-vault.md
@@ -0,0 +1,299 @@
+---
+{
+ "title": "Storage Vault の管理：作成、設定、アクセス制御",
+ "sidebar_label": "Storage Vault の管理",
+ "language": "ja",
+ "description": "コンピュートとストレージを分離したモードでの Storage Vault の作成、表示、変更方法、テーブルやデータベースの保存先の指定方法、ユーザーのアクセス権限の管理方法を説明します。",
+ "keywords": ["Storage Vault", "コンピュートとストレージの分離", "オブジェクトストレージ", "HDFS", "S3", "ストレージ管理", "Doris"]
+}
+---
+
+<!-- Knowledge type: Operational steps -->
+<!-- Applicable scenarios: Storage configuration and management for compute-storage decoupled clusters -->
+
+Storage Vault は、コンピュートとストレージを分離したモードで Doris が使用するリモート共有ストレージの抽象化です。一つ以上の Storage Vault を設定し、テーブルごとに異なる Storage Vault にデータを保存することで、ストレージを柔軟に管理できます。
+
+## Storage Vault を作成する
+
+<!-- Knowledge type: Operational steps -->
+
+**構文**
+
+```sql
+CREATE STORAGE VAULT [IF NOT EXISTS] <vault_name>
+PROPERTIES
+("key" = "value", ...)
+```
+
+`<vault_name>` は Storage Vault に付ける任意の名前で、以降の操作で使用する一意の識別子です。
+
+### HDFS Storage Vault を作成する
+
+<!-- Applicable scenarios: Using HDFS as shared storage -->
+
+HDFS ベースの Storage Vault を作成する前に、FE、BE、Meta Service を含むすべてのノードから対象の HDFS にアクセスできることを確認してください。Kerberos 認証の設定と接続確認も行います（各ノードで Hadoop Client を使用してテストできます）。
+
+```sql
+CREATE STORAGE VAULT IF NOT EXISTS hdfs_vault_demo
+PROPERTIES (
+ "type" = "hdfs", -- required
+ "fs.defaultFS" = "hdfs://127.0.0.1:8020", -- required
+ "path_prefix" = "big/data", -- optional, typically filled with the business name
+ "hadoop.username" = "user", -- optional
+ "hadoop.security.authentication" = "kerberos", -- optional
+ "hadoop.kerberos.principal" = "hadoop/127.0.0.1@XXX", -- optional
+ "hadoop.kerberos.keytab" = "/etc/emr.keytab" -- optional
+);
+```
+
+### S3 Storage Vault を作成する
+
+<!-- Applicable scenarios: Using object storage (OSS/S3/COS, etc.) as shared storage -->
+
+```sql
+CREATE STORAGE VAULT IF NOT EXISTS s3_vault_demo
+PROPERTIES (
+ "type" = "S3", -- required
+ "s3.endpoint" = "oss-cn-beijing.aliyuncs.com", -- required
+ "s3.region" = "cn-beijing", -- required
+ "s3.bucket" = "bucket", -- required
+ "s3.root.path" = "big/data/prefix", -- required
+ "s3.access_key" = "ak", -- required
+ "s3.secret_key" = "sk", -- required
+ "provider" = "OSS", -- required
+ "use_path_style" = "false" -- optional
+);
+```
+
+:::caution 必要な権限
+オブジェクトストレージのパスには、`head`、`get`、`list`、`put`、`multipartUpload`、`delete` のアクセス権限が必要です。
+:::
+
+クラウドプロバイダー別の例やパラメータの説明については、[CREATE-STORAGE-VAULT](../sql-manual/sql-statements/cluster-management/storage-management/CREATE-STORAGE-VAULT)を参照してください。
+
+## Storage Vault を表示する
+
+<!-- Knowledge type: Operational steps -->
+
+**構文**
+
+```sql
+SHOW STORAGE VAULTS
+```
+
+結果には次の 4 列が含まれます。
+
+| 列 | 説明 |
+|--------|-------------|
+| Storage Vault Name | ユーザーが定義した Vault の識別子 |
+| Storage Vault ID | システムが割り当てた一意の ID |
+| Properties | Vault の設定プロパティ |
+| IsDefault | デフォルトの Storage Vault かどうか |
+
+## デフォルトの Storage Vault を設定する
+
+<!-- Knowledge type: Operational steps -->
+
+**構文**
+
+```sql
+SET <vault_name> AS DEFAULT STORAGE VAULT
+```
+
+設定後、テーブルの作成時に Storage Vault を明示的に指定しなければ、このデフォルトの Vault が自動的に使用されます。
+
+## テーブルの作成時に Storage Vault を指定する
+
+<!-- Knowledge type: Operational steps -->
+<!-- Applicable scenarios: Binding a storage location to a specific table -->
+
+テーブルを作成するときは、`storage_vault_name` を `PROPERTIES` 句に指定した `CREATE TABLE` 文を使用します。テーブルのデータは、対応する Storage Vault に保存されます。
+
+:::warning 注意
+テーブルの作成に成功した後、そのテーブルの `storage_vault` は**変更できません**。作成後に Storage Vault を変更することはサポートされていません。
+:::
+
+**例**
+
+```sql
+CREATE TABLE IF NOT EXISTS supplier (
+ s_suppkey int(11) NOT NULL COMMENT "",
+ s_name varchar(26) NOT NULL COMMENT "",
+ s_address varchar(26) NOT NULL COMMENT "",
+ s_city varchar(11) NOT NULL COMMENT "",
+ s_nation varchar(16) NOT NULL COMMENT "",
+ s_region varchar(13) NOT NULL COMMENT "",
+ s_phone varchar(16) NOT NULL COMMENT ""
+)
+UNIQUE KEY (s_suppkey)
+DISTRIBUTED BY HASH(s_suppkey) BUCKETS 1
+PROPERTIES (
+ "replication_num" = "1",
+ "storage_vault_name" = "hdfs_demo_vault"
+);
+```
+
+## データベースの作成時に Storage Vault を指定する
+
+<!-- Knowledge type: Operational steps -->
+<!-- Applicable scenarios: Setting a default storage location for a database -->
+
+データベースを作成するときは、`storage_vault_name` を `PROPERTIES` 句に指定した `CREATE DATABASE` 文を使用します。データベース内で新しく作成するテーブルに Storage Vault を個別に指定しなかった場合、データベースの Storage Vault 設定が継承されます。
+
+**例**
+
+```sql
+CREATE DATABASE IF NOT EXISTS `db_test`
+PROPERTIES (
+ "storage_vault_name" = "hdfs_demo_vault"
+);
+```
+
+データベースの `storage_vault_name` は [ALTER-DATABASE](../sql-manual/sql-statements/database/ALTER-DATABASE.md) で変更できます。**変更は新しく作成するテーブルにのみ適用され、既存のテーブルには影響しません。**
+
+:::info バージョンに関する注意事項と優先順位
+
+- データベース作成時の Storage Vault の指定は、**バージョン 3.0.5** 以降でサポートされています。
+- テーブル作成時に使用する Storage Vault の優先順位は、高い順に **テーブル** > **データベース** > **デフォルトの Storage Vault** です。
+- Storage Vault の `VAULT_NAME` を変更すると、データベース単位で設定された Vault が無効になり、エラーが発生する場合があります。その場合は、データベースに有効な `storage_vault_name` を再設定する必要があります。
+
+:::
+
+## Storage Vault を変更する
+
+<!-- Knowledge type: Configuration parameters -->
+<!-- Applicable scenarios: Updating storage credentials or renaming a Vault -->
+
+`ALTER STORAGE VAULT` を使用して、Storage Vault の変更可能なプロパティを更新します。
+
+### 変更可能なプロパティ
+
+**S3 Storage Vault** で変更できるプロパティは次のとおりです。
+
+| プロパティ | 説明 |
+|----------|-------------|
+| `VAULT_NAME` | Vault 名（名前の変更） |
+| `s3.access_key` | アクセスキー ID |
+| `s3.secret_key` | シークレットアクセスキー |
+| `use_path_style` | パス形式のアクセスを使用するかどうか |
+
+**HDFS Storage Vault** で**変更できない**プロパティは次のとおりです。
+
+| プロパティ | 理由 |
+|----------|--------|
+| `path_prefix` | 変更すると、過去のデータのパスとの整合性が失われるため |
+| `fs.defaultFS` | 変更すると、書き込み済みのデータにアクセスできなくなるため |
+
+その他のプロパティの説明については、[CREATE-STORAGE-VAULT](../sql-manual/sql-statements/cluster-management/storage-management/CREATE-STORAGE-VAULT)を参照してください。
+
+### 例
+
+S3 Storage Vault を変更します。
+
+```sql
+ALTER STORAGE VAULT old_s3_vault
+PROPERTIES (
+ "type" = "S3",
+ "VAULT_NAME" = "new_s3_vault",
+ "s3.access_key" = "new_ak",
+ "s3.secret_key" = "new_sk"
+);
+```
+
+HDFS Storage Vault を変更します。
+
+```sql
+ALTER STORAGE VAULT old_hdfs_vault
+PROPERTIES (
+ "type" = "hdfs",
+ "VAULT_NAME" = "new_hdfs_vault",
+ "hadoop.username" = "hdfs"
+);
+```
+
+## Storage Vault を削除する
+
+現在、Storage Vault の削除はサポートされていません。
+
+## Storage Vault のアクセス制御
+
+<!-- Knowledge type: Operational steps -->
+<!-- Applicable scenarios: Storage access control in multi-user environments -->
+
+管理者ユーザーは、指定した MySQL ユーザーまたはロールに Storage Vault の使用権限を付与できます。これにより、テーブル作成時に Vault を参照したり、その情報を表示したりできるユーザーを制御します。
+
+Storage Vault に対する `USAGE_PRIV` を持つユーザーまたはロールは、次の操作を実行できます。
+
+- `SHOW STORAGE VAULTS` で Storage Vault の情報を表示する
+- テーブル作成時に `PROPERTIES` で Storage Vault を指定する
+
+### 権限を付与する
+
+**構文**
+
+```sql
+GRANT
+ USAGE_PRIV
+ ON STORAGE VAULT <vault_name>
+ TO { ROLE | USER } {<role> | <user>}
+```
+
+**例**
+
+```sql
+GRANT USAGE_PRIV ON STORAGE VAULT my_storage_vault TO USER user1;
+```
+
+### 権限を取り消す
+
+**構文**
+
+```sql
+REVOKE
+ USAGE_PRIV
+ ON STORAGE VAULT <vault_name>
+ FROM { ROLE | USER } {<role> | <user>}
+```
+
+**例**
+
+```sql
+REVOKE USAGE_PRIV ON STORAGE VAULT my_storage_vault FROM USER user1;
+```
+
+## よくある質問
+
+<!-- Knowledge type: Troubleshooting -->
+<!-- Applicable scenarios: Routine operations and troubleshooting -->
+
+### Q1: 特定の Storage Vault を参照しているテーブルを調べるにはどうすればよいですか？
+
+**ステップ 1**：`SHOW STORAGE VAULTS` を実行し、対象の Storage Vault の `storage_vault_id` を確認します。
+
+**ステップ 2**：次の SQL を実行して、その Vault を参照しているテーブルを検索します。`PROPERTY_VALUE=3` を実際の `storage_vault_id` の値に置き換えてください。
+
+```sql
+SELECT *
+FROM information_schema.table_properties
+WHERE PROPERTY_NAME = "storage_vault_id"
+ AND PROPERTY_VALUE = 3;
+```
+
+クエリ結果の例：
+
+```
++---------------+---------------------------------+-------------------------------------+------------------+----------------+
+| TABLE_CATALOG | TABLE_SCHEMA | TABLE_NAME | PROPERTY_NAME | PROPERTY_VALUE |
++---------------+---------------------------------+-------------------------------------+------------------+----------------+
+| internal | regression_test_vault_p0_create | s3_92ba28c209154d968e680e58dd54d0cc | storage_vault_id | 3 |
++---------------+---------------------------------+-------------------------------------+------------------+----------------+
+1 row in set (0.04 sec)
+```
+
+### Q2: テーブルの作成後に Storage Vault を変更できますか？
+
+できません。テーブルの作成に成功した後、そのテーブルの `storage_vault` プロパティは変更できません。別の Storage Vault を使用するには、テーブルを再作成してデータを再ロードする必要があります。
+
+### Q3: Storage Vault の名前を変更すると、以前その Vault を参照していたデータベースに影響しますか？
+
+はい。Storage Vault の `VAULT_NAME` を変更すると、データベース単位の `storage_vault_name` 設定が無効になり、そのデータベース内で新しいテーブルを作成するときにエラーが発生する場合があります。[ALTER-DATABASE](../sql-manual/sql-statements/database/ALTER-DATABASE.md) を使用して、データベースに有効な `storage_vault_name` を再設定する必要があります。
diff --git a/i18n/ja/docusaurus-plugin-content-docs/version-4.x/compute-storage-decoupled/recycler.md b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/compute-storage-decoupled/recycler.md
new file mode 100644
index 00000000000..5de67d1462d
--- /dev/null
+++ b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/compute-storage-decoupled/recycler.md
@@ -0,0 +1,286 @@
+---
+title: コンピュートとストレージを分離した構成におけるデータ回収（Recycler）— 原理、設定、チューニング
+sidebar_label: データ回収（Recycler）
+description: Doris のコンピュートとストレージを分離した構成における Recycler のデータ回収の仕組みについて、削除マークの原理、保持期間による保護、監視メトリクス、一般的なチューニングの場面を説明します。
+keywords: [Doris, コンピュートとストレージの分離, データ回収, Recycler, 削除マーク, ガベージコレクション, ストレージ容量, チューニング]
+language: ja
+---
+
+<!-- Knowledge type: Architecture principles + Operational configuration -->
+<!-- Applicable scenarios: Compute-storage decoupled deployment / Storage space management / Troubleshooting -->
+
+Doris のコンピュートとストレージを分離した構成では、データ回収に**削除マーク（Mark-for-Deletion）**方式を使用します。専用コンポーネントの Recycler が削除マークの付いたメタデータエントリを定期的に走査し、対応するオブジェクトファイルを一括で削除します。これにより、性能、安全性、リソース使用率のバランスを取ります。
+
+## データ回収方式の比較
+
+<!-- Knowledge type: Architecture selection decision -->
+
+一般的な三つのデータ回収方式には、それぞれ長所と短所があります。Doris のコンピュートとストレージを分離した構成では、削除マーク方式を採用しています。
+
+| 方式 | トリガー | 長所 | 短所 |
+|----------|---------|------------|---------------|
+| **同期削除** | 削除コマンドの実行時にメタデータとファイルを直ちに削除する | 実装が簡単 | 応答が遅く、リスクが高く、猶予期間がない |
+| **照合による削除（逆方向）** | すべてのファイルを定期的に走査し、参照されていないファイルを特定して一括で削除する | 孤立したファイルを削除できる | すべてのファイルを走査する必要があり、I/O の負荷が高い |
+| **削除マーク（順方向）** | 削除時にはメタデータにマークを付けるだけで、バックグラウンド処理が定期的にマークを走査してファイルを削除する | 応答が速く、猶予期間があり、効率が高い | 一時的に余分なストレージ容量を使用する |
+
+### 削除マーク方式の利点
+
+削除マーク方式には、ほかの方式と比べて次の利点があります。
+
+- **応答が速い**: `DROP TABLE` はファイル I/O の完了を待たずにメタデータ KV に削除マークを付けるだけです。そのため、ユーザーへの応答が速く、大きなテーブルの削除でも処理がブロックされません。
+- **効率的な一括処理**: バックグラウンド処理がファイルの削除を定期的に一括実行するため、システムコールの回数が減り、I/O 全体の効率が向上します。
+- **誤操作からの保護**: ファイルが実際に削除されるまで猶予期間があります。誤って削除したテーブルはこの期間内に復元できるため、人的ミスによるリスクを大幅に低減できます。
+- **トランザクションの安全性**: 削除マークの付与は軽量なメタデータ変更です。原子性を保証しやすく、システム障害によるデータの不整合を減らせます。
+- **負荷の分散**: システムがアイドル状態のときにファイルを削除できるため、業務のピーク時に I/O リソースを大量に消費することを避けられます。
+
+## Recycler の動作
+
+<!-- Knowledge type: Architecture principles -->
+
+Recycler は独立してデプロイされるコンポーネントで、期限切れの不要なファイルを定期的に回収します。一つの Recycler で複数のインスタンスを同時に回収できますが、同じインスタンスを同時に処理できる Recycler は一つだけです。
+
+### 削除マーク方式の処理フロー
+
+`DROP` コマンドが実行されたとき、またはコンパクションでマージされた rowset などの不要なデータがシステムで生成されたとき、対応するメタデータ KV は `recycled` 状態としてマークされます。Recycler はインスタンス内の回収対象 KV を定期的に走査し、次の順序で処理します。
+
+1. 対応するオブジェクトファイル（セグメントファイルなど）を削除する
+2. 回収対象の KV を削除する
+
+メタデータを削除した後にファイルが残ることを防ぐため、メタデータより先にファイルを削除し、安全な削除順序を確保します。
+
+### 階層的な回収構造
+
+<!-- Knowledge type: Operational steps -->
+
+データ回収は階層に沿って上から下へ実行されます。`DROP TABLE` を例に示します。
+
+```
+Table
+ └─ Partition (delete recycle partition KV)
+ └─ Tablet (delete recycle tablet KV)
+ └─ Rowset (delete recycle rowset KV)
+ └─ Segment files (actual object files, the final deletion unit)
+```
+
+回収中は、`recycle_indexes`、`recycle_partition`、`recycle_compacted_rowsets`、`recycle_txn` など、複数の種類のタスクが並行して実行されます。各階層の回収対象 KV は、その階層に属するすべての子項目が正常に削除された後にのみ削除されます。
+
+### 保持期間による保護の仕組み
+
+回収対象となる各オブジェクトの KV には保持期間が記録されています。Recycler は走査時に保持期間を計算し、**まだ期限が切れていないオブジェクトは削除しません**。
+
+この仕組みは誤操作からデータを保護します。ユーザーが誤ってテーブルを削除しても、保持期間が過ぎるまでは Recycler がそのデータを削除しないため、その間にデータを復元する機会があります。
+
+### 信頼性の保証
+
+<!-- Knowledge type: Architecture principles -->
+
+**段階的な削除**: データファイル、メタデータ、インデックスまたはパーティションの KV の順に削除し、安全な削除順序を確保します。
+
+**リースによる保護**: 各 Recycler は回収を開始する前にリースを取得する必要があり、バックグラウンドスレッドがリースを定期的に更新します。リースの期限が切れるか、状態が IDLE になった場合にのみ、別の Recycler が処理を引き継げます。これにより、特定のインスタンスを一度に回収する Recycler を一つに限定し、並行回収によるデータの不整合を防ぎます。
+
+### 多層チェックの仕組み（Checker）
+
+<!-- Knowledge type: Architecture principles -->
+
+Recycler は、FE メタデータ、MS KV、オブジェクトファイルの間で多層の相互チェックを行う仕組み（checker）を実装しています。checker は、すべての Recycler KV、オブジェクトファイル、FE のメモリ内メタデータをバックグラウンドで双方向にチェックします。
+
+セグメントファイルの KV とオブジェクトファイルのチェックを例に示します。
+
+| チェック方向 | チェック内容 |
+|-----------------|---------------|
+| **順方向チェック** | すべての KV を走査し、対応するセグメントファイルが存在するか、対応するセグメント情報が FE のメモリ内にあるかを確認する |
+| **逆方向チェック** | すべてのセグメントファイルを走査し、それぞれに対応する KV があるか、対応するセグメント情報が FE のメモリ内にあるかを確認する |
+
+回収不足または過剰回収が発生した場合、checker は関連情報を取得します。運用担当者は checker のレポートに基づいて余分な不要ファイルを手動で削除するか、オブジェクトのバージョニングを使用して誤って削除されたファイルを復元できます。
+
+現在はセグメントファイル、idx ファイル、delete bitmap メタデータの順方向および逆方向のチェックに対応しており、今後はすべてのメタデータに対象を広げる予定です。
+
+## 監視メトリクス
+
+<!-- Knowledge type: Observability -->
+<!-- Applicable scenarios: Performance monitoring / Troubleshooting -->
+
+すべての監視メトリクスは、**MS ダッシュボード**でリアルタイムに確認できます。
+
+### 監視時の主な確認事項
+
+| 確認事項 | 対応するメトリクス |
+|----------|---------------------|
+| オブジェクトの種類ごとの秒あたりの回収バイト数と回収数 | `recycler_instance_recycle_bytes_per_ms`、`recycler_instance_recycle_time_per_resource` |
+| 回収ラウンドごとのデータ量と経過時間 | `recycler_instance_last_round_recycled_bytes`、`recycler_instance_last_round_recycle_elpased_ts` |
+| 回収済み／回収待ちのデータ量 | `recycler_instance_last_round_recycled_num`、`recycler_instance_last_round_to_recycle_num` |
+| ストレージバックエンドごとの回収状態 | `recycler_vault_recycle_status` |
+| 最後に成功／失敗した時刻 | `recycler_instance_recycle_last_success_ts`、`recycler_instance_recycle_end_ts` |
+| 次回の推定回収時刻 | `recycler_instance_next_ts` |
+
+### メトリクス一覧
+
+| 変数名 | メトリクス名 | ディメンション／ラベル | 説明 |
+|---------------|--------------|---------------------|-------------|
+| `g_bvar_recycler_vault_recycle_status` | `recycler_vault_recycle_status` | instance_id, resource_id, status | インスタンス ID、リソース ID、状態ごとの vault 回収処理の状態を計測する |
+| `g_bvar_recycler_vault_recycle_task_concurrency` | `recycler_vault_recycle_task_concurrency` | instance_id, resource_id | インスタンス ID、リソース ID ごとの vault ファイル回収タスクの並行数を計測する |
+| `g_bvar_recycler_instance_last_round_recycled_num` | `recycler_instance_last_round_recycled_num` | instance_id, resource_type | 直近のラウンドで回収されたオブジェクト数 |
+| `g_bvar_recycler_instance_last_round_to_recycle_num` | `recycler_instance_last_round_to_recycle_num` | instance_id, resource_type | 直近のラウンドで回収対象となったオブジェクト数 |
+| `g_bvar_recycler_instance_last_round_recycled_bytes` | `recycler_instance_last_round_recycled_bytes` | instance_id, resource_type | 直近のラウンドで回収されたデータ量（バイト） |
+| `g_bvar_recycler_instance_last_round_to_recycle_bytes` | `recycler_instance_last_round_to_recycle_bytes` | instance_id, resource_type | 直近のラウンドで回収対象となったデータ量（バイト） |
+| `g_bvar_recycler_instance_last_round_recycle_elpased_ts` | `recycler_instance_last_round_recycle_elpased_ts` | instance_id, resource_type | 直近の回収処理の経過時間（ms） |
+| `g_bvar_recycler_instance_recycle_round` | `recycler_instance_recycle_round` | instance_id, resource_type | 回収処理のラウンド番号 |
+| `g_bvar_recycler_instance_recycle_time_per_resource` | `recycler_instance_recycle_time_per_resource` | instance_id, resource_type | リソースごとの回収所要時間（ms）。`-1` は未回収を示す |
+| `g_bvar_recycler_instance_recycle_bytes_per_ms` | `recycler_instance_recycle_bytes_per_ms` | instance_id, resource_type | ミリ秒あたりの回収バイト数。`-1` は未回収を示す |
+| `g_bvar_recycler_instance_recycle_total_num_since_started` | `recycler_instance_recycle_total_num_since_started` | instance_id, resource_type | Recycler の起動後に回収されたオブジェクトの総数 |
+| `g_bvar_recycler_instance_recycle_total_bytes_since_started` | `recycler_instance_recycle_total_bytes_since_started` | instance_id, resource_type | Recycler の起動後に回収されたデータの総量（バイト） |
+| `g_bvar_recycler_instance_running_counter` | `recycler_instance_running_counter` | — | 現在回収中のインスタンス数 |
+| `g_bvar_recycler_instance_last_round_recycle_duration` | `recycler_instance_last_round_recycle_duration` | instance_id | 直近の回収ラウンド全体の所要時間 |
+| `g_bvar_recycler_instance_next_ts` | `recycler_instance_next_ts` | instance_id | `recycle_interval_seconds` に基づく次回の推定回収時刻 |
+| `g_bvar_recycler_instance_recycle_st_ts` | `recycler_instance_recycle_start_ts` | instance_id | 回収処理全体の開始時刻 |
+| `g_bvar_recycler_instance_recycle_ed_ts` | `recycler_instance_recycle_end_ts` | instance_id | 回収処理全体の終了時刻 |
+| `g_bvar_recycler_instance_recycle_last_success_ts` | `recycler_instance_recycle_last_success_ts` | instance_id | 最後に回収が成功した時刻 |
+
+## 設定パラメータ
+
+<!-- Knowledge type: Configuration parameters -->
+<!-- Applicable scenarios: Deployment tuning / Performance optimization -->
+
+Recycler で一般的に使用する設定パラメータを次に示します。
+
+| パラメータ | デフォルト値 | 説明 |
+|-----------|---------|-------------|
+| `recycle_interval_seconds` | `3600` | 回収の間隔（秒） |
+| `retention_seconds` | `259200`（3 日） | 個別の保持期間が設定されていないすべてのオブジェクトに適用される、一般的な保持期間 |
+| `recycle_concurrency` | `16` | 一つの Recycler が同時に回収できるインスタンスの最大数 |
+| `compacted_rowset_retention_seconds` | `1800` | コンパクションでマージされた rowset の保持期間（秒） |
+| `dropped_index_retention_seconds` | `10800` | 削除されたインデックスの保持期間（秒） |
+| `dropped_partition_retention_seconds` | `10800` | 削除されたパーティションの保持期間（秒） |
+| `recycle_whitelist` | `""` | 回収対象のホワイトリスト。インスタンス ID をカンマ区切りで指定する。空の場合はすべてのインスタンスを回収する |
+| `recycle_blacklist` | `""` | 回収対象のブラックリスト。インスタンス ID をカンマ区切りで指定する。空の場合はすべてのインスタンスを回収する |
+| `instance_recycler_worker_pool_size` | `32` | オブジェクト I/O 操作（一覧取得、削除など）の並行数 |
+| `recycle_pool_parallelism` | `40` | 回収タスク（`recycle_tablet`、`recycle_rowset` など）の並行数 |
+| `enable_checker` | `false` | 順方向 checker を有効にするかどうか |
+| `enable_inverted_check` | `false` | 逆方向 checker を有効にするかどうか |
+| `check_object_interval_seconds` | `43200`（12 時間） | checker の実行間隔（秒） |
+| `enable_recycler_stats_metrics` | `false` | Recycler の可観測性メトリクスを有効にするかどうか |
+| `recycler_storage_vault_white_list` | `""` | ストレージバックエンドのホワイトリスト。vault 名をカンマ区切りで指定する。空の場合はすべての vault を回収する |
+| `enable_mark_delete_rowset_before_recycle` | `false` | rowset のデータを実際に削除する前に、そのメタデータを回収対象としてマークし、次の走査ラウンドでデータと KV を削除するかどうか。動的な変更に対応。**バージョン 4.0.8 以降、デフォルト値が `true` から `false` に変更された** |
+| `enable_abort_txn_and_job_for_delete_rowset_before_recycle` | `false` | rowset を削除する前に、それに関連するトランザクションとジョブを中止するかどうか。動的な変更に対応。**バージョン 4.0.8 以降、デフォルト値が `true` から `false` に変更された** |
+
+:::caution 動作変更（4.0.8）
+
+`enable_mark_delete_rowset_before_recycle` と `enable_abort_txn_and_job_for_delete_rowset_before_recycle` のデフォルト値は、4.0.8 で `true` から `false` に変更されました。
+
+どちらも rowset を削除する前の追加の保護手順ですが、現在の実装では性能上の負荷が目立ち、回収が遅くなるため、デフォルトでは有効になっていません。この保護を維持するには、両方を明示的に `true` に設定してください。
+
+:::
+
+## 一般的なチューニングの場面
+
+<!-- Knowledge type: Operational steps -->
+<!-- Applicable scenarios: Troubleshooting / Performance tuning -->
+
+### 回収が遅すぎる場合
+
+**目的**: 不要なデータの削除を速め、ストレージ容量を解放します。
+
+**調整方法**:
+
+1. 並行数を増やします。
+ - `recycle_concurrency`（デフォルト値 16）: 同時に回収するインスタンス数を増やします。
+ - `instance_recycler_worker_pool_size`（デフォルト値 32）: オブジェクト I/O 操作の並行数を増やします。
+ - `recycle_pool_parallelism`（デフォルト値 40）: 回収タスクの並行数を増やします。
+2. 回収間隔を短くします。たとえば、`recycle_interval_seconds` をデフォルトの 3600 秒から 1800 秒に減らします。
+3. ホワイトリストを使用します。`recycle_whitelist` を使って、重要なインスタンスを優先的に回収します。
+
+### 回収の負荷が業務に影響する場合
+
+**目的**: Recycler が業務処理に与える影響を抑えます。
+
+**調整方法**:
+
+1. 並行数を減らします。`recycle_concurrency`、`instance_recycler_worker_pool_size`、`recycle_pool_parallelism` を適切に下げます。
+2. 回収間隔を長くします。たとえば、`recycle_interval_seconds` を 7200 秒に増やします。
+3. ブラックリストを使用します。`recycle_blacklist` を使って、負荷の高いインスタンスを一時的に除外します。
+
+### ストレージ容量が不足し、削除を速める必要がある場合
+
+**目的**: できるだけ速くストレージ容量を解放します。
+
+**調整方法**:
+
+1. 一般的な保持期間を短くします。`retention_seconds` をデフォルトの 259200 秒（3 日）から減らします。
+2. 特定の種類のオブジェクトの保持期間を短くします。
+ - `compacted_rowset_retention_seconds`（デフォルト値 1800 秒）を適切に減らします。
+ - `dropped_index_retention_seconds` と `dropped_partition_retention_seconds`（デフォルト値 10800 秒）を必要に応じて調整します。
+3. ストレージバックエンドを選択して回収します。`recycler_storage_vault_white_list` を使って、特定の vault の削除を優先します。
+
+### 誤削除を防ぐために保持期間を延長する必要がある場合
+
+**目的**: 誤操作からの復元に使える猶予期間を長く確保します。
+
+**調整方法**:
+
+1. `retention_seconds` を、たとえば 604800 秒（7 日）に増やします。
+2. オブジェクトの種類ごとの重要度に応じて、`dropped_partition_retention_seconds` などのパラメータを個別に調整します。
+
+### 監視と整合性チェックを有効にする場合
+
+**目的**: 可観測性を高め、データの整合性に関する潜在的な問題を調査します。
+
+**調整方法**:
+
+1. 可観測性メトリクスを有効にします。`enable_recycler_stats_metrics = true` に設定します。
+2. チェック機能を有効にします。
+ - `enable_checker = true`（順方向チェック）
+ - `enable_inverted_check = true`（逆方向チェック）
+3. `check_object_interval_seconds`（デフォルト値 43200 秒）を適切なチェック頻度に調整します。
+
+### 特定のインスタンスで回収に異常がある場合
+
+**目的**: 問題のあるインスタンスを一時的に隔離し、ほかのインスタンスの回収への影響を防ぎます。
+
+**調整方法**:
+
+1. 異常のあるインスタンス ID を `recycle_blacklist` に追加し、一時的に回収をスキップします。
+2. 優先的に処理する必要があるインスタンス ID を `recycle_whitelist` に追加します。
+3. `recycler_storage_vault_white_list` を使って、特定のストレージバックエンドを選択して回収します。
+
+### 大きなテーブルの削除によって回収タスクが滞留する場合
+
+**目的**: 滞留した回収タスクを速やかに処理します。
+
+**調整方法**:
+
+1. 並行数のパラメータ（`recycle_concurrency`、`recycle_pool_parallelism`）を一時的に増やし、滞留を解消します。
+2. ホワイトリストを使用し、タスクが大きく滞留しているインスタンスを優先します。
+3. 必要に応じて複数の Recycler インスタンスをデプロイし、負荷を分担します。
+
+## よくある質問
+
+<!-- Knowledge type: Troubleshooting -->
+<!-- Applicable scenarios: Troubleshooting / Common errors -->
+
+### 長時間実行されるクエリで「404 File Not Found」エラーが発生する
+
+**症状**: クエリの実行に長い時間がかかっています。その間に tablet のコンパクションが行われ、マージされた rowset が Recycler によって回収されます。クエリがその rowset にアクセスすると、`404 file not found` が報告されます。
+
+**原因**: `compacted_rowset_retention_seconds` のデフォルト値は 1800 秒（30 分）です。クエリの実行時間がこれを超えると、必要な rowset ファイルがすでに削除されている場合があります。
+
+**対処方法**: クラスターで最も実行時間の長いクエリに合わせて、`compacted_rowset_retention_seconds` を増やします。長時間実行されるクエリがある場合は、7200 秒以上に設定することを推奨します。
+
+### データ回収が正常に進んでいることを確認する方法
+
+**確認方法**:
+
+1. `enable_recycler_stats_metrics = true` に設定し、MS ダッシュボードで `recycler_instance_last_round_recycle_duration` と `recycler_instance_recycle_last_success_ts` のメトリクスを確認します。
+2. `recycler_instance_recycle_last_success_ts` が長時間更新されていない場合は、回収が停止している可能性があります。ログを調査してください。
+
+### データの整合性に問題があると疑われる場合の調査方法
+
+**確認方法**:
+
+1. `enable_checker = true` と `enable_inverted_check = true` に設定されていることを確認します。
+2. `check_object_interval_seconds` を適切に短くし、チェック頻度を上げます。
+3. checker が検出した異常を MS ダッシュボードで確認します。
+4. checker のレポートに基づいて余分な不要ファイルを手動で処理するか、オブジェクトのバージョニングを使用して誤って削除されたファイルを復元します。
+
+---
+
+> **注**: 上記のチューニングの推奨事項は、実際のクラスターの規模、ストレージ容量、業務の特性を踏まえて評価する必要があります。チューニング中はシステムの負荷と業務への影響を注意深く監視し、パラメータを徐々に調整して最適な設定を見つけることを推奨します。
diff --git a/i18n/ja/docusaurus-plugin-content-docs/version-4.x/compute-storage-decoupled/rw/file-cache-rw-compute-group-best-practice.md b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/compute-storage-decoupled/rw/file-cache-rw-compute-group-best-practice.md
new file mode 100644
index 00000000000..9d890b0e92a
--- /dev/null
+++ b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/compute-storage-decoupled/rw/file-cache-rw-compute-group-best-practice.md
@@ -0,0 +1,222 @@
+---
+{
+ "title": "読み書き分離における File Cache 最適化のベストプラクティス",
+ "sidebar_label": "読み書き分離：File Cache の最適化",
+ "language": "ja",
+ "description": "キャッシュウォームアップの設定を使用して、読み書き分離を採用した Apache Doris のコンピュートとストレージが分離された環境で、読み取り専用コンピュートグループの Cache Miss を解消し、クエリ性能を安定させる方法を説明します。",
+ "keywords": ["File Cache", "キャッシュウォームアップ", "読み書き分離", "Cache Miss", "コンピュートグループ", "コンピュートとストレージの分離", "Compaction", "クエリ性能"]
+}
+---
+
+<!-- Knowledge type: Architecture selection decision -->
+<!-- Applicable scenario: Performance tuning / Read-write separation deployment -->
+
+Apache Doris のコンピュートとストレージが分離されたアーキテクチャで、複数のコンピュートグループによって読み書きを分離する場合、クエリ性能は File Cache のヒット率に大きく左右されます。読み取り専用コンピュートグループで Cache Miss が発生すると、リモートのオブジェクトストレージからデータを取得する必要があり、クエリのレイテンシが大幅に増加することがあります。
+
+このドキュメントでは、キャッシュウォームアップと関連設定を使用して、**Compaction**、**データ取り込み**、**Schema Change** に起因する Cache Miss を減らし、読み取り専用クラスタのクエリ性能を安定させる方法を説明します。
+
+## 主な問題：新しいデータバージョン（Rowset）による Cache Miss
+
+<!-- Knowledge type: Principle explanation -->
+
+Doris では、Compaction、Schema Change、データ取り込みによって新しいデータファイル群（Rowset）が生成されます。書き込み専用コンピュートグループは、書き込み時にデフォルトでデータをローカルの File Cache にキャッシュするため、そのコンピュートグループのクエリ性能には影響しません。
+
+読み取り専用コンピュートグループでは、メタデータを同期して新しい Rowset を認識しても、そのデータファイルはローカルキャッシュにありません。この時点でクエリが新しい Rowset にアクセスすると、Cache Miss が発生し、性能が低下します。
+
+**基本方針は、クエリがアクセスする前に、読み取り専用コンピュートグループのキャッシュへデータを事前に、または状況に応じて読み込むことです。**
+
+## キャッシュウォームアップの仕組み
+
+<!-- Knowledge type: Feature overview -->
+<!-- Applicable scenario: Pre-deployment planning -->
+
+キャッシュウォームアップとは、リモートストレージから BE ノードの File Cache へデータを能動的に読み込む処理です。Doris には主に次の二つの方法があります。
+
+| ウォームアップ方式 | 適用する状況 | 特徴 |
+| --- | --- | --- |
+| アクティブ増分ウォームアップ | ウォームアップ関係を設定する権限がある一般的な状況 | 状況に応じて自動実行される。第一候補として推奨 |
+| 読み取り専用コンピュートグループの自動ウォームアップ | ウォームアップ関係を設定する権限がない場合、または MoW 以外のテーブルを使用する場合 | 軽量で設定が簡単 |
+
+### アクティブ増分ウォームアップ（推奨）
+
+<!-- Knowledge type: Operational steps -->
+
+書き込み用コンピュートグループと読み取り専用コンピュートグループの間にウォームアップ関係を設定します。書き込みや Compaction などで新しい Rowset が生成されると、システムは関連する読み取り専用コンピュートグループに能動的に通知し、非同期のキャッシュウォームアップを開始します。
+
+詳しい設定方法は、[FileCache のアクティブ増分ウォームアップ](./read-write-separation)を参照してください。
+
+### 読み取り専用コンピュートグループの自動ウォームアップ
+
+<!-- Knowledge type: Configuration parameters -->
+
+読み取り専用コンピュートグループの BE ノードでこの設定を有効にすると、新しい Rowset を検出するたびに、システムが非同期のウォームアップタスクを自動的に開始します。
+
+読み取り専用コンピュートグループの `be.conf` に次を設定します。
+
+```properties
+enable_warmup_immediately_on_new_rowset = true
+```
+
+### コンピュートグループ間の Peer Cache Read（フォールバック）
+
+<!-- Knowledge type: Architecture selection decision -->
+
+ウォームアップの対象から漏れたコールドデータの読み取りには、[Peer Cache Read](../file-cache/file-cache-peer-read)をフォールバックとして使用できます。ローカルキャッシュでミスが発生すると、読み取り専用コンピュートグループは、まず書き込み用コンピュートグループの BE にある File Cache からブロックを読み取り、それにも失敗した場合にのみオブジェクトストレージへアクセスします。書き込み用コンピュートグループをフィル用コンピュートグループ（`peer_cache_fill_compute_group_id`）に設定すると、書き込み用グループが読み取り専用グループに代わって不足するブロックをオブジェクトストレージから取得し、自身のキャッシュにもコピーを保持します。
+
+Peer Cache Read はデフォルトで有効です。クエリ実行時に受動的に読み取る仕組みであり、ウォームアップの代わりにはなりません。読み取り専用クエリが、書き込み用コンピュートグループのネットワーク帯域とキャッシュ読み取り能力を利用できるようになります。厳密な分離が必要な場合は無効にしてください。
+
+## Compaction と Schema Change がクエリ性能に与える影響を抑える
+
+<!-- Knowledge type: Operational steps -->
+<!-- Applicable scenario: Troubleshooting / Performance tuning -->
+
+バックグラウンドの Compaction は古い Rowset を統合し、新しい Rowset を生成します。新しい Rowset がまだウォームアップされていない場合、Cache Miss によって読み取り専用コンピュートグループのクエリ性能が変動することがあります。次の二つの方法で対処できます。
+
+### 方法 1：アクティブ増分ウォームアップとコミットの遅延（推奨）
+
+この方法では、読み取り専用コンピュートグループが、Compaction や Schema Change によって生成された未キャッシュの新しい Rowset をクエリすることを根本的に防ぎます。
+
+**仕組み：**
+
+1. 書き込み用コンピュートグループと読み取り専用コンピュートグループの間に、アクティブ増分ウォームアップ関係を設定します。
+2. 書き込み用コンピュートグループの BE ノードで、Compaction と Schema Change に対するコミット遅延機能を有効にします。
+
+書き込み用コンピュートグループの `be.conf` に次を設定します。
+
+```properties
+enable_compaction_delay_commit_for_warm_up = true
+```
+
+**処理の流れ：**
+
+1. 書き込み用コンピュートグループで Compaction または Schema Change のタスクが完了し、新しい Rowset が生成されます。
+2. 新しい Rowset は**直ちにはコミットされず**、読み取り専用コンピュートグループからは見えません。
+3. システムが、関連する読み取り専用コンピュートグループで新しい Rowset のキャッシュウォームアップを開始します。
+4. 関連するすべての読み取り専用コンピュートグループでウォームアップが完了してから、新しい Rowset がコミットされ、すべてのコンピュートグループから見えるようになります。
+
+**利点：**
+
+- **円滑な切り替え**：読み取り専用コンピュートグループから見える Compaction の結果はすべてキャッシュ済みのため、クエリ性能が変動しません。
+- **高い安定性**：読み書き分離環境でクエリ性能を保証するうえで、最も堅牢な方法です。
+
+### 方法 2：読み取り専用コンピュートグループの自動ウォームアップとクエリでの考慮
+
+この方法では、クエリ層が状況に応じて Rowset を選択し、ウォームアップが完了していない新しい Rowset を可能な場合にスキップします。
+
+> **注意**：Unique Key MoW テーブルでは、正しい結果を得るために Compaction によって生成された Rowset をスキップできません。
+
+**設定手順：**
+
+1. 読み取り専用コンピュートグループの `be.conf` で自動ウォームアップを有効にします。
+
+ ```properties
+ enable_warmup_immediately_on_new_rowset = true
+ ```
+
+2. セッション変数またはユーザープロパティを使用して、ウォームアップ状態を考慮した Rowset 選択方式をクエリ時に有効にします。
+
+ クエリセッションに設定する場合：
+
+ ```sql
+ SET enable_prefer_cached_rowset = true;
+ ```
+
+ ユーザープロパティとして設定する場合：
+
+ ```sql
+ SET property for "jack" enable_prefer_cached_rowset = true;
+ ```
+
+**処理の流れ：**
+
+1. 読み取り専用コンピュートグループが Compaction による新しい Rowset を検出すると、非同期のウォームアップタスクを開始します。
+2. `enable_prefer_cached_rowset` を有効にすると、クエリ実行エンジンはウォームアップ済みの Rowset バージョンを優先します。
+3. ウォームアップ中の新しい Rowset は、データの整合性に影響しない範囲でクエリが自動的にスキップし、代わりにキャッシュ済みの古い Rowset にアクセスします。
+
+**注意事項：**
+
+この方法はベストエフォートです。新しい Rowset に対応する古い Rowset がすでに削除されている場合や、クエリが最新のデータバージョンにアクセスする必要がある場合は、ウォームアップの完了を待つか、コールドデータを直接読み取ります。
+
+## データ取り込みがクエリ性能に与える影響を抑える
+
+<!-- Knowledge type: Operational steps -->
+<!-- Applicable scenario: High-frequency writes / Real-time ingestion performance optimization -->
+
+`INSERT INTO` や `Stream Load` などによる高頻度のデータ取り込みでは、小さな新しいファイル（Rowset）が継続的に生成され、読み取り専用コンピュートグループで Cache Miss が発生します。業務上、秒単位またはサブ秒単位のデータ遅延を許容できる場合は、以下を組み合わせることで、データの鮮度をわずかに下げる代わりに性能を大幅に改善できます。
+
+**仕組み：** 自動ウォームアップとクエリ時の鮮度許容値を組み合わせます。指定した時間内にウォームアップが完了していない最新データを、クエリ実行エンジンが状況に応じてスキップします。
+
+**設定手順：**
+
+1. **ウォームアップを有効にする**：読み取り専用コンピュートグループでアクティブ増分ウォームアップを有効にするか、自動ウォームアップを有効にします。
+
+ ```properties
+ enable_warmup_immediately_on_new_rowset = true
+ ```
+
+2. **クエリで許容するデータの遅延を設定する**：読み取り専用コンピュートグループのクエリセッションまたはユーザープロパティに `query_freshness_tolerance_ms` を設定します。
+
+ クエリセッションに設定する場合：
+
+ ```sql
+ -- Allow up to 1000 milliseconds (1 second) of data latency
+ SET query_freshness_tolerance_ms = 1000;
+ ```
+
+ ユーザープロパティとして設定する場合：
+
+ ```sql
+ SET property for "jack" query_freshness_tolerance_ms = 1000;
+ ```
+
+**処理の流れ：**
+
+1. クエリが実行を開始すると、アクセスが必要な Rowset を確認します。
+2. Rowset が**直近 1000 ms 以内**に生成され、かつ**ウォームアップがまだ完了していない**場合、クエリ実行エンジンはその Rowset を自動的にスキップし、代わりに古くてもキャッシュ済みのデータにアクセスします。
+3. ほとんどのクエリがキャッシュにヒットし、新たに書き込まれたコールドデータの読み取りによる性能低下を回避できます。
+
+**フォールバック動作：** Rowset のウォームアップに `query_freshness_tolerance_ms` で指定した時間より長くかかる場合（たとえば 1000 ms を超える場合）、クエリはその Rowset をスキップしなくなります。データが最終的に見えるよう、デフォルトの動作に戻ってコールドデータを直接読み取ります。
+
+**利点：**
+
+- **大幅な性能向上**：高スループットの書き込み環境で、クエリ性能の急な変動を効果的に抑えられます。
+- **柔軟な調整**：業務要件に応じて、データの鮮度とクエリ性能のバランスを調整できます。
+
+## 方法の比較と選択
+
+<!-- Knowledge type: Architecture selection decision -->
+
+| 方法 | 適用する状況 | Compaction の影響 | Schema Change の影響 | 新規書き込みデータの影響 |
+| --- | --- | --- | --- | --- |
+| アクティブ増分ウォームアップとコミットの遅延（必要に応じて鮮度許容値を追加） | クエリのレイテンシに対する要件が非常に厳しく、ウォームアップ関係を設定する権限がある場合 | なし | なし | 鮮度許容値の設定に依存 |
+| 読み取り専用コンピュートグループの自動ウォームアップとキャッシュ済みデータの優先（必要に応じて鮮度許容値を追加） | ウォームアップ関係を設定する権限がない場合。鮮度許容値を設定しない MoW 主キーテーブルでは効果がない | なし | Cache Miss | 鮮度許容値の設定に依存 |
+
+どちらの方法でも、ウォームアップの対象から漏れたコールドデータについて、オブジェクトストレージからの読み取りを減らすフォールバックとして[コンピュートグループ間の Peer Cache Read](../file-cache/file-cache-peer-read)を組み合わせられます。上記のキャッシュウォームアップ方式と関連設定を適用することで、Apache Doris の読み書き分離アーキテクチャでキャッシュの動作を管理し、Cache Miss による性能低下を抑えて、読み取り専用クエリの性能を安定させることができます。
+
+## よくある質問
+
+<!-- Knowledge type: Troubleshooting -->
+<!-- Applicable scenario: Troubleshooting / Operations Q&A -->
+
+**Q：アクティブ増分ウォームアップと読み取り専用コンピュートグループの自動ウォームアップを同時に有効にできますか？**
+
+はい。両者は併用できます。両方を有効にすると、ウォームアップの対象範囲が広がります。アクティブ増分ウォームアップを主な方法とし、自動ウォームアップを補助として使うことを推奨します。
+
+**Q：コミットの遅延を有効にした後、Compaction の結果はいつ見えるようになりますか？**
+
+関連するすべての読み取り専用コンピュートグループでウォームアップが完了してから、Compaction の結果がコミットされ、すべてのコンピュートグループから見えるようになります。ウォームアップがタイムアウトした場合は、Compaction の処理が停止しないように、システムが強制的にコミットします。
+
+**Q：`query_freshness_tolerance_ms` にはどの値を設定すればよいですか？**
+
+業務で許容できるデータ遅延に応じて設定してください。通常、500～2000 ms の範囲で性能と鮮度のバランスを取れます。リアルタイム性に対する要件が非常に厳しい場合は、この設定を有効にすることは推奨しません。
+
+**Q：MoW 主キーテーブルの Compaction による Rowset をスキップできないのはなぜですか？**
+
+MoW（Merge-on-Write）テーブルの削除セマンティクスは、Compaction 後に生成されるデータバージョンに依存します。その Rowset をスキップするとクエリ結果が誤る可能性があるため、システムは常に最新の Rowset を読み取ります。
+
+**Q：読み取り専用コンピュートグループのクエリ性能が急に低下しました。原因をすばやく調べるにはどうすればよいですか？**
+
+1. BE の監視で File Cache のヒット率メトリクスを確認し、Cache Miss が大量に発生していないか調べます。
+2. 最近、Compaction、Schema Change、または大量のデータ取り込みが行われたか確認します。
+3. ウォームアップの仕組み（`enable_warmup_immediately_on_new_rowset` またはアクティブ増分ウォームアップ）が正しく設定されているか確認します。
+4. ウォームアップタスクの実行状況を調べ、正常に完了しているか確認します。
diff --git a/i18n/ja/docusaurus-plugin-content-docs/version-4.x/compute-storage-decoupled/rw/read-write-separation.md b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/compute-storage-decoupled/rw/read-write-separation.md
new file mode 100644
index 00000000000..1b1551312f5
--- /dev/null
+++ b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/compute-storage-decoupled/rw/read-write-separation.md
@@ -0,0 +1,621 @@
+---
+{
+ "title": "読み書き分離とプライマリ／スタンバイクラスターの File Cache ウォームアップ設定ガイド",
+ "sidebar_label": "読み書き分離：File Cache ウォームアップ",
+ "language": "ja",
+ "description": "読み書き分離とプライマリ／スタンバイ構成における Doris File Cache のアクティブな増分ウォームアップの仕組みを説明します。コンピュートグループ単位とテーブル単位のイベント駆動ウォームアップ、ジョブの作成、状態の確認、メトリクス、トラブルシューティングを扱います。",
+ "keywords": ["読み書き分離", "プライマリ／スタンバイクラスター", "File Cache ウォームアップ", "アクティブな増分ウォームアップ", "テーブル単位のウォームアップ", "ON TABLES", "コンピュートグループの同期", "高可用性"]
+}
+---
+
+<!-- Knowledge type: Architecture decision -->
+<!-- Applicable scenarios: Read/write separation deployment / Primary/standby cluster high availability / File Cache warm-up -->
+
+## 背景と適用シナリオ
+
+Apache Doris のコンピュートとストレージを分離した構成では、複数のコンピュートグループが同じリモートストレージのデータを共有できます。書き込み用コンピュートグループはデータの取り込み、Compaction、Schema Change を処理し、クエリ用コンピュートグループはオンラインクエリを処理します。新しい Rowset の生成後、クエリ用コンピュートグループが対応するファイルをローカルの File Cache に読み込んでいない場合、最初のクエリはオブジェクトストレージまたは HDFS にアクセスする必要があり、クエリのレイテンシーが変動する可能性があります。
+
+File Cache のアクティブな増分ウォームアップは、書き込み側で新しいデータが生成された後、関連する Segment ファイルとインデックスファイルを対象コンピュートグループのローカルキャッシュに事前に読み込みます。主に次のシナリオに適しています。
+
+| シナリオ | 説明 | 利点 |
+|------|------|----------|
+| 読み書き分離 | 書き込み用コンピュートグループが継続的にデータを取り込み、クエリ用コンピュートグループはクエリのみを処理する | クエリ用コンピュートグループが新しいデータを読み取る際のキャッシュミスを減らす |
+| プライマリ／スタンバイクラスターの高可用性 | スタンバイ側のコンピュートグループがプライマリ側のコンピュートグループからホットデータを継続的に同期する | フェイルオーバー後のコールドキャッシュからの復旧時間を短縮する |
+| マルチテナントまたは階層型データウェアハウス | クエリ用コンピュートグループごとに、業務テーブルの一部だけにアクセスする | テーブル単位のフィルタリングにより、不要なウォームアップとキャッシュ使用量を減らす |
+| コストの最適化 | ソースコンピュートグループには多数のテーブルがあるが、頻繁に実行されるクエリは一部のテーブルに集中する | リモートストレージからの読み取りとネットワーク転送を減らす |
+
+:::tip バージョン情報
+このドキュメントでは、File Cache のアクティブな増分ウォームアップと、テーブル単位でフィルタリングする `ON TABLES` 機能について説明します。対応する正確なバージョンは、該当バージョンのリリースノートと SQL 構文ドキュメントを参照してください。
+:::
+
+## 機能の概要
+
+File Cache のアクティブなウォームアップは、次の三つの同期モードをサポートします。
+
+| 同期モード | プロパティ値 | 適用シナリオ |
+|------|--------|----------|
+| 一度限りの同期 | `once` | 新しいコンピュートグループの稼働開始時に初期ウォームアップを手動で実行する |
+| 定期同期 | `periodic` | 一定の間隔でホットデータを同期し、キャッシュを継続的に温めておく |
+| イベント駆動同期 | `event_driven` | Load、Compaction、Schema Change 中に生成されたデータを自動的にウォームアップする |
+
+イベント駆動同期は、次の二つの範囲に適用できます。
+
+| 範囲 | 構文形式 | 説明 |
+|------|----------|------|
+| コンピュートグループ単位のイベント駆動ウォームアップ | `ON TABLES` なし | ソースコンピュートグループで、一致するイベントによって生成された新しいデータがウォームアップをトリガーする |
+| テーブル単位のイベント駆動ウォームアップ | `ON TABLES (...)` あり | ルールに一致するテーブルの新しいデータだけがウォームアップをトリガーする |
+
+テーブル単位のイベント駆動ウォームアップは、クエリ用コンピュートグループが主要テーブルの一部だけを必要とする場合に適しています。コンピュートグループ単位のウォームアップと比べ、対象コンピュートグループでの不要なリモート読み取り、ネットワーク転送、キャッシュ使用量を減らせます。
+
+## ウォームアップジョブの作成
+
+### 一度限りの同期
+
+一度限りの同期は、新しいコンピュートグループの稼働開始時に初期ウォームアップを行う場合に適しています。
+
+```sql
+WARM UP COMPUTE GROUP <target_compute_group> WITH COMPUTE GROUP <source_compute_group>;
+```
+
+### 定期同期
+
+定期同期は、ホットデータの同期を継続的に維持する場合に適しています。
+
+```sql
+WARM UP COMPUTE GROUP <target_compute_group> WITH COMPUTE GROUP <source_compute_group>
+PROPERTIES (
+ "sync_mode" = "periodic",
+ "sync_interval_sec" = "600"
+);
+```
+
+`sync_interval_sec` は同期間隔を秒単位で指定します。デフォルト値は `600` です。
+
+### コンピュートグループ単位のイベント駆動ウォームアップ
+
+コンピュートグループ単位のイベント駆動ウォームアップは、読み書き分離のシナリオに適しています。ソースコンピュートグループの書き込みイベントを監視し、Load、Compaction、Schema Change 中に生成されたデータを対象コンピュートグループに事前に読み込みます。
+
+```sql
+WARM UP COMPUTE GROUP <target_compute_group> WITH COMPUTE GROUP <source_compute_group>
+PROPERTIES (
+ "sync_mode" = "event_driven",
+ "sync_event" = "load"
+);
+```
+
+- `sync_event`：イベント駆動ウォームアップジョブを作成する場合は、このパラメータを `load` に設定します。
+
+### テーブル単位のイベント駆動ウォームアップ
+
+テーブル単位のイベント駆動ウォームアップでは、コンピュートグループ単位のイベント駆動ウォームアップに `ON TABLES` 句を追加し、ウォームアップ対象のテーブル範囲を指定します。
+
+```sql
+WARM UP COMPUTE GROUP <target_compute_group> WITH COMPUTE GROUP <source_compute_group>
+ON TABLES (
+ INCLUDE '<database_pattern>.<table_pattern>'
+ [, INCLUDE '<database_pattern>.<table_pattern>' ...]
+ [, EXCLUDE '<database_pattern>.<table_pattern>' ...]
+)
+PROPERTIES (
+ "sync_mode" = "event_driven",
+ "sync_event" = "load"
+);
+```
+
+パラメータの説明：
+
+| パラメータ | 必須 | 説明 |
+|------|----------|------|
+| `<target_compute_group>` | はい | 対象コンピュートグループの名前。一致したテーブルの新しいデータは、このコンピュートグループのローカル File Cache にウォームアップされます |
+| `<source_compute_group>` | はい | ソースコンピュートグループの名前。Doris はこのコンピュートグループの書き込みイベントを監視します |
+| `ON TABLES` | いいえ | テーブル単位のフィルタリングルール。省略すると、コンピュートグループ単位のイベント駆動ウォームアップジョブになります |
+| `INCLUDE` | `ON TABLES` を使用する場合は必須 | ウォームアップ範囲に含めるテーブルパターンを指定します。少なくとも一つの `INCLUDE` ルールが必要です |
+| `EXCLUDE` | いいえ | `INCLUDE` の結果からテーブルパターンを除外します |
+| `sync_mode` | はい | テーブル単位のイベント駆動ウォームアップでは `event_driven` を使用します |
+| `sync_event` | はい | テーブル単位のイベント駆動ウォームアップでは、現在 `load` イベントを使用します |
+
+:::caution 注意
+同じソースコンピュートグループと対象コンピュートグループに対して、コンピュートグループ単位の `load` イベント駆動ウォームアップと、テーブル単位の `ON TABLES` イベント駆動ウォームアップを同時に設定しないでください。両者の意味は重複しており、Doris はジョブ作成時に競合する設定を拒否します。コンピュートグループ単位からテーブル単位のウォームアップに切り替えるには、先に古いジョブをキャンセルしてから、新しい `ON TABLES` ジョブを作成します。
+:::
+
+## ON TABLES のマッチングルール
+
+### パターンの形式
+
+`ON TABLES` のパターンは `'database.table'` 形式を使用し、単一引用符で囲む必要があります。次のワイルドカードを使用できます。
+
+| ワイルドカード | 意味 | 例 |
+|--------|------|------|
+| `*` | 空文字列を含む任意の長さの文字列に一致する | `'ods.*'` は `ods` データベース内のすべてのテーブルに一致する |
+| `?` | 任意の一文字に一致する | `'logs.access_202?'` は `logs.access_2020` から `logs.access_2029` までに一致する |
+
+ワイルドカードを使わないパターンは完全一致です。たとえば、`'sales.orders'` は `orders` テーブルのうち、`sales` データベースにあるものだけに一致します。
+
+よく使うパターンの例：
+
+| パターン | 意味 |
+|------|------|
+| `'mydb.*'` | `mydb` データベース内のすべてのテーブルに一致する |
+| `'*.orders'` | すべてのデータベースにある `orders` という名前のテーブルに一致する |
+| `'dw.fact_*'` | 名前が `fact_` で始まるテーブルのうち、`dw` データベースにあるものに一致する |
+| `'*.*_bak'` | すべてのデータベースにある、名前が `_bak` で終わるテーブルに一致する |
+| `'sales.orders'` | `sales.orders` に完全一致する |
+
+### INCLUDE と EXCLUDE
+
+Doris は最終的なウォームアップ範囲を次のように計算します。
+
+```text
+Final warm-up scope = tables matched by all INCLUDE rules - tables matched by all EXCLUDE rules
+```
+
+ルール：
+
+- `INCLUDE` と `EXCLUDE` ルールの順序は、最終結果に影響しません。
+- 少なくとも一つの `INCLUDE` ルールが必要です。`EXCLUDE` だけは指定できません。
+- 複数の `INCLUDE` ルールは和集合として扱われます。
+- 複数の `EXCLUDE` ルールは、候補集合から一致するテーブルを除外します。
+- マッチングは Doris のデータベース名とテーブル名の命名規則に従います。実際のデータベース名とテーブル名と同じ大文字・小文字を使用してください。
+
+例：
+
+```sql
+WARM UP COMPUTE GROUP analytics_cg WITH COMPUTE GROUP write_cg
+ON TABLES (
+ INCLUDE 'ods.*',
+ INCLUDE 'dw.fact_*',
+ INCLUDE 'dw.dim_*',
+ EXCLUDE 'ods.tmp_*',
+ EXCLUDE '*.*_bak'
+)
+PROPERTIES (
+ "sync_mode" = "event_driven",
+ "sync_event" = "load"
+);
+```
+
+この例では、次のテーブルがウォームアップされます。
+
+- `ods` データベース内の、名前が `tmp_` で始まるテーブルを除くテーブル。
+- `dw` データベース内の、名前が `fact_` または `dim_` で始まるテーブル。
+- どのデータベースでも、名前が `_bak` で終わるバックアップテーブルは対象外です。
+
+### マテリアライズドビュー
+
+`ON TABLES` ルールは、通常のテーブルと非同期マテリアライズドビューの両方に一致します。非同期マテリアライズドビューはデータベースの名前空間内に独立したテーブルとして存在し、`INCLUDE` と `EXCLUDE` ルールによって名前で照合されます。
+
+同期マテリアライズドビュー（Rollup）はベーステーブルの内部インデックスであり、独立したテーブルではありません。ベーステーブルがウォームアップされると、その同期マテリアライズドビューに関連するデータもベーステーブルと一緒に処理されるため、別のルールは不要です。
+
+## 例
+
+### 特定のテーブルをウォームアップする
+
+```sql
+WARM UP COMPUTE GROUP report_cg WITH COMPUTE GROUP business_cg
+ON TABLES (
+ INCLUDE 'sales.orders',
+ INCLUDE 'sales.customers',
+ INCLUDE 'inventory.stock_level'
+)
+PROPERTIES (
+ "sync_mode" = "event_driven",
+ "sync_event" = "load"
+);
+```
+
+### データベース全体をウォームアップする
+
+```sql
+WARM UP COMPUTE GROUP analytics_cg WITH COMPUTE GROUP load_cg
+ON TABLES (
+ INCLUDE 'analytics_db.*'
+)
+PROPERTIES (
+ "sync_mode" = "event_driven",
+ "sync_event" = "load"
+);
+```
+
+### 複数のデータベースをウォームアップし、一時テーブルを除外する
+
+```sql
+WARM UP COMPUTE GROUP query_cg WITH COMPUTE GROUP etl_cg
+ON TABLES (
+ INCLUDE 'ods.*',
+ INCLUDE 'dwd.*',
+ INCLUDE 'dws.*',
+ EXCLUDE '*.tmp_*',
+ EXCLUDE '*.*_backup'
+)
+PROPERTIES (
+ "sync_mode" = "event_driven",
+ "sync_event" = "load"
+);
+```
+
+### 同じテーブルを複数の対象コンピュートグループにウォームアップする
+
+同じテーブルを複数のクエリ用コンピュートグループで使用する必要がある場合は、対象コンピュートグループごとに一つずつジョブを作成します。
+
+```sql
+WARM UP COMPUTE GROUP realtime_cg WITH COMPUTE GROUP write_cg
+ON TABLES (INCLUDE 'sales.orders')
+PROPERTIES ("sync_mode" = "event_driven", "sync_event" = "load");
+
+WARM UP COMPUTE GROUP batch_cg WITH COMPUTE GROUP write_cg
+ON TABLES (INCLUDE 'sales.orders')
+PROPERTIES ("sync_mode" = "event_driven", "sync_event" = "load");
+```
+
+## ウォームアップジョブの管理
+
+### ジョブの表示
+
+すべてのウォームアップジョブを表示します。
+
+```sql
+SHOW WARM UP JOB;
+```
+
+特定のジョブを表示します。
+
+```sql
+SHOW WARM UP JOB WHERE id = <job_id>;
+```
+
+フィールドの説明：
+
+| フィールド | 説明 |
+|--------|------|
+| `JobId` | ウォームアップジョブの一意の ID |
+| `SrcComputeGroup` | ソースコンピュートグループの名前 |
+| `DstComputeGroup` | 対象コンピュートグループの名前 |
+| `Status` | ジョブの状態。`PENDING`、`RUNNING`、`FINISHED`、`CANCELLED` など |
+| `Type` | ウォームアップ範囲。`CLUSTER` はコンピュートグループ単位、`TABLE` は明示的に指定したテーブル、`TABLES` は `ON TABLES` ルールで一致したテーブルを意味します |
+| `SyncMode` | 同期モード。`ONCE`、`PERIODIC(interval_sec)`、`EVENT_DRIVEN(event)` など |
+| `CreateTime` | ジョブの作成時刻 |
+| `StartTime` | 直近の開始時刻 |
+| `FinishBatch` | 完了したバッチの数 |
+| `AllBatch` | バッチの総数 |
+| `FinishTime` | 直近の終了時刻。イベント駆動ジョブは通常、実行状態を維持します |
+| `ErrMsg` | 直近のエラーメッセージ。エラーがなければ空です |
+| `Tables` | 明示的なテーブル一覧。主に一度限り、または定期的なテーブル単位のウォームアップで使用します |
+| `TableFilter` | `ON TABLES` ルールの正規化された表現。コンピュートグループ単位のジョブでは空です |
+| `MatchedTables` | 現在一致しているテーブル名の一覧。定期的な更新により、テーブルの作成、削除、名前変更が反映されます |
+| `SyncStats` | イベント駆動ジョブの同期進捗。一覧クエリでは概要を、ID を指定したクエリでは詳細な JSON を表示します |
+
+`SHOW WARM UP JOB` は日常的な確認に適しています。表示する一覧が横に広がりすぎないよう、`SyncStats` には直近 30 分間の概要が表示されます。
+
+```json
+{
+ "window": "30m",
+ "src_size": "58.2mb",
+ "dst_size": "57.5mb",
+ "gap_size": "716kb",
+ "trigger_gap_ms": 1200
+}
+```
+
+ジョブ ID を指定して照会すると、`SyncStats` には 5 分、30 分、1 時間のウィンドウごとの詳細なメトリクスが表示されます。
+
+```sql
+SHOW WARM UP JOB WHERE id = <job_id>;
+```
+
+`SyncStats` の例：
+
+```json
+{
+ "seg_num": {
+ "requested_5m": 42,
+ "finish_5m": 40,
+ "gap_5m": 2,
+ "fail_5m": 0,
+ "requested_30m": 180,
+ "finish_30m": 178,
+ "gap_30m": 2,
+ "fail_30m": 0,
+ "requested_1h": 320,
+ "finish_1h": 318,
+ "gap_1h": 2,
+ "fail_1h": 0
+ },
+ "seg_size": {
+ "requested_5m": "12.5mb",
+ "finish_5m": "11.8mb",
+ "gap_5m": "716kb",
+ "fail_5m": "0b",
+ "requested_30m": "58.2mb",
+ "finish_30m": "57.5mb",
+ "gap_30m": "716kb",
+ "fail_30m": "0b",
+ "requested_1h": "102.3mb",
+ "finish_1h": "101.6mb",
+ "gap_1h": "716kb",
+ "fail_1h": "0b"
+ },
+ "idx_num": {
+ "requested_5m": 10,
+ "finish_5m": 10,
+ "gap_5m": 0,
+ "fail_5m": 0
+ },
+ "idx_size": {
+ "requested_5m": "2.1mb",
+ "finish_5m": "2.1mb",
+ "gap_5m": "0b",
+ "fail_5m": "0b"
+ },
+ "last_trigger_ts": "2026-08-11 14:32:15",
+ "last_finish_ts": "2026-08-11 14:32:18",
+ "progress_trigger_ts": "2026-08-11 14:32:14",
+ "trigger_gap_ms": 1000
+}
+```
+
+次のフィールドに注目してください。
+
+| フィールド | 説明 |
+|------|------|
+| `requested_*` | ソースコンピュートグループが送信したウォームアップ要求の量 |
+| `finish_*` | 対象コンピュートグループで完了したウォームアップ処理の量 |
+| `gap_*` | 未完了の量を示す差分 |
+| `fail_*` | 対象コンピュートグループで失敗したウォームアップ処理の量 |
+| `last_trigger_ts` | 直近にウォームアップがトリガーされた時刻 |
+| `progress_trigger_ts` | 対象コンピュートグループの現在の進捗に対応する、上流側のトリガー時刻 |
+| `last_finish_ts` | 直近にウォームアップが完了した時刻 |
+| `trigger_gap_ms` | ソース側の最新トリガー時刻と対象側の進捗ウォーターマークとの差。単位はミリ秒 |
+
+:::info バージョンに関する注意（4.0.8）
+
+バージョン 4.0.8 以降、三つの時刻フィールド `last_trigger_ts`、`last_finish_ts`、`progress_trigger_ts` の形式が `HH:mm:ss` から `yyyy-MM-dd HH:mm:ss` に変更され、日付も含まれるようになりました。それ以前は時刻のみが表示され、日付をまたぐ場合に日付が曖昧でした。
+
+これらのフィールドを固定の形式で解析するスクリプトは、4.0.8 にアップグレードする前に調整してください。
+
+:::
+
+### ジョブのキャンセル
+
+```sql
+CANCEL WARM UP JOB WHERE id = <job_id>;
+```
+
+キャンセルすると、Doris はこのジョブのイベント監視とウォームアップのトリガーを停止します。対象コンピュートグループの File Cache に書き込まれたデータは積極的には削除されず、通常のキャッシュ退避ポリシーに従って解放されます。
+
+現在のバージョンでは、既存ジョブの `ON TABLES` ルールを直接変更することはできません。ウォームアップ範囲を調整するには、先に古いジョブをキャンセルしてから新しいジョブを作成します。
+
+## マッチングの更新と動作上の注意
+
+### テーブルの作成、削除、名前変更
+
+`ON TABLES` ルールはジョブの作成時に評価され、ジョブの実行中にも定期的に再評価されます。デフォルトの更新間隔は 60 秒です。
+
+これにより、次のように動作します。
+
+- ジョブ作成後に新しいテーブルが作成され、その名前がルールに一致する場合、後続の更新サイクルでウォームアップ範囲に自動的に含まれます。
+- 一致していたテーブルが削除されると、後続の更新サイクルで `MatchedTables` から削除されます。
+- 一致していたテーブルの名前が変更された場合、ウォームアップが継続するかどうかは、新しい名前がルールに引き続き一致するかどうかによります。
+
+新しいテーブルの作成から次のルール更新まで、最大 60 秒の遅延が生じることがあります。この間に新しいテーブルへ書き込んでも、このテーブル単位のジョブはトリガーされません。更新後の書き込みでは通常どおりウォームアップがトリガーされます。
+
+### 作成時に一致するテーブルがない場合
+
+テーブル単位のイベント駆動ウォームアップジョブを作成する際、`ON TABLES` ルールは既存のテーブルに少なくとも一つ一致する必要があります。一致するテーブルがない場合、ジョブの作成は失敗します。データベース名、テーブル名、ワイルドカードのパターンを確認してください。
+
+ウォームアップの関係を事前に設定したい場合は、ウォームアップジョブを作成する前に、ルールに一致するテーブルを少なくとも一つ作成してください。
+
+### Schema Change
+
+`ON TABLES` はテーブルの集合のみを決定し、イベントの種類自体が持つトリガーの意味は変更しません。現在のジョブで設定され、現在のバージョンでサポートされるイベントの種類について、新しく生成されたデータはテーブルのマッチング結果に従って処理されます。ジョブに `sync_event = "load"` が設定されている場合は、対応する Load イベントだけを監視します。
+
+## 動作の仕組み
+
+### 定期同期の実行フロー
+
+1. FE がジョブを登録し、同期間隔を記録します。
+2. FE がトリガー時刻に達したかどうかを定期的に確認します。
+3. トリガー時刻に達すると、FE は対象のテーブルまたはパーティションを対応する Tablet に変換し、タスクを配布します。
+4. BE はリモートストレージからファイルを読み取り、対象コンピュートグループの File Cache に書き込みます。
+
+### イベント駆動同期の実行フロー
+
+1. ユーザーがイベント駆動ジョブを作成し、FE が同期関係を永続化します。
+2. FE がイベント駆動の設定をソースコンピュートグループの BE に送信します。
+3. ソースコンピュートグループの BE が、書き込みイベントのコミット後にウォームアップをトリガーします。
+4. テーブル単位のイベント駆動ジョブでは、ソース BE は現在一致しているテーブル集合に属する Rowset だけを処理します。
+5. 対象コンピュートグループの BE が対応する Segment ファイルとインデックスファイルをダウンロードし、ローカルの File Cache に書き込みます。
+6. FE が `SHOW WARM UP JOB` と FE メトリクスを通じて、ジョブの状態と同期進捗を公開します。
+
+## メトリクスによる監視
+
+### SQL による確認
+
+ウォームアップの進捗を確認する最も直接的な方法は、`SHOW WARM UP JOB` を使用することです。
+
+```sql
+SHOW WARM UP JOB;
+SHOW WARM UP JOB WHERE id = <job_id>;
+```
+
+確認の目安：
+
+- `gap_size` または詳細な `gap_*` が継続的に 0 に近づいている場合、対象コンピュートグループは概ねソースコンピュートグループの書き込み速度に追いついています。
+- `trigger_gap_ms` が 0 に近づいている場合、対象コンピュートグループはソースコンピュートグループの最新のトリガーイベントに追いついています。
+- `fail_*` が 0 より大きい場合は、ディスク容量の問題、リモートストレージへのアクセス失敗、ネットワークエラーがないか BE のログを確認してください。
+- 5 分間のウィンドウはリアルタイムの変動、30 分間と 1 時間のウィンドウは継続的な傾向の確認に役立ちます。
+
+### BE の Bvar メトリクス
+
+`SHOW WARM UP JOB` と FE の `/metrics` に加え、BE の Bvar ページを使用して、個々の BE におけるウォームアップ実行メトリクスを確認できます。
+
+```bash
+curl http://<be_host>:<brpc_port>/vars
+```
+
+定期ジョブの BE 側メトリクス：
+
+| メトリクス名 | 意味 |
+|----------|------|
+| `file_cache_once_or_periodic_warm_up_submitted_segment_size` | 送信したセグメントデータのサイズ |
+| `file_cache_once_or_periodic_warm_up_finished_segment_size` | 完了したセグメントデータのサイズ |
+| `file_cache_once_or_periodic_warm_up_submitted_index_num` | 送信したインデックスの数 |
+| `file_cache_once_or_periodic_warm_up_finished_index_num` | 完了したインデックスの数 |
+
+イベント駆動ジョブにおけるソース BE のメトリクス：
+
+| メトリクス名 | 意味 |
+|----------|------|
+| `file_cache_event_driven_warm_up_requested_segment_size` | 同期を要求したセグメントデータのサイズ |
+| `file_cache_event_driven_warm_up_requested_index_num` | 同期を要求したインデックスの数 |
+| `file_cache_warm_up_rowset_last_call_unix_ts` | 最後に開始した同期要求のタイムスタンプ |
+
+イベント駆動ジョブにおける対象 BE のメトリクス：
+
+| メトリクス名 | 意味 |
+|----------|------|
+| `file_cache_event_driven_warm_up_submitted_segment_num` | 受信したセグメントの数 |
+| `file_cache_event_driven_warm_up_finished_segment_num` | ウォームアップが完了したセグメントの数 |
+| `file_cache_warm_up_rowset_last_handle_unix_ts` | 最後に処理した同期要求のタイムスタンプ |
+
+これらのメトリクスは個々の BE の実行状況を反映します。BE がウォームアップ要求を受信したか、ダウンロードを完了したか、最近要求を開始または処理したかを確認する際に役立ちます。複数の BE にまたがるジョブ単位の集計には、`SHOW WARM UP JOB WHERE id = <job_id>` または FE の Prometheus メトリクスを使用してください。
+
+### FE の Prometheus メトリクス
+
+クラウドモードでは、FE が BE からイベント駆動ウォームアップの進捗を定期的に取得して集計します。デフォルトの更新間隔は 15 秒です。この間隔は FE の設定項目 `cloud_warm_up_sync_stats_refresh_interval_ms` で制御され、デフォルト値は `15000` ミリ秒です。
+
+FE の `/metrics` から次のメトリクスを収集できます。
+
+| メトリクス名 | 説明 |
+|--------|------|
+| `doris_fe_file_cache_warm_up_sync_job_info` | ジョブのメタデータ。値は常に 1 です。ラベルには `job_id`、`job_type`、`sync_mode`、`sync_event`、`job_state`、ソースおよび対象コンピュートグループが含まれます |
+| `doris_fe_file_cache_warm_up_sync_job_size_bytes` | ソース側が送信し、対象側が完了したウォームアップの合計サイズ。単位はバイトです。`side` ラベルと `window` ラベルが含まれます |
+| `doris_fe_file_cache_warm_up_sync_job_trigger_gap_ms` | ソース側の最新トリガー時刻と対象側の進捗ウォーターマークとの差。単位はミリ秒です |
+
+よく使う PromQL の例：
+
+```promql
+# Total warm-up size submitted by the source side in the last 5 minutes for each job
+doris_fe_file_cache_warm_up_sync_job_size_bytes{side="src",window="5m"}
+
+# Total warm-up size completed by the target side in the last 5 minutes for each job
+doris_fe_file_cache_warm_up_sync_job_size_bytes{side="dst",window="5m"}
+
+# Sync size gap in the last 5 minutes for each job
+doris_fe_file_cache_warm_up_sync_job_size_bytes{side="src",window="5m"}
+ - ignoring(side)
+doris_fe_file_cache_warm_up_sync_job_size_bytes{side="dst",window="5m"}
+
+# Trigger progress time gap for each job
+doris_fe_file_cache_warm_up_sync_job_trigger_gap_ms
+```
+
+`ignoring(side)` は Prometheus に対し、ソースと対象のサイズ系列の差を計算するときに `side` ラベルを無視するよう指定します。これにより、同じジョブとウィンドウに属する `src` 系列と `dst` 系列を対応付けられます。
+
+## 一連の操作手順
+
+1. 現在のコンピュートグループを表示し、ソースと対象のコンピュートグループ名を確認します。
+
+ ```sql
+ SHOW COMPUTE GROUPS;
+ ```
+
+2. ウォームアップが必要なテーブルの範囲を確認します。
+
+ ```sql
+ SHOW TABLES FROM ods;
+ SHOW TABLES FROM dw;
+ ```
+
+3. テーブル単位のイベント駆動ウォームアップジョブを作成します。
+
+ ```sql
+ WARM UP COMPUTE GROUP read_cg WITH COMPUTE GROUP write_cg
+ ON TABLES (
+ INCLUDE 'ods.*',
+ INCLUDE 'dw.fact_*',
+ EXCLUDE 'ods.tmp_*'
+ )
+ PROPERTIES (
+ "sync_mode" = "event_driven",
+ "sync_event" = "load"
+ );
+ ```
+
+4. ジョブの状態と一致したテーブルを確認します。
+
+ ```sql
+ SHOW WARM UP JOB;
+ ```
+
+5. データを書き込んだ後、同期の進捗を確認します。
+
+ ```sql
+ SHOW WARM UP JOB WHERE id = <job_id>;
+ ```
+
+6. ルールを調整するには、古いジョブをキャンセルして新しいジョブを作成します。
+
+ ```sql
+ CANCEL WARM UP JOB WHERE id = <job_id>;
+ ```
+
+## ベストプラクティス
+
+- クエリ用コンピュートグループが少数の主要テーブルだけにアクセスする場合は、コンピュートグループ単位のウォームアップによる過剰なキャッシュ使用を避けるため、テーブル単位のイベント駆動ウォームアップを選択してください。
+- テーブル名の命名規則が明確なデータウェアハウスでは、`INCLUDE 'dws.*'`、`INCLUDE 'ads.*'`、`EXCLUDE '*.tmp_*'` のようなルールを使うと管理しやすくなります。
+- 複数のジョブで同じホットテーブルを対象にすることは避けてください。対象側で可能な限り重複ダウンロードを回避できても、ジョブ管理とメトリクスの解釈が複雑になります。
+- ウォームアップ範囲を変更するには、ジョブをキャンセルして再作成します。既存ジョブのルールが自動的に変更されることはありません。
+- 個々のジョブの詳細には `SHOW WARM UP JOB` を使用し、長期的な傾向の監視には Grafana で FE の Prometheus メトリクスを使用してください。
+
+## FAQ
+
+**Q: ある回の同期に失敗すると、ジョブ全体がキャンセルされますか？**
+
+いいえ。その回の同期に失敗しても、その実行がスキップされるだけです。ジョブの状態は変わらず、以降のサイクルでも再試行が続きます。`SHOW WARM UP JOB WHERE id = <job_id>` を実行して `ErrMsg` と `SyncStats` の失敗数を確認し、根本原因を調べるために BE のログを確認してください。
+
+**Q: 定期ジョブの実行がタイムアウトするとどうなりますか？**
+
+タイムアウトすると、その回の実行はスキップされます。ジョブ自体は削除されず、次のサイクルは通常どおりトリガーされます。`StartTime`、`FinishTime`、`FinishBatch`、`AllBatch` を `SHOW WARM UP JOB` で確認すると、直近の実行状況を把握できます。
+
+**Q: 複数のソースコンピュートグループから同じ対象コンピュートグループへ同期できますか？**
+
+はい。たとえば、コンピュートグループ A とコンピュートグループ C の両方からコンピュートグループ B へ同期できます（A -> B と C -> B が共存します）。複数のジョブが同じテーブルを対象にする場合、ジョブ管理とメトリクスの解釈が複雑になります。
+
+**Q: テーブル単位のイベント駆動ウォームアップは、どのような場合に使用すべきですか？**
+
+対象コンピュートグループが一部のテーブルだけを照会する場合や、ソースコンピュートグループに多数のテーブルがあっても、アクセスの多いテーブルは少数に限られる場合に使用します。これにより、不要なウォームアップとキャッシュの占有を減らせます。
+
+**Q: `ON TABLES` を使用しない場合はどうなりますか？**
+
+`ON TABLES` を指定しない場合、ジョブはコンピュートグループ単位のイベント駆動ウォームアップジョブになります。ソースコンピュートグループで、一致するイベントによって生成された新しいデータがウォームアップをトリガーします。
+
+**Q: `INCLUDE` と `EXCLUDE` の順序は結果に影響しますか？**
+
+いいえ。Doris はまずすべての `INCLUDE` ルールの和集合を計算し、その後、`EXCLUDE` ルールに一致するすべてのテーブルを除外します。
+
+**Q: ジョブ作成後にルールに一致するテーブルを作成した場合、自動的にウォームアップされますか？**
+
+はい。Doris はルールを定期的に再評価します。新しいテーブルがルールに一致する場合、後続の更新サイクルでウォームアップ範囲に含まれます。デフォルトの更新間隔は 60 秒です。
+
+**Q: テーブルの名前を変更した後もウォームアップは継続しますか？**
+
+新しいテーブル名が `ON TABLES` ルールに引き続き一致するかどうかによります。一致すればウォームアップは継続します。一致しなければ、後続の更新サイクルで停止します。
+
+**Q: テーブル内の一つのパーティションだけをウォームアップできますか？**
+
+テーブル単位のイベント駆動ウォームアップはテーブル単位でフィルタリングするため、`ON TABLES` でパーティションを指定することはできません。一致したテーブルの新しいデータは、テーブル単位のルールに従って処理されます。
+
+**Q: ウォームアップが有効になっていることを確認するにはどうすればよいですか？**
+
+次の手順で確認できます。
+
+1. `SHOW WARM UP JOB WHERE id = <job_id>` を実行し、`Status` が `RUNNING` または `FINISHED` であることを確認します。
+2. テーブル単位のイベント駆動ウォームアップでは、`MatchedTables` が想定どおりか確認します。
+3. `FinishBatch` と `AllBatch` を比較し、一度限りのジョブまたは定期ジョブの進捗を確認します。
+4. `SyncStats` を確認し、`gap_size` または詳細な `gap_*` が 0 に近づき、`trigger_gap_ms` が増加し続けていないことを確認します。
+5. 対象コンピュートグループの BE Bvar メトリクスを確認し、`file_cache_event_driven_warm_up_finished_segment_num` などの完了カウンターが増加し続けていることを確認します。
+6. 対象コンピュートグループで関連テーブルを照会し、File Cache のヒット率、FE メトリクス、BE のログを使用して、リモート読み取りが依然として多いかどうかを確認します。
+
+**Q: 同期間隔や `ON TABLES` ルールなど、同期ジョブの設定を変更するにはどうすればよいですか？**
+
+現在のバージョンでは直接変更できません。まず `CANCEL WARM UP JOB WHERE id = <job_id>` を実行して古いジョブをキャンセルし、その後、新しいジョブを作成する必要があります。
diff --git a/i18n/ja/docusaurus-plugin-content-docs/version-4.x/compute-storage-decoupled/upgrade.md b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/compute-storage-decoupled/upgrade.md
new file mode 100644
index 00000000000..4e156dacb9d
--- /dev/null
+++ b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/compute-storage-decoupled/upgrade.md
@@ -0,0 +1,279 @@
+---
+{
+ "title": "ストレージ・コンピューティング分離クラスターのアップグレードガイド（ローリングアップグレード）",
+ "sidebar_label": "ローリングアップグレードガイド",
+ "language": "ja",
+ "description": "Doris のストレージ・コンピューティング分離クラスターでローリングアップグレードを行う方法。MetaService、Recycler、BE、FE のアップグレード順序と手順を説明します。",
+ "keywords": ["Doris アップグレード", "ストレージ・コンピューティング分離のアップグレード", "ローリングアップグレード", "MetaService アップグレード", "BE アップグレード", "FE アップグレード"]
+}
+---
+
+<!-- Knowledge type: Operational steps -->
+<!-- Applicable scenario: Cluster upgrade / Version migration -->
+
+Doris のストレージ・コンピューティング分離クラスターは、システム全体を停止せずに上流アプリケーションへの影響を抑えられる**ローリングアップグレード**に対応しています。このドキュメントでは、アップグレード前の確認、コンポーネントごとのアップグレード手順、よくある質問を含む、ストレージ・コンピューティング分離モードのアップグレード手順全体を説明します。
+
+ストレージ・コンピューティング統合クラスターのアップグレードについては、[クラスターのアップグレード](../admin-manual/cluster-management/upgrade)を参照してください。
+
+## バージョン番号
+
+<!-- Knowledge type: Configuration parameters -->
+
+Doris のバージョン番号は三つの部分から構成されます（例: `3.0.3`）。現在のバージョンを確認するには、次の SQL を実行します。
+
+```sql
+MySQL [(none)]> select @@version_comment;
++----------------------------------------------------------+
+| @@version_comment |
++----------------------------------------------------------+
+| Doris version doris-3.0.3-rc03-43f06a5e26 (Cloud Mode) |
++----------------------------------------------------------+
+```
+
+バージョン番号の各部分の意味は次のとおりです。
+
+| 位置 | 意味 | 例 |
+|------|------|------|
+| 最初 | メジャーバージョン | `3` |
+| 二番目 | マイナーバージョン | `0` |
+| 三番目 | パッチバージョン | `3` |
+| 四番目（任意） | パッチバージョンの重大な不具合に対応する緊急修正版 | `2.0.2.1` |
+
+バージョン文字列に付く `Cloud Mode` は、クラスターがストレージ・コンピューティング分離モードで稼働していることを示します。ストレージ・コンピューティング統合モードのクラスターには、この表示は付きません。
+
+**モード切り替えの制限:** ストレージ・コンピューティング分離モードとストレージ・コンピューティング統合モードの間の切り替えは**サポートされていません**。
+
+**ダウングレードの制限:** 下位バージョンから上位バージョンへのアップグレード、およびパッチバージョンのダウングレードはサポートされています。**マイナーバージョンとメジャーバージョンのダウングレードはサポートされていません。**
+
+## 前提条件
+
+<!-- Knowledge type: Operational steps -->
+<!-- Applicable scenario: Pre-deployment check / Environment validation -->
+
+アップグレード前に、以下の条件をすべて満たしていることを確認してください。
+
+1. **デプロイモードの確認:** クラスターがストレージ・コンピューティング分離モードで稼働していることを確認します（バージョン文字列に `Cloud Mode` が含まれます）。
+2. **インポートの再試行の設定:** アップグレード中のノード再起動によってジョブが失敗しないように、インポートジョブに再試行の仕組みがあることを確認します。
+3. **コンポーネントの状態の確認:** MetaService、Recycler、FE、BE がすべて正常に稼働し、エラーログがないことを確認します。
+4. **FE メタデータのバックアップ:** Master FE のメタデータディレクトリ（デフォルトでは FE ディレクトリ内の `doris-meta` ディレクトリ）をバックアップします。そのディレクトリが空の場合は、`meta_dir` 設定項目（`conf/fe.conf` 内）で実際のパスを確認してください。
+5. **インストールパッケージのダウンロード:** [Doris 公式サイト](https://doris.apache.org/download)から対象バージョンのインストールパッケージをダウンロードし、SHA-512 チェックサムを検証してパッケージの完全性を確認します。
+
+## アップグレードの流れ
+
+<!-- Knowledge type: Operational steps -->
+
+各コンポーネントを次の順序でアップグレードします。
+
+1. MetaService をアップグレード
+2. Recycler をアップグレード（個別にデプロイされている場合のみ）
+3. BE をアップグレード
+4. FE をアップグレード
+ 1. 最初に Observer FE ノードをアップグレード
+ 2. 次に Master 以外の FE ノードをアップグレード
+ 3. 最後に Master FE ノードをアップグレード
+
+## アップグレード手順
+
+<!-- Knowledge type: Operational steps -->
+<!-- Applicable scenario: Cluster upgrade / Version migration -->
+
+### ステップ 1: MetaService のアップグレード
+
+各 MetaService インスタンスで以下の操作を行います。このステップで使用する環境変数は次のとおりです。
+
+| 変数 | 意味 |
+|------|------|
+| `${MS_HOME}` | MetaService の作業ディレクトリ |
+| `${MS_PACKAGE_DIR}` | 新しい MetaService インストールパッケージを格納したディレクトリ |
+
+**1. 現在の MetaService を停止する**
+
+```shell
+cd ${MS_HOME}
+sh bin/stop.sh
+```
+
+**2. 既存のバイナリをバックアップする**
+
+```shell
+mv ${MS_HOME}/bin bin_backup_$(date +%Y%m%d_%H%M%S)
+mv ${MS_HOME}/lib lib_backup_$(date +%Y%m%d_%H%M%S)
+```
+
+**3. 新しいインストールパッケージを配置する**
+
+```shell
+cp ${MS_PACKAGE_DIR}/bin ${MS_HOME}/bin
+cp ${MS_PACKAGE_DIR}/lib ${MS_HOME}/lib
+```
+
+**4. 新しい MetaService を起動する**
+
+```shell
+sh ${MS_HOME}/bin/start.sh --daemon
+```
+
+**5. アップグレードを確認する**
+
+MetaService プロセスが正常に稼働し、`${MS_HOME}/log/doris_cloud.out` に新しいバージョン番号が表示されることを確認します。
+
+---
+
+### ステップ 2: Recycler のアップグレード（該当する場合）
+
+:::caution
+Recycler コンポーネントを個別にデプロイしていない場合は、このステップをスキップしてください。
+:::
+
+各 Recycler インスタンスで以下の操作を行います。MetaService と Recycler は同じインストールパッケージを使用します。このステップで使用する環境変数は次のとおりです。
+
+| 変数 | 意味 |
+|------|------|
+| `${RECYCLER_HOME}` | Recycler の作業ディレクトリ |
+| `${MS_PACKAGE_DIR}` | 新しいインストールパッケージを格納したディレクトリ（MetaService と共通） |
+
+**1. 現在の Recycler を停止する**
+
+```shell
+cd ${RECYCLER_HOME}
+sh bin/stop.sh
+```
+
+**2. 既存のバイナリをバックアップする**
+
+```shell
+mv ${RECYCLER_HOME}/bin bin_backup_$(date +%Y%m%d_%H%M%S)
+mv ${RECYCLER_HOME}/lib lib_backup_$(date +%Y%m%d_%H%M%S)
+```
+
+**3. 新しいインストールパッケージを配置する**
+
+```shell
+cp ${MS_PACKAGE_DIR}/bin ${RECYCLER_HOME}/bin
+cp ${MS_PACKAGE_DIR}/lib ${RECYCLER_HOME}/lib
+```
+
+**4. 新しい Recycler を起動する**
+
+```shell
+sh ${RECYCLER_HOME}/bin/start.sh --recycler --daemon
+```
+
+**5. アップグレードを確認する**
+
+Recycler プロセスが正常に稼働し、`${RECYCLER_HOME}/log/doris_cloud.out` に新しいバージョン番号が表示されることを確認します。
+
+---
+
+### ステップ 3: BE のアップグレード
+
+:::tip
+BE をアップグレードする前に、すべての MetaService インスタンスと Recycler インスタンス（該当する場合）のアップグレードが完了していることを確認してください。
+:::
+
+各 BE インスタンスで以下の操作を行います。このステップで使用する環境変数は次のとおりです。
+
+| 変数 | 意味 |
+|------|------|
+| `${BE_HOME}` | BE の作業ディレクトリ |
+| `${BE_PACKAGE_DIR}` | 新しい BE インストールパッケージを格納したディレクトリ |
+
+**1. 現在の BE を停止する**
+
+```shell
+cd ${BE_HOME}
+sh bin/stop_be.sh
+```
+
+**2. 既存のバイナリをバックアップする**
+
+```shell
+mv ${BE_HOME}/bin bin_backup_$(date +%Y%m%d_%H%M%S)
+mv ${BE_HOME}/lib lib_backup_$(date +%Y%m%d_%H%M%S)
+```
+
+**3. 新しいインストールパッケージを配置する**
+
+```shell
+cp ${BE_PACKAGE_DIR}/bin ${BE_HOME}/bin
+cp ${BE_PACKAGE_DIR}/lib ${BE_HOME}/lib
+```
+
+**4. 新しい BE を起動する**
+
+```shell
+sh ${BE_HOME}/bin/start_be.sh --daemon
+```
+
+**5. アップグレードを確認する**
+
+次の SQL を実行し、BE のバージョンと状態を確認します。
+
+```sql
+show backends;
+```
+
+---
+
+### ステップ 4: FE のアップグレード
+
+:::tip
+FE をアップグレードする前に、すべての BE インスタンスのアップグレードが完了していることを確認してください。
+:::
+
+FE ノードは、**Observer -> Master 以外 -> Master** の順序で一台ずつアップグレードする必要があります。
+
+各 FE インスタンスで以下の操作を行います。このステップで使用する環境変数は次のとおりです。
+
+| 変数 | 意味 |
+|------|------|
+| `${FE_HOME}` | FE の作業ディレクトリ |
+| `${FE_PACKAGE_DIR}` | 新しい FE インストールパッケージを格納したディレクトリ |
+
+**1. 現在の FE を停止する**
+
+```shell
+cd ${FE_HOME}
+sh bin/stop_fe.sh
+```
+
+**2. 既存のバイナリをバックアップする**
+
+```shell
+mv ${FE_HOME}/bin bin_backup_$(date +%Y%m%d_%H%M%S)
+mv ${FE_HOME}/lib lib_backup_$(date +%Y%m%d_%H%M%S)
+```
+
+**3. 新しいインストールパッケージを配置する**
+
+```shell
+cp ${FE_PACKAGE_DIR}/bin ${FE_HOME}/bin
+cp ${FE_PACKAGE_DIR}/lib ${FE_HOME}/lib
+```
+
+**4. 新しい FE を起動する**
+
+```shell
+sh ${FE_HOME}/bin/start_fe.sh --daemon
+```
+
+**5. アップグレードを確認する**
+
+次の SQL を実行し、FE のバージョンと状態を確認します。
+
+```sql
+show frontends;
+```
+
+## よくある質問
+
+<!-- Knowledge type: Operational steps -->
+<!-- Applicable scenario: Troubleshooting -->
+
+**Q1: ストレージ・コンピューティング統合クラスターのアップグレードでは、事前にレプリカの再配置を無効にする必要があります。ストレージ・コンピューティング分離モードでも必要ですか？**
+
+いいえ。ストレージ・コンピューティング分離モードでは、Doris は HDFS またはオブジェクトストレージ（S3）にデータを保存するため、レプリカの再配置に関する要件はありません。この操作は不要です。
+
+**Q2: MetaService が専用のメタデータサービスを提供しているのに、なぜ FE のメタデータもバックアップする必要があるのですか？**
+
+現時点では、MetaService と FE がそれぞれ異なる部分を担当し、共同でメタデータを管理しています。アップグレードを安全に行うため、アップグレード前に FE のメタデータディレクトリをバックアップしてください。
diff --git a/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/arrow-flight-sql.md b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/arrow-flight-sql.md
new file mode 100644
index 00000000000..bd2c080a96e
--- /dev/null
+++ b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/arrow-flight-sql.md
@@ -0,0 +1,778 @@
+---
+{
+ "title": "Arrow Flight SQL による高速データ転送",
+ "sidebar_label": "Arrow Flight SQL",
+ "language": "ja",
+ "description": "Doris から大量のデータを高速に読み取る方法を説明します。Arrow Flight SQL プロトコルを使用すると、Python/Java クライアントは Arrow の列指向形式でデータを直接取得でき、シナリオによっては MySQL/JDBC より数十倍から数百倍高速です。BI ツールとの連携と一般的なエラーの対処方法も紹介します。",
+ "keywords": [
+ "Arrow Flight SQL",
+ "ADBC Driver",
+ "Doris の列指向読み取り",
+ "pydoris",
+ "jdbc:arrow-flight-sql",
+ "flight-sql-jdbc-core",
+ "Doris の高速データ転送",
+ "i/o timeout",
+ "invalid bearer token",
+ "parameter ordinal 1 out of range"
+ ]
+}
+---
+
+<!-- Knowledge type: Capability definition + Operation steps + Troubleshooting -->
+<!-- Applicable scenarios: High-speed read of Doris data / Python/Java integration / BI tool integration / Troubleshooting -->
+
+:::caution 実験的機能
+このドキュメントで説明する Arrow Flight SQL による高速データ転送は、現在**実験的機能**です。本番環境での使用は推奨しません。使用中に問題が発生した場合は、メーリングリストまたは [GitHub Issue](https://github.com/apache/doris/issues/65615) で報告してください。
+:::
+
+Doris 2.1 以降、Arrow Flight SQL プロトコルを使用した高速データ転送経路が実装され、複数の言語から SQL を使って Doris の大量のデータを高速に読み取れるようになりました。MySQL Client や JDBC/ODBC ドライバーを使用する方法と比べ、一部のシナリオでは性能が数十倍から数百倍向上します。Arrow Flight SQL は、同じプロトコルに対応するデータベースと連携できる汎用 JDBC ドライバーも提供します。
+
+## 適用シナリオ
+
+- Doris から大規模なデータを一括エクスポートして分析する場合（MySQL/JDBC プロトコルと比較して数十倍から数百倍の性能向上）。
+- 後続のデータ分析で Apache Arrow や Pandas などの列指向形式を使用し、行指向から列指向への変換コストを避けたい場合。
+- DBeaver などの BI ツールから Arrow Flight SQL プロトコルを使用して Doris にアクセスする場合。
+- Spark や Flink などのビッグデータコンポーネントから、Doris のデータを Arrow 形式で高速に読み取る場合。
+
+## 実装の仕組み
+
+<!-- Knowledge type: Architecture principle -->
+
+Doris では、クエリ結果は列指向形式の Block として保持されます。2.1 より前のバージョンでは、MySQL Client または JDBC/ODBC ドライバーを介して結果をクライアントに送信する際に、列指向の Block を行指向のバイト列にシリアライズし、クライアント側で再び列指向形式にデシリアライズする必要がありました。
+
+Arrow Flight SQL による高速データ転送では、クライアントも Arrow の列指向形式に対応していれば、転送の全過程でシリアライズとデシリアライズを回避でき、それらに伴う時間と性能上のコストをなくせます。
+
+
+
+参考資料:
+
+- Apache Arrow の公式インストールガイド: [Apache Arrow](https://arrow.apache.org/install/)
+- Doris における Arrow Flight プロトコルの実装: [Doris support Arrow Flight SQL protocol](https://github.com/apache/doris/issues/25514)
+
+## サーバー側の設定
+
+<!-- Knowledge type: Configuration parameters -->
+<!-- Applicable scenarios: Pre-deployment preparation -->
+
+Arrow Flight SQL を使用する前に、Doris の FE と BE で Arrow Flight SQL サービスを有効にする必要があります。
+
+1. `arrow_flight_sql_port` を `fe/conf/fe.conf` で変更し、`8070` などの使用可能なポートに設定します。
+2. `arrow_flight_sql_port` を `be/conf/be.conf` で変更し、`8050` などの使用可能なポートに設定します。
+3. クラスターを再起動します。
+
+:::caution
+`arrow_flight_sql_port` は、`fe.conf` と `be.conf` で異なる値に設定してください。
+:::
+
+正常に起動したことを確認する方法:
+
+| 役割 | ログファイル | 確認する文字列 |
+| ---- | ---------------- | ------------------------------------- |
+| FE | `fe/log/fe.log` | `Arrow Flight SQL service is started` |
+| BE | `be/log/be.INFO` | `Arrow Flight Service bind to host` |
+
+## Python での使用方法
+
+<!-- Knowledge type: Operation steps -->
+<!-- Applicable scenarios: Python application integration with Doris -->
+
+Python ADBC Driver を使用して Doris に接続すると、データを非常に高速に読み取れます。必要な Python のバージョンは 3.9 以上です。以下では、ADBC Driver を使用した DDL、DML、セッション変数の設定、SHOW 文など、一般的なデータベース操作を示します。
+
+### 1. 依存ライブラリのインストール
+
+ADBC Driver は PyPI で公開されており、`pip` でインストールできます。
+
+```bash
+pip install adbc_driver_manager
+pip install adbc_driver_flightsql
+```
+
+コードでは、次のモジュールをインポートして使用します。
+
+```Python
+import adbc_driver_manager
+import adbc_driver_flightsql.dbapi as flight_sql
+
+>>> print(adbc_driver_manager.__version__)
+1.1.0
+>>> print(adbc_driver_flightsql.__version__)
+1.1.0
+```
+
+### 2. 接続の確立
+
+Doris の Arrow Flight SQL サービスと通信するクライアントを作成するには、FE のホスト、Arrow Flight のポート、ユーザー名、パスワードを指定します。
+
+FE と BE の Arrow Flight SQL サービスがそれぞれポート `8070` と `8050` で動作し、ユーザー名とパスワードが `user` と `pass` であるとします。接続手順は次のとおりです。
+
+```Python
+conn = flight_sql.connect(uri="grpc://{FE_HOST}:{fe.conf:arrow_flight_sql_port}", db_kwargs={
+ adbc_driver_manager.DatabaseOptions.USERNAME.value: "user",
+ adbc_driver_manager.DatabaseOptions.PASSWORD.value: "pass",
+ })
+cursor = conn.cursor()
+```
+
+接続後は、返された Cursor を使用して SQL で Doris を操作し、テーブルの作成、メタデータの取得、データの取り込み、クエリなどを実行できます。
+
+### 3. DDL の実行とメタデータの取得
+
+`cursor.execute()` 関数に SQL を渡して、テーブルの作成やメタデータの取得を実行します。
+
+```Python
+cursor.execute("DROP DATABASE IF EXISTS arrow_flight_sql FORCE;")
+print(cursor.fetchallarrow().to_pandas())
+
+cursor.execute("create database arrow_flight_sql;")
+print(cursor.fetchallarrow().to_pandas())
+
+cursor.execute("show databases;")
+print(cursor.fetchallarrow().to_pandas())
+
+cursor.execute("use arrow_flight_sql;")
+print(cursor.fetchallarrow().to_pandas())
+
+cursor.execute("""CREATE TABLE arrow_flight_sql_test
+ (
+ k0 INT,
+ k1 DOUBLE,
+ K2 varchar(32) NULL DEFAULT "" COMMENT "",
+ k3 DECIMAL(27,9) DEFAULT "0",
+ k4 BIGINT NULL DEFAULT '10',
+ k5 DATE,
+ )
+ DISTRIBUTED BY HASH(k5) BUCKETS 5
+ PROPERTIES("replication_num" = "1");""")
+print(cursor.fetchallarrow().to_pandas())
+
+cursor.execute("show create table arrow_flight_sql_test;")
+print(cursor.fetchallarrow().to_pandas())
+```
+
+`StatusResult` が `0` を返した場合、クエリは正常に実行されています（この仕様は JDBC との互換性のためです）。
+
+```text
+ StatusResult
+0 0
+
+ StatusResult
+0 0
+
+ Database
+0 __internal_schema
+1 arrow_flight_sql
+.. ...
+507 udf_auth_db
+
+[508 rows x 1 columns]
+
+ StatusResult
+0 0
+
+ StatusResult
+0 0
+ Table Create Table
+0 arrow_flight_sql_test CREATE TABLE `arrow_flight_sql_test` (\n `k0`...
+```
+
+### 4. データの取り込み
+
+`INSERT INTO` を実行して、作成したテーブルに少量のテストデータを取り込みます。
+
+```Python
+cursor.execute("""INSERT INTO arrow_flight_sql_test VALUES
+ ('0', 0.1, "ID", 0.0001, 9999999999, '2023-10-21'),
+ ('1', 0.20, "ID_1", 1.00000001, 0, '2023-10-21'),
+ ('2', 3.4, "ID_1", 3.1, 123456, '2023-10-22'),
+ ('3', 4, "ID", 4, 4, '2023-10-22'),
+ ('4', 122345.54321, "ID", 122345.54321, 5, '2023-10-22');""")
+print(cursor.fetchallarrow().to_pandas())
+```
+
+次の出力は、取り込みが成功したことを示します。
+
+```text
+ StatusResult
+0 0
+```
+
+:::tip
+Doris に大量のデータを取り込む場合は、`pydoris` で Stream Load を実行することを推奨します。
+:::
+
+### 5. クエリの実行
+
+取り込んだデータを、集計、並べ替え、セッション変数の設定を含めてクエリします。
+
+```Python
+cursor.execute("select * from arrow_flight_sql_test order by k0;")
+print(cursor.fetchallarrow().to_pandas())
+
+cursor.execute("set exec_mem_limit=2000;")
+print(cursor.fetchallarrow().to_pandas())
+
+cursor.execute("show variables like \"%exec_mem_limit%\";")
+print(cursor.fetchallarrow().to_pandas())
+
+cursor.execute("select k5, sum(k1), count(1), avg(k3) from arrow_flight_sql_test group by k5;")
+print(cursor.fetch_df())
+```
+
+出力:
+
+```text
+ k0 k1 K2 k3 k4 k5
+0 0 0.10000 ID 0.000100000 9999999999 2023-10-21
+1 1 0.20000 ID_1 1.000000010 0 2023-10-21
+2 2 3.40000 ID_1 3.100000000 123456 2023-10-22
+3 3 4.00000 ID 4.000000000 4 2023-10-22
+4 4 122345.54321 ID 122345.543210000 5 2023-10-22
+
+[5 rows x 6 columns]
+
+ StatusResult
+0 0
+
+ Variable_name Value Default_Value Changed
+0 exec_mem_limit 2000 2147483648 1
+
+ k5 Nullable(Float64)_1 Int64_2 Nullable(Decimal(38, 9))_3
+0 2023-10-22 122352.94321 3 40784.214403333
+1 2023-10-21 0.30000 2 0.500050005
+
+[2 rows x 5 columns]
+```
+
+:::caution
+結果を列指向形式のまま取得するには、次のいずれかの方法を使用します。
+
+- `cursor.fetchallarrow()`: Arrow 形式で返します。
+- `cursor.fetch_df()`: Pandas DataFrame を直接返します。
+
+`cursor.fetchall()` は使用しないでください。列指向データを行指向形式に戻すため、実質的に mysql-client を使用する場合と同じになります。クライアント側で列から行への変換が増える分、mysql-client より遅くなることもあります。
+:::
+
+### 6. 完全なサンプル
+
+```Python
+# Doris Arrow Flight SQL Test
+
+# step 1, library is released on PyPI and can be easily installed.
+# pip install adbc_driver_manager
+# pip install adbc_driver_flightsql
+import adbc_driver_manager
+import adbc_driver_flightsql.dbapi as flight_sql
+
+# step 2, create a client that interacts with the Doris Arrow Flight SQL service.
+# Modify arrow_flight_sql_port in fe/conf/fe.conf to an available port, such as 8070.
+# Modify arrow_flight_sql_port in be/conf/be.conf to an available port, such as 8050.
+conn = flight_sql.connect(uri="grpc://{FE_HOST}:{fe.conf:arrow_flight_sql_port}", db_kwargs={
+ adbc_driver_manager.DatabaseOptions.USERNAME.value: "root",
+ adbc_driver_manager.DatabaseOptions.PASSWORD.value: "",
+ })
+cursor = conn.cursor()
+
+# interacting with Doris via SQL using Cursor
+def execute(sql):
+ print("\n### execute query: ###\n " + sql)
+ cursor.execute(sql)
+ print("### result: ###")
+ print(cursor.fetchallarrow().to_pandas())
+
+# step3, execute DDL statements, create database/table, show stmt.
+execute("DROP DATABASE IF EXISTS arrow_flight_sql FORCE;")
+execute("show databases;")
+execute("create database arrow_flight_sql;")
+execute("show databases;")
+execute("use arrow_flight_sql;")
+execute("""CREATE TABLE arrow_flight_sql_test
+ (
+ k0 INT,
+ k1 DOUBLE,
+ K2 varchar(32) NULL DEFAULT "" COMMENT "",
+ k3 DECIMAL(27,9) DEFAULT "0",
+ k4 BIGINT NULL DEFAULT '10',
+ k5 DATE,
+ )
+ DISTRIBUTED BY HASH(k5) BUCKETS 5
+ PROPERTIES("replication_num" = "1");""")
+execute("show create table arrow_flight_sql_test;")
+
+
+# step4, insert into
+execute("""INSERT INTO arrow_flight_sql_test VALUES
+ ('0', 0.1, "ID", 0.0001, 9999999999, '2023-10-21'),
+ ('1', 0.20, "ID_1", 1.00000001, 0, '2023-10-21'),
+ ('2', 3.4, "ID_1", 3.1, 123456, '2023-10-22'),
+ ('3', 4, "ID", 4, 4, '2023-10-22'),
+ ('4', 122345.54321, "ID", 122345.54321, 5, '2023-10-22');""")
+
+
+# step5, execute queries, aggregation, sort, set session variable
+execute("select * from arrow_flight_sql_test order by k0;")
+execute("set exec_mem_limit=2000;")
+execute("show variables like \"%exec_mem_limit%\";")
+execute("select k5, sum(k1), count(1), avg(k3) from arrow_flight_sql_test group by k5;")
+
+# step6, close cursor
+cursor.close()
+```
+
+## Java での使用方法
+
+<!-- Knowledge type: Operation steps + Architecture selection decision -->
+<!-- Applicable scenarios: Java application integration with Doris -->
+
+Java では三種類の接続方法を選択できます。それぞれの特徴と選択の目安は次のとおりです。
+
+| 接続方法 | URL 形式 | 戻り値の形式 | 推奨するシナリオ |
+| ----------------------------------- | ----------------------------- | ---------------------- | ------------------------------------------------------------------- |
+| **JDBC (`jdbc:arrow-flight-sql`)** | `jdbc:arrow-flight-sql://...` | JDBC ResultSet（行指向） | 後続の分析で**行指向形式**を使用する場合、または BI ツールや既存の JDBC コードとの互換性が必要な場合 |
+| **Flight ADBC Driver** | `grpc://...` | Arrow（列指向） | 後続の分析で **Arrow / 列指向形式**を使用し、性能を重視する場合 |
+| **Flight JDBC Driver（ADBC ラッパー）** | `jdbc:arrow-flight-sql://...` | Arrow（列指向） | Flight ADBC Driver と同じ用途で、プロジェクト内で `jdbc:arrow-flight-sql` 形式の URL を使い続ける必要がある場合 |
+
+接続方法ごとの性能を試すには、[JDBC/Java Arrow Flight SQL Sample](https://github.com/apache/doris/blob/master/samples/arrow-flight-sql/java/README.md) のデモを参照してください。想定される結果は [Add Arrow Flight Sql demo for Java](https://github.com/apache/doris/pull/45306) に記載されています。Java の Arrow Flight SQL 接続方法と従来の `jdbc:mysql` の性能比較については、[GitHub Issue 25514（セクション 6.2）](https://github.com/apache/doris/issues/25514) を参照してください。
+
+**その他の推奨事項:**
+
+- JDBC の `ResultSet` と Arrow データのどちらを解析する場合も、解析時間はデータの読み取り自体にかかる時間より長くなります。Arrow Flight SQL による `jdbc:mysql://` からの性能向上が小さい場合は、まずデータ解析に時間がかかりすぎていないか確認してください。
+- どの接続方法でも、JDK 17 のほうが JDK 1.8 より高速にデータを読み取れます。
+- データ量が非常に多い場合、Arrow Flight SQL は `jdbc:mysql://` よりメモリ使用量が少なくなります。メモリに制約がある場合は、Arrow Flight SQL を先に試してください。
+- 上記の三種類の方法に加え、ネイティブの `FlightClient` を使用して Arrow Flight Server に直接接続することもできます。この方法は柔軟性が高く、複数の Endpoint からの並列読み取りに対応します。Flight ADBC Driver 自体も `FlightClient` に基づいて接続を作成しますが、`FlightClient` を直接使うより簡単です。
+
+:::caution
+Java 9 以降を使用する場合は、JDK 内部の一部にアクセスできるように、Java コマンドに `--add-opens=java.base/java.nio=ALL-UNNAMED` を追加する必要があります。追加しないと、次のいずれかのエラーが発生します。
+
+- `module java.base does not "opens java.nio" to unnamed module`
+- `module java.base does not "opens java.nio" to org.apache.arrow.memory.core`
+- `java.lang.NoClassDefFoundError: Could not initialize class org.apache.arrow.memory.util.MemoryUtil (Internal; Prepare)`
+
+このオプションは次の二通りの方法で追加できます。
+
+```shell
+# Option 1: Add via command-line argument directly
+$ java --add-opens=java.base/java.nio=ALL-UNNAMED -jar ...
+
+# Option 2: Add via environment variable
+$ env _JAVA_OPTIONS="--add-opens=java.base/java.nio=ALL-UNNAMED" java -jar ...
+```
+
+IntelliJ IDEA でデバッグする場合は、`Build and run` にこの引数を追加します。この項目は `Run/Debug Configurations` にあります。次の図を参照してください。
+
+
+:::
+
+### 方法 1: `jdbc:arrow-flight-sql`
+
+Arrow Flight SQL プロトコル向けのオープンソース JDBC ドライバーは、標準の JDBC API と互換性があります。ほとんどの BI ツールが JDBC 経由で Doris にアクセスでき、Apache Arrow データの高速転送にも対応します。使用方法は MySQL JDBC ドライバーと似ています。接続 URL の `jdbc:mysql` プロトコルを `jdbc:arrow-flight-sql` に置き換えるだけです。クエリ結果は引き続き JDBC の `ResultSet` データ構造で返されます。
+
+POM の依存関係:
+
+```xml
+<properties>
+ <arrow.version>17.0.0</arrow.version>
+</properties>
+<dependencies>
+ <dependency>
+ <groupId>org.apache.arrow</groupId>
+ <artifactId>flight-sql-jdbc-core</artifactId>
+ <version>${arrow.version}</version>
+ </dependency>
+</dependencies>
+```
+
+接続コードの例:
+
+```Java
+import java.sql.Connection;
+import java.sql.DriverManager;
+import java.sql.ResultSet;
+import java.sql.Statement;
+
+Class.forName("org.apache.arrow.driver.jdbc.ArrowFlightJdbcDriver");
+String DB_URL = "jdbc:arrow-flight-sql://{FE_HOST}:{fe.conf:arrow_flight_sql_port}?useServerPrepStmts=false"
+ + "&cachePrepStmts=true&useSSL=false&useEncryption=false";
+String USER = "root";
+String PASS = "";
+
+Connection conn = DriverManager.getConnection(DB_URL, USER, PASS);
+Statement stmt = conn.createStatement();
+ResultSet resultSet = stmt.executeQuery("select * from information_schema.tables;");
+while (resultSet.next()) {
+ System.out.println(resultSet.toString());
+}
+
+resultSet.close();
+stmt.close();
+conn.close();
+```
+
+### 方法 2: Flight ADBC Driver / Flight JDBC Driver
+
+JDBC のほかに、Java では Driver を作成して Doris から直接データを読み取り、Arrow 形式で返すこともできます。以下の例では、ADBC Driver と JDBC Driver（ADBC ラッパー）を使用して Doris Arrow Flight Server に接続する方法を示します。
+
+POM の依存関係:
+
+```xml
+<properties>
+ <adbc.version>0.15.0</adbc.version>
+</properties>
+
+<dependencies>
+ <dependency>
+ <groupId>org.apache.arrow.adbc</groupId>
+ <artifactId>adbc-driver-jdbc</artifactId>
+ <version>${adbc.version}</version>
+ </dependency>
+ <dependency>
+ <groupId>org.apache.arrow.adbc</groupId>
+ <artifactId>adbc-core</artifactId>
+ <version>${adbc.version}</version>
+ </dependency>
+ <dependency>
+ <groupId>org.apache.arrow.adbc</groupId>
+ <artifactId>adbc-driver-manager</artifactId>
+ <version>${adbc.version}</version>
+ </dependency>
+ <dependency>
+ <groupId>org.apache.arrow.adbc</groupId>
+ <artifactId>adbc-sql</artifactId>
+ <version>${adbc.version}</version>
+ </dependency>
+ <dependency>
+ <groupId>org.apache.arrow.adbc</groupId>
+ <artifactId>adbc-driver-flight-sql</artifactId>
+ <version>${adbc.version}</version>
+ </dependency>
+</dependencies>
+```
+
+#### Flight ADBC Driver
+
+接続コードの例:
+
+```Java
+// 1. new driver
+final BufferAllocator allocator = new RootAllocator();
+FlightSqlDriver driver = new FlightSqlDriver(allocator);
+Map<String, Object> parameters = new HashMap<>();
+AdbcDriver.PARAM_URI.set(parameters, Location.forGrpcInsecure("{FE_HOST}", {fe.conf:arrow_flight_sql_port}).getUri().toString());
+AdbcDriver.PARAM_USERNAME.set(parameters, "root");
+AdbcDriver.PARAM_PASSWORD.set(parameters, "");
+AdbcDatabase adbcDatabase = driver.open(parameters);
+
+// 2. new connection
+AdbcConnection connection = adbcDatabase.connect();
+AdbcStatement stmt = connection.createStatement();
+
+// 3. execute query
+stmt.setSqlQuery("select * from information_schema.tables;");
+QueryResult queryResult = stmt.executeQuery();
+ArrowReader reader = queryResult.getReader();
+
+// 4. load result
+List<String> result = new ArrayList<>();
+while (reader.loadNextBatch()) {
+ VectorSchemaRoot root = reader.getVectorSchemaRoot();
+ String tsvString = root.contentToTSVString();
+ result.add(tsvString);
+}
+System.out.printf("batchs %d\n", result.size());
+
+// 5. close
+reader.close();
+queryResult.close();
+stmt.close();
+connection.close();
+```
+
+#### Flight JDBC Driver（ADBC ラッパー）
+
+接続コードの例:
+
+```Java
+final Map<String, Object> parameters = new HashMap<>();
+AdbcDriver.PARAM_URI.set(
+ parameters,"jdbc:arrow-flight-sql://{FE_HOST}:{fe.conf:arrow_flight_sql_port}?useServerPrepStmts=false&cachePrepStmts=true&useSSL=false&useEncryption=false");
+AdbcDriver.PARAM_USERNAME.set(parameters, "root");
+AdbcDriver.PARAM_PASSWORD.set(parameters, "");
+try (
+ BufferAllocator allocator = new RootAllocator();
+ AdbcDatabase db = new JdbcDriver(allocator).open(parameters);
+ AdbcConnection connection = db.connect();
+ AdbcStatement stmt = connection.createStatement()
+) {
+ stmt.setSqlQuery("select * from information_schema.tables;");
+ AdbcStatement.QueryResult queryResult = stmt.executeQuery();
+ ArrowReader reader = queryResult.getReader();
+ List<String> result = new ArrayList<>();
+ while (reader.loadNextBatch()) {
+ VectorSchemaRoot root = reader.getVectorSchemaRoot();
+ String tsvString = root.contentToTSVString();
+ result.add(tsvString);
+ }
+ long etime = System.currentTimeMillis();
+ System.out.printf("batchs %d\n", result.size());
+
+ reader.close();
+ queryResult.close();
+ stmt.close();
+} catch (Exception e) {
+ e.printStackTrace();
+}
+```
+
+## 型の対応関係
+
+<!-- Knowledge type: Behavior description -->
+<!-- Applicable scenarios: Parsing Arrow results on the client -->
+
+:::caution 動作の変更（4.1.4）
+
+バージョン 4.1.4 以降、Arrow Flight SQL が返す `DATETIME` / `DATETIMEV2` の値は、**タイムゾーン情報を持たない** Arrow タイムスタンプです。一方、`TIMESTAMPTZ` は引き続きタイムゾーン情報を持つタイムスタンプとして返されます。
+
+4.1.4 より前は、`DATETIME` にタイムゾーン情報があると示されていたため、クライアントがローカルタイムゾーンで解析すると余分なタイムゾーンオフセットが適用されていました。アップグレード後は、`DATETIME` 列をタイムゾーン情報のないローカル時刻の値として解析してください。
+
+同じバージョンでは、次の型メタデータも修正されています。
+
+- `GetTables` メタデータエンドポイントで、`DATEV2` の Arrow 型が `Date(MILLISECOND)` から `Date(DAY)` に修正されました。
+- `ARRAY` / `MAP` / `STRUCT` のメタデータは、プレースホルダーの型ではなく、実際の子フィールドの型を返すようになりました。
+
+:::
+
+## サードパーティーコンポーネントとの連携
+
+<!-- Knowledge type: Integration solution -->
+<!-- Applicable scenarios: BI tool / Spark / Flink integration -->
+
+### BI ツール（DBeaver など）
+
+Doris v2.1.8 以降、DBeaver などの BI ツールは `arrow-flight-sql` プロトコルを使用して Doris に接続できます。設定方法は、次を参照してください。
+
+- [DBeaver クライアントで JDBC ドライバーを使用する方法](https://www.dremio.com/blog/jdbc-driver-for-arrow-flight-sql/#h-how-to-use-jdbc-driver-with-dbeaver-client)
+- [Dremio Sonar - クライアントアプリケーション: DBeaver](https://docs.dremio.com/current/sonar/client-applications/clients/dbeaver/?_gl=1*1epgwh0*_gcl_au*MjUyNjE1ODM0LjE3MzQwMDExNDg)
+
+### Spark and Flink
+
+Arrow Flight には、Spark と Flink を公式にサポートする計画はありません（[GitHub Issue](https://github.com/apache/arrow-adbc/issues/1490) を参照）。ただし、バージョン 24.0.0 以降、以下のコネクターは Arrow Flight SQL を介した Doris へのアクセスに対応しており、読み取り性能が数倍向上することが期待されます。
+
+- [Doris Spark Connector](https://github.com/apache/doris-spark-connector)
+- [Doris Flink Connector](https://github.com/apache/doris-flink-connector)
+
+コミュニティでは以前、[Spark-Flight-Connector](https://github.com/qwshen/spark-flight-connector) を参考に、Spark から `FlightClient` を介して Doris に接続するテストを行いました。その結果は次のとおりです。
+
+- Arrow と Doris Block 間の変換は、CSV と Doris Block 間の変換より 10 倍高速です。
+- Arrow は Map や Array などの複合型への対応が優れています。
+- Arrow データは圧縮率が高く、転送時のネットワーク負荷を抑えられます。
+
+ただし、Doris Arrow Flight には、複数ノードからの並列読み取りがまだ実装されていません。クエリ結果は返却前に単一の BE ノードに集約されます。単純な大量データのエクスポートでは、Tablet 単位の並列読み取りに対応する Doris Spark Connector より性能が低い場合があります。
+
+Spark から Arrow Flight SQL を使用して Doris に接続する機能を独自に実装する場合は、次のオープンソースプロジェクトを参考にできます。
+
+- [Spark-Flight-Connector](https://github.com/qwshen/spark-flight-connector)
+- [Dremio-Flight-Connector](https://github.com/dremio-hub/dremio-flight-connector)
+
+## 高度な設定
+
+<!-- Knowledge type: Configuration parameters + Deployment solution -->
+<!-- Applicable scenarios: Performance tuning / Complex deployment topologies -->
+
+### 複数 BE からの並列結果返却
+
+Doris はデフォルトで、すべての BE ノードからのクエリ結果を単一の BE ノードに集約します。プロトコルごとの動作は次のとおりです。
+
+- **MySQL/JDBC クエリ**: FE が、結果を集約した BE ノードからクエリ結果を取得します。
+- **Arrow Flight SQL クエリ**: FE がその BE ノードの IP/ポートを Endpoint に格納し、ADBC Client に返します。ADBC Client は、その Endpoint からデータを取得します。
+
+#### シナリオ 1: 単純な SELECT による取得（Join/Sort/ウィンドウ関数なし）
+
+クエリが、Join、Sort、ウィンドウ関数などのデータの再分配を伴う演算子を使用しない単純な SELECT であれば、Tablet 単位で分割できます。Doris Spark/Flink Connector は、この方法で次の二段階により並列読み取りを実現します。
+
+1. `EXPLAIN SQL` を実行します。FE が返すクエリプランには、ScanOperator 内に Tablet ID の完全なリストが含まれます。
+2. その Tablet ID リストに基づき、元の SQL を複数の SQL 文に分割します。それぞれが一部の Tablet だけを読み取るようにします。例:
+
+ ```sql
+ SELECT * FROM t1 TABLET(10001,10002) limit 1000;
+ ```
+
+ 分割した SQL 文は並列に実行できます。詳細は [Support select table sample](https://github.com/apache/doris/pull/10170) を参照してください。
+
+#### シナリオ 2: 最外層で集計するクエリ
+
+`select k1, sum(k2) from xxx group by k1` のようなクエリでは、Doris v3.0.4 以降、次の設定によって各 BE ノードがそれぞれの結果を返せます。
+
+```sql
+set enable_parallel_result_sink=true;
+```
+
+FE から返された Endpoint のリストを受け取ると、ADBC Client は複数の BE ノードから結果を並列に取得します。実装の詳細は [support parallel result sink](https://github.com/apache/doris/pull/36053) を参照してください。
+
+:::caution
+集計結果が小さい場合、複数の BE から結果を返すと RPC の負荷が増加します。
+:::
+
+理論上は、最外層で並べ替えを行うクエリ以外なら、BE ノードごとの並列結果返却に対応できます。ただし、これはまだ実装されていません。
+
+### 複数の BE が同じ外部アクセス IP を共有する場合
+
+FE ノードにはクラスター外部からアクセスできるものの、すべての BE ノードにはクラスター内部からしかアクセスできない構成があります。
+
+- MySQL Client または JDBC で Doris に接続してクエリを実行する場合、結果は FE から返されるため動作します。
+- Arrow Flight SQL で Doris に接続する場合、ADBC Client が結果の取得のため BE ノードに直接接続する必要があるため、クエリを実行できません。
+
+本番環境では、BE ノードをクラスター外部に公開することが難しい場合が一般的です。すべての BE ノードの前段に Nginx などのリバースプロキシを配置すると、Nginx に接続した外部クライアントを BE ノードのいずれかにランダムに振り分けられます。ただし、Arrow Flight SQL のクエリ結果は、デフォルトで特定の BE ノードにランダムに保存されます。そのノードと Nginx が振り分けたノードが異なる場合、BE 内部でデータを転送する処理が発生します。
+
+Doris v2.1.8 以降、`public_host` と `arrow_flight_sql_proxy_port` を、すべての BE ノードの `be.conf` で複数の BE が共有する外部アクセス用 IP とポートに設定できます。クエリ結果は適切に転送され、ADBC Client に返されます。
+
+```conf
+public_host={nginx ip}
+arrow_flight_sql_proxy_port={nginx port}
+```
+
+## FAQ
+
+<!-- Knowledge type: Troubleshooting -->
+<!-- Applicable scenarios: Error diagnosis / Compatibility issues -->
+
+### 1. エラー `i/o timeout`
+
+**Q:** エラーメッセージの全文は `connection error: desc = "transport: Error while dialing: dial tcp <ip:arrow_flight_port>: i/o timeout"` です。
+
+**A:** エラーメッセージ中の `<ip:arrow_flight_port>` が示すノードの役割に応じて、次の二つの場合に分けて調査します。
+
+**ケース 1: `<ip:arrow_flight_port>` が FE ノードの IP と `arrow_flight_port` を示す場合**
+
+1. FE ノードの Arrow Flight Server が正常に起動したか確認します。`Arrow Flight SQL service is started` が `fe/log/fe.log` にあれば、正常に起動しています。
+2. FE の Arrow Flight Server が正常に起動している場合は、クライアントマシンからこの IP に `ping` できるか確認します。到達できない場合は、FE ノードに外部からアクセス可能な IP を設定し、クラスターを再デプロイする必要があります。
+
+**ケース 2: `<ip:arrow_flight_port>` が BE ノードの IP と `arrow_flight_port` を示す場合**
+
+1. BE ノードの Arrow Flight Server が正常に起動したか確認します。`Arrow Flight Service bind to host` が `be/log/be.INFO` にあれば、正常に起動しています。
+2. BE の Arrow Flight Server が正常に起動している場合は、クライアントマシンからこの IP に `ping` できるか確認します。
+
+BE ノードがクラスターの内部ネットワーク上にあることが分かっている場合は、次のいずれかの方法を使用します。
+
+- 各 BE ノードに外部からアクセス可能な IP を設定します。Doris v2.1.8 以降は、`public_host` をその BE ノードの `be.conf` でこの IP に設定します。同様に、すべての BE ノードの `public_host` を、それぞれクライアントからアクセスできる IP に設定します。
+- [複数の BE が同じ外部アクセス IP を共有する場合](#multiple-bes-sharing-the-same-external-access-ip) を参照し、すべての BE ノードの前段にリバースプロキシを配置します。
+
+BE が完全に内部ネットワーク上にあるか不明な場合は、次の手順で確認します。
+
+1. BE ノードのマシンで `ifconfig` を実行し、すべての IP を確認します。そのうちの一つは `<ip:arrow_flight_port>` の IP、および `show backends` に表示される IP と一致するはずです。
+2. `ping` を使用して、`ifconfig` で得た他の各 IP への到達性をクライアントから順に確認します。
+3. クライアントから到達可能な IP があれば、それを `public_host` に設定します。いずれにも到達できなければ、BE ノードは完全に内部ネットワーク上にあります。
+
+### 2. JDBC または Java で Arrow Flight SQL に接続するときのエラー `module java.base does not "opens java.nio"...`
+
+**Q:** 次のいずれかのエラーが発生する場合があります。
+
+- `module java.base does not "opens java.nio" to unnamed module`
+- `module java.base does not "opens java.nio" to org.apache.arrow.memory.core`
+- `java.lang.NoClassDefFoundError: Could not initialize class org.apache.arrow.memory.util.MemoryUtil (Internal; Prepare)`
+
+**A:** 次のように対処します。
+
+1. `JAVA_OPTS_FOR_JDK_17` は `fe/conf/fe.conf` にある設定です。この設定に `--add-opens=java.base/java.nio=ALL-UNNAMED` が含まれているか確認し、含まれていなければ追加します。
+2. [Java での使用方法](#java-usage) を参照し、Java コマンドに `--add-opens=java.base/java.nio=ALL-UNNAMED` を追加します。
+3. IntelliJ IDEA でデバッグする場合は、`--add-opens=java.base/java.nio=ALL-UNNAMED` を `Build and run` に追加します。この項目は `Run/Debug Configurations` にあります。
+
+### 3. ARM 環境でのエラー `arrow flight schema timeout`
+
+**Q:** エラーメッセージの全文は `get flight info statement failed, arrow flight schema timeout, TimeoutException: Waited 5000 milliseconds for io.grpc.stub.Client` です。
+
+**A:** Linux カーネルのバージョンが 4.19.90 以下の場合は、4.19.279 以降にアップグレードするか、古いバージョンの Linux カーネル環境で Doris BE を再コンパイルする必要があります。具体的なコンパイル方法は、`docs/dev/install/source-install/compilation-arm` を参照してください。
+
+**原因:** 古い Linux カーネルには Arrow との互換性の問題があります。`cpp: arrow::RecordBatch::MakeEmpty()` が Arrow Record Batch の構築中に停止するため、BE の Arrow Flight Server は 5000ms 以内に FE の RPC リクエストに応答できず、FE がクライアントに RPC タイムアウトエラーを返します。Spark と Flink も Doris の読み取り時にクエリ結果を Arrow Record Batch に変換して返すため、同じ問題が発生します。
+
+KylinV10 SP2 と SP3 の Linux カーネルは `4.19.90-24.4.v2101.ky10.aarch64` までしか提供されず、それ以降にアップグレードできません。そのため、KylinV10 上で Doris BE を再コンパイルする必要があります。新しい `ldb_toolchain` でコンパイルしても問題が続く場合は、古い `ldb_toolchain v0.17` を試してください。ARM 環境からインターネットに接続できない場合、Huawei Cloud は ARM + KylinV10、Alibaba Cloud は x86 + KylinV10 の環境を提供しています。
+
+### 4. Prepared Statement のパラメーター指定エラー
+
+**Q:** Prepared Statement でパラメーターを指定する場合（例: `select * from xxx where id=?`）、`parameter ordinal 1 out of range` というエラーが発生します。
+
+**A:** 現在、`jdbc:arrow-flight-sql` と Java ADBC/JDBC Driver は、Prepared Statement によるパラメーター指定に対応していません。これは Arrow Flight SQL のバグです。詳細は [GitHub Issue](https://github.com/apache/arrow/issues/40118) を参照してください。
+
+### 5. `jdbc:arrow-flight-sql` のバッチごとの読み取りサイズを変更する方法
+
+**Q:** シナリオによっては、性能を向上させるためにバッチサイズを変更する必要があります。
+
+**A:** `setTargetBatchSize` を、`makeJdbcConfig` メソッド（`org.apache.arrow.adbc.driver.jdbc.JdbcArrowReader` 内）で変更します。デフォルトは `1024` です。その後、変更したファイルを同じパスのローカルディレクトリに保存して元のファイルを上書きすると、変更が反映されます。
+
+### 6. ADBC v0.10 は並列読み取りに非対応
+
+**Q:** ADBC v0.10 の JDBC と Java ADBC/JDBC Driver は並列読み取りに対応していますか。
+
+**A:** いいえ。`stmt.executePartitioned()` メソッドが実装されていないためです。複数の Endpoint から並列に読み取るには、ネイティブの FlightClient を使用して実装する必要があります。呼び出しの流れは次のとおりです。
+
+```text
+sqlClient = new FlightSqlClient
+execute = sqlClient.execute(sql)
+endpoints = execute.getEndpoints()
+for (FlightEndpoint endpoint : endpoints) { ... }
+```
+
+また、ADBC v0.10 のデフォルトの `AdbcStatement` は実際には `JdbcStatement` です。`executeQuery` の後、行指向の JDBC `ResultSet` が Arrow の列指向形式に変換されます。Java ADBC の機能は ADBC 1.0.0 でより充実する見込みです。詳細は [GitHub Issue](https://github.com/apache/arrow-adbc/issues/1490) を参照してください。
+
+### 7. URL でのデータベース名の指定
+
+**Q:** URL にデータベース名を指定できますか。
+
+**A:** Arrow v15.0 の時点では、Arrow JDBC Connector は URL でのデータベース名の指定に対応していません。たとえば、`test` データベースを `jdbc:arrow-flight-sql://{FE_HOST}:{fe.conf:arrow_flight_sql_port}/test?useServerPrepStmts=false` で指定しても効果はありません。SQL の `use database` を手動で実行する必要があります。Arrow v18.0 では URL でのデータベース名の指定に対応していますが、実際の使用では依然としてバグがあります。
+
+### 8. Python ADBC で警告 `Cannot disable autocommit` が表示される
+
+**Q:** 警告の全文は `Warning: Cannot disable autocommit; conn will not be DB-API 2.0 compliant` です。
+
+**A:** Python を使用する場合、この警告は無視できます。Python ADBC Client 側の問題であり、クエリには影響しません。
+
+### 9. Python のエラー `grpc: received message larger than max`
+
+**Q:** エラーメッセージの全文は `grpc: received message larger than max (20748753 vs. 16777216)` です。
+
+**A:** [Python: grpc: received message larger than max #2078](https://github.com/apache/arrow-adbc/issues/2078) を参照し、Database Option に `adbc_driver_flightsql.DatabaseOptions.WITH_MAX_MSG_SIZE.value` を追加してください。
+
+### 10. エラー `invalid bearer token`
+
+**Q:** クライアントで `invalid bearer token` というエラーが発生します。
+
+**A:** 次の操作を試してください。
+
+1. 現在のユーザーの最大接続数を変更します。
+
+ ```sql
+ SET PROPERTY FOR 'root' 'max_user_connections' = '10000';
+ ```
+
+2. `fe.conf` に次の二項目を追加し、FE を再起動します。
+
+ ```conf
+ qe_max_connection=30000
+ arrow_flight_token_cache_size=8000
+ ```
+
+**原因: 長時間維持される接続の保持機構**
+
+ADBC Client と Arrow Flight Server の接続は、基本的に長時間維持される接続です。サーバーは Auth Token、Connection、Session をキャッシュする必要があります。接続は作成後、単一のクエリが終了してもすぐには閉じられません。クリーンアップには、クライアントからの `close()` リクエストが必要です。実際にはクライアントが `close()` を送信しないことが多いため、Auth Token、Connection、Session がサーバーに長期間残ります。デフォルトでは 3 日後にタイムアウトするか、接続数が `arrow_flight_token_cache_size` の上限を超えると LRU によって削除されます。
+
+**原因: デフォルトの接続数上限が小さい**
+
+Doris v2.1.8 の時点では、Arrow Flight 接続と MySQL/JDBC 接続は次の接続数上限を共有します。
+
+- FE 上の全ユーザーの合計接続数: `qe_max_connection`、デフォルトは `1024`。
+- ユーザーごとの接続数: `max_user_connections`（`UserProperty` 内）、デフォルトは `100`。
+
+Arrow Flight SQL は JDBC の代わりに使われることが多い一方、JDBC 接続はクエリの終了後すぐに解放されます。そのため、Arrow Flight SQL を使用する場合、Doris のデフォルトの接続数上限では小さすぎることがあり、接続数が `arrow_flight_token_cache_size` を超えて、使用中の接続が削除される場合があります。
+
+### 11. JDBC または Java で Datetime 型を読み取るとタイムスタンプが返される
+
+**Q:** JDBC または Java で Arrow Flight SQL に接続して Datetime 型を読み取ると、タイムスタンプ（例: `1740993808`）が書式付きの時刻（例: `2025-03-03 17:23:28Z`）の代わりに返されます。
+
+**A:** JDBC または Java で Arrow Flight SQL に接続して Datetime 型を読み取る場合は、タイムスタンプを自分で変換する必要があります。[Add java parsing datetime type in arrow flight sql sample #48578](https://github.com/apache/doris/pull/48578) を参照してください。Python Arrow Flight SQL は Datetime 型に対して `2025-03-03 17:23:28Z` を返しますが、JDBC または Java は `1740993808` を返します。
+
+### 12. JDBC または Java JDBC Client で Array のネスト型を読み取るときのエラー
+
+**Q:** エラーメッセージの全文は `Configuration does not provide a mapping for array column 2` です。
+
+**A:** [`sample/arrow-flight-sql`](https://github.com/apache/doris/blob/master/samples/arrow-flight-sql/java/src/main/java/doris/arrowflight/demo/FlightAdbcDriver.java) を参照し、Java ADBC Client に切り替えることを推奨します。
+
+Python ADBC Client、Java ADBC Client、Java JDBC DriverManager はいずれも Array のネスト型を問題なく読み取れます。この問題は、JDBC または Java JDBC Client を使用して Arrow Flight SQL に接続する場合にのみ発生します。Arrow Flight JDBC は Arrow の公式開発ではなく、サードパーティーのデータベース企業 Dremio が開発したもので、互換性が低くなります。過去にもほかの互換性の問題が見つかっているため、Java ADBC Client の使用を推奨します。
diff --git a/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/automq.md b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/automq.md
new file mode 100644
index 00000000000..9a62fbd1dee
--- /dev/null
+++ b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/automq.md
@@ -0,0 +1,174 @@
+---
+{
+ "title": "AutoMQ",
+ "language": "ja",
+ "description": "Apache Doris の Routine Load を使用して、Kafka と互換性のある AutoMQ のトピックから JSON データを消費し、リアルタイムでデータを取り込みます。"
+}
+---
+
+[AutoMQ](https://github.com/AutoMQ/automq) は、クラウド向けに再設計されたクラウドネイティブの Kafka です。ストレージをオブジェクトストレージに移すことで、Apache Kafka との 100% の互換性を維持しながら、最大 10 倍のコスト優位性と 100 倍の伸縮性を実現します。革新的な共有ストレージアーキテクチャにより、高スループットと低レイテンシーを維持しながら、秒単位のパーティション移行、トラフィックの自動分散、秒単位の自動スケーリングを実現します。
+
+このドキュメントでは、Apache Doris の Routine Load を使用して、Kafka と互換性のある AutoMQ のトピックから JSON データを消費し、Doris テーブルへ継続的に取り込む方法を説明します。
+
+
+
+## ユースケース
+
+ビジネスデータがすでに AutoMQ に書き込まれており、そのリアルタイムデータを Apache Doris で継続的に分析したい場合は、Routine Load を使用して AutoMQ のトピックからデータを消費できます。このドキュメントでは、JSON 形式のトピックと Doris のテストテーブルを使用し、データの準備から取り込み結果の確認までの一連の手順を示します。
+
+全体の手順は次のとおりです。
+
+1. Apache Doris のテスト用データベースとテストテーブルを準備します。
+2. AutoMQ クラスター、Kafka のコマンドラインツール、テスト用トピックを準備します。
+3. AutoMQ のトピックに JSON 形式のテストデータを書き込みます。
+4. Doris で Routine Load の取り込みジョブを作成します。
+5. Doris テーブルをクエリし、データが正常に取り込まれたことを確認します。
+
+## 前提条件
+
+開始する前に、次の環境が整っていることを確認してください。
+
+| 項目 | 説明 |
+| --- | --- |
+| Apache Doris クラスター | Apache Doris クラスターが利用可能であることを確認してください。このドキュメントでは、デモ用のテスト環境を Linux 上にデプロイする方法として、[クイックスタート](../../getting-started/quick-start)を参照します。 |
+| AutoMQ クラスター | AutoMQ の[公式デプロイドキュメント](https://docs.automq.com/automq/deployment/deploy-multi-nodes-cluster-on-linux)を参照して利用可能なクラスターをデプロイし、AutoMQ と Apache Doris の間でネットワーク接続が確立されていることを確認してください。 |
+| Kafka のコマンドラインツール | [AutoMQ Releases](https://github.com/AutoMQ/automq/releases) から最新の TGZ パッケージをダウンロードして展開します。このドキュメントでは、展開先ディレクトリを `$AUTOMQ_HOME` とし、`$AUTOMQ_HOME/bin` 以下のツールを使用してトピックの作成とテストデータの生成を行います。 |
+
+## Doris のテストテーブルを準備する
+
+Doris にデータベースとテストテーブルを作成します。以降の例は、デフォルトで `automq_db` 内で実行します。
+
+```sql
+CREATE DATABASE automq_db;
+USE automq_db;
+
+CREATE TABLE automq_db.users (
+ id BIGINT NOT NULL,
+ name STRING NOT NULL,
+ timestamp STRING NULL,
+ status STRING NULL
+) DISTRIBUTED BY HASH(id) PROPERTIES ("replication_num" = "1");
+```
+
+## AutoMQ のトピックとテストデータを準備する
+
+このドキュメントでは、次のサンプルパラメータを使用します。コマンドを実行するときは、サンプルのアドレスを実際の AutoMQ Bootstrap Server のアドレスに置き換えてください。
+
+| パラメータ | サンプル値 | 説明 |
+| --- | --- | --- |
+| AutoMQ Bootstrap Server | `127.0.0.1:9092` | AutoMQ クラスターへの接続アドレス。 |
+| トピック | `example_topic` | JSON 形式のテストデータを保存するトピック。 |
+| AutoMQ の展開先ディレクトリ | `$AUTOMQ_HOME` | AutoMQ の TGZ パッケージを展開したディレクトリ。 |
+
+### トピックを作成する
+
+Apache Kafka のコマンドラインツールを使用して `example_topic` を作成します。
+
+```shell
+$AUTOMQ_HOME/bin/kafka-topics.sh \
+ --create \
+ --topic example_topic \
+ --bootstrap-server 127.0.0.1:9092 \
+ --partitions 1 \
+ --replication-factor 1
+```
+
+作成後、次のコマンドでトピックが正常に作成されたことを確認します。
+
+```shell
+$AUTOMQ_HOME/bin/kafka-topics.sh \
+ --describe \
+ --topic example_topic \
+ --bootstrap-server 127.0.0.1:9092
+```
+
+### テストデータを準備する
+
+テストデータには JSON 形式を使用します。フィールドは、Doris テーブルおよび後述する Routine Load の `jsonpaths` に対応している必要があります。
+
+```json
+{
+ "id": 1,
+ "name": "Test User",
+ "timestamp": "2023-11-10T12:00:00",
+ "status": "active"
+}
+```
+
+### テストデータを書き込む
+
+Kafka のコマンドラインツールまたはプログラムを使用して、テストデータを `example_topic` に書き込みます。次の例では、コマンドラインツールを使用します。
+
+```shell
+echo '{"id": 1, "name": "Test User", "timestamp": "2023-11-10T12:00:00", "status": "active"}' | $AUTOMQ_HOME/bin/kafka-console-producer.sh \
+ --bootstrap-server 127.0.0.1:9092 \
+ --topic example_topic
+```
+
+次のコマンドで、書き込んだトピックのデータを確認します。
+
+```shell
+$AUTOMQ_HOME/bin/kafka-console-consumer.sh \
+ --bootstrap-server 127.0.0.1:9092 \
+ --topic example_topic \
+ --from-beginning
+```
+
+## Routine Load の取り込みジョブを作成する
+
+Apache Doris のコマンドラインで Routine Load ジョブを作成し、AutoMQ のトピックから JSON データを継続的に消費します。Routine Load のパラメータの詳細については、[Doris Routine Load](../../data-operate/import/import-way/routine-load-manual)を参照してください。
+
+```sql
+CREATE ROUTINE LOAD automq_example_load ON users
+COLUMNS(id, name, timestamp, status)
+PROPERTIES
+(
+ "format" = "json",
+ "jsonpaths" = "[\"$.id\",\"$.name\",\"$.timestamp\",\"$.status\"]"
+)
+FROM KAFKA
+(
+ "kafka_broker_list" = "127.0.0.1:9092",
+ "kafka_topic" = "example_topic",
+ "property.kafka_default_offsets" = "OFFSET_BEGINNING"
+);
+```
+
+主な設定は次のとおりです。
+
+| 設定 | サンプル値 | 説明 |
+| --- | --- | --- |
+| `format` | `json` | 取り込むデータの形式に JSON を指定します。 |
+| `jsonpaths` | `["$.id","$.name","$.timestamp","$.status"]` | JSON フィールドと Doris テーブルのフィールドとの対応を指定します。 |
+| `kafka_broker_list` | `127.0.0.1:9092` | AutoMQ Bootstrap Server のアドレス。実行時に実際のアドレスに置き換えてください。 |
+| `kafka_topic` | `example_topic` | Routine Load がデータを消費する AutoMQ のトピック。 |
+| `property.kafka_default_offsets` | `OFFSET_BEGINNING` | トピックの先頭からデータを消費します。 |
+
+## データの取り込みを確認する
+
+まず、Routine Load の取り込みジョブのステータスを確認し、ジョブが実行中であることを確かめます。
+
+```sql
+SHOW ROUTINE LOAD\G;
+```
+
+次に Doris テーブルをクエリし、テストデータが取り込まれたことを確認します。
+
+```sql
+SELECT * FROM users;
+```
+
+```text
++------+-----------+---------------------+--------+
+| id | name | timestamp | status |
++------+-----------+---------------------+--------+
+| 1 | Test User | 2023-11-10T12:00:00 | active |
++------+-----------+---------------------+--------+
+1 row in set (0.01 sec)
+```
+
+## 注意事項
+
+- サンプルコマンドを実行するときは、`127.0.0.1:9092` を実際の AutoMQ Bootstrap Server のアドレスに置き換えてください。
+- テスト用 JSON データのフィールドは、Doris テーブルのフィールドと Routine Load の `jsonpaths` 設定に一致させる必要があります。
+- Routine Load ジョブを作成する前に、Doris から AutoMQ クラスターにアクセスできることを確認してください。
diff --git a/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/beats.md b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/beats.md
new file mode 100644
index 00000000000..fbe4ed3c992
--- /dev/null
+++ b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/beats.md
@@ -0,0 +1,369 @@
+---
+{
+ "title": "Beats",
+ "language": "ja",
+ "description": "Beats Doris output プラグインを使い、Filebeat などの Beats コンポーネントが収集したデータを Stream Load 経由で Apache Doris にリアルタイムで書き込む方法を説明します。"
+}
+---
+
+[Beats](https://github.com/elastic/beats) は、カスタム出力プラグインを通じてストレージシステムへのデータ書き込みをサポートするデータ収集エージェントです。Beats Doris output プラグインは、Beats が収集したデータを Doris に出力します。
+
+Filebeat などの Beats コンポーネントが収集したデータを Doris にリアルタイムで書き込むには、Beats Doris output プラグインを使用できます。このプラグインは [Doris Stream Load](../../data-operate/import/import-way/stream-load-manual) の HTTP インターフェースを呼び出してデータを書き込みます。また、マルチスレッドによる並列処理、失敗時の再試行、Stream Load の形式とパラメーターのカスタマイズ、書き込み速度の報告などに対応しています。
+
+Beats Doris output プラグインは、次の Beats コンポーネントをサポートします。
+
+| Beats コンポーネント | 説明 |
+| --- | --- |
+| [Filebeat](https://github.com/elastic/beats/tree/master/filebeat) | ログファイルを収集します |
+| [Metricbeat](https://github.com/elastic/beats/tree/master/metricbeat) | メトリクスデータを収集します |
+| [Packetbeat](https://github.com/elastic/beats/tree/master/packetbeat) | ネットワークデータを収集します |
+| [Winlogbeat](https://github.com/elastic/beats/tree/master/winlogbeat) | Windows イベントログを収集します |
+| [Auditbeat](https://github.com/elastic/beats/tree/master/auditbeat) | 監査データを収集します |
+| [Heartbeat](https://github.com/elastic/beats/tree/master/heartbeat) | 可用性の監視データを収集します |
+
+Beats Doris output プラグインの使用手順は、通常、次の三つのステップです。
+
+1. Doris output プラグインを含む Beats バイナリをダウンロードするか、コンパイルします。
+2. Beats の設定ファイルで Doris の出力先アドレスなどのパラメーターを設定します。
+3. Beats を起動し、Doris にデータをリアルタイムで書き込みます。
+
+## インストール {#installation}
+
+Doris output プラグインを含む Beats バイナリをダウンロードするか、ソースコードからコンパイルできます。
+
+### 公式サイトからダウンロードする {#download-from-the-official-site}
+
+[filebeat-doris-2.1.1](https://apache-doris-releases.oss-accelerate.aliyuncs.com/extension/filebeat-doris-2.1.1) をダウンロードします。
+
+### ソースコードからコンパイルする {#compile-from-source}
+
+Doris のソースコードにある `extension/beats/` ディレクトリで、次のコマンドを実行します。
+
+```bash
+cd doris/extension/beats
+
+go build -o filebeat-doris filebeat/filebeat.go
+go build -o metricbeat-doris metricbeat/metricbeat.go
+go build -o winlogbeat-doris winlogbeat/winlogbeat.go
+go build -o packetbeat-doris packetbeat/packetbeat.go
+go build -o auditbeat-doris auditbeat/auditbeat.go
+go build -o heartbeat-doris heartbeat/heartbeat.go
+```
+
+## Doris への出力を設定する {#configure-the-doris-output}
+
+Beats の設定ファイルで `output.doris` を使用して Doris への出力を設定します。主な設定項目は次のとおりです。
+
+| 設定項目 | デフォルト値 | 説明 |
+| --- | --- | --- |
+| `fenodes` | なし | Stream Load の HTTP アドレス。文字列の配列で指定し、一つ以上のアドレスを設定できます。例: `["http://fe1:8030", "http://fe2:8030"]`。 |
+| `user` | なし | Doris のユーザー名。このユーザーには、書き込み先のデータベースとテーブルに対するロード権限が必要です。 |
+| `password` | なし | Doris ユーザーのパスワード。 |
+| `database` | なし | 書き込み先の Doris データベース名。 |
+| `table` | なし | 書き込み先の Doris テーブル名。 |
+| `label_prefix` | `beats` | Doris Stream Load の Label に付けるプレフィックス。最終的な Label の形式は `{label_prefix}_{db}_{table}_{yyyymmdd_hhmmss}_{uuid}` です。 |
+| `headers` | なし | Doris Stream Load に渡すヘッダー。YAML マップ形式で指定します。 |
+| `codec_format_string` | なし | Doris Stream Load に出力するデータのフォーマット文字列。`%{[a][b]}` を使用すると、入力の `a.b` フィールドを参照できます。 |
+| `bulk_max_size` | `100000` | Doris Stream Load のバッチサイズ。 |
+| `max_retries` | `-1` | Doris Stream Load のリクエストが失敗した後の再試行回数。`-1` は無制限の再試行を意味し、データの信頼性を確保するために使用します。 |
+| `log_request` | `true` | トラブルシューティングに使用するため、Doris Stream Load のリクエストとレスポンスのメタデータをログに出力するかどうか。 |
+| `log_progress_interval` | `10` | 書き込み速度をログに出力する間隔（秒）。`0` に設定すると、このログ出力を無効にします。 |
+
+## シナリオ 1: TEXT ログを収集する {#scenario-1-collecting-text-logs}
+
+このシナリオでは Doris FE のログを例に、プレーンテキストのログと複数行にわたるスタックトレースを収集し、Doris に書き込む方法を示します。
+
+### ステップ 1: データを準備する {#step-1-prepare-the-data}
+
+Doris FE のログファイルは通常、Doris のインストールディレクトリ内の `fe/log/fe.log` にあります。FE ログは一般的な Java プログラムのログで、タイムスタンプ、ログレベル、スレッド名、コード上の位置、ログ内容などのフィールドを含みます。通常のログエントリと、スタックトレースを伴う例外エントリの両方が含まれます。スタックトレースは複数行にわたるため、収集時にメインのログエントリと対応するスタックトレースを一つのログエントリにまとめる必要があります。
+
+```text
+2024-07-08 21:18:01,432 INFO (Statistics Job Appender|61) [StatisticsJobAppender.runAfterCatalogReady():70] Stats table not available, skip
+2024-07-08 21:18:53,710 WARN (STATS_FETCH-0|208) [StmtExecutor.executeInternalQuery():3332] Failed to run internal SQL: OriginStatement{originStmt='SELECT * FROM __internal_schema.column_statistics WHERE part_id is NULL ORDER BY update_time DESC LIMIT 500000', idx=0}
+org.apache.doris.common.UserException: errCode = 2, detailMessage = tablet 10031 has no queryable replicas. err: replica 10032's backend 10008 does not exist or not alive
+ at org.apache.doris.planner.OlapScanNode.addScanRangeLocations(OlapScanNode.java:931) ~[doris-fe.jar:1.2-SNAPSHOT]
+ at org.apache.doris.planner.OlapScanNode.computeTabletInfo(OlapScanNode.java:1197) ~[doris-fe.jar:1.2-SNAPSHOT]
+```
+
+### ステップ 2: Doris テーブルを作成する {#step-2-create-a-doris-table}
+
+テーブルスキーマには、ログの生成時刻、収集時刻、ホスト名、ログファイルのパス、ログの種類、ログレベル、スレッド名、コード上の位置、ログ内容などのフィールドが含まれます。
+
+```sql
+CREATE TABLE `doris_log` (
+ `log_time` datetime NULL COMMENT 'log content time',
+ `collect_time` datetime NULL COMMENT 'log agent collect time',
+ `host` text NULL COMMENT 'hostname or ip',
+ `path` text NULL COMMENT 'log file path',
+ `type` text NULL COMMENT 'log type',
+ `level` text NULL COMMENT 'log level',
+ `thread` text NULL COMMENT 'log thread',
+ `position` text NULL COMMENT 'log code position',
+ `message` text NULL COMMENT 'log message',
+ INDEX idx_host (`host`) USING INVERTED COMMENT '',
+ INDEX idx_path (`path`) USING INVERTED COMMENT '',
+ INDEX idx_type (`type`) USING INVERTED COMMENT '',
+ INDEX idx_level (`level`) USING INVERTED COMMENT '',
+ INDEX idx_thread (`thread`) USING INVERTED COMMENT '',
+ INDEX idx_position (`position`) USING INVERTED COMMENT '',
+ INDEX idx_message (`message`) USING INVERTED PROPERTIES("parser" = "unicode", "support_phrase" = "true") COMMENT ''
+) ENGINE=OLAP
+DUPLICATE KEY(`log_time`)
+COMMENT 'OLAP'
+PARTITION BY RANGE(`log_time`) ()
+DISTRIBUTED BY RANDOM BUCKETS 10
+PROPERTIES (
+"replication_num" = "1",
+"dynamic_partition.enable" = "true",
+"dynamic_partition.time_unit" = "DAY",
+"dynamic_partition.start" = "-7",
+"dynamic_partition.end" = "1",
+"dynamic_partition.prefix" = "p",
+"dynamic_partition.buckets" = "10",
+"dynamic_partition.create_history_partition" = "true",
+"compaction_policy" = "time_series"
+);
+```
+
+### ステップ 3: Filebeat を設定する {#step-3-configure-filebeat}
+
+Filebeat のログ収集用設定ファイル（例: `filebeat_doris_log.yml`）は YAML 形式で、主に次の四つの部分で構成されます。
+
+1. `input`: 元のログファイルを読み取ります。
+2. `processors`: ログの内容を変換・解析します。
+3. `queue.mem`: Filebeat の内部バッファーキューを設定します。
+4. `output`: データを Doris に出力します。
+
+```yaml
+# 1. input is responsible for reading raw data.
+# type: log is the log input plugin, which lets you configure the path of the log file to read.
+# multiline appends lines that do not start with a timestamp to the previous line, used to merge stack traces with the main log entry.
+# The log input stores the log content in the message field, and also generates metadata fields such as agent.host and log.file.path.
+filebeat.inputs:
+- type: log
+ enabled: true
+ paths:
+ - /path/to/your/log
+ multiline:
+ type: pattern
+ # A line starting with yyyy-mm-dd HH:MM:SS is recognized as a new log entry; other lines are appended to the previous entry.
+ pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2}'
+ negate: true
+ match: after
+ skip_newline: true
+
+# 2. processors handle data transformation.
+processors:
+# Use the js script plugin to replace \t in the log with spaces, to avoid JSON parsing errors.
+- script:
+ lang: javascript
+ source: >
+ function process(event) {
+ var msg = event.Get("message");
+ msg = msg.replace(/\t/g, " ");
+ event.Put("message", msg);
+ }
+# Use the dissect plugin for simple log parsing.
+- dissect:
+ # 2024-06-08 18:26:25,481 INFO (report-thread|199) [ReportHandler.cpuReport():617] begin to handle
+ tokenizer: "%{day} %{time} %{log_level} (%{thread}) [%{position}] %{content}"
+ target_prefix: ""
+ ignore_failure: true
+ overwrite_keys: true
+
+# 3. queue.mem configures the total number of events in the internal buffer queue, the flush batch size, and the flush time interval.
+queue.mem:
+ events: 1000000
+ flush.min_events: 100000
+ flush.timeout: 10s
+
+# 4. output is responsible for sending data to Doris.
+# doris output uses the Stream Load HTTP interface to write to Doris.
+# headers specifies the Stream Load data format as JSON.
+# codec_format_string formats the output content in a printf-like manner.
+# In the example, you can reference Filebeat built-in fields (such as agent.hostname) or fields generated by processors (such as day).
+output.doris:
+ fenodes: [ "http://fehost1:http_port", "http://fehost2:http_port", "http://fehost3:http_port" ]
+ user: "your_username"
+ password: "your_password"
+ database: "your_db"
+ table: "your_table"
+ # output string format
+ ## %{[agent][hostname]} and %{[log][file][path]} are Filebeat built-in metadata.
+ ## Other commonly used Filebeat metadata includes the collection timestamp %{[@timestamp]}.
+ ## %{[day]} and %{[time]} are fields obtained from the dissect parsing above.
+ codec_format_string: '{"ts": "%{[day]} %{[time]}", "host": "%{[agent][hostname]}", "path": "%{[log][file][path]}", "message": "%{[message]}"}'
+ headers:
+ format: "json"
+ read_json_by_line: "true"
+ load_to_single_tablet: "true"
+```
+
+### ステップ 4: Filebeat を実行する {#step-4-run-filebeat}
+
+次のコマンドを実行して Filebeat を起動します。
+
+```bash
+./filebeat-doris -f config/filebeat_doris_log.yml
+```
+
+`log_request` が `true` の場合、各 Stream Load のリクエストパラメーターとレスポンス結果がログに出力されます。
+
+```text
+doris stream load response:
+{
+ "TxnId": 45464,
+ "Label": "beats_log_db_doris_log_20240708_223532_539_6c20a0d1-dcab-4b8e-9bc0-76b46a929bd1",
+ "Comment": "",
+ "TwoPhaseCommit": "false",
+ "Status": "Success",
+ "Message": "OK",
+ "NumberTotalRows": 452,
+ "NumberLoadedRows": 452,
+ "NumberFilteredRows": 0,
+ "NumberUnselectedRows": 0,
+ "LoadBytes": 277230,
+ "LoadTimeMs": 1797,
+ "BeginTxnTimeMs": 0,
+ "StreamLoadPutTimeMs": 18,
+ "ReadDataTimeMs": 9,
+ "WriteDataTimeMs": 1758,
+ "CommitAndPublishTimeMs": 18
+}
+```
+
+デフォルトでは、起動後のデータ量（MB および ROWS）、全体の速度（MB/s および R/s）、直近 10 秒間の速度などの書き込み速度情報が、10 秒ごとにログに出力されます。
+
+```text
+total 11 MB 18978 ROWS, total speed 0 MB/s 632 R/s, last 10 seconds speed 1 MB/s 1897 R/s
+```
+
+## シナリオ 2: JSON ログを収集する {#scenario-2-collecting-json-logs}
+
+このシナリオでは GitHub Events Archive のデータを例に、JSON ログを収集して Doris に書き込む方法を示します。
+
+### ステップ 1: データを準備する {#step-1-prepare-the-data-1}
+
+GitHub Events Archive は、GitHub ユーザーの操作イベントを JSON 形式でアーカイブしたデータです。[GitHub Archive](https://www.gharchive.org/) からダウンロードできます。たとえば、2024 年 1 月の初日 15:00 のデータをダウンロードするには、次のコマンドを実行します。
+
+```bash
+wget https://data.gharchive.org/2024-01-01-15.json.gz
+```
+
+以下はレコードの例です。実際のデータは各行に一件の JSON レコードが記録されていますが、ここでは読みやすいように整形しています。
+
+```json
+{
+ "id": "37066529221",
+ "type": "PushEvent",
+ "actor": {
+ "id": 46139131,
+ "login": "Bard89",
+ "display_login": "Bard89",
+ "gravatar_id": "",
+ "url": "https://api.github.com/users/Bard89",
+ "avatar_url": "https://avatars.githubusercontent.com/u/46139131?"
+ },
+ "repo": {
+ "id": 780125623,
+ "name": "Bard89/talk-to-me",
+ "url": "https://api.github.com/repos/Bard89/talk-to-me"
+ },
+ "payload": {
+ "repository_id": 780125623,
+ "push_id": 17799451992,
+ "size": 1,
+ "distinct_size": 1,
+ "ref": "refs/heads/add_mvcs",
+ "head": "f03baa2de66f88f5f1754ce3fa30972667f87e81",
+ "before": "85e6544ede4ae3f132fe2f5f1ce0ce35a3169d21"
+ },
+ "public": true,
+ "created_at": "2024-04-01T23:00:00Z"
+}
+```
+
+### ステップ 2: Doris テーブルを作成する {#step-2-create-a-doris-table-1}
+
+```sql
+CREATE DATABASE log_db;
+USE log_db;
+
+CREATE TABLE github_events
+(
+ `created_at` DATETIME,
+ `id` BIGINT,
+ `type` TEXT,
+ `public` BOOLEAN,
+ `actor` VARIANT,
+ `repo` VARIANT,
+ `payload` TEXT,
+ INDEX `idx_id` (`id`) USING INVERTED,
+ INDEX `idx_type` (`type`) USING INVERTED,
+ INDEX `idx_actor` (`actor`) USING INVERTED,
+ INDEX `idx_host` (`repo`) USING INVERTED,
+ INDEX `idx_payload` (`payload`) USING INVERTED PROPERTIES("parser" = "unicode", "support_phrase" = "true")
+)
+ENGINE = OLAP
+DUPLICATE KEY(`created_at`)
+PARTITION BY RANGE(`created_at`) ()
+DISTRIBUTED BY RANDOM BUCKETS 10
+PROPERTIES (
+"replication_num" = "1",
+"compaction_policy" = "time_series",
+"dynamic_partition.enable" = "true",
+"dynamic_partition.create_history_partition" = "true",
+"dynamic_partition.time_unit" = "DAY",
+"dynamic_partition.start" = "-30",
+"dynamic_partition.end" = "1",
+"dynamic_partition.prefix" = "p",
+"dynamic_partition.buckets" = "10",
+"dynamic_partition.replication_num" = "1"
+);
+```
+
+### ステップ 3: Filebeat を設定する {#step-3-configure-filebeat-1}
+
+TEXT ログの収集設定と比較すると、JSON のシナリオには次の二つの違いがあります。
+
+1. 追加の変換が不要なため、`processors` は使用しません。
+2. `codec_format_string` は、`message` 全体、つまり元の JSON コンテンツをそのまま出力します。
+
+```yaml
+# input
+filebeat.inputs:
+- type: log
+ enabled: true
+ paths:
+ - /path/to/your/log
+
+# queue and batch
+queue.mem:
+ events: 1000000
+ flush.min_events: 100000
+ flush.timeout: 10s
+
+# output
+output.doris:
+ fenodes: [ "http://fehost1:http_port", "http://fehost2:http_port", "http://fehost3:http_port" ]
+ user: "your_username"
+ password: "your_password"
+ database: "your_db"
+ table: "your_table"
+ # output string format
+ ## Output the message of each line in the original file as-is.
+ ## headers specifies format: "json", so Stream Load automatically parses JSON fields and writes them into the corresponding fields of the Doris table.
+ codec_format_string: '%{[message]}'
+ headers:
+ format: "json"
+ read_json_by_line: "true"
+ load_to_single_tablet: "true"
+```
+
+### ステップ 4: Filebeat を実行する {#step-4-run-filebeat-1}
+
+次のコマンドを実行して Filebeat を起動します。
+
+```bash
+./filebeat-doris -f config/filebeat_github_events.yml
+```
diff --git a/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/cloudcanal.md b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/cloudcanal.md
new file mode 100644
index 00000000000..d6daa9395c3
--- /dev/null
+++ b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/cloudcanal.md
@@ -0,0 +1,64 @@
+---
+{
+ "title": "CloudCanal",
+ "language": "ja",
+ "description": "CloudCanal は、独自開発されたビジュアル操作型の自動データ移行・同期ツールです。一般的なリレーショナルデータベース、リアルタイムデータウェアハウス、メッセージミドルウェア、キャッシュデータベース、検索エンジンなど、30 種類以上のシステム間でデータを連携できます。高いリアルタイム性、正確な連携、安定性と拡張性、ワンストップの運用、ハイブリッドデプロイ、複雑なデータ変換に対応しています。"
+}
+---
+
+CloudCanal は、独自開発されたビジュアル操作型の自動データ移行・同期ツールです。一般的なリレーショナルデータベース、リアルタイムデータウェアハウス、メッセージミドルウェア、キャッシュデータベース、検索エンジンなど、30 種類以上のシステム間でデータを連携できます。高いリアルタイム性、正確な連携、安定性と拡張性、ワンストップの運用、ハイブリッドデプロイ、複雑なデータ変換に対応しています。
+
+## 機能の説明
+CloudCanal のビジュアルインターフェースを使用すると、スキーマ移行、データの全量移行、増分同期、検証と修正を簡単に実行できます。また、パラメータを設定することで、より細かくカスタマイズしたデータ同期も可能です。現在、以下のデータソースから Doris へのデータ連携に対応しています。
+
+| 接続元データソース | スキーマ移行 | 全量移行 | 増分同期 | 検証と修正 |
+|------------------------------|--------------|----------|----------|------------|
+| MySQL/MariaDB/AuroraMySQL | 対応 | 対応 | 対応 | 対応 |
+| Oracle | 対応 | 対応 | 対応 | 対応 |
+| PostgreSQL/AuroraPostgreSQL | 対応 | 対応 | 対応 | 対応 |
+| SQL Server | 対応 | 対応 | 対応 | 対応 |
+| Kafka | 非対応 | 非対応 | 対応 | 非対応 |
+| AutoMQ | 非対応 | 非対応 | 対応 | 非対応 |
+| TiDB | 対応 | 対応 | 対応 | 対応 |
+| Hana | 対応 | 対応 | 対応 | 対応 |
+| PolarDB-X | 対応 | 対応 | 対応 | 対応 |
+
+:::info
+その他の機能やパラメータ設定については、[CloudCanal データ連携ドキュメント](https://www.clougence.com/cc-doc/dataMigrationAndSync/connection/mysql2?target=Doris)を参照してください。
+:::
+
+
+## ダウンロードとインストール
+[新規インストール（Docker Linux/MacOS）](https://www.clougence.com/cc-doc/productOP/docker/install_linux_macos)を参照し、[CloudCanal 公式サイト](https://www.clougence.com/)からプライベートデプロイ版をダウンロードしてインストールしてください。
+
+## 使用例
+以下では、MySQL から Doris にデータを移行・同期する方法を例として説明します。
+
+### データソースの追加
+1. CloudCanal コンソールにログインし、**データソース管理** > **データソースの追加**をクリックします。
+2. MySQL と Doris のデータソースをそれぞれ選択し、対応する情報を入力します。
+ 
+
+3. **接続テスト**をクリックします。接続に成功したら、**データソースの追加**をクリックして、データソースの追加を完了します。
+ 
+
+### タスクの作成
+1. **同期タスク** > **タスクの作成**をクリックします。
+2. 接続元と接続先のデータソースを選択し、それぞれで**接続テスト**をクリックします。
+ 
+
+3. **データ同期**を選択し、**全量初期化**にチェックを入れます。
+ 
+
+4. 同期するテーブルを選択します。
+ 
+
+5. 同期するカラムを選択します。
+ 
+
+6. タスクの作成を確定します。
+7. タスクは自動的に実行されます。CloudCanal は、次のステップで構成されるタスクの処理を自動的に行います。
+ - スキーマ移行：接続元のテーブルスキーマを接続先に移行します。接続先に同名のテーブルが既に存在する場合、そのテーブルは無視されます。
+ - データの全量移行：既存のデータをすべて接続先に移行します。中断した箇所からの再開に対応しています。
+ - 増分データ同期：増分データを接続先のデータベースにリアルタイムで継続的に同期します（遅延は秒単位）。
+ 
diff --git a/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/clouddm.md b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/clouddm.md
new file mode 100644
index 00000000000..156c0132533
--- /dev/null
+++ b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/clouddm.md
@@ -0,0 +1,85 @@
+---
+{
+ "title": "CloudDM",
+ "language": "ja",
+ "description": "CloudDM を使用して Apache Doris に接続し、Doris データソースを管理する方法を説明します。データアクセス、データマスキング、視覚的な編集、データベースの CI/CD をサポートします。"
+}
+---
+
+## 概要
+
+<!-- Knowledge type: Scenario description -->
+<!-- Applicable scenario: Use CloudDM to connect to and manage Apache Doris data sources -->
+
+Clougence が開発した CloudDM は、チームと個人ユーザー向けのクロスプラットフォームのデータベースツールです。データベースの変更と管理を、安全かつ効率的に、規制に準拠して行うのに役立ちます。
+
+Apache Doris を使用する場面では、CloudDM は Doris の機能に合わせた専用の対応を提供し、データアクセス、データマスキング、視覚的な編集、データベースの CI/CD をサポートします。この記事では、次の操作を説明します。
+
+- CloudDM に Doris データソースを追加する。
+- Doris インスタンスのデータ管理を有効にし、接続をテストする。
+- CloudDM を使用して Doris のデータにアクセスし、管理する。
+
+## 事前準備
+
+<!-- Knowledge type: Prerequisites -->
+<!-- Applicable scenario: Check the CloudDM installation and verify the version before connecting to Doris -->
+
+| 項目 | 要件 |
+|-------|------|
+| CloudDM | CloudDM がインストールされていること。[CloudDM 公式サイト](https://www.cdmgr.com/)からダウンロードしてインストールできます。 |
+| 検証済みバージョン | この記事は CloudDM 2.8.0.0 で検証しています。 |
+
+## Doris データソースに接続する
+
+<!-- Knowledge type: Procedure -->
+<!-- Applicable scenario: Create a Doris data source connection in CloudDM -->
+
+### 1. Doris データソースを追加する
+
+1. CloudDM にログインします。
+2. ナビゲーションバーで **Data Source Management（データソース管理）** > **Add Data Source（データソースを追加）** をクリックします。
+3. Doris データソースを選択します。
+
+
+
+### 2. 接続情報を設定する
+
+データソースの追加ページで、次の接続情報を設定します。
+
+| 項目 | 説明 |
+|-------|------|
+| クライアントアドレス（Client address） | Doris クラスターの FE クエリポートのアドレス。例: `hostID:9030`。 |
+| アカウント（Account） | Doris クラスターへのログインに使用するユーザー名。例: `admin`。 |
+| パスワード（Password） | Doris クラスターへのログインに使用するユーザーのパスワード。 |
+
+:::tip
+Doris には `internal catalog` と `external catalog` があり、CloudDM では両方を同時に管理できます。
+:::
+
+:::info 注記
+Doris の `external catalog` を `catalog.db` 形式のデータベースとして管理するには、Doris 2.1.0 以降が必要です。
+:::
+
+### 3. データ管理を有効にして接続をテストする
+
+画面上部の **Query Settings（クエリ設定）** > **Query Configuration（クエリ構成）** をクリックして、Doris インスタンスのデータ管理を有効にし、接続をテストします。
+
+
+
+### 4. Doris のデータにアクセスする
+
+データベースへの接続が確立すると、左側のデータベース接続ナビゲーションに接続済みのデータソースが表示され、CloudDM を使用してデータベースに接続し、管理できます。
+
+
+
+## CloudDM がサポートする Doris の管理シナリオ
+
+<!-- Knowledge type: Feature support -->
+<!-- Applicable scenario: Understand which Doris management capabilities CloudDM supports -->
+
+CloudDM は、次の二つのカテゴリで Doris の機能をサポートします。
+
+| シナリオ | サポートする機能 |
+|---------|---------|
+| クエリクライアント | Doris のデータベースオブジェクトを視覚的に管理する。コンソールで SQL を記述して Doris を操作する。クエリ結果をエクスポートする。 |
+| チームでの利用 | テーブル単位までのステートメントレベルの権限付与、チケットの承認、データベースの CI/CD、機密データのマスキング、SQL レビュールール。 |
diff --git a/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/datagrip.md b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/datagrip.md
new file mode 100644
index 00000000000..4e850157b99
--- /dev/null
+++ b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/datagrip.md
@@ -0,0 +1,87 @@
+---
+{
+ "title": "DataGrip",
+ "language": "ja",
+ "description": "DataGrip の MySQL データソースを使用して Apache Doris に接続し、内部カタログと外部カタログを設定して、接続を確認する方法を説明します。"
+}
+---
+
+<!-- Knowledge type: Procedure -->
+<!-- Applicable scenario: Use DataGrip to connect to and query Apache Doris -->
+
+## 適用シナリオ
+
+DataGrip は JetBrains が提供する強力なクロスプラットフォームのデータベースツールで、リレーショナルデータベースと NoSQL データベースの両方をサポートしています。Apache Doris は MySQL プロトコルとの互換性が高いため、DataGrip の MySQL データソースを使用して Apache Doris に接続し、内部カタログと外部カタログのデータをクエリできます。
+
+この記事を読むと、次のことができるようになります。
+
+- MySQL データソースを使用して Doris への接続を作成する。
+- 内部カタログまたは外部カタログの接続情報を設定する。
+- 接続を確認し、DataGrip でデータベースを表示および管理する。
+
+## 前提条件
+
+- DataGrip がインストールされていること。インストールされていない場合は、[DataGrip の公式サイト](https://www.jetbrains.com/datagrip/)からダウンロードしてインストールしてください。
+- FE ホストの IP アドレス、FE クエリポート、接続先データベース、ユーザー名、パスワードを含む Doris クラスターの接続情報が用意されていること。
+
+:::info バージョンに関する注記
+この記事の手順は DataGrip 2023.3.4 で検証されています。
+:::
+
+## Doris への接続
+
+### 1. MySQL データソースを追加する
+
+DataGrip を起動し、ウィンドウ左上のプラス（**+**）アイコンをクリックして、MySQL データソースを選択します。
+
+
+
+### 2. Doris への接続を設定する
+
+Data Sources and Drivers ウィンドウの General タブで、Doris への接続情報を設定します。
+
+| 設定項目 | 説明 |
+| --- | --- |
+| Host | Doris クラスターの FE ホストの IP アドレス。 |
+| Port | Doris クラスターの FE クエリポート（例：`9030`）。 |
+| Database | Doris クラスターの接続先データベース。`catalog.db` 形式でカタログを指定することもできます。 |
+| User | Doris クラスターへのログインに使用するユーザー名（例：`admin`）。 |
+| Password | Doris クラスターへのログインに使用するパスワード。 |
+
+Database フィールドを使って、内部カタログと外部カタログを区別できます。DataGrip の MySQL データソースで Doris への接続を複数作成し、異なるカタログを個別に管理できます。
+
+| Database フィールドの入力内容 | デフォルトの接続先 |
+| --- | --- |
+| データベース名のみを入力 | デフォルトで内部カタログに接続します。 |
+| `catalog.db` を入力 | デフォルトで Database フィールドで指定したカタログに接続します。DataGrip に表示されるデータベースとテーブルも、接続先カタログ内のものです。 |
+
+:::info バージョンに関する注記
+`catalog.db` 形式の Database フィールドを使用して Doris の外部カタログを管理するには、Doris 2.1.0 以降が必要です。
+:::
+
+内部カタログへの接続例を以下に示します。
+
+
+
+外部カタログへの接続例を以下に示します。
+
+
+
+### 3. データソースへの接続をテストする
+
+接続情報を入力したら、左下の Test Connection をクリックして、データベースへの接続情報が正しいことを確認します。DataGrip に次のダイアログボックスが表示されれば、接続テストは成功です。その後、右下の OK をクリックして接続設定を完了します。
+
+
+
+### 4. データベースに接続して管理する
+
+データベースへの接続が確立すると、左側のデータベース接続ナビゲーションに作成したデータソースへの接続が表示され、DataGrip からデータベースに接続して管理できます。
+
+
+
+## 機能のサポート範囲
+
+| サポート状況 | 説明 |
+| --- | --- |
+| 基本的にサポート | ほとんどの画面上での表示操作と、SQL コンソールで SQL を記述して Doris を操作すること。 |
+| 未サポートまたは未検証 | データベースやテーブルの作成、スキーマ変更、データの挿入・更新・削除などの操作。 |
diff --git a/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/datax.md b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/datax.md
new file mode 100644
index 00000000000..98a652164d1
--- /dev/null
+++ b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/datax.md
@@ -0,0 +1,316 @@
+---
+{
+ "title": "DataX Doriswriter",
+ "language": "ja",
+ "description": "DataX Doriswriter を使用し、MySQL、Oracle、SQL Server などのデータソースから Stream Load 経由で Apache Doris にデータを同期する方法を説明します。パラメータ設定とインポート例も示します。",
+ "keywords": [
+ "DataX Doriswriter",
+ "DataX から Doris へのインポート",
+ "Stream Load",
+ "MySQL から Doris への同期"
+ ]
+}
+---
+
+<!-- Knowledge type: Procedure -->
+<!-- Applicable scenario: Data integration / Offline batch synchronization -->
+
+[DataX](https://github.com/alibaba/DataX) の Doriswriter プラグインは、MySQL、Oracle、SQL Server などのさまざまなデータソースから、Stream Load を介して Doris にデータを同期します。
+
+オフラインのデータ同期にすでに DataX を使用している場合や、DataX がサポートするデータソースから Doris にデータを書き込む必要がある場合は、Doriswriter を DataX の Writer プラグインとして使用できます。このドキュメントでは、実際の設定手順に沿って、プラグインの入手、パラメータの設定、ジョブの実行方法を説明し、JSON および CSV 形式でインポートする際の注意点を示します。
+
+DataX Doriswriter を使用する主な手順は次のとおりです。
+
+1. DataX のインストールパッケージを入手するか、Doriswriter プラグインを自分でコンパイルします。
+2. Doriswriter が Doris に書き込むために必要な接続、バッチ、Stream Load の各パラメータを設定します。
+3. DataX のジョブスクリプトを作成し、同期ジョブを実行します。
+4. 区切り文字の衝突を避けるため、データ形式に応じて `loadProps` を調整します。
+
+## 事前確認
+
+| 項目 | 説明 |
+| --- | --- |
+| DataX サービス | Doriswriter は DataX サービスと併用する必要があります。 |
+| データソースのサポート | DataX は多くのデータソースをサポートしています。対応一覧は [DataX がサポートするデータチャネル](https://github.com/alibaba/DataX#support-data-channels) を参照してください。 |
+| Doris のインポート先 | Doriswriter は Stream Load を介して Doris に書き込みます。`loadUrl` には FE ノードの `http_port` を指定する必要があります。 |
+
+## DataX と Doriswriter の入手
+
+### DataX インストールパッケージを直接ダウンロードする
+
+DataX にはそのまま使用できるインストールパッケージが用意されています。ダウンロードリンクは [DataX インストールパッケージのダウンロード](https://github.com/alibaba/DataX?tab=readme-ov-file#download-datax%E4%B8%8B%E8%BD%BD%E5%9C%B0%E5%9D%80) を参照してください。
+
+### Doriswriter プラグインを自分でコンパイルする
+
+Doriswriter プラグインを自分でコンパイルするには、まず [Doriswriter プラグインのソースコード](https://github.com/apache/doris/tree/master/extension/DataX) をダウンロードします。
+
+1. `init-env.sh` を実行します。
+2. `doriswriter` プラグインを個別にコンパイルします。
+
+ ```shell
+ mvn clean install -pl plugin-rdbms-util,doriswriter -DskipTests
+ ```
+
+DataX プロジェクト全体のコンパイル方法は、[DataX クイックスタート](https://github.com/alibaba/DataX/blob/master/userGuid.md#quick-start) を参照してください。
+
+#### `datax-all` の依存関係エラーへの対処
+
+コンパイル中に次のエラーが表示された場合：
+
+```text
+Could not find artifact com.alibaba.datax:datax-all:pom:0.0.1-SNAPSHOT ...
+```
+
+次の手順で対処します。
+
+1. [alibaba-datax-maven-m2-20210928.tar.gz](https://doris-thirdparty-repo.bj.bcebos.com/thirdparty/alibaba-datax-maven-m2-20210928.tar.gz) をダウンロードします。
+2. 展開して得られた `alibaba/datax/` ディレクトリを、ローカルの Maven が使用する `.m2/repository/com/alibaba/` ディレクトリにコピーし、再度コンパイルします。
+
+## Doriswriter のパラメータ設定
+
+<!-- Knowledge type: Configuration parameters -->
+<!-- Applicable scenario: DataX job configuration -->
+
+Doriswriter のパラメータでは、Doris への接続、書き込み先のデータベースとテーブル、バッチサイズ、失敗時の再試行、Stream Load リクエストのプロパティを設定します。
+
+| パラメータ | 必須 | デフォルト | 説明 |
+| --- | --- | --- | --- |
+| `jdbcUrl` | はい | なし | `preSql` または `postSql` の実行に使用する Doris の JDBC 接続文字列です。 |
+| `loadUrl` | はい | なし | Stream Load の送信先です。形式は `ip:port` で、`ip` は FE ノードの IP アドレス、`port` は FE ノードの `http_port` です。カンマ（`,`）で区切って複数のアドレスを指定できます。doriswriter はそれらにラウンドロビン方式でアクセスします。 |
+| `username` | はい | なし | Doris データベースへのアクセスに使用するユーザー名です。 |
+| `password` | いいえ | 空文字列 | Doris データベースへのアクセスに使用するパスワードです。 |
+| `connection.selectedDatabase` | はい | なし | 書き込み先の Doris データベース名です。 |
+| `connection.table` | はい | なし | 書き込み先の Doris テーブル名です。 |
+| `flushInterval` | いいえ | `30000` ms | データ書き込みバッチ間の時間間隔です。小さすぎる値を設定すると Doris への書き込みがブロックされ、エラーコード `-235` が返されることがあります。また、`maxBatchRows` と `batchSize` に大きな値を設定していても、行数やデータ量のしきい値に達する前にインポートが開始されることがあります。 |
+| `column` | はい | なし | 書き込み先テーブルの対象カラムです。指定した名前が、生成される JSON データのフィールド名として使用されます。たとえば `"column": ["id", "name", "age"]` のように、フィールドをカンマで区切って指定します。 |
+| `preSql` | いいえ | なし | 書き込み先テーブルへのデータ書き込み前に実行する標準 SQL 文です。 |
+| `postSql` | いいえ | なし | 書き込み先テーブルへのデータ書き込み後に実行する標準 SQL 文です。 |
+| `maxBatchRows` | いいえ | `500000` | インポートバッチあたりの最大行数です。`batchSize` とともに各バッチのサイズを制御し、どちらかのしきい値に達した時点でインポートが開始されます。 |
+| `batchSize` | いいえ | `94371840` | インポートバッチあたりの最大データ量です。`maxBatchRows` とともに各バッチのサイズを制御し、どちらかのしきい値に達した時点でインポートが開始されます。 |
+| `maxRetries` | いいえ | `3` | バッチのインポートが失敗した後の再試行回数です。 |
+| `labelPrefix` | いいえ | `datax_doris_writer_` | 各インポートジョブのラベルの接頭辞です。最終的なラベルは `labelPrefix + UUID` となり、グローバルな一意性を確保して重複インポートを防ぎます。 |
+| `loadProps` | いいえ | なし | Stream Load リクエストのパラメータです。インポートするデータ形式、区切り文字、その他のプロパティを設定できます。デフォルトの形式は CSV で、JSON もサポートされています。その他のパラメータは [Stream Load のドキュメント](../../data-operate/import/import-way/stream-load-manual.md) を参照してください。 |
+
+## 使用例
+
+### シナリオ 1：Stream からデータを読み取り、Doris にインポートする
+
+プラグインを使用して Stream からデータを読み取り、Doris にインポートする方法は、[Doriswriter の公式サンプル](https://github.com/apache/doris/blob/master/extension/DataX/doriswriter/doc/doriswriter.md) を参照してください。
+
+### シナリオ 2：MySQL からデータを読み取り、Doris にインポートする
+
+次の例では、DataX で MySQL からデータを読み取り、Doriswriter を介して Doris に書き込む方法を示します。
+
+#### 1. MySQL のソーステーブルを準備する
+
+```sql
+CREATE TABLE `t_test` (
+ `id` bigint(30) NOT NULL,
+ `order_code` varchar(30) DEFAULT NULL COMMENT '',
+ `line_code` varchar(30) DEFAULT NULL COMMENT '',
+ `remark` varchar(30) DEFAULT NULL COMMENT '',
+ `unit_no` varchar(30) DEFAULT NULL COMMENT '',
+ `unit_name` varchar(30) DEFAULT NULL COMMENT '',
+ `price` decimal(12,2) DEFAULT NULL COMMENT '',
+ PRIMARY KEY (`id`) USING BTREE
+) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 ROW_FORMAT=DYNAMIC COMMENT='';
+```
+
+#### 2. Doris の書き込み先テーブルを準備する
+
+```sql
+CREATE TABLE `ods_t_test` (
+ `id` bigint(30) NOT NULL,
+ `order_code` varchar(30) DEFAULT NULL COMMENT '',
+ `line_code` varchar(30) DEFAULT NULL COMMENT '',
+ `remark` varchar(30) DEFAULT NULL COMMENT '',
+ `unit_no` varchar(30) DEFAULT NULL COMMENT '',
+ `unit_name` varchar(30) DEFAULT NULL COMMENT '',
+ `price` decimal(12,2) DEFAULT NULL COMMENT ''
+) ENGINE=OLAP
+UNIQUE KEY(`id`, `order_code`)
+DISTRIBUTED BY HASH(`order_code`) BUCKETS 1
+PROPERTIES (
+ "replication_allocation" = "tag.location.default: 3",
+ "in_memory" = "false",
+ "storage_format" = "V2"
+);
+```
+
+#### 3. DataX のジョブスクリプトを作成する
+
+`my_import.json` を作成します。実際に使用する際は、`reader` 内のソースデータベースとテーブル、および `writer` 内の Doris の書き込み先データベースとテーブル、ユーザー名、パスワードを、使用環境に合った値に置き換えてください。
+
+```json
+{
+ "job": {
+ "content": [
+ {
+ "reader": {
+ "name": "mysqlreader",
+ "parameter": {
+ "column": ["id", "order_code", "line_code", "remark", "unit_no", "unit_name", "price"],
+ "connection": [
+ {
+ "jdbcUrl": ["jdbc:mysql://localhost:3306/demo"],
+ "table": ["employees_1"]
+ }
+ ],
+ "username": "root",
+ "password": "xxxxx",
+ "where": ""
+ }
+ },
+ "writer": {
+ "name": "doriswriter",
+ "parameter": {
+ "loadUrl": ["127.0.0.1:8030"],
+ "column": ["id", "order_code", "line_code", "remark", "unit_no", "unit_name", "price"],
+ "username": "root",
+ "password": "xxxxxx",
+ "postSql": ["select count(1) from all_employees_info"],
+ "preSql": [],
+ "flushInterval": 30000,
+ "connection": [
+ {
+ "jdbcUrl": "jdbc:mysql://127.0.0.1:9030/demo",
+ "selectedDatabase": "demo",
+ "table": ["all_employees_info"]
+ }
+ ],
+ "loadProps": {
+ "format": "json",
+ "strip_outer_array": "true",
+ "line_delimiter": "\\x02"
+ }
+ }
+ }
+ }
+ ],
+ "setting": {
+ "speed": {
+ "channel": "1"
+ }
+ }
+ }
+}
+```
+
+#### 4. インポートするデータ形式を設定する
+
+上記の例では、JSON 形式でデータをインポートします。
+
+```json
+"loadProps": {
+ "format": "json",
+ "strip_outer_array": "true",
+ "line_delimiter": "\\x02"
+}
+```
+
+JSON 形式を使用する際の注意点は次のとおりです。
+
+1. `line_delimiter` のデフォルトは改行文字で、データ内の値と衝突することがあります。インポートエラーを避けるため、特殊文字や不可視文字を使用してください。
+2. `strip_outer_array` は、インポートする単一バッチのデータに複数行が含まれることを示します。解析時に、Doris は外側の配列を展開し、その中の各 Object を個別の行として解析します。
+3. Stream Load のその他のパラメータについては、[Stream Load のドキュメント](../../data-operate/import/import-way/stream-load-manual.md) を参照してください。
+
+CSV 形式を使用する場合は、次のように設定します。
+
+```json
+"loadProps": {
+ "format": "csv",
+ "column_separator": "\\x01",
+ "line_delimiter": "\\x02"
+}
+```
+
+CSV 形式では、データ内の特殊文字との衝突を避けるため、行とカラムの区切り文字に特に注意してください。不可視文字の使用を推奨します。デフォルトのカラム区切り文字は `\t`、行区切り文字は `\n` です。
+
+#### 5. DataX ジョブを実行する
+
+次のコマンドでジョブを実行します。その他の実行方法については、[DataX ユーザーガイド](https://github.com/alibaba/DataX/blob/master/userGuid.md) を参照してください。
+
+```shell
+python bin/datax.py my_import.json
+```
+
+正常に実行されると、次のようなログが表示されます。
+
+```text
+2022-11-16 14:28:54.012 [job-0] INFO JobContainer - jobContainer starts to do prepare ...
+2022-11-16 14:28:54.012 [job-0] INFO JobContainer - DataX Reader.Job [mysqlreader] do prepare work .
+2022-11-16 14:28:54.013 [job-0] INFO JobContainer - DataX Writer.Job [doriswriter] do prepare work .
+2022-11-16 14:28:54.020 [job-0] INFO JobContainer - jobContainer starts to do split ...
+2022-11-16 14:28:54.020 [job-0] INFO JobContainer - Job set Channel-Number to 1 channels.
+2022-11-16 14:28:54.023 [job-0] INFO JobContainer - DataX Reader.Job [mysqlreader] splits to [1] tasks.
+2022-11-16 14:28:54.023 [job-0] INFO JobContainer - DataX Writer.Job [doriswriter] splits to [1] tasks.
+2022-11-16 14:28:54.033 [job-0] INFO JobContainer - jobContainer starts to do schedule ...
+2022-11-16 14:28:54.036 [job-0] INFO JobContainer - Scheduler starts [1] taskGroups.
+2022-11-16 14:28:54.037 [job-0] INFO JobContainer - Running by standalone Mode.
+2022-11-16 14:28:54.041 [taskGroup-0] INFO TaskGroupContainer - taskGroupId=[0] start [1] channels for [1] tasks.
+2022-11-16 14:28:54.043 [taskGroup-0] INFO Channel - Channel set byte_speed_limit to -1, No bps activated.
+2022-11-16 14:28:54.043 [taskGroup-0] INFO Channel - Channel set record_speed_limit to -1, No tps activated.
+2022-11-16 14:28:54.049 [taskGroup-0] INFO TaskGroupContainer - taskGroup[0] taskId[0] attemptCount[1] is started
+2022-11-16 14:28:54.052 [0-0-0-reader] INFO CommonRdbmsReader$Task - Begin to read record by Sql: [select taskid,projectid,taskflowid,templateid,template_name,status_task from dwd_universal_tb_task
+] jdbcUrl:[jdbc:mysql://localhost:3306/demo?yearIsDateType=false&zeroDateTimeBehavior=convertToNull&tinyInt1isBit=false&rewriteBatchedStatements=true].
+Wed Nov 16 14:28:54 GMT+08:00 2022 WARN: Establishing SSL connection without server's identity verification is not recommended. According to MySQL 5.5.45+, 5.6.26+ and 5.7.6+ requirements SSL connection must be established by default if explicit option isn't set. For compliance with existing applications not using SSL the verifyServerCertificate property is set to 'false'. You need either to explicitly disable SSL by setting useSSL=false, or set useSSL=true and provide truststore for ser [...]
+2022-11-16 14:28:54.071 [0-0-0-reader] INFO CommonRdbmsReader$Task - Finished read record by Sql: [select taskid,projectid,taskflowid,templateid,template_name,status_task from dwd_universal_tb_task
+] jdbcUrl:[jdbc:mysql://localhost:3306/demo?yearIsDateType=false&zeroDateTimeBehavior=convertToNull&tinyInt1isBit=false&rewriteBatchedStatements=true].
+2022-11-16 14:28:54.104 [Thread-1] INFO DorisStreamLoadObserver - Start to join batch data: rows[2] bytes[438] label[datax_doris_writer_c4e08cb9-c157-4689-932f-db34acc45b6f].
+2022-11-16 14:28:54.104 [Thread-1] INFO DorisStreamLoadObserver - Executing stream load to: 'http://127.0.0.1:8030/api/demo/dwd_universal_tb_task/_stream_load', size: '441'
+2022-11-16 14:28:54.224 [Thread-1] INFO DorisStreamLoadObserver - StreamLoad response :{"Status":"Success","BeginTxnTimeMs":0,"Message":"OK","NumberUnselectedRows":0,"CommitAndPublishTimeMs":17,"Label":"datax_doris_writer_c4e08cb9-c157-4689-932f-db34acc45b6f","LoadBytes":441,"StreamLoadPutTimeMs":1,"NumberTotalRows":2,"WriteDataTimeMs":11,"TxnId":217056,"LoadTimeMs":31,"TwoPhaseCommit":"false","ReadDataTimeMs":0,"NumberLoadedRows":2,"NumberFilteredRows":0}
+2022-11-16 14:28:54.225 [Thread-1] INFO DorisWriterManager - Async stream load finished: label[datax_doris_writer_c4e08cb9-c157-4689-932f-db34acc45b6f].
+2022-11-16 14:28:54.249 [taskGroup-0] INFO TaskGroupContainer - taskGroup[0] taskId[0] is successed, used[201]ms
+2022-11-16 14:28:54.250 [taskGroup-0] INFO TaskGroupContainer - taskGroup[0] completed it's tasks.
+2022-11-16 14:29:04.048 [job-0] INFO StandAloneJobContainerCommunicator - Total 2 records, 214 bytes | Speed 21B/s, 0 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 0.000s | All Task WaitReaderTime 0.000s | Percentage 100.00%
+2022-11-16 14:29:04.049 [job-0] INFO AbstractScheduler - Scheduler accomplished all tasks.
+2022-11-16 14:29:04.049 [job-0] INFO JobContainer - DataX Writer.Job [doriswriter] do post work.
+Wed Nov 16 14:29:04 GMT+08:00 2022 WARN: Establishing SSL connection without server's identity verification is not recommended. According to MySQL 5.5.45+, 5.6.26+ and 5.7.6+ requirements SSL connection must be established by default if explicit option isn't set. For compliance with existing applications not using SSL the verifyServerCertificate property is set to 'false'. You need either to explicitly disable SSL by setting useSSL=false, or set useSSL=true and provide truststore for ser [...]
+2022-11-16 14:29:04.187 [job-0] INFO DorisWriter$Job - Start to execute preSqls:[select count(1) from dwd_universal_tb_task]. context info:jdbc:mysql://172.16.0.13:9030/demo.
+2022-11-16 14:29:04.204 [job-0] INFO JobContainer - DataX Reader.Job [mysqlreader] do post work.
+2022-11-16 14:29:04.204 [job-0] INFO JobContainer - DataX jobId [0] completed successfully.
+2022-11-16 14:29:04.204 [job-0] INFO HookInvoker - No hook invoked, because base dir not exists or is a file: /data/datax/hook
+2022-11-16 14:29:04.205 [job-0] INFO JobContainer -
+ [total cpu info] =>
+ averageCpu | maxDeltaCpu | minDeltaCpu
+ -1.00% | -1.00% | -1.00%
+
+
+ [total gc info] =>
+ NAME | totalGCCount | maxDeltaGCCount | minDeltaGCCount | totalGCTime | maxDeltaGCTime | minDeltaGCTime
+ PS MarkSweep | 1 | 1 | 1 | 0.017s | 0.017s | 0.017s
+ PS Scavenge | 1 | 1 | 1 | 0.007s | 0.007s
+
+2022-11-16 14:29:04.205 [job-0] INFO JobContainer - PerfTrace not enable!
+2022-11-16 14:29:04.206 [job-0] INFO StandAloneJobContainerCommunicator - Total 2 records, 214 bytes | Speed 21B/s, 0 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 0.000s | All Task WaitReaderTime 0.000s | Percentage 100.00%
+2022-11-16 14:29:04.206 [job-0] INFO JobContainer -
+Job start time : 2022-11-16 14:28:53
+Job end time : 2022-11-16 14:29:04
+Total job duration : 10s
+Average job throughput : 21B/s
+Record write speed : 0rec/s
+Total records read : 2
+Total read/write failures : 0
+```
+
+## インポート時の注意点とベストプラクティス
+
+- `flushInterval` を小さすぎる値に設定しないでください。Doris への書き込みがブロックされてエラーコード `-235` が返されたり、`maxBatchRows` または `batchSize` のしきい値に達する前にインポートが開始されたりすることがあります。
+- CSV 形式を使用する場合は、`column_separator` と `line_delimiter` がデータ内の値と衝突しないか確認してください。不可視文字を使うと衝突の可能性を下げられます。
+- バッチが配列になっている JSON 形式を使用する場合は、Doris が配列内の各 Object を独立した行として解析するように `strip_outer_array = true` を設定してください。
+- `labelPrefix` は UUID と組み合わされてグローバルに一意なラベルとなり、重複インポートを防ぎます。
+- `loadUrl` にはカンマで区切って複数の FE アドレスを指定できます。doriswriter はそれらにラウンドロビン方式でアクセスします。
+
+## FAQ
+
+### DataX Doriswriter で同期できるのは MySQL のデータだけですか？
+
+いいえ。DataX は多くのデータソースをサポートしています。このドキュメントの詳細な例では MySQL を使用していますが、DataX がサポートする他のデータソースからも Doriswriter を介して Doris に書き込めます。
+
+### `loadUrl` にはどのポートを使用しますか？
+
+`loadUrl` には FE ノードの `http_port` を `ip:port` 形式で指定します。複数のアドレスを指定した場合、doriswriter はそれらにラウンドロビン方式でアクセスします。
+
+### JSON または CSV 形式でインポートする際に、区切り文字に注意が必要なのはなぜですか？
+
+`line_delimiter` や `column_separator` がデータ内の文字と衝突すると、インポートエラーが発生することがあります。区切り文字に特殊文字や不可視文字を使用すると、衝突の可能性を下げられます。
diff --git a/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/dbeaver.md b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/dbeaver.md
new file mode 100644
index 00000000000..0b8628285fc
--- /dev/null
+++ b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/dbeaver.md
@@ -0,0 +1,271 @@
+---
+{
+ "title": "DBeaver",
+ "language": "ja",
+ "description": "Apache Doris ドライバーまたは MySQL ドライバーで DBeaver を Apache Doris に接続し、内部・外部カタログを参照して SQL クエリを実行する方法を説明します。"
+}
+---
+
+<!-- Knowledge type: Operation steps -->
+<!-- Applicable scenario: Use DBeaver to connect to and manage Apache Doris databases -->
+
+DBeaver は、開発者、データベース管理者、アナリストなど、データを扱う人向けのクロスプラットフォーム対応データベースツールです。
+
+Apache Doris は MySQL プロトコルを通じてクエリを受け付けます。DBeaver 26.1.1 以降には `Apache Doris` データソースがあり、内部カタログと外部カタログにクエリを実行できます。
+
+`Select your database` ウィンドウに `Apache Doris` が表示されない場合は、MySQL ドライバーを使用してください。[MySQL ドライバーで接続する](#connect-with-the-mysql-driver)を参照してください。
+
+## ユースケース
+
+- Apache Doris のカタログ、データベース、テーブル、ビューなどのメタデータを参照する。
+- SQL エディターでクエリを実行し、データを分析する。
+- 単一のツールで内部カタログと外部カタログを管理する。
+- セッション、システム変数、ユーザー権限などの実行時情報を確認する。
+
+## 前提条件
+
+- [https://dbeaver.com](https://dbeaver.com) から DBeaver 26.1.1 以降をインストールします。
+- Apache Doris クラスターに接続でき、FE のホストアドレス、MySQL プロトコルのポート、ユーザー名、パスワードが分かっている必要があります。
+- `catalog.db` 形式で外部カタログに接続するには、Doris 2.1.0 以降を使用します。
+
+## DBeaver を Doris に接続する
+
+### Apache Doris ドライバーで接続する（推奨）
+
+:::warning バージョン要件
+DBeaver 26.1.1 以降が必要です。
+:::
+
+#### ステップ 1: データベース接続を作成する
+
+DBeaver を起動します。
+
+左上のプラス（`+`）アイコンをクリックするか、メニューバーから `Database` > `New Database Connection` を選択します。`Connect to a database` ウィンドウが開きます。
+
+
+
+#### ステップ 2: Apache Doris ドライバーを選択する
+
+`Select your database` ウィンドウで `Apache Doris` を検索または選択し、`Next` をクリックします。
+
+
+
+#### ステップ 3: Doris への接続を設定する
+
+`Main` タブ（`Apache Doris connection settings` ウィンドウ）で、次の値を入力します。
+
+| フィールド | 説明 | 例 |
+|-------|-------------|---------|
+| Host | FE のホスト名または IP アドレス。SSH トンネルを使用する場合は、ローカル転送先のアドレスを入力します。 | `127.0.0.1` |
+| Port | FE の MySQL プロトコルのポート。SSH トンネルを使用する場合は、ローカル転送先のポートを入力します。 | `9030` または `19030` |
+| Database/Schema | 省略可能。接続先のデータベース。外部カタログに直接接続する場合は `catalog.db` 形式を使用します。 | `example_db` または `hive.example_db` |
+| Username | Doris クラスターのユーザー名。 | `admin` |
+| Password | Doris クラスターのパスワード。 | - |
+
+`Database/Schema` の値によって、DBeaver が開くカタログとデータベースが決まります。
+
+- 空欄にすると、接続後に Database Navigator でカタログとデータベースを参照できます。
+- データベース名を入力すると、内部カタログ内のそのデータベースが開きます。
+- `catalog.db` を入力すると、指定した外部カタログ内のデータベースが開きます。DBeaver には、そのカタログとデータベースのテーブルが表示されます。
+
+:::note
+`catalog.db` 形式には Doris 2.1.0 以降が必要です。
+:::
+
+内部カタログに接続する場合:
+
+
+
+外部カタログに接続する場合:
+
+
+
+DBeaver に組み込まれた SSH 機能を使用するには、右上の `SSH, Proxy` をクリックしてトンネルを設定します。ローカルポート転送をすでに設定している場合は、`Host` と `Port` にローカルのアドレスとポートを入力します。
+
+#### ステップ 4: 接続をテストして保存する
+
+左下の `Test Connection` をクリックします。
+
+DBeaver に接続成功が表示されたら、`OK` をクリックします。
+
+`Finish` をクリックして接続を保存します。
+
+
+
+#### ステップ 5: Doris のオブジェクトを参照する
+
+新しいデータソースが Database Navigator に表示されます。展開すると、Doris のカタログ、データベース、テーブル、ビューを参照できます。
+
+
+
+#### ドライバーのプロパティを設定する
+
+Apache Doris ドライバーは MySQL Connector/J を使用して FE の MySQL プロトコルのポートに接続します。デフォルトのポートは `9030`、デフォルトのユーザーは `root` です。JDBC URL テンプレートは次のとおりです。
+
+```text
+jdbc:mysql://{host}[:{port}]/[{database}]
+```
+
+ドライバークラスは次のとおりです。
+
+```text
+com.mysql.cj.jdbc.Driver
+```
+
+ドライバーには、デフォルトで次の値が設定されます。
+
+```text
+connectTimeout=20000
+rewriteBatchedStatements=true
+useSSL=false
+enabledTLSProtocols=TLSv1.2,TLSv1.3
+```
+
+
+
+`useSSL=false` により、TLS/SSL はデフォルトで無効になります。FE の MySQL プロトコルのポートで TLS が有効であり、証明書チェーンが正しく設定されている場合は、`Driver properties` で MySQL Connector/J の SSL プロパティを設定します。例:
+
+```text
+useSSL=true
+sslMode=REQUIRED
+```
+
+認証局を検証するには、Java トラストストアを設定します。
+
+```text
+sslMode=VERIFY_CA
+trustCertificateKeyStoreUrl=file:/path/to/doris-truststore.jks
+trustCertificateKeyStorePassword=<password>
+```
+
+サーバーのホスト名も検証するには、次を使用します。
+
+```text
+sslMode=VERIFY_IDENTITY
+```
+
+`VERIFY_IDENTITY` を使用する場合、DBeaver の `Host` の値は証明書の SAN または CN と一致する必要があります。
+
+### MySQL ドライバーで接続する {#connect-with-the-mysql-driver}
+
+`Select your database` ウィンドウに `Apache Doris` が表示されない場合は、MySQL ドライバーで接続します。
+
+#### ステップ 1: データベース接続を作成する
+
+DBeaver を起動します。
+
+左上のプラス（`+`）アイコンをクリックするか、メニューバーから `Database` > `New Database Connection` を選択します。`Connect to a database` ウィンドウが開きます。
+
+
+
+#### ステップ 2: MySQL ドライバーを選択する
+
+`Select your database` ウィンドウで `MySQL` を選択します。
+
+#### ステップ 3: Doris への接続を設定する
+
+`Main` タブ（`Connection Settings` ウィンドウ）で、次の値を入力します。
+
+| フィールド | 説明 | 例 |
+|-------|-------------|---------|
+| Server Host | FE のホスト名または IP アドレス。 | `127.0.0.1` |
+| Port | FE の MySQL プロトコルのポート。 | `9030` |
+| Database | 接続先のデータベース。外部カタログに直接接続する場合は `catalog.db` 形式を使用します。 | `example_db` または `hive.example_db` |
+| Username | Doris クラスターのユーザー名。 | `admin` |
+| Password | Doris クラスターのパスワード。 | - |
+
+`Database` の値によって、デフォルトのカタログが決まります。
+
+- データベース名を入力すると、内部カタログ内のそのデータベースが開きます。
+- `catalog.db` を入力すると、指定した外部カタログ内のデータベースが開きます。DBeaver には、そのカタログとデータベースのテーブルが表示されます。
+
+複数のカタログに直接アクセスする必要がある場合は、Doris のデータソースを個別に作成します。
+
+:::note
+`catalog.db` 形式には Doris 2.1.0 以降が必要です。
+:::
+
+内部カタログに接続する場合:
+
+
+
+外部カタログに接続する場合:
+
+
+
+#### ステップ 4: 接続をテストして保存する
+
+左下の `Test Connection` をクリックします。
+
+DBeaver に接続成功が表示されたら、`OK` をクリックします。
+
+
+
+`Finish` をクリックして接続を保存します。
+
+#### ステップ 5: データベースを管理する
+
+新しいデータソースが Database Navigator に表示されます。このデータソースを使用して、データベースに接続し、管理します。
+
+
+
+## ドライバーの選択と機能の対応状況
+
+### ドライバーを選択する
+
+Apache Doris ドライバーと MySQL ドライバーは、どちらも FE の MySQL プロトコルのポートを通じて Doris に接続します。主な違いは、DBeaver におけるメタデータのモデル化、ナビゲーター内のオブジェクトの構成、管理機能の提供方法です。
+
+ドライバーを選択する際は、次の目安を使用してください。
+
+| ユースケース | 推奨ドライバー |
+|----------|--------------------|
+| Doris に接続し、SQL を実行してデータベースとテーブルを参照する | Apache Doris ドライバー |
+| 単一の接続で内部カタログと複数の外部カタログを参照する | Apache Doris ドライバー |
+| 使用中の DBeaver のバージョンに Apache Doris データソースがない | MySQL ドライバー |
+| Users、Session Manager、System Info を表示する | MySQL ドライバー |
+
+内部カタログのみを使用する場合は、どちらのドライバーでも Doris に接続して SQL を実行できます。ただし、Apache Doris ドライバーを推奨します。
+
+### 機能の比較
+
+| 機能 | Apache Doris ドライバー | MySQL ドライバー |
+|---------|---------------------|--------------|
+| Doris に接続して SQL を実行する | 対応 | 対応 |
+| 内部カタログを参照する | 対応 | 対応 |
+| 単一の接続で複数のカタログを参照する | 対応 | 非対応 |
+| Database Navigator で外部カタログを参照する | 対応 | 非対応 |
+| `catalog.db` をデフォルトの SQL コンテキストとして使用する | 対応 | 対応 |
+| テーブル、ビュー、カラム、DDL を表示する | 対応 | 対応 |
+| SQL エディターと SQL コンソールを使用する | 対応 | 対応 |
+| UI からデータを表示する | 対応 | 対応 |
+| UI からデータを挿入する | 対応 | 対応 |
+| Users、Session Manager、System Info を表示する | 非対応 | 対応 |
+| Tools > Analyse | 非対応 | 対応 |
+| Tools > Truncate | 非対応 | 対応 |
+
+:::note 対応範囲
+
+この表では、対応する機能を明示的に列挙しています。
+
+- 表で「対応」と明記された機能のみが、このドキュメントの対象です。
+- 表にない DBeaver の UI 操作や管理機能は、サポートされていません。
+- MySQL ドライバーを使用する場合、DBeaver のインターフェースに MySQL の機能が表示されても、Doris がその機能をサポートしているとは限りません。
+- Users、Session Manager、System Info は読み取り専用です。DBeaver を使用してユーザー、権限、セッションを変更することはできません。
+- `Analyse` と `Truncate` の対応は、MySQL ドライバー使用時の DBeaver の Tools メニューにのみ適用されます。Apache Doris ドライバーを使用する場合は、SQL エディターで対応する Doris SQL 文を実行してください。
+
+:::
+
+### 主な制限事項
+
+どちらのドライバーも、次の操作には対応していません。
+
+- UI から既存のデータを更新または削除する。
+- UI からテーブルを作成する。
+- UI からカラムを追加または変更する。
+- UI からインデックスを作成または変更する。
+- UI から外部キーまたはトリガーを作成する。
+- UI からキーモデル、パーティション、バケット、レプリカ数、テーブルプロパティを設定する。
+- Session Status、Global Status、Dashboard を使用する。
+- データベースに対して Check、Optimize、Repair、Dump を実行する。
+
+Doris のテーブルスキーマを変更したり、既存のデータを更新または削除したりする場合は、SQL エディターを使用してください。
diff --git a/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/dbt-doris-adapter.md b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/dbt-doris-adapter.md
new file mode 100644
index 00000000000..3a3975b3148
--- /dev/null
+++ b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/dbt-doris-adapter.md
@@ -0,0 +1,754 @@
+---
+{
+ "title": "dbtアダプター",
+ "sidebar_label": "dbtアダプター",
+ "language": "ja",
+ "description": "dbt-for-apache-doris 1.1.1をインストールし、モデル、External Catalogのソース、Icebergのターゲット、非同期マテリアライズドビューを設定します。",
+ "keywords": [
+ "Apache Doris dbt",
+ "dbt Dorisアダプター",
+ "dbt-for-apache-doris",
+ "dbt Dorisプロファイル",
+ "Dorisデータ変換",
+ "Dorisインクリメンタルモデル",
+ "Doris insert_overwrite",
+ "Doris microbatch",
+ "Dorisソースの鮮度",
+ "Doris非同期マテリアライズドビュー",
+ "dbt External Catalog",
+ "dbt debug接続エラー"
+ ]
+}
+---
+
+<!-- Knowledge Type: Integration Guide / Capability Definition -->
+<!-- Use Case: Apache Doris data transformation with dbt / ELT modeling -->
+
+[dbt](https://docs.getdbt.com/docs/introduction)は、ELT（抽出、ロード、変換）ワークフローの変換段階を管理します。`dbt-for-apache-doris`アダプターはdbtモデルをDoris SQLにコンパイルし、Doris Frontend（FE）のMySQLクエリポートを通じて、テーブル作成、変換、テスト、ドキュメント生成を実行します。
+
+ソースデータは、Internal Catalogのテーブルまたは設定済みのExternal Catalogを通じて、Dorisから照会できる状態である必要があります。アダプターはデータを変換しますが、ソースデータの取り込みや同期は行いません。
+
+:::caution
+
+`dbt-for-apache-doris`はVeloDBが提供・保守しています。Apache Dorisプロジェクトの一部ではなく、Apache Dorisコミュニティがリリースまたは推奨するものでもありません。本番環境で使用する前にアダプターを評価し、パッケージとリリース情報の完全性を確認して、サードパーティープロジェクトのライセンスに従ってください。アダプターの問題は[`dbt-for-apache-doris`プロジェクト](https://github.com/velodb/dbt-for-apache-doris/issues)に報告してください。
+
+:::
+
+<!-- Knowledge Type: Version Requirements / Environment Requirements / Released Versions -->
+<!-- Use Case: Pre-installation version check / Environment preparation / Release lookup -->
+
+## 環境要件
+
+| コンポーネント | 要件 |
+| --- | --- |
+| Python | 3.10以降 |
+| dbt Core | 1.12.x（アダプターとともにインストール） |
+
+## リリース済みバージョン
+
+| バージョン |
+| --- |
+| [1.1.1](https://github.com/velodb/dbt-for-apache-doris/releases/tag/v1.1.1) |
+| [1.1.0](https://github.com/velodb/dbt-for-apache-doris/releases/tag/v1.1.0) |
+
+<!-- Knowledge Type: Operational Steps -->
+<!-- Use Case: Adapter installation / Installation verification -->
+
+## インストール
+
+以下のコマンドでは、公開されている[`v1.1.1`リリース](https://github.com/velodb/dbt-for-apache-doris/releases/tag/v1.1.1)をインストール例として使用します。別のリリースをインストールする場合は、`pip`の要件指定に含まれるバージョンを置き換えてください。
+
+分離されたPython環境にPyPIからアダプターをインストールします。
+
+```shell
+python3 -m venv .venv
+source .venv/bin/activate
+python -m pip install --upgrade pip
+python -m pip install "dbt-for-apache-doris==1.1.1"
+dbt --version
+```
+
+Windows PowerShellの場合:
+
+```powershell
+py -m venv .venv
+.\.venv\Scripts\Activate.ps1
+python -m pip install --upgrade pip
+python -m pip install "dbt-for-apache-doris==1.1.1"
+dbt --version
+```
+
+この例では、`Plugins`セクション（`dbt --version`の出力）に`doris: 1.1.1`が含まれるはずです。dbt CoreとMySQL Connector/Pythonは依存パッケージとしてインストールされます。
+
+<!-- Knowledge Type: Operational Steps / Minimal Example -->
+<!-- Use Case: Connect dbt to Doris / Validate an end-to-end model build -->
+
+## 接続の設定
+
+dbtプロジェクトを作成します。
+
+```shell
+dbt init doris_demo
+cd doris_demo
+```
+
+`~/.dbt/profiles.yml`にDorisの出力設定を追加します。認証情報はバージョン管理の対象外にしてください。この例では、環境変数からパスワードを読み取ります。
+
+```yaml
+doris_demo:
+ target: dev
+ outputs:
+ dev:
+ type: doris
+ host: 127.0.0.1
+ port: 9030
+ username: dbt_user
+ password: "{{ env_var('DORIS_PASSWORD') }}"
+ schema: analytics
+ threads: 4
+```
+
+| 設定 | 推奨値 | 動作 |
+| --- | --- | --- |
+| `type` | `doris`を指定 | Dorisアダプターを選択します |
+| `host` | Doris FEのアドレスを明示的に指定 | 省略すると基となる認証情報の設定では`127.0.0.1`が使用されます。`dbt init`の入力にはデフォルト値がありません |
+| `port` | 通常は`9030` | 省略すると`9030`が使用されます。これはFEのクエリポートであり、HTTPポートではありません |
+| `username` | 専用のDorisユーザーを明示的に指定 | 省略すると基となる認証情報の設定では`root`が使用されます。`dbt init`の入力にはデフォルト値がありません |
+| `password` | 環境変数から読み取る | デフォルトは空文字列です |
+| `schema` | ターゲットのDorisデータベースを指定 | `dbt init`のプロンプトのデフォルトは`dbt`、基となる認証情報の設定のデフォルトは`None`です |
+| `threads` | FEとワークロードの処理能力に合わせて設定 | `dbt init`のプロンプトのデフォルトは`1`です |
+| `database` | Internal Catalogでは省略し、外部ターゲットでは既存のDoris Catalogを指定 | v1.1.1ではDoris Catalogに対応します |
+
+v1.1.1では、dbtの`database.schema.identifier`はDorisの`catalog.database.table`に対応します。Internal Catalogを使用する場合は`database`を省略し、`schema`にDorisデータベースを指定します。外部ターゲットの場合は、`database`に既存のDoris Catalogを、`schema`にそのCatalog内のデータベースを指定します。Catalogが対応していれば、アダプターは存在しないターゲットデータベースの作成を試みることができます。dbtの実行アカウントには、ソースの読み取りと、ターゲットオブジェクトの作成、変更、削除、書き込みの権限が必要です。External Catalogへの書き込み可否はDorisコネクターにも依存します。
+
+`dbt_project.yml`が同じプロファイルを参照していることを確認します。
+
+```yaml
+name: doris_demo
+version: "1.0.0"
+config-version: 2
+profile: doris_demo
+
+model-paths: ["models"]
+
+models:
+ doris_demo:
+ +materialized: view
+```
+
+macOSまたはLinuxでは、次のコマンドで接続を検証します。
+
+```shell
+export DORIS_PASSWORD='your_password'
+dbt debug
+```
+
+Windows PowerShellの場合:
+
+```powershell
+$env:DORIS_PASSWORD = 'your_password'
+dbt debug
+```
+
+<!-- Knowledge Type: Operational Steps / Minimal Example -->
+<!-- Use Case: Validate an end-to-end model build -->
+
+## 最初のモデルの構築
+
+次のSQLは、この例で使用するソーステーブルを作成します。レプリカ数`1`が適しているのは、単一BEの開発用クラスターに限られます。
+
+```sql
+CREATE DATABASE IF NOT EXISTS raw;
+
+CREATE TABLE IF NOT EXISTS raw.orders (
+ order_id BIGINT,
+ customer_id BIGINT,
+ order_time DATETIME,
+ amount DECIMAL(18, 2),
+ status VARCHAR(20),
+ updated_at DATETIME,
+ is_valid BOOLEAN
+)
+DUPLICATE KEY(order_id)
+DISTRIBUTED BY HASH(order_id) BUCKETS 1
+PROPERTIES ("replication_num" = "1");
+
+INSERT INTO raw.orders VALUES
+ (1, 101, '2026-08-01 10:00:00', 20.00, 'PAID', '2026-08-01 10:05:00', true),
+ (2, 102, '2026-08-01 11:00:00', 35.00, 'PAID', '2026-08-01 11:05:00', true);
+```
+
+`models/sources.yml`でソースを宣言します。
+
+```yaml
+version: 2
+
+sources:
+ - name: raw
+ schema: raw
+ tables:
+ - name: orders
+```
+
+`models/fct_daily_sales.sql`を作成します。
+
+```sql
+{{
+ config(
+ materialized='table',
+ duplicate_key=['order_date'],
+ distributed_by=['order_date'],
+ buckets=1,
+ properties={'replication_num': '1'}
+ )
+}}
+
+select
+ cast(order_time as date) as order_date,
+ sum(amount) as sales_amount
+from {{ source('raw', 'orders') }}
+group by cast(order_time as date)
+```
+
+`models/schema.yml`にデータテストを追加します。
+
+```yaml
+version: 2
+
+models:
+ - name: fct_daily_sales
+ description: Daily sales summary
+ columns:
+ - name: order_date
+ description: Order date
+ data_tests:
+ - not_null
+ - unique
+ - name: sales_amount
+ description: Daily sales amount
+ data_tests:
+ - not_null
+```
+
+モデルとテストを実行します。
+
+```shell
+dbt build --select fct_daily_sales
+```
+
+ビルドが成功すると、`analytics.fct_daily_sales`が作成されます。本番環境のレプリカ数とバケット数は、クラスターの構成に合わせて設定してください。
+
+ソースが別のDorisデータベースにある場合は、`schema`を直接指定することを推奨します。
+
+```yaml
+sources:
+ - name: finance
+ schema: finance_raw
+ tables:
+ - name: payments
+```
+
+v1.1.1では、ソースの`database`はDoris Catalogの名前を表します。Internal Catalog内の別のデータベースから読み取るには、上記のように`schema`のみを設定します。v1.1.0でデータベースをまたぐソースに`database: finance_raw`を使用していたプロジェクトでは、アップグレード前にその値を`schema`へ移してください。
+
+## v1.1.1でのExternal Catalog
+
+アダプターはExternal Catalog内のソースを読み取り、`dbt docs generate`用にそのテーブルと列を検出できます。先にDorisでCatalogを作成し、その名前をソースの`database`フィールドに指定します。
+
+```yaml
+sources:
+ - name: lakehouse
+ database: hive_catalog
+ schema: ods
+ tables:
+ - name: orders
+```
+
+`{{ source('lakehouse', 'orders') }}`は`hive_catalog.ods.orders`に解決されます。`schema`フィールドは、そのCatalog内のデータベース名です。アダプターはCatalog名を含むリレーション名に対応していますが、Dorisで実行できるDDLと書き込み操作は各Catalogコネクターによって決まります。
+
+Icebergのターゲットを作成するには、まず[書き込み可能なIceberg Catalogを設定](../../lakehouse/catalogs/iceberg-catalog)します。既存のプロファイル出力設定に次のフィールドを指定します。
+
+```yaml
+database: iceberg_catalog
+schema: analytics
+```
+
+`models/iceberg_sample.sql`を作成します。
+
+```sql
+{{ config(materialized='table', engine='iceberg') }}
+
+select cast(1 as int) as id
+```
+
+明示的に`INT`へキャストすることで、Icebergの列型として使用できない`TINYINT`として推論されるのを防ぎます。
+
+`dbt run --select iceberg_sample`を実行します。`iceberg_catalog.analytics.iceberg_sample`が作成されます。Catalogは存在している必要があり、そのデータベースは既存かdbtによって作成可能で、ターゲットは書き込み可能である必要があります。`engine='iceberg'`は明示的なエンジン句を出力します。`engine`を省略すると、DorisがターゲットCatalogから推論します。Catalogに基づく推論はDoris 4.1.3で検証されています。以前のDorisリリースでは、明示的なエンジン指定が必要な場合があります。
+
+| Icebergのターゲット | v1.1.1での動作 |
+| --- | --- |
+| `table` | Icebergテーブルを作成します。再実行時はバックアップと名前変更によって置き換えます |
+| `incremental` | 以下で説明する`append`、`merge`、`insert_overwrite`、`microbatch`に対応します |
+| SeedとSnapshot | 対応しています。Snapshotの公開とSeedの全件更新には、バックアップと名前変更を使用します。通常の再ロードでは、非パーティションテーブルにINSERT OVERWRITE、パーティションテーブルにネイティブMERGEを使用し、後者はV2以降が必要です。V1のパーティション化されたSeedには`dbt seed --full-refresh`を使用してください |
+| `view`と`materialized_view` | ターゲットはInternal Catalogに置く必要があります。Internal CatalogのビューとMVはExternal Catalogのソースを照会できます |
+
+Icebergの`merge`、`microbatch`、パーティション化されたSeedの再ロードには、ネイティブのIceberg `MERGE INTO`に対応するDorisリリースと、Iceberg V2以降のテーブルが必要です。これらの処理経路はDoris 4.1.3で検証されています。[DorisのドキュメントではIceberg MERGEは4.1.0以降、実験的機能とされています](../../lakehouse/catalogs/iceberg-catalog#merge-into)。外部テーブルの置き換えはアトミックではありません。名前変更の間は一時的に元の名前でアクセスできなくなり、失敗すると旧テーブルがバックアップ名で残る場合があります。本番環境で使用する前に、分離されたテストプロジェクトでDorisのリリース、Catalogコネクター、復旧手順を検証してください。
+
+アダプターは、Table、View、Incremental、MVのターゲットを書き込む前に、モデルまたは列の`constraints`宣言を拒否します。モデルコントラクトでは引き続き列名と型を検査します。書き込み後のデータ検証には`data_tests`を使用してください。たとえば`not_null`を指定できます。これらはデータベースが強制する制約を作成しません。
+
+[実行可能な五つのDorisデモ](https://github.com/velodb/dbt-for-apache-doris/tree/3fb9cc75f9dcdd756b472847728bbdf42fb3b128/examples/doris-demos)では、モデル、テスト、データベースをまたぐソース、インクリメンタル処理、スナップショット、非同期マテリアライズドビューを扱います。デモのセットアップではデフォルトで`dbt-for-apache-doris==1.1.1`を使用します。
+
+<!-- Knowledge Type: Capability Reference / Configuration Parameters / Architecture Decision -->
+<!-- Use Case: Materialization selection / Incremental processing / Materialized views -->
+
+## マテリアライゼーション
+
+`dbt-for-apache-doris`は、主に次のマテリアライゼーションに対応します。
+
+| マテリアライゼーション | Dorisのオブジェクトまたは動作 | 用途 |
+| --- | --- | --- |
+| `view` | Internal CatalogのDorisビュー | 常に最新のソースデータを読み取る軽量な変換 |
+| `table` | 毎回全件再構築するInternal CatalogのDuplicate Keyテーブル、または書き込み可能なIcebergテーブル | 安定したクエリ性能を必要とする、結果の規模が限定された処理 |
+| `incremental` | 戦略に応じてデータを追加、アップサート、または上書き | 大規模テーブルのインクリメンタル処理 |
+| `materialized_view` | Internal CatalogのDoris非同期マテリアライズドビュー | Dorisが管理する更新と透過的なクエリ書き換え |
+| `ephemeral` | 下流モデルでCTEにコンパイル | Dorisオブジェクトを作成せずにSQLを再利用 |
+
+SeedとSnapshotでもDorisテーブルを作成できます。現時点でアダプターには独自の`partition`マテリアライゼーションはありません。パーティションの置き換えには、インクリメンタルの`insert_overwrite`を使用します。以下の例では、単一BEの開発用クラスターでも実行できるよう`replication_num=1`を使用しています。実際の本番環境では、適切なレプリカ数を使用してください。
+
+### ビュー
+
+```sql
+{{ config(materialized='view') }}
+
+select order_id, customer_id, amount
+from {{ source('raw', 'orders') }}
+where status = 'PAID'
+```
+
+実行のたびにビュー定義が更新されます。ビューはデータを保存しません。クエリのコストはビューのSQLと下流のクエリによって決まります。
+
+### テーブル
+
+```sql
+{{
+ config(
+ materialized='table',
+ duplicate_key=['event_date', 'event_id'],
+ partition_by=['event_date'],
+ partition_type='RANGE',
+ partition_by_init=[
+ "PARTITION p_before_202608 VALUES LESS THAN ('2026-08-01')",
+ "PARTITION p202608 VALUES LESS THAN ('2026-09-01')",
+ "PARTITION pmax VALUES LESS THAN (MAXVALUE)"
+ ],
+ distributed_by=['event_id'],
+ buckets=16,
+ properties={'replication_num': '1'}
+ )
+}}
+
+select
+ cast(order_time as date) as event_date,
+ order_id as event_id,
+ status as event_type
+from {{ source('raw', 'orders') }}
+```
+
+Internal Catalogのターゲットでは、`table`マテリアライゼーションはDuplicate Keyテーブルを作成し、以降の実行時にそのテーブルを全件置き換えます。Icebergのターゲットでは、DorisのOLAPキーやデフォルトの分散設定を使用しません。テーブルモデルでは、次のテーブル作成設定を指定できます。
+
+| 設定 | 型とデフォルト | 説明 |
+| --- | --- | --- |
+| `duplicate_key` | 文字列またはリスト。省略可能 | Duplicate Keyの列 |
+| `partition_by` | 文字列またはリスト。省略可能 | パーティション列 |
+| `partition_type` | `RANGE`または`LIST`。デフォルトは`RANGE` | `partition_by`とともに使用するパーティション方式 |
+| `partition_by_init` | 文字列のリスト。省略可能 | テーブル作成時に`partition_by`とともに使用するDorisのパーティション定義 |
+| `distributed_by` | 文字列またはリスト。省略可能 | ハッシュ分散の列 |
+| `buckets` | 正の整数。ハッシュ分散を出力する場合のデフォルトは`10` | ハッシュバケット数。`distributed_by`とともに指定した場合のみ使用 |
+| `replication_num` | 正の整数または数値文字列。省略可能 | レプリカ数。トップレベルの設定は`properties`内の同じキーより優先されます |
+| `properties` | 辞書。省略可能 | Dorisの`PROPERTIES`として出力するキーと値のペア |
+
+Duplicate Key列、パーティション列、分散列はモデルの出力に含まれ、Dorisのテーブル作成ルールを満たす必要があります。アダプターは`partition_by_init`と`properties`を`CREATE TABLE`文に出力し、Dorisがパーティション定義、プロパティ名、値を検証します。`duplicate_key`や`distributed_by`などのOLAP固有のオプションはIcebergのターゲットには適しません。通常の`table`モデルでは、現時点でAggregate Keyや独立したUnique Keyの設定は公開されていません。Unique Keyによるアップサートには、インクリメンタルの`merge`を使用します。
+
+### インクリメンタル
+
+`append`、`merge`、`insert_overwrite`を使用するインクリメンタルモデルは、次の二つの要素で構成されます。
+
+- モデルSQL（通常は`is_incremental()`を使用）が、今回の実行で返すソース行を決定します。
+- `incremental_strategy`が、そのバッチをターゲットに書き込む方法を決定します。
+
+Microbatchではこのフィルタリング方式を使用しません。dbt Coreがバッチのコンテキストと上流リソースに設定された`event_time`を基に時間フィルターを挿入します。
+
+| 戦略 | Dorisのターゲットと動作 | 主な要件 |
+| --- | --- | --- |
+| `append` | OLAPのDuplicate Keyテーブルまたは書き込み可能なIcebergテーブルに`INSERT INTO` | `unique_key`を設定しないでください |
+| `merge` | OLAPのUnique Keyテーブルには全列の`INSERT INTO`によるアップサート、Icebergにはネイティブの`MERGE INTO` | `unique_key`が必要です。IcebergではネイティブMERGEへの対応とV2以降のテーブルも必要です |
+| `insert_overwrite` | OLAPではテーブル全体、名前を指定したパーティション、または動的パーティションの上書き。Icebergではテーブル全体、動的または静的なパーティションの上書き | `unique_key`は指定できません。Icebergの静的な対象範囲には列と値のマッピングを使用します |
+| `microbatch` | OLAPでは正確に対応するRANGEパーティションを上書きし、IcebergではネイティブMERGEで一つのUTCウィンドウを置き換えます | `event_time`、`batch_size`、`begin`を設定します。IcebergではネイティブMERGEへの対応とV2以降のテーブルが必要です |
+
+戦略を設定しない場合、`unique_key`があれば`merge`が選ばれ、なければ`append`が使用されます。アダプターは`on_schema_change`の四つのモード（`ignore`、`fail`、`append_new_columns`、`sync_all_columns`）すべてに対応します。
+
+`delete+insert`と`delete_insert`は拒否されます。DorisのUnique Keyによるアップサートには`merge`を使用してください。OLAPのターゲットでは、`merge`はDorisのUnique Keyのセマンティクスに従い、全列の`INSERT INTO`を使用します。Icebergのターゲットでは、ネイティブの`MERGE INTO`を生成し、書き込み前にソースキーの重複を拒否します。各バッチで、`unique_key`の各値に対応する行は最大一行でなければなりません。Sequence Columnを使用するには、`function_column.sequence_col`で可視列を`properties`内に指定し、引き続き`merge`を使用します。単独の`sequence_col`設定と、`function_column.sequence_type`を隠し列`__DORIS_SEQUENCE_COL__`とともに使う方法には現時点で対応していません。
+
+次の例では、`order_id`をキーとして全列をアップサートします。
+
+```sql
+{{
+ config(
+ materialized='incremental',
+ incremental_strategy='merge',
+ unique_key=['order_id'],
+ distributed_by=['order_id'],
+ buckets=16,
+ properties={'replication_num': '1'},
+ on_schema_change='append_new_columns'
+ )
+}}
+
+select
+ order_id,
+ customer_id,
+ amount,
+ updated_at
+from {{ source('raw', 'orders') }}
+
+{% if is_incremental() %}
+where updated_at >= (
+ select coalesce(max(updated_at), '1970-01-01 00:00:00')
+ from {{ this }}
+)
+{% endif %}
+```
+
+名前を指定したInternal CatalogのDorisパーティションを上書きするには、次のようにします。
+
+```sql
+{{
+ config(
+ materialized='incremental',
+ incremental_strategy='insert_overwrite',
+ duplicate_key=['event_date', 'event_id'],
+ partition_by=['event_date'],
+ partition_type='RANGE',
+ partition_by_init=[
+ "PARTITION p_before_202607 VALUES LESS THAN ('2026-07-01')",
+ "PARTITION p202607 VALUES LESS THAN ('2026-08-01')",
+ "PARTITION p202608 VALUES LESS THAN ('2026-09-01')",
+ "PARTITION pmax VALUES LESS THAN (MAXVALUE)"
+ ],
+ overwrite_partitions=['p202607', 'p202608'],
+ distributed_by=['event_id'],
+ buckets=16,
+ properties={'replication_num': '1'}
+ )
+}}
+
+select event_date, event_id, event_type
+from (
+ select
+ cast(order_time as date) as event_date,
+ order_id as event_id,
+ status as event_type,
+ order_time
+ from {{ source('raw', 'orders') }}
+) events
+
+{% if is_incremental() %}
+where order_time >= '2026-07-01'
+ and order_time < '2026-09-01'
+{% endif %}
+```
+
+初回の実行ではCTASによってターゲットを作成し、`INSERT OVERWRITE`は実行しません。このため、この例では`partition_by_init`を使用して必要なターゲットパーティションをすべて作成します。ターゲットの作成後は、`overwrite_partitions`が上書き範囲を制御します。
+
+- 省略した場合: テーブル全体を上書きします。
+- パーティション名のリスト: 指定したパーティションのみを上書きします。
+- `'*'`: バッチが対象とするパーティションをDorisが動的に上書きします。
+
+動的なOLAP上書きでは、空のバッチからクリアすべきパーティションを推論できません。ソースのバッチが空でもターゲットデータを削除する必要がある場合は、パーティション名を指定してください。
+
+Icebergのターゲットでは、`overwrite_partitions`を省略すると、パーティション化されたテーブルでネイティブの動的上書きが使用されます。一つの静的な範囲を置き換えるには、`overwrite_partitions={'dt': '2025-01-25'}`のように、空でない列と値のマッピングを指定します。モデルは、その範囲のすべての行を返す必要があります。パーティション化されていないターゲットでは、モデルは置き換え後の全データを返す必要があり、結果が空ならテーブルがクリアされます。静的な範囲でも、結果が空ならその範囲がクリアされます。`NULL`を含むマッピングではネイティブMERGEを使用し、Iceberg V2以降が必要です。
+
+### マイクロバッチ
+
+`microbatch`はdbt Coreのバッチコンテキストを使用します。次の例はInternal CatalogのOLAPテーブルをターゲットにし、各UTCウィンドウに正確に対応する一つのRANGEパーティションを上書きします。直接参照する各上流リソースとターゲットモデルに`event_time`フィールドを設定してください。上記の最初のモデルの例で作成した`raw.orders`ソースについては、既存のテーブル宣言に次の設定を追加します。
+
+```yaml
+sources:
+ - name: raw
+ schema: raw
+ tables:
+ - name: orders
+ config:
+ event_time: order_time
+```
+
+```sql
+{{
+ config(
+ materialized='incremental',
+ incremental_strategy='microbatch',
+ event_time='event_time',
+ batch_size='day',
+ begin=modules.datetime.datetime(2026, 8, 1, 0, 0, 0),
+ duplicate_key=['event_id', 'event_time'],
+ partition_by=['event_time'],
+ partition_type='RANGE',
+ distributed_by=['event_id'],
+ buckets=16,
+ properties={'replication_num': '1'}
+ )
+}}
+
+select
+ order_id as event_id,
+ order_time as event_time,
+ status as event_type
+from {{ source('raw', 'orders') }}
+```
+
+Internal CatalogのOLAPターゲットでは、`event_time`は引用符で囲まない列名で、`partition_by`と同じ単一列を指す必要があります。`batch_size`は`hour`、`day`、`month`、`year`に対応します。ターゲットはDuplicate Keyテーブルです。`duplicate_key`はDorisのテーブルキーを設定するもので、dbtの`unique_key`ではありません。`unique_key`、`overwrite_partitions`、`partition_by_init`は設定しないでください。アダプターが現在のバッチからパーティション境界と上書き対象を導き出します。上流の`ref()`または`source()`にも`event_time`が設定されていれば、dbt Coreはその入力を現在のウィンドウに絞り込みます。Microbatchの各バッチは順次実行され、空のバッチでも該当パーティションを上書きするため、そのウィンドウから削除された行もクリアされます。
+
+次のプロパティを設定し、アダプターの検証に合格する場合、Internal CatalogのMicrobatchでDorisのDynamic Partitionも使用できます。
+
+- `dynamic_partition.enable='true'`。
+- `dynamic_partition.time_unit`が`batch_size`と一致し、`dynamic_partition.time_zone`が`UTC`、`Etc/UTC`、`+00:00`のいずれかであること。
+- `dynamic_partition.create_history_partition='true'`であり、`dynamic_partition.start`または`dynamic_partition.history_partition_num`のいずれかを指定すること。
+- `dynamic_partition.prefix`が有効な識別子であり、`dynamic_partition.end`が正の整数であること。
+- 月単位のバッチでは、`dynamic_partition.start_day_of_month`を設定する場合、その値が`1`であること。
+
+DorisではDynamic Partitionテーブルの作成時に`dynamic_partition.buckets`の値も正である必要があります。このプロパティはアダプターではなくDorisが検証します。保持期間には、`begin`、`lookback`、手動でのバックフィル範囲が含まれている必要があります。既存のターゲットについては、アダプターが検証する物理プロパティがモデル設定と一致する必要があります。一致しない場合は設定を合わせるか、`--full-refresh`を実行してください。
+
+:::caution
+
+`append`、`merge`、パーティション単位の`insert_overwrite`では、アダプターは新規または変更されたソース行を自動検出しません。モデルSQLが意図したバッチを返す必要があります。テーブル全体を対象にした`insert_overwrite`では、ターゲットの全データを返す必要があります。各`merge`バッチ内の`unique_key`の値は一意でなければなりません。dbt Coreは`event_time`を設定した上流リソースからMicrobatch用のフィルタリングを行うため、Microbatchモデルで`is_incremental()`は不要です。キー、パーティション、または物理レイアウトに互換性のない変更を加えた後は、`dbt run --full-refresh`を実行してください。IcebergのMicrobatchでは、`unique_key`、`overwrite_partitions`（列と値のマッピングを含む）、`partition_by_init`、OLAPのDynamic Partitionプロパティを省略します。` [...]
+
+:::
+
+### 非同期マテリアライズドビュー
+
+dbtユーザーは標準の`materialized='materialized_view'`を設定します。アダプターはDorisの[非同期マテリアライズドビュー](../../query-acceleration/materialized-view/async-materialized-view/overview)を使用して実装します。
+
+:::note
+
+このマテリアライゼーションに対するFEのバージョン判定では、Doris 2.xの2.1.5以降、Doris 3.x（3.0.0を除く）、Doris 4.x以降、および`doris-0.0.0-<git-sha>`として報告される識別可能なソースビルドが許可されます。ソースビルドは開発テスト専用です。これらはコード上で受け入れる条件であり、許可されたすべてのバージョンで互換性テストに合格した証拠ではありません。
+
+:::
+
+```sql
+{{
+ config(
+ materialized='materialized_view',
+ build_mode='immediate',
+ refresh_method='auto',
+ refresh_trigger='manual',
+ duplicate_key=['order_date'],
+ distribution_type='hash',
+ distributed_by=['order_date'],
+ buckets=8,
+ wait_for_refresh=true,
+ properties={'replication_num': '1'}
+ )
+}}
+
+select order_date, sales_amount
+from {{ ref('fct_daily_sales') }}
+```
+
+| 設定 | デフォルト | 対応する値または形式 |
+| --- | --- | --- |
+| `build_mode` | `immediate` | `immediate`, `deferred` |
+| `refresh_method` | `auto` | `auto`ではDorisが更新範囲を決定し、`complete`ではすべてのパーティションを更新します |
+| `refresh_trigger` | `manual` | `manual`, `schedule`, `commit` |
+| `refresh_schedule` | - | `schedule`で必須。正の`interval`、`minute/hour/day/week`のいずれかの単位、省略可能な`start_time`を含みます |
+| `wait_for_refresh` | `true` | `BUILD IMMEDIATE`による初回の構築、またはアダプターが送信した手動更新の完了を待つかどうか |
+| `refresh_wait_timeout` | `300` | 更新タスクのタイムアウト（秒）。正の整数 |
+| `refresh_poll_interval` | `1` | 更新タスクのポーリング間隔（秒）。タイムアウト以下の正の整数 |
+| `duplicate_key` | - | 非同期マテリアライズドビューのDuplicate Key列。文字列またはリスト |
+| `partition_by` | - | Dorisのパーティション列またはパーティション関数式を一つ指定。文字列または単一要素のリスト |
+| `distribution_type` | 自動選択 | `hash`（`distributed_by`を設定した場合）、それ以外は`random` |
+| `distributed_by` | - | ハッシュ分散の列 |
+| `buckets` | `auto` | 正の整数または`auto` |
+| `replication_num` | - | レプリカ数を簡単に指定するための設定。`properties`内の同じキーより優先されます |
+| `properties` | `{}` | Doris非同期マテリアライズドビューのプロパティ |
+| `on_configuration_change` | `apply` | `apply`, `continue`, `fail` |
+
+`BUILD IMMEDIATE`は、定義の作成時または置き換え時に初回の構築を開始します。アダプターは一時的な名前で新しい定義を作成し、デフォルトでは初回の構築を待ってからターゲット名で公開します。追加の`REFRESH MATERIALIZED VIEW`は送信しません。`BUILD DEFERRED`は初回の構築を行わずに定義を作成します。
+
+定義が変わっていない場合、更新動作は`refresh_trigger`だけで制御されます。現時点で`refresh_on_run`設定はありません。
+
+- `manual`では、`REFRESH MATERIALIZED VIEW ... AUTO|COMPLETE`を後続の`dbt run`でモデルが選択されたときに送信し、デフォルトでは成功するまで待ちます。
+- `schedule`と`commit`では、後続のdbt実行から更新を送信しません。Dorisがスケジュールまたはベーステーブルへのコミットを契機に更新します。
+
+たとえば、日次スケジュールは次のように設定します。
+
+```sql
+{{
+ config(
+ materialized='materialized_view',
+ build_mode='deferred',
+ refresh_method='auto',
+ refresh_trigger='schedule',
+ refresh_schedule={
+ 'interval': 1,
+ 'unit': 'day'
+ },
+ properties={'replication_num': '1'}
+ )
+}}
+
+select order_date, sales_amount
+from {{ ref('fct_daily_sales') }}
+```
+
+`wait_for_refresh=false`はタスクのポーリングを無効にしますが、更新リクエストは抑止しません。dbt側の待機がタイムアウトしても、送信済みのDorisタスクはキャンセルされません。アダプターは、送信前後のDoris MVタスクIDを比較して新しいタスクを識別します。そのため、同じターゲットに対する手動更新を並行して実行しないでください。
+
+モデルSQLまたはDDL設定が変わった場合、デフォルトの`on_configuration_change=apply`は一時的な非同期マテリアライズドビューを構築し、既存の定義をアトミックに置き換えます。`continue`は手動更新を送信せずに既存の定義を維持し、`fail`は実行を停止します。`--full-refresh`は定義の再デプロイを強制します。
+
+<!-- Knowledge Type: Capability Reference / Configuration Parameters -->
+<!-- Use Case: Seeds / Snapshots / Source freshness / Grants -->
+
+## その他のdbt機能
+
+| 機能 | 対応状況 |
+| --- | --- |
+| Seed | `seeds/`にバージョン管理された小さなCSVファイルを配置し、`dbt seed`を実行します。型推論、`column_types`、`ref`に対応します |
+| Snapshot | `check`または`timestamp`戦略を`snapshots/`で定義し、`dbt snapshot`を実行します。ハードデリートとスキーマの変更に対応します。Internal Catalogでの置き換えはアトミックですが、Icebergではバックアップと名前変更を使用します |
+| データテスト | YAMLでGeneric Testを設定するか、`tests/`にSingular Testを記述します。ephemeralと`store_failures`の処理経路に対応します |
+| ユニットテスト | モデルのYAMLに行を直接記述するかCSVのフィクスチャーを指定し、`dbt test --select test_type:unit`を実行します |
+| モデルコントラクト | `contract.enforced: true`を設定し、Table、View、Incrementalモデルの列名と型を宣言します。`constraints`宣言は拒否され、データテストはデータベースの制約を作成しません |
+| 永続化されたドキュメント | `persist_docs`を有効にして、主要なリレーション型にリレーションと列のコメントを設定します |
+| ソースの鮮度 | `loaded_at_field`または`loaded_at_query`を`freshness`とともに設定し、`dbt source freshness`を実行します |
+| 権限付与 | 標準の`grants`設定をDorisの`user`および`user@host`のテーブル権限に使用します。ロールをプリンシパルにすることは現時点でできません |
+| フック | `pre_hook`と`post_hook`を使用して、マテリアライゼーションの前後にDoris SQLを実行します。フックの副作用はトランザクションでロールバックされません |
+| ドキュメントとリネージ | 説明を記述して`dbt docs generate`を実行し、Internal Catalogの非同期マテリアライズドビューを含むInternal CatalogとExternal Catalogのリレーション・列のメタデータを生成します |
+
+Seedは国コードやステータスの対応表など、バージョン管理される小規模なデータに適しています。大量の業務データの取り込みには適しません。大きなファイルにはDoris Stream Load、Broker Load、またはDoris Connectorを使用してください。
+
+Snapshotのソースにある`unique_key`の値は`NULL`以外で、各バッチ内で一意でなければなりません。`timestamp`戦略では、`updated_at`も`NULL`以外で、そのキーの現在の履歴バージョンより前の値にすることはできません。
+
+テーブルと列の説明を永続化するには、次のようにします。
+
+```yaml
+models:
+ - name: fct_daily_sales
+ description: Daily sales summary
+ config:
+ persist_docs:
+ relation: true
+ columns: true
+ columns:
+ - name: order_date
+ description: Order date
+ - name: sales_amount
+ description: Daily sales amount
+```
+
+### ソースの鮮度
+
+ソースの鮮度は、タイムスタンプを明示的に指定する二つの方法に対応します。一般的なタイムスタンプ列を使う場合は`loaded_at_field`を使用します。
+
+```yaml
+sources:
+ - name: raw
+ schema: raw
+ tables:
+ - name: orders
+ config:
+ loaded_at_field: updated_at
+ freshness:
+ warn_after: {count: 1, period: hour}
+ error_after: {count: 2, period: hour}
+```
+
+鮮度を判定するタイムスタンプにカスタムSQLまたは集約が必要な場合は、`loaded_at_query`を使用します。
+
+```yaml
+sources:
+ - name: raw
+ schema: raw
+ tables:
+ - name: orders
+ config:
+ loaded_at_query: |
+ select max(updated_at)
+ from {{ this }}
+ where is_valid = 1
+ freshness:
+ warn_after: {count: 1, period: hour}
+ error_after: {count: 2, period: hour}
+```
+
+`loaded_at_field`を使用する場合は、鮮度評価の対象行を絞り込むため、`filter`を`freshness`の下に設定します。たとえば`filter: is_valid = 1`を指定します。`loaded_at_field`と`loaded_at_query`を同時に設定しないでください。現時点でアダプターはDorisのテーブルメタデータからロード時刻を推論しません。フィールドまたはクエリを明示的に指定してください。
+
+アダプターは現在時刻として`utc_timestamp()`を使用します。これはタイムゾーン情報のない鮮度判定用タイムスタンプをUTCとして評価するdbt Coreの慣例に沿っています。
+
+### 権限付与
+
+宣言的な権限付与ではDorisユーザーをプリンシパルとして使用します。
+
+```yaml
+models:
+ doris_demo:
+ +grants:
+ select:
+ - analyst
+ - reporter@10.0.0.%
+```
+
+`@host`を含まない名前は`username@%`として扱われます。権限の対応は、`select`が`SELECT_PRIV`、`insert`が`LOAD_PRIV`、`alter`が`ALTER_PRIV`、`create`が`CREATE_PRIV`、`drop`が`DROP_PRIV`、`show_view`が`SHOW_VIEW_PRIV`です。Dorisのロールは現時点で`grants`に対応していないため、具体的なユーザーを設定してください。dbtの実行アカウントには、プリンシパルの確認とターゲットオブジェクトの権限調整ができる必要があります。
+
+<!-- Knowledge Type: Command Reference -->
+<!-- Use Case: dbt project development / Execution / Testing / Documentation generation -->
+
+## よく使うコマンド
+
+| コマンド | 目的 |
+| --- | --- |
+| `dbt debug` | プロジェクト設定とDorisへの接続を検証します |
+| `dbt parse` | SQLを実行せずにプロジェクトを解析します |
+| `dbt compile` | モデルをコンパイルし、生成されたDoris SQLを確認します |
+| `dbt run` | 選択したモデルを構築します |
+| `dbt test` | データテストとユニットテストを実行します |
+| `dbt build` | 依存関係の順序に従ってSeed、モデル、Snapshot、テストを実行します |
+| `dbt seed` | SeedのCSVファイルをロードします |
+| `dbt snapshot` | Snapshotを更新します |
+| `dbt source freshness` | ソースの鮮度を評価します |
+| `dbt docs generate` | カタログ、ドキュメント、リネージのメタデータを生成します |
+
+よく使うセレクター:
+
+```shell
+# Run one model
+dbt run --select fct_daily_sales
+
+# Run the model and all upstream dependencies
+dbt build --select +fct_daily_sales
+
+# Run the model and all downstream dependencies
+dbt build --select fct_daily_sales+
+
+# Fully rebuild an incremental model
+dbt run --select fct_orders --full-refresh
+```
+
+<!-- Knowledge Type: Limitations / Architecture Decision -->
+<!-- Use Case: Version evaluation / Production readiness review -->
+
+## 現在の制限事項
+
+- 現時点でアダプターは、Aggregate Keyテーブルのモデリングとセカンダリインデックスの設定に対応していません。
+- External Catalogへの書き込み動作はDorisコネクターに依存します。Catalogs V2とコネクター固有の書き込み保証には対応していません。
+- 現時点でアダプターは、SSLの設定、タイムアウトとリトライ、複数FEのフェイルオーバー、サーバー側でのキャンセル、完全なクエリテレメトリーを実装していません。
+- 一部のTable、View、MVの型変更では、無停止で切り替わるのではなく、正規の名前が短時間利用できなくなります。
+
+<!-- Knowledge Type: Troubleshooting -->
+<!-- Use Case: Connection errors / Catalog and database lookup -->
+
+## トラブルシューティング
+
+### `dbt debug`で接続できない
+
+`host`と`port`が到達可能なFEのMySQLクエリポートを指していることを確認し、ユーザー名、パスワード、ネットワークポリシーを確認してください。クエリポートのデフォルトは`9030`です。`8030`は通常、FEのHTTPポートです。
+
+### Catalogまたはデータベースが見つからない
+
+v1.1.1では、プロファイルとソースの`database`の値はDoris Catalogを、`schema`はその中のデータベースを表します。Internal Catalogを使用する場合は`database`を省略します。古いプロジェクトでソースの`database`をDorisデータベースの指定に使用していた場合は、その値を`schema`に移してください。External Catalogが既に存在し、dbtの実行アカウントから参照できることを確認してください。
diff --git a/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/doris-kafka-connector.md b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/doris-kafka-connector.md
new file mode 100644
index 00000000000..c8cd31c2881
--- /dev/null
+++ b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/doris-kafka-connector.md
@@ -0,0 +1,684 @@
+---
+{
+ "title": "Doris Kafka Connector",
+ "language": "ja",
+ "description": "Doris Kafka Connector を使用して Kafka トピックのデータを Apache Doris にリアルタイムで書き込む方法を説明します。デプロイモード、設定項目、型マッピング、Debezium による同期、トラブルシューティングを扱います。",
+ "keywords": [
+ "Doris Kafka Connector",
+ "Kafka Connect",
+ "Kafka から Doris へのデータ連携",
+ "Apache Doris へのリアルタイム取り込み",
+ "Debezium から Doris へのデータ連携"
+ ]
+}
+---
+
+<!-- Knowledge type: Operations guide / Configuration reference -->
+<!-- Applicable scenarios: Real-time ingestion of Kafka data into Doris / Kafka Connect Sink Connector deployment and troubleshooting -->
+
+[Kafka Connect](https://docs.confluent.io/platform/current/connect/index.html) は、Apache Kafka とほかのシステム間でデータを移動するための、拡張性と信頼性の高いデータ連携ツールです。Doris コミュニティは、Kafka トピックのデータを Doris に書き込む [doris-kafka-connector](https://github.com/apache/doris-kafka-connector) プラグインを提供しています。
+
+## 適用シナリオ
+
+Kafka から Doris にデータを継続的に書き込むには、データソースと実行環境に合った設定を選択します。
+
+| 利用シナリオ | 使用する機能 | 参照セクション |
+| --- | --- | --- |
+| ローカルでの検証や開発テスト | Kafka Connect を Standalone モードで起動し、ローカル設定ファイルで Doris Sink Connector を作成する | [Standalone モードでのデプロイ](#standalone-mode-deployment) |
+| 本番環境やクラスターへのデプロイ | Kafka Connect を Distributed モードで起動し、REST API で Connector を管理する | [Distributed モードでのデプロイ](#distributed-mode-deployment) |
+| 通常の JSON データの同期 | `JsonConverter` または `StringConverter` で Kafka トピックを消費し、Doris テーブルに書き込む | [通常の JSON データの同期](#synchronizing-plain-json-data) |
+| Debezium が取得した CDC データの同期 | `converter.mode=debezium_ingestion` を設定し、必要に応じて削除の同期を有効にする | [Debezium が取得したデータの同期](#synchronizing-data-captured-by-debezium) |
+| Avro または Protobuf でシリアライズされたデータの同期 | Confluent Avro Converter または Protobuf Converter を使用し、Schema Registry のアドレスを設定する | [Avro でシリアライズされたデータの同期](#synchronizing-avro-serialized-data)、[Protobuf でシリアライズされたデータの同期](#synchronizing-protobuf-serialized-data) |
+| 書き込み前の Kafka メッセージの変換 | Kafka Connect SMT を使用してメッセージにフィールドを追加したり、日時形式を変換したりする | [Kafka Connect SMT によるデータ変換](#transforming-data-with-kafka-connect-smt) |
+| SSL 認証を使用する Kafka クラスターへのアクセス | Kafka Connect Worker と組み込みコンシューマーに SSL パラメータを設定する | [SSL 認証を使用する Kafka クラスターへのアクセス](#accessing-an-ssl-authenticated-kafka-cluster) |
+| 変換に失敗したレコードの記録 | Kafka Connect のデッドレターキューを設定する | [デッドレターキューの設定](#configuring-a-dead-letter-queue) |
+
+## バージョン情報
+
+| Connector のバージョン | Kafka のバージョン | Doris のバージョン | Java のバージョン |
+| --- | --- | --- | --- |
+| 1.0.0 | 2.4+ | 2.0+ | 8 |
+| 1.1.0 | 2.4+ | 2.0+ | 8 |
+| 24.0.0 | 2.4+ | 2.0+ | 8 |
+| 25.0.0 | 2.4+ | 2.0+ | 8 |
+| 26.0.0 | 2.4+ | 2.0+ | 8 |
+
+## Doris Kafka Connector の準備
+
+Doris Kafka Connector は、JAR パッケージをダウンロードするか、Maven の依存関係に追加して利用できます。
+
+### JAR パッケージのダウンロード
+
+[Doris のダウンロードページ](https://doris.apache.org/download)から doris-kafka-connector の JAR パッケージを取得します。Kafka Connect をデプロイするときに、JAR パッケージを `$KAFKA_HOME/plugins` ディレクトリに配置します。
+
+### Maven 依存関係の使用
+
+Maven プロジェクトに次の依存関係を追加します。
+
+```xml
+<dependency>
+ <groupId>org.apache.doris</groupId>
+ <artifactId>doris-kafka-connector</artifactId>
+ <version>25.0.0</version>
+</dependency>
+```
+
+## Standalone モードでのデプロイ {#standalone-mode-deployment}
+
+Standalone モードは、ローカルでの検証や開発テストに適しています。通常、本番環境には推奨されません。
+
+### 1. プラグインディレクトリの準備
+
+`plugins` ディレクトリを `$KAFKA_HOME` の下に作成し、ダウンロードした doris-kafka-connector の JAR パッケージを配置します。
+
+### 2. Kafka Connect Worker の設定
+
+`$KAFKA_HOME/config/connect-standalone.properties` を編集します。
+
+```properties
+# Modify the broker address
+bootstrap.servers=127.0.0.1:9092
+
+# Set this to the plugins directory you created
+# Note: use Kafka's direct path here. For example: plugin.path=/opt/kafka/plugins
+plugin.path=$KAFKA_HOME/plugins
+
+# It is recommended to increase Kafka's max.poll.interval.ms to more than 30 minutes (default is 5 minutes)
+# This avoids consumers being kicked out of the consumer group due to Stream Load consumption timeouts
+max.poll.interval.ms=1800000
+consumer.max.poll.interval.ms=1800000
+```
+
+### 3. Doris Sink Connector の設定
+
+`doris-connector-sink.properties` を `$KAFKA_HOME/config` ディレクトリに作成します。
+
+```properties
+name=test-doris-sink
+connector.class=org.apache.doris.kafka.connector.DorisSinkConnector
+topics=topic_test
+doris.topic2table.map=topic_test:test_kafka_tbl
+doris.urls=10.10.10.1
+doris.http.port=8030
+doris.query.port=9030
+doris.user=root
+doris.password=
+doris.database=test_db
+buffer.count.records=10000
+buffer.flush.time=120
+buffer.size.bytes=5000000
+enable.combine.flush=true
+key.converter=org.apache.kafka.connect.storage.StringConverter
+value.converter=org.apache.kafka.connect.json.JsonConverter
+value.converter.schemas.enable=false
+```
+
+### 4. Standalone モードの起動
+
+```shell
+$KAFKA_HOME/bin/connect-standalone.sh -daemon $KAFKA_HOME/config/connect-standalone.properties $KAFKA_HOME/config/doris-connector-sink.properties
+```
+
+## Distributed モードでのデプロイ {#distributed-mode-deployment}
+
+Distributed モードは、複数ノードの Kafka Connect クラスターに適しています。このモードでは、先に Kafka Connect Worker を起動し、REST API を使用して Connector を作成・管理します。
+
+### 1. プラグインディレクトリの準備
+
+`plugins` ディレクトリを `$KAFKA_HOME` の下に作成し、ダウンロードした doris-kafka-connector の JAR パッケージを配置します。
+
+### 2. Kafka Connect Worker の設定
+
+`$KAFKA_HOME/config/connect-distributed.properties` を編集します。
+
+```properties
+# Modify the broker address
+bootstrap.servers=127.0.0.1:9092
+
+# Modify group.id; it must be the same across the same cluster
+group.id=connect-cluster
+
+# Set this to the plugins directory you created
+# Note: use Kafka's direct path here. For example: plugin.path=/opt/kafka/plugins
+plugin.path=$KAFKA_HOME/plugins
+
+# It is recommended to increase Kafka's max.poll.interval.ms to more than 30 minutes (default is 5 minutes)
+# This avoids consumers being kicked out of the consumer group due to Stream Load consumption timeouts
+max.poll.interval.ms=1800000
+consumer.max.poll.interval.ms=1800000
+```
+
+### 3. Distributed モードの起動
+
+```shell
+$KAFKA_HOME/bin/connect-distributed.sh -daemon $KAFKA_HOME/config/connect-distributed.properties
+```
+
+:::note
+Kafka Connect の初回起動時には、Kafka クラスターに `config.storage.topic`、`offset.storage.topic`、`status.storage.topic` の三つのトピックが作成されます。これらは共有 Connector 設定、オフセットデータ、ステータス更新の記録に使用されます。詳しくは [Kafka Connect の使い方: はじめに](https://docs.confluent.io/platform/current/connect/userguide.html)を参照してください。
+:::
+
+### 4. Connector の作成
+
+```shell
+curl -i http://127.0.0.1:8083/connectors -H "Content-Type: application/json" -X POST -d '{
+ "name":"test-doris-sink-cluster",
+ "config":{
+ "connector.class":"org.apache.doris.kafka.connector.DorisSinkConnector",
+ "topics":"topic_test",
+ "doris.topic2table.map":"topic_test:test_kafka_tbl",
+ "doris.urls":"10.10.10.1",
+ "doris.user":"root",
+ "doris.password":"",
+ "doris.http.port":"8030",
+ "doris.query.port":"9030",
+ "doris.database":"test_db",
+ "enable.combine.flush":"true",
+ "buffer.count.records":"10000",
+ "buffer.flush.time":"120",
+ "buffer.size.bytes":"5000000",
+ "key.converter":"org.apache.kafka.connect.storage.StringConverter",
+ "value.converter":"org.apache.kafka.connect.json.JsonConverter",
+ "value.converter.schemas.enable":"false"
+ }
+}'
+```
+
+### 5. Connector の管理
+
+Kafka Connect REST API を使用して、Connector の状態確認、一時停止、再開、削除、再起動ができます。API の詳細は [Connect REST Interface](https://docs.confluent.io/platform/current/connect/references/restapi.html#kconnect-rest-interface)を参照してください。
+
+```shell
+# View Connector status
+curl -i http://127.0.0.1:8083/connectors/test-doris-sink-cluster/status -X GET
+
+# Delete the current Connector
+curl -i http://127.0.0.1:8083/connectors/test-doris-sink-cluster -X DELETE
+
+# Pause the current Connector
+curl -i http://127.0.0.1:8083/connectors/test-doris-sink-cluster/pause -X PUT
+
+# Resume the current Connector
+curl -i http://127.0.0.1:8083/connectors/test-doris-sink-cluster/resume -X PUT
+
+# Restart a task within the Connector
+curl -i http://127.0.0.1:8083/connectors/test-doris-sink-cluster/tasks/0/restart -X POST
+```
+
+## 本番環境向けの設定
+
+### SSL 認証を使用する Kafka クラスターへのアクセス {#accessing-an-ssl-authenticated-kafka-cluster}
+
+Kafka Connect から SSL 認証を使用する Kafka クラスターにアクセスする場合は、`client.truststore.jks` など、Kafka ブローカーの公開鍵を検証するための証明書ファイルが必要です。`connect-distributed.properties` に次の設定を追加します。
+
+```properties
+# Connect worker
+security.protocol=SSL
+ssl.truststore.location=/var/ssl/private/client.truststore.jks
+ssl.truststore.password=test1234
+
+# Embedded consumer for sink connectors
+consumer.security.protocol=SSL
+consumer.ssl.truststore.location=/var/ssl/private/client.truststore.jks
+consumer.ssl.truststore.password=test1234
+```
+
+Kafka Connect から SSL 認証を使用する Kafka クラスターへの接続について詳しくは、[Kafka Connect の設定](https://docs.confluent.io/platform/current/security/security_tutorial.html#configure-kafka-connect)を参照してください。
+
+### デッドレターキューの設定 {#configuring-a-dead-letter-queue}
+
+デフォルトでは、変換中にエラーが発生すると Connector は失敗します。次の設定を使用すると、これらのエラーを許容し、問題のレコードとともに各エラーおよび失敗した処理の詳細をデッドレターキューに書き込めます。
+
+```properties
+errors.tolerance=all
+errors.deadletterqueue.topic.name=test_error_topic
+errors.deadletterqueue.context.headers.enable=true
+errors.deadletterqueue.topic.replication.factor=1
+```
+
+## 設定項目
+
+以下の設定項目は Doris Sink Connector の作成に使用します。Kafka Connect Sink に共通するその他の設定項目については、[connect_configuring](https://kafka.apache.org/documentation/#connect_configuring)を参照してください。
+
+| キー | 選択肢 | デフォルト値 | 必須 | 説明 |
+| --- | --- | --- | --- | --- |
+| `name` | - | - | Y | Connect アプリケーションの名前。Kafka Connect 環境内で一意である必要があります。 |
+| `connector.class` | - | - | Y | `org.apache.doris.kafka.connector.DorisSinkConnector`。 |
+| `topics` | - | - | Y | 購読するトピックの一覧。複数のトピックは `topic1,topic2` のようにカンマで区切ります。 |
+| `doris.urls` | - | - | Y | Doris FE の接続先アドレス。複数のアドレスは `10.20.30.1,10.20.30.2,10.20.30.3` のようにカンマで区切ります。 |
+| `doris.http.port` | - | - | Y | Doris の HTTP プロトコルのポート。 |
+| `doris.query.port` | - | - | Y | Doris の MySQL プロトコルのポート。 |
+| `doris.user` | - | - | Y | Doris のユーザー名。 |
+| `doris.password` | - | - | Y | Doris のパスワード。 |
+| `doris.database` | - | - | Y | 書き込み先データベース。複数のデータベースに書き込む場合は空にできます。その場合、データベース名を `topic2table.map` で指定する必要があります。 |
+| `doris.topic2table.map` | - | - | Y | トピックとテーブルの対応付け。例: `topic1:tb1,topic2:tb2`。空の場合、デフォルトではトピック名が書き込み先テーブル名として使用されます。複数のデータベースを使用する場合の形式は `topic1:db1.tbl1,topic2:db2.tbl2` です。 |
+| `buffer.count.records` | - | 50000 | N | 一回の Stream Load で書き込むレコード数。 |
+| `buffer.flush.time` | - | 120 | N | バッファをフラッシュする間隔（秒）。デフォルトは 120 秒です。 |
+| `buffer.size.bytes` | - | 104857600(100MB) | N | 一回の Stream Load で書き込むデータサイズ。 |
+| `enable.combine.flush` | `true`,<br />`false` | false | N | すべてのパーティションのデータを 一回の書き込みにまとめるかどうか。デフォルトは `false` です。有効にした場合、保証できるのは `at_least_once` セマンティクスのみです。 |
+| `jmx` | - | true | N | JMX を使用して Connector 内部の監視メトリクスを取得するかどうか。[Doris-Connector-JMX](https://github.com/apache/doris-kafka-connector/blob/master/docs/en/Doris-Connector-JMX.md)を参照してください。 |
+| `label.prefix` | - | `${name}` | N | データ取り込み時の Stream Load ラベルのプレフィックス。デフォルトは Connector アプリケーション名です。 |
+| `auto.redirect` | - | true | N | Stream Load リクエストをリダイレクトするかどうか。有効にすると、FE を経由して書き込み先の BE に Stream Load がリダイレクトされ、BE の情報は表示されなくなります。 |
+| `sink.properties.*` | - | `'sink.properties.format':'json'`,<br />`'sink.properties.read_json_by_line':'true'` | N | Stream Load の取り込みパラメータ。たとえば列区切り文字は `'sink.properties.column_separator':','` で指定します。詳しくは [Stream Load マニュアル](../../data-operate/import/import-way/stream-load-manual.md)を参照してください。<br /><br />Group Commit を有効にする場合、たとえば `sync_mode` を有効にするには `"sink.properties.group_commit":"sync_mode"` を指定します。Group Commit では `off_mode`、`sync_mode`、`async_mode` の三モードをサポートします。詳しくは [Group Commit [...]
+| `delivery.guarantee` | `at_least_once`,<br />`exactly_once` | at_least_once | N | Kafka データの消費から Doris への取り込みまでのデータ整合性保証。`at_least_once` と `exactly_once` をサポートします。デフォルトは `at_least_once` です。`exactly_once` を保証するには Doris を 2.1.0 以降にアップグレードする必要があります。 |
+| `converter.mode` | `normal`,<br />`debezium_ingestion` | normal | N | Connector が Kafka データを消費するときに使用する、上流データ型の変換モード。`normal` は特別な型変換を行わずに Kafka データを通常どおり消費します。`debezium_ingestion` は、Debezium などの CDC（変更データキャプチャ）ツールで上流の Kafka データを収集した場合に、特別な型変換を行います。 |
+| `debezium.schema.evolution` | `none`,<br />`basic` | none | N | Debezium を使用して MySQL などの上流データベースからデータを収集する際、スキーマが変更された場合に追加されたフィールドを Doris に同期できます。`none` は上流データベースのスキーマ変更を Doris に同期しません。`basic` は上流データベースのデータ変更操作を同期します。列スキーマの変更は危険を伴い、Doris テーブルのスキーマから列が誤って削除されるおそれがあるため、現在は上流での列追加のみをサポートします。列名を変更した場合、古い列はそのまま残り、Connector は書き込み先テーブルに新しい列を追加して、名前を変更したデータをその列に書き込みます。 |
+| `enable.delete` | - | false | N | Debezium による同期で削除レコードを同期するかどうか。デフォルトは `false` です。Debezium を使用しない同期では、メッセージに削除マーカーを追加する必要があります。 |
+| `database.time_zone` | - | UTC | N | `converter.mode` を `normal` 以外に設定した場合、`datetime`、`date`、`timestamp` などの日時データ型に適用するタイムゾーン変換を指定します。デフォルトは UTC です。 |
+| `avro.topic2schema.filepath` | - | - | N | ローカルの Avro スキーマファイルを読み込んでトピック内の Avro ファイルの内容を解析し、Confluent Schema Registry への依存をなくします。この設定は `key.converter` または `value.converter` のプレフィックスとともに使用する必要があります。たとえば `avro-user` と `avro-product` トピックにローカルの Avro スキーマファイルを設定するには、`"value.converter.avro.topic2schema.filepath":"avro-user:file:///opt/avro_user.avsc, avro-product:file:///opt/avro_product.avsc"` を指定します。詳しくは [#32](https://github.com/apache/doris-kafka-connector/pull/32)を参照してください。 |
+| `record.tablename.field` | - | - | N | この項目を有効にすると、一つのトピックから複数の Doris テーブルにデータを流せます。設定の詳細は [#58](https://github.com/apache/doris-kafka-connector/pull/58)を参照してください。 |
+| `max.retries` | - | 10 | N | タスクが失敗するまでにエラーを再試行する最大回数。 |
+| `retry.interval.ms` | - | 6000 | N | エラー発生後、再試行するまでの待機時間（ミリ秒）。デフォルトは 6000 ミリ秒です。 |
+| `behavior.on.null.values` | `ignore`,<br />`fail` | ignore | N | `null` 値を持つレコードの処理方法。デフォルトではスキップします。 |
+
+## 型マッピング
+
+Doris Kafka Connector は、Kafka Connect のプリミティブ型または論理型を使用して列のデータ型を解析します。プリミティブ型は Kafka Connect の `Schema` で表される単純なデータ型です。論理型は通常、`Struct` を使用して複合型や日時型を表します。
+
+### Kafka のプリミティブ型
+
+| Kafka のプリミティブ型 | Doris の型 |
+| --- | --- |
+| INT8 | TINYINT |
+| INT16 | SMALLINT |
+| INT32 | INT |
+| INT64 | BIGINT |
+| FLOAT32 | FLOAT |
+| FLOAT64 | DOUBLE |
+| BOOLEAN | BOOLEAN |
+| STRING | STRING |
+| BYTES | STRING |
+
+### Kafka の論理型
+
+| Kafka の論理型 | Doris の型 |
+| --- | --- |
+| `org.apache.kafka.connect.data.Decimal` | DECIMAL |
+| `org.apache.kafka.connect.data.Date` | DATE |
+| `org.apache.kafka.connect.data.Time` | STRING |
+| `org.apache.kafka.connect.data.Timestamp` | DATETIME |
+
+### Debezium の論理型
+
+| Debezium の論理型 | Doris の型 |
+| --- | --- |
+| `io.debezium.time.Date` | DATE |
+| `io.debezium.time.Time` | String |
+| `io.debezium.time.MicroTime` | DATETIME |
+| `io.debezium.time.NanoTime` | DATETIME |
+| `io.debezium.time.ZonedTime` | DATETIME |
+| `io.debezium.time.Timestamp` | DATETIME |
+| `io.debezium.time.MicroTimestamp` | DATETIME |
+| `io.debezium.time.NanoTimestamp` | DATETIME |
+| `io.debezium.time.ZonedTimestamp` | DATETIME |
+| `io.debezium.data.VariableScaleDecimal` | DOUBLE |
+
+## データシナリオ別の Connector 設定
+
+### 通常の JSON データの同期 {#synchronizing-plain-json-data}
+
+このシナリオでは、Kafka トピック内の通常の JSON メッセージを Doris テーブルに書き込みます。
+
+1. Kafka のサンプルデータを確認します。
+
+ ```bash
+ kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic test-data-topic --from-beginning
+ {"user_id":1,"name":"Emily","age":25}
+ {"user_id":2,"name":"Benjamin","age":35}
+ {"user_id":3,"name":"Olivia","age":28}
+ {"user_id":4,"name":"Alexander","age":60}
+ {"user_id":5,"name":"Ava","age":17}
+ {"user_id":6,"name":"William","age":69}
+ {"user_id":7,"name":"Sophia","age":32}
+ {"user_id":8,"name":"James","age":64}
+ {"user_id":9,"name":"Emma","age":37}
+ {"user_id":10,"name":"Liam","age":64}
+ ```
+
+2. Doris に書き込み先テーブルを作成します。
+
+ ```sql
+ CREATE TABLE test_db.test_kafka_connector_tbl (
+ user_id BIGINT NOT NULL COMMENT "user id",
+ name VARCHAR(20) COMMENT "name",
+ age INT COMMENT "age"
+ )
+ DUPLICATE KEY(user_id)
+ DISTRIBUTED BY HASH(user_id) BUCKETS 12;
+ ```
+
+3. Kafka Connect をデプロイしたマシンで、`curl` を使用して取り込みタスクを送信します。
+
+ ```shell
+ curl -i http://127.0.0.1:8083/connectors -H "Content-Type: application/json" -X POST -d '{
+ "name":"test-doris-sink-cluster",
+ "config":{
+ "connector.class":"org.apache.doris.kafka.connector.DorisSinkConnector",
+ "tasks.max":"10",
+ "topics":"test-data-topic",
+ "doris.topic2table.map":"test-data-topic:test_kafka_connector_tbl",
+ "doris.urls":"10.10.10.1",
+ "doris.user":"root",
+ "doris.password":"",
+ "doris.http.port":"8030",
+ "doris.query.port":"9030",
+ "doris.database":"test_db",
+ "buffer.count.records":"10000",
+ "buffer.flush.time":"120",
+ "buffer.size.bytes":"5000000",
+ "enable.combine.flush":"true",
+ "key.converter":"org.apache.kafka.connect.storage.StringConverter",
+ "value.converter":"org.apache.kafka.connect.json.JsonConverter",
+ "value.converter.schemas.enable":"false"
+ }
+ }'
+ ```
+
+### Debezium が取得したデータの同期 {#synchronizing-data-captured-by-debezium}
+
+このシナリオでは、Debezium が取得した MySQL の CDC データを Kafka 経由で Doris に書き込みます。
+
+1. MySQL データベースには次のテーブルとデータがあるものとします。
+
+ ```sql
+ CREATE TABLE test.test_user (
+ user_id int NOT NULL,
+ name varchar(20),
+ age int,
+ PRIMARY KEY (user_id)
+ ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
+
+ INSERT INTO test.test_user VALUES (1, 'zhangsan', 20);
+ INSERT INTO test.test_user VALUES (2, 'lisi', 21);
+ INSERT INTO test.test_user VALUES (3, 'wangwu', 22);
+ ```
+
+2. Doris に書き込み先テーブルを作成します。
+
+ ```sql
+ CREATE TABLE test_db.test_user (
+ user_id BIGINT NOT NULL COMMENT "user id",
+ name VARCHAR(20) COMMENT "name",
+ age INT COMMENT "age"
+ )
+ UNIQUE KEY(user_id)
+ DISTRIBUTED BY HASH(user_id) BUCKETS 12;
+ ```
+
+3. MySQL 用の Debezium connector コンポーネントをデプロイします。手順の詳細は [Debezium connector for MySQL](https://debezium.io/documentation/reference/stable/connectors/mysql.html)を参照してください。
+
+4. doris-kafka-connector の取り込みタスクを作成します。Debezium が取得した MySQL テーブルのデータは `mysql_debezium.test.test_user` トピックにあるものとします。
+
+ ```shell
+ curl -i http://127.0.0.1:8083/connectors -H "Content-Type: application/json" -X POST -d '{
+ "name":"test-debezium-doris-sink",
+ "config":{
+ "connector.class":"org.apache.doris.kafka.connector.DorisSinkConnector",
+ "tasks.max":"10",
+ "topics":"mysql_debezium.test.test_user",
+ "doris.topic2table.map":"mysql_debezium.test.test_user:test_user",
+ "doris.urls":"10.10.10.1",
+ "doris.user":"root",
+ "doris.password":"",
+ "doris.http.port":"8030",
+ "doris.query.port":"9030",
+ "doris.database":"test_db",
+ "buffer.count.records":"10000",
+ "buffer.flush.time":"30",
+ "buffer.size.bytes":"5000000",
+ "enable.combine.flush":"true",
+ "converter.mode":"debezium_ingestion",
+ "enable.delete":"true",
+ "key.converter":"org.apache.kafka.connect.json.JsonConverter",
+ "value.converter":"org.apache.kafka.connect.json.JsonConverter"
+ }
+ }'
+ ```
+
+### Avro でシリアライズされたデータの同期 {#synchronizing-avro-serialized-data}
+
+このシナリオでは、Avro でシリアライズされた Kafka トピックを消費し、Confluent Avro Converter でデータを解析します。
+
+```shell
+curl -i http://127.0.0.1:8083/connectors -H "Content-Type: application/json" -X POST -d '{
+ "name":"doris-avro-test",
+ "config":{
+ "connector.class":"org.apache.doris.kafka.connector.DorisSinkConnector",
+ "topics":"avro_topic",
+ "tasks.max":"10",
+ "doris.topic2table.map":"avro_topic:avro_tab",
+ "doris.urls":"127.0.0.1",
+ "doris.user":"root",
+ "doris.password":"",
+ "doris.http.port":"8030",
+ "doris.query.port":"9030",
+ "doris.database":"test",
+ "buffer.count.records":"100000",
+ "buffer.flush.time":"120",
+ "buffer.size.bytes":"10000000",
+ "enable.combine.flush":"true",
+ "key.converter":"io.confluent.connect.avro.AvroConverter",
+ "key.converter.schema.registry.url":"http://127.0.0.1:8081",
+ "value.converter":"io.confluent.connect.avro.AvroConverter",
+ "value.converter.schema.registry.url":"http://127.0.0.1:8081"
+ }
+}'
+```
+
+### Protobuf でシリアライズされたデータの同期 {#synchronizing-protobuf-serialized-data}
+
+このシナリオでは、Protobuf でシリアライズされた Kafka トピックを消費し、Confluent Protobuf Converter でデータを解析します。
+
+```shell
+curl -i http://127.0.0.1:8083/connectors -H "Content-Type: application/json" -X POST -d '{
+ "name":"doris-protobuf-test",
+ "config":{
+ "connector.class":"org.apache.doris.kafka.connector.DorisSinkConnector",
+ "topics":"proto_topic",
+ "tasks.max":"10",
+ "doris.topic2table.map":"proto_topic:proto_tab",
+ "doris.urls":"127.0.0.1",
+ "doris.user":"root",
+ "doris.password":"",
+ "doris.http.port":"8030",
+ "doris.query.port":"9030",
+ "doris.database":"test",
+ "buffer.count.records":"100000",
+ "buffer.flush.time":"120",
+ "buffer.size.bytes":"10000000",
+ "enable.combine.flush":"true",
+ "key.converter":"io.confluent.connect.protobuf.ProtobufConverter",
+ "key.converter.schema.registry.url":"http://127.0.0.1:8081",
+ "value.converter":"io.confluent.connect.protobuf.ProtobufConverter",
+ "value.converter.schema.registry.url":"http://127.0.0.1:8081"
+ }
+}'
+```
+
+### Kafka Connect SMT によるデータ変換 {#transforming-data-with-kafka-connect-smt}
+
+このシナリオでは、Doris に書き込む前に個々の Kafka メッセージにフィールドを追加したり、形式を変換したりします。次の例では `InsertField` で静的フィールドを追加し、`TimestampConverter` で Bigint のタイムスタンプを日時文字列に変換します。
+
+元データの例:
+
+```json
+{
+ "registertime": 1513885135404,
+ "userid": "User_9",
+ "regionid": "Region_3",
+ "gender": "MALE"
+}
+```
+
+Connector を作成します。
+
+```shell
+curl -i http://127.0.0.1:8083/connectors -H "Content-Type: application/json" -X POST -d '{
+ "name":"insert_field_tranform",
+ "config":{
+ "connector.class":"org.apache.doris.kafka.connector.DorisSinkConnector",
+ "tasks.max":"1",
+ "topics":"users",
+ "doris.topic2table.map":"users:kf_users",
+ "buffer.count.records":"10000",
+ "buffer.flush.time":"10",
+ "buffer.size.bytes":"5000000",
+ "doris.urls":"127.0.0.1:8030",
+ "doris.user":"root",
+ "doris.password":"123456",
+ "doris.http.port":"8030",
+ "doris.query.port":"9030",
+ "doris.database":"testdb",
+ "key.converter":"org.apache.kafka.connect.storage.StringConverter",
+ "value.converter":"org.apache.kafka.connect.json.JsonConverter",
+ "value.converter.schemas.enable":"false",
+ "transforms":"InsertField,TimestampConverter",
+ "transforms.InsertField.type":"org.apache.kafka.connect.transforms.InsertField$Value",
+ "transforms.InsertField.static.field":"repo",
+ "transforms.InsertField.static.value":"Apache Doris",
+ "transforms.TimestampConverter.type":"org.apache.kafka.connect.transforms.TimestampConverter$Value",
+ "transforms.TimestampConverter.field":"registertime",
+ "transforms.TimestampConverter.format":"yyyy-MM-dd HH:mm:ss.SSS",
+ "transforms.TimestampConverter.target.type":"string"
+ }
+}'
+```
+
+SMT による処理後、サンプルデータは次のようになります。
+
+```json
+{
+ "userid": "User_9",
+ "regionid": "Region_3",
+ "gender": "MALE",
+ "repo": "Apache Doris",
+ "registertime": "2017-12-21 03:38:55.404"
+}
+```
+
+ここでは、`repo` は `InsertField` によって追加された静的フィールドで、`registertime` は `TimestampConverter` によって変換された日時文字列です。Kafka Connect の Single Message Transforms（SMT）のその他の例は、[SMT ドキュメント](https://docs.confluent.io/cloud/current/connectors/transforms/overview.html)を参照してください。
+
+## よくある質問
+
+### JSON データの読み取り時に `JsonConverter with schemas.enable requires "schema" and "payload" fields` が報告される
+
+**エラーメッセージ:**
+
+```shell
+Caused by: org.apache.kafka.connect.errors.DataException: JsonConverter with schemas.enable requires "schema" and "payload" fields and may not contain additional fields. If you are trying to deserialize plain JSON data, set schemas.enable=false in your converter configuration.
+ at org.apache.kafka.connect.json.JsonConverter.toConnectData(JsonConverter.java:337)
+ at org.apache.kafka.connect.storage.Converter.toConnectData(Converter.java:91)
+ at org.apache.kafka.connect.runtime.WorkerSinkTask.lambda$convertAndTransformRecord$4(WorkerSinkTask.java:536)
+ at org.apache.kafka.connect.runtime.errors.RetryWithToleranceOperator.execAndRetry(RetryWithToleranceOperator.java:180)
+ at org.apache.kafka.connect.runtime.errors.RetryWithToleranceOperator.execAndHandleError(RetryWithToleranceOperator.java:214)
+```
+
+**原因:**
+
+`org.apache.kafka.connect.json.JsonConverter` を使用する場合、データは `schema` フィールドと `payload` フィールドに一致する必要があります。
+
+**解決方法:**
+
+次のいずれかの方法を使用します。
+
+1. `org.apache.kafka.connect.json.JsonConverter` を `org.apache.kafka.connect.storage.StringConverter` に置き換えます。
+2. 対応する設定ファイルで `value.converter.schemas.enable` または `key.converter.schemas.enable` を `false` に設定します。
+ - Standalone モード: `config/connect-standalone.properties` を変更します。
+ - Distributed モード: `config/connect-distributed.properties` を変更します。
+
+### 消費のタイムアウトによりコンシューマーがコンシューマーグループから除外される
+
+**エラーメッセージ:**
+
+```shell
+org.apache.kafka.clients.consumer.CommitFailedException: Offset commit cannot be completed since the consumer is not part of an active group for auto partition assignment; it is likely that the consumer was kicked out of the group.
+ at org.apache.kafka.clients.consumer.internals.ConsumerCoordinator.sendOffsetCommitRequest(ConsumerCoordinator.java:1318)
+ at org.apache.kafka.clients.consumer.internals.ConsumerCoordinator.doCommitOffsetsAsync(ConsumerCoordinator.java:1127)
+ at org.apache.kafka.clients.consumer.internals.ConsumerCoordinator.commitOffsetsAsync(ConsumerCoordinator.java:1093)
+ at org.apache.kafka.clients.consumer.KafkaConsumer.commitAsync(KafkaConsumer.java:1590)
+ at org.apache.kafka.connect.runtime.WorkerSinkTask.doCommitAsync(WorkerSinkTask.java:361)
+ at org.apache.kafka.connect.runtime.WorkerSinkTask.doCommit(WorkerSinkTask.java:376)
+ at org.apache.kafka.connect.runtime.WorkerSinkTask.commitOffsets(WorkerSinkTask.java:467)
+ at org.apache.kafka.connect.runtime.WorkerSinkTask.commitOffsets(WorkerSinkTask.java:381)
+ at org.apache.kafka.connect.runtime.WorkerSinkTask.iteration(WorkerSinkTask.java:221)
+ at org.apache.kafka.connect.runtime.WorkerSinkTask.execute(WorkerSinkTask.java:206)
+ at org.apache.kafka.connect.runtime.WorkerTask.doRun(WorkerTask.java:204)
+ at org.apache.kafka.connect.runtime.WorkerTask.run(WorkerTask.java:259)
+ at org.apache.kafka.connect.runtime.isolation.Plugins.lambda$withClassLoader$1(Plugins.java:181)
+ at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
+ at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
+ at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
+ at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
+ at java.base/java.lang.Thread.run(Thread.java:833)
+```
+
+**解決方法:**
+
+利用シナリオに応じて Kafka の `max.poll.interval.ms` を増やします。デフォルト値は `300000` です。
+
+- Standalone モード: `max.poll.interval.ms` と `consumer.max.poll.interval.ms` を `config/connect-standalone.properties` に追加し、値を設定します。
+- Distributed モード: `max.poll.interval.ms` と `consumer.max.poll.interval.ms` を `config/connect-distributed.properties` に追加し、値を設定します。
+
+パラメータを調整した後、Kafka Connect を再起動します。
+
+### Doris Kafka Connector を 1.0.0 または 1.1.0 から 24.0.0 にアップグレードすると `cleanup.policy=compact` エラーが報告される
+
+**エラーメッセージ:**
+
+```shell
+org.apache.kafka.common.config.ConfigException: Topic 'connect-status' supplied via the 'status.storage.topic' property is required to have 'cleanup.policy=compact' to guarantee consistency and durability of connector and task statuses, but found the topic currently has 'cleanup.policy=delete'. Continuing would likely result in eventually losing connector and task statuses and problems restarting this Connect cluster in the future. Change the 'status.storage.topic' property in the Connec [...]
+ at org.apache.kafka.connect.util.TopicAdmin.verifyTopicCleanupPolicyOnlyCompact(TopicAdmin.java:581)
+ at org.apache.kafka.connect.storage.KafkaTopicBasedBackingStore.lambda$topicInitializer$0(KafkaTopicBasedBackingStore.java:47)
+ at org.apache.kafka.connect.util.KafkaBasedLog.start(KafkaBasedLog.java:247)
+ at org.apache.kafka.connect.util.KafkaBasedLog.start(KafkaBasedLog.java:231)
+ at org.apache.kafka.connect.storage.KafkaStatusBackingStore.start(KafkaStatusBackingStore.java:228)
+ at org.apache.kafka.connect.runtime.AbstractHerder.startServices(AbstractHerder.java:164)
+ at org.apache.kafka.connect.runtime.distributed.DistributedHerder.run
+```
+
+**解決方法:**
+
+`connect-configs` と `connect-status` トピックのクリーンアップポリシーを `compact` に変更します。
+
+```shell
+$KAFKA_HOME/bin/kafka-configs.sh --alter --entity-type topics --entity-name connect-configs --add-config cleanup.policy=compact --bootstrap-server 127.0.0.1:9092
+$KAFKA_HOME/bin/kafka-configs.sh --alter --entity-type topics --entity-name connect-status --add-config cleanup.policy=compact --bootstrap-server 127.0.0.1:9092
+```
+
+### `debezium_ingestion` 変換モードでスキーマ変更に失敗する
+
+**エラーメッセージ:**
+
+```shell
+[2025-01-07 14:26:20,474] WARN [doris-normal_test_sink-connector|task-0] Table 'test_sink' cannot be altered because schema evolution is disabled. (org.apache.doris.kafka.connector.converter.RecordService:183)
+[2025-01-07 14:26:20,475] ERROR [doris-normal_test_sink-connector|task-0] WorkerSinkTask{id=doris-normal_test_sink-connector-0} Task threw an uncaught and unrecoverable exception. Task is being killed and will not recover until manually restarted. Error: Cannot alter table org.apache.doris.kafka.connector.model.TableDescriptor@67cd8027 because schema evolution is disabled (org.apache.kafka.connect.runtime.WorkerSinkTask:612)
+org.apache.doris.kafka.connector.exception.SchemaChangeException: Cannot alter table org.apache.doris.kafka.connector.model.TableDescriptor@67cd8027 because schema evolution is disabled
+ at org.apache.doris.kafka.connector.converter.RecordService.alterTableIfNeeded(RecordService.java:186)
+ at org.apache.doris.kafka.connector.converter.RecordService.checkAndApplyTableChangesIfNeeded(RecordService.java:150)
+ at org.apache.doris.kafka.connector.converter.RecordService.processStructRecord(RecordService.java:100)
+ at org.apache.doris.kafka.connector.converter.RecordService.getProcessedRecord(RecordService.java:305)
+ at org.apache.doris.kafka.connector.writer.DorisWriter.putBuffer(DorisWriter.java:155)
+ at org.apache.doris.kafka.connector.writer.DorisWriter.insertRecord(DorisWriter.java:124)
+ at org.apache.doris.kafka.connector.writer.StreamLoadWriter.insert(StreamLoadWriter.java:151)
+ at org.apache.doris.kafka.connector.service.DorisDefaultSinkService.insert(DorisDefaultSinkService.java:154)
+ at org.apache.doris.kafka.connector.service.DorisDefaultSinkService.insert(DorisDefaultSinkService.java:135)
+ at org.apache.doris.kafka.connector.DorisSinkTask.put(DorisSinkTask.java:97)
+ at org.apache.kafka.connect.runtime.WorkerSinkTask.deliverMessages(WorkerSinkTask.java:583)
+ at org.apache.kafka.connect.runtime.WorkerSinkTask.poll(WorkerSinkTask.java:336)
+ at org.apache.kafka.connect.runtime.WorkerSinkTask.iteration(WorkerSinkTask.java:237)
+ at org.apache.kafka.connect.runtime.WorkerSinkTask.execute(WorkerSinkTask.java:206)
+ at org.apache.kafka.connect.runtime.WorkerTask.doRun(WorkerTask.java:202)
+ at org.apache.kafka.connect.runtime.WorkerTask.run(WorkerTask.java:257)
+ at org.apache.kafka.connect.runtime.isolation.Plugins.lambda$withClassLoader$1(Plugins.java:177)
+ at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
+ at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
+ at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
+ at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
+ at java.base/java.lang.Thread.run(Thread.java:829)
+```
+
+**解決方法:**
+
+`debezium_ingestion` 変換モードでは、デフォルトでスキーマ変更が無効になっています。スキーマ変更を有効にするには `debezium.schema.evolution=basic` を設定します。
+
+スキーマ変更を有効にしても、変更した列だけが Doris テーブルに存在することは厳密には保証されません。具体的な制限事項については、`debezium.schema.evolution` パラメータの説明を参照してください。上流と下流で列を一つだけに保つには、先に Doris テーブルに変更後の列を手動で追加してから Connector タスクを再起動することを推奨します。Connector は最後に未消費だった `offset` から消費を続け、データの整合性を維持します。
diff --git a/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/doris-streamloader.md b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/doris-streamloader.md
new file mode 100644
index 00000000000..9725f138404
--- /dev/null
+++ b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/doris-streamloader.md
@@ -0,0 +1,297 @@
+---
+{
+ "title": "Doris Streamloader",
+ "language": "ja",
+ "description": "Doris Streamloader は Apache Doris 公式のデータ取り込み用クライアントツールです。並列処理、複数ファイルの取り込み、途中からの再開、自動リトライに対応し、大量データの一括ロードに適しています。"
+}
+---
+
+[Doris Streamloader](https://github.com/apache/doris-streamloader) は、Apache Doris データベースにデータを取り込むための専用クライアントツールです。`curl` を直接使用して単一の処理で取り込む方法と比べて、複数の処理を並列に実行でき、大量データのロードにかかる時間を大幅に短縮できます。
+
+## 主な機能
+
+| 機能 | 説明 |
+|---|---|
+| 並列取り込み | 複数のワーカーで Stream Load を並列実行します。並列度は `workers` パラメータで設定します |
+| 複数ファイルの取り込み | 単一のタスクで複数のファイルやディレクトリを取り込みます。ワイルドカードによる指定に対応し、ディレクトリ内のすべてのファイルを再帰的に探索します |
+| 途中からの再開 | 取り込み中に一部が失敗した場合、失敗した箇所から再開できます |
+| 自動リトライ | 取り込みに失敗しても手動でリトライする必要はありません。デフォルトの回数まで自動的にリトライし、それでも失敗した場合は手動リトライ用のコマンドを表示します |
+
+## ユースケース
+
+- 大量データ（GB～TB 規模）を Doris に一括ロードする場合
+- 複数のファイルやディレクトリをまとめて取り込む場合
+- 取り込みの遅延が重要で、並列処理によってスループットを高める必要がある場合
+- 途中からの再開や障害からの自動復旧が必要な、安定した取り込み処理を構築する場合
+
+---
+
+## ダウンロードとインストール
+
+| リソース | アドレス |
+|---|---|
+| ソースコード | [https://github.com/apache/doris-streamloader](https://github.com/apache/doris-streamloader) |
+| バイナリのダウンロード | [https://doris.apache.org/download](https://doris.apache.org/download) |
+
+:::note
+ダウンロードするファイルは実行可能なバイナリです。追加のコンパイルやインストールは不要です。
+:::
+
+---
+
+## 使用方法
+
+### 基本的なコマンド形式
+
+```shell
+doris-streamloader \
+ --source_file={FILE_LIST} \
+ --url={FE_OR_BE_SERVER_URL}:{PORT} \
+ --header={STREAMLOAD_HEADER} \
+ --db={TARGET_DATABASE} \
+ --table={TARGET_TABLE}
+```
+
+### 必須パラメータ
+
+| パラメータ | 説明 |
+|---|---|
+| `--source_file` | 取り込むデータファイルの一覧。単一ファイル、ディレクトリ、ワイルドカード、カンマ区切りのリストに対応します |
+| `--url` | Doris FE または BE のサービスアドレス。形式は `http://host:port` です |
+| `--header` | Stream Load のヘッダーパラメータ。複数のパラメータは `?` で区切ります |
+| `--db` | 取り込み先のデータベース名 |
+| `--table` | 取り込み先のテーブル名 |
+
+### `source_file` で指定できる形式
+
+`--source_file` パラメータは次の五つの形式に対応しています。用途に応じて選択できます。
+
+#### 1. 単一ファイル
+
+たとえば、単一ファイル `file.csv` を取り込む場合：
+
+```shell
+doris-streamloader --source_file="file.csv" --url="http://localhost:8330" --header="column_separator:|?columns:col1,col2" --db="testdb" --table="testtbl"
+```
+
+#### 2. 単一ディレクトリ
+
+たとえば、ディレクトリ `dir` を取り込む場合：
+
+```shell
+doris-streamloader --source_file="dir" --url="http://localhost:8330" --header="column_separator:|?columns:col1,col2" --db="testdb" --table="testtbl"
+```
+
+#### 3. ワイルドカードを含むファイル名（引用符で囲む必要があります）
+
+たとえば、`file0.csv`、`file1.csv`、`file2.csv` を取り込む場合：
+
+```shell
+doris-streamloader --source_file="file*" --url="http://localhost:8330" --header="column_separator:|?columns:col1,col2" --db="testdb" --table="testtbl"
+```
+
+#### 4. カンマ区切りのファイル名リスト
+
+たとえば、`file0.csv`、`file1.csv`、`file2.csv` を取り込む場合：
+
+```shell
+doris-streamloader --source_file="file0.csv,file1.csv,file2.csv" --url="http://localhost:8330" --header="column_separator:|?columns:col1,col2" --db="testdb" --table="testtbl"
+```
+
+#### 5. カンマ区切りのディレクトリリスト
+
+たとえば、`dir1`、`dir2`、`dir3` を取り込む場合：
+
+```shell
+doris-streamloader --source_file="dir1,dir2,dir3" --url="http://localhost:8330" --header="column_separator:|?columns:col1,col2" --db="testdb" --table="testtbl"
+```
+
+### ヘッダーパラメータ
+
+`--header` には Stream Load のすべてのパラメータを指定できます。複数のパラメータは `?` で区切ります。
+
+例：
+
+```shell
+doris-streamloader --source_file="data.csv" --url="http://localhost:8330" --header="column_separator:|?columns:col1,col2" --db="testdb" --table="testtbl"
+```
+
+---
+
+## オプションパラメータ
+
+上記の必須パラメータに加え、取り込み動作を細かく制御するためのオプションパラメータがあります。以下の表では、機能別にまとめています。
+
+### 認証と転送
+
+| パラメータ | 説明 | デフォルト | 推奨設定 |
+|---|---|---|---|
+| `--u` | データベースのユーザー名 | `root` | —— |
+| `--p` | データベースユーザーのパスワード | 空文字列 | —— |
+| `--compress` | HTTP 転送時にデータを圧縮するかどうか | `false` | 通常はデフォルトのままにします。圧縮を有効にすると、圧縮と展開のためにツールと Doris BE の両方で CPU 負荷が増加します。データソース側のマシンのネットワーク帯域幅がボトルネックの場合にのみ有効にしてください |
+| `--timeout` | Doris に送信する HTTP リクエストのタイムアウト（秒） | `60*60*10` | デフォルトのままにします |
+
+### バッチ処理と並列度
+
+| パラメータ | 説明 | デフォルト | 推奨設定 |
+|---|---|---|---|
+| `--batch` | ファイルをバッチ単位で読み取り、送信する際の粒度（行数） | `4096` | デフォルトのままにします |
+| `--batch_byte` | ファイルをバッチ単位で読み取り、送信する際の粒度（バイト数） | `943718400` (900 MB) | デフォルトのままにします |
+| `--workers` | 取り込みの並列度 | `0` | `0` に設定すると自動モードになり、取り込むデータのサイズ、ディスクのスループット、Stream Load の取り込み速度に基づいて値が計算されます。手動での設定も可能です。高性能なクラスタでは適宜増やせますが、**10 以下を推奨します**。取り込み時のメモリ使用量が多すぎる場合（Memtracker または Exceed ログで確認できます）は、適宜減らしてください |
+| `--disk_throughput` | ディスクのスループット（MB/s） | `800` | 通常はデフォルトのままにします。この値は `--workers` の自動計算に使用されます。適切な `workers` 数を計算させたい場合は、実際のディスクスループットに合わせて設定できます |
+| `--streamload_throughput` | Stream Load の実際の取り込みスループット（MB/s） | `100` | 通常はデフォルトのままにします。この値は `--workers` の自動計算に使用されます。デフォルト値は日次の性能テスト環境に基づいています。適切な `workers` 数を計算させたい場合は、測定したスループットを次の式で求めて設定できます：`(LoadBytes*1000) / (LoadTimeMs*1024*1024)` |
+| `--max_byte_per_task` | 取り込みタスクあたりのデータ量の上限。超過分は新しいタスクに分割されます | `107374182400` (100 GB) | 取り込みで生成されるバージョン数を減らすため、大きめの値を推奨します。ただし、`body exceed max size` エラーが発生し、BE の再起動が必要な `streaming_load_max_mb` の変更を避けたい場合や、`-238 TOO MANY SEGMENT` が発生した場合は、一時的に値を下げられます |
+
+### データ検証とログ
+
+| パラメータ | 説明 | デフォルト | 推奨設定 |
+|---|---|---|---|
+| `--check_utf8` | 取り込むデータのエンコーディングをチェックするかどうか。`false` はチェックを省略して元のデータを取り込み、`true` は UTF-8 以外の文字を `�` に置き換えます | `true` | デフォルトのままにします |
+| `--debug` | デバッグログを出力するかどうか | `false` | デフォルトのままにします |
+| `--log_filename` | ログの保存先 | `""` | デフォルトではログがコンソールに出力されます。ファイルに出力するには、たとえば `--log_filename="/var/log"` のようにパスを指定します |
+
+### 失敗時のリトライ
+
+| パラメータ | 説明 | デフォルト | 推奨設定 |
+|---|---|---|---|
+| `--auto_retry` | 自動的にリトライするワーカー番号とタスク番号のリスト | 空文字列 | 取り込みに失敗した場合にのみ使用します。通常の取り込み時に設定する必要はありません。失敗時には具体的なパラメータ値が表示されるため、それをコピーして実行してください。たとえば、`--auto_retry="1,1,2,1"` は、最初のワーカーの最初のタスクと、二番目のワーカーの最初のタスクをリトライすることを意味します |
+| `--auto_retry_times` | 自動リトライの回数 | `3` | デフォルトのままにします。リトライを無効にするには `0` に設定します |
+| `--auto_retry_interval` | 自動リトライの間隔（秒） | `60` | デフォルトのままにします。Doris の停止が原因で失敗する場合は、実際の再起動時間に合わせて設定します |
+
+---
+
+## 結果
+
+取り込みの成否にかかわらず、ツールは処理の終了時に最終結果を表示します。
+
+### 結果のフィールド
+
+| フィールド | 説明 |
+|---|---|
+| `Status` | 取り込みの状態。`Success` は成功、`Failed` は失敗を意味します |
+| `TotalRows` | 取り込み対象ファイルの総行数 |
+| `FailLoadRows` | 取り込む予定だったものの、取り込まれなかった行数 |
+| `LoadedRows` | Doris に実際に取り込まれた行数 |
+| `FilteredRows` | 取り込み時に Doris によってフィルタリングされた行数 |
+| `UnselectedRows` | 取り込み時に Doris によって無視された行数 |
+| `LoadBytes` | 実際に取り込まれたバイト数 |
+| `LoadTimeMs` | 実際の取り込み時間（ミリ秒） |
+| `LoadFiles` | 実際に取り込まれたファイルの一覧 |
+
+### 成功例
+
+取り込みに成功すると、次のように出力されます：
+
+```Go
+Load Result: {
+ "Status": "Success",
+ "TotalRows": 120,
+ "FailLoadRows": 0,
+ "LoadedRows": 120,
+ "FilteredRows": 0,
+ "UnselectedRows": 0,
+ "LoadBytes": 40632,
+ "LoadTimeMs": 971,
+ "LoadFiles": [
+ "basic.csv",
+ "basic_data1.csv",
+ "basic_data2.csv",
+ "dir1/basic_data.csv",
+ "dir1/basic_data.csv.1",
+ "dir1/basic_data1.csv"
+ ]
+}
+```
+
+### 失敗例
+
+一部のデータを取り込めなかった場合、ツールはまずリトライ用のコマンドを表示します：
+
+```Go
+load has some error, and auto retry failed, you can retry by :
+./doris-streamloader --source_file /mnt/disk1/laihui/doris/tools/tpch-tools/bin/tpch-data/lineitem.tbl.1 --url="http://127.0.0.1:8239" --header="column_separator:|?columns: l_orderkey, l_partkey, l_suppkey, l_linenumber, l_quantity, l_extendedprice, l_discount, l_tax, l_returnflag,l_linestatus, l_shipdate,l_commitdate,l_receiptdate,l_shipinstruct,l_shipmode,l_comment,temp" --db="db" --table="lineitem1" -u root -p "" --compress=false --timeout=36000 --workers=3 --batch=4096 --batch_byte= [...]
+```
+
+このコマンドをコピーして実行すると、手動でリトライできます。`auto_retry` の意味は上記のパラメータの項目で説明しています。その後、失敗結果が表示されます：
+
+```Go
+Load Result: {
+ "Status": "Failed",
+ "TotalRows": 1,
+ "FailLoadRows": 1,
+ "LoadedRows": 0,
+ "FilteredRows": 0,
+ "UnselectedRows": 0,
+ "LoadBytes": 0,
+ "LoadTimeMs": 104,
+ "LoadFiles": [
+ "/mnt/disk1/laihui/doris/tools/tpch-tools/bin/tpch-data/lineitem.tbl.1"
+ ]
+}
+```
+
+---
+
+## ベストプラクティス
+
+### 推奨パラメータ
+
+1. **必須パラメータ**：次のパラメータを設定する必要があります：
+
+ ```text
+ --source_file=FILE_LIST
+ --url=FE_OR_BE_SERVER_URL_WITH_PORT
+ --header=STREAMLOAD_HEADER
+ --db=TARGET_DATABASE
+ --table=TARGET_TABLE
+ ```
+
+ **複数のファイルを取り込む場合は、`source_file` を使用してください。**
+
+2. **`workers`**：デフォルト値は `0` で、自動モードになります（ツールが取り込みサイズ、`disk_throughput`、`streamload_throughput` から値を計算し、通常は 1、2、4、8 のいずれかになります）。手動で設定することもできます。高性能なクラスタでは増やせますが、**10 以下を推奨します**。**手動設定でよく使われる値は `8` です**。
+
+3. **`max_byte_per_task`**：値を大きくすると取り込みで生成されるバージョン数が減ります。ただし、`body exceed max size` エラーが発生し、BE の再起動が必要な `streaming_load_max_mb` の変更を避けたい場合や、`-238 TOO MANY SEGMENT` エラーが発生した場合は、この値を一時的に下げられます。**通常はデフォルト値を使用できます。**
+
+4. **バージョン数に影響する二つの主要パラメータ**：
+
+ | パラメータ | 影響 | 推奨設定 |
+ |---|---|---|
+ | `workers` | ワーカー数を増やすと、バージョン数と並列度が増えます | 通常は `8` を使用します |
+ | `max_byte_per_task` | 値を大きくすると各バージョンのデータ量が増えてバージョン数が減りますが、大きすぎると `-238 TOO MANY SEGMENT` が発生する可能性があります | 通常はデフォルト値を使用します |
+
+### 推奨コマンド
+
+ほとんどの場合、必須パラメータと `workers` を `8` に設定すれば十分です：
+
+```shell
+./doris-streamloader \
+ --source_file="demo.csv,demoFile*.csv,demoDir" \
+ --url="http://127.0.0.1:8030" \
+ --header="column_separator:," \
+ --db="demo" \
+ --table="test_load" \
+ --u="root" \
+ --workers=8
+```
+
+---
+
+## FAQ
+
+### 1. 取り込み中に一部のサブタスクが失敗した場合はどうすればよいですか？
+
+ツールは自動的にリトライします。それでも失敗した場合は、手動リトライ用のコマンドが表示されます。そのコマンドをコピーして実行してください。テーブルを削除して再度取り込む必要はありません。
+
+### 2. 単一の取り込みが BE のデフォルトの `streaming_load_max_mb` 閾値を超える場合はどうすればよいですか？
+
+ツールの取り込みあたりのデフォルトの上限は 100 GB で、BE の `streaming_load_max_mb` 閾値を超える可能性があります。BE の再起動を避けるには、`--max_byte_per_task` パラメータを小さくしてください。
+
+`streaming_load_max_mb` の値を確認するには：
+
+```shell
+curl "http://127.0.0.1:8040/api/show_config"
+```
+
+### 3. `-238 TOO MANY SEGMENT` エラーが発生した場合はどうすればよいですか？
+
+`--max_byte_per_task` パラメータを小さくすると、この問題を緩和できます。
diff --git a/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/finebi.md b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/finebi.md
new file mode 100644
index 00000000000..88fc5c3590a
--- /dev/null
+++ b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/finebi.md
@@ -0,0 +1,106 @@
+---
+{
+ "title": "FineBI",
+ "language": "ja",
+ "description": "MySQL プロトコルを使用して FineBI を Apache Doris に接続し、データモデリング、テーブルのインポート、可視化分析までの設定手順を説明します。"
+}
+---
+
+<!-- Knowledge type: Operation steps -->
+<!-- Applicable scenarios: BI tool integration / Visualization analysis -->
+
+FineBI は、データ処理、アドホック分析、多次元ダッシュボードなどの機能を備えたビジネスインテリジェンス製品です。多様なデータソースへの接続と、複数のビューを使ったテーブル分析の管理に対応しており、Apache Doris の内部データと外部データの両方を使用したモデリングと可視化を円滑に行えます。
+
+このドキュメントでは、FineBI から Apache Doris のデータソースに接続し、接続設定からデータモデリングまでを行う手順を説明します。
+
+## 適用シナリオ {#applicable-scenarios}
+
+| シナリオ | 説明 |
+| --- | --- |
+| BI レポート分析 | Doris のビジネスデータを基にダッシュボードやレポートを作成する |
+| アドホックな多次元分析 | FineBI の多次元分析機能を使用して Doris のデータを探索する |
+| 内部データと外部データのモデリング | Doris の内部テーブルと外部テーブルを FineBI にまとめて取り込み、モデリングに使用する |
+
+## 前提条件 {#prerequisites}
+
+- FineBI 5.0 以降がインストールされていること。ダウンロード先: [https://www.finebi.com/](https://www.finebi.com/)
+- Apache Doris クラスターがデプロイ済みで、次の接続情報が分かっていること:
+ - FE ホストの IP アドレス
+ - FE のクエリポート（デフォルトは `9030`）
+ - アクセス権限を持つユーザー名とパスワード
+ - 接続先のデータベース名
+
+## 操作手順 {#procedure}
+
+### ステップ 1: FineBI にログインする {#step-1-log-in-to-finebi}
+
+1. FineBI のログインアカウントを作成し、そのアカウントでログインします。
+
+ 
+
+2. FineBI の情報リポジトリとして内蔵データベースを選択します。外部データベースを使用する場合は、公式ドキュメントを参照してください: [https://help.fanruan.com/finebi/doc-view-437.html](https://help.fanruan.com/finebi/doc-view-437.html)
+
+ :::info 注記
+ FanRuan BI の情報リポジトリには、内蔵データベースを選択することを推奨します。ここで選択するデータベースの種類は、クエリ分析の対象となるデータベースではありません。モデルやダッシュボードなど、FineBI のメタデータを保存・管理するためのデータベースです。FineBI は、このデータベースに対して作成、読み取り、更新、削除の操作を行う必要があります。
+ :::
+
+ 
+
+### ステップ 2: Doris のデータ接続を作成する {#step-2-create-a-doris-data-connection}
+
+1. **Management System**（管理システム）に移動し、**Data Connection**（データ接続）の下にある **Database Connection**（データベース接続）を選択して、新しいデータベース接続を作成します。
+
+ 
+
+2. データベース接続の種類を選択する画面で **MySQL** を選択します。
+
+ 
+
+3. Doris データベースへの接続情報を入力します。各項目は次のとおりです。
+
+ | パラメータ | 説明 |
+ | --- | --- |
+ | Username（ユーザー名） | Doris クラスターへのログインに使用するユーザー名。例: `admin` |
+ | Password（パスワード） | Doris クラスターへのログインに使用するパスワード |
+ | Host（ホスト） | Doris クラスターの FE ホストの IP アドレス |
+ | Port（ポート） | Doris クラスターの FE クエリポート。例: `9030` |
+ | Coding（文字エンコーディング） | Doris クラスターで使用する文字エンコーディング |
+ | Name Database（データベース名） | Doris クラスター内の接続先データベース |
+
+ 
+
+4. **Test Connection**（接続テスト）をクリックします。接続情報が正しく入力されていれば、接続成功のメッセージが表示されます。
+
+ 
+
+### ステップ 3: データモデルを作成する {#step-3-create-a-data-model}
+
+1. **Public Data**（公開データ）で新しいデータセットを作成します。Doris のデータセットを追加する際は、**Database Table**（データベーステーブル）を選択します。
+
+ 
+
+2. 作成したデータベース接続から、インポートするテーブルを選択します。
+
+ 
+
+3. テーブルをインポートした後、インポートした各テーブルをリフレッシュする必要があります。リフレッシュ後、分析トピックでそのテーブルをデータ分析に使用できるようになります。
+
+ 
+
+4. インポートした公開データを分析トピックに追加すると、業務要件に応じてダッシュボードの分析と設定を行えます。
+
+ 
+
+## よくある質問 {#faq}
+
+**Q: 接続テストに失敗した場合は、どのように調査すればよいですか？**
+
+次の項目を順番に確認してください。
+
+- Doris の FE ノードの IP アドレスとクエリポート（デフォルトは `9030`）に、FineBI を実行しているホストから到達できること。
+- ログインユーザーに接続先データベースへのアクセス権限があること。
+- 接続の種類が別のデータベースではなく、MySQL に設定されていること。
+
+**Q: テーブルをインポートしても、分析トピックで分析できないのはなぜですか？**
+
+**Public Data**（公開データ）で、インポートした各テーブルをリフレッシュする必要があります。リフレッシュが完了すると、そのテーブルを分析トピックで使用できます。
diff --git a/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/flink-doris-connector.md b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/flink-doris-connector.md
new file mode 100644
index 00000000000..1ef0339e919
--- /dev/null
+++ b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/flink-doris-connector.md
@@ -0,0 +1,1136 @@
+---
+{
+ "title": "Flink Doris Connector",
+ "language": "ja",
+ "description": "Flink Doris Connector を使用して Doris データを読み書きし、Lookup Join でディメンションテーブルを結合し、CDC を介して MySQL、Oracle、PostgreSQL などのデータベース全体を同期します。"
+}
+---
+
+# Flink Doris Connector
+
+[Flink Doris Connector](https://github.com/apache/doris-flink-connector) は、Flink を介して Doris クラスターのデータを読み書きします。また、[Flink CDC](https://nightlies.apache.org/flink/flink-cdc-docs-release-3.2/docs/connectors/flink-sources/overview/) と連携し、MySQL などの上流データベース全体を Doris に同期できます。
+
+主な機能は次のとおりです。
+
+- **Doris データの読み取り**: BE からの並列読み取りにより、読み取り効率を高めます。
+- **Doris データの書き込み**: Flink 内でデータをバッチ化し、Stream Load で一括取り込みします。
+- **Lookup Join によるディメンションテーブル結合**: バッチ処理と非同期クエリによって結合を高速化します。
+- **データベース全体の同期**: Flink CDC を使用して MySQL、Oracle、PostgreSQL などのデータベース全体を同期します。テーブルの自動作成と DDL の同期にも対応します。
+
+## バージョン対応表
+
+| Connector のバージョン | Flink のバージョン | Doris のバージョン | Java のバージョン | Scala のバージョン |
+| ----------------- | --------------------- | ------------- | -------------- | ------------- |
+| 1.0.3 | 1.11,1.12,1.13,1.14 | 0.15+ | 8 | 2.11,2.12 |
+| 1.1.1 | 1.14 | 1.0+ | 8 | 2.11,2.12 |
+| 1.2.1 | 1.15 | 1.0+ | 8 | - |
+| 1.3.0 | 1.16 | 1.0+ | 8 | - |
+| 1.4.0 | 1.15 - 1.17 | 1.0+ | 8 | - |
+| 1.5.2 | 1.15 - 1.18 | 1.0+ | 8 | - |
+| 1.6.1 | 1.15 - 1.19 | 1.0+ | 8 | - |
+| 24.0.1 | 1.15 - 1.20 | 1.0+ | 8 | - |
+| 24.1.0 | 1.15 - 1.20 | 1.0+ | 8 | - |
+| 25.0.0 | 1.15 - 1.20 | 1.0+ | 8 | - |
+| 25.1.0 | 1.15 - 1.20 | 1.0+ | 8 | - |
+| 26.0.0 | 1.15 - 1.20,2.0 - 2.2 | 1.0+ | 8(1.x),17(2.x) | - |
+| 26.1.1 | 1.15 - 1.20,2.0 - 2.2 | 1.0+ | 8(1.x),17(2.x) | - |
+
+## インストール {#installation}
+
+Jar パッケージと Maven 依存関係のどちらでも導入できます。
+
+### Jar パッケージを使用する方法
+
+対応するバージョンの Flink Doris Connector の Jar パッケージを [Doris ダウンロードページ](https://doris.apache.org/download#doris-ecosystem) からダウンロードし、Flink の `classpath` にコピーします。
+
+- **Standalone モード**: Jar ファイルを `lib/` ディレクトリに配置します。
+- **Yarn クラスターモード**: Jar ファイルを事前デプロイ用パッケージに配置します。
+
+### Maven 依存関係を使用する方法
+
+プロジェクトの `pom.xml` に次の依存関係を追加します。
+
+```xml
+<dependency>
+ <groupId>org.apache.doris</groupId>
+ <artifactId>flink-doris-connector-${flink.version}</artifactId>
+ <version>${connector.version}</version>
+</dependency>
+```
+
+例:
+
+```xml
+<dependency>
+ <groupId>org.apache.doris</groupId>
+ <artifactId>flink-doris-connector-1.16</artifactId>
+ <version>25.1.0</version>
+</dependency>
+```
+
+## 動作の仕組み
+
+### 読み取りの仕組み
+
+
+
+データ読み取り時の性能は Flink JDBC Connector より Flink Doris Connector の方が高いため、後者を推奨します。
+
+- **Flink JDBC Connector**: Doris は MySQL プロトコルと互換性がありますが、JDBC 経由の読み書きは単一の FE ノードで直列に処理されるため、性能上のボトルネックになります。使用は推奨しません。
+- **Flink Doris Connector**: Doris 2.1 以降、デフォルトの読み取りプロトコルは ADBC です。読み取りは次の手順で行われます。
+ 1. Flink Doris Connector が FE からクエリプラン内の Tablet ID 情報を取得します。
+ 2. クエリ文 `SELECT * FROM tbs TABLET(id1, id2, id3)` を生成します。
+ 3. FE の ADBC ポートを介してクエリを実行します。
+ 4. BE がデータを直接返します。これにより、データが FE を経由せず、単一 FE のボトルネックを回避できます。
+
+### 書き込みの仕組み
+
+Flink Doris Connector は、書き込みデータを Flink のメモリ内でバッチ化し、Stream Load で Doris に一括取り込みします。バッチ化には次の二つのモードがあり、デフォルトは Flink Checkpoint に基づくストリーミング書き込みです。
+
+| 比較項目 | ストリーミング書き込み | バッチ書き込み |
+| --------------------- | ---------------------------------------------------------------- | ------------------------------------------------------------ |
+| トリガー条件 | Flink Checkpoint に依存し、Checkpoint のたびに Doris に書き込む | Connector 内で時間とデータ量のしきい値に基づいて定期的にコミットする |
+| 一貫性 | Exactly-Once | At-Least-Once。主キーモデルを使用すると Exactly-Once を保証できる |
+| レイテンシー | Checkpoint 間隔に制限され、通常は高め | 独立したバッチ処理機構があり、柔軟に調整できる |
+| 障害耐性と復旧 | Flink の状態復旧と完全に整合する | 外部の重複排除ロジック（Doris の主キーによる重複排除など）に依存する |
+
+## クイックスタート
+
+このセクションでは、Flink クラスターのデプロイから FlinkSQL を使用した Doris データの読み書きまで、一連の手順を示します。
+
+### 1. Flink クラスターをデプロイする
+
+Standalone クラスターを例に説明します。
+
+1. [Flink 1.18.1](https://archive.apache.org/dist/flink/flink-1.18.1/flink-1.18.1-bin-scala_2.12.tgz) のインストールパッケージをダウンロードします。
+2. 展開後、Flink Doris Connector の Jar パッケージを `<FLINK_HOME>/lib` に配置します。
+3. `<FLINK_HOME>` ディレクトリに移動し、`bin/start-cluster.sh` を実行して Flink クラスターを起動します。
+4. `jps` コマンドで Flink クラスターが正常に起動したことを確認します。
+
+### 2. Doris テーブルを初期化する
+
+次の SQL を実行して Doris テーブルを作成し、テストデータを書き込みます。
+
+```sql
+CREATE DATABASE test;
+
+CREATE TABLE test.student (
+ `id` INT,
+ `name` VARCHAR(256),
+ `age` INT
+)
+UNIQUE KEY(`id`)
+DISTRIBUTED BY HASH(`id`) BUCKETS 1
+PROPERTIES (
+ "replication_allocation" = "tag.location.default: 3"
+);
+
+INSERT INTO test.student values(1, "James", 18);
+INSERT INTO test.student values(2, "Emily", 28);
+
+CREATE TABLE test.student_trans (
+ `id` INT,
+ `name` VARCHAR(256),
+ `age` INT
+)
+UNIQUE KEY(`id`)
+DISTRIBUTED BY HASH(`id`) BUCKETS 1
+PROPERTIES (
+ "replication_allocation" = "tag.location.default: 3"
+);
+```
+
+### 3. FlinkSQL ジョブを実行する
+
+FlinkSQL Client を起動します。
+
+```shell
+bin/sql-client.sh
+```
+
+次の FlinkSQL を実行します。
+
+```sql
+CREATE TABLE Student (
+ id STRING,
+ name STRING,
+ age INT
+)
+WITH (
+ 'connector' = 'doris',
+ 'fenodes' = '127.0.0.1:8030',
+ 'table.identifier' = 'test.student',
+ 'username' = 'root',
+ 'password' = ''
+);
+
+CREATE TABLE StudentTrans (
+ id STRING,
+ name STRING,
+ age INT
+)
+WITH (
+ 'connector' = 'doris',
+ 'fenodes' = '127.0.0.1:8030',
+ 'table.identifier' = 'test.student_trans',
+ 'username' = 'root',
+ 'password' = '',
+ 'sink.label-prefix' = 'doris_label'
+);
+
+INSERT INTO StudentTrans SELECT id, concat('prefix_', name), age + 1 FROM Student;
+```
+
+### 4. 結果を確認する
+
+```text
+mysql> select * from test.student_trans;
++------+--------------+------+
+| id | name | age |
++------+--------------+------+
+| 1 | prefix_James | 19 |
+| 2 | prefix_Emily | 29 |
++------+--------------+------+
+2 rows in set (0.02 sec)
+```
+
+## ユースケース
+
+### ケース 1: Doris データを読み取る
+
+Flink が Doris データを読み取る場合、Doris Source は有限ストリームとなり、CDC による継続的な読み取りには対応しません。次の二つの読み取りプロトコルを使用できます。
+
+| プロトコル | 説明 | 推奨バージョン |
+| -------------- | ------------------------------------------------------------ | ------------------- |
+| Thrift | BE の Thrift インターフェースを呼び出してデータを読み取る | すべてのバージョンと互換 |
+| ArrowFlightSQL | Doris 2.1 を基盤とする Arrow Flight SQL プロトコルを介して大量のデータを高速に読み取る | Connector 24.0.0+ |
+
+- Thrift の処理フローについては、[Thrift インターフェースによるデータ読み取り](https://github.com/apache/doris/blob/master/samples/doris-demo/doris-source-demo/README.md) を参照してください。
+- ArrowFlightSQL の使い方については、[Arrow Flight SQL に基づく高速データ転送](https://doris.apache.org/docs/dev/db-connect/arrow-flight-sql-connect/) を参照してください。Doris 2.1 以降では ArrowFlightSQL の使用を推奨します。
+
+#### FlinkSQL で読み取る（Thrift 方式）
+
+```sql
+CREATE TABLE student (
+ id INT,
+ name STRING,
+ age INT
+)
+WITH (
+ 'connector' = 'doris',
+ 'fenodes' = '127.0.0.1:8030', -- FE host:HttpPort
+ 'table.identifier' = 'test.student',
+ 'username' = 'root',
+ 'password' = ''
+);
+
+SELECT * FROM student;
+```
+
+#### FlinkSQL で読み取る（ArrowFlightSQL 方式）
+
+```sql
+CREATE TABLE student (
+ id INT,
+ name STRING,
+ age INT
+)
+WITH (
+ 'connector' = 'doris',
+ 'fenodes' = '{fe.conf:http_port}',
+ 'table.identifier' = 'test.student',
+ 'source.use-flight-sql' = 'true',
+ 'source.flight-sql-port' = '{fe.conf:arrow_flight_sql_port}',
+ 'username' = 'root',
+ 'password' = ''
+);
+
+SELECT * FROM student;
+```
+
+#### DataStream API で読み取る
+
+DataStream API で読み取る場合は、あらかじめプロジェクトの POM ファイルに依存関係を追加する必要があります。[インストール](#installation) を参照してください。
+
+```java
+final StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
+DorisOptions option = DorisOptions.builder()
+ .setFenodes("127.0.0.1:8030")
+ .setTableIdentifier("test.student")
+ .setUsername("root")
+ .setPassword("")
+ .build();
+
+DorisReadOptions readOptions = DorisReadOptions.builder().build();
+DorisSource<List<?>> dorisSource = DorisSource.<List<?>>builder()
+ .setDorisOptions(option)
+ .setDorisReadOptions(readOptions)
+ .setDeserializer(new SimpleListDeserializationSchema())
+ .build();
+
+env.fromSource(dorisSource, WatermarkStrategy.noWatermarks(), "doris source").print();
+env.execute("Doris Source Test");
+```
+
+### ケース 2: Doris データを書き込む
+
+Flink は Stream Load を介して Doris に書き込みます。ストリーミング書き込みとバッチ書き込みの二つのモードに対応します。
+
+:::info ストリーミング書き込みとバッチ書き込みの違い
+
+バッチ書き込みは Connector 1.5.0 以降でサポートされます。バッチ書き込みは Checkpoint に依存せず、データをメモリにキャッシュし、バッチ化パラメーターに基づいて書き込みタイミングを制御します。ストリーミング書き込みでは Checkpoint を有効にする必要があり、Checkpoint の期間を通して上流データを Doris に継続的に書き込みます。データを常時メモリにキャッシュすることはありません。
+
+:::
+
+#### FlinkSQL で書き込む
+
+Flink の [Datagen](https://nightlies.apache.org/flink/flink-docs-master/docs/connectors/table/datagen/) を使用し、上流から継続的に生成されるデータをシミュレートします。
+
+```sql
+-- Enable checkpoint
+SET 'execution.checkpointing.interval' = '30s';
+
+CREATE TABLE student_source (
+ id INT,
+ name STRING,
+ age INT
+) WITH (
+ 'connector' = 'datagen',
+ 'rows-per-second' = '1',
+ 'fields.name.length' = '20',
+ 'fields.id.min' = '1',
+ 'fields.id.max' = '100000',
+ 'fields.age.min' = '3',
+ 'fields.age.max' = '30'
+);
+
+-- doris sink
+CREATE TABLE student_sink (
+ id INT,
+ name STRING,
+ age INT
+)
+WITH (
+ 'connector' = 'doris',
+ 'fenodes' = '10.16.10.6:28737',
+ 'table.identifier' = 'test.student',
+ 'username' = 'root',
+ 'password' = 'password',
+ 'sink.label-prefix' = 'doris_label'
+ -- 'sink.enable.batch-mode' = 'true' Add this configuration to use batch write
+);
+
+INSERT INTO student_sink SELECT * FROM student_source;
+```
+
+#### DataStream API で書き込む
+
+DataStream API で書き込む場合は、上流データを Doris テーブルに書き込むために、さまざまなシリアライズ方式を使用できます。
+
+:::info
+
+Connector には HttpClient バージョン 4.5.13 が組み込まれています。プロジェクトで HttpClient を別途参照する場合は、バージョンを一致させてください。
+
+:::
+
+##### プレーン文字列形式
+
+上流データが csv または json 形式の場合は、`SimpleStringSerializer` を直接使用してシリアライズできます。
+
+```java
+StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
+env.enableCheckpointing(30000);
+DorisSink.Builder<String> builder = DorisSink.builder();
+
+DorisOptions dorisOptions = DorisOptions.builder()
+ .setFenodes("10.16.10.6:28737")
+ .setTableIdentifier("test.student")
+ .setUsername("root")
+ .setPassword("")
+ .build();
+
+Properties properties = new Properties();
+// When upstream is json data, the following configuration is required
+properties.setProperty("read_json_by_line", "true");
+properties.setProperty("format", "json");
+
+// When upstream is csv, the following configuration is required
+// properties.setProperty("format", "csv");
+// properties.setProperty("column_separator", ",");
+
+DorisExecutionOptions executionOptions = DorisExecutionOptions.builder()
+ .setLabelPrefix("label-doris")
+ .setDeletable(false)
+ // .setBatchMode(true) Enable batch write
+ .setStreamLoadProp(properties)
+ .build();
+
+builder.setDorisReadOptions(DorisReadOptions.builder().build())
+ .setDorisExecutionOptions(executionOptions)
+ .setSerializer(new SimpleStringSerializer())
+ .setDorisOptions(dorisOptions);
+
+List<String> data = new ArrayList<>();
+data.add("{\"id\":3,\"name\":\"Michael\",\"age\":28}");
+data.add("{\"id\":4,\"name\":\"David\",\"age\":38}");
+
+env.fromCollection(data).sinkTo(builder.build());
+env.execute("doris test");
+```
+
+##### RowData 形式
+
+`RowData` は Flink の内部形式です。上流データが RowData 形式で渡される場合は、`RowDataSerializer` を使用してシリアライズする必要があります。
+
+```java
+StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
+env.enableCheckpointing(10000);
+env.setParallelism(1);
+
+DorisSink.Builder<RowData> builder = DorisSink.builder();
+
+Properties properties = new Properties();
+properties.setProperty("column_separator", ",");
+properties.setProperty("line_delimiter", "\n");
+properties.setProperty("format", "csv");
+// When upstream is json, the following configuration is required
+// properties.setProperty("read_json_by_line", "true");
+// properties.setProperty("format", "json");
+DorisOptions.Builder dorisBuilder = DorisOptions.builder();
+dorisBuilder
+ .setFenodes("10.16.10.6:28737")
+ .setTableIdentifier("test.student")
+ .setUsername("root")
+ .setPassword("");
+DorisExecutionOptions.Builder executionBuilder = DorisExecutionOptions.builder();
+executionBuilder.setLabelPrefix(UUID.randomUUID().toString()).setDeletable(false).setStreamLoadProp(properties);
+
+// flink rowdata's schema
+String[] fields = {"id", "name", "age"};
+DataType[] types = {DataTypes.INT(), DataTypes.VARCHAR(256), DataTypes.INT()};
+
+builder.setDorisExecutionOptions(executionBuilder.build())
+ .setSerializer(
+ RowDataSerializer.builder() // serialize according to rowdata
+ .setType(LoadConstants.CSV)
+ .setFieldDelimiter(",")
+ .setFieldNames(fields)
+ .setFieldType(types)
+ .build())
+ .setDorisOptions(dorisBuilder.build());
+
+// mock rowdata source
+DataStream<RowData> source =
+ env.fromElements("")
+ .flatMap(
+ new FlatMapFunction<String, RowData>() {
+ @Override
+ public void flatMap(String s, Collector<RowData> out)
+ throws Exception {
+ GenericRowData genericRowData = new GenericRowData(3);
+ genericRowData.setField(0, 1);
+ genericRowData.setField(1, StringData.fromString("Michael"));
+ genericRowData.setField(2, 18);
+ out.collect(genericRowData);
+
+ GenericRowData genericRowData2 = new GenericRowData(3);
+ genericRowData2.setField(0, 2);
+ genericRowData2.setField(1, StringData.fromString("David"));
+ genericRowData2.setField(2, 38);
+ out.collect(genericRowData2);
+ }
+ });
+
+source.sinkTo(builder.build());
+env.execute("doris test");
+```
+
+##### Debezium 形式
+
+上流からのデータが Debezium 形式の場合（Flink CDC や Kafka 内の Debezium 形式のデータなど）、`JsonDebeziumSchemaSerializer` を使用してシリアライズします。
+
+```java
+// Enable checkpoint
+env.enableCheckpointing(10000);
+
+Properties props = new Properties();
+props.setProperty("format", "json");
+props.setProperty("read_json_by_line", "true");
+DorisOptions dorisOptions = DorisOptions.builder()
+ .setFenodes("127.0.0.1:8030")
+ .setTableIdentifier("test.student")
+ .setUsername("root")
+ .setPassword("").build();
+
+DorisExecutionOptions.Builder executionBuilder = DorisExecutionOptions.builder();
+executionBuilder.setLabelPrefix("label-prefix")
+ .setStreamLoadProp(props)
+ .setDeletable(true);
+
+DorisSink.Builder<String> builder = DorisSink.builder();
+builder.setDorisReadOptions(DorisReadOptions.builder().build())
+ .setDorisExecutionOptions(executionBuilder.build())
+ .setDorisOptions(dorisOptions)
+ .setSerializer(JsonDebeziumSchemaSerializer.builder().setDorisOptions(dorisOptions).build());
+
+env.fromSource(mySqlSource, WatermarkStrategy.noWatermarks(), "MySQL Source")
+ .sinkTo(builder.build());
+```
+
+##### 複数テーブルへの書き込み形式
+
+DorisSink は、一つの Sink で複数テーブルを同期できます。データをデータベース名とテーブル名の情報とともに Sink に渡し、`RecordWithMetaSerializer` を使用してシリアライズする必要があります。
+
+```java
+StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
+env.setParallelism(1);
+DorisSink.Builder<RecordWithMeta> builder = DorisSink.builder();
+Properties properties = new Properties();
+properties.setProperty("column_separator", ",");
+properties.setProperty("line_delimiter", "\n");
+properties.setProperty("format", "csv");
+DorisOptions.Builder dorisBuilder = DorisOptions.builder();
+dorisBuilder
+ .setFenodes("10.16.10.6:28737")
+ .setTableIdentifier("")
+ .setUsername("root")
+ .setPassword("");
+
+DorisExecutionOptions.Builder executionBuilder = DorisExecutionOptions.builder();
+
+executionBuilder
+ .setLabelPrefix("label-doris")
+ .setStreamLoadProp(properties)
+ .setDeletable(false)
+ .setBatchMode(true);
+
+builder.setDorisReadOptions(DorisReadOptions.builder().build())
+ .setDorisExecutionOptions(executionBuilder.build())
+ .setDorisOptions(dorisBuilder.build())
+ .setSerializer(new RecordWithMetaSerializer());
+
+RecordWithMeta record = new RecordWithMeta("test", "student_1", "1,David,18");
+RecordWithMeta record1 = new RecordWithMeta("test", "student_2", "1,Jack,28");
+env.fromCollection(Arrays.asList(record, record1)).sinkTo(builder.build());
+```
+
+### ケース 3: Lookup Join によるディメンションテーブル結合
+
+Lookup Join は、Flink でのディメンションテーブル結合の性能を改善できます。ディメンションテーブル結合に Flink JDBC Connector を使用すると、次の問題が生じる可能性があります。
+
+- Flink JDBC Connector は同期クエリ方式を使用します。上流（Kafka など）からレコードが届くたびに Doris のディメンションテーブルを即座にクエリするため、同時実行数が多いとクエリのレイテンシーが高くなります。
+- JDBC 経由のクエリは通常、レコードを一件ずつ検索しますが、Doris では効率を高めるためにバッチクエリを推奨しています。
+
+Flink Doris Connector の [Lookup Join](https://nightlies.apache.org/flink/flink-docs-release-1.20/docs/dev/table/sql/queries/joins/#lookup-join) には次の利点があります。
+
+- 上流データをバッチ単位でキャッシュし、レコード単位のクエリによる高いレイテンシーとデータベースへの負荷を抑えます。
+- 結合クエリを非同期に実行し、データのスループットを高めながら Doris のクエリ負荷を軽減します。
+
+```sql
+CREATE TABLE fact_table (
+ `id` BIGINT,
+ `name` STRING,
+ `city` STRING,
+ `process_time` as proctime()
+) WITH (
+ 'connector' = 'kafka',
+ ...
+);
+
+create table dim_city(
+ `city` STRING,
+ `level` INT,
+ `province` STRING,
+ `country` STRING
+) WITH (
+ 'connector' = 'doris',
+ 'fenodes' = '127.0.0.1:8030',
+ 'jdbc-url' = 'jdbc:mysql://127.0.0.1:9030',
+ 'table.identifier' = 'dim.dim_city',
+ 'username' = 'root',
+ 'password' = '',
+ 'lookup.cache.max-rows' = '100000',
+ 'lookup.cache.ttl' = '300s'
+);
+
+SELECT a.id, a.name, a.city, c.province, c.country, c.level
+FROM fact_table a
+LEFT JOIN dim_city FOR SYSTEM_TIME AS OF a.process_time AS c
+ON a.city = c.city
+```
+
+### ケース 4: CDC によるデータベース全体の同期
+
+Flink Doris Connector は [Flink CDC](https://nightlies.apache.org/flink/flink-cdc-docs-release-3.2/docs/connectors/flink-sources/overview/) と連携し、MySQL などのリレーショナルデータベースを Doris に同期できます。テーブルの自動作成や Schema Change にも対応します。現在サポートされるデータベースは MySQL、Oracle、PostgreSQL、SQLServer、MongoDB、DB2 です。
+
+:::info 注意
+
+1. データベース全体を同期する場合は、対応する Flink CDC の依存関係（**Fat Jar**）を `$FLINK_HOME/lib` に追加する必要があります。たとえば、`flink-sql-connector-mysql-cdc-${version}.jar` や `flink-sql-connector-oracle-cdc-${version}.jar` です。Flink CDC 3.1 以降は、それ以前のバージョンと互換性がありません。ダウンロード先: [Flink CDC 3.x](https://repo.maven.apache.org/maven2/org/apache/flink/flink-sql-connector-mysql-cdc/)、[Flink CDC 2.x](https://repo.maven.apache.org/maven2/com/ververica/flink-sql-connector-mysql-cdc/)。
+2. Connector 24.0.0 以降では、依存する Flink CDC のバージョンは 3.1 以上である必要があります。[ダウンロード先](https://repo.maven.apache.org/maven2/org/apache/flink/flink-sql-connector-mysql-cdc/)。Flink CDC で MySQL と Oracle を同期する場合は、対応する JDBC ドライバーも `$FLINK_HOME/lib` に追加する必要があります。
+
+:::
+
+Flink クラスターを起動したら、データソースの種類に応じたコマンドを実行します。
+
+#### MySQL データベース全体の同期
+
+```shell
+<FLINK_HOME>bin/flink run \
+ -Dexecution.checkpointing.interval=10s \
+ -Dparallelism.default=1 \
+ -c org.apache.doris.flink.tools.cdc.CdcTools \
+ lib/flink-doris-connector-1.16-24.0.1.jar \
+ mysql-sync-database \
+ --database test_db \
+ --mysql-conf hostname=127.0.0.1 \
+ --mysql-conf port=3306 \
+ --mysql-conf username=root \
+ --mysql-conf password=123456 \
+ --mysql-conf database-name=mysql_db \
+ --including-tables "tbl1|test.*" \
+ --sink-conf fenodes=127.0.0.1:8030 \
+ --sink-conf username=root \
+ --sink-conf password=123456 \
+ --sink-conf jdbc-url=jdbc:mysql://127.0.0.1:9030 \
+ --sink-conf sink.label-prefix=label \
+ --table-conf replication_num=1
+```
+
+#### Oracle データベース全体の同期
+
+```shell
+<FLINK_HOME>bin/flink run \
+ -Dexecution.checkpointing.interval=10s \
+ -Dparallelism.default=1 \
+ -c org.apache.doris.flink.tools.cdc.CdcTools \
+ ./lib/flink-doris-connector-1.16-24.0.1.jar \
+ oracle-sync-database \
+ --database test_db \
+ --oracle-conf hostname=127.0.0.1 \
+ --oracle-conf port=1521 \
+ --oracle-conf username=admin \
+ --oracle-conf password="password" \
+ --oracle-conf database-name=XE \
+ --oracle-conf schema-name=ADMIN \
+ --including-tables "tbl1|tbl2" \
+ --sink-conf fenodes=127.0.0.1:8030 \
+ --sink-conf username=root \
+ --sink-conf password=\
+ --sink-conf jdbc-url=jdbc:mysql://127.0.0.1:9030 \
+ --sink-conf sink.label-prefix=label \
+ --table-conf replication_num=1
+```
+
+#### PostgreSQL データベース全体の同期
+
+```shell
+<FLINK_HOME>/bin/flink run \
+ -Dexecution.checkpointing.interval=10s \
+ -Dparallelism.default=1 \
+ -c org.apache.doris.flink.tools.cdc.CdcTools \
+ ./lib/flink-doris-connector-1.16-24.0.1.jar \
+ postgres-sync-database \
+ --database db1 \
+ --postgres-conf hostname=127.0.0.1 \
+ --postgres-conf port=5432 \
+ --postgres-conf username=postgres \
+ --postgres-conf password="123456" \
+ --postgres-conf database-name=postgres \
+ --postgres-conf schema-name=public \
+ --postgres-conf slot.name=test \
+ --postgres-conf decoding.plugin.name=pgoutput \
+ --including-tables "tbl1|tbl2" \
+ --sink-conf fenodes=127.0.0.1:8030 \
+ --sink-conf username=root \
+ --sink-conf password=\
+ --sink-conf jdbc-url=jdbc:mysql://127.0.0.1:9030 \
+ --sink-conf sink.label-prefix=label \
+ --table-conf replication_num=1
+```
+
+#### SQLServer データベース全体の同期
+
+```shell
+<FLINK_HOME>/bin/flink run \
+ -Dexecution.checkpointing.interval=10s \
+ -Dparallelism.default=1 \
+ -c org.apache.doris.flink.tools.cdc.CdcTools \
+ ./lib/flink-doris-connector-1.16-24.0.1.jar \
+ sqlserver-sync-database \
+ --database db1 \
+ --sqlserver-conf hostname=127.0.0.1 \
+ --sqlserver-conf port=1433 \
+ --sqlserver-conf username=sa \
+ --sqlserver-conf password="123456" \
+ --sqlserver-conf database-name=CDC_DB \
+ --sqlserver-conf schema-name=dbo \
+ --including-tables "tbl1|tbl2" \
+ --sink-conf fenodes=127.0.0.1:8030 \
+ --sink-conf username=root \
+ --sink-conf password=\
+ --sink-conf jdbc-url=jdbc:mysql://127.0.0.1:9030 \
+ --sink-conf sink.label-prefix=label \
+ --table-conf replication_num=1
+```
+
+#### DB2 データベース全体の同期
+
+```shell
+<FLINK_HOME>bin/flink run \
+ -Dexecution.checkpointing.interval=10s \
+ -Dparallelism.default=1 \
+ -c org.apache.doris.flink.tools.cdc.CdcTools \
+ lib/flink-doris-connector-1.16-24.0.1.jar \
+ db2-sync-database \
+ --database db2_test \
+ --db2-conf hostname=127.0.0.1 \
+ --db2-conf port=50000 \
+ --db2-conf username=db2inst1 \
+ --db2-conf password=doris123456 \
+ --db2-conf database-name=testdb \
+ --db2-conf schema-name=DB2INST1 \
+ --including-tables "FULL_TYPES|CUSTOMERS" \
+ --single-sink true \
+ --use-new-schema-change true \
+ --sink-conf fenodes=127.0.0.1:8030 \
+ --sink-conf username=root \
+ --sink-conf password=123456 \
+ --sink-conf jdbc-url=jdbc:mysql://127.0.0.1:9030 \
+ --sink-conf sink.label-prefix=label \
+ --table-conf replication_num=1
+```
+
+#### MongoDB データベース全体の同期
+
+```shell
+<FLINK_HOME>/bin/flink run \
+ -Dexecution.checkpointing.interval=10s \
+ -Dparallelism.default=1 \
+ -c org.apache.doris.flink.tools.cdc.CdcTools \
+ ./lib/flink-doris-connector-1.18-24.0.1.jar \
+ mongodb-sync-database \
+ --database doris_db \
+ --schema-change-mode debezium_structure \
+ --mongodb-conf hosts=127.0.0.1:27017 \
+ --mongodb-conf username=flinkuser \
+ --mongodb-conf password=flinkpwd \
+ --mongodb-conf database=test \
+ --mongodb-conf scan.startup.mode=initial \
+ --mongodb-conf schema.sample-percent=0.2 \
+ --including-tables "tbl1|tbl2" \
+ --sink-conf fenodes=127.0.0.1:8030 \
+ --sink-conf username=root \
+ --sink-conf password= \
+ --sink-conf jdbc-url=jdbc:mysql://127.0.0.1:9030 \
+ --sink-conf sink.label-prefix=label \
+ --sink-conf sink.enable-2pc=false \
+ --table-conf replication_num=1
+```
+
+#### AWS Aurora MySQL データベース全体の同期
+
+```shell
+<FLINK_HOME>bin/flink run \
+ -Dexecution.checkpointing.interval=10s \
+ -Dparallelism.default=1 \
+ -c org.apache.doris.flink.tools.cdc.CdcTools \
+ lib/flink-doris-connector-1.18-25.0.0.jar \
+ mysql-sync-database \
+ --database testwd \
+ --mysql-conf hostname=xxx.us-east-1.rds.amazonaws.com \
+ --mysql-conf port=3306 \
+ --mysql-conf username=admin \
+ --mysql-conf password=123456 \
+ --mysql-conf database-name=test \
+ --mysql-conf server-time-zone=UTC \
+ --including-tables "student" \
+ --sink-conf fenodes=127.0.0.1:8030 \
+ --sink-conf username=root \
+ --sink-conf password= \
+ --sink-conf jdbc-url=jdbc:mysql://127.0.0.1:9030 \
+ --sink-conf sink.label-prefix=label \
+ --table-conf replication_num=1
+```
+
+#### AWS RDS MySQL データベース全体の同期
+
+```shell
+<FLINK_HOME>bin/flink run \
+ -Dexecution.checkpointing.interval=10s \
+ -Dparallelism.default=1 \
+ -c org.apache.doris.flink.tools.cdc.CdcTools \
+ lib/flink-doris-connector-1.18-25.0.0.jar \
+ mysql-sync-database \
+ --database testwd \
+ --mysql-conf hostname=xxx.ap-southeast-1.rds.amazonaws.com \
+ --mysql-conf port=3306 \
+ --mysql-conf username=admin \
+ --mysql-conf password=123456 \
+ --mysql-conf database-name=test \
+ --mysql-conf server-time-zone=UTC \
+ --including-tables "student" \
+ --sink-conf fenodes=127.0.0.1:8030 \
+ --sink-conf username=root \
+ --sink-conf password= \
+ --sink-conf jdbc-url=jdbc:mysql://127.0.0.1:9030 \
+ --sink-conf sink.label-prefix=label \
+ --table-conf replication_num=1
+```
+
+## 設定リファレンス
+
+### 共通設定
+
+| キー | デフォルト値 | 必須 | 説明 |
+| ----------------------------- | ------------- | -------- | ------------------------------------------------------------------------------------- |
+| fenodes | -- | Y | Doris FE の HTTP アドレス。複数のアドレスをカンマ区切りで指定できます。 |
+| benodes | -- | N | Doris BE の HTTP アドレス。複数のアドレスをカンマ区切りで指定できます。 |
+| jdbc-url | -- | N | JDBC 接続情報。例: `jdbc:mysql://127.0.0.1:9030`。 |
+| table.identifier | -- | Y | Doris のテーブル名。例: `db.tbl`。 |
+| username | -- | Y | Doris にアクセスするためのユーザー名。 |
+| password | -- | Y | Doris にアクセスするためのパスワード。 |
+| auto-redirect | TRUE | N | Stream Load リクエストをリダイレクトするかどうか。有効な場合、BE 情報を明示的に取得せず、FE を介して Stream Load で書き込みます。 |
+| doris.request.retries | 3 | N | Doris へのリクエスト送信時の再試行回数。 |
+| doris.request.connect.timeout | 30s | N | Doris へのリクエスト送信時の接続タイムアウト。 |
+| doris.request.read.timeout | 30s | N | Doris へのリクエスト送信時の読み取りタイムアウト。 |
+
+### Source の設定
+
+| キー | デフォルト値 | 必須 | 説明 |
+| --------------------------- | ------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| doris.request.query.timeout | 21600s | N | Doris へのクエリのタイムアウト。デフォルトは 6 時間です。 |
+| doris.request.tablet.size | 1 | N | 一つの Partition に対応する Doris Tablet の数。値を小さくすると Partition が増えて Flink 側の並列度が上がりますが、Doris への負荷も増えます。 |
+| doris.batch.size | 4064 | N | BE から一度に読み取る最大行数。値を大きくすると Flink と Doris の間で確立する接続の数を減らせるため、ネットワーク遅延による追加の時間コストを抑えられます。 |
+| doris.exec.mem.limit | 8192mb | N | 一つのクエリのメモリ上限。デフォルトは 8GB で、単位はバイトです。 |
+| source.use-flight-sql | TRUE | N | 読み取りに Arrow Flight SQL を使用するかどうか。 |
+| source.flight-sql-port | - | N | Arrow Flight SQL で読み取る場合の FE の `arrow_flight_sql_port`。 |
+
+**DataStream 固有の設定**
+
+| キー | デフォルト値 | 必須 | 説明 |
+| ------------------ | ------------- | -------- | --------------------------------------------------------------------------------------------- |
+| doris.read.field | -- | N | Doris テーブルから読み取る列名のリスト。カンマで区切ります。 |
+| doris.filter.query | -- | N | 読み取りデータを絞り込む式。この式は Doris にそのまま渡され、Doris が読み取り元でデータをフィルタリングします。例: `age=18`。 |
+
+### Sink の設定 {#sink-configuration}
+
+| キー | デフォルト値 | 必須 | 説明 |
+| --------------------------- | ------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- [...]
+| sink.label-prefix | -- | Y | Stream Load による取り込みで使用するラベルのプレフィックス。2pc を使用する場合、Flink の EOS セマンティクスを保証するために、全体で一意である必要があります。 |
+| sink.properties.* | -- | N | Stream Load の取り込みパラメーター。例: `'sink.properties.column_separator' = ', '` は列区切り文字を定義します。`'sink.properties.escape_delimiters' = 'true'` は特殊文字を区切り文字に使用することを示し、`\x01` はバイナリの `0x01` に変換されます。JSON 形式の取り込みには `'sink.properties.format' = 'json'` と `'sink.properties.read_json_by_line' = 'true'` を使用します。詳細は [Stream Load](../../data-operate/import/import-way/stream-load-manual.md#import-configuration-parameters) を参照してください。Group Commit モードでは `'si [...]
+| sink.enable-delete | TRUE | N | 削除を有効にするかどうか。このオプションを使用するには、Doris テーブルでバッチ削除が有効になっている必要があります（Doris 0.15+ ではデフォルトで有効）。Unique モデルのみをサポートします。 |
+| sink.enable-2pc | TRUE | N | 二相コミット（2pc）を有効にするかどうか。デフォルトは true で、Exactly-Once セマンティクスを保証します。詳細は [Stream Load 2PC](../../data-operate/transaction.md#streamload-2pc) を参照してください。 |
+| sink.buffer-size | 1MB | N | 書き込みデータのキャッシュに使用するバッファーのサイズ。単位はバイトです。デフォルト設定で十分なため、変更は推奨しません。 |
+| sink.buffer-count | 3 | N | 書き込みデータのキャッシュバッファーの数。デフォルト設定で十分なため、変更は推奨しません。 |
+| sink.max-retries | 3 | N | Commit が失敗した後の最大再試行回数。デフォルトは 3 です。 |
+| sink.enable.batch-mode | FALSE | N | バッチモードで Doris に書き込むかどうか。有効な場合、書き込みタイミングは Checkpoint に依存せず、`sink.buffer-flush.max-rows`、`sink.buffer-flush.max-bytes`、`sink.buffer-flush.interval` で制御されます。有効にすると Exactly-Once セマンティクスは保証されません。Unique モデルを使用すると冪等性を実現できます。 |
+| sink.flush.queue-size | 2 | N | バッチモードでのキャッシュキューのサイズ。 |
+| sink.buffer-flush.max-rows | 500000 | N | バッチモードで一回のバッチに書き込む最大行数。 |
+| sink.buffer-flush.max-bytes | 100MB | N | バッチモードで一回のバッチに書き込む最大バイト数。 |
+| sink.buffer-flush.interval | 10s | N | バッチモードでキャッシュを非同期にフラッシュする間隔。 |
+| sink.ignore.update-before | TRUE | N | update-before イベントを無視するかどうか。デフォルトでは無視します。 |
+
+### Lookup Join の設定
+
+| キー | デフォルト値 | 必須 | 説明 |
+| --------------------------------- | ------------- | -------- | --------------------------------------------- |
+| lookup.cache.max-rows | -1 | N | lookup がキャッシュする最大行数。デフォルトの -1 はキャッシュを無効にすることを示します。 |
+| lookup.cache.ttl | 10s | N | lookup キャッシュの最大保持時間。デフォルトは 10s です。 |
+| lookup.max-retries | 1 | N | lookup クエリが失敗した後の再試行回数。 |
+| lookup.jdbc.async | FALSE | N | 非同期 lookup を有効にするかどうか。デフォルトは false です。 |
+| lookup.jdbc.read.batch.size | 128 | N | 非同期 lookup でのクエリ一回あたりの最大バッチサイズ。 |
+| lookup.jdbc.read.batch.queue-size | 256 | N | 非同期 lookup で使用する中間バッファーキューのサイズ。 |
+| lookup.jdbc.read.thread-size | 3 | N | 各タスクで lookup に使用する JDBC スレッドの数。 |
+
+### データベース全体の同期設定
+
+**構文**
+
+```shell
+<FLINK_HOME>bin/flink run \
+ -c org.apache.doris.flink.tools.cdc.CdcTools \
+ lib/flink-doris-connector-1.16-1.6.1.jar \
+ <mysql-sync-database|oracle-sync-database|postgres-sync-database|sqlserver-sync-database|mongodb-sync-database> \
+ --database <doris-database-name> \
+ [--job-name <flink-job-name>] \
+ [--table-prefix <doris-table-prefix>] \
+ [--table-suffix <doris-table-suffix>] \
+ [--including-tables <mysql-table-name|name-regular-expr>] \
+ [--excluding-tables <mysql-table-name|name-regular-expr>] \
+ --mysql-conf <mysql-cdc-source-conf> [--mysql-conf <mysql-cdc-source-conf> ...] \
+ --oracle-conf <oracle-cdc-source-conf> [--oracle-conf <oracle-cdc-source-conf> ...] \
+ --postgres-conf <postgres-cdc-source-conf> [--postgres-conf <postgres-cdc-source-conf> ...] \
+ --sqlserver-conf <sqlserver-cdc-source-conf> [--sqlserver-conf <sqlserver-cdc-source-conf> ...] \
+ --sink-conf <doris-sink-conf> [--table-conf <doris-sink-conf> ...] \
+ [--table-conf <doris-table-conf> [--table-conf <doris-table-conf> ...]]
+```
+
+**設定項目**
+
+| キー | 説明 |
+| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| --job-name | Flink ジョブ名。省略可能です。 |
+| --database | Doris への同期先データベース名。 |
+| --table-prefix | Doris テーブル名のプレフィックス。例: `--table-prefix ods_`。 |
+| --table-suffix | Doris テーブル名のサフィックス。 |
+| --including-tables | 同期する MySQL テーブル。複数のテーブルを `\|` で区切って指定できます。正規表現にも対応します。例: `--including-tables table1`。 |
+| --excluding-tables | 同期しないテーブル。指定方法は上記と同じです。 |
+| --mysql-conf | MySQL CDCSource の設定。例: `--mysql-conf hostname=127.0.0.1`。すべての設定項目は [MySQL CDC](https://nightlies.apache.org/flink/flink-cdc-docs-release-3.2/docs/connectors/flink-sources/mysql-cdc/) を参照してください。hostname/username/password/database-name は必須です。同期対象のデータベースまたはテーブルに主キーのないテーブルが含まれる場合は、`scan.incremental.snapshot.chunk.key-column` を設定する必要があり、単一の非 NULL フィールドのみを選択できます。例: `scan.incremental.snapshot.chunk.key-column=database.table:column,database.table1:column...`。異なるデータベースやテ [...]
+| --oracle-conf | Oracle CDCSource の設定。例: `--oracle-conf hostname=127.0.0.1`。すべての設定項目は [Oracle CDC](https://nightlies.apache.org/flink/flink-cdc-docs-release-3.2/docs/connectors/flink-sources/oracle-cdc/) を参照してください。hostname/username/password/database-name/schema-name は必須です。 |
+| --postgres-conf | Postgres CDCSource の設定。例: `--postgres-conf hostname=127.0.0.1`。すべての設定項目は [Postgres CDC](https://nightlies.apache.org/flink/flink-cdc-docs-release-3.2/docs/connectors/flink-sources/postgres-cdc/) を参照してください。hostname/username/password/database-name/schema-name/slot.name は必須です。 |
+| --sqlserver-conf | SQLServer CDCSource の設定。例: `--sqlserver-conf hostname=127.0.0.1`。すべての設定項目は [SQLServer CDC](https://nightlies.apache.org/flink/flink-cdc-docs-release-3.2/docs/connectors/flink-sources/sqlserver-cdc/) を参照してください。hostname/username/password/database-name/schema-name は必須です。 |
+| --db2-conf | DB2 CDCSource の設定。例: `--db2-conf hostname=127.0.0.1`。すべての設定項目は [DB2 CDC](https://nightlies.apache.org/flink/flink-cdc-docs-release-3.2/docs/connectors/flink-sources/db2-cdc/) を参照してください。hostname/username/password/database-name/schema-name は必須です。 |
+| --mongodb-conf | MongoDB CDCSource の設定。例: `--mongodb-conf hosts=127.0.0.1:27017`。すべての設定項目は [Mongo CDC](https://nightlies.apache.org/flink/flink-cdc-docs-release-3.2/docs/connectors/flink-sources/mongodb-cdc/) を参照してください。hosts/username/password/database は必須です。`--mongodb-conf schema.sample-percent` は MongoDB データを自動サンプリングして Doris テーブルを作成するための設定で、デフォルトは 0.2 です。 |
+| --sink-conf | Doris Sink のすべての設定項目。完全な一覧は [Sink の設定](#sink-configuration) を参照してください。 |
+| --table-conf | Doris テーブルの設定項目。properties 内の内容を指定します（properties 属性ではない table-buckets を除きます）。例: `--table-conf replication_num=1`。`--table-conf table-buckets="tbl1:10,tbl2:20,a.*:30,b.*:40,.*:50"` では、正規表現の順序に従って各テーブルのバケット数を指定します。一致しない場合は `BUCKETS AUTO` を使用してテーブルを作成します。 |
+| --schema-change-mode | スキーマ変更の解析モード。`debezium_structure` と `sql_parser` の二つに対応し、デフォルトは `debezium_structure` です。`debezium_structure` は、上流の CDC データを同期するときに使用されるデータ構造を解析し、DDL 変更操作を判定します。`sql_parser` は、上流の CDC データを同期するときに DDL 文を解析して変更操作を判定するため、より正確です。使用例: `--schema-change-mode debezium_structure`。Connector 24.0.0 以降でサポートされます。 |
+| --single-sink | すべてのテーブルを一つの Sink で同期するかどうか。有効にすると、上流で新規作成されたテーブルも自動検出され、テーブルが自動作成されます。 |
+| --multi-to-one-origin | 複数の上流テーブルを同じテーブルに書き込む場合の、ソーステーブルの設定。例: `--multi-to-one-origin "a_.*\|b_.*"`。詳細は [#208](https://github.com/apache/doris-flink-connector/pull/208) を参照してください。 |
+| --multi-to-one-target | `--multi-to-one-origin` と併用する、ターゲットテーブルの設定。例: `--multi-to-one-target "a\|b"`。 |
+| --create-table-only | テーブル構造のみを同期するかどうか。 |
+
+## データ型の対応関係
+
+### Doris から Flink へ
+
+| Doris の型 | Flink の型 |
+| ---------- | ---------- |
+| NULL_TYPE | NULL |
+| BOOLEAN | BOOLEAN |
+| TINYINT | TINYINT |
+| SMALLINT | SMALLINT |
+| INT | INT |
+| BIGINT | BIGINT |
+| FLOAT | FLOAT |
+| DOUBLE | DOUBLE |
+| DATE | DATE |
+| DATETIME | TIMESTAMP |
+| DECIMAL | DECIMAL |
+| CHAR | STRING |
+| LARGEINT | STRING |
+| VARCHAR | STRING |
+| STRING | STRING |
+| DECIMALV2 | DECIMAL |
+| ARRAY | ARRAY |
+| MAP | STRING |
+| JSON | STRING |
+| VARIANT | STRING |
+| IPV4 | STRING |
+| IPV6 | STRING |
+
+### Flink から Doris へ
+
+| Flink の型 | Doris の型 |
+| ------------- | -------------- |
+| BOOLEAN | BOOLEAN |
+| TINYINT | TINYINT |
+| SMALLINT | SMALLINT |
+| INTEGER | INTEGER |
+| BIGINT | BIGINT |
+| FLOAT | FLOAT |
+| DOUBLE | DOUBLE |
+| DECIMAL | DECIMAL |
+| CHAR | CHAR |
+| VARCHAR | VARCHAR/STRING |
+| STRING | STRING |
+| DATE | DATE |
+| TIMESTAMP | DATETIME |
+| TIMESTAMP_LTZ | DATETIME |
+| ARRAY | ARRAY |
+| MAP | MAP/JSON |
+| ROW | STRUCT/JSON |
+
+## モニタリングメトリクス
+
+Flink は、クラスターの状態を監視するためのさまざまな [Metrics](https://nightlies.apache.org/flink/flink-docs-master/docs/ops/metrics/#metrics) を提供します。Flink Doris Connector が追加するモニタリングメトリクスは次のとおりです。
+
+| 名前 | メトリクスの種類 | 説明 |
+| ------------------------- | ----------- | ---------------------------------------------------- |
+| totalFlushLoadBytes | Counter | フラッシュして取り込んだ合計バイト数。 |
+| flushTotalNumberRows | Counter | 取り込んで処理した合計行数。 |
+| totalFlushLoadedRows | Counter | 正常に取り込んだ合計行数。 |
+| totalFlushTimeMs | Counter | 取り込みが正常に完了するまでにかかった合計時間。 |
+| totalFlushSucceededNumber | Counter | 取り込みが成功した回数。 |
+| totalFlushFailedNumber | Counter | 取り込みが失敗した回数。 |
+| totalFlushFilteredRows | Counter | データ品質の要件を満たさなかった行の合計数。 |
+| totalFlushUnselectedRows | Counter | where 条件によって除外された行の合計数。 |
+| beginTxnTimeMs | Histogram | FE にトランザクション開始を要求するのにかかった時間（ミリ秒）。 |
+| putDataTimeMs | Histogram | FE に取り込みデータの実行プランの取得を要求するのにかかった時間。 |
+| readDataTimeMs | Histogram | データの読み取りにかかった時間。 |
+| writeDataTimeMs | Histogram | データの書き込み処理にかかった時間。 |
+| commitAndPublishTimeMs | Histogram | FE にトランザクションのコミットと公開を要求するのにかかった時間。 |
+| loadTimeMs | Histogram | 取り込みの完了にかかった時間。 |
+
+## ベストプラクティス
+
+### FlinkSQL で CDC を使用して MySQL データをすばやく取り込む
+
+```sql
+-- Enable checkpoint
+SET 'execution.checkpointing.interval' = '10s';
+
+CREATE TABLE cdc_mysql_source (
+ id int,
+ name VARCHAR,
+ PRIMARY KEY (id) NOT ENFORCED
+) WITH (
+ 'connector' = 'mysql-cdc',
+ 'hostname' = '127.0.0.1',
+ 'port' = '3306',
+ 'username' = 'root',
+ 'password' = 'password',
+ 'database-name' = 'database',
+ 'table-name' = 'table'
+);
+
+-- Supports synchronizing insert/update/delete events
+CREATE TABLE doris_sink (
+ id INT,
+ name STRING
+)
+WITH (
+ 'connector' = 'doris',
+ 'fenodes' = '127.0.0.1:8030',
+ 'table.identifier' = 'database.table',
+ 'username' = 'root',
+ 'password' = '',
+ 'sink.properties.format' = 'json',
+ 'sink.properties.read_json_by_line' = 'true',
+ 'sink.enable-delete' = 'true', -- Synchronize delete events
+ 'sink.label-prefix' = 'doris_label'
+);
+
+insert into doris_sink select id, name from cdc_mysql_source;
+```
+
+### Flink で列を部分更新する
+
+```sql
+CREATE TABLE doris_sink (
+ id INT,
+ name STRING,
+ bank STRING,
+ age int
+)
+WITH (
+ 'connector' = 'doris',
+ 'fenodes' = '127.0.0.1:8030',
+ 'table.identifier' = 'database.table',
+ 'username' = 'root',
+ 'password' = '',
+ 'sink.properties.format' = 'json',
+ 'sink.properties.read_json_by_line' = 'true',
+ 'sink.properties.columns' = 'id,name,bank,age', -- Columns to update
+ 'sink.properties.partial_columns' = 'true' -- Enable partial column update
+);
+```
+
+### Flink で Bitmap データを取り込む
+
+```sql
+CREATE TABLE bitmap_sink (
+ dt int,
+ page string,
+ user_id int
+)
+WITH (
+ 'connector' = 'doris',
+ 'fenodes' = '127.0.0.1:8030',
+ 'table.identifier' = 'test.bitmap_test',
+ 'username' = 'root',
+ 'password' = '',
+ 'sink.label-prefix' = 'doris_label',
+ 'sink.properties.columns' = 'dt,page,user_id,user_id=to_bitmap(user_id)'
+)
+```
+
+### Flink CDC でキー列を更新する
+
+業務データベースでは通常、ID をテーブルの主キーとして使用します。たとえば Student テーブルでは ID（id）が主キーです。ただし、業務の変化に伴って、あるデータに対応する ID が変わることがあります。この場合、Flink CDC と Doris Connector を使用してデータを同期すると、Doris の主キー列のデータが自動的に更新されます。
+
+**仕組み**
+
+Flink CDC の基盤となる収集ツールは Debezium です。Debezium は内部で `op` フィールドを使用して操作を識別します。`op` の値 `c`、`u`、`d`、`r` は、それぞれ作成、更新、削除、読み取りを表します。主キー列の更新時には、Flink CDC が下流に DELETE イベントと INSERT イベントを送信します。Doris にデータが同期されると、主キー列のデータが自動的に更新されます。
+
+**使い方**
+
+Flink プログラムは、上記の CDC 同期の例を参照してください。ジョブの送信が成功したら、MySQL 側で主キー列に対して Update 文（例: `update student set id = '1002' where id = '1001'`）を実行すると、Doris のデータを変更できます。
+
+### Flink で指定列の値に基づいてデータを削除する
+
+Kafka のメッセージでは、`{"op_type":"delete",data:{...}}` のように、特定のフィールドで操作の種類を示すことがよくあります。このようなデータでは、`op_type=delete` のレコードを削除したい場合があります。
+
+デフォルトでは、DorisSink は RowKind に基づいてイベントの種類を判別します。CDC ではイベントの種類を直接取得でき、隠し列 `__DORIS_DELETE_SIGN__` に値を割り当てることで削除を実行できます。Kafka の場合は、アプリケーションロジックで値を判断し、隠し列に明示的に渡す必要があります。
+
+```sql
+-- For example, upstream data: {"op_type":"delete",data:{"id":1,"name":"zhangsan"}}
+CREATE TABLE KAFKA_SOURCE(
+ data STRING,
+ op_type STRING
+) WITH (
+ 'connector' = 'kafka',
+ ...
+);
+
+CREATE TABLE DORIS_SINK(
+ id INT,
+ name STRING,
+ __DORIS_DELETE_SIGN__ INT
+) WITH (
+ 'connector' = 'doris',
+ 'fenodes' = '127.0.0.1:8030',
+ 'table.identifier' = 'db.table',
+ 'username' = 'root',
+ 'password' = '',
+ 'sink.enable-delete' = 'false', -- false means do not get the event type from RowKind
+ 'sink.properties.columns' = 'id, name, __DORIS_DELETE_SIGN__' -- Explicitly specify the import columns of Stream Load
+);
+
+INSERT INTO DORIS_SINK
+SELECT json_value(data, '$.id') as id,
+ json_value(data, '$.name') as name,
+ if(op_type = 'delete', 1, 0) as __DORIS_DELETE_SIGN__
+from KAFKA_SOURCE;
+```
+
+### Flink CDC で DDL 文を同期する
+
+MySQL などの上流データソースを同期する場合、上流でフィールドが追加または削除されたら、Doris でも同期して Schema Change 操作を行う必要があります。
+
+この場合、通常は DataStream API プログラムを作成し、DorisSink が提供する `JsonDebeziumSchemaSerializer` を使用してシリアライズします。その後、Schema Change が自動的に実行されます。
+
+Connector が提供するデータベース全体の同期ツールでは、追加設定なしで上流の DDL が自動同期され、Doris で Schema Change 操作が実行されます。
+
+## よくある質問（FAQ）
+
+**1. errCode = 2, detailMessage = Label [label_0_1] has already been used, relate to txn [19650]**
+
+Exactly-Once を使用する場合、Flink ジョブの再起動時には最新の Checkpoint/Savepoint から開始する必要があります。そうしないと、上記のエラーが発生します。Exactly-Once が不要な場合は、2PC コミットを無効化する（`sink.enable-2pc=false`）か、別の `sink.label-prefix` を使用して解決することもできます。
+
+**2. errCode = 2, detailMessage = transaction [19650] not found**
+
+このエラーは Commit フェーズで発生します。Checkpoint に記録されたトランザクション ID が FE 側で期限切れになっているため、この時点で再度コミットすると上記のエラーが発生します。この場合、その Checkpoint から開始することはできません。`streaming_label_keep_max_second` の設定を `fe.conf` で変更すると、有効期間（デフォルトは 12 時間）を延長できます。Doris 2.0 以降では、`label_num_threshold` の設定による制限も `fe.conf` で適用されます（デフォルトは 2000）。この値を増やすか、-1 に設定できます（-1 は時間の制限のみを適用することを意味します）。
+
+**3. errCode = 2, detailMessage = current running txns on db 10006 is 100, larger than limit 100**
+
+このエラーは、同じデータベースへの同時取り込みが 100 件を超えると発生します。`max_running_txn_num_per_db` パラメーターを `fe.conf` で調整して解決できます。詳細は [max_running_txn_num_per_db](../../admin-manual/config/fe-config.md#max_running_txn_num_per_db) を参照してください。また、ラベルを頻繁に変更してジョブを再起動した場合も発生することがあります。2pc を使用する場合（Duplicate/Aggregate モデル）、各ジョブのラベルは一意である必要があります。Flink ジョブが、以前にプリコミットに成功したものの未コミットのトランザクションを自動的に中止するのは、Checkpoint から再起動した場合だけです。ラベルを頻繁に変更して再起動すると、プリコミット済みトランザクションが大量に残って中止できず、トランザクション枠を占有します。Unique モデル
では 2pc を無効にして冪等書き込みを実現することもできます。
+
+**4. tablet writer write failed, tablet_id=190958, txn_id=3505530, err=-235**
+
+通常、この問題は Connector 1.1.0 より前で発生します。書き込み頻度が高すぎてバージョン数が増えすぎることが原因です。`sink.batch.size` と `sink.batch.interval` パラメーターを設定し、Stream Load の実行頻度を下げられます。Connector 1.1.0 以降では、デフォルトの書き込みタイミングが Checkpoint によって制御されるため、Checkpoint 間隔を長くすることで書き込み頻度を下げられます。
+
+**5. Flink の取り込みデータに不正なデータがある場合、どのようにスキップしますか？**
+
+Flink でデータを取り込む際、フィールドの形式や長さの問題などによる不正なデータがあると、Stream Load がエラーを報告し、Flink は再試行を続けます。スキップするには、Stream Load の厳格モードを無効にする（`strict_mode=false`、`max_filter_ratio=1`）か、Sink オペレーターの前にデータをフィルタリングします。
+
+**6. Flink マシンと BE マシンがネットワークで接続できない場合は、どう設定しますか？**
+
+Flink が Doris への書き込みを開始すると、Doris は書き込み先を BE にリダイレクトします。このとき返されるアドレスは BE の内部 IP（`show backends` で確認できる IP）です。Flink と Doris が通信できない場合はエラーになります。この場合、`benodes` に BE の外部 IP を設定できます。
+
+**7. stream load error: HTTP/1.1 307 Temporary Redirect**
+
+Flink は最初に FE へリクエストを送信し、307 応答を受け取るとリダイレクト先の BE にリクエストを送信します。FE が FullGC 中、高負荷状態、またはネットワーク遅延がある場合、デフォルトでは HttpClient は一定時間（3 秒）応答を受信しないとデータを送信します。リクエスト本文はデフォルトで InputStream のため、307 応答を受け取ってもデータを再送できず、そのままエラーになります。対処方法は次の三つです。
+
+1. Connector 25.1.0 以降にアップグレードします。このバージョンではデフォルトの待機時間が延長されています。
+2. `auto-redirect=false` を設定して BE に直接リクエストを送信します（一部のクラウド環境では使用できません）。
+3. 主キーモデルではバッチモードを有効にできます。
diff --git a/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/fluentbit.md b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/fluentbit.md
new file mode 100644
index 00000000000..71e9204c27d
--- /dev/null
+++ b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/fluentbit.md
@@ -0,0 +1,406 @@
+---
+{
+ "title": "Fluent Bit",
+ "language": "ja",
+ "description": "Fluent Bit Doris Output Plugin を使用し、Stream Load 経由で TEXT および JSON ログを Apache Doris にリアルタイムで書き込む方法を説明します。",
+ "keywords": [
+ "Fluent Bit",
+ "Doris Stream Load",
+ "ログ収集",
+ "Doris へのログ書き込み",
+ "Fluent Bit Doris Output Plugin"
+ ]
+}
+---
+
+<!-- Knowledge type: One-sentence definition -->
+<!-- Applicable scenario: Use Fluent Bit to write logs into Apache Doris in real time -->
+
+[Fluent Bit](https://fluentbit.io/) は、高速なログ処理・転送ツールです。カスタム出力プラグインを通じてストレージシステムにデータを書き込めます。Fluent Bit Doris Output Plugin は、Fluent Bit から Doris にデータを書き込む出力プラグインです。[Doris Stream Load](../../data-operate/import/import-way/stream-load-manual) の HTTP インターフェースを呼び出し、Doris にデータをリアルタイムで書き込みます。
+
+主な機能は次のとおりです。
+
+- 複数スレッドによる並行書き込み。
+- Doris Stream Load リクエストが失敗した場合の再試行。
+- Stream Load のフォーマットとパラメータのカスタマイズ。
+- 書き込み速度の統計情報の出力。
+
+## 適用シナリオと導入手順 {#applicable-scenarios-and-onboarding-flow}
+
+<!-- Knowledge type: Architecture selection decision -->
+<!-- Applicable scenario: Choosing a log collection solution -->
+
+ログの種類に応じて、次の連携方法を選択できます。
+
+| ユーザーのシナリオ | 推奨方法 | このドキュメントの例 |
+| --- | --- | --- |
+| `stacktrace` を含む TEXT ログを収集する | `tail` 入力、マルチラインパーサー、ログフィールドパーサーを使用し、複数行のログを単一のレコードにまとめてから Doris に書き込む | [Doris FE の TEXT ログを収集する](#collect-doris-fe-text-logs) |
+| 単一行の JSON イベントログを収集する | `tail` 入力と JSON パーサーを使用し、JSON レコードを Doris に直接書き込む | [JSON ログを収集する](#collect-json-logs) |
+
+Fluent Bit Doris Output Plugin を使用して Doris と連携する基本的な手順は次のとおりです。
+
+1. Doris Output Plugin を含む Fluent Bit のバイナリをダウンロードするか、コンパイルします。
+2. ログの種類に応じて、Fluent Bit の入力、パーサー、Doris 出力のパラメータを設定します。
+3. Fluent Bit を起動し、ログを Doris にリアルタイムで書き込みます。
+
+## Fluent Bit Doris Output Plugin のインストール（アルファ版） {#install-the-fluent-bit-doris-output-plugin-alpha-version}
+
+<!-- Knowledge type: Operation steps -->
+<!-- Applicable scenario: Prepare the runtime environment for the Fluent Bit Doris Output Plugin -->
+
+ビルド済みのバイナリを直接ダウンロードするか、ソースからビルドできます。
+
+### 公式サイトからダウンロードする {#download-from-the-official-site}
+
+[fluent-bit-doris-3.1.9](https://apache-doris-releases.oss-accelerate.aliyuncs.com/integrations/fluent-bit-doris-3.1.9) をダウンロードします。
+
+### ソースからビルドする {#build-from-source}
+
+`dev` ブランチの [fluent-bit](https://github.com/joker-star-l/fluent-bit) リポジトリをクローンし、`build/` ディレクトリで次のコマンドを実行します。
+
+```shell
+cmake -DFLB_RELEASE=ON ..
+make
+```
+
+ビルド成果物は `build/bin/fluent-bit` です。
+
+## Doris 出力パラメータの設定 {#configure-doris-output-parameters}
+
+<!-- Knowledge type: Configuration parameters -->
+<!-- Applicable scenario: Configure Fluent Bit to write to Doris -->
+
+Fluent Bit Doris Output Plugin の設定項目は次のとおりです。
+
+| 設定項目 | 説明 |
+| --- | --- |
+| `host` | Stream Load の HTTP ホスト。 |
+| `port` | Stream Load の HTTP ポート。 |
+| `user` | Doris のユーザー名。このユーザーには、対象のデータベースとテーブルに対するインポート権限が必要です。 |
+| `password` | Doris ユーザーのパスワード。 |
+| `database` | 書き込み先の Doris データベース名。 |
+| `table` | 書き込み先の Doris テーブル名。 |
+| `label_prefix` | Doris Stream Load のラベルのプレフィックス。最終的に生成されるラベルは `{label_prefix}_{timestamp}_{uuid}` です。デフォルト値は `fluentbit` です。`false` に設定すると、ラベルは付加されません。 |
+| `time_key` | データに追加するタイムスタンプ列の名前。デフォルト値は `date` です。`false` に設定すると、この列は追加されません。 |
+| `header` | Doris Stream Load のヘッダーパラメータ。複数の値を設定できます。 |
+| `log_request` | トラブルシューティングに使用する Doris Stream Load リクエストとレスポンスのメタデータをログに出力するかどうか。デフォルト値は `true` です。 |
+| `log_progress_interval` | 書き込み速度をログに出力する間隔（秒）。デフォルト値は `10` です。`0` に設定すると、このログ出力は無効になります。 |
+| `retry_limit` | Doris Stream Load リクエストの失敗後に再試行する回数。デフォルト値は `1` です。`false` に設定すると、再試行回数は無制限になります。 |
+| `workers` | Doris Stream Load を実行するワーカーの数。デフォルト値は `2` です。 |
+
+## Doris FE の TEXT ログを収集する {#collect-doris-fe-text-logs}
+
+<!-- Knowledge type: Operation steps -->
+<!-- Applicable scenario: Collect multi-line Java logs and write them to Doris -->
+
+このシナリオでは、Doris FE のログを例に TEXT ログの収集方法を示します。`stacktrace` を含む複数行の例外ログでは、まずメインのログと `stacktrace` を単一のレコードにまとめ、次にフィールドを解析して Doris に書き込む必要があります。
+
+### 1. ログのサンプルを準備する {#1-prepare-a-log-sample}
+
+FE のログファイルは通常、Doris のインストールディレクトリ内の `fe/log/fe.log` にあります。これは一般的な Java プログラムのログで、タイムスタンプ、ログレベル、スレッド名、コードの位置、ログの内容などのフィールドを含みます。通常のログエントリに加え、`stacktrace` を含む例外エントリもあります。`stacktrace` は複数行にまたがるため、ログ収集時にメインのログと `stacktrace` を単一のログエントリにまとめる必要があります。
+
+```text
+2024-07-08 21:18:01,432 INFO (Statistics Job Appender|61) [StatisticsJobAppender.runAfterCatalogReady():70] Stats table not available, skip
+2024-07-08 21:18:53,710 WARN (STATS_FETCH-0|208) [StmtExecutor.executeInternalQuery():3332] Failed to run internal SQL: OriginStatement{originStmt='SELECT * FROM __internal_schema.column_statistics WHERE part_id is NULL ORDER BY update_time DESC LIMIT 500000', idx=0}
+org.apache.doris.common.UserException: errCode = 2, detailMessage = tablet 10031 has no queryable replicas. err: replica 10032's backend 10008 does not exist or not alive
+ at org.apache.doris.planner.OlapScanNode.addScanRangeLocations(OlapScanNode.java:931) ~[doris-fe.jar:1.2-SNAPSHOT]
+ at org.apache.doris.planner.OlapScanNode.computeTabletInfo(OlapScanNode.java:1197) ~[doris-fe.jar:1.2-SNAPSHOT]
+```
+
+### 2. Doris テーブルを作成する {#2-create-a-doris-table}
+
+テーブルのスキーマには、ログの生成時刻、収集時刻、ホスト名、ログファイルのパス、ログの種類、ログレベル、スレッド名、コードの位置、ログの内容などのフィールドが含まれます。
+
+```sql
+CREATE TABLE `doris_log` (
+ `log_time` datetime NULL COMMENT 'log content time',
+ `collect_time` datetime NULL COMMENT 'log agent collect time',
+ `host` text NULL COMMENT 'hostname or ip',
+ `path` text NULL COMMENT 'log file path',
+ `type` text NULL COMMENT 'log type',
+ `level` text NULL COMMENT 'log level',
+ `thread` text NULL COMMENT 'log thread',
+ `position` text NULL COMMENT 'log code position',
+ `message` text NULL COMMENT 'log message',
+ INDEX idx_host (`host`) USING INVERTED COMMENT '',
+ INDEX idx_path (`path`) USING INVERTED COMMENT '',
+ INDEX idx_type (`type`) USING INVERTED COMMENT '',
+ INDEX idx_level (`level`) USING INVERTED COMMENT '',
+ INDEX idx_thread (`thread`) USING INVERTED COMMENT '',
+ INDEX idx_position (`position`) USING INVERTED COMMENT '',
+ INDEX idx_message (`message`) USING INVERTED PROPERTIES("parser" = "unicode", "support_phrase" = "true") COMMENT ''
+) ENGINE=OLAP
+DUPLICATE KEY(`log_time`)
+COMMENT 'OLAP'
+PARTITION BY RANGE(`log_time`) ()
+DISTRIBUTED BY RANDOM BUCKETS 10
+PROPERTIES (
+ "replication_num" = "1",
+ "dynamic_partition.enable" = "true",
+ "dynamic_partition.time_unit" = "DAY",
+ "dynamic_partition.start" = "-7",
+ "dynamic_partition.end" = "1",
+ "dynamic_partition.prefix" = "p",
+ "dynamic_partition.buckets" = "10",
+ "dynamic_partition.create_history_partition" = "true",
+ "compaction_policy" = "time_series"
+);
+```
+
+### 3. Fluent Bit を設定する {#3-configure-fluent-bit}
+
+このシナリオでは、次の二つの設定ファイルが必要です。
+
+| 設定ファイル | 用途 |
+| --- | --- |
+| `doris_log.conf` | Fluent Bit の Service、入力、フィルター、Doris 出力を定義します。 |
+| `parsers.conf` | マルチラインログパーサーと FE ログのフィールドパーサーを定義します。 |
+
+`doris_log.conf`:
+
+```ini
+# config for Fluent Bit service
+[SERVICE]
+ log_level info
+ # parsers file
+ parsers_file parsers.conf
+
+# use input tail
+[INPUT]
+ name tail
+ path /path/to/your/log
+ # add log file name to the record, key is 'path'
+ path_key path
+ # set multiline parser
+ multiline.parser multiline_java
+
+# parse log
+[FILTER]
+ match *
+ name parser
+ key_name log
+ parser fe_log
+ reserve_data true
+
+# add host info
+[FILTER]
+ name sysinfo
+ match *
+ # add hostname to the record, key is 'host'
+ hostname_key host
+
+# output to doris
+[OUTPUT]
+ name doris
+ match *
+ host fehost
+ port feport
+ user your_username
+ password your_password
+ database your_db
+ table your_table
+ # add 'collect_time' to the record
+ time_key collect_time
+ # 'collect_time' is timestamp, change it to datatime
+ header columns collect_time=from_unixtime(collect_time)
+ log_request true
+ log_progress_interval 10
+```
+
+`parsers.conf`:
+
+```ini
+[MULTILINE_PARSER]
+ name multiline_java
+ type regex
+ flush_timeout 1000
+ # Regex rules for multiline parsing
+ # ---------------------------------
+ #
+ # configuration hints:
+ #
+ # - first state always has the name: start_state
+ # - every field in the rule must be inside double quotes
+ #
+ # rules | state name | regex pattern | next state name
+ # --------|----------------|---------------|-----------------
+ rule "start_state" "/(^[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2})(.*)/" "cont"
+ rule "cont" "/(^(?![0-9]{4}-[0-9]{2}-[0-9]{2}))(.*)/" "cont"
+
+
+[PARSER]
+ name fe_log
+ format regex
+ # parse and add 'log_time', 'level', 'thread', 'position', 'message' to the record
+ regex ^(?<log_time>[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2},[0-9]{3}) (?<level>[^ ]+) \((?<thread>[^\)]+)\) \[(?<position>[^\]]+)\] (?<message>(\n|.)*)\n$
+```
+
+### 4. Fluent Bit を起動して書き込み結果を確認する {#4-start-fluent-bit-and-check-the-write-results}
+
+```shell
+fluent-bit -c doris_log.conf
+```
+
+ログには Stream Load のレスポンスメタデータが出力されます。
+
+```text
+[2024/10/31 18:39:55] [ info] [output:doris:doris.1] 127.0.0.1:8040, HTTP status=200
+{
+ "TxnId": 32155,
+ "Label": "fluentbit_1730371195_91cca1aa-c15f-45d2-b503-fe7d2e839c2a",
+ "Comment": "",
+ "TwoPhaseCommit": "false",
+ "Status": "Success",
+ "Message": "OK",
+ "NumberTotalRows": 1,
+ "NumberLoadedRows": 1,
+ "NumberFilteredRows": 0,
+ "NumberUnselectedRows": 0,
+ "LoadBytes": 836,
+ "LoadTimeMs": 298,
+ "BeginTxnTimeMs": 0,
+ "StreamLoadPutTimeMs": 3,
+ "ReadDataTimeMs": 0,
+ "WriteDataTimeMs": 268,
+ "CommitAndPublishTimeMs": 25
+}
+```
+
+ログには書き込み速度も出力されます。
+
+```text
+[2024/10/31 18:40:13] [ info] [output:doris:doris.1] total 0 MB 2 ROWS, total speed 0 MB/s 0 R/s, last 10 seconds speed 0 MB/s 0 R/s
+```
+
+## JSON ログを収集する {#collect-json-logs}
+
+<!-- Knowledge type: Operation steps -->
+<!-- Applicable scenario: Collect single-line JSON event logs and write them to Doris -->
+
+このシナリオでは、GitHub Events Archive のデータを例に JSON ログの収集方法を示します。TEXT ログの収集とは異なり、JSON ログでは処理や変換のための追加の `FILTER` は必要ありません。
+
+### 1. データを準備する {#1-prepare-data}
+
+[GitHub Events Archive](https://www.gharchive.org/) は、GitHub ユーザーのアクションイベントを JSON 形式で保存したアーカイブデータです。次の例では、2024 年 1 月の初日、15:00 のデータをダウンロードします。
+
+```shell
+wget https://data.gharchive.org/2024-01-01-15.json.gz
+```
+
+実際のデータは、各行に JSON オブジェクトが一つずつ記録されています。次に、整形したデータのサンプルを示します。
+
+```json
+{
+ "id": "37066529221",
+ "type": "PushEvent",
+ "actor": {
+ "id": 46139131,
+ "login": "Bard89",
+ "display_login": "Bard89",
+ "gravatar_id": "",
+ "url": "https://api.github.com/users/Bard89",
+ "avatar_url": "https://avatars.githubusercontent.com/u/46139131?"
+ },
+ "repo": {
+ "id": 780125623,
+ "name": "Bard89/talk-to-me",
+ "url": "https://api.github.com/repos/Bard89/talk-to-me"
+ },
+ "payload": {
+ "repository_id": 780125623,
+ "push_id": 17799451992,
+ "size": 1,
+ "distinct_size": 1,
+ "ref": "refs/heads/add_mvcs",
+ "head": "f03baa2de66f88f5f1754ce3fa30972667f87e81",
+ "before": "85e6544ede4ae3f132fe2f5f1ce0ce35a3169d21"
+ },
+ "public": true,
+ "created_at": "2024-04-01T23:00:00Z"
+}
+```
+
+### 2. Doris テーブルを作成する {#2-create-a-doris-table-1}
+
+```sql
+CREATE TABLE github_events
+(
+ `created_at` DATETIME,
+ `id` BIGINT,
+ `type` TEXT,
+ `public` BOOLEAN,
+ `actor` VARIANT,
+ `repo` VARIANT,
+ `payload` TEXT,
+ INDEX `idx_id` (`id`) USING INVERTED,
+ INDEX `idx_type` (`type`) USING INVERTED,
+ INDEX `idx_actor` (`actor`) USING INVERTED,
+ INDEX `idx_host` (`repo`) USING INVERTED,
+ INDEX `idx_payload` (`payload`) USING INVERTED PROPERTIES("parser" = "unicode", "support_phrase" = "true")
+)
+ENGINE = OLAP
+DUPLICATE KEY(`created_at`)
+PARTITION BY RANGE(`created_at`) ()
+DISTRIBUTED BY RANDOM BUCKETS 10
+PROPERTIES (
+ "replication_num" = "1",
+ "compaction_policy" = "time_series",
+ "dynamic_partition.enable" = "true",
+ "dynamic_partition.create_history_partition" = "true",
+ "dynamic_partition.time_unit" = "DAY",
+ "dynamic_partition.start" = "-30",
+ "dynamic_partition.end" = "1",
+ "dynamic_partition.prefix" = "p",
+ "dynamic_partition.buckets" = "10",
+ "dynamic_partition.replication_num" = "1"
+);
+```
+
+### 3. Fluent Bit を設定する {#3-configure-fluent-bit-1}
+
+このシナリオでは、次の二つの設定ファイルが必要です。
+
+| 設定ファイル | 用途 |
+| --- | --- |
+| `github_events.conf` | Fluent Bit の Service、入力、Doris 出力を定義します。 |
+| `github_parsers.conf` | JSON パーサーを定義します。 |
+
+`github_events.conf`:
+
+```ini
+[SERVICE]
+ log_level info
+ parsers_file github_parsers.conf
+
+[INPUT]
+ name tail
+ parser github
+ path /path/to/your/log
+
+[OUTPUT]
+ name doris
+ match *
+ host fehost
+ port feport
+ user your_username
+ password your_password
+ database your_db
+ table your_table
+ time_key false
+ log_request true
+ log_progress_interval 10
+```
+
+`github_parsers.conf`:
+
+```ini
+[PARSER]
+ name github
+ format json
+```
+
+### 4. Fluent Bit を起動する {#4-start-fluent-bit}
+
+```shell
+fluent-bit -c github_events.conf
+```
diff --git a/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/hive-udf.md b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/hive-udf.md
new file mode 100644
index 00000000000..8aa529c8c49
--- /dev/null
+++ b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/hive-udf.md
@@ -0,0 +1,352 @@
+---
+{
+ "title": "Hive の Bitmap/HLL UDF",
+ "language": "ja",
+ "description": "Hive で Bitmap と HLL を生成・操作する UDF。結果を Doris に直接ロードできるため、辞書の構築や事前集約を Doris 側で行う必要がなくなり、ロード時間とストレージコストを削減できます。"
+}
+---
+
+Doris は、Hive テーブルで Bitmap と HLL を直接生成・操作するための Hive UDF を提供します。Hive で生成した Bitmap と HLL は Doris カーネルと完全に互換性があり、Hive Catalog または Spark Load を使って Doris に直接ロードできます。
+
+HLL の詳細については、[HLL による近似重複排除](../../query-acceleration/distinct-counts/hll-approximate-deduplication)を参照してください。
+
+## ユースケース
+
+| シナリオ | 利点 |
+| --------------------------------------- | -------------------------------------------------------------------------------------------------------- |
+| Doris へのデータロード時間を短縮する | 辞書の構築と事前集約を Hive 側で完了するため、Doris へのロード時に再構築する必要がありません |
+| Hive と Doris のストレージコストを削減する | Bitmap と HLL が元データを圧縮します。通常、HLL のストレージ使用量は Bitmap より大幅に少なくなります |
+| Hive で柔軟に計算する | Bitmap の積集合・和集合・差集合、HLL の和集合・カーディナリティ推定に対応します。結果を Doris に直接ロードできます |
+
+:::tip
+HLL は近似アルゴリズムであり、通常、結果には正確な値と比べて 1%～2% の誤差があります。高い精度が必要な場合は Bitmap を使用してください。
+:::
+
+## 関数一覧
+
+<!-- Knowledge type: Function reference -->
+
+### Bitmap の UDF
+
+| 関数 | 種別 | 説明 |
+| ---------------- | ----- | ------------------------------------ |
+| `to_bitmap` | UDAF | 集約して Doris Bitmap の列を生成します |
+| `bitmap_union` | UDAF | グループ内の Bitmap の和集合を計算します |
+| `bitmap_count` | UDF | Bitmap の要素数を返します |
+| `bitmap_and` | UDF | 二つの Bitmap の積集合を計算します |
+| `bitmap_or` | UDF | 二つの Bitmap の和集合を計算します |
+| `bitmap_xor` | UDF | 二つの Bitmap の対称差集合を計算します |
+
+### HLL の UDF
+
+| 関数 | 種別 | 説明 |
+| ----------------- | ----- | ------------------------------------------------------------ |
+| `to_hll` | UDAF | `to_bitmap` と同様に、集約して Doris HLL の列を生成します |
+| `hll_union` | UDAF | `bitmap_union` と同様に、グループ内の HLL の和集合を計算します |
+| `hll_cardinality` | UDF | `bitmap_count` と同様に、HLL 内の異なる要素の概数を返します |
+
+## 使用手順
+
+<!-- Knowledge type: Operation steps -->
+
+全体の手順は次の四つのステップです。
+
+1. `hive-udf.jar` をビルドして HDFS にアップロードします。
+2. Hive で JAR をロードし、UDF を登録します。
+3. Hive で UDF を使って Bitmap または HLL を生成・操作します。
+4. Hive Catalog または Spark Load を使って結果を Doris にロードします。
+
+### ステップ 1: UDF JAR をビルドする
+
+Hive Bitmap と HLL の UDF は Hive / Spark で使用するため、まず Doris FE モジュールをビルドして `hive-udf.jar` を取得する必要があります。
+
+```bash
+# 1. Clone the Doris source code
+git clone https://github.com/apache/doris.git
+cd doris
+git submodule update --init --recursive
+
+# 2. Enter the fe directory
+cd fe
+
+# 3. Run maven package (all submodules of fe will be packaged)
+mvn package -Dmaven.test.skip=true
+
+# You can also package only the hive-udf module
+mvn package -pl hive-udf -am -Dmaven.test.skip=true
+
+# 4. After packaging, hive-udf.jar will be generated under hive-udf/target
+# Upload it to HDFS (here uploading to the root directory as an example)
+hdfs dfs -put hive-udf/target/hive-udf.jar /
+```
+
+### ステップ 2: Hive で JAR をロードし、UDF を登録する
+
+Hive に接続し、HDFS の `hostname` と `port` を実際の環境に合わせて変更してください。
+
+```sql
+-- Load the UDF JAR
+add jar hdfs://hostname:port/hive-udf.jar;
+
+-- Register Bitmap UDAFs
+create temporary function to_bitmap as 'org.apache.doris.udf.ToBitmapUDAF' USING JAR 'hdfs://hostname:port/hive-udf.jar';
+create temporary function bitmap_union as 'org.apache.doris.udf.BitmapUnionUDAF' USING JAR 'hdfs://hostname:port/hive-udf.jar';
+
+-- Register Bitmap UDFs
+create temporary function bitmap_count as 'org.apache.doris.udf.BitmapCountUDF' USING JAR 'hdfs://hostname:port/hive-udf.jar';
+create temporary function bitmap_and as 'org.apache.doris.udf.BitmapAndUDF' USING JAR 'hdfs://hostname:port/hive-udf.jar';
+create temporary function bitmap_or as 'org.apache.doris.udf.BitmapOrUDF' USING JAR 'hdfs://hostname:port/hive-udf.jar';
+create temporary function bitmap_xor as 'org.apache.doris.udf.BitmapXorUDF' USING JAR 'hdfs://hostname:port/hive-udf.jar';
+
+-- Register HLL UDAFs
+create temporary function to_hll as 'org.apache.doris.udf.ToHllUDAF' USING JAR 'hdfs://hostname:port/hive-udf.jar';
+create temporary function hll_union as 'org.apache.doris.udf.HllUnionUDAF' USING JAR 'hdfs://hostname:port/hive-udf.jar';
+
+-- Register HLL UDF
+create temporary function hll_cardinality as 'org.apache.doris.udf.HllCardinalityUDF' USING JAR 'hdfs://hostname:port/hive-udf.jar';
+```
+
+### ステップ 3: Hive で生成・計算する
+
+#### テストデータの準備
+
+```sql
+use hive_test;
+
+-- Regular Hive table that stores raw data
+CREATE TABLE IF NOT EXISTS `hive_table`(
+ `k1` int COMMENT '',
+ `k2` String COMMENT '',
+ `k3` String COMMENT '',
+ `uuid` int COMMENT ''
+) COMMENT 'source table';
+
+insert into hive_table select 1, 'a', 'b', 12345;
+insert into hive_table select 1, 'a', 'c', 12345;
+insert into hive_table select 2, 'b', 'c', 23456;
+insert into hive_table select 3, 'c', 'd', 34567;
+```
+
+#### Bitmap の例
+
+```sql
+-- Create a Hive Bitmap table; the binary column stores the Bitmap
+CREATE TABLE IF NOT EXISTS `hive_bitmap_table`(
+ `k1` int COMMENT '',
+ `k2` String COMMENT '',
+ `k3` String COMMENT '',
+ `uuid` binary COMMENT 'bitmap'
+) COMMENT 'bitmap table';
+
+-- Aggregate and generate Bitmap with to_bitmap, then write into the Hive Bitmap table
+insert into hive_bitmap_table
+select
+ k1,
+ k2,
+ k3,
+ to_bitmap(uuid) as uuid
+from hive_table
+group by k1, k2, k3;
+
+-- Count the number of elements in the Bitmap
+select k1, k2, k3, bitmap_count(uuid) from hive_bitmap_table;
+
+-- Compute the Bitmap union after grouping
+select k1, bitmap_union(uuid) from hive_bitmap_table group by k1;
+```
+
+#### HLL の例
+
+```sql
+-- Create a Hive HLL table; the binary column stores the HLL
+CREATE TABLE IF NOT EXISTS `hive_hll_table`(
+ `k1` int COMMENT '',
+ `k2` String COMMENT '',
+ `k3` String COMMENT '',
+ `uuid` binary COMMENT 'hll'
+) COMMENT 'hll table';
+
+-- Aggregate and generate HLL with to_hll, then write into the Hive HLL table
+insert into hive_hll_table
+select
+ k1,
+ k2,
+ k3,
+ to_hll(uuid) as uuid
+from hive_table
+group by k1, k2, k3;
+
+-- Count the number of elements in the HLL
+select k1, k2, k3, hll_cardinality(uuid) from hive_hll_table;
++-----+-----+-----+------+
+| k1 | k2 | k3 | _c3 |
++-----+-----+-----+------+
+| 1 | a | b | 1 |
+| 1 | a | c | 1 |
+| 2 | b | c | 1 |
+| 3 | c | d | 1 |
++-----+-----+-----+------+
+
+-- Compute the HLL union after grouping (returns 3 rows)
+select k1, hll_union(uuid) from hive_hll_table group by k1;
+
+-- You can also merge first and then count
+select k3, hll_cardinality(hll_union(uuid)) from hive_hll_table group by k3;
++-----+------+
+| k3 | _c1 |
++-----+------+
+| b | 1 |
+| c | 2 |
+| d | 1 |
++-----+------+
+```
+
+### ステップ 4: Hive の Bitmap / HLL を Doris にロードする
+
+<!-- Knowledge type: Operation steps -->
+<!-- Applicable scenario: Hive already has Bitmap / HLL data and needs to be written into a Doris internal table -->
+
+**推奨方法: Hive Catalog**
+
+Hive テーブルが `TEXT` 形式で保存されている場合、`binary` 型は Base64 エンコードされた文字列として保存されます。Hive Catalog を使うと、[`bitmap_from_base64`](../../sql-manual/sql-functions/scalar-functions/bitmap-functions/bitmap-from-base64) または [`hll_from_base64`](../../sql-manual/sql-functions/scalar-functions/hll-functions/hll-from-base64) 関数を使って、データを Doris の内部テーブルに直接書き込めます。
+
+一連の手順は次のとおりです。
+
+1. Hive で `TEXTFILE` 形式のテーブルを作成します。
+2. Doris で [Hive Catalog](../../lakehouse/catalogs/hive-catalog) を作成します。
+3. Doris で対応する Bitmap / HLL 内部テーブルを作成します。
+4. `INSERT INTO ... SELECT` を使って Hive から Doris にデータを書き込みます。
+
+#### Bitmap の一連の例
+
+**1. Hive で TEXT 形式のテーブルを作成する**
+
+```sql
+CREATE TABLE IF NOT EXISTS `test`.`hive_bitmap_table`(
+ `k1` int COMMENT '',
+ `k2` String COMMENT '',
+ `k3` String COMMENT '',
+ `uuid` binary COMMENT 'bitmap'
+) STORED AS TEXTFILE;
+```
+
+**2. Doris で Hive Catalog を作成する**
+
+```sql
+CREATE CATALOG hive PROPERTIES (
+ 'type' = 'hms',
+ 'hive.metastore.uris' = 'thrift://127.0.0.1:9083'
+);
+```
+
+**3. Doris で Bitmap 内部テーブルを作成する**
+
+```sql
+CREATE TABLE IF NOT EXISTS `test`.`doris_bitmap_table`(
+ `k1` int COMMENT '',
+ `k2` String COMMENT '',
+ `k3` String COMMENT '',
+ `uuid` BITMAP BITMAP_UNION COMMENT 'bitmap'
+)
+AGGREGATE KEY(k1, k2, k3)
+DISTRIBUTED BY HASH(`k1`) BUCKETS 1
+PROPERTIES (
+ "replication_allocation" = "tag.location.default: 1"
+);
+```
+
+**4. Catalog を使って Hive から Doris にデータを書き込む**
+
+```sql
+insert into test.doris_bitmap_table
+select k1, k2, k3, bitmap_from_base64(uuid)
+from hive.test.hive_bitmap_table;
+```
+
+#### HLL の一連の例
+
+**1. Hive で TEXT 形式のテーブルを作成する**
+
+```sql
+CREATE TABLE IF NOT EXISTS `hive_hll_table`(
+ `k1` int COMMENT '',
+ `k2` String COMMENT '',
+ `k3` String COMMENT '',
+ `uuid` binary COMMENT 'hll'
+) STORED AS TEXTFILE;
+
+-- You can reuse the previous steps and write data from a regular table using the to_hll function
+```
+
+**2. Doris で Hive Catalog を作成する**
+
+```sql
+CREATE CATALOG hive PROPERTIES (
+ 'type' = 'hms',
+ 'hive.metastore.uris' = 'thrift://127.0.0.1:9083'
+);
+```
+
+**3. Doris で HLL 内部テーブルを作成する**
+
+```sql
+CREATE TABLE IF NOT EXISTS `doris_test`.`doris_hll_table`(
+ `k1` int COMMENT '',
+ `k2` varchar(10) COMMENT '',
+ `k3` varchar(10) COMMENT '',
+ `uuid` HLL HLL_UNION COMMENT 'hll'
+)
+AGGREGATE KEY(k1, k2, k3)
+DISTRIBUTED BY HASH(`k1`) BUCKETS 1
+PROPERTIES (
+ "replication_allocation" = "tag.location.default: 1"
+);
+```
+
+**4. Catalog を使って Hive から Doris にデータを書き込む**
+
+```sql
+insert into doris_test.doris_hll_table
+select k1, k2, k3, hll_from_base64(uuid)
+from hive.hive_test.hive_hll_table;
+
+-- View the loaded results, can be combined with hll_to_base64 for decoding
+select *, hll_to_base64(uuid) from doris_test.doris_hll_table;
++------+------+------+------+---------------------+
+| k1 | k2 | k3 | uuid | hll_to_base64(uuid) |
++------+------+------+------+---------------------+
+| 1 | a | b | NULL | AQFw+a9MhpKhoQ== |
+| 1 | a | c | NULL | AQFw+a9MhpKhoQ== |
+| 2 | b | c | NULL | AQGyB7kbWBxh+A== |
+| 3 | c | d | NULL | AQFYbJB5VpNBhg== |
++------+------+------+------+---------------------+
+
+-- Use native HLL functions on the Doris internal table; the result is consistent with Hive
+select k3, hll_cardinality(hll_union(uuid)) from doris_test.doris_hll_table group by k3;
++------+----------------------------------+
+| k3 | hll_cardinality(hll_union(uuid)) |
++------+----------------------------------+
+| b | 1 |
+| d | 1 |
+| c | 2 |
++------+----------------------------------+
+
+-- Query the Hive external table directly (data before loading) for cross-validation to confirm consistency
+select k3, hll_cardinality(hll_union(hll_from_base64(uuid)))
+from hive.hive_test.hive_hll_table
+group by k3;
++------+---------------------------------------------------+
+| k3 | hll_cardinality(hll_union(hll_from_base64(uuid))) |
++------+---------------------------------------------------+
+| d | 1 |
+| b | 1 |
+| c | 2 |
++------+---------------------------------------------------+
+```
+
+## 注意事項
+
+- **HLL の精度**: HLL は近似アルゴリズムであり、通常、結果には正確な値と比べて 1%～2% の誤差があります。高い精度が必要な場合は Bitmap を使用してください。
+- **保存形式**: Hive Catalog 経由でロードする場合、Hive テーブルには `TEXTFILE` 形式を使用し、`binary` 列が Base64 文字列として保存されるようにする必要があります。
+- **JAR のパス**: 例の `hdfs://hostname:port/hive-udf.jar` は実際の HDFS アドレスに置き換えてください。すべての UDF で同じ JAR を参照することを推奨します。
+- **関数の対応関係**: `to_hll` は `to_bitmap`、`hll_union` は `bitmap_union`、`hll_cardinality` は `bitmap_count` に対応しているため、Bitmap と HLL の方式を切り替えやすくなっています。
diff --git a/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/intro.mdx b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/intro.mdx
new file mode 100644
index 00000000000..56511bbc334
--- /dev/null
+++ b/i18n/ja/docusaurus-plugin-content-docs/version-4.x/connection-integration/data-integration/intro.mdx
@@ -0,0 +1,254 @@
+---
+{
+ "title": "データ連携",
+ "language": "ja",
+ "description": "Apache Doris を BI、データ同期、ストリーム処理、ログの可観測性、開発管理、データモデリングの各ツールと連携させます。"
+}
+---
+
+import GettingStartedCard from '@site/src/components/getting-started-card/getting-started-card';
+
+# データ連携
+
+Apache Doris は、データエコシステムの幅広いツールとの連携に対応しています。用途に適したツールを選ぶことで、Doris をデータの可視化、移行と同期、リアルタイムの取り込み、ログと可観測性の分析、データベースの開発と管理、データモデリングと変換に活用できます。
+
+## BI とビジュアル分析
+
+<div className="cards-grid">
+<GettingStartedCard
+ title="Apache Superset"
+ icon="/images/next/connection-integration/data-integration/logos/apache-superset.png"
+ description="Superset に Doris データソースを設定し、セルフサービス分析、グラフの作成、ダッシュボードの構築を行います"
+ link="./apache-superset"
+/>
+
+<GettingStartedCard
+ title="Metabase"
+ icon="/images/next/connection-integration/data-integration/logos/metabase.svg"
+ description="Metabase Doris Driver を通じて Doris にクエリを実行し、対話型の分析ダッシュボードを構築します"
+ link="./metabase"
+/>
+
+<GettingStartedCard
+ title="FineBI"
+ icon="/images/next/connection-integration/data-integration/logos/finebi.svg"
+ description="FineBI を Doris に接続し、データモデリング、多次元分析、ダッシュボードの構築を行います"
+ link="./finebi"
+/>
+
+<GettingStartedCard
+ title="Power BI"
+ icon="/images/next/connection-integration/data-integration/logos/powerbi.svg"
+ description="Doris コネクターを通じて Power BI Desktop で Doris のデータにクエリを実行するか、データをインポートします"
+ link="./powerbi"
+/>
+
+<GettingStartedCard
+ title="Tableau"
+ icon="/images/next/connection-integration/data-integration/logos/tableau.svg"
+ description="Tableau の公式 MySQL コネクターを通じて Doris にアクセスし、Doris のデータを可視化します"
+ link="./tableau"
+/>
+
+<GettingStartedCard
+ title="QuickSight"
+ icon="/images/next/connection-integration/data-integration/logos/quicksight.svg"
+ description="AWS QuickSight の MySQL データソースを使用し、直接クエリモードまたはインポートモードで Doris に接続します"
+ link="./quicksight"
+/>
+
+<GettingStartedCard
+ title="Quick BI"
+ icon="/images/next/connection-integration/data-integration/logos/quickbi.png"
+ description="Alibaba Cloud Quick BI で Doris のデータソースとデータセットを作成し、ビジュアル分析レポートを構築します"
+ link="./quickbi"
+/>
+
+<GettingStartedCard
+ title="Smartbi"
+ icon="/images/next/connection-integration/data-integration/logos/smartbi.jpeg"
+ description="Smartbi を Doris と連携させ、データ接続、モデリング、ビジュアル分析を行います"
+ link="./smartbi"
+/>
+</div>
+
+## データベースの開発と管理
+
+<div className="cards-grid">
+<GettingStartedCard
+ title="DataGrip"
+ icon="/images/next/connection-integration/data-integration/logos/datagrip.svg"
+ description="DataGrip の MySQL データソースを使用して Doris に接続し、内部カタログと外部カタログへのクエリおよび管理を行います"
+ link="./datagrip"
+/>
+
+<GettingStartedCard
+ title="DBeaver"
+ icon="/images/next/connection-integration/data-integration/logos/dbeaver.svg"
+ description="DBeaver の MySQL ドライバーを通じて Doris に接続し、SQL クエリの実行とデータベースの視覚的な管理を行います"
+ link="./dbeaver"
+/>
+
+<GettingStartedCard
+ title="CloudDM"
+ icon="/images/next/connection-integration/data-integration/logos/clouddm.svg"
+ description="CloudDM で Doris データソースを管理し、クエリ、視覚的な編集、アクセス制御、データベースの CI/CD を行います"
+ link="./clouddm"
+/>
+</div>
+
+## データの移行、同期、一括ロード
+
+<div className="cards-grid">
+<GettingStartedCard
+ title="CloudCanal"
+ icon="/images/next/connection-integration/data-integration/logos/cloudcanal.svg"
+ description="CloudCanal を使用して、MySQL、Oracle、PostgreSQL、SQL Server などのソースから Doris にデータを移行または同期します"
+ link="./cloudcanal"
+/>
+
+<GettingStartedCard
+ title="DataX Doriswriter"
+ icon="/images/next/connection-integration/data-integration/logos/datax.jpg"
+ description="DataX Doriswriter を使用し、Stream Load を通じてさまざまなソースから Doris にデータを同期します"
+ link="./datax"
+/>
+
+<GettingStartedCard
+ title="Kettle Doris Plugin"
+ icon="/images/next/connection-integration/data-integration/logos/kettle.png"
+ description="Kettle ジョブで Doris プラグインを使用し、処理済みのデータを Stream Load を通じて Doris に書き込みます"
+ link="./kettle"
+/>
+
+<GettingStartedCard
+ title="SeaTunnel Doris Sink"
+ icon="/images/next/connection-integration/data-integration/logos/seatunnel.png"
+ description="SeaTunnel Doris Sink を使用して分散データ同期を行います。リアルタイム同期と Exactly Once の書き込みに対応しています"
+ link="./seatunnel"
+/>
+
+<GettingStartedCard
+ title="Doris Streamloader"
+ icon="/images/next/connection-integration/data-integration/logos/doris.png"
+ description="Doris Streamloader を使用し、複数ファイルの Stream Load インポートを並列実行します。中断した転送の再開にも対応しています"
+ link="./doris-streamloader"
+/>
+
+<GettingStartedCard
+ title="Spark Load"
+ icon="/images/next/connection-integration/data-integration/logos/spark.png"
+ description="外部の Spark リソースを使用して大規模な履歴データを前処理してロードし、Doris クラスターへのインポート負荷を軽減します"
+ link="./spark-load"
+/>
+
+<GettingStartedCard
+ title="Hive UDF"
+ icon="/images/next/connection-integration/data-integration/logos/hive.svg"
+ description="Hive テーブル内で Bitmap と HLL を直接生成・計算し、Hive Catalog または Spark Load を通じて Doris にロードします。"
+ link="./hive-udf"
+/>
+</div>
+
+## ストリーミング取り込みとビッグデータ処理
+
+<div className="cards-grid">
+<GettingStartedCard
+ title="Flink Doris Connector"
+ icon="/images/next/connection-integration/data-integration/logos/flink.png"
+ description="Flink で Doris との間でデータを読み書きします。ストリーム書き込み、バッチ書き込み、Lookup Join、Flink CDC によるデータベース全体の同期に対応しています"
+ link="./flink-doris-connector"
+/>
+
+<GettingStartedCard
+ title="Spark Doris Connector"
+ icon="/images/next/connection-integration/data-integration/logos/spark.png"
+ description="RDD、DataFrame、Spark SQL を通じて Spark で Doris との間でデータを読み書きします。バッチ書き込みとストリーミング書き込みに対応しています"
+ link="./spark-doris-connector"
+/>
+
+<GettingStartedCard
+ title="Doris Kafka Connector"
+ icon="/images/next/connection-integration/data-integration/logos/kafka.png"
+ description="Kafka Connect を使用し、Kafka トピックのデータを Doris に継続的に書き込みます"
+ link="./doris-kafka-connector"
+/>
+
+<GettingStartedCard
+ title="AutoMQ Load"
+ icon="/images/next/connection-integration/data-integration/logos/automq.png"
+ description="Doris Routine Load を使用して AutoMQ の Kafka 互換トピックからデータを取り込み、リアルタイムでロードします"
+ link="./automq"
+/>
+</div>
+
+## ログと可観測性
+
+<div className="cards-grid">
+<GettingStartedCard
+ title="Filebeat"
+ icon="/images/next/connection-integration/data-integration/logos/filebeat.svg"
+ description="Beats Doris output プラグインを使用してログ、メトリクス、監査データを収集し、リアルタイムで Doris に書き込みます"
+ link="./beats"
+/>
+
+<GettingStartedCard
+ title="Fluent Bit"
+ icon="/images/next/connection-integration/data-integration/logos/fluentbit.svg"
+ description="Fluent Bit Doris Output Plugin を使用してログを収集し、Stream Load を通じて Doris に書き込みます"
+ link="./fluentbit"
+/>
+
+<GettingStartedCard
+ title="Logstash"
+ icon="/images/next/connection-integration/data-integration/logos/logstash.svg"
+ description="Logstash Doris output プラグインを使用してログを収集・前処理し、リアルタイムで Doris に書き込みます"
+ link="./logstash"
+/>
+
+<GettingStartedCard
+ title="LoongCollector"
+ icon="/images/next/connection-integration/data-integration/logos/loongcollector.png"
+ description="LoongCollector Doris Flusher を使用してログを収集・処理し、データを Doris に書き込みます"
+ link="./loongcollector"
+/>
+
+<GettingStartedCard
+ title="OpenTelemetry"
+ icon="/images/next/connection-integration/data-integration/logos/opentelemetry.svg"
+ description="OpenTelemetry のログ、トレース、メトリクスを Doris にエクスポートし、まとめて分析します"
+ link="./opentelemetry"
+/>
+
+<GettingStartedCard
+ title="Vector"
+ icon="/images/next/connection-integration/data-integration/logos/vector.svg"
... 19489 lines suppressed ...
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@doris.apache.org
For additional commands, e-mail: commits-help@doris.apache.org