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 でのこの資料が、包括的で分かりやすかったのでメモ。（先日見かけて、今日見直そうとしたら見つけるのに時間がかかったので。。）データの温度などの概念も交えながら綺麗に図にまとまっているので分かりやすいです。

Big Data Architectural Patterns and Best Practices from Amazon Web Services

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

2018/12/07 Netflix のデータ分析基盤事例

来週土曜日、12月15日に JJUG CCC 2018 Fall が開催されます。 JJUG CCCは毎年2回、春と秋に開催する日本最大のJavaコミュニティイベントです。Java関連の技術や事例に関する良質なセッションが行われ、また異なる分野で活躍するJava技術者が一堂に会する場ともなっています。ぜひご参加ください。 ということで、Java 関連技術の動向などをキャッチアップするにはよいイベントだと思います。

私はボランティアスタッフとして参加させていただくことになっているので、イベントがスムーズに行われるようにお手伝いします。LT でドラを叩く役割をするかもしれません、いわゆるドラ息子というやつでしょうか。。

www.java-users.jp

AWS re:Invent 2016: Netflix: Using Amazon S3 as the fabric of our big data ecosystem (BDM306)

Netflix のデータ分析基盤の事例を調べていたのですが、以下のプレゼンが包括的でとても分かりやすかったです。

データの大きな流れと S3 を中心としたアーキテクチャである理由から始まり、各要素技術である理由がそれぞれ説明されています。S3 に明示的にデータを分離することで、データはデータでスケールできるし、計算クラスタは必要な分だけデータを利用して計算リソースのスケールに集中できるとのこと。

Genie というツールを内製していて、今は OSS になっているのですが、distributed job orchestration engine と紹介されています。ジョブを実行するクラスタが複数ある場合にジョブ管理を統合的に行うツールのようで、どのクラスタでどのジョブが実行されたかなどが管理できます。クラスタ管理者にはクラスタのアップデートなどをサポートする機能も備わっているようです。

Metacat というメタデータ管理ツールもあって、利用されていないデータの削除等もこれで行っているようなのですが、Genie とどう組み合わせて利用しているか気になります。

Druid についても紹介がありました。"out-of-the-box visualization tools" （型に捉われない可視化ツール、その場で自由に分析・可視化するツール？）だと数十億行のデータを扱いたい場合に扱いきれないということで、S3 に入ってきたデータを集計して S3 に Druid 用に保存することで、高速に参照することが出来るようになります。

www.youtube.com

データ分析基盤などはトレンドはありつつも正解はないので、ビジネスのゴールに向けてアーキテクチャを各社考えているようです。Netflix ではとにかくデータが多く1つのクラスタで集中管理することが適切ではないことから、Genie などのジョブ管理ツールを利用してクラスタが複数作成されても集中管理できるように工夫しているようです。Druid もすべての可視化を Druid にするのではなく、必要に応じて使い分けているようで、洗練されたデータ分析基盤が構築され、また利用されているなと感じました。

2018/12/04 Hive のマテリアライズドビュー

2019年の手帳を買い、12月から使おうと予定を書き込んで数日使っていたところ、2018年ではなく2019年の12月にずっと書き込んでいることに気づきました。無印の手帳なのですがウィークリーに「年」が付いていないので気づきませんでした。。買い換えるのももったいないのでこのまま使おうと思いますが、知り合いの先生が30年ぶりに出勤場所を間違えた（その先生は曜日によって出勤場所が違う）とこの前話していて、12月に入ると注意力が落ちるのだろうかとふと思いました。

Hive の VIEW について

"VIEW" だと非常に検索しづらいですが、CREATE VIEW して作成される論理的で物理的なデータを持たないテーブルのことです。作り方や使い方は MySQL などとほぼ同様だと思います。MySQL でどうだったかは忘れたのですが、Hive の VIEW は作成された後は元となったテーブルが存在するか、スキーマが変更されていないかはチェックしないので、参照時（実行時）にクエリが失敗することがあるようです。

LanguageManual DDL - Apache Hive - Apache Software Foundation

Hive では 3.0.0 から materialized view（マテリアライズドビュー、マテビューとも言うらしい） が導入されています。

Materialized views - Apache Hive - Apache Software Foundation

これは事前にクエリの一部を計算しておくことで、クエリ全体の実行速度を向上させる技術とのこと。クエリ結果は Hive 内の他、Druid 内にも保存できるようです。

元のテーブルが更新された場合、 REBUILD コマンドを実行することでマテビューのデータも更新されます。これは自動では発行されず、ユーザが自ら行う必要があります（一定時間ごとでよいなら、 hive.materializedview.rewriting.time.window というオプションがありました）。この際、差分更新（incremental rebuild) が可能であればそうするとのことで、以下の条件が満たされた場合に差分更新が実行されます：

• "micromanaged" か "ACID" テーブルしか利用していない
• GROUP BY 句を含む場合、マテリアライズドビュー自体も ACID テーブルとして保存しなければいけない（Scan-Project-Filter-Join のみからなるマテリアライズドビューの場合はこの制約はない）

ACID テーブルについてはこちらで紹介されていました。行単位での更新を可能にするための技術として明示的に ACID と呼んでいるようです：

Hive Does ACID from DataWorks Summit

www.slideshare.net

1つめの条件内に "micromanaged" とありますが、これは ACID テーブルで INSERT のみを許可するものを指すようです。Hive としては ACID テーブルを 2つ用意していて、INSERT, UPDATE, DELETE ができる full transactional tables, INSERT しか許可しない insert only tables (micromanaged) のどちらかを利用していればマテリアライズドビューが差分更新になるようです。