Sparkへようこそ... Javaについて：Evgeny Borisovのインタビュー

ビッグデータは問題です。 情報量は日々増加しており、雪だるま式に蓄積されています。 素晴らしいことは、この問題には解決策があることです。JVMの世界でのみ、数万のプロジェクトがより多くのデータを処理します。



2012年に、 Apache Sparkフレームワークが開発され、Scalaで開発され、ビッグデータを操作するタスクの特定のクラスのパフォーマンスを改善するように設計されました。 4年間、プロジェクトは成熟し、バージョン2.0に成長しました（実際には、バージョン1.3-1.5から既に開始されています）。Javaを操作するための強力で便利なAPIを備えています。 これが誰に必要なのか、Sparkの助けを借りてどのタスクを解決する必要があるのか​​、そして価値がないのかを理解するために、サンクトペテルブルクで10月12〜13日に開催されるトレーニング「Welcome to Spark」の著者であるEvgeny EvgenyBorisov Borisovと話しました。







JUG.RU：ユージーン、ようこそ！ 最初から来てください。 Sparkの概要と、Sparkの使用方法を簡単に教えてください。



Eugene：まず第一に、Apache Sparkはフレームワークです。ビッグデータを無制限の数のリソース、マシンで処理できる特定のAPIであり、独立してスケーリングできます。 Java開発者を完全に理解できるようにするために、データベースと通信できる古い意地悪な JDBCを想像してください。データベースから何かを読み取り、何かに書き込むと、Sparkでデータベースに何かを書き込んで読み取ることができますただし、コードは無制限にスケーリングされます。



そして、ここで合理的な疑問が生じます：どこで書くことができ、どこで書くことができますか？ Apache Hadoopで記述でき、HDFSで作業でき、Amazon S3を使用できます。 一般的に、多くの分散ストレージがあり、多くの場合、SparkのAPIはすでに作成されていますが、他のAPIについては作成されています。 たとえば、 Apache Cassandraにはこのための独自のコネクターがあり（DataStax Enterprise内）、CassandraでSparkを書くことができます。 最終的には、ローカルファイルシステムで可能です。これはここで行う必要はありませんが（スケーリングする場所はありません）、この機能は通常テストに使用されます。

情報は毎年ますます蓄積されているため、無制限のリソースで処理したいという要望があります。

JUG.RU：それで、Sparkは分散インフラストラクチャ上で回転しています。 これは、プロジェクトが純粋に「エンタープライズ」であることを意味しますか、それとも原則としていくつかの個人プロジェクトで使用できますか？



ユージーン：今日はエンタープライズフレームワークである可能性が高いですが、ビッグデータは現在、それなしではどこにも存在しないほどの速度で広がっています。毎年、より多くの情報が蓄積され、それぞれ、無制限の量のリソースで処理したいという要望があります。 今日、情報はほとんどなく、それを処理するだけのコードがあり、さらに情報が蓄積されると、すべてを書き直す必要があります。 だから？ また、すべてが最初にSparkで処理された場合、クラスターを複数のマシンで単純に増やすことができ、コードをまったく変更する必要はありません。



JUG.RU：Sparkはまだエンタープライズクラスだと言います。 これは重要な質問ですが、安定性と下位互換性についてはどうですか？



Eugene： SparkはScalaで書かれているので、後方互換性のあるScalaは十分に悪いのですが、Sparkもこれに少し苦しんでいます。 あなたが更新したことがあり、ある種の機能が突然落ちましたが、これはScalaよりもはるかに少ない範囲で起こります。 それでも、ここのAPIははるかに安定しており、すべてがそれほど重要ではありません。通常、「ブレークダウン」はローカルで、ポイントごとに解決されます。



Sparkの2番目のバージョンがリリースされ、非常にクールに見えますが、これまでのところ、すべてが崩壊しているとは言えません。 トレーニングのためにある種のレビュートピックを準備し、何が変更され、更新されたかを示す時間があります。



Spark自体がScalaで書かれているという事実にもかかわらず、ここに追加する価値があり、私はそれを知らない人が Scalaで書くことを支持しています 。 私はしばしば「ここで、彼らはあなたがScalaに出会うと言います」と非難されます。 私はScalaに遭遇しません！ もし誰かがScalaを知らないが、Sparkで書きたいと思うなら、これはScalaを学ぶ理由ではないと思う。



JUG.RU：さて、原則として、Scalaの下でSpalaを書く方が良いと判断しましたが、Scalaに書き込めない場合は、Jaに書くことができます...



ユージン：いやいやいや！ Scalaで書く方が良いとは言いませんでした。 私は、Skalaをよく知っていて、その上でSparkの下で書く人は完全に普通だと言いました。



しかし、ある人が次のように言った場合、「Scalaのことは知りませんが、Sparkを書く必要があるのは、これがいかにクールかを理解したからです。 今、Rockに教えるには何が必要ですか？」これはまったく意味がないと言います！ そして、私がScalaを知らなかったので、ここでJavaで記述しようとしましたが、Javaを知っていましたが、すべてがひどく悪くなり、最終的にScalaに切り替える必要がありました。それから私たちは幸せです。」



今日、これはまったくこのようなものではありません。Java7について話していて、Sparkがまだ​​RDDで古かったのは事実です。



今日、Javaは8番目であり、データフレームがSpark（バージョン1.3から）に登場し、実行対象に関係なくAPIを提供します。Scala、Javaでは、Scalaがなくても完全に生きることができます。



JUG.RU：Java 8で記述できる場合、Sparkのエントリしきい値はいくらですか？ スマートな本を読んで、たくさん学ぶ必要がありますか？



Eugene ：特にJava 8の実践的な経験がある場合は非常に低いです。8番目のJavaのストリームを見てみましょう。イデオロギーは非常に似ており、ほとんどのメソッドが同じと呼ばれています。 自分で始めて理解することができます。



あらゆる種類の微妙さ、トリック、ニュアンスに対処するために、 トレーニングが必要になる可能性が高くなります。 さらに、トレーニングはJava開発者向けであるため、Springですべてをカスタマイズする方法、インフラストラクチャを記述して、すべてを機能させるためにアノテーションを使用してSparkのパフォーマンストリックを実行する方法を示します。箱から出してすぐに。



JUG.RU：彼らが書いているどこでも、Sparkはビッグデータを扱うのに最適であると言っていますが、これは理解できます。 しかし、それほど頻繁に聞こえない質問は、Sparkが適切ではない理由です。 どのような制限があり、どのタスクのためにそれを取ることは絶対に価値がないのですか？



Eugene：タスクがそのイデオロギーに従ってスケーリングしない場合、Sparkが役に立たないという意味で、スケーリングしないタスクにSparkを使用することは絶対に意味がありません。



例として、ウィンドウ関数は、Sparkeにあるという事実にもかかわらず（一般に、Sparkですべてを行うことができます）、非常にゆっくりと動作します。 時間が経つにつれて、ここでは良くなるはずです、彼らはこの方向に動いています。



JUG.RU：ところで、これはいい話です。Sparkはどこへ行くのですか？ いくつかのデータを迅速かつ適切に処理することがすでに可能であることは明らかです。



Eugene：最初のSparkにはRDD（Resilient Distributed Dataset）があり 、コードを使用してデータを処理できるようになりました。 データは通常列ベースの構造を持っていますが、列名を参照できないことが判明しているため、RDD APIの場合はそうではありません。 また、膨大な数の列と膨大な数の行を含むファイルがあり、これらすべてを処理するロジックを作成すると、非常に読みにくいコードが得られます。



データフレームを使用すると、列名を使用して構造を維持しながらデータを処理できます。コードがはるかに読みやすくなり、SQLに精通した人々がこの世界で非常に良くなりました。 一方、ロジックを微調整する機能が欠けていました。



その結果、RDDの助けを借りて、データフレームの助けを借りて特定のことを行うのが便利になったことが判明しました。 2番目のSparkは、このすべてをDataSetと呼ばれる構造に統合し、1つのAPIを離れることなく、 とにかく作業することができます。 さらに、すべてがより速く動作し始めました。 したがって、Sparkがどこに向かっているのかを言うと、さまざまな最適化が行われており、フレームワークはますます高速に動作していると言えます。

フレームワークはますます高速になっています。

JUG.RU：明らかに、動きはスピードと柔軟性に向かっています。 インフラストラクチャについて質問する時が来ました。Sparkで動作するツールは何ですか？ JPointのレポートでは、Hadoopを使用して作業できること、Hadoopを使用しないことなどができることを詳しく説明しています。



しかし、前回の記事へのコメントで、ヤーンのないスパークは悪者であり、そこでは通常のリソース管理は得られないとの意見が表明されました。



ユージーン：私はこの意見に同意しません。 それがどのように始まるかを見てみましょう。コードが送信されるワーカーの作業を調整する何かがあり、それは並行して実行されます。 Yarnはもちろん、これらすべてをより迅速に調整し、労働者の状態を監視し、必要に応じて再起動する方法も知っています。 ただし、必要に応じて、Yarnなしで作業できます。 もちろん、Spark Standaloneがありますが、これはもちろん低速でそれほど強力ではありませんが、これに加えて、代替手段もあります。たとえば、Apache Mesosは、今でも見ています。 5年後にはすべてがヤーンに結び付けられるどころか、満員になると確信しています。 さらに、最初に述べたように、分散ストレージには多くのツールもあります。



JUG.RU：彼らは理論を多かれ少なかれ整理しました。 Sparkが必要ない理由も理解できます。 そして、あなた自身の経験からSparkの使用例を示すことができますか？ 確かに、ビッグデータ領域には興味深いものがありました。



ユージーン： 「興味深い」ということは知りません。結局のところ、私は主にエンタープライズプロジェクトを実施しましたが、それほど面白くありません。 別のことは、書くことが面白くて、速くて便利だったことです。



興味深い事例のうち、電話会社向けのサービスを思い出すことができます。想像してみてください。あなたは別の国に飛び、SIMカードを変更しなかったので、ローミングを選択する必要があります。 何に基づいて、彼はどのように選ばれますか？ 安く、高価で、利益があり、利益が出ない-そのような決定を下すために、電話会社はすべてのデータを分析する必要があります：すべての電話、誰、誰、どこから、どこから電話をかけたか、良いコミュニケーションがあったかどうか-すべてが修正されます。 具体的には、このプロジェクトでは、世界中のすべての通話についてこのようなデータを計算し、すべてを分析して、異なる統計を表示しました。



2番目の例はスライスです。 メールからの購入、注文、チケットなどを分析して、広告のターゲットを絞り、オファーを受け取るために、メールボックスへのアクセスを許可する人がいます。 ここでも、大量の文字の処理があり、それらはすべてAmazon'eのRedshift'eに保存されます：既にどの顧客に基づいて統計を発行するためにも、すべてを構造化、計算、何らかの形で迅速に処理する必要がありますターゲットを絞った広告や推奨事項を提供します。 ここでは、パフォーマンスを改善するためにSparkをねじ込みました。



JUG.RU：Sparkはデータをリアルタイムで処理しますか？



ユージーン：リアルタイムでできること、batch'ami。



JUG.RU：なるほど、データ検証はどうですか？ 整合性または正確性のためにデータ検証を簡素化するツールはありますか？



Eugene：これはすべてコードレベルで解決されます。100万行のコードを取得し、最初に行うことは無効なコードを破棄することです。 ところで、統計は通常それらについて収集されます：そのようなデータの量、それが間違っている理由、これもSparkによって行われます。



JUG.RU：最後に、「Java vs Scala in Spark」という質問にもう一度触れざるを得ません。 好奇心からさらに。 どちら側にいますか？



ユージン：私はJavaを好む傾向がありますが、多くの人はこれを嫌います。 私は理解できます-私は15年間Javaを書き、Groovyを数年間書きました。これはもちろんJavaと比較した次のステップですが、Javaの8番目のバージョンのリリースでは、すべてがそれほど明確ではありませんでした。 今、新しいプロジェクトを開始し、Java 8またはGroovyでプロジェクトを開始するたびに考えています。



しかし、Scalaはまったく異なる世界です！ そして、楽器のように理解するのは難しいです。 一部のマクロパターンはありません。 Scalaで書く必要があった時期がありました-私はひどく苦しみました。 当然、あなたが苦しむとき、あなたは他の人に相談に行きます。 アーキテクチャを構築する方法を一人に相談すると、彼は一つのことを言います。 別の質問をすると、まったく異なる答えが得られます！ Javaの世界では、すべてがより均一で、より多くの経験、より多くの人々、コミュニティです。私にはサービスがあり、タオがあり、依存性注入があり、Springがあります。これにはSpring Dataがあるか、Spring MVCがあります人々が収集したこの膨大な情報をすべてScalaに移動して、すべてをゼロから学びますか？ なんで？ Javaですべてが悪くならない場合。 Scalaが2〜3倍速く動作する場合、またはAPIが10倍便利である場合、1年半学習することに同意することを理解しています。



面白い出来事を思い出しました。 報告後、ある男がリヴィウで私のところに来て言った：

-聞いてください、あなたはScalaが好きじゃないですか？

「私はそれを言わなかった」と私は答える。

-まあ、それは同じように感じます。

「まあ、すでにJavaプログラマーがいるプロジェクトでは、それらをScalaに翻訳するのに時間を浪費しても意味がないと思います。」

-そして、あなた自身がロックに書いた？

-さて、私は少し書きました。

-いくら？

-どこかで6ヶ月。

-ハ、半年...半年はScalaを理解できませんでした！ 少なくとも2〜3年は必要です。



しかしその瞬間、 私は自分が絶対に正しいことに気づきました。 入学基準が高いのは2〜3年のレベルです。 結局のところ、問題は言語が良いか悪いかではありません。 真実は、もしあなたがJavaで書くことができれば-Javaで書けば、Sparkで、いずれにしても、それは簡単で簡単です。 私のプロジェクトの開発者がGoogleでいくつかのソリューションを探して、JavaではなくScalaで見つける状況がますます少なくなっています。 以前は、これはたくさんありましたが、現在はほとんどありません。



実際、Scalaの使命はそれほど変わっていません。開発者をScalaに移すのではなく（12年も経っていない）、彼らの目標はすべてのScala製品をJavaで使用することです。 -これはすでに非常に強く感じられています。現在、同じSparkの新しいバージョンごとに、Javaを含め、ますますシャープになり、バージョンごとに差は小さくなっています。

1年前にGitHubでJavaとScalaのSparkのプロジェクトの数を比較し、ディストリビューションが約3000と7000であった場合、これらの数はより近い

1年前にGitHubでJavaとScalaのSparkのプロジェクト数を比較し、ディストリビューションが約3000と7000であった場合、これらの数値はより近くなりました。 そして、それでもギャップはそれほど広くありませんでした。これはSparkの下でJavaを書く膨大な数のプログラマーであり、すべてがうまく機能します。



JUG.RU：ユージーン、ありがとう、そしてトレーニングで会いましょう！

---

一般的に、SparkのJavaテーマに興味がある場合は、トレーニングでお会いできてうれしいです。 多くのタスク、ライブコーディングがあり、最終的には、慣れ親しんだJavaの世界でSpark-eの独立した作業を開始するのに十分な知識をこのトレーニングに残します。 対応するページで読むことができる詳細。



トレーニングがあなたにとって面白くない場合は、ジョーカーのカンファレンスでユージンと会うことができます。そこでユージンは2つのレポートを提供します。

-Sparkについての神話、またはSparkを通常のJava開発者にすることはできますか（トレーニングの非常に短いバージョン） 。

-Maven vs Gradle：自動化の夜明け（Baruch Sadogurskyと）