注目の投稿

15歳になったTalendは、データに関わる作業を自動化し続けます

詳細情報
注目の投稿

自社のデータの健全性を信頼していますか?

詳細情報
注目の投稿

Talend、Q2 2020 Forrester WaveTMのEnterprise Data Fabricリーダーの一社に選ばれる

詳細情報
注目の投稿

Talend Winter’20で、データからインテリジェンスを引き出す

詳細情報
注目の投稿

Pipeline Designerの紹介:データ統合の革新

詳細情報

『データプレパレーションに関するガートナーマーケットガイド2019』の3つの重要点

Jean-Michel Franco          2019年4月26日 ガートナーは、データプレパレーションに関するマーケットガイド2019([1])(2019 Market Guide for Data Preparation)を公表しました。マーケット黎明期の2015年、データプレパレーションが主にセルフサービスのユースケースを支援することを想定していた時代に初めて作られたガイドで、今回が第4版となります。 マジック・クアドラントと比較すると、この マーケットガイドシリーズは主に初期、成熟、または小規模なマーケットを取り上げており、ベンダー間の競争の位置づけに関する情報は少ないですが、マーケットの状況や長期的に見た市場の発展についての情報は充実しています。このような資料では、多くの人がまずベンダーのプロフィールをチェックされるかと思います(Talend Data Preparation も詳細なプロフィールと一緒に紹介されています)。このレポートが提供するリーダーシップについての思考と市場分析にもぜひ注目していただけると幸いです。 組織内でのデータプレパレーションの価値と拡張を成功させる方法について、著者のEhtisham ZaidiとSharat Menonのコメントも参考にしてください。 このレポートを調べた後に、私はデータプレパレーションという刺激的なマーケットでのお客様のニーズに対応する3つの重要な点をお伝えしたいと考えました。   データプレパレーションは、データ管理をチームスポーツへ データプレパレーションの市場が誕生したきっかけは、セルフサービス機能がトレンドになったことでした。これは、TableauやPower BIといった最新のデータディスカバリーツールを使用して権限が与えられていても、ビジネスユーザーが知見を得る前に新しいデータソースを効率よく見つける方法がなかったことから発生しました。ビジネスユーザーはIT部門に頼るか、ガバナンスの十分ではない方法でMicrosoft Excelなどのツールを使用してデータをサイロ化するしかありませんでした。データプレパレーションツールはこうした生産性の面での課題に対応するものでした。 レポートによると、データ専門家やビジネスアナリストは、データから実際に知見を引き出せるようにするために、データの検索や保護の準備に業務時間の80%を費やしています。データプレパレーションは、より多くの関係者がデータ統合やデータ品質管理を利用できるようにすることによって、このような状況を改善するために登場したのです。これは21世紀初頭では大きな課題でしたが、それ以降、データ関連業務はより規模の大きなゲームになっていきました。個人の生産性の問題ではなくなり、データ駆動型の知見の活用に向けた企業文化の育成も重要になってきています。 ガートナーのマーケットガイドは、このような動向に焦点をあて強調したことにあります。手法やツールが完成しつつある現在、データプレパレーションを社内とIT部門の誰もが連携してデータを活用できるチームスポーツにすることが主な課題になっています。結果として、もっとも重要なことは運用です。 ビジネスユーザー、ビジネスアナリスト、データサイエンティストやデータエンジニアが別々にその場しのぎで行っていることを集約し、生産時に十分にガバナンスされた方法で繰り返し実行できる、社内全体で活用できる資産にする必要があります。 最終的にこのアプローチは、データ統合、データ分析やビジネスインテリジェンス、データサイエンス、データウェアハウス構築、データ品質管理といった会社全体での取り組みに役立ちます。   スマートな人にはスマートなツールを…逆もまたしかり ガートナーのマーケットレポートでは、データカタロギング、パターン認識、スキーマオンリード、機械学習といった最新鋭のテクノロジーがツールに組み込まれていることも強調しています。 これによってスキルの低いユーザーでもデータを使って複雑な活動ができるようになり、一方でデータ変換、統合、照合や復旧は、それらが繰り返し作業になった時点で自動化できるようになりました。 さらに興味深いのは、ガートナーがこうしたテクノロジーのイノベーションを市場の収束に結び付けているということです。レポートでは次のような予測が書かれています。 「2024年までには、機械学習によって強化されたデータプレパレーション、データカタログ、データ統一化およびデータ品質管理ツールは、統合された最新のエンタープライズ情報管理プラットフォームにまとめられるだろう」。 実際、データプレパレーションを特定のビジネスユーザーを対象にした単独の規律であると考えるのは思い違いといえるでしょう。むしろ、潜在的にはあらゆる人が作業に関与できるようにする機能が整っていることから、情報管理における革新的テクノロジーとみなすべきです。革新的なテクノロジーを活用し、企業は新しい共同作業を通じてデータバリューチェーンを組織することができます。 Talendでは「コラボレーション型データ管理」と呼び、このマーケットガイドでのガートナーを含む一部のアナリストはDataOpsとして言及している手法です。 データ品質管理を例にとってみましょう。 多くの企業では、データ品質の対応に苦労しています。中央IT部門やCDOオフィスといった中央組織の少人数しかいないデータ品質管理の専門家に頼りすぎるアプローチをとっているためです。こうした専門家は、データ品質プロファイリングの調整や復旧では重要な役割を果たしますが、社内で最もデータを熟知しているというわけではありません。データの取得源に近いところで働いている同僚に、データクリーニング作業の一部を依頼する必要があります。こうした人々が手軽なデータプレパレーションツールを使えると、データ品質管理の効率は非常に高くなります。   ハイブリッドクラウドの価値 ガートナーはまた、革新的なPaaS(Platform as a Service)デプロイメントモデルを通じて提供されるデータプレパレーションに対する顧客の需要の高まりを把握しています。ガートナーが強調するのは、基本的なSaaSを超えるはるかに洗練されたデプロイメントモデルが必要であるということです。 レポートでは「企業が必要としているのは、事前にデータを移動させなくても、もっとも意義のある場所でデータプレパレーションを行うことができるような柔軟性が必要である」と説明しています。 …

Read Article

TalendでCI/CDとコンテナー型仮想化を使用してサーバーレスアーキテクチャに移行する

| 2018年8月13日 | Cloud Integration Containers

CI/CDとコンテナーの重要性 CI/CD(継続的インテグレーション・デリバリー・デプロイ)は、ソフトウェアプロジェクトを成功させるための重要な要素であり、プロジェクトを進めるうえで明らかにメリットがあります。既に、コンテナーは現在あらゆる場所で使用され、開発者から絶大な人気を博しています。CI/CDを使用するユーザーは、構築しているアプリケーションを自動的かつ継続的にテスト/検証できるので、アプリケーションの品質を確かなものにします。一方で、コンテナーは、企業が採用する標準的な手順に基づき、一度構築すれば「どこにでも」デプロイできるので、ソフトウェアの配布と実行をより俊敏に行えます。このような一般的なDevOpsプラクティスにより、「特定のマシンしか動作しない」という状況は、回避されます。結果として、サービスを市場投入するまでの時間が短縮されるとともに、デリバリーの頻度を高めることができます。 Talendのシステム環境へどのように適応できるか? Talendでは、CI/CDとコンテナーの両方のメリットを利用できます。Talend 7.0のリリース以降では、標準的なMavenビルドにより、Dockerイメージ内でTalendジョブをビルドできるようになりました。そして、このプロセスをCI/CDのパイプラインにスムーズに接続できます。 サーバーレスアーキテクチャとは? 最後の段階で活用されるのはサーバーレスアーキテクチャです。Talendでは、サーバーレスでジョブがデプロイされます。実際に、ジョブをコンテナー内で送ることによって、統合ジョブを任意の場所に自由にデプロイできるようになりました。様々な選択において、サーバーレスとして定義される新しいサービスのカテゴリーが登場しています。AWS FargateやAzure Container Instancesなど、ほとんどの大手クラウドプロバイダーはコンテナー用のサーバーレスサービスの提供を開始しています。これらのサービスを利用すると、コンテナーを実行する際にインフラストラクチャ(サーバーやクラスター)を管理する必要がなくなります。発生するコストはコンテナーの使用料だけです。 これらの新しい機能は、Talend Connect US 2018の基調講演で紹介され、AWS FargateやAzure ACIでジョブのビルドから実行までのパイプライン全体のデモンストレーションを使用して解説されました。このブログでは、Jenkinsを利用してCI/CDパイプラインを作成する方法について説明します。最初にDockerイメージ内でジョブをビルドし、Dockerレジストリでイメージを利用できるようにします。そしてAWS FargateやAzure ACIを呼び出してイメージを実行します。 このプロセスを再現する方法を見ていきましょう。 まず、次の要件を満たしていることを確認して下さい。 Talend Studio 7.0 以降 Talend Cloud Spring 18’ 以降 Jenkinsサーバーを利用できること Jenkinsサーバーが、同じマシンにインストールされたDockerデーモンにアクセスできること Talend CommandLineがJenkinsのマシンにインストールされていること Nexus version 2 または 3 Talend CI BuilderがTalend CommandLineと共に構成されていること * 上記のTalendコンポーネントは全て、Talend Cloudの30日間の試用版で利用できます。 Talend環境 Talendを初めて使用する方向けに、各コンポーネントの概要について説明します。Talend Cloudから使用を開始し、Talend …

Read Article

データレイク構築で陥りやすい3つの落とし穴とその回避方法

| 2018年8月8日 | Big Data/Data Lake

最近、北米大手銀行のIT部門のSVP(シニアバイスプレジデント)とデジタルトランスフォーメーション戦略について話す機会がありました。その中で、ビッグデータやデジタルトランスフォーメーションに対するアプローチが絶え間なく進化しているという話が印象的でした。市場に新しく登場してきたテクノロジーの機能をビジネスに生かすには、新たな軸足やアプローチが必要です。データとアナリティクスの成長を維持/拡張できる俊敏性の高いアーキテクチャーを使用することが、これまで以上に重要になっています。ここでは、データレイクの構築で陥りやすい3つの落とし穴と、その回避方法について説明したいと思います。 「取り込みツールさえあればよい」 データレイクを構築すれば、あらゆる課題を解決できると思われがちです。確かに、データの格納場所ができることは成果と言えます。多くの場合、最初に課題となるのがデータの取り込みです。データレイクに流れ込む種類も量も莫大なデータの収集/取り込みに対処する必要があり、データさえ収集できれば簡単に目標を達成できると考え、データ取り込みソリューションを購入します。データのキャプチャーと収集は可能になりますが、これで問題が解決したのではありません。一時的には問題ないかもしれませんが、真の取り組みはこれからです。 データをデータレイクに格納することが始まりでしかないことは、すぐに明らかになります。多くのプロジェクトは、「データスワンプ(沼)」の問題により失敗します。これは、データレイクが構造を持たず、品質が低いうえに、人材も不足し、実際にデータがどこから来たのかトレースすることもできない状況を指します。生データは、そのままでは有用性が低く、データから質の高いアナリティクスを行うには、まずデータを処理し、クレンジングし、変換する必要があります。これが、2つ目の落とし穴につながります。 データレイクのハンドコーディング We have had many blogs in the past on this, but you can’t emphasize this topic enough. It’s strikingly true that hand coding may look promising from the initial deployment costs, but the maintenance costs can increase by upwards of 200%. The …

Read Article

Apache Beamを使用したデータ処理ジョブの開発 – ストリーミングパイプライン

| 2018年8月7日 | Open Source Streaming Data

前回のブログでは、Apache Beamを使ったデータ処理ジョブの開発について紹介しました。今回は、現代のビッグデータ処理で非常にニーズの大きなストリーミングデータの処理について説明します。 バッチとストリーミングの主な違いは、入力データソースのタイプです。データセットが限られていて(サイズが巨大でも)、処理中に更新されない場合は、バッチパイプラインを使用する可能性が高くなります。この場合、入力ソースはファイル、データベーステーブル、オブジェクトストレージ内のオブジェクトなど、何でもかまいません。もう一度強調しますが、バッチ処理では、処理の期間全体でデータが変更可能であり、入力レコードの数は一定です。この点に注意しなければならないのは、ファイルについても、常にファイルの追加や変更が行われるとデータストリームが無限になる可能性があるためです。その場合は、データを処理するためにストリーミングアプローチを適用する必要があります。したがって、データが限られていて不変であることがわかっている場合は、バッチ処理パイプラインを開発する必要があります。 データセットが無制限(継続的に到着)/可変の場合は、処理がより複雑になります。ソースの例としては、メッセージシステム(Apache Kafkaなど)、ディレクトリー内の新しいファイル(Webサーバーログなど)、その他のリアルタイムデータを収集するシステム(IoTセンサーなど)といったものがあります。これらすべての情報源に共通しているのは、常に新しいデータを待たなければならないという点です。もちろん、データを(時間ごとまたはデータサイズごとに)バッチに分割し、分割ごとにバッチ処理することも可能です。しかし、一部の関数については、すべての消費データセットに適用し、そのためのパイプラインを丸ごと作るのが困難です。幸いなことに、この種のデータ処理に簡単に対処できるストリーミングエンジンとして、Apache Spark、Apache Flink、Apache Apex、Google DataFlowを使用できます。これらはすべてApache Beamによってサポートされ、コードを変更することなく、異なるエンジンで同じパイプラインを実行できます。さらに、最小限の変更でバッチ処理でもストリーミングモードでも同じパイプラインを使用できます。入力パイプラインを正しく設定するだけで、即座に使用できます。バッチジョブをストリーミングジョブに書き換えていた頃から、このような機能があれば素晴らしいだろうと考えていました。 理屈はさておき、例を使用して最初のストリーミングコードを記述していきましょう。Kafka(無制限のソース)からデータを読み込み、簡単なデータ処理を実行し、結果をKafkaにも書き戻します。 リアルタイムで到着する地図上のいくつかのオブジェクトの地理座標(XとY)の無限の流れ(この例では、オブジェクトは車だとしましょう)があり、特定地域にあるものだけを選択したい場合を考えます。つまり、我々はKafkaトピックからテキストデータを消費し、それを解析し、指定された制限でフィルタリングし、別のKafkaトピックに書き戻す必要があります。Apache Beamを利用してこれを実現する方法を見ていきましょう。 それぞれのKafkaメッセージには、次の形式のテキストデータが含まれています。 id,x,y このとき: id – オブジェクトの一意のID x, y – 上の座標(整数) 形式に注意し、有効でない場合はスキップします。 パイプラインの作成 前回のブログでのバッチ処理と同じ方法でパイプラインを作成します。 Pipeline pipeline = Pipeline.create(options); Optionsオブジェクトを詳細に指定することで、コマンドラインオプションをパイプラインに渡すことができます。詳しくはGithubを参照してください。 次に、Kafkaの入力トピックからデータを読み込みます。すでに述べたように、Apache BeamはさまざまなIOコネクターを提供しています。KafkaIOもその1つです。したがって、指定されたKafkaトピックからの着信メッセージを消費し、それらをさらに次のステップに伝播する新しい無制限のPTransformを作成します。 pipeline.apply( KafkaIO.<Long, String>read() .withBootstrapServers(options.getBootstrap()) .withTopic(options.getInputTopic()) .withKeyDeserializer(LongDeserializer.class) .withValueDeserializer(StringDeserializer.class)) デフォルトでは、KafkaIOは消費されるすべてのメッセージをKafkaRecordオブジェクトにカプセル化します。ただし、次の変換は新しく作成されるDoFnオブジェクトによってペイロード(文字列値)を取得するだけです。 .apply( ParDo.of( new DoFn<KafkaRecord<Long, String>, String>() …

Read Article

効果的なTalendジョブ設計レビューの実施 – 入門編

どこの開発チームでも、一般的なプラクティスとしてコードレビューが実施されています(少なくとも、そうあるべきです)。コードレビューは、複数の開発者が記述されたコードを調べ、品質と正確さを向上させるために、その設計、実装、構造について議論するプロセスです。正式な手法、あるいは、より簡易な手法(ペアプログラミングなど)のどちらを実施するにせよ、実稼働前に欠陥や不足を見つけるために、コードレビューは効果的であることが証明されています。 さらに、コードレビューを実施することで、チーム内で確立されたベストプラクティスに沿って全員が作業を進めることができます。このチーム内でのコラボレーションにより、途中で新しいベストプラクティスを特定することも容易になります。それだけでなく、定期的にコードレビューを行うことで一定レベルの情報共有が実現され、すべての開発者がお互いから学ぶ機会が得られます。これは、経験の浅い開発者にとって特に有効ですが、上級の開発者もこのプロセスから学ぶことがあります Talendはコードジェネレーターなので、開発者が実際にコードを記述することはありませんが、その裏で、ジョブの開発中には行単位のコーディングで多くの要素を共通しています。すなわち、Talendは非常に柔軟なプラットフォームであり、開発者は様々な方法でジョブを構築できるのです。ジョブの設計、設定、オーケストレーションのフローをレビューするだけであっても、コードレビューを実施することのメリットを100%得ることができます。 Talendジョブレビューの「意義」 Talendジョブレビューの目的を一語で表すとすれば、「品質」でしょう。戦略的には、長期的にはジョブレビューによって当然のことながら開発者のスキルが向上し、ベストプラクティスが洗練されます。つまり、将来のジョブについては、ジョブレビュー前の段階からパフォーマンスが改善され、欠陥が減少し、そして保守が容易になるのです。 Talendジョブ設計レビューのメリットについて、上記の説明だけでは確信を持てない方もいるでしょう。開発者はそれなりのプライドをもってジョブを構築しているので、反応にばらつきがあるのも当然です。しかし、レビューのメリットに注目し、お互いから学び、全員のスキルを向上させる場として前向きに捉えることが重要です。レビューに参加している間は、関与する開発者に対して常に思いやりと敬意を持つべきです。チームによっては、正式なチーム全体のレビューよりもペアで行うレビューの方が効果的な場合もあります。ペアで実施する場合でも、オフラインではなく直接顔を合わせてのレビューの実施を推奨します。そのほうが、レビューのコラボレーションから得られるものが多いのです。実利をとることが重要です。コードレビュープロセスを改善する方法を提案するようにチームに求めましょう 定性的側面と定量的側面 Talendジョブをレビューするときには、質と量の両方から考えることが重要です。 質の面では、ベストプラクティスの適用と、それを採用することが必要です。Talendの推奨するベストプラクティスをまだ読まれていない場合は、ぜひ目を通してください。現在、4回シリーズのブログ記事で紹介しています。 Talendの「ジョブ設計パターン」とベストプラクティス - 第1回 Job Design Patterns & Best Practices PART 2(英語) Job Design Patterns & Best Practices PART 3(英語) Job Design Patterns & Best Practices PART 4(英語) ベストプラクティスに関するこれらの記事では、効果的なジョブ設計の定性的側面について説明しています。読みやすく、書きやすく、保守しやすいジョブを設計する方法について、推奨事項を紹介しています。さらに、より良いジョブを構築するために事前に知っておくべき、以下のような基本事項についても述べています。 機能 再利用可能性 拡張性 一貫性 パフォーマンス その他 これらの基本事項をうまく選択してバランスを取ることが成功の秘訣です。 成功するジョブ設計パターンの方法論と実践に関する後続シリーズ(現在のところ2回分)も参考にしてください。 Successful Methodologies …

Read Article

Apache SparkとTalend:パフォーマンスと調整

| 2018年4月12日 | ビッグデータ統合

このブログシリーズでは、すでに2つの記事でTalendとApache Sparkに関して説明してきました。 このブログシリーズのこれまでの記事をまだ読んでいない場合は、最初に第1部「TalendとApache Spark:技術的な手引きと概要」と第2部「Talend Sparkジョブ vs. spark-submitの構成:2つの違いとは?」をお読みください。 Apache Sparkに関するシリーズの最初の2回は、Talendとspark-submitの類似点、およびTalendのSparkジョブで使用可能な構成オプションの概要について説明しました。 このブログでは、Apache Sparkのパフォーマンスと調整について説明します。これは、Talendユーザーに限らず、Apache Sparkを使用しているほとんどのユーザーに共通の議論です。最初のSparkジョブを開発して実行するときには、常に次のような疑問が浮かびます。 Sparkジョブにはいくつのエクゼキューターを割り当てる必要があるのか? 各エグゼキューターに必要なメモリー量は? コアをいくつ使用する必要があるのか? 一部のSparkジョブは10GB程度のデータを処理するのに何時間もかかるが、この問題をどうやって解決できるか? このブログでは、これらの質問を取り上げ、答えと洞察を提供します。その前に、このブログで使用されるいくつかの重要な概念を紹介します。 パーティション:パーティションは分散データセットの一部です。デフォルトのHDFSブロックサイズで作成されます。Sparkはパーティションを利用してデータセットを並列処理します。 タスク:タスクは、エクゼキューター内で実行できる作業単位です。 コア:コアは、エクゼキューター内で実行できるSpark内の並列タスクの数を決定する、CPU内の処理単位です。 Sparkエグゼキューター:ワーカーノード上で開始され、メモリーまたはディスク内でジョブのサブミットを実行するプロセスです。 アプリケーションマスター:各YARNアプリケーションは、リソースマネージャーからリソースを要求する責任を持つアプリケーションマスタープロセスをスピンアップします。リソースが割り当てられると、プロセスはノードマネージャーと連携して、ノードマネージャー内で必要なコンテナーを起動します。 Sparkの調整 最初に、Talend内のApache Sparkジョブを調整する方法を検討しましょう。前述のように、Talend Sparkジョブには、[Spark Configuration]タブがあり、ここで調整プロパティを設定できます。Talendでは、これはデフォルトでは常にオフになっています。 このセクションには、アプリケーションのマスターとエグゼキューターが使用するメモリーとコア、およびジョブが要求するエグゼキューターの数を設定するオプションがあります。このセクションで値を指定する際の主な疑問は、「アプリケーションマスターやエグゼキューターがパフォーマンスを向上させるために必要なコア数またはメモリー数をどのように決定するのか」ということです。 Sparkジョブのコア数を選択する方法 この時点では、先に進む前に考慮しなければならない要素がいくつかあります。 データセットのサイズ ジョブが完了する必要がある時間枠 ジョブが実行している処理とアクション これらの要素を念頭に置いて、パフォーマンスを最大化するようにジョブを構成し始めることができます。まずアプリケーションマスターの調整から始めましょう。アプリケーションマスターの場合、リソースのオーケストレーションを行うだけで、処理は行わないため、デフォルト値をそのまま使用できます。つまり、メモリーやコアの値を大きくする必要はありません。 次のステップは、エクゼキューター用にメモリーとコアを構成することです。ここでの主な問題は、エクゼキューター、メモリー、コアをいくつ使うべきかということです。その答えを見つけるために、それぞれに32コアと120GBのメモリーを使用する6つのワーカーノードを持つHadoopクラスターがあるとします。おそらく頭に浮かぶ最初の考えは、エグゼキューターごとに持つことができる同時タスクが多いほど、パフォーマンスが向上するということです。これについて調べると、Hadoopディストリビューションのパフォーマンスチューニングガイド(Clouderaの例はこちら)では、1エクゼキューターあたり5コアを超えるとHDFS I/Oが低下することがわかります。したがって、高いパフォーマンスのためのコアの最適値は5です。 次に、いくつのエグゼキューターを起動したいのかを見てみましょう。コアとノードの数に基づいて、この数を簡単に判断できます。前述したように、5コアがエグゼキューターごとに使用するのに最適な数です。さて、ノードあたりの32個のコアのそれぞれから、ノードで実行されているオペレーティングシステムとHadoopデーモンで必要とされているために、ジョブに使用できないものを削除する必要があります。Hadoopクラスター管理ツールはすでにこれを行っているので、ノードあたりのSparkジョブに使用できるコアの数を簡単に判断できます。 この計算を行った後、使用可能なノードあたり30コアが残っているとしましょう。5コアがエグゼキューターあたりの最適な数であるとすでに決定したので、ノードあたり最大6つのエグゼキューターを実行できることを意味します。簡単に特定できましたね! 最後に、使用可能なメモリー量を計算します。上記のハードウェア仕様に基づいて、ノードごとに120GBのメモリーがあることがわかりますが、コアについて説明したときに述べたように、オペレーティングシステムが一部を使用する必要があるため、ジョブ用にそのメモリーをすべて使用できません。ここでも、Hadoopクラスター管理ツールは、メモリーのうちどれだけをジョブに使用できるかを判断できます。オペレーティングシステムとHadoopデーモンに2GBのメモリーが必要な場合、Sparkジョブに使用するために118GBのメモリーが残ります。ノードごとに6つのエクゼキューターを持つことができると決定済みなので、エクゼキューターごとに最大約20GBのメモリーを使用できることになります。ただし、これは100%正しいわけではありません。各エクゼキューターが持つメモリーオーバーヘッドも計算する必要があるためです。前のブログで、オーバーヘッドのデフォルトは384MBであると述べました。これを20GBから差し引くと、1エグゼキューターあたり最大19GBを指定できると言えます。 クラスターリソースの動的割り当て vs. 固定割り当て 上記の数値は、Sparkジョブ内のクラスターリソースの固定または動的割り当てに使用できます。両者の違いは動的割り当てです。動的割り当てでは、使用されるエクゼキューターの最初の数、それほどワークロードがない場合にジョブが使用できる最低限のエクゼキューター、より多くの処理能力が必要な場合の最大数を指定できます。ジョブのためにクラスターのすべてのリソースを使うことができれば素晴らしいですが、その処理能力をクラスター上で実行される他のジョブと共有する必要があります。そのため、Talend Sparkジョブの調整を検討するために先に定義した要因を検討する際に、要件として特定したものに基づいて、最大値の何パーセントを使用可能か決定します。 ジョブを構成したので、次は実際にジョブを実行しましょう。上記で定義した最大設定でもSparkジョブが完了までに時間がかかることがわかった場合は、最大のパフォーマンスを引き出すために、ジョブに戻り、さらにいくつかの設定を確認する必要があります。 Sparkのパフォーマンス まず、Sparkのジョブで2つのテーブルを結合しましょう。Sparkジョブの最適化を開始する前に検討した要因の1つは、データセットのサイズです。テーブルのサイズを確認し、1つが50GBで、もう1つが100MBであると判断したら、Talendコンポーネントのレプリケート結合を利用しているかどうかを確認する必要があります。 …

Read Article

Apache Sparkのパーティショニングの基礎知識

| 2018年3月5日 | Developer Step-by-Step ビッグデータ統合

Apache SparkのResilient Distributed Dataset(RDD)は、サイズが大きすぎて1つのノードに収まらないため、複数のノードに分割する必要があるさまざまなデータの集合です。Apache Sparkは自動的にRDDをパーティションに分割し、複数のノードに分散します。この操作は遅延評価され(たとえば、アクションがトリガーされるまで実行を開始しないことで管理性が高まり、計算量が低減するため、結果的に最適化と速度が向上します)、変換はDirected Acyclic Graph(DAG)として格納されます。したがって、RDDに対して何らかのアクションが実行されると、Apache SparkがDAGを再計算します。 Apache Sparkのパーティションの特性を理解しておくことで、パフォーマンスの向上、デバッグ、およびエラー処理が容易になります。 以下に、パーティション分割の基本情報をいくつか紹介します。 Sparkクラスター内の各ノードには、1つ以上のパーティションが含まれています。 Sparkで使用されるパーティションの数は設定が可能で、少なすぎると同時実行性の低下、データの偏り(データスキュー)、不適切なリソース利用の原因となり、多すぎるとタスクスケジューリングの所要時間が実際の実行時間より長くなるなどの問題が発生します。デフォルトでは、すべてのexecutorノード上のコアの総数に設定されています。 Sparkのパーティションが複数のマシンにまたがることはありません。 同じパーティション内のタプルは、同じマシン上にあることが保証されています。 Sparkはパーティションごとに1つのタスクを割り当て、各Workerは一度に1つのタスクを処理できます。 Apache Sparkでのハッシュパーティショニングとレンジパーティショニング Apache Sparkは「ハッシュパーティショニング」と「レンジパーティショニング」の2種類のパーティショニングをサポートしています。データ内のキーの分散方法または配列方法や、データに対して実行するアクションに応じて、適切な手法を選択します。以下のような多くの要因が、パーティショニングの選択に影響を与えます。 利用可能なリソース — タスクを実行できるコアの数。 外部のデータソース — ローカルコレクション、Cassandraテーブル、またはHDFSファイルのサイズによってパーティション数が決まります。 RDDの派生に使用される変換 — RDDが別のRDDから派生する際にパーティションの数を決定するためのルールが多数存在します。 Apache Sparkの使用に際しては、留意すべき点がいくつかあります。このブログでは、ビジネスデータ、そのデータのキー、Spark処理における物理リソース、そして何よりもネットワーク、CPU、メモリーを完全に認識しておくことの重要性について説明します。 Apache Sparkのパーティショニングでよく見られる問題には次のようなものがあります。 データの偏り(データスキュー)とシャッフルブロック Apache Sparkのデフォルトのパーティション分割ではデータの偏りが発生し、その結果、データ集約操作中のシャッフルや単一のエグゼキューターのメモリー不足に関連した問題が発生する可能性があります。 この例では、「key-a」のパーティション内のデータ量が大きいため、Exec-5のタスクの完了には他の5つのタスクよりもはるかに長い時間を要します。もう1つの重要なのは、Sparkのシャッフルブロックは2GB以下でなければならないという点です(内部的にByteBuffer抽象化ではMAX_SIZEが2GBに設定されているため)。たとえば、集約、結合、キャッシュ操作などの操作を実行している場合、Sparkシャッフルが発生し、パーティションの数が少ないことやデータスキューが原因でシャッフルブロックの問題が発生する可能性があります。したがって、シャッフルによるMAX_SIZE制限の違反に関連するエラーが発生し始めた場合には、データの偏りが原因であることがわかります。 賢明なパーティショニング では、どうすればデータの偏りとシャッフルブロックを回避できるのでしょうか。非常に重要なのは、メモリープレッシャーを管理し、エグゼキューターのノードでリソースをフル活用できるよう、賢明な方法でパーティション分割を行うことです。そのためには、データのサイズ、タイプ、分散方法を常に把握しておく必要があります。覚えておくべきベストプラクティスは次のとおりです。 ドライバーに負荷をかけないように、またエグゼキューター上でタスクが適切に実行されるように、reduceByKeyやaggregateByKeyなどのアクションの正しい演算子を理解し選択します。 いくつかの大規模で分割不可なファイルでデータを受け取った場合、InputFormatによるパーティション分割では各パーティションに大量のレコードを配置される可能性があります。しかし、利用可能なすべてのコアを活用するのに十分なパーティションは生成されません。この場合、データのロード後に多数のパーティションを使用する再パーティションを呼び出すことで、後続の操作でクラスターのCPUをより多く利用できるようになります。 また、データが偏っている場合は、負荷を均等に分散できる適切なキーを使用して再パーティション化することも推奨されます。 Talendは、選択された適切なキーに基づいて、再パーティション化に必要なtPartitionコンポーネントを提供します。 最適なパーティション数を算出するには Apache Sparkは、RDDの各パーティションに対して1つの同時タスクしか実行できず、その最大数はクラスター内のコア数(またはその2~3倍)になります。したがって、「最適な」数のパーティションを選択するためには、一般的に最低でも並列処理用のエクゼキューターの数と同数のパーティションが必要です。この数値を算出するには、sc.defaultParallelismを呼び出します。パーティションの最大サイズは、最終的にはエグゼキューターの利用可能なメモリーによって決まります。 適切な再パーティション化キーを使用してデータを均等に分散することが不可能な場合もあります。そこで、新しい「偽の」キーを追加し、現在のキーと一緒に使用することでデータを均等に分散させるソルトなどの方法を使用します。次に例を示します。 …

Read Article

Talend Sparkジョブ vs. spark-submitの構成:2つの違いとは?

| 2018年2月21日 | Hadoop Streaming Data ビッグデータ統合

前回のブログ、「TalendとApache Spark:技術的な手引きと概要」では、Talend Sparkジョブとspark-submitの対応について説明しました。このブログ記事では、Apache spark-submitとの比較でTalend Sparkの構成を引き続き評価していきます。最初に、Talend Sparkジョブでの[Spark Configuration]タブのオプションをspark-submitに引数として渡す先にマッピングする方法を検討し、それらの使用について説明します。 コマンドの違い お使いの環境でApache Sparkジョブ(Sparkが正常に機能することを確認するために使用される、Hadoopクラスターでデフォルトとして提供されるApache Sparkサンプルジョブなど)を実行するときは、次のコマンドを使用します。 export HADOOP_CONF_DIR=XXX./bin/spark-submit –class org.apache.spark.examples.SparkPi –master yarn –deploy-mode client –executor-memory 5G –num-executors 10 /path/to/examples.jar 1000 上記の2つのコマンドは、spark-submitジョブがクラスター構成ファイルを読み込むディレクトリーを設定します。次に、Sparkサンプルジョブを実行するために、10のエクゼキューターと5Gのメモリーを使用して、クライアントモードによりYARNクラスター上でSparkを実行するspark-submitコマンドを発行します。 次に、同じSparkサンプルジョブがTalendでどのように実行されるのかを見てみましょう。TalendでSparkサンプルジョブ(上記のようなもの)を実行すると、すべてのSpark構成情報が実行タブ内の次のタブに入力されます。 ここでいくつか疑問が生まれます。Talendに入力した情報は、Sparkジョブを実行するために端末に入力した情報にどのように対応するのか? どのくらいの数のエグゼキューターとメモリーを要求したのかを、どうやって知ることができるのか? トラブルシューティングについてはどうか? これらの質問すべてに答えていきます。 まず、このブログで使用されるspark-submitのオプションをいくつか紹介します。Apache Sparkドキュメントによると、これらはspark-submitスクリプトに渡すことができる一般的なオプションです。 –class:これは、Sparkアプリケーションの主なエントリーポイントです。 –master:このオプションでは、SparkマスターをスタンドアロンのSparkとして使用するか、YARN上でSparkを使用するかを指定します。 –deploy-mode:前のブログで述べたように、これは利用可能な2つのYARNモードに移り、Sparkドライバーの展開方法を詳述します。 –conf:このオプションでは、ジョブに使用させる追加のSpark構成(たとえば、spark.executor.userClassPathFirst=true)を渡します。 –application-jar:これは、Apache Sparkが実行するSparkのコンパイル済みコードを配置した場所のパスを指します。 –application-arguments:このオプションでは、Sparkコードに固有の引数を渡します。 では、Talend Sparkジョブ内で上記のオプションがどのように使用されるのかを見てみましょう。実行タブの[Spark Configuration]タブでは、設定可能なさまざまなオプションが論理的に次のカテゴリに分類されています。 クラスターのバージョン 構成 認証 調整 …

Read Article

TalendとApache Spark:技術的な手引きと概要

| 2017年9月15日 | Developer Step-by-Step Hadoop ビッグデータ統合

Talendのカスタマーサクセスアーキテクトチームに加わる前の数年間は、サポートエンジニアとして、Apache SparkでのTalendの機能についてお客様からよく質問を受けました。Sparkについて話すとき、最初に頭に浮かぶのはspark-submitコマンドです。これはSparkジョブをサブミットするために使用するものです。そのため、TalendのSparkジョブと通常のspark-submitの対応についての疑問が自然に生じます。このブログでは、提供されているさまざまなApache Sparkモード、Talendで使用されるモード、およびTalendとApache Sparkの連携について説明します。 Apache Sparkジョブについて Apache Sparkでは、2種類のジョブをサブミットできす。そのうちの1つはSpark Batchで、もう1つはSpark Streamingです。Spark Batchはバッチ処理モデルで動作します。このモデルでは、一定期間にわたって収集されたデータセットがSparkエンジンに送信され、処理されます。 他方のSpark Streamingはストリーミングモデルで動作し、データがSparkエンジンに1つずつ送信され、処理がリアルタイムで行われます。Talendは両方のジョブタイプをサポートしており、それぞれのタイプ向けにSparkジョブを作成できます。Talend Studioでは、ライセンスに応じて、Spark Batchジョブを作成するための「ビッグデータバッチ」とSpark Streamingジョブを作成するための「ビッグデータストリーミング」のオプションを使用できます。 TalendとApache Sparkについて、さらに検討 先に進む前に、このブログで使用される重要な概念をいくつか紹介します。 Sparkドライバー:アプリケーションをSparkマスターに送り、Spark Contextを作成・実行します。 Sparkマスター:Sparkドライバーの定義に従ってYARNからリソースを要求し、ジョブを実行するホストを見つけます。 Sparkエグゼキューター:ワーカーノード上で開始され、メモリーまたはディスク内でジョブのサブミットを実行するプロセスです。 はじめに、spark-submitまたはTalendを使用してSparkジョブがどのように機能するかについて、いくつかのコンテキストで見ていきます。Sparkのジョブには、Sparkのジョブを設定・調整する「ドライバー」が常にあります。この場合、Sparkドライバーは、接続に使用するSparkマスターやSparkエグゼキューターに割り当てるメモリー量など、ジョブが使用する構成をセットアップします。したがって、Talendは、Sparkジョブを設定・調整するSparkドライバーが常に存在するという前提の下で、spark-submitと同等の機能を果たします。 これで、Hadoopクラスター内からspark-submitを実行したときに、一部の構成情報がクラスター構成ファイルから取得されます。Talend Studioは常にHadoopクラスター上にあるわけではないので、使用できる設定を認識できるようにするために、Studioでのジョブ内でこの情報を提供する必要があります。 Sparkジョブで行われるデータ変換は、Talendでは、spark-submitプロシージャーが使用されるときに行われるものと同一のジョブのコンパイル時に行われます。spark-submitと同様に、Talendもジョブを上記のように定義された「ドライバー」として開始しますが、ジョブはドライバー内ではなく、クラスターレベルのSparkエグゼキューター上で実行されます。ジョブが開始されると、TalendはHadoopクラスターレベルで発生しているイベントを監視して、ジョブの進行状況を確認することでジョブを監視します。これは、ユーザーがspark-submitを使用する場合と似ています。 spark-submitまたはTalendジョブのいずれかを使用してSparkにジョブをサブミットする場合、Hadoopクラスター構成に応じて3つのモードが提供されます。Sparkドキュメントでは、以下の3つのモードがあります(http://spark.apache.org/docs/latest/cluster-overview.html)。 1. スタンドアロン:このモードでは、SparkドライバーがジョブをサブミットするSparkマスターと、ジョブを処理するためにクラスター上で実行されるSparkエグゼキューターがあります。 2. YARNクライアントモード:ここでは、各ジョブに割り当てられたSparkワーカーデーモンがYARNフレームワーク内で開始・停止されます。上記で説明したSparkドライバーは、Talendジョブを実行しているのと同じシステム上で実行されます。 3. YARNクラスターモード:SparkマスターとSparkエグゼキューターはYARNフレームワーク内で実行されます。これらはジョブと共に開始・停止します。この場合、SparkドライバーもHadoopクラスターレベルのYARN内で動作します。 Sparkが提供するモードを定義したので、次にTalendが提供する機能を見ていきましょう。Talendでサポートされるモードは次のとおりです。 1. ローカル:これを選択すると、ジョブはSparkフレームワークをローカルでスピンアップして、ジョブを実行します。ローカルマシンが、Sparkマスターとして、そしてデータ変換を実行するためのSparkエグゼキューターとしても使われます。 2. スタンドアロン:このモードでは、上でも定義されているように、TalendはHadoopクラスターで定義されているSparkマスターに接続してからジョブを実行します。 3. YARNクライアントモード:上記で定義したように、Talend StudioはSparkの「ドライバー」を実行して、ジョブの開始場所からジョブのオーケストレーションを行い、次にオーケストレーションをYARNフレームワークに送信してリソースの実行と割り当てを行います。これは、Hortonworks、Cloudera、MapR、Amazon EMRなどのHadoopディストリビューションで使用できる選択肢です。 4. YARNクラスター:このモードは現在、Talend内のHDInsightとCloudera Altusでのみサポートされています。前述のとおり、このモードでは、TalendはHadoopクラスターレベルのYARN内でSparkの「ドライバー」を実行します。 TalendとApache …

Read Article