/home/by-natures/dev*

ソフトウェア開発者としての技術的なメモと、たまに普通の日記。

2019/01/22-23 AWS Glue Crawler が struct をカラムに持つテーブルに使いづらい

AWS Glue を色々と触っているのですが、どうにも正しい使い方がよく分からなくなってきました。

Glue Job で Parquet フォーマットで書き出して Athena から読み込みたいのですが、パーティションによってキー数が大きく異なる JSON 形式のカラムがあるためにうまくいきません。統一的に扱うなら string にして保存してしまえば良いんですけど、そうすると SparkSQL で上手く扱えない(SparkSQL で string を JSON として扱う方法があれば教えてください ありました、get_json_object 関数を使うことで string 形式の JSON からバリューを抜き出すことができました。)。

Glue Job で string ではなく struct で書き出すと、Glue Crawler がパーティションごとに異なるスキーマを生成してしまい、テーブル全体としてスキーマが一致しない(incompatible) ので Athena で読めない。その場合のエラーは HIVE_PARTITION_SCHEMA_MISMATCH なので、回避方法はあります:

https://forums.aws.amazon.com/thread.jspa?messageID=805011

Athena と AWS Glue を併用する際のベストプラクティス - Amazon Athena

stackoverflow.com

ただこれを回避すると、別の HIVE_CANNOT_OPEN_SPLIT というエラーが。私の環境では Schema mismatch, metastore schema for row column contents has 185 fields but parquet schema has 149 fields と出ます。色々 Glue Crawler 上で試しましたが回避方法は見つかっていません。

adtech-blog.united.jp

結局、struct を使うのが問題の根源なので、 string か、せめて map<string,string> のようなもう少し汎用的な形で保存できればよいなと思っています。これなら Crawler ではなく MSCK REPAIR TABLE コマンドでパーティション追加するだけでいけるはず。ただこれを Glue Job(PySpark) で実現する方法がまだ分かりません。

Glue は便利そうだなと思っていましたが、Crawler のようなデータ管理をよしなにやってくれるサービスが上手くいかないと逆に検証に時間を取られて徒労に終わってしまうなぁと思った今日この頃。。結局 Spark でのデータ変換をきちんと勉強して地道に変換した方が早い気がしています。

追記

上で記載しましたが、 get_json_object という関数を利用することで string 形式の JSON からバリューを抜き出すことができました。とりあえずこれで、 Glue Job で string 形式で保存した上で、あとから SparkSQL でアクセスすることができます。

API ドキュメントはこちら。先週結構探したつもりだったんですが、今日さがしたらすぐに見つかりました。。

spark.apache.org

2019/01/15 Glue における SQL 中心アーキテクチャ ETL、他

昨日居酒屋で飲んでいたら(かぶら屋 美味しいです、おすすめ)、隣の席の人が UberEATS の使いすぎで他の方から怒られていました。僕の友人でも UberEATS や LINE デリマを良く使う人はいるので、別にいいんじゃないかなと思ったら、どうやら人はタクシーやデリバリーなどの細かい出費の積み重ねで借金をしてしまった?ようです。

借金とは言わないまでも、昔はなかった通信費は今やもはや固定費になっているし、便利さと引き換えに可処分所得は減っているという記事をどこかで見たような気がしたなぁと思った週末でした。

「AWS Glue と SQLのみで、サクッとETL(Extract、Transform、Load)するJobを作成する」

dev.classmethod.jp

Glue のジョブはGlue が提供する Transform を利用しないといけないと思っていましたが、 入出力の雛形ジョブだけ Glue に用意して、SparkSQL を外部から設定できるようにすれば「SQL中心アーキテクチャ」による ETL が簡単に実現できるといった内容です。

外部(S3 上に置いておく想定)の設定ファイルは以下のようなものです:

{
    "source_database":"default", 
    "source_table":"elb_parquet_20150101", 
    "target_s3_url":"s3://<mybucket>/tmp/", 
    "target_format":"parquet", 
    "sql":"SELECT elb_name, count(*) as request_count FROM stagingtable group by elb_name order by elb_name"
}

これを S3 から読み込んで JSON パースして Glue 上で SparkSQL を実行します。これだと1テーブルしか扱えないので複数テーブル与えられるようにフォーマットを変更したいですが、これなら SQL だけ書ければ ETL 処理が実現できるので扱える人が増えそうです。

ただ、ETL ジョブの依存関係を解決しようとすると Glue だけでは難しそうです。Glue にも「トリガー」があって、他のジョブへ依存するジョブを作成できるのですが、パラメータレベルでは対応していないので、上のように SQL をパラメータ経由で渡すような運用だと「トリガー」では対応できません。

「Glueの使い方的な⑦(Step Functionsでジョブフロー)」

こちらも分かりやすい記事でした、Glue + Step Functions の組み合わせです。Glue の呼び出しには Lambda を使っています。

qiita.com

ワークフローが巨大だと GUI でも JSON でも扱いづらそうなので、ある程度意味のあるまとまりでまとめておく程度にした方がよさそうでしょうか。。CloudWatch を使えばワークフロー間の連携も実現できそうなので引き続き調べます。

2019/01/11

ご挨拶が遅れました、あけましておめでとうございます。

年の始まりはいつも不思議な出来事があって、今年はこういう感じなのか、と思うことがあります。今年は変わったことがちらほら周りで起きていて、変化の年になるのかもしれません。よい方向に変化するように少しずつの積み重ねで勉強だけは一層取り組もうと思います。去年部署移動してチーム開発が始まるかもしれないので、今年はソフトウェア設計についてもう少し詳しくなりたいです。

知り合いから語学の才能があるとよく言われるので、そちらももっと活かしたいなぁという思いが最近強いのですが、学習は継続しつつどこかキャリア内でも使えればよいなぁと思う昨今。

AWS Glue

Glue について色々調べているのでメモ。

qiita.com

Spark の DataFrame との違いが冒頭に書いてあります。

docs.aws.amazon.com

docs.aws.amazon.com

Spark

Spark 直接扱ったことがなくて、Glue で Python から Spark を動かすと大量に小さいファイルができてしまいました。Hive のように適切なファイルサイズでファイル出力する方法はないかと調べていましたが、どうやら難しいようです。

stackoverflow.com

概念的には重要なものの、Spark アプリケーションを構築する際は DataFrame, DataSet を利用すべきと書いてあります。理由としては「時代遅れ」「使いづらい」「速度が遅い」と3つ挙げられていました。

dzone.com

ついでながら RDD の復習・・・

dev.classmethod.jp

Step Function

まだ読んでいないけれど、Glue のジョブキッカーとして使えそう

noise.getoto.net

2019/01/11

ご挨拶が遅れました、あけましておめでとうございます。

年の始まりはいつも不思議な出来事があって、今年はこういう感じなのか、と思うことがあります。今年は変わったことがちらほら周りで起きていて、変化の年になるのかもしれません。よい方向に変化するように少しずつの積み重ねで勉強だけは一層取り組もうと思います。去年部署移動してチーム開発が始まるかもしれないので、今年はソフトウェア設計についてもう少し詳しくなりたいです。

知り合いから語学の才能があるとよく言われるので、そちらももっと活かしたいなぁという思いが最近強いのですが、学習は継続しつつどこかキャリア内でも使えればよいなぁと思う昨今。中国語も簡単なものなら少し読み書きできるようになってきました。

勉強会レポート:「Docker/Kubernetes 実践コンテナ開発入門」の著者を招いてハンズオンをしました

社内勉強会の様子をブログにまとめました。 Docker, Kubernetes のハンズオンを社内で実施したのでその様子です。

developers.cyberagent.co.jp

会社が大きいと色々な領域でのプロフェッショナルがいて、今回のようにご教示いただけるのはとてもありがたいです。部署移動して本社ビル(?)に移ったのですが、様々な変化はありつつ、こういった勉強会に参加しやすくなるのは純粋に嬉しいです。

メモ

AWS Glue

Glue について色々調べているのでメモ。

qiita.com

Spark の DataFrame との違いが冒頭に書いてあります。

docs.aws.amazon.com

docs.aws.amazon.com

Spark

Spark 直接扱ったことがなくて、Glue で Python から Spark を動かすと大量に小さいファイルができてしまいました。Hive のように適切なファイルサイズでファイル出力する方法はないかと調べていましたが、どうやら難しいようです。割と一般的な問題のように思えるんですが、Parquet フォーマットのデータを吐き出してそこに Hive なり Athena で繋ぐのは間違っているんだろうか。。

stackoverflow.com

Step Function

まだ読んでいないけれど、Glue のジョブキッカーとして使えそう

noise.getoto.net

2018/12/14 AWS Glue と Lambda Architecture

クリスマスの雰囲気が好きなのですがいかんせん寒くなってきて、出かけるのが億劫になってきました。インフルエンザも流行りだしたようなので、そろそろマスクをしなければいけない季節でしょうか。

今日は分散処理周りで調べ物をしていたので、読んだ記事をご紹介します。

The Illustrated Children's Guide to Kubernetes

同僚がチャットで紹介していたのですが、分かりやすかったです。Kubernetes はまだ触ったことがなくて、今月末社内でセミナーがあるので予習代わり・・・にはさすがにならないですが。。ユーモラスがあって可愛らしい。

www.publickey1.jp

www.publickey1.jp

AWS Glue の事例

primeNumber さんの事例

primeNumber さんの AWS Glue 活用事例です。Kinesis Firehose から S3 へ書き込み、そのあとの集計結果をまた S3 へ書き込むことによって、Batch layer と Serving layer(データを閲覧するレイヤ)の分離ができています。

speakerdeck.com

フューチャーアーキテクトさんの事例

Glue での実際のコード例や、EMR との比較なども紹介されていて分かりやすいです。あまり実態がつかめていなかったのですが、おかげで Glue を具体的に理解することができました。入出力でのパフォーマンス計測の記事もあり、参考になります。

future-architect.github.io

future-architect.github.io

キャスレー社のブログ

ログをクロールしてテーブルを作成し、さらに整形する・・・といった流れを Glue で行う例が紹介されています。大規模データに対してはどうか、と最後に締めくくられているのでパフォーマンス検証は行えていないようですが、Glue の使い方を理解するにはとても役立ちます。

www.casleyconsulting.co.jp

Lambda Architecture

Lambda Architecture » λ lambda-architecture.net

昔先輩に説明されて、よく理解できなかったのですが、今読むと理解できました。上の AWS Glue を利用した事例でも Lambda Architecture の概念から説明がされています。

"Lambda" は「ラムダ計算」から名付けられているようです。データは Batch layer に貯め続けて、そこに対する純粋な関数があり、データに対する問い合わせも副作用がない関数であり、様々なところで純粋な関数が出てくるので、"lambda" とつけるのが適切であるということのようです。

面白半分で I think its just the letter 'Lambda'. It looks like the data is divided into two streams. なんていう人もちらほら見かけました。。データが二手に分かれる様がλの文字のようだ、ということですが、ちょっと無理があるような。

stackoverflow.com

2018/12/13 (公式ブログより)AWS Kinesis を利用したリアルタイム+バッチ集計

Amazon Kinesis および Amazon Athena を使用して VPC ネットワークのトラフィックを分析および視覚化する

AWS の公式ブログにて、以下の Kinesis と Athena を利用した分析基盤の例が紹介されていました:

aws.amazon.com

Athena のところは本質的ではないと思いますが、、Kinesis を利用することで、リアルタイム集計ときちんと管理されたデータに対するデータ集計の2つを扱うことが可能です。

S3 へは Kinesis Firehose で出力するのですが、 S3 で作成されるファイルのサイズを最大化するためにこのソリューションは 15 分間または 128 MB までバッファリング とありますので、リアルタイムとは行かずとも、ニアリアルタイムなデータを Athena で扱うことができそうです。

  • 上記例は VPC フローログ という AWS 側が収集したデータですが、外部から流れてくるデータに対しての精査などはどこで行えば良いか
  • 日次などの集計をどうやって扱うと効率的か

まだ調べ始めたばかりなので各コンポーネントに対する理解が足らず、引き続き調べます。

2018/12/11

Big Data Analytics Architectural Patterns and Best Practices

re:Invent でのこの資料が、包括的で分かりやすかったのでメモ。(先日見かけて、今日見直そうとしたら見つけるのに時間がかかったので。。)データの温度などの概念も交えながら綺麗に図にまとまっているので分かりやすいです。

www.slideshare.net

www.youtube.com

Presto についていくつか

ETL には向かないという話。結果が出ることが保障されていない(クエリが失敗する可能性が低くない)ことや、単純に ETL としては能力に限界があることが理由としてあげられています。Presto はクエリエンジンなので、クエリで書ける以上のことはできない、といった理由です。

それでも事例を見る限り ETL 処理で利用している企業もいくつかあったので、計算時間を短くするべき集計についてのみ使い、値の正確性は日時処理で補うなど、ETL でも使い分けができると良さそうです。

What are the pros/cons of using Presto for ETL of large datasets (e.g. 5~10TB of raw data)? - Quora

また、Presto は HBase をサポートしていません。JDBC 経由では接続できますが非常に遅いようです。

HBase Support · Issue #3992 · prestodb/presto · GitHub