変更要約: in-scope サービス網羅: 中核サービスの解説を追加
1.3ストレージとデータ形式
効率よく蓄える——列指向（Parquet/ORC）、パーティション、S3 ストレージクラス、SageMaker の入力モード——を理解します。形式とレイアウトがコストと速度を左右します。
大量の学習データは、形式とレイアウトで扱いやすさが大きく変わります。分析・学習には 列指向フォーマットとパーティションが効きます。
1.3.1形式とレイアウト
- 列指向（Parquet/ORC）：必要な列だけ読めるため、分析・学習で高速かつ低コスト。
- パーティション：日付やキーで分割するとスキャン量が減りコスト減（Athena 等）。
- S3 ストレージクラス：アクセス頻度に応じ Standard/IA/Glacier を使い分けコスト最適化。
- SageMaker 入力モード：大規模データは Pipe モード（ストリーム）/RecordIO-protobuf で効率化できる。
「分析/学習の効率＝列指向（Parquet/ORC）＋パーティション」「コスト最適化＝S3 ストレージクラス」「大規模学習の効率＝SageMaker Pipe モード/RecordIO-protobuf」 は MLS-C01 で頻出です。Athena のコストはスキャン量で決まるので、列指向＋パーティションが効きます。
MLS-C01 では SageMaker の入力モードと、学習を速くするデータ供給の設計が問われます。入力モードは 3 つを区別します——File モードは学習開始前にデータを丸ごとインスタンスの EBS にコピーするためシンプルだが起動が遅く容量を食う、Pipe モードは S3 から直接ストリーミングして読み込み開始を速め大容量に強い、そして現行の Fast File モードは POSIX ファイルのように見せつつ遅延ロードするため File の使いやすさと Pipe の速さを両立する。さらに FSx for Lustre を使うと S3 をバックエンドに高スループットの並列ファイルシステムを学習に供給でき、同じデータで多数のジョブやハイパーパラメータ探索を回すときに繰り返しの S3 ダウンロードを避けられる。組み込みアルゴリズムの多くは RecordIO-protobuf（特に疎データに有利）を最も効率よく扱う。形式選択は「分析は列指向（Parquet/ORC・必要列のみ読む・述語プッシュダウン）」「ストリーミング学習は RecordIO」「相互運用は CSV/JSON」で考える。Athena/Glue のコストとスキャン量を抑えるには、列指向＋適切な粒度のパーティション（過剰分割は小ファイル問題を招く）＋ファイルサイズの最適化（小さすぎるファイルを避ける・コンパクション）が効く。S3 階層は、頻繁アクセスの学習中データは Standard、アクセスが読めない混在は Intelligent-Tiering、古い生データは IA や Glacier にライフサイクルで移し、暗号化（SSE-KMS）とバージョニングも併用する。
| 入力モード | 仕組み | 向き/不向き |
|---|---|---|
| File モード | 学習前に全データを EBS へコピー | 小〜中規模・単純／起動が遅い |
| Pipe モード | S3 から直接ストリーミング | 大容量・開始が速い |
| Fast File モード | POSIX 風に遅延ロード | File の手軽さ＋Pipe の速さ |
| FSx for Lustre | S3 連携の並列 FS | 反復ジョブ・HPO で再利用 |
シナリオ：数 TB の学習データで、毎回 File モードのコピーに時間がかかり、さらにハイパーパラメータ探索で同じデータを何十回も読む。→ 起動を速めるなら Pipe または Fast File モード、同じデータを多数ジョブで反復利用するなら FSx for Lustre（S3 連携）で並列高スループット供給にし、繰り返しの S3 ダウンロードを排除する。
FAQ：Q. Pipe と Fast File の違いは? A. Pipe は逐次ストリーム、Fast File は POSIX 風に見せて必要箇所を遅延ロード。多くは Fast File が扱いやすい。Q. パーティションは細かいほど良い? A. 細かすぎると小ファイルが増えメタデータ負荷とスキャン非効率を招く。粒度はクエリパターンに合わせる。Q. 組み込みアルゴリズムに最適な形式は? A. 多くは RecordIO-protobuf（疎データに有利）。
ひっかけ：「学習を速くするには常に Pipe モードが正解」は誤り。小規模データや POSIX 的なランダムアクセスが要る場合は File/Fast File が適し、同じデータを多数ジョブで再利用するなら FSx for Lustre が効く。「列指向にすれば常に速い」も誤りで、行を丸ごと使うストリーミング学習や逐次読み出しでは列指向の利点は出ない。用途で選ぶ。
1.3.2データ準備・基盤の in-scope サービス
ML のデータエンジニアリングでは多様な基盤サービスが in-scope です。大規模分散処理は Amazon EMR（Spark/Hadoop）、ストリームのリアルタイム処理は Amazon Managed Service for Apache Flink、データレイクの細粒度権限は AWS Lake Formation、全文/ベクトル検索は Amazon OpenSearch Service。 実行基盤は、コンテナ化ワークロードを Amazon Elastic Container Service（ECS）や AWS Fargate（サーバーレス実行）で動かし、エッジでのローカル推論は AWS IoT Greengrass で行います。ストレージは、学習データ/モデルの標準が Amazon S3、複数インスタンスからの同時共有が Amazon Elastic File System（EFS）です。
1.3.3この節のまとめ
- 効率＝列指向（Parquet）＋パーティション
- コスト＝S3 ストレージクラス、大規模学習＝Pipe モード
- 処理＝EMR/Flink、検索＝OpenSearch、実行＝ECS/Fargate/Greengrass、保管＝S3/EFS
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 大量の表形式データを Athena や学習で効率よく・低コストにスキャンしたい。どの形式が適していますか？
Q2. Athena のクエリコストを下げるために、S3 のデータレイアウトで有効な手法はどれですか？
Q3. SageMaker で非常に大きな学習データを、ディスクにすべてダウンロードせず効率的に読みたい。何を使いますか？