クラウドインフラ構築記

現在AWSの構築支援に携わっております。今注視しているのは、GKE、BigQuery、Google Dataflowなどサービスを展開しているGoolge Cloud Platformです。

『Amazon Redshift』での本格データ分析~ここまで来た、クラウド型DWH~セミナーに参加しました。

『Amazon Redshift』での本格データ分析~ここまで来た、クラウド型DWH~セミナーに参加しました。

Amazon の松本様からRedshiftについての話

  • Redshiftは2PBまで使用できる。(これ以上使いたい場合は、相談に応じるとのこと)
  • Redshiftは縦指向。RDSとは異なる。集計に最適
  • S3からRedshiftにロードさせるのが基本的な使い方
    • Lambdaを使うことでイベントトリブンでロードする方法も可能だが、S3にcsvなりデータ取り組むとで、データがRedshiftにロードできてしまうので、変なデータが置かれてもデータがロードされてしまうことが起こりうるので、気をつけないといけない。Lambdaのスケジュールトリブン(スケジュールによるイベント発火)が望まれる。

ウルシステムズ 吉田悦万様からデータ分析システム導入のポイントについて

 

ウルシステムズが提供している、オールインワン型のクラウドDWH Whte-eYeの紹介から

お客様ごとに要件を合わせて提供

 必要なAMIを組み合わせて短期間で構築

 事例として、ショッパーインサイトの「 POSデータの分析システム」で移行前だと以下問題を抱えていたのをクラウドに移行することでどう解決したかの話

  • 大量のデータだとパフォーマンスがでないとか
  • オンプレで運用していたのをクラウドに移行
  •  データ量が多い。パフォーマンスがでない →3,000億件
  • チューニングで対応
  • 可用性の要件が高い →自社内でやることが多い。信頼性の高いシステムが求めれていた
  • 負荷も考慮
  • 複雑で多様な要件 バスケット分析とか多様な分析

 フラストレーションが溜まっていた。

 

次に、分析システムを導入する場合のポイントについての話

  • 経営層を説得できない

→投資対効果が見えにくい。

  • 競合他社の動向を説明し、ホラーストーリーで説得

→スモールスタートする企画

→システムのライフサイクルを踏まえたコスト比較

→クラウドのコストメリット 3,4,5年を見据えて。オンプレだとインフラのマイグレーションとの比較も含めてコスト比較のがいい

 BIG DATA LANDSCAPE (→ここ

→BIG-Dataはコンポーネント(部品)が多岐に渡っている

  • 使ってみるのがよりよいものを見つけるのがオススメ
  • パフォーマンスが出ない

ある程度は、チューニングをしなくても出ますが、データ量が多くなるとチューニングは必要になる

チューニングすることで、処理も速くなり、リソースの使用時間も減る。つまりは利用料にも跳ね返ってくる

  • チューニング

Sortkey カーディナリティの低いものに有効

ディスクの利用率などて適切な圧縮エンコーディングで

 Distkeyは、データを投入してから検証

 分散されているか指標があるので、データ投入後に確認する

  •  データ連携の開発が時間がかかる

共通部品を作って開発をするのがポイント

  •  Cloudwatchだけでは不十分、あるスライスの容量は監視できない
  •  ディスク容量のサイジングミス

定期的にVACUUM使わないと

多量のデータ扱っているとそんなにVACUUM時間がかかるのでそんなに実行できないSELECTのサブクエリー

メモリに展開できない場合、ディスクフルのエラーが発生する

 十分容量を確保した設計が重要

ロングランテスト。ディスク容量のグラフ化

 列数が多いテーブルでVACUUMを実行するとエラーになる可能性がある

 ERROR 1036 DETAIL: Vacuum clumn limit exceded

→VACUUMの間だけ、wlm_query_slot_count の値を上げる

 本番機のパラメータを変えたくないので、DEEP COPY でこれで解決しているとのこと

  •  PostgreSQL 8.xのJDBCドライバーを使うと、21億件を超える行数を更新するとエラー
    • PostgreSQL 9.x系のドライバを使うことで解決

コメントは受け付けていません。