継続は力なり

タイトル通り定期的な更新を心掛けるブログです。

『Data Engineering Study #1 』でデータ分析基盤の活用で必要なアクションとデータ活用の実例を聞いた

タダです.

クラウドサービスの活用が増えていく中で企業の扱うデータは増えていって,そのデータを活用できるかって企業活動においてすごく大事だと感じてデータ分析に興味を持ったのですが,データ分析基盤の勉強会「Data Engineering Study #1 」が開催されたので参加してきました.今回の記事では発表を聞いて感じたことをまとめていきます.

forkwell.connpass.com

イベント概要

本イベントでは、ゆずたそ氏( @yuzutas0 )にモデレーターを依頼し、複数回にわたって、各回テーマに沿った内容で各分野でご活躍されているエンジニア/研究者に講演いただきます。

また、講演後には視聴者の方も参加できる二次会会場(Zoom)を用意しています。登壇者と共にデータエンジニアリングに関する学びを深めましょう。

本編動画

当日のツイートまとめ togetter.com

内容

基調講演「Data Platform Guide - 事業を成長させるデータ基盤を作るには

個人的な大ファンである yuzutas0 さん( id:yuzutas0 )の発表でした.僕がデータ分析基盤に関わりたいと思ったのは yuzutas0 さんの下記のエントリーを見たのがきっかけだったりしたので,楽しみでした.

yuzutas0.hatenablog.com

発表は既に発売されている Software Design の記事をベースにされています.発表では企業の中で使われるデータ基盤を作って運用していくための視点とアクションを聞くことができたなと感じました.特に,利用者のニーズと利用シーンに目を向けて利用する人が使ってもらえるように一緒にツールを試したり,提供するデータ基盤のサービスレベルを合意形成していくというメッセージが納得できました.yuzutas0 さん曰くデータ基盤での取り組みは,利用者の目線に立ってテクノロジーを組み合わせていく総合格闘技だというのが今後データ分析に関わりたいと思っている僕にとって胸に刻んでいきたいです.

発表とは別ですが,yuzutas0 さんが執筆されたデータマネジメント本は Kindle Unlimited に加入していれば無料で読めるのですが,データマネジメントに関する知識とアクションをサクッと勉強できるなと感じたので興味ある方は手にとってみてはどうでしょうか?オススメの一冊です!

www.amazon.co.jp

発表資料

事例紹介1「ZOZOTOWNの事業を支えるBigQueryの話」

続いて,ZOZO テクノロジーの塩崎さんの発表でしたが,発表冒頭からロビンマスクが出てきてむちゃくちゃ笑いましたw ごはんですよの人もやられているそうです🍚

発表はデータの基盤として最初は Redshift を使っていたけど BigQuery に置き換えてからの運用のお話と社内での BI ツールの利用例を聞けました.BigQuery の運用話で面白かったのがクエリを投げすぎてお金がかかっていた時に講習をしたり,セキュリティ面での対策は GCP ならではの対応が興味深かったです.yuzutas0 さんの発表でもありましたが,利用者によって BI ツールが様々だっていうお話の通りで ZOZO さんの中でも PowerBI,Looker,Redash,Google Spreadsheet といった各種のツールが利用者によって異なっていているそうです.中でも Looker はよく名前を聞いていたのですが,LookML や LookML のクエリを GitHub で管理してよろしくないクエリを見つけたりといったガバナンスを効かすために使っているというのが BI ツールの利用目的で考えで初めて聞いて驚きでした.

Looker 関連記事 techblog.zozo.com

また,ZOZO さんでは AI の活用が増えてきており鮮度の良いデータを提供して欲しいというところからリアルタイム系のデータ基盤を仕掛かり中とのことです.こちらも気になります.

発表資料

関連資料と記事

codezine.jp

事例紹介2「freeeのデータ基盤におけるDWH/BIの運用事例紹介」

最後に,freee の中山さんの発表で DWH として Redshift,BI として Redash を使っているお話でZOZO テクノロジーさんの事例とはまた違った面白さがありました.個人的に発表で扱われませんでしたが,割愛された一部に使われている GCP や LakeFormation を使って IAM ロールやユーザーベースでカラムレベルのアクセス制御しているお話は気になりました.

Redshift の運用ではデータはマスク処理したり,カラム選別していたり,時に利用者が入れてしまった個人情報データも適切な形にクレンジングしているそうです.コスト面,集計処理の回しやすさ,S3 との連携しやすさがある一方,キャパシティプランニング(気づいたらディスク容量を 100% になっていたりするそうです...)やテーブルのチューニングが必要で苦労する場面もあるようです.Redash の運用において EC2 on Docker で動いていて Mackerel で監視しているようです.組織的に素敵だなと思ったことが freee さんではどの部門の人でも SQL をかけることが求められているからだと思うのですが,変なクエリが少なく運用の負担軽減に繋がっているとのことです.使ってもらえるようになるためには利用者のクエリサポートも必要だなと感じました.

今後の課題に Redshift の ra3 インスタンスタイプを試したり,データカタログの整備や ETL 周りのレガシーな部分をリファクタリングしていきたいとのことでした.Redshift の新しいインスタンスタイプは直近出たばかりなんですね.キャッチアップできてませんでした.

aws.amazon.com

発表資料

まとめ

Data Engineering Study #1 」で聞いた発表ごとに所感をまとめていきました.データ基盤に特化した勉強会ってそうなかったので組織内でのデータの活用の進め方と活用事例を聞けてとても勉強になりました.既に第2回もイベントが公開されているので興味ある方はぜひ参加を検討してみてはいかがでしょうか?📊

forkwell.connpass.com

データを可視化する QuickSight に入門しよう!『セルフBIサービス・販売管理ダッシュボード編』の紹介

タダです.

前回「Basic ハンズオン編」を終えたので今回は,「セルフBIサービス・販売管理ダッシュボード編」を取り組んでみたので学べることやハンズオンでどんな風にデータを可視化できるかをまとめていきます.

sadayoshi-tada.hatenablog.com

ハンズオン概要

セルフBIサービス・販売管理ダッシュボード編」も3部構成になっています.

  1. 販売損益ダッシュボードの作成(予算売り上げ/粗利グラフ作成/売り上げ・粗利達成状況 KPI作成/売り上げ状況表作成/部門検索の追加)
  2. 販売明細テーブルの作成
  3. ドリルスルー設定

ハンズオンの概要としては次の通りです.

  • 販売予算と実績データが入ったyosanjissekidata_u8.csvと部門・親部門のデータが入ったbumonmaster_u8.csvを結合したデータセットの作成
  • 棒グラフ,KPI,ピボットテーブル,テーブルといった表示形式での可視化
    • 条件式書式による表示データへのテキストやアイコンの色付け
    • 可視化したデータの公開
  • 特定の年度や特定の部署にフィルタリングしたデータの抽出・表示
  • 販売損益ダッシュボートと販売明細テーブル間の関連のあるデータのみ絞り込んで表示したい場合におけるドリルスルー設定

ハンズオンで学べること

セルフBIサービス・販売管理ダッシュボード編」を通して次のことを学べました.

  • QuickSight でデータを取り込んで特定の年度の特定の事業部・部署・支店を絞って,データの可視化およびデータの色付け,データの公開方法
  • Basic ハンズオン編」同様に QuickSight でサポートされている関数を使ってフィルタリングして見せたいデータを表示する方法
  • 販売損益ダッシュボートと販売明細テーブル間の関連のあるデータのみフィルタリングする方法

注意点としてハンズオンの制約上 QuickSight を Enterprise Edition で実施する必要があります.QuickSight ユーザーが1人であれば無料枠内ですが,ユーザーを増やす場合は料金に気をつけつつハンズオンをやりましょう.

aws.amazon.com

なお,学びではなく一部ハンズオン資料通りにうまくいかなかった部分がありました.ハンズオンに取り組んでいて yosanjissekidata_u8.csvbumonmaster_u8.csv 間のデータ結合が突然外れたことで,部門データからパラメータを作る時にデータが参照できなくなる事象に当たったので対処しました.ハンズオン上はデータの結合を外すような操作はしてないので通常は発生しないと思います.対応内容としては再度データ結合し直せば参照ができたので,同じ事象に陥った場合はハンズオンの冒頭に戻ってデータを再結合するようにしましょう.

どういう可視化を実現できるか

では,「セルフBIサービス・販売管理ダッシュボード編」のハンズオンでどんなデータの可視化ができるのかを簡単に見ていきましょう.

販売損益ダッシュボード f:id:sadayoshi_tada:20200714051600p:plain

販売明細テーブル f:id:sadayoshi_tada:20200714051613p:plain

販売損益ダッシュボードと販売明細テーブル間のドリルスルー

※2020年10月のデータをフィルタリングした場合 f:id:sadayoshi_tada:20200714051626p:plain f:id:sadayoshi_tada:20200714051656p:plain

まとめ

セルフBIサービス・販売管理ダッシュボード編」の概要,学べることとどんなビジュアライズを作れるのかをまとめました.2020年7月14日時点でのハンズオンを全て取り組んだので自分で用意したデータを可視化してみたいと思っており,次回は東京都が公開しているオープンデータが CSV 形式で提供されているのでこのデータを可視化していきたいです.

stopcovid19.metro.tokyo.lg.jp

コンテナの環境構築とデプロイをサポートする『AWS Copilot』の概念や用語を理解する

タダです.

前回「Copilot CLI」の導入と Get Started の記事を書きました.

sadayoshi-tada.hatenablog.com

今回は, 「AWS Copilot」(以下,Copilot)を理解するためにどんな概念や用語があるかを確認してツールの使い方を整理していきたいと思います.

ツールのコンセプト

Copilot」のコンセプトは下記ページに載ってます.各用語の意義をまとめます.

github.com

Services

Service は Copilot のサポートされている構成を指す用語です.Service のタイプによって構成される環境が決まり,Copilot が Dockerfile の作成と ECR への保存,Manifest ファイルが作られます.

Services Type

Copilot のサービスタイプは2種類です.

  • Load Balanced Web Service
    • インターネットアクセスが必要な場合に選択するサービスタイプ
    • インターネット向け ALB が前段にいて,背後に Fargate の構成を作れる
    • ユースケースとしては ウェブサイトやフロントエンド API
  • Backend Service
    • インターネット経由での接続はできないが,他のサービスからサービスディスカバリーで接続できるサービスタイプ
    • ユースケースとしては 内向け API サービス

github.com

Environments

Environments は実行環境のステージを表す用語です.実行環境はそれぞれ独立しているのでデバッグしたいためのテスト環境を設ける等やりやすいです.copilot env init と実行することで Environments を作れます.例えばテスト環境を作る場合は下記のようにパラメータを使うことで作れます.

copilot env init --name test --profile xxxx --app test-app

lsshow を使えば現在の Environments を確認できます.

» copilot env ls
test

» copilot env show
Only found one environment, defaulting to: test
About

  Name              test
  Production        false
  Region            ap-northeast-1
  Account ID        XXXXXXXXXXXX

Services

  Name              Type
  ----              ----

Tags

  Key                  Value
  ---                  -----
  copilot-application  test-app
  copilot-environment  test

Applications

Applications は Services と Environments の集合体を指す用語です.Copilot を使う時に最初にアプリケーション名をつけます.copilot init を実行した際に一番最初に問われるのが Applications の名前です.Application も lsshow を使うことで現在の Applications を確認できます.

» copilot env ls
test

» copilot app show
About

  Name              test-app
  URI

Environments

  Name              AccountID           Region
  test              XXXXXXXXXXXX        ap-northeast-1

Services

  Name              Type
  front-end         Load Balanced Web Service

Pipelines

Pipelines はリリースパイプラインを指す用語です.Copilot では自動リリースプロセスのセットアップを簡単にすることを目指しています.ドキュメントでは,CodePipeline を使って GitHub にプッシュした後の自動リリースを行うための設定を紹介されています.

github.com

Manifest

そして,Services のアーキテクチャをコードして定義する Manifest も押さえておくべき用語です.前回の記事でも触れていますが,copilot initcopilot svc initを実行した時にcopilot/<サービス名>/ディレクトリ配下に生成されるファイルが Manifest です.manifest.yml のファイルができます.このファイルは CloudFormation テンプレートに変換されるファイルです.CloudFormation テンプレートは通常 JSONYAML 形式で定義しなければなりませんが,その定義作成の負担がないのは大きなメリットだと思います.ドキュメントのページには Load Balanced Web Service と Backend Service の Manifest ファイルの定義が載っているのでどんな感じかの参考になります.

github.com

まとめ

ツールのことを知るために「Copilot」の概念や用語を整理しました.公式ブログでも「Copilot」のことがアナウンスされました.今後のツールとしてよりよくしていくため「Copilot CLI」を使ってみてフィードバックや機能リクエストをしていきたいですね! 次の記事ではCLI コマンドとそのオプションがどんなものがあり,どんなことができるのかを書きたいと思います.

aws.amazon.com

aws.amazon.com

【Athena の躓きシリーズ】CloudTrail ログの中から API コール数を集計する Athena のクエリ

タダです.

業務で Athena を使ったログ解析で詰まったことがあったら都度記事にクエリの結果とその対処をまとめるシリーズをやってます.今回は CloudTrail ログの中から特定の API コール数がどこから発信されているかを確認する必要があった時の学びをこの記事で書きます.

API コール数の集計の対象

今回は API コール数の集計の対象として CloudTrail のログの中で eventTime (いつ),eventSource(どのサービスにリクエストが行われたか),userAgent(どこから)のデータを確認しました.

docs.aws.amazon.com

さて,データを確認するためにテーブルを作ったのですが,当初CloudTrail のログデータが1年以上溜まっているシステムだったので,全検検索すると読み取り処理がタイムアウトしました.そのため,ログで確認したい期間が2020年のログだったので2020年のフォルダを検索するようLOCATIONの指定を変更し作り直して対処しました.

docs.aws.amazon.com

テーブル作成用クエリ例

CREATE EXTERNAL TABLE [テーブル名] (
eventversion STRING,
useridentity STRUCT<
               type:STRING,
               principalid:STRING,
               arn:STRING,
               accountid:STRING,
               invokedby:STRING,
               accesskeyid:STRING,
               userName:STRING,
sessioncontext:STRUCT<
attributes:STRUCT<
               mfaauthenticated:STRING,
               creationdate:STRING>,
sessionissuer:STRUCT<  
               type:STRING,
               principalId:STRING,
               arn:STRING, 
               accountId:STRING,
               userName:STRING>>>,
eventtime STRING,
eventsource STRING,
eventname STRING,
awsregion STRING,
sourceipaddress STRING,
useragent STRING,
errorcode STRING,
errormessage STRING,
requestparameters STRING,
responseelements STRING,
additionaleventdata STRING,
requestid STRING,
eventid STRING,
resources ARRAY<STRUCT<
               ARN:STRING,
               accountId:STRING,
               type:STRING>>,
eventtype STRING,
apiversion STRING,
readonly STRING,
recipientaccountid STRING,
serviceeventdetails STRING,
sharedeventid STRING,
vpcendpointid STRING
)
PARTITIONED BY (region string, year string, month string, day string)
ROW FORMAT SERDE 'com.amazon.emr.hive.serde.CloudTrailSerde'
STORED AS INPUTFORMAT 'com.amazon.emr.cloudtrail.CloudTrailInputFormat'
OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat'
LOCATION 's3://CloudTrail_bucket_name/AWSLogs/Account_ID/CloudTrail/ap-northeast-1/2020/'; <= 変更箇所

API コール数を集計するクエリ例

テーブルができたのでクエリを投げていくのですが,結論としては次のようなクエリでデータを取れました.

SELECT DATE_FORMAT(from_iso8601_timestamp(eventTime), '%Y-%m-%d') AS EventDate, eventSource, userAgent, COUNT(*) as APICount
FROM "DB名"."テーブル名"
WHERE eventName='CreateBucket(検索したいAPI名)'
AND eventTime > '2020-07-01T00:00:00Z(検索したい期間.左は7/1以降が対象期間の例)'
GROUP BY DATE_FORMAT(from_iso8601_timestamp(eventTime), '%Y-%m-%d'),eventSource, userAgent
ORDER BY EventDate ASC;

クエリのレスポンスとして以下のような結果が返ってきます.

EventDate|eventSource|userAgent|APICount|
2020/7/7|s3.amazonaws.com|athena.amazonaws.com|1|

ハマりポイント

今回ハマったのは,eventTimeのフォーマット変更して集計したかったのですが,その際に CloudTrail のタイムフォーマットがiso8601形式(2014-03-06T21:22:54Z形式)であると知らずに苦戦しました.Athena のクエリエンジンは Presto になっていますが,Presto の関数に iso8601 用の from_iso8601_timestamp 関数があったのでこちらを使って対応しました.

prestodb.io

まとめ

CloudTrail ログの中から特定の API コール数を集計するクエリ例とハマったポイントを整理しました.今後も Athena を使っていたハマりポイントをまとめて同じ事象に当たった方や参考情報をまとめていければと思います!

関連記事

sadayoshi-tada.hatenablog.com

データを可視化する QuickSight に入門しよう!『Basic ハンズオン編』の紹介

タダです.

QuickSight のハンズオンキットが公式ブログでアナウンスされていたのですが,QuickSight をあんまり使ったことがなかったのでこのハンズオンシリーズを通して QuickSight の使い方を学んでいきます.今回は,「Basicハンズオン編」を取り組んでみたので学べることやハンズオンでどんな風にデータを可視化できるかをまとめていきます.なお,他のコンテンツとして「販売管理ダッシュボード編」もリリースされています.

aws.amazon.com

ハンズオン概要

Basicハンズオン編」は3部構成になっています.

  1. 基本的なビジュアライズの実践,クイックフィルタの設定,セルの色を変えるコンディショナルフォーマットの実践(パート1)
  2. フィルタの設定,計算フィールドの利用,ML インサイトによる異常検知と自動ナラティブの作成(パート2)
  3. Level-Aware Aggregation(LAA)機能を使った分析(オプションパート)

ハンズオンの概要としては次の通りです.

  • QuickSight でユーザー登録後,データセットを取り込んで棒グラフ,円グラフ,ピボットテーブル等で可視化
    • データセットには病院の患者データが入っているPatient-Info.csvと地域ごとの社員データが入っているAssign.csvが入ってます
  • QuickSight の ML インサイトの機能を使ってデータの推移予測や異常検知の体験
  • Level-Aware Aggregation(LAA)機能を使った分析の体験

ハンズオンで学べること

Basicハンズオン編」を通して次のことを学べました.

  • QuickSight でデータを取り込んで様々な表やグラフで可視化
  • 表示するデータも QuickSight でサポートされている関数を使ってフィルタリングして見せたいデータを表示
  • 可視化したデータを何もコーディングしなくても未来の予測値や異常検知をサクッと表現する方法

注意点としてハンズオンの制約上 QuickSight を Enterprise Edition で実施する必要があります.料金は気をつけつつハンズオンをやりましょう.

aws.amazon.com

どういう可視化を実現できるか

では,ハンズオンでどんなビジュアライズができるのかを簡単に見ていきましょう.今回僕はオプションパートを除いたものになりますが,ほとんど BI を使ったことがない状態でもハンズオンで こういった可視化ができました.

パート1で作ったもの f:id:sadayoshi_tada:20200706193724p:plain

パート2で作ったもの f:id:sadayoshi_tada:20200706193735p:plain

まとめ

Basicハンズオン編」の概要,学べることとどんなビジュアライズを作れるのかをまとめました.BI ツールは企業では様々な部門の人が見て各部門ごとの意思決定などに使うので,いかに見やすくわかりやすい表示にしていくかが肝と思うのですが,ツールの使い方を細かく学べるハンズオン資料の存在はありがたいです.僕と同じように QuickSight を学びたいと思っている人やハンズオン教材のことを知らなかった人が知るきっかけになれば嬉しいです.次は「販売管理ダッシュボード編」に取り組んでいきたいです.

関連情報

本ハンズオンと合わせて7/9にでる「AWSで始めるデータレイク」も学んで実践していけるとデータの利活用にチャレンジできそうです!

www.amazon.co.jp