/home/by-natures/dev*

データ界隈で働くエンジニアとしての技術的なメモと、たまに普通の日記。

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 と呼んでいるようです:

www.slideshare.net

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

2018/12/02 DAMA-DMBOK2

いよいよ12月ですね、個人的にはイベントが多くて楽しみな月です。

読み中: DAMA-DMBOK: Data Management Body of Knowledge (2nd Edition)

先輩に紹介されて、以下の本を読んでいます:

www.safaribooksonline.com

データマネジメントについて体系的に説明していて、章ごとに様々な話題に触れています。私としては "CHAPTER 11 Data Warehousing and Business Intelligence", "CHAPTER 12 Metadata Management" が業務に関係しそうだなと思っているので、読み進めています。ちょうど今日、第二版の日本語訳「データマネジメント知識体系ガイド 第二版」も出たそうです:

https://www.amazon.co.jp/%E3%83%87%E3%83%BC%E3%82%BF%E3%83%9E%E3%83%8D%E3%82%B8%E3%83%A1%E3%83%B3%E3%83%88%E7%9F%A5%E8%AD%98%E4%BD%93%E7%B3%BB%E3%82%AC%E3%82%A4%E3%83%89-%E7%AC%AC%E4%BA%8C%E7%89%88-DAMA-International/dp/4296100491

"CHAPTER 12 Metadata Management" だけ先にざっと読み終えたのですが、テーマ的に概念的な話にはなりがちですが、メタデータをどのように分類したらよいか、組織の規模に応じてどのように集めたら良いか、実際に "metadata repository"(メタデータを収集するシステム)をどのように構築していけばよいか、など実践的なアドバイスも含まれていました。

もう少し深く読んだり他の章を読んだりしたらレビューなど書きたいです。

2018/11/30

いよいよ12月ですね。街中のクリスマスムードも一気に加速するんでしょうか。イルミネーション見るのも寒いのも好きなので、一年で一番楽しみな季節です。

勉強会・忘年会の予定がすでにいくつか入っているので、師走の文字通り忙しくなりそうです。ひとまず Go の勉強会でブログ担当をすることになっているので、Go 関連の記事をたまに読んでいます。

Microservices実装ガイド in Go at Mercari

メルカリの @yagi5 さんが、GoConference2018 Autumnで発表された資料です。

PHP のモノリシック API からマイクロサービスへ移行したということで、どのようにマイクロサービスで開発しているかが紹介されています。大元の定義ファイル(.proto) を GitHub にプッシュすると CI が動いて、各開発者はそれぞれの言語で自由に実装できるようです。

まだ使ったことがないのですが、通信に関するシリアライズ・デシリアライズの部分がすでに各言語ごとに提供されているのがとても良さそうです。REST API で別のサービスにリクエストするときに適切なフォーマットをドキュメントなどで確認しながら探り探り作っているので、その労力が無くなるのは嬉しい。。

個人的には、そもそも大元の定義ファイルをどうやって決めているのかも気になります。API のバージョン差なんかも吸収できるんだろうか。

speakerdeck.com

3年で5パターンの分析基盤を作ってみた

「作ってみた」とありますが、これだけのサービスの構築経験があるのは凄いです。少し前の記事なのですが、Redshift, Hive, Spark, MySQL から最後は BigQuery に辿り着いています。データがそこまで多くなさそうなので、移設しやすいなどの理由もあったかもしれません。

qiita.com

2018/11/27 Maven, Spring のプロファイル設定

渋谷でお気に入りの居酒屋ランチがあって、今日同僚を連れて行ったのですが、食べログで非常に点数が高いお店だったようです。ランチはぶらぶら歩きながら決めることが多いので、評価はおろか店の名前すら知らなかったです(今も忘れました。。)。焼き魚もフライも美味しい、それでいて割と安いよいお店です。

食べログを全く見ない訳でもないですが、懇親会で選んだお店で参加者に「美味しかった」と喜んでもらえるお店って大抵自分の足で探したお店だったりします。年配の方がやってるお店が多いので、まだまだインターネットが活用されていないということかもしれません。・・・単に年季の入った店が好みだというだけかもしれないですね。でも繁華街で店が古いというのはある程度味が保障されているはずなので、判断基準としては悪くないのかも。

golang.tokyo #20

来月、こちらの Go 言語の勉強会に参加することにしました:

golangtokyo.connpass.com

一般枠は埋まっていたのですが、ブログ枠という イベントに関するブログを書いて頂ける方にご応募頂く参加枠 は誰も応募していなくて、最近筆が乗っているのでちょうど良いかなと思ってブログ枠で応募しました。文章にすることで記憶の整理にもなってよいですが、Go はまだまだ初心者なので理解して記事にできるか少し不安です。頑張ります。

Go 言語に貢献する人が守るべき行動指針というのがあるようです。多様性に非常に重きを置いているようで、主義・人種・性別・性的指向等々にまで触れられているのは面白いです:

Go Community Code of Conduct - The Go Programming Language

Maven, Spring のプロファイル設定

Maven のプロファイル設定がうまく聞かなくていろいろ調べていたところ、Spring のログでプロファイルに関するものが出てきていて、少し混乱してしまったのでメモ。

Maven, Spring(3系以降)どちらもプロファイルを設定可能ですが、Maven はビルド時にプロファイルを指定するのに対し、Spring はランタイムで設定できるようです。生成する Bean をプロファイルで切り替えるような仕組みのようです。

stackoverflow.com

どちらが良いという訳ではないですが、ランタイムで切り替えられるということは SpringBoot としては環境ごとの設定やそれに付随するライブラリも丸ごと fatjar にまとまってしまいます。以下の比較記事でこんなことが述べられています:環境ごとの設定がまとまってしまうのが嫌だと思うかもしれないけれど、結局アーカイブされていて直接は見れなくて、見るには jar を展開する必要があって、そこまでしてプロファイルを見るのはバッドプラクティスだから大きな問題ではない。"clean" にしておきたければ Maven を、そうでなければ Spring のランタイムで切り替えられるプロファイルは欠点を補って余りある魅力があるとのことです。確かに、jar の起動オプションを変えるだけで環境に応じた動作をするのは便利そうです。

blog.frankel.ch

2018/11/26 Hadoop ResourceManager HA 構成の設定(メモ)

Hadoop 系のプロダクトはパラメータが多く、業務で私が設定することは少ないので、何かの調査のたびにいつも調べたり眺めたりしているだけなのですが、、忘れがちなので文章にしてみます。

Hadoop 本家はこちら:

Hadoop – Apache Hadoop 2.8.5

そして特に YARN のパラメータはあまり読ませる気がない・・・横スクロール必須です。

https://hadoop.apache.org/docs/r2.8.5/hadoop-yarn/hadoop-yarn-common/yarn-default.xml

ResourceManager の HA 構成について

ResourceManager はクラスタのリソース状況を監視し、アプリケーションに新たにスケジューリングする仕組みを提供します。ResourceManager は Hadoop 2.4 以前は単一障害点(SPOF) でしたが、2.4 以降は Active-Standby 構成が取れるようになりました。

フェイルオーバーは手動(CLI)で行うか、ZooKeeper を利用して自動でフェイルオーバーする許可が設定されていれば自動で行うようです。

以下、Hadoop 本家の説明です。フェイルオーバーの仕組みやパラメータについては非常に簡潔にまとまっていて読みやすいです:

Apache Hadoop 2.8.5 – ResourceManager High Availability

https://hadoop.apache.org/docs/r2.8.5/hadoop-yarn/hadoop-yarn-site/images/rm-ha-overview.png

HA 構成にするための最小設定も上のドキュメントに紹介されています:

<property>
  <name>yarn.resourcemanager.ha.enabled</name>
  <value>true</value>
</property>
<property>
  <name>yarn.resourcemanager.cluster-id</name>
  <value>cluster1</value>
</property>
<property>
  <name>yarn.resourcemanager.ha.rm-ids</name>
  <value>rm1,rm2</value>
</property>
<property>
  <name>yarn.resourcemanager.hostname.rm1</name>
  <value>master1</value>
</property>
<property>
  <name>yarn.resourcemanager.hostname.rm2</name>
  <value>master2</value>
</property>
<property>
  <name>yarn.resourcemanager.webapp.address.rm1</name>
  <value>master1:8088</value>
</property>
<property>
  <name>yarn.resourcemanager.webapp.address.rm2</name>
  <value>master2:8088</value>
</property>
<property>
  <name>yarn.resourcemanager.zk-address</name>
  <value>zk1:2181,zk2:2181,zk3:2181</value>
</property>

自動フェイルオーバーはデフォルトで true のようなので、これで Active ノードがダウンした際にフェイルオーバーされるようになります。

また、2.4 からは ResourceManager Restart という機能が提供されていて、 実行中のアプリケーションを中断することなく ResourceManager の再起動を行えるようです。フェイルオーバーが行われた際、新しく Active となったノードはフェイルオーバー前に実行されていたアプリケーションを継続して監視し続けるようです。

Apache Hadoop 2.8.5 – ResourceManger Restart

2018/11/21 LINE DEVELOPER DAY 2018

先日、LINE DEVELOPER DAY 2018 に参加してきました。

linedevday.linecorp.com

engineering.linecorp.com

資料は後日公開されるようですので詳しくはそちらをご覧ください。 公開されていました、SlideShare から閲覧できます:

www.slideshare.net

数日時間が経ってしまったので、以下簡単な感想まで。。

全体的なところでは、資料が全て英語だったり、発表は英語と日本語のものがありましたがどちらも通訳レシーバーを利用することができました。発表も通訳されることを意識してか、ハキハキした口調で日本語も英語も聞きやすかったです。TED talk を聞いているような錯覚に陥りました。w 資料準備、発表準備どちらもかなり時間をかけているなという印象です。英語でのプレゼンや、海外学会での学術的な発表を行っていたりと、グローバル企業であることを強く主張しているように見えました。

今回聞いたのは以下のセッションです。手元のメモや記憶頼りで書いているので正確には後日公開されるし資料をご覧ください。

How does LINE effectively handle media content?

www.slideshare.net

LINE での画像・動画データなどをどう世界中の拠点で効率よく扱っているか、という話で、データの種類に応じてキャッシュの仕方を変えたりされていました。同じ画像でも、グループラインであれば多数のユーザに見られるので効率的なキャッシュをし、個別ラインであればそうでない・・・といったような細かいハンドリングをしていた印象です。

また、2019年に LIME(LINE Media)という GPU を利用したメディアデータのプロセッシングの仕組みを OSS 化を目指しているそうです。

Multi-Tenancy Kafka cluster for LINE services with 250 billion daily messages

www.slideshare.net

LINE のサービス間で利用される Kafka クラスタの話です。利用用途としては主に2つで、1つはアプリケーションが分散処理させるためのキューとして利用していて、2つめの利用用途は他のサービスへアクションなどを伝えるデータハブとして利用されているということです。1つの Kafka クラスタへ処理を集めることによって、データを見つけやすくし、オペレーションの効率化を目指しています。

発表の中では、Kafka クラスタに対する要件として、クライアント間で isolation を保つこと、とありますが、以前 Kafka クラスタがこれに反した動作をしていたということです。Kafka のソースコードや Linux カーネル API を調査して原因の発見・解消を行っているストーリーは技術力の高さを感じさせました。

Efficient And Invincible Big Data Platform In LINE

www.slideshare.net

LINE でのビッグデータに関する取り組みの全体像についての紹介です。Pipeline platform, Analysis platform, Security, Monitoring, Tuning という流れで紹介されていました。特に分析基盤として、1668Hive テーブル、25PB、550ユーザーというのは圧巻の大規模です。

OASIS - Data Analysis Platform for Multi-tenant Hadoop Cluster

www.slideshare.net

OASIS という、誤解を恐れずに言えば全社で利用できる BI ツールの紹介です。

OASIS は利用ユーザを分類し、様々なスキルを持った人が適切に LINE のデータを扱えるようにしています。例えばレポートを見るだけの人は Manager として扱い、クエリだけでなくプログラムが書ける人は Engineer として分類し ETL 処理を記述することができます。また、データサイエンスの技術がある人はアドホック分析を行うこともできます。

当初は既存の OSS で BI ツール(Apache Zeppelin など)の運用をしていたそうですが、セキュリティや安定性の面、また YARN アプリケーションの扱い方が合わずに自前で開発することに決めたそうです。Apache Zeppelin や Jupyter Notebook のような「ノート」単位での見やすいレポート機能は踏襲しつつ、YARN アプリケーションのリソース管理を効率よく行えるようにしたり、スケジューリングを設定できることでレポーティングツール+ETL サービスとして運用しているようです。

発表を聞く限り多くのユーザが OASIS を利用しているようで、細かいところも配慮した作りで OASIS が使いやすくなるよう配慮しているように見えました。例えば、レポートごとに誰が見れるか権限を振るのは運用上煩雑なので、その人が所属するチームに自動的にレポート共有されるようにする、などです。細かいことですが、基礎的な技術に合わせて細かい配慮の積み重ねで BI ツールが広く使われるかどうかが変わってくるかもしれないな、と感じました。