Noto(51)59この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。2016に行ってきましたので、その内容についてレポートします。最近は機械学習とSparkに興味があるためランチはB会場のライトニングトークを聞き、午後はD会場のセッションに参加しました。日本Hadoopユーザー会に公開されるそうなので、そちらも合わせてご覧下さい。Keynoteまずは午前中のKeynoteです。他にもKeynoteに関する記事を見つけたのこちらも合わせてご覧下さい。JapanNTTデータの濱野さんから最初のご挨拶とHadoopを取り巻く環境、そしてカンファレンスを行っている意図についての説明でした。Hadoopエコシステムは年々広がる一方で定義が難しくなっているなというのは同感でした。初開催!(併催)Hadoop10周年!参加登録者数1347名!約63%がはじめて参加される方!いまのHadoopHadoopは終わった。何がHadoopなのか?Hadoopはひとつのものではなくなった初期のHadoopはMapReduceとHDFSと言われていた周辺ソフトウェアが出てきたImpala、Presto、Drill、、、Hadoopエコシステムという言い方も昔からあったが、どこからどこまでを含めるかパッケージングの多様さ利用するパッケージによって含まれるソフトが異なるようになってきたLinuxディストリビューションでも同じ話があった。当初はディストリビューションによって含まれるソフトが異なったが、今は落ち着いている。Hadoopも過渡期だと思われる。JapanHadoopコミッタであり最近PMCにも就任した鯵坂さんと小沢さんからは、Hadoopの現状と将来についての話がありました。YARNの将来像として機械学習というコンテキストが出てきていて、機械学習がいまホットなんだなーと改めて思いました。Hadoopの現在と未来。YARNもHDFSも新しいハードウェアに対応して進化していく。JAPANのデータプラットフォームの全体像と今後についての話がありました。Hadoopに関する技術チャレンジということで年々増えるデータサイズ、クエリ数に対してNode数を増やすのではなくチューニングで対応したという話でした。ワークロードにもよるのでしょうが、チューニングすれば同時クエリ数を10倍に増やせるようです。JapanのHadoopクラスタは6000ノードで120PB。指数関数的に増大するデータ需要を技術で解決していく。Lipcon(Cloudera)(現時点でスライドは公開されていないようです)ClouderaのToddさんからHadoopのストレージの現状と展望についてのお話でした。ストレージを専門とされていることもあり、とても丁寧にストレージという観点でHadoopの歴史的経緯を説明し、最後にKuduの紹介をしていました。聞き取りやすいように英語を話してくれていたのが印象的でした。HDFSとMapReduceのみ。Japanを開催した背景についての説明とセッションの紹介がありました。JapanDatabricksのReynoldさんからはSparkの現状と2.0の紹介がありました。私はあまり英語が聞き取れないのですが、Reynoldさんはジョーク満載のトークをしてる印象でした。Spark2.0が今年の5月にはリリースされるというのに驚きました。ほんと進化が速いと思います。2.0フロントエンドAPIを作るバックエンドは10倍のパフォーマンスにするDataFrame経由にして将来はGPUなどにも対応する?ストリーム処理に関する課題Sparkは既にかなり速いSpark2.0のリリーススケジュール。2.0はフロントエンドAPIの創設と10倍の性能向上を目指す。早くも今年の5月頃登場予定。武文(さくらインターネット)(現時点でスライドは公開されていないようです)さくらインターネットの須藤さんからは、さくらインターネットの原価計算システムを作った背景とそのシステムがSparkで実行されるようになったという話がありました。これまで知らなかったんですが原価計算システムということでやはりノーチラス・テクノロジーズさんなんだなと思いました。Frameworkの強みがはっきりと出てるなと思いました。普通の業務システムの話し。コミッタとかいるわけでもないSparkを使っている意識もない。Frameworkを使っているだけで、バックエンドがMapReduceからSparkに変わったらしいそれぐらい意識しなくてもよいものだということを話せばよいのかと考えているC会場で詳細を話す。原価計算システム投下した資本は計画通り回収できるかサービスを提供するのにどのくらいコストがかかっているかを把握する必要があるコストが分かれば予測できるようになるはずデータ量は300GB/dayオンプレミス。サーバは売るほどある。Publickey(午前ではなく午後のセッションのレポート記事です)ランチ&ライトニングトークリクルートテクノロジーズさまご提供のランチをいただきつつ、B会場のライトニングトークを聞きました。河原センサー間のパターンが異なるようになる予め予測モデルを作っておく部分がバッチだが、時間がかかるのでSparkを使ってみたBeforeLASSO回帰。午後はD会場にいました。飛志(ノーチラステクノロジーズ)(現時点でスライドは公開されていないようです)ノーチラステクノロジーズの神林さんからは次世代アーキテクチャから見たHadoop/Sparkの位置づけの話でした。残念なことに移動した時点でD会場は満席でスライドを見ずに神林さんの話す内容だけメモしていました。以下あたりの話をまとめて詳細に説明した内容だと思います。急がば回れ、選ぶなら近道Hadoop/Sparkのアーキテクチャの次が見えてきているというのは、個人的にはかなりわくわくしました。あと、神林さんが数年前からトランザクション系の読書会を開催しているのはこの辺りを見据えてなのだなーと納得してたりしました。Hadoopは右側を見ている。何が違うかというと故障の発生率。100ノード超えると壊れるが、10ノードぐらいなら壊れない障害対策の仕組みを入れるのでアーキテクチャに制約を受ける。途中にバリアを入れるとオーバーヘッドとなる。レプリケーションもオーバーヘッドになるどれぐらいのオーバーヘッドなら許容できるのか。100ノードなら許容できるが、10ノードならやり直せばいいので早く終わって欲しい理想を言えば利用者が選べるのがいいが、出来ない最悪オーバーヘッドで7割になる。オープンソースなので提案したが却下されたデータサイズがデカイ方が偉いというのを誇る人がいるが、止めた方がいい。品がないコミッタが出てることをPRしている事自体がオープンソースではないが、そこは察してあげてコミッタにならないといけないというのはオープンソースではない新しい形のプロプラ。要はオープンソースになったIBMとして見ればいいだから新しい物がでない。中で喧嘩になるDataFrameいらない。99%はSQLしか使わないムーアの法則は終わった。Intelが主張している時点で終わってるwメニーコア、バスの高速化とかHPCの技術RSAインターコネクトNVM(不揮発性メモリ)遅い。DRAMの代わりにはならない。SSDより2桁速い大体1000コア。chip)でやるので、メモリすぐ呼べる全部オンプレ。オープンソースはないデータベースを作るのが大変なのはリカバリー。車の例えで言うとエンジンがデータベース。電気自動車が出て、誰でも作れるようになった。これと同じことが起きるデータベース関係は特許が切れるようになるのでこれからおもしろくなるMS一番進んでる、Oracle力技、HP脱落気味、SAPフルコミット、Hadoopガン無視Sparkもって2,3年。こっちの方が速いOSは普通に各ノードにOS入れるが、ほんとは分散OSにしたい。RSAで通信のボトルネックは取れる。failureはあるデータはローカルに置くのがいいという結論ではない。全体の半分ぐらいはそういう結果が出ているが、半分は遅くなっている転送がネックになっている。インターリーブ処理を飛ばすかデータを飛ばすかSparkはデータを飛ばすインターリーブを事前に計算できるか?→無理というのが今の結論joinの時に手元でやるのと飛ばすのとどっちがよいか。これはケース・バイ・ケース。やらないと分からない論文でも両方やってみてstats取ればいいと書いてあるwこれはおもしろい。結局アプリで決めることになる。Hadoopは制御出来ないので別のものを使うことになる更新どうする。分散トランザクションMVCCどこでやるのか、ハードウェアでやるのかバージョンでやるのかHadoop関係ない。Container?おれおれトランザクションマネージャを作る。これをやってるのがワークスアプリケーションズさんユースケースを絞って実装ほんとにメンテ出来るかバス遅延をどうするか。これは分散系の知識パフォーマンスは出る。100倍ぐらい出るかもグローバルの競争で勝てない。SIerが技術のキャップになっているユーザー企業さんは勝てない。Hadoop陣営ガン無視する:100台以上を相手にしている。なったら捨てるアダプティブに行くHadoopが無理に対応しようとするなら分散OS:いらない。YARNもRSAには対応すると思う。パフォーマンスが出るかは謎だがスケジューラ:現状だと無理。いいものが出てくればいいがトランザクション:無理。最初から作った方がいい。これ動くとHiveいらなくなる。全体としてもう少し身軽なら行けただろうが、、イノベーティブのジレンマに見えるこの分野は賭けるに値する。LLAPの性能比較の話がありました。このセッションからは席を確保できました。とあるクラウドDWHとOSS(Hive)の比較スタースキーマTableauからアクセスデフォルトの設定でHiveが遅い1ヶ月前に相談を受けた。結果出たの2,3日前。SQLの方がデータ件数が多いと約半分の速度になったエグゼキュータのメモリ設定が必要。Japanのセッションでもあったように設定でチューニングできるHiveチューニングの基本はデータのロードパーティショニングORCとしてストアクエリ実行Tez/LLAPにする。MLlibについてのお話でした。APIを利用したことはなかったのですが、ほんと便利そうだなと思いました。試してみたいと思いました。API以下のように同じような手順を複数繰り返す。JapanIHIの鈴木さんとNTTデータの土橋さんからはSparkによるGISデータを題材とした時系列データ処理ということで、ダミーの船舶データに関するお話でした。PySparkも検討しているため、非常に参考になる内容でした。Sparkについてのお話でした。HiveとSparkさえ知っていればそのまま利用できるというのは、既に両方を利用しているユーザーからすると移行しやすいのだと思いました。Tezよりも広がるのかもなーと思いました。初期設定ではあまりパフォーマンスは期待できない。Fallの頃から参加させてもらっていますが、毎回とても勉強させてもらっていて、企画/運営/登壇者の皆さまには本当に感謝しております。519,641大規模データ処理とか機械学習周りに興味があります。〜ITエンジニアのお仕事とホンネ〜2月19日に新卒向けの会社説明会〜ITエンジニアのお仕事とホンネ〜を開催します。リモート】クラスメソッドの会社説明会を開催しますクラスメソッドでは、AWS・AI・ビッグデータ・モバイルなどの技術職や営業のメンバーとして一緒にお仕事をする仲間を大募集しています。#cmdevio新型コロナウイルスの感染拡大を受け、本イベントを延期させていただくことになりました(開催時期未定)。お申し込みいただいた皆様には大変申し訳ございませんが、何卒ご理解いただけますようよろしくお願いいたします。AWSについてライトに色んな情報交換をしましょう。カフェ店長のオカノです。使いたいときの注意点を書きました。EC2)環境において、不要な踏み台サーバをなくすことができる便利なアップデートです。環境をDockerで構築してみました。臼田佳祐295ワークフロー自動化OSSのn8nをAWS環境で建てて検証してみました。非常に期待できるサービスです。Fargateの勉強をしています。使ってみたい方は参考にしてください。洋介252SnowflakeがAWSの東京リージョン上で稼働するようになりました。データを日本に置けます。芳賀健231こんにちは!猫様の忠実なるしもべ、芳賀健です。Tokyoで開催されました。クラスメソッド株式会社が運営するAWS・iOS・HTML5に関する技術情報サイトです。