JAPAN - AWS | Contact Us ·...

J A P A N

© 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.

「ふくおかＦＧＤＸ推進基盤の構築」～おいしいデータレイクの作り方～

常盤和宏

ふくおかフィナンシャル・グループ

おしながき

• 準備編これからデータレイクを作る方向け

• 調達編〃

• 調理編データレイクを構築中の方向け

• 実食編データレイクを運用中の方向け

• 調理法レシピの一例を公開

• DXは企業が生き残るための進化あらゆる企業・組織が、持続可能な社会に向けて転換する

デジタル技術を利用して、現実にある社会問題を解決する

• 事業部門が主人公となりベンダと共創する従来はIT部門が先導してデジタル技術を活用していた

これからは事業部門が競争優位性を上げるために導入する

• PDCAではなくDCPAサイクルで推進するアイデア生成から意思決定までを俊敏に実行できる体制

やってみて(Do),検証して(Check),正式に計画して(Plan),具体的に進める(Action)

DXを推進するためにはDXは「アイデア」✕「テクノロジー」✕「挑む力」

note: 日本ではエンジニアなどのITの専門家の75%

がITベンダ企業に属し、ユーザ企業に属する割合は、わずか25%。世界はこの状況とは真逆であり、ITの専門家の70%以上がユーザ企業に属する。

note: DXは企業の新しい価値を創出することなので、IT部門やベンダに丸投げしない。

• AIの時代が訪れ産業構造を大きく変えているAIを活用するには、ビッグ・データの蓄積・整備・意味付けが必要

ビッグ・データを正しく理解、分析し、使いこなす組織への変革が急務ビッグ・データは経営資源となり、新たな価値をもたらす

• 可視化、創造、予測情報を可視化する

ビッグ・データを分析することで顧客ニーズ、経営状況など様々な「情報が見えてくる」

歴史を知り未来を創る

ビッグ・データを活用し、新たなビジネスモデル、業務効率化など自社に「変化をもたらす」

中長期の予測を可能とする

分析をもとに顧客に新たなサービスを提供したり、品質向上により「競争優位性を確保する」

ビッグ・データの必要性これからの時代はビッグ・データ活用がビジネスを変えていく

可視化

創造予測

ビッグデータ

• DX推進のためのビッグ・データ分析基盤の整備「データレイク」＋「高度分析環境」

① 社内のデータ群を、見極め、浄化し、「データレイク」に集約する

② ビッグ・データを高速に分析できる「高度分析環境」を構築する

③ この環境を活用して「デジタル人財」を育成する

• 分析基盤を活用した顧客中心アプローチの実現新商品・サービスの創出

ビジネス仮説の試行的な検証

AIによるデータ活用

既存事業の高度化・収益化

事業部門間の協業・共創

変容に俊敏に応じる柔軟性

データレイク構築の目的人が環境をつくり、環境が人をつくる

事業部門

KPI

事業部門

事業部門

事業部門

高度分析環境

データレイク

顧客中心アプローチ

• DX推進ガイドライン(経産省)より抜粋体制・仕組み

複雑化・ブラックボックス化しない

ユーザ企業自らがシステム連携基盤の企画・要件定義

実行プロセス

ビジネス環境の変化に対応

共通プラットフォーム

経営環境の変化に対応して廃棄

技術負債※の低減

ビジネスモデルの変化に迅速に追従

• 調達方針の決定リーン・スタートアップとしてAWS cloud platform serviceを選択

分析基盤に求められるものアマゾンウェブサービス(AWS)のマネージド・サービスのみで実装

https://www.meti.go.jp/press/2018/12/20181212004/20181212004.html

note: 技術負債短期的な観点でITシステムを開発し、結果と

して、長期的に運用費や保守費が高騰し、支払い続けることを意味し、一種の負債ととらえられる。

https://www.meti.go.jp/press/2018/12/20181212004/20181212004.html

• AWSサービス機能の調査と資料化・共有化

• 試行環境の構築と検証・要件抽出

• ベンダへの要件提示と共創

AWSの徹底的なリサーチ彼を知り己を知れば百戦殆うからず

データレイク調達時の要員と作業ボリューム・人数：３人（AWS初心者）・調査(資料化)：２ヶ月（２０機能）・試行環境構築：１ヶ月・要件書作成：１ヶ月（１００ページ）

• あれこれ試すことの重要性知ることの重要性を知る

• 想像力の重要性使う人のことを考える

• メモを取ることの重要性開拓者はパンくずの道標を残す責務を追う

試行に次ぐ試行失敗は成功の素

Thank you always.・AWS SA and Support・classmethod(Qiita)

データレイク構成図データレイクにおけるAWSの各種マネージドサービスの構成

AWSGlue

On-premises

NFS

DB

sas7bdat

Excel

CSV

AWS Cloud

Dire

ct Co

nn

ect

AmazonRDS

AmazonS3

Cold Warm Hot

AWSGlue

中継

AWSLambda

AmazonSageMaker

AWSCloud9

QuickSight

AmazonS3

(Parquet)

AWSGlue

AWSGlue

AmazonAthena(CTAS)

AmazonAthena(CTAS)

AWSLambda

Amazon API Gateway

Peering

AmazonAthena

AmazonRDS

SFTP

SQL

AmazonS3

(Parquet)

AmazonS3

(Parquet)

AWSCode

Commit

AmazonECR

データレイク構成図社内からデータレイクへデータを移出・移入する領域

AWSGlue

On-premises

NFS

DB

sas7bdat

Excel

CSV

AWS Cloud

Dire

ct Co

nn

ect

AmazonRDS

AmazonS3

Cold Warm Hot

AWSGlue

中継

AWSLambda

AmazonSageMaker

AWSCloud9

QuickSight

AmazonS3

(Parquet)

AWSGlue

AWSGlue

AmazonAthena(CTAS)

AmazonAthena(CTAS)

AWSLambda

Amazon API Gateway

Peering

AmazonAthena

AmazonRDS

SFTP

SQL

AmazonS3

(Parquet)

AmazonS3

(Parquet)

AWSCode

Commit

AmazonECR

データレイク構成図データを精錬しながらデータレイクとして完成させる領域

AWSGlue

On-premises

NFS

DB

sas7bdat

Excel

CSV

AWS Cloud

Dire

ct Co

nn

ect

AmazonRDS

AmazonS3

Cold Warm Hot

AWSGlue

中継

AWSLambda

AmazonSageMaker

AWSCloud9

QuickSight

AmazonS3

(Parquet)

AWSGlue

AWSGlue

AmazonAthena(CTAS)

AmazonAthena(CTAS)

AWSLambda

Amazon API Gateway

Peering

AmazonAthena

AmazonRDS

SFTP

SQL

AmazonS3

(Parquet)

AmazonS3

(Parquet)

AWSCode

Commit

AmazonECR

データレイク構成図データレイクを使用して、分析やシステム・アプリケーションを開発する領域

AWSGlue

On-premises

NFS

DB

sas7bdat

Excel

CSV

AWS Cloud

Dire

ct Co

nn

ect

AmazonRDS

AmazonS3

Cold Warm Hot

AWSGlue

中継

AWSLambda

AmazonSageMaker

AWSCloud9

QuickSight

AmazonS3

(Parquet)

AWSGlue

AWSGlue

AmazonAthena(CTAS)

AmazonAthena(CTAS)

AWSLambda

Amazon API Gateway

Peering

AmazonAthena

AmazonRDS

SFTP

SQL

AmazonS3

(Parquet)

AmazonS3

(Parquet)

AWSCode

Commit

AmazonECR

データレイク構成図データレイク内で開発したアプリケーションを外部へAPIとして公開する領域

AWSGlue

On-premises

NFS

DB

sas7bdat

Excel

CSV

AWS Cloud

Dire

ct Co

nn

ect

AmazonRDS

AmazonS3

Cold Warm Hot

AWSGlue

中継

AWSLambda

AmazonSageMaker

AWSCloud9

QuickSight

AmazonS3

(Parquet)

AWSGlue

AWSGlue

AmazonAthena(CTAS)

AmazonAthena(CTAS)

AWSLambda

Amazon API Gateway

Peering

AmazonAthena

AmazonRDS

SFTP

SQL

AmazonS3

(Parquet)

AmazonS3

(Parquet)

AWSCode

Commit

AmazonECR

• Edge移入データの関所。スキーマ(型/桁)を維持するために、RDSを介す

• Cold移入データの保管所。Parquet形式にて保管する。RDS->S3のExtract/Loadが主体。

• Warmデータレイク本体。Coldデータを精錬して格納する領域。S3->S3のTransformが主体。

• Hotデータウェアハウス(DWH)、データマート(DM)。Warmデータを加工して格納する領域。

• Parquet（columnar storage format）の採用並列分散性能を向上するために、

パーティショニング・バケッティングを最適化

Edge/Cold/Warm/Hot“データの沼”にしないために

• オンラインデータの移出入① オンラインデータ(DB2)を､社内のETL処理にてEdge RDSへ移出

② Lambdaで社内ETL処理の完了を検知し、Glue Workflowsをキック

③ Glue Workflowsにて、 Edge RDS -> Cold S3 -> Warm S3の一連のETL処理を実行

ビッグデータの移出入千里の道も一歩から。移出入の完全自動化への道程。

①

②

③

③

①

②

③

③

• オフラインデータの移出入① 過去のオフラインデータ・セット(Sas7bdat)を､SFTPにてEdge S3ヘ移出

② Glue Job(Python)にて、Edge S3内のデータセットを順次Edge RDSヘ移入

③ Edge EDSへの移入完了後、Glue Workflowsをキックし、一連のETL処理を実行

ビッグデータの移出入千里の道も一歩から。移出入の完全自動化への道程。

①②

③

③

①②

③

③

• データサイエンティストのための個室研究環境インスタンスタイプ変更、ライフサイクル変更による、個室ごとの増改築が可能

Pythonライブラリなどのインストールを自由化

CodeCommit(Git)との連携による研究者間のリソース共有

カスタマイズされた機械学習コンテナ(ECR)の整備と提供（銀行特有のアルゴリズム最適化）

Amazon SageMaker静かで快適な個室環境

AWS Cloud9賑やかでパワフルな共創環境

• プロジェクトルームとしてのCloud IDE統合開発環境プロジェクトごとに環境を整備しCode Commit(Git)によってリソース共有

社内、在宅、リモート勤務などを問わずチーム開発、ペアプログラミングを実現

Glue Job(python)、Lambda、Lambda Layerなどの開発も集約、Deploy自動化

オンライン、バッチ、API開発を支援

プロジェクトルームワイガヤでリモートでペアプロ

AWS Lambdaさっとやって、さっと帰ろう

• 分析基盤の運用ツールとして活用時間指定によるインスタンスの一斉停止・起動（働き方改革・コスト削減）

行内からのデータ移入監視によるGlue ETL処理のキック（TCO削減）

利用者増加時の環境自動作成（TCO削減）

移入状況サマリ処理などのboto3を使用した簡単なバッチ処理の実行（TCO削減）

定時一斉停止・起動移入監視・起動環境自動作成定時集計処理

FaaS(Function as a Service)でがっちり！

• 分析基盤で開発した機能・サービスをAPI公開 API Hubなるデータレイクの出島を作成し、外部とのAPI連携を実現

データレイクのセキュリティ・堅牢性を維持しつつ、外部との連携を可能に

機械学習モデルによる与信スコアリングAPIを自社のオルタナティブ融資サービスへ提供

サーバレスなので、運用負担ゼロ、費用も使った分だけ、MVP(Minimum Viable Product)に最適

AWS Cloud

Hot

AWSLambda

AWSCloud9

AWSLambdaAmazon API Gateway

Peering

AmazonRDS

Deploy

リーンスタートアップの最適解!

AWS Lambda

AWS Glue速い、安い、美味い

• 完全マネージド型のETLサービス（Spark Shell）速い：数千万件のトランザクションデータも十数分で処理

安い：ジョブごとにDPU数を調整でき、使った分だけの時間課金

美味い：Pythonコードなので痒いところに手が届く

3000万件のETL処理でもわずか13分(0.38USD)

DPU数が３では足りず、４に変更して実行

速い、安い、美味い

• ETL汎用スクリプトを開発しGlue Jobを大量生産日次、月次で大量の社内データ(数TB)の差分を移入する必要があった

数百テーブル✕３銀行分のGlue Job/Workflowを手動で作成することは非現実的

Edge(RDS)->Cold(S3)->Warm(S3)->Hot(S3)のそれぞれの汎用スクリプトを作成

パラメータ＋汎用スクリプトの組み合わせでGlue Jobを大量生産

メイン処理はこれだけ

外部からのJob パラメータに基づくETL処理

AWS Glue

集めてはやし最上川

• Glue Workflowsによる一連のETL処理の自動実行トリガによる自動起動

カタログ最新化のためのCrawlerの実行

開発用、本番用への日次データの同時デリバリー

開発用、本番用データデリバリ

カタログ最新化

AWS Glue

ETLだけに使うなんてもったいない

• 業務のバッチ処理開発に採用（Python Shell） Lambdaの15分の壁をGlue Job(python)で解決

Cloud9で業務処理を開発・テストし、python パッケージ化

他のPython Libraryと合わせてGlue Job実行時にインストールするだけ

処理の大部分はパッケージ化されているので、Glue Job(スクリプト)はこれだけ

AWS Glue

Amazon Athena戦略を司るギリシア神話の女神

• サーバレスのクエリサービス、これぞデータレイクの意義社内では数日かかる集計処理が秒で完了

機械学習のための前処理や、Adhocな特徴量生成が高速に実行でき、試行錯誤を支援

件数(Count) 19億レコード

合計(Sum)実行時間：34秒スキャン：6.5GB(5円未満)

戦略を司るギリシア神話の女神

• ParquetのPartitioningやBucketingが性能最適化の鍵Where句などで使用される項目を設定することでスキャン数を削減できる(index的な意義)

Partitioning

データを複数のパーティション(フォルダ)に分割保存すること、負荷の水平方向への分散

Bucketing

データをパーティション内に複数のファイルとして分割保存し、負荷分散

https://aws.amazon.com/jp/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/

https://docs.aws.amazon.com/ja_jp/athena/latest/ug/bucketing-vs-partitioning.html

Partitioning：year/month/day etc

Bucketing ：顧客ID etc

Amazon Athena

https://aws.amazon.com/jp/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/

https://docs.aws.amazon.com/ja_jp/athena/latest/ug/bucketing-vs-partitioning.html

Amazon Athena ✕ Amazon SageMaker戦略を司るギリシア神話の女神もびっくり

• 必要なものは自分たちで創る Athena APIのpython wrapper class

クエリ結果のダウンロード

DataFrameヘの読み込み

CTAS(Create Table As Select)クエリの実行

CTASクエリのOverwrite処理の実装

クエリを書いて、メソッドを実行するだけ

DataFrameに読み込み

処理時間、スキャン量、料金目安などをログ出力

総評総じて、素質充分だが荒削り、プロ仕様でコンソールなどはなおざり

• 機能～そのものが持っている働き～

◎ セキュリティを維持しつつ、データレイクおよび分析基盤として充分な機能を提供できる

△ 全体的にコンソール機能が弱く、実運用するためには補完する運用ツール開発が必須

• 性能～そのものが持っている能力～

◎ 社内より高速な処理が可能になり、データドリブン、試行錯誤を支援できる

△ 現時点では、大規模運用に難がある（API粒度、AWSコンソールの表示速度）

• 仕様～ものを作る際に決めた設計～

◎ マネージドサービスを組み合わせることで、安価で迅速な開発が可能

△ サービス間でAPI仕様にゆらぎや差異があり、不統一感が否めない

• 品質～一連の固有の特性が要求事項を満足している度合い～

◎ サービス毎に充分な要求機能・性能を満たしており、日々改善も行われている

△ 個々のサービスが競争、アジャイル開発されおり、改善スピードに不均一感が否めない

キャリア採用来たれ！福岡へ！一緒にDXしよう！ https://www.fukuokabank.co.jp/employment/careers/

・クラウド基盤技術者

・データサイエンティスト

・データエンジニア

・UI/UXデザイナー

・スクラムマスター

・Dev/Opsエンジニア

・ビジネスストラテジスト

・銀行業務全般

高速サーキット場完備！求む！ドライバー！

https://www.fukuokabank.co.jp/employment/careers/

Thank you!


Kazuhiro Tokiwa

[email protected]

差分処理のレシピ RDS(Edge)->S3(Cold) Extract処理

AWS Glue

AWSGlue

AWS Cloud

AmazonRDS

Cold Warm

AmazonS3

(Parquet)

AWSGlue

AmazonS3

(Parquet)

RDS JDBCからの並列読み込みのオプションに対応{“hashfield”: “TransactionID“,"hashpartitions":"10"}

差分処理のレシピ RDS(Edge)->S3(Cold) Transform処理

AWSGlue

AWS Cloud

AmazonRDS

Cold Warm

AmazonS3

(Parquet)

AWSGlue

AmazonS3

(Parquet)

標準のTransform処理はもとより、文字列の前後の空白除去などを拡張

AWS Glue

差分処理のレシピ RDS(Edge)->S3(Cold) Load処理

AWSGlue

AWS Cloud

AmazonRDS

Cold Warm

AmazonS3

(Parquet)

AWSGlue

AmazonS3

(Parquet)

Glue Jobパラメータに準じて、パーティション数を自動計算・設定

AWS Glue


AWSGlue

AWS Cloud

AmazonRDS

Cold Warm

AmazonS3

(Parquet)

AWSGlue

AmazonS3

(Parquet)

パーティション列の生成（日付列）※基本的には日付列を使用する

AWS Glue


AWSGlue

AWS Cloud

AmazonRDS

Cold Warm

AmazonS3

(Parquet)

AWSGlue

AmazonS3

(Parquet)

パーティション列の生成（オプション列）※均等分散するようにHash列化も支援

上書きLoad処理（dynamic overwrite）※差分処理を実現するためには必須

AWS Glue

ワーカータイプの選択がビッグ・データETLの肝

• ワーカータイプの選択 Standard

Maximum capacityを指定する。いわゆるデータ処理ユニット (DPU) の数。

DPUの構成は、4vCPU・16 GB Mem・50 GB Disk・2 Executer。

G.1X

Number of workersを指定する。

workerの構成は、1DPU・4vCPU・16 GB Mem・64 GB Disk・1 Executer。

Maximum capacity = Number of workers * 1 + 1となる。すなわち総DPU数+1。

G.2X

Number of workersを指定する。

workerの構成は、2DPU・8vCPU・32 GB Mem・128 GB Disk・1 Executer。

Maximum capacity = Number of workers * 2 + 1となる。すなわち総DPU数+1。

移入データ量が増えるとメモリが足りなくなるため、Standard->G1.X->G2.Xと変更する

AWS Glue

パーティショニングがビッグ・データETLの肝

• repartition時のnumPartitionsのベストプラクティスrepartitionメソッドは、各パーティションの要素が均等になるようにシャッフルし、numPartitionで指定したファイルに分割する。

Standard

{([number of DPU] - 1) * 2 - 1} * 4

G.1X

{([number of DPU] - 1) - 1} * 8

G.2X

{([number of DPU] / 2 - 1) - 1} * 16

Glue Jobのジョブパラメータに従って自動設定するようにスクリプトを開発した

AWS Glue

SageMakerでGlue Job Python Scriptの開発レシピ

Amazon SageMaker

/tmpにPython Libraryをインストールする準備この技はCloud9でも使用可能

開発・テストが完了したら、pyファイルにしてGlue Job化するだけ

/tmpに必要なライブラリをインストールする

LifecycleによるNbExtensionの導入レシピ

設定を復元、共通化するために、notebook.jsonをコピーするのを忘れずに

５分は短すぎる！ので、バックグラウンドインストール化

Amazon SageMaker

Lambda Layerの作り方レシピ

AWS Cloud9

そのまま使ってください

JAPAN - AWS | Contact Us ·...

Documents

Transcript of JAPAN - AWS | Contact Us ·...