motherduck-ducklake

MotherDuck で DuckLake を使用する

信頼できる情報源

• まず、MotherDuck の最新の DuckLake ドキュメントを優先してください。
• MotherDuck のドキュメントで言及されている拡張機能レベルの動作を明確にする場合に限り、上流の DuckLake および DuckDB 拡張機能のドキュメントを参照してください。
• ガイダンスは、文書化されている製品の方針に沿わせてください。
  • まずネイティブの MotherDuck を検討する
  • MotherDuck の DuckLake ドキュメントが、サポート対象の製品機能とライフサイクル／互換性の制限を定義しています。プロンプトに上流のバージョンや製品のステータスをそのまま残すのではなく、現在の DuckDB／DuckLake のバージョン対応表を確認してください
  • 完全マネージド、BYOB、自前コンピュートの各方式はそれぞれ異なります
  • メンテナンスとコンパクションは明示的な操作であり、バックグラウンドで自動的に行われるものではありません

基本方針

• 具体的な DuckLake の要件がない限り、まずネイティブの MotherDuck ストレージを使用してください。
• オープンテーブル形式のセマンティクス、信頼できる情報源としてのオブジェクトストレージ、BYOB、またはファイルを考慮したメンテナンスが必要な場合は、DuckLake を検討してください。
• ワークロードが「大規模」であるという理由だけで DuckLake を推奨しないでください。MotherDuck のドキュメントでは、読み取りではネイティブストレージのほうが速いことが多いと明記されています。
• 運用モードは意図的に選択してください。評価を最も簡単に行うには完全マネージド、顧客がバケットを所有するには BYOB、コンピュートの境界も重要な場合にのみ自前コンピュートを選びます。
• DuckLake の要件が弱い、未確認、または将来の移植性だけに関するものであれば、ネイティブの MotherDuck ストレージに切り替える方法を記載してください。
• データのインライン化、ソート済みテーブル、バケットパーティショニング、削除ベクトル、または拡張機能の動作について構文を保証する場合は、現在の MotherDuck DuckLake ドキュメントと DuckDB／DuckLake のバージョン対応表を確認してください。
• 上流の DuckDB リリースノートだけを根拠に、MotherDuck クライアント／ランタイムのサポートを推測しないでください。正確な DuckDB バージョンが重要な場合は、MotherDuck のライフサイクルに関するドキュメントを確認してください。
• MotherDuck の製品機能と、DuckLake 拡張機能に関する未確認の前提を分けて扱ってください。
• きめ細かな共有（INCLUDE_PATTERN と、行、列、マスキングに対応したセキュアビュー）は、完全マネージドの DuckLake でのみ利用できます。独自の DATA_PATH を持つ BYOB データベースでは利用できません。このような共有は UPDATE AUTOMATIC にする必要があり、利用者はタイムトラベルと DuckLake のメタデータ関数を使用できなくなります。利用者ごとのアクセス制御が重要な場合は、BYOB ではなく完全マネージドを選ぶ理由になります。永続化された Iceberg カタログは共有できません。
• BYOB バケットは、組織とは異なるリージョンやクラウドに配置できます。S3 シークレットでは REGION を、その他の S3 互換ストアでは ENDPOINT を、R2 では ACCOUNT_ID を設定してください（データの所在地が重要な場合は、管轄区域エンドポイントも設定します）。レイテンシが高くなる可能性があり、プロバイダーの転送料金が発生する場合があります。コンピュート、メタデータカタログ、統計情報、インライン化された行は、組織のリージョンに保持されます。
• 永続化された Iceberg カタログに、ネイティブ／共有の REFRESH DATABASE に関する前提を適用しないでください。カタログは独立して更新されます。更新操作を案内する前に、最新のドキュメントを確認してください。

ワークフロー

1. ネイティブの MotherDuck ストレージでは不十分な理由を確認します。
2. 運用モードを選択します。完全マネージド、MotherDuck コンピュートを使用する BYOB、または自前コンピュートを使用する BYOB です。
3. BYOB を提案する前に、バケットへのアクセス可否、リージョン、転送コスト、データの所在地を確認し、設計できめ細かな共有が必要かどうか（完全マネージドでのみ利用可能）も確認します。
4. データのインライン化、ファイルのコンパクション、クリーンアップの想定を含め、取り込みとメンテナンスの方針を事前に定めます。
5. アーキテクチャを確定する前に、誰がどのコンピュート環境からデータをクエリするのかを確認します。

参考資料

現在のタスクに必要な参考資料のセクションのみを読んでください。

• モード選択マトリクス、MotherDuck 固有の SQL パターン、BYOB の制約、データのインライン化の動作、メンテナンス関数、DuckLake でよくある間違いについては、references/DUCKLAKE_PLAYBOOK.md を参照してください。

関連スキル

不足している機能を補う場合にのみ、関連スキルを読み込みます。確立済みのコンテキストを再利用してください。

• motherduck-connect：ネイティブ DuckDB と Postgres エンドポイント経由のアクセス方法を選ぶ場合
• motherduck-load-data：実際の課題がストレージ形式ではなく、データの取り込みである場合
• motherduck-model-data：ストレージの決定後も、ユーザーが分析用テーブルの設計を必要としている場合
• motherduck-build-data-pipeline：DuckLake が、より広範なデータ取り込みから提供までのワークフローの一部にすぎない場合