20250829_Jagu'e'r データ利活用分科会_マルチクラウド環境におけるデータウェアハウスの配置とデータパイプライン

© 2025 NTT West, Inc. All Rights Reserved. マルチクラウド環境における データウェアハウスの配置とデータパイプライン Jagu‘e’r データ利活用分科会 2025/8/29 高須賀 将秀

© 2025 NTT West, Inc. All Rights Reserved. 2 /12 自己紹介 たかすか まさひで 高須賀 将秀 博士（情報学）（2023/3） 研究分野：組合せ最適化，数理最適化，オペレーションズ・リサーチ（OR），グラフ理論 所属：NTT西日本 デジタル改革推進部（2021/8～）， 法政大学 デザイン工学部 兼任講師（2024/4～），個人事業（Udemy講師等）（2024/6～） 業務：データドリブン経営を牽引する立場 ・データ活用基盤のシステム開発 ・データ分析手法の研究 ・データ分析活用事例の提案 ・デジタル人材育成 資格：クラウド資格（AWS全冠，Azure全冠，GCP全冠）， Microsoft Top Partner Engineer Award（2024）， AWS All Certifications Engineers（2024, 2025） ， Snowflake Squad（2025） 高須賀将秀のホームページ

© 2025 NTT West, Inc. All Rights Reserved. 3 /12 私の研究（博論）内容 ◼ 与えられた全ての工事に対して立会者の割当を決定する問題である ◼ 移動距離や立会者のスキル等の様々な条件を考慮し割当を決定している ◼ 条件は万人共通の条件もあれば手配者の思考や嗜好によって異なるものもある 入力 出力 工事4 工事1 1 工事2 4 手配者 工事5 2 1 工事6 3 工事7 工事8 8 工事9 6 工事5 数理モデル 5 工事6 工事3 手配者 の思考/嗜好 = 7 工事2 4 2 5 工事3 立会者1～4 工事4 工事1 立会者4 3 工事7 立会者1 7 立会者2 工事8 ブラックボックス 化 8 工事9 9 9 立会者3 6

© 2025 NTT West, Inc. All Rights Reserved. 4 /12 私の研究（博論）内容 ◼ 高度な技能を有している手配者により意思決定が行われている工事立会者手配 業務に対し実用的な手配結果を算出可能な数理モデルを構築した 長期効果 短期効果 付随効果 過去の工事立会者手配業務 デジタルデータ活用による工事立会者手配業務 人件費 年間1億（関東エリア：年間6万件） 年間0.1億（関東エリア：年間6万件）（想定） 品質 年間工事事故5件 年間工事事故0件（想定） 総移動時間 11,424 s（3.2 h） 11,593 s（3.2 h）※1 総割当ペナルティ 163 pt 81 pt※1 手配時間 3時間2回/1日 5分×2回/1日 やり方 アナログ（手書き） デジタル 手配結果 ※1：数理モデル4で総移動時間を重視すると, 総合移動時間10,697 s, 総品質146 ptとなる.

© 2025 NTT West, Inc. All Rights Reserved. 5 /12 マルチクラウド環境におけるデータウェアハウスの必要性 • 主要クラウド事業者の独自の強みが年々増し，差別化が進んでいる中，それぞれの 強みを活かしたアーキテクチャを取るために，異なるクラウド間におけるクロスデータウェ アハウスの需要が増している • Google Cloud：BigQueryを軸としたAI/ML等のデータ分析，GeminiやGWS独自サービス • AWS：多様なサービスやサードパーティ製品，Anthropicとの連携 • Azure：Office365やDynamics365，OpenAIとの連携 一極集中型のアーキテクチャ ハイブリッド型のアーキテクチャ

© 2025 NTT West, Inc. All Rights Reserved. 6 /12 一極集中型のアーキテクチャの課題 • 一極集中型のアーキテクチャの場合，以下のような課題がある • 複数のシステムで別のクラウドサービスを利用している場合，データ連携の仕組み（データパイプラ イン等）が必要 • 単一システムでも別のクラウドサービスを利用したい場合，データ連携の仕組み（データパイプライ ン等）が必要 • ハイブリッド型のクラウドデータウェアハウスの利用を前提としているアーキテクチャがあまりない結果， 1つのクラウドに集約するかデータ連携による仕組みをそれぞれ検討する必要がある 1つのクラウドに集約 データ連携による仕組み （データパイプライン）

© 2025 NTT West, Inc. All Rights Reserved. 7 /12 データパイプラインの種類 • データパイプラインとは，複数のシステム間でデータを自動的に収集・加工・転送する 一連の処理フロー • 主な構成要素として，データソース: 業務システム・DB・API・ファイル，データ処理: 変換・クレンジング・集計，データ配信: データウェアハウス・分析基盤がある • アーキテクチャパターンとしては，ETL型，ELT型，ストリーミング型に分類される ETL型 ELT型 ストリーミング型 [ソース] → 抽出(Extract) → 変換(Transform) → 格納 (Load) → [ターゲット] [ソース] → 抽出(Extract) → 格納(Load) → 変換 (Transform) → [分析] [ソース] → リアルタイム収集 → 処理 → 配信 → [ターゲット] バッチ処理向き 大量データの定期処理 クラウドDWH活用 柔軟な後処理 リアルタイム処理 イベント駆動

© 2025 NTT West, Inc. All Rights Reserved. 8 /12 その他のデータパイプライン メジャーなデータパイプライン Cloud Strage Dataflow オープンテーブルフォーマット（Apache Iceberg） Cloud Strage BigQuery BigQuery 論理ミラーリング，データシェアリング GCPサービス内ではあり 他クラウドサービスに対してはなし （とあるFabricはSnowと連携可） 最近注目されている

© 2025 NTT West, Inc. All Rights Reserved. 9 /12 その他のデータパイプライン • Apache Iceberg（BigLake連携） • 「GCSに置いた1つの真実のデータ」をBigQueryやSparkで共有し，マルチクラウド・マルチエンジン運用向け • 論理ミラーリング • BigQueryやCloud Storageにコピーを持たせる方式，DRやバッチ同期が必要な場合に有効 • データシェアリング • BigQuery Analytics Hubでの参照共有が中心，外部パートナー連携やマーケット公開に向く 観点 オープンテーブルフォーマット 論理ミラーリング データシェアリング GCPでの実現例 BigLake + Iceberg テーブルとして作成し、 Cloud Storage上にデータ保存。BigQuery, Dataproc, Dataflow, Spark-on-GKEなどから アクセス可能 BigQuery Data Transfer Service、 Datastream（CDC）、Dataflowなどで別プロ ジェクトや別リージョンのBigQuery/Cloud Storageにコピー BigQuery Analytics Hub または Authorized Views で共有 データ転送コスト なし（直接同一GCSバケット参照） あり（コピー時のストレージ書き込み＋転送） なし（メタデータ共有のみ） ストレージコスト 単一のGCS領域に保存（共有利用） コピー先分のストレージ追加 コピー不要で低コスト リアルタイム性 高い（直接同じGCSのIcebergテーブルを参照） 同期間隔に依存（遅延あり） 高い（即時参照可能） 他クラウドとの連携 Cloud StorageのバケットをAWS S3/ADLSと連 携すればマルチクラウド可能 別クラウドに複製可能（転送料増） GCP外の共有は基本不可（外部連携にはエクス ポートが必要） 性能（クエリ速度） Icebergはメタデータ管理でパーティションプルーニン グやスナップショット読み込みが可能だ，BigQuery ネイティブよりやや遅い傾向（特に大規模ジョイン 時） コピー先BigQueryならネイティブ列指向ストレージ 利用で高速だが、同期遅延あり BigQueryネイティブ性能で高速

© 2025 NTT West, Inc. All Rights Reserved.

10 /12

その他のデータパイプライン
REST API等（or ODBCドライバ）を用いて，外部プログラムからデータ書き込み

疑似ミラーリングの仕組み

Snowflake
def snowflake_connect(self):
try:
self.conn = snowflake.connector.connect(
user=os.getenv('SNOWFLAKE_USER'),
password=os.getenv('SNOWFLAKE_PASSWORD'),
account=os.getenv('SNOWFLAKE_ACCOUNT'), # xxxxx.region
warehouse=os.getenv('SNOWFLAKE_WAREHOUSE',
'COMPUTE_WH'),
database=os.getenv('SNOWFLAKE_DATABASE', 'MY_DB'),
schema=os.getenv('SNOWFLAKE_SCHEMA', 'PUBLIC')
)
self.cursor = self.conn.cursor()
return True
except Exception as e:
return False
def create_table(self):
create_sql = """
CREATE TABLE IF NOT EXISTS sales_data (
id INTEGER AUTOINCREMENT,
product_name VARCHAR(100),
quantity INTEGER,
price DECIMAL(10,2),
sale_date DATE,
created_at TIMESTAMP_NTZ DEFAULT CURRENT_TIMESTAMP()
)

Fivetran，TROCCO等

BigQuery

def get_bigqueryc_connection():
try:
# プロジェクト情報の設定
project_id = ‘<PROJECT_ID>'
dataset_id = ‘<DATASET_ID>' # BigQueryではデータセットが必要
table_id = ‘<TABLE_ID>'
# フルパスでのテーブルID
full_table_id = f"{project_id}.{dataset_id}.{table_id}"
# カレントディレクトリにあるサービスアカウントキーファイルのパス
current_dir = os.path.dirname(os.path.abspath(__file__))
keyfile_path = os.path.join(current_dir, “xxx.json")
# サービスアカウントの認証情報を読み込む
credentials =
service_account.Credentials.from_service_account_file(
keyfile_path,
scopes=["https://www.googleapis.com/auth/cloud-platform"]
)
# 認証情報を使用してBigQueryクライアントを初期化
client = bigquery.Client(
project=project_id,
credentials=credentials
)

© 2025 NTT West, Inc. All Rights Reserved. データパイプライン選定のベストプラクティス • ビジネス要件（データ鮮度，データ量，更新頻度，SLA要件等）や 技術要件（既存インフラ，チームスキル，予算，拡張性）によってある 程度使い分けが必要 • 品質・ガバナンスを重視する場合ETL型，柔軟性を重視する場合ELT 型，リアルタイム性を重視する場合ストリーミング型，複数要件が混在す る場合ハイブリッド型を選ぶ • 異なるクラウド間におけるクロスデータウェアハウスの要件が強い場合は， 最近注目されつつある，オープンテーブルフォーマットや論理ミラーリング， データシェアリング，疑似ミラーリングを使うとよい • 用途は少し限定的だが，最近だと，データベース向けMCPツールボック ス を使用して，LLM とBigQuery などのデータソースに接続するやり方 もある 11 /12

• https://github.com/googleapis/genai-toolbox

© 2025 NTT West, Inc. All Rights Reserved.

12 /12

BigQueryへのデータ書き込み
• 外部からBigQuery のウェアハウスにデータを書き込む

• プロジェクトID，データセットID，テーブルID，サービスアカウントキー（json）が必要
def get_bigquery_connection():
try:
# プロジェクト情報の設定
project_id = ‘<PROJECT_ID>'
dataset_id = ‘<DATASET_ID>' # BigQueryではデータセットが必要
table_id = ‘<TABLE_ID>'
# フルパスでのテーブルID
full_table_id = f"{project_id}.{dataset_id}.{table_id}"
# カレントディレクトリにあるサービスアカウントキーファイルのパス
current_dir = os.path.dirname(os.path.abspath(__file__))
keyfile_path = os.path.join(current_dir, “xxx.json")

# サービスアカウントの認証情報を読み込む
credentials = service_account.Credentials.from_service_account_file(
keyfile_path,
scopes=["https://www.googleapis.com/auth/cloud-platform"]
)
# 認証情報を使用してBigQueryクライアントを初期化
client = bigquery.Client(
project=project_id,
credentials=credentials
)

# サンプルデータを準備
rows_to_insert = [
{
"id": "user1",
"name": "Sample User 1",
"email": "[email protected]",
"created_at": timestamp_str
},
{
"id": f"auto_{int(time.time())}",
"name": f"Auto Generated User at {timestamp_str}",
"email": "[email protected]",
"created_at": timestamp_str
}
]
try:
# データをテーブルに挿入
errors = client.insert_rows_json(table, rows_to_insert)
if errors == []:
print("サンプルデータを正常に挿入しました")
else:
print(f"データ挿入中にエラーが発生しました: {errors}")

統合資格分析ダッ
シュボード（GCP）

• https://st-app-credly-504242909255.asia-northeast1.run.app/