他サーバからアクセスしてもらうエンドポイントを追加したのですが、その際に CORS が必要だったので設定した際の記録です。
Tomcat なら web.xml のフィルタ機能で CORS 対策ができます。7系の途中から追加されているため、7系の場合はバージョンに注意してください。
cors.allowed.origins は * が指定できますが、その場合は Access-Control-Allow-Credentials を true にしていてもクッキーのやりとりができません。クッキーのやりとりを行うためには cors.allowed.origins にドメイン、プロトコル、ポートなどのアクセス情報を個別に記述する必要があります。
CSRF 対策に、CORS の preflight の機能を使う説明。preflight なんて何に使うんだろうと思っていましたが、認証のような役割を果たすようです。
古いシステムのメンテナンスをする場面があり、Tomcat へ WAR ファイルをデプロイすることになりました。概念はなんとなく理解していたのですが Tomcat への実作業は初めてだったのでメモ。小さいシステムだったのでよかったですが、大きなシステムでドキュメント等が不足していると大変だったかもしれないです。
pom.xml の packaging が war になっていれば、普通に mvn package などで WAR ファイルが生成されます。これはただの ZIP ファイルなので展開すれば中身のチェックも可能です。
上のブログで詳しく紹介されていますが、Tomcat には unpackWARs と autoDeploy というオプションがあり、リリースする際には注意しなければいけません。特に tomcat を停止して WAR ファイルを差し替えて起動しなおしても、tomcat は WAR ファイルの差し替えが認識できないため、すでに展開されているアプリケーションディレクトリ（WAR ファイルを展開したもの）からスクリプトを読み込んで動作してしまいます。
自動化してしまえば気にしなくても良いことだと思いますが、環境移設の合間にリリースしなければならずに急遽手動でリリースしました。一度経験すると理解が深まります。
オフィスが4月から移転するので、今週はバタバタしそうです。移転先では多くの部署が集約されるのですが、そのせいで人が多く、エレベータが長蛇の列・・・という噂もちらほら。駅からも遠いし少し憂鬱ですが、ランチする場所は増えそうなのでお昼は楽しみです。
システム間でデータをやりとりするためのシリアライズの仕組みです。あまり深く調べてこなかったので、いくつかブログや発表資料などを読みました。
Avro Sink / Avro Source を利用すると、Avro プロトコルでシステム間のデータ転送が実現できます。
www.slideshare.net
Protocol Buffers も同様の文脈で登場するなと思って調べると、比較資料がありました。とても分かりやすかったです。
www.slideshare.net
パフォーマンスはともかくとして、スキーマ情報の管理の仕方が異なるようです。Protocol Buffers だとモデルクラスを追加しないといけないため、様々なスキーマが現れた場合にどういう運用になるんでしょうか。。Schema Registry でスキーマ管理できる Avro の方が、データの大規模なワークフローを構築する場合は分かりやすい気がします。ただ速度面では Protocol Buffers に軍配が上がります。また、アプリケーション間での通信はスキーマファイルをやりとりしなくてよい Protocol Buffers の方がよさそうです。
「データマネジメント 業務改善の正攻法 戦略から実践」という書籍を同僚に教えてもらったので読み進めています。堅い本のように見えますが序章からかなり面白くて、技術の革新と共にデータは分散され、統一して管理することが難しくなったということです。技術の発展によって利便性が高まると、データの管理面ではネガティブに働くというのは直感に反している気がしますが理解できます。だからこそ「データモデル」を作成して業務をモデリングし、データに基づいた事業戦略などを進めていかなければいけないんですね。
データ総研が2015年に出版しているのですが、値段も良心的で内容もたっぷりです。。輪読向きのような気がしますが、ひとまず一人で読み進めてみます。
先日のアナウンスで、Glue Job から DataCatalog に直接アクセスできるようになりました。
「AWS Glue によって Apache Spark SQL クエリの実行が可能に」というリリースタイトルがやや誤解を招きそうですが、Spark SQL はもともと利用できたのですが、今までは createOrReplaceTempView をいちいち呼んで Spark SQL で処理するデータを登録しなければいけませんでした。この手間がなくなるというリリースです：
一番下に、 Use Glue data catalog as the Hive Metastore というオプションが追加されていました。デフォルトではオンになっています。
直感的にはそうあってほしい状態がやっと実現されて嬉しいです。今までは読み込むパーティションを手動で制御していたので手間が減ります。ただ、SparkSQL から直接 DataCatalog を読み込む場合は読み込むデータ範囲はどうなるのか（必要なデータのみ取得してくれるのか）が気になるので動作確認しています。何かわかったら追記します。（追記）Spark の挙動として、WHERE 句の条件で取得するデータを push down するようです。
Glue Job による DynamicFrame のデータ書き出し方法には書き出し方法がいくつかあって、 from_options を使っていたのですが、ふとドキュメントを見ていると from_catalog というメソッドが。
Glue Job を使う以上、Glue DataCatalog に寄せたい気持ちがあります。現状は from_options で Parquet ファイルを書き出してそれを DataCatalog 経由で読む…ということをしていますが、DataCatalog に存在するテーブルに追記し、DataCatalog からデータを読み込む、となると運用がシンプルで分かりやすいです。
しかし少し触ってみたところ、パーティション指定がある場合（from_catalog を使いたいタイミングだと、大抵パーティションはあると思うんですが）は from_options をお勧めします。というのも
from_catalog を使って書き込んでも、テーブルのパーティション情報は無視され、S3 の保存場所のルートに直接出力されてしまうadditional_options というパラメータがあり、そこに path や partitionKeys を指定することは可能。ただしその場合はテーブルの保存場所は無視されるという挙動をして、変に from_catalog を使うよりは from_options で細かく制御できた方がよいなと思った次第です。
正しい使い方はこうだ、というのがあればご指摘ください。
調べてたリンクです、メモのみ
createOrReplaceTempView した瞬間に RDD としてキャッシュされるのかと思っていましたが、明示的に cache 指定しないとそうはならないようです。しかも lazy とあるので、どちらにせよ createOrReplaceTempView には何も起こらず、処理が行われた場合にキャッシュするかどうか、ということのようです。
Beanstalk VS CodeDeploy, みたいな記事が多いですが、CodeDeploy を使って Beanstalk をリリースできる、といった内容です。
AWS などのクラウドサービスは多くのサービスが提供されているので、それを組み合わせるだけで目的のシステムが構築できるかというと、似たようなサービスがあってどちらを使うべきか判断に迷う場面も多く、調査に時間を要すると感じます。今は ETL 処理に何を使ったら良いか調査していますが、AWS の方にも尋ねたりして、AWS では Athena(Presto), Glue Job(Spark), Redshift, あとは EMR などで Hadoop クラスタを構築してその上でジョブを走らせる、など様々な方法があることが分かりました。
大規模データが扱えるマネージドサービスに絞ると Athena か Glue Job となりますが、Athena はあくまでも分析をインタラクティブに行えるサービスで、中小規模の ETL には耐えますが大規模となると厳しいようです。パフォーマンスはともかく、1アカウントあたり同時実行数が20に限定されているので立ち行かなくなる画面も出てくるかと思います。
一方 Glue は「完全マネージド型 ETL」と謳っていることから、大規模データに対する ETL も実用的です。色々なリソース制限はありますが必要に応じて緩和が可能なようです。この比較は裏の中心となるアプリケーションが Presto か Spark か、というところでも納得できます。
ということで先日は Athena について色々調べていましたが、今後は Glue を中心に調査する予定です。Athena はすぐにクエリが書けるし、分析用の環境と ETL でデータ生成する環境が同じになると運用上便利かなと思っていたのですが、用途に適したサービスとして Glue 選び、運用を Glue に寄せた方がスケーラビリティ・コスト面で利が大きそうです。
ただ私の探し方が悪かったのか、Glue の活用事例があまり見つからなかったので AWS の方に教えていただきました。ETL 祭り（すごい名前）というイベントが2018年にあったようで、そちらの資料から。
Glue を使って、現 Hadoop 環境（on EC2）のリプレイスをされています。Lambda Architecture に沿って Glue を実装しているのが簡潔で分かりやすい説明でした。コスト面も Hadoop クラスタを EC2 上に構築している状態からは75%カットと、かなり削減できたとのことです。
以前は Hadoop 専属エンジニアがいて運用・管理していたようなのですが、Glue を使ったアーキテクチャではこの「問題」が解決されたと紹介されています。「Hadoop エンジニアに頼らない開発ができるように」とまとめられています。資料からはスケールアウト性において Hadoop エンジニアの負荷が高そうだったり、リアルタイムデータの活用に着手できていないといった課題が挙げられていて、Hadoop エンジニアは数も少ないでしょうし開発リソースがボトルネックになっていたのかなと見受けられます。それを Glue などのマネージドサービスを利用することで回避したのかと思いました。
こちらは Atlassian 社の事例です。Atlassian 社は自社のデータレイクのことを Socrates と呼んでいて、そのアーキテクチャの紹介がされています。ただプレゼンテーション用の資料なので、資料だけだとよく分かりません。Youtube に発表動画も上がっていたので合わせて見ると分かりやすいです：
動画が1時間もあるので、私なりに要点をまとめました。飛ばし飛ばしだったり、興味あるところは戻ってじっくりみている箇所もあったりして、包括的ではないのでご了承ください。
発表は2人の登壇者が行なっていて、前半の一人はデータレイクやETL処理の大枠について、後半の一人は Atlassian 社の実際の具体例について説明しています。
前半は DataCatalog についてわりと時間を割いて説明しています。DataCatalog は Hive Metastore の拡張として提供されているメタデータ管理システムです。S3 に溜めたデータをさまさまなサービス（Athena, EMR, Redshift, etc）から利用できますが、中央集権的に管理されている DataCatalog を参照することでデータを扱いやすくしているとのことです。S3, DataCatalog の2つはデータレイク構築に必須で、他のデータ処理サービスは必要に応じて使い分けると説明されています（22ページ目、発表だと13分過ぎ）
後半は具体例です。Atlassian 社が2017年末時点で約2年間運用してきた社内向けのデータレイク Socrates についての紹介で、エンジニアは9名おり、ウィークリーアクティブユーザーで1000人（ユーザ自体は2000人前後）いるということで、かなり多くのユーザが利用しているデータレイクのようです。発表は Ingest, Prepare, Organize, Discover の4つに分け、それぞれの課題が3つずつと、その解決方法を紹介しています。
Ingest のところでは、当初は REST API でデータをデータレイクに入れていた方法から、"Stream Hub" を構築した流れが紹介されています。また、Kinesis を利用したデータ検証(validation) と、最初に入ってきた(landed)データを圧縮、データフォーマット変換する流れを EMR で構築しています。
Prepare の課題の1つにデータエンジニアへの依存が問題として上がっています。テーブル作成、データ作成のスケジューリングなど、アナリストもデータサイエンティストも、その他データを扱う人々が様々なことをデータエンジニアに依存するようになり、次第にボトルネックとなっていきます。
Discover の課題は分かりやすくて、用途に適した可視化ツールが要望されていること、突発的な高負荷クエリでデータ分析が行えなくなること、どのテーブルが信頼できるものかというデータの信頼性を担保したい、という3つです。2つめは Presto クラスタを廃止して Athena へ移行することで、使用していないリソースに対してコストを払う必要がなくなりました。高負荷クエリが他のクエリ実行に影響を及ぼすことも Athena なら無くなるでしょうし、運用負荷も下がったようです。Athena に対しては課題も3つ紹介されていて、"Early Adopter" だったので Presto との比較情報がなかったこと、鍵認証を利用した JDBC 接続しか対応していないこと（すみませんあまり理解していないです、、）、コスト管理が手間であることが挙げられています。
EMR や Presto などを AWS 上でクラスタ構築している状態から、AWS が同等のマネージドサービスを提供した段階で移行を検討し、それを実行しているんだなという印象です。質疑応答の質問は動画だと聞こえないのですが、、受け答えの中では、実際の運用では理想通りではなくてクラスタ平行稼働したりしている、というような答えがあります。
今日は Athena でのクエリ結果の出力方法についてです。
ユースケースがハマるなら CTAS で、データサイズが小さいなら Python 側で処理して、そうでなければ現状は Athena を使うのは難しそうです。データの加工に Glue Job を使えば、SparkSQL を発行して Parquet ファイルを S3 に出力できるので、私の場合は Glue Job が適切そうです。
Athena で CREATE TABLE AS という、クエリ結果を元にテーブル作成する機能が2018年10月頃に追加されました。
これを実行すると、Glue データカタログにテーブルが追加され、S3 にファイルが書き込まれます。WITH 句を使うことで出力フォーマットもテキストから Parquet へ変更できるなど使い勝手が良いです。ただ、今回はパーティションを日毎に追加していきたかったのですが、CTAS だとすでに同名のテーブルが存在している場合はエラーになってしまいました。
Dativa という会社が、Athena のクライアントを拡張して、まさに上に記載したことを実現しているライブラリを提供していました。pip でインストールできます。ただ Python のライブラリで実現
Athena を使う用途って大規模データに対して集計したいという場合が多いと思うのですが、それに対して形式を指定して出力する術が非常に限られているのが現状のようです。ETL 用途で利用する場合は柔軟性が高い Glue Job を使うのが私が調べた限りは良さそうです。EMR クラスタを自前で立てて・・・というのも選択肢かもしれません。
