MLS-2.1モデリングのためのデータのサニタイズと準備。

ヒントボタン

1行目
予測結果を日次で得たいときは、Amazon Forecast に投入する target time series も日次にそろえるのが王道です。S3 の 1 時間データは AWS Glue で 24 時間ごとに sum して在庫ゼロ日は 0 として残し、障害で欠けた行だけ 0 で埋めるとタイムスタンプの等間隔が保たれます。これによりレコード数が 1/24 まで削減され、AutoPredictor の学習時間を 30% 以上短縮しつつ MAPE の安定化にも寄与します。

2行目
価格改定や在庫水準のような説明変数は item metadata に置くと Amazon Forecast が自動で特徴量化してくれますが、店舗 ID のように SKU をまたいで共有される変量は related time series に分けるのが推奨です。AWS Glue でメタデータと時系列を個別にパーティション化し、Data Catalog に登録したうえで AutoPredictor に渡せば、DeepAR+ や ARIMA 単独より少ないパラメータ設定で多変量学習が可能となり、精度向上と運用コスト抑制が両立します。

3行目
大量の SKU ×店舗を扱う際は、モデル選定より先に「等間隔・粒度統一・説明変数の切り分け」という前処理設計が鍵です。集約でレコード数を抑え、欠損は 0 埋め、外部変量は item metadata／related の使い分け、そして AutoML 機能を活用してモデル探索を自動化する流れが、Amazon Forecast における学習時間短縮・MAPE 最小化の双方をバランス良く満たす総合的な解決策となります。

ヒントボタン

母集団分布を保ったまま欠損を埋めるには多重代入が不可欠です。scikit-learn の IterativeImputer は回帰連鎖により複数パターンを生成でき、SageMaker Processing の Python スクリプトであれば nightly バッチに組み込みやすく、生成した複数データの平均でバイアスを抑制できます。GUI での平均・中央値補完は単一代入に留まり分布が縮む点に注意し、S3 入力を直接扱って処理を完結させましょう。

再現性という観点では random_state を固定できるコードベースが重要です。Git で管理した Python スクリプトを SageMaker Processing から呼び出せば SHA 単位でバージョンが追跡でき、pull request でのレビューも容易になります。対して AWS Glue DataBrew や SageMaker Data Wrangler の GUI 設定はシード指定が難しくファイル差分も見えにくいため、CI/CD と組み合わせる際に手間が増えがちです。SageMaker Pipelines で Git コミット ID をパラメータ化する構成が運用ベストプラクティスです。

処理性能と運用負荷を考えると、ml.m5.xlarge 1 台で 500 万行を 30 分以内にさばくには列指向の Parquet が効果的で、SageMaker Processing なら一時クラスターを透過的に立ち上げて I/O とメモリを最適化してくれます。Athena CTAS は全体再生成が必要で所要時間が読みにくく、Glue DataBrew もバックエンド初期化のオーバーヘッドがあります。多重代入・固定シード・Git 管理・時間制約という複数要件を俯瞰すると、コードとして管理可能な Processing ジョブが最もバランスの取れた解となるはずです。

ヒントボタン

データサイエンティストが処理内容を GUI で確認できることを重視する場合、Amazon SageMaker Data Wrangler の Flow を使えば欠損値除去やワンホットエンコードに続けて「オーバーサンプリング（少数クラス）」を 10 倍で追加でき、200 GB 規模でもマネージドでスケールしつつ各ステップの順序と結果をプレビューしながら直感的に構築できます。
処理後のファイルを列順を保ったまま Parquet 形式で Amazon S3 に保存したいときは、Data Wrangler から出力形式を Parquet に選択し、そのまま SageMaker Pipelines の Processing ステップとしてエクスポートするだけで同一 Flow を本番パイプラインでも自動再実行でき、GUI からいつでも変換ロジックを再確認できます。
運用負荷とコード保守を最小化する観点では、Data Wrangler＋SageMaker Pipelines のマネージド連携が AWS Glue や SageMaker Processing のフルスクリプト実装よりレビューや監査対応が容易で、再現性・自動化・可視化という複数要件を横断的に満たす総合バランスが鍵となります。

ヒントボタン

株価のように自己相関が強いデータをAmazon SageMakerでLSTM学習させるときは、まずS3からProcessing Jobで取り出し、timestampで昇順ソートして時間軸を保ちます。そのうえでInputChannelを分け、古い行だけをtrain、直近30日程度をvalidationにホールドアウトすれば、推論時には手に入らない未来情報をモデルが見ることを確実に防げます。

ランダムシャッフルや交互抽出はIID前提のタブラーや画像では便利ですが、時系列ではCloudWatchで監視する実運用精度を過大評価する原因になります。scikit-learnのShuffleSplitより、Feature Storeに保存する段階で時系列構造を保ち、Training Jobに渡す際に過去→未来の一方向性を崩さない分割が安全です。

週次バッチで「7日先」を評価する要件、データリーク防止、SageMaker Estimatorにおけるtrain/validationチャンネル管理という三点を同時に満たせる方法を選ぶと、保守の再現性とモデルの信頼性を両立できると総合的に判断できます。

ヒントボタン

時系列ログでは未来のレコードを学習に混入させないことが肝心です。Amazon SageMaker Data Wrangler には timestamp を昇順ソートし、過去ウィンドウと最新ホールドアウトウィンドウを日数で区切る「時系列分割」トランスフォームが備わっていますので、Glue や Athena を追加せずともパイプライン内から呼び出して S3 の Training と Validation へ直接エクスポートできます。

rand() 関数やハッシュ分割は AWS Glue DynamicFrame や Amazon Athena CTAS で容易に書けますが、これらは過去と未来をランダムに混ぜてしまい時系列予測で深刻なデータリークを招きます。SageMaker Pipelines で公正にモデルを評価するには timestamp 列に沿った境界で切り出すことが必須であり、GUI でコードレスに実装できるサービスとして最適なのが Data Wrangler です。

「追加 ETL 基盤を置かない」「過去90日を Training、直近7日を Evaluation」「再現性のあるパイプライン」「時系列順を厳守」という複数要件を総合的に眺めると、Studio 上で時系列ソートとホールドアウト期間を指定し学習・評価チャネル用に S3 へ自動出力できる SageMaker Data Wrangler が全観点を最もバランス良く充たす方法となります。

ヒントボタン

Amazon SageMaker Data Wrangler はブラウザ GUI だけで Amazon S3 に置いた 5 億件のログをサンプリングしつつ取り込み、欠損補完やワンホット化に加え SMOTE を含む「Balance classes」変換をワンクリックで加えられます。Apply & Save で .flow ファイルが生成され、そのまま ProcessingJob や SageMaker Pipelines の ProcessingStep に変換でき、IAM ロールも自動推奨されるため前処理のコード記述と権限設定の手間を大幅に削減できます。GUI 上で統計量の可視化も確認できるのでデータ理解も容易です。

同様の課題を解こうとして SageMaker Autopilot を走らせても SMOTE は自動適用されず、AWS Glue で PySpark を書くとコード保守が増え、トレーニングスクリプトで imbalanced-learn を pip install する道は CodeBuild や Amazon ECR の管理が付随します。GUI ベースでクラスバランス調整を済ませたい、かつ Lineage で処理経路を追跡したいという条件を並べると、前処理をノーコードで保存し再利用できるサービスが有利だと比較できます。またスケーラビリティも自動で担保されます。

GUI 作業、SMOTE、Pipelines 統合、Lineage、コード最小化、保守削減という複数要件を同時に満たす選択肢を探すと、SageMaker Data Wrangler フローをそのまま ProcessingStep として組み込み、マネージドインフラで実行するアプローチが最も自然です。運用時はスケジュール実行やイベント駆動で再実行も容易な点も後押しになります。諸条件を俯瞰して総合的に評価するとこの結論に収束するはずです。

ヒントボタン

SageMaker Data Wrangler にはドラッグ＆ドロップで列タイプを自動判定し、数値列は中央値、カテゴリ列は最頻値で欠損補完するトランスフォームをボタン一つで追加でき、5000 列規模でもコードを書かずに処理結果をそのまま SageMaker Feature Store に送る専用ノードがあるため、追加スクリプトや Lambda を挟む運用が不要になり工数を大幅に削減できます。
Data Wrangler のフローはワンクリックで SageMaker Pipelines に変換でき、パイプラインは SDK 形式で Git リポジトリにプッシュするだけで履歴が残るうえ、EventBridge で週次スケジュールを組むと実行時にだけ一時的な SageMaker Processing インスタンスが起動し、終了後は自動でリソースが解放されるため常時稼働クラスタを持たずに 1 時間以内のバッチ処理を低コストで回せます。
AWS Glue DataBrew は Feature Store 直書きができず追加バッチが必要、Athena は SQL で中央値や最頻値を求める複雑なロジックが発生し、EMR は常時起動コストが高いという比較ポイントを踏まえると、ノーコード操作・自動バージョン管理・直接登録・スケジュール実行を一体で満たす SageMaker Data Wrangler と Pipelines、EventBridge の組み合わせが全要件を俯瞰したうえで最も運用負荷を抑えた選択肢といえます。