翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# ベストプラクティス
<a name="best-practices"></a>

ストレージと技術的なベストプラクティスに従うことをお勧めします。これらのベストプラクティスは、データ中心のアーキテクチャを最大限に活用するのに役立ちます。

## ビッグデータのストレージのベストプラクティス
<a name="storage-best-practices"></a>

次の表は、ビッグデータ処理負荷のファイルを Amazon S3 に保存するための一般的なベストプラクティスを示しています。最後の列は、設定できるライフサイクルポリシーの例です。[Amazon S3 Intelligent-Tiering](https://aws.amazon.com/s3/storage-classes/intelligent-tiering/) が有効になっている場合 (データアクセスパターンが変化するとストレージコストが自動的に削減される)、ポリシーを手動で設定する必要はありません。


|  |  |  | 
| --- |--- |--- |
| **データレイヤー名** | **説明** | **ライフサイクルポリシー戦略の例** | 
| Raw | 未処理、未加工のデータを含む**注**: 外部データソースの場合、raw データレイヤーは通常、データの 1:1 のコピーですが、 AWS データ上の は、取り込みプロセス中の AWS リージョン または 日付に基づいてキーで分割できます。 | 1 年後に、ファイルを S3 Standard-IA [ストレージクラス](https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-class-intro.html)に移動します。S3 Standard-IA で 2 年経過したら、[Amazon Simple Storage Service Glacier (Amazon S3 Glacier) ](https://docs.aws.amazon.com/amazonglacier/latest/dev/introduction.html)にファイルをアーカイブします。 Amazon Glacier (元のスタンドアロンのボールトベースのサービス) は、2025 年 12 月 15 日以降、新規のお客様を受け入れなくなります。既存のお客様に影響はありません。 Amazon Glacier は、ボールトにデータを保存する独自の API を備えたスタンドアロンサービスであり、Amazon S3 および Amazon S3 Glacier ストレージクラスとは異なります。既存のデータは Amazon Glacier で無期限に安全性が確保され、引き続きアクセス可能です。移行は必要ありません。低コストの長期アーカイブストレージの場合、 は [Amazon S3 Glacier ストレージクラス](https://aws.amazon.com/s3/storage-classes/glacier/) AWS を推奨します。これにより、S3 バケットベースの APIs、フル AWS リージョン 可用性、低コスト、 AWS サービス統合で優れたカスタマーエクスペリエンスを実現できます。拡張機能が必要な場合は、Amazon S3 ボールトから Amazon [AWS Amazon S3 Glacier ストレージクラスにデータを転送するためのソリューションガイダンスを使用してAmazon S3 Glacier ストレージクラスへの移行を検討してください。](https://aws.amazon.com/solutions/guidance/data-transfer-from-amazon-s3-glacier-vaults-to-amazon-s3/) | 
| ステージ | 使用に最適化された中間処理データを含む**例**: CSV から Apache Parquet に変換された raw ファイルまたはデータ変換 | 所定の期間の後、または組織の要件に従ってデータを削除できます。一部のデータ派生 (元の JSON 形式の Apache Avro 変換など) は、(90 日後など) より短い期間の後でデータレイクから削除できます。 | 
| 分析 | 特定のユースケースの集計データをすぐに使用できる形式で含めます。**例**: Apache Parquet | S3 Standard-IA にデータを移動してから、所定の期間の後、または組織の要件に従ってデータを削除できます。 | 

次の図は、すべてのデータレイヤーで使用できるパーティショニング戦略 (1 つの S3 フォルダ/プレフィックスに対応) の例を示しています。データの使用方法に基づいてパーティショニング戦略を選択することをお勧めします。例えば、レポートがデータに基づいて構築されている場合 (レポートの最も一般的なクエリがリージョンと日付に基づいて結果をフィルタリングする場合)、クエリのパフォーマンスとランタイムを向上させるために、リージョンと日付をパーティションとして含めてください。

![\[パーティション戦略の図\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/modern-data-centric-use-cases/images/partitioning_strategy.png)


## 技術的なベストプラクティス
<a name="technical-best-practices"></a>

技術的なベストプラクティスは、データ中心のアーキテクチャの設計に使用する特定の AWS のサービス および処理テクノロジーによって異なります。ただし、以下のベストプラクティスに留意することをお勧めします。これらのベストプラクティスは、一般的なデータ処理のユースケースに適用されます。


|  |  | 
| --- |--- |
| **[面積]** | **ベストプラクティス** | 
| SQL | データに属性を射影することで、クエリする必要があるデータの量を減らします。テーブル全体を解析する代わりに、データ射影を使用して、テーブル内の特定の必要な列のみをスキャンして返すことができます。複数のテーブル間の結合は、リソースを大量に消費する需要が生じ、パフォーマンスに大きな影響を与える可能性があるため、大きな結合はできるだけ避けてください。 | 
| Apache Spark | のワークロードパーティショニングを使用して [Spark アプリケーションを最適化する](https://aws.amazon.com/blogs/big-data/optimizing-spark-applications-with-workload-partitioning-in-aws-glue/) AWS Glue (AWS ビッグデータブログ）。の[メモリ管理を最適化する](https://aws.amazon.com/blogs/big-data/optimize-memory-management-in-aws-glue/) AWS Glue (AWS ビッグデータブログ）。 | 
| データベース設計 | [データベースのアーキテクチャのベストプラクティス](https://aws.amazon.com/architecture/databases/?cards-all.sort-by=item.additionalFields.sortDate&cards-all.sort-order=desc&awsf.content-type=*all&awsf.methodology=*all) (AWS アーキテクチャセンター) に従ってください。 | 
| データプルーニング | [サーバー側のパーティションプルーニング](https://docs.aws.amazon.com/glue/latest/dg/partition-indexes.html)と `catalogPartitionPredicate` を使用します。 | 
| スケーリング | [水平スケーリング](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.horizontal-scaling.en.html)を理解して実装します。 |