注目の投稿

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

詳細情報
注目の投稿

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

詳細情報
注目の投稿

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

詳細情報
注目の投稿

オンプレミスからクラウドにデータを移行する方法:Amazon S3

詳細情報
注目の投稿

データガバナンス戦略を構築するために重要な5つの考慮事項

詳細情報

データモデルの設計とベストプラクティス(第2部)

| 2019年5月20日 | Database Integration Developer Step-by-Step ETL / ELT ビッグデータ統合

  データモデルとは何を指すのでしょうか。毎日データモデルに接して熟知しているTalendの開発者は、以下のようにデータモデルを定義しています。 ビジネスシステムデータの構造的定義 ビジネスデータのグラフィカルな表現 ビジネスソリューションを構築するためのデータ基盤 これらはいずれも真実かもしれません。しかしあえて言うなれば、いずれも本質的な定義ではありません。それぞれ単独では、データモデルが本来実現すべき核心/目的あるいは目標に到達するものではなく、末梢的であるためです。 では、何が本当にデータモデルであると言えるのでしょうか。あれこれ思いつくものの、やはり一点に尽きるのではないでしょうか。私にとって、データモデルは、ビジネス情報システムをグラフィカルな方法で明確に特徴付けるものとして表現される構造基盤です。どう思われますか? 上記の定義と同一というわけではありませんね。この定義は、すべての要素を単一の目的に包含します。つまり、データだけでなく、構造的にビジネスのユースケースに関する情報を識別するための手段なのです。 このブログシリーズの第1部では、50年間のデータモデリングの歴史を4つの短い段落にまとめました。省いた部分もありますが、前任者から学んだ教訓と改善の結果として、データモデリングに関する私たちの知識や達成がどのように実現したのかを理解できるのではないでしょうか。今日、ほとんどの企業が要件を検証するために活用してるデータモデルには、真のビジネス価値があります。しかし、これらの企業が正しい方法を理解しているかどうかを疑問に思うことがよくあります。多くの場合、永続性のあるデータモデルに対する幻想は、とりあえずモデルが存在するという事実のみによって推定され、それが正しいかどうかは確認または検証されていないのです。 私は、データアーキテクチャーとデータベース設計の実務家として、あまりにも多くの粗悪なデータモデルを目にしてきたため、ほとんどのデータモデルには何らかの問題があると言わざるを得ません。その一方で優れたモデルも多く見てきましたが、それではデータモデルの良し悪しをどのように判断できるのでしょうか。それは重要なことなのか、データの出入りに問題がなければ十分ではないのか、と疑問に思われるかもしれません。しかし、データモデルの良し悪しは明らかに重要なのです。データモデルを基盤として/データモデルと協調して運営されるビジネスシステムを確実に成功させるためには、データモデル自体が優れたものである必要があります。データモデルはビジネスの本質です。したがって、包括的であり、非の打ちどころがなく、回復力のあるものでなければなりません。 このことから、優れたデータモデルを使用する動機は明らかです。Talend StudioのようなETL/ELTツールを使ってデータを出し入れし始めると、それが明らかになります(ほとんどの人には)。どのようなソフトウェアプロジェクトでも、データモデルは欠かすことのできない3つの技術的要素の1つです。ほかの2つの要素は、アプリケーションコードとユーザーインターフェイスです。 本シリーズの第1部では、私が設計するすべてのデータモデルで採用されているデータベース開発ライフサイクル(DDLC)の方法論を取り上げましたが、お読みいただいたでしょうか。この方法論は私にとって役立つものであり、データベース開発に本気で取り組んでいるすべてのチームはぜひとも採用すべきです。このプロセスを理解して採用することで、データモデルの実装と保守を合理化/自動化/改善できます。しかし、このプロセスについては、ほかの事柄も検討する必要あります。ビジネスに貢献する信頼性、柔軟性、正確性を備えたデータモデルを促進できる、追加のベストプラクティスをご紹介します。 データモデリングのベストプラクティス 多くのデータモデルは、モデラーが論理モデルを作成してから物理モデルを作成するプロセスによって設計されます。通常、論理モデルは実体と属性、および両者を結び付ける関係を記述して、データのビジネス目的を明確に表現します。続いて、物理モデルは論理モデルを実装します(論理モデルは、テーブル、列、データ型、索引として、簡潔なデータ整合性規則と共に実装されます)。これらの規則は、プライマリーキーと外部キー、およびデフォルト値を定義します。さらに、必要に応じて実装をサポートするために、ビュー、トリガー、ストアドプロシージャーが定義されることがあります。物理モデルは、ほとんどのホストシステム(Oracle、MS SQL Server、MySQLなど)が提供する特定の構成オプションに基づいて、ディスク上のストレージ割り当ても定義します。 納得できることですね。それにもかかわらず、私は論理モデルと概念モデルの違いをめぐる激しい議論を何度も経験してきました。多くの人は、これら2つは同じであり、どちらもビジネスデータの実体と属性を提示するものであると言います。私も同意見です!概念モデルは、データに対するビジネス上の理解(技術的な理解ではありません)についてコンテキストを提供することを目的とします。概念モデルはすべてのステークホルダーが理解できるものであり、多くの人が実体と属性に取り組んでいます。適切な概念モデルは、すべての関係者にとってビジネスデータのコミュニケーションのために最善のツールになります。統一モデリング言語(UML)の側面を使用することで、概念モデルを図解して、細かい事柄にとらわれずにシンプルに保持できます。詳細は論理モデルと物理モデルで不可欠ですが、それぞれで洗練させればよいでしょう。 一般的に多くのアプリケーションシステムを使用しているエンタープライズビジネスでは、データのモデル化で高次の懸念が生じます。概念モデル、論理モデル、物理モデルだけでは十分ではありません。そこで登場するのが、全体論的データモデル(少なくとも、私がそれを改造したモデル)です! 全体論的データモデルの目的は、企業全体でデータサイロを識別・抽象化することです。これにより、データサイロが存在する場所、必要な場所、相互に関連する場所、そして最も効果的に使用するために体系づける方法を大局的に説明します。 データモデリングプロセスの4つの階層 企業内に4タイプの異なるデータモデルが存在する可能性を考慮して、定義、理解の洗練化、および具体的な設計のために、「階層」としてトップダウン型で従うデータモデリングプロセスを次のように提案します。各レベルの主要な役割については、プロセスのどこで誰が関与したかを明確にします。 全体論的データモデル: 全体論的な層は、全社的なデータサイロの抽象的な環境を表します。このデータモデルは、広範なビジネスデータガバナンスを確立する機会を生み出し、それによって企業に固有のすべてのデータ関係に対する理解を深めることができます。それらのサイロは、社内外のアプリケーションからのデータを取り込むことを目的としています。バブルチャートを使用すると、全体論的データモデルを図解できます。以下のように設計します。 バブルチャート – データサイロ バブルチャートは、一意のデータサイロを表す単純なバブルで構成されます。2つ(2つだけ)のバブルを結ぶ線(「リンク」)は、2つの間に何らかの関係が存在することを示します。基本的には、バブルの各集合(多くの場合、放射状の「スポーク」を持つ中心の「ハブ」として示されます)は、企業全体で識別された特定のデータサイロのセットを具体化するものであり、それ以上でもそれ以下もありません。要素の詳細は以下のとおりです。 青色の実線で表されたリンクは、2つのデータサイロ間の直接的な関係を示します。赤色の破線で表されたリンクは、2つのデータサイロ間の間接的な関係を示します。緑色の点線で表されたリンクは、2つのデータサイロ間の拡張された関係を示します。これらのリンクは、複数の関係(概念層で定義)を表すことがあるため、主観的に使用します。単に関係が存在すると定義します。 バブルの周囲を、より大きいバブルが囲むことがあります。大きい方のバブルは、そのデータサイロに固有の分類を体系化するオントロジーが存在する(または存在すべきである)ことを意味します。オントロジーとその分類メタデータは、それが囲むサイロへの有意義なマッピングを提供します。これは、データを高度に検索可能にするのに大いに役立つものであり、この層で識別されるべきです。 バブルチャートは、ビジネス情報の特定の集合を定義します。その目的は、サポート対象のアプリケーション、実装または技術的詳細がない情報を識別、単純化、統合することです。全体論的データモデルのメリットは、すべてのオーディエンスが単一の包括的かつ単純化されたビューで企業データ環境を理解でき、基盤となるデータモデルをほとんど/まったく中断することなく新しいデータを識別してモデルに挿入する(後述)ための柔軟な出発点を提供できることです。 ここに示したのは、完全に定義された全体論的データモデルの図解の一例です。プリンターで大きく印刷して壁に貼り、皆で検討することで、活発で生産的な会話が生まれ、それがビジネスにとって効果的で価値ある資産になります。 概念データモデル: 概念層は、ビジネスデータ要素とそれらの関係の抽象的な定義を表します。このデータモデルは、アプリケーションの観点から企業データ環境のセマンティクスを定義し、これによって基盤となるビジネス情報の理解が深まります。UMLは、このモデルを設計するためのグラフィカルな手段となります。要素オブジェクトから成る概念データモデルは、全体論的モデルのデータサイロから抽出された情報クラスを定義します。基本的には、これを情報モデルと考えることができます。以下のように設計します。 UML情報アーキテクチャー 各要素オブジェクトは、データサイロの特定部分と、2つ(やはり2つだけ)の要素間の関係を定義する接続線(「リンク」)をカプセル化します。特定の要素項目(「特性」)は、オブジェクトの理解と目的をさらに支援するために定義され、以下のいずれかになります。 保護(値は事前に決定) パブリック(値は可変) プライベート(値の使用が制限) 直接的に相互接続された要素オブジェクトは、グレーの実線のリンクと意図的なラベルによって示される「関連付け」を持つと見なされます。これらの関連付けは、親要素に付けられた菱形により、次のいずれかの関係を表します。 単純(菱形なし) 共有(塗りつぶしのない菱形) 複合(塗りつぶされた菱形) 子要素が「ナビゲート可能」な場合は、矢印と関係基数(0.* = ゼロから多数、など)で示されます。 要素オブジェクトは、「一般化」を持つこともできます。つまり、オブジェクトのインスタンスは、特定または一意の特性や関係を持つことができます。この例では、オブジェクトは1つの親要素のサブクラスに似ており、親のすべての特性に加えて、関連する一意の特性をすべて追加的に含みます。サブクラス要素は、その名前と表現の両方で洗練化されることで、抽象化された全体論的データサイロの理解しやすい洗練化を提供します。要素オブジェクトに結合する一般化は、親オブジェクトに閉じた矢印が付いた青色の実線のリンクで示され、ラベルは不要です。 …

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

LambdaからKappaまで:リアルタイムビッグデータアーキテクチャーのガイド

| 2017年8月28日 | Streaming Data ビッグデータ統合

今日では、リアルタイムビッグデータアーキテクチャーを選べるようになっています。現在の選択肢はLambdaだけではありません。このブログシリーズでは、これら2つの選択肢について説明し、関連するユースケースで比較します。リアルタイムプロジェクトに適したアーキテクチャーを選択する方法について紹介します。 リアルタイムの要件 アーキテクチャーのトピックに入る前に、ビッグデータシナリオにおけるリアルタイムデータ処理システムの要件のいくつかについて検討しましょう。 これらの要件の中でも、データが動いているという点は最も明白なものです。言い換えれば、データは連続的で無制限です。重要なのは、このデータをいつ分析するかということです。現在のデータのスナップショットに対する回答を探している場合、または特定の低レイテンシー要件がある場合は、リアルタイムのシナリオを検討しているでしょう。 さらに、多くの場合はビジネス上の期限に対応しなければなりません。結局のところ、リアルタイム分析の期限を守らなくても影響がないのであれば、バッチ処理のプロセスでもかまいません。これらの影響は、完全な障害から単なるサービスの低下まで多様です。 ここで問題となっているのはビッグデータであることから、データのボリューム、速度そしておそらく種類の限界をも押し広げることが期待されています。 リアルタイムデータ処理は、スケーラビリティ、フォールトトレランス、予測可能性、ストリームの不完全性に対する回復力などの品質を必要とし、拡張可能でなければなりません。 新データ時代の新アーキテクチャー この必要性に取り組むために、新しいアーキテクチャーが生まれました。つまり、「必要は発明の母」です。 Nathan MarzによるLambdaアーキテクチャーは、今日のリアルタイムデータ処理で最も一般的なアーキテクチャーの1つです。低レイテンシーの読み取りと更新を直線的にスケーラブルかつフォールトトレラントな方法で処理するように設計されています。 システムに到着するデータストリームは、バッチレイヤーとスピードレイヤーの両方に二重に供給されます。 バッチレイヤーは、生データを到着時に保存し、消費のためにバッチビューを計算します。当然のことながら、バッチ処理は一定の時間間隔で発生し、長期間存続します。データの範囲は数時間から数年まで及びます。 スピードレイヤーは、リアルタイムビューを計算してバッチビューを補完するために使用されます。 どのようなクエリーでも、バッチビューとリアルタイムビューの両方からデータを取得することで、全体像を把握できます。クエリーは両方の長所を利用します。バッチビューはより複雑で高価なルールで処理され、データクオリティにより優れ、スキューがより少ないかもしれません。一方、リアルタイムビューは可能な限り新しいデータへのアクセスを提供します。時間が経過するにつれて、リアルタイムデータは期限切れになり、バッチビューのデータに置き換えられます。 このアーキテクチャーのもう1つのメリットは、コードまたは式が変更された場合に、同じ受信データを再生して新しいビューを生成できることです。 このアーキテクチャーの最大の欠点は、バッチレイヤーとスピードレイヤーの両方を生成するために、2つの異なる(そして、おそらく複雑な)システムを維持する必要があることです。幸いなことに、Spark Streaming(抽象化レイヤー)やTalend(Spark BatchおよびStreamingコードジェネレーター)を使うことで、操作上の負担は残りますが、問題ははるかに少なくなります。 次に、Kappaアーキテクチャーについて説明します。 Kappaアーキテクチャーは、Jay Krepsによって最初に記述されました。データをストリームとして処理することのみに焦点を当てています。ユースケースが当てはまる場合を除き、Lambdaアーキテクチャーの代替にはなりません。このアーキテクチャーでは、受信データはリアルタイムレイヤーを介してストリーミングされ、その結果はクエリー用のサービングレイヤーに配置されます。 その目的は、リアルタイムのデータ処理と連続的な再処理の両方に単一のストリーム処理エンジンで対応することです。つまり、再処理はストリームから発生することになります。そのためには、受信データストリームを丸ごと、または特定の位置から(非常に高速で)再生できることが必要です。コードに変更があると、2番目のストリームプロセスが最新のリアルタイムエンジンを介して以前のデータをすべて再生し、サービングレイヤーに格納されているデータを置き換えます。 このアーキテクチャーは、Lambdaアーキテクチャーのようにバッチレイヤーとスピードレイヤーそれぞれのコードベースを管理するのではなく、コードベースを1つだけにすることで単純化を図ります。さらに、クエリーは、バッチビューとスピードビューに対してではなく、単一のサービング場所を検索するだけで済みます。 このアーキテクチャーの複雑さは、重複するイベントの処理、イベントの相互参照、順序操作の維持など、通常はバッチ処理で簡単に実行できるデータ処理をストリームで実行する必要があることに、主として起因します。 単独ですべてに対応できない場合もある Lambdaアーキテクチャーには多くのリアルタイムユースケースが適合しますが、Kappaアーキテクチャーについて同じことは言えません。バッチ分析とストリーミング分析が同じ場合は、Kappaを使用するのが最善の解決策です。ただし、場合によっては、バッチウィンドウで完全なデータセットにアクセスすると特定の最適化が起こるため、Lambdaの方がパフォーマンスに優れ、実装が簡単になる可能性があります。 また、バッチアルゴリズムとストリーミングのアルゴリズムがまったく異なる結果を生成する、非常に複雑な状況(機械学習モデル、エキスパートシステム、またはリアルタイムで異なる方法で実行する必要がある本質的に非常に高価な操作を使用する)もあります。そのような場合には、Lambdaを使用する必要があります。 以上、最も人気のある2つのリアルタイムデータ処理アーキテクチャーについて取り上げました。このシリーズの次回の記事では、各アーキテクチャーについてさらに詳しく説明し、具体的なユースケースと、よく見られるテクノロジーについて検討します。 参考文献: 「How to beat the CAP theorem」(Nathan Marz) http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html 「Questioning the Lambda Architecture」(Jay Kreps) https://www.oreilly.com/ideas/questioning-the-lambda-architecture 「Big Data」(Nathan Marz、James …

Read Article

Apache SparkとTalendを使用してHadoopにOracle及びMySQLデータベースをオフロードする方法

| 2017年2月1日 | Data Migration Database Integration Developer Step-by-Step ビッグデータ統合

ビッグデータの分野では、従来のデータウェアハウスをHadoop環境にオフロードすることが一般的です。一次使用向けの場合も、「コールドデータ」を保存するためだけの場合も、Talendは負担のないオフロードを実現します。 データアーキテクチャーを最適化しようとする多くの組織は、Hadoopをコールドデータに利用したり、アーカイブの維持のために使用したりしています。 Talendは、Hadoopのネイティブコード生成によってこのプロセスを容易にすることができます。 Talendはすでに、Sqoopを使用してこの手法をサポートするためのコネクターを事前に組み込んでいます。ここでは、Apache Sparkを使って同じ目的を達成する方法について説明します。 Download >> Talend Open Studio for Data Integration Apache Sparkは、大規模データ処理のための高速の汎用エンジンです。 このエンジンは、Hadoopディストリビューションのほとんどの最新バージョン(Cloudera、Hortonworks、MapR、AWS EMR等)で利用できます。Massively Parallel Processing(MPP)アーキテクチャー上に構築されているため、データフローを大規模に並列化してあらゆるエンタープライズワークロードを処理できます。 現在、データベースからHadoopにデータをオフロードする手段として最も高速で最も広く知られているのは、Sqoopを活用する方法です(SqoopはMapReduceプロセスの下でRDBMSからHadoopへのオフロードを実行します)。 ここでは、Sqoopを使用する場合と同じ目的を達成するために、SPARKをフレームワーク/エンディングとして使用する方法をご紹介します 最初に、Sparkを使用して1つのテーブルをOracleまたはMySQLからHadoopに移動する方法について解説します。ジョブが準備できたら、データベースサーバーからHadoopに移動するためにテーブルリストによって制御される汎用ジョブを作成するタスクを実行します。 わかりやすくするために、次の2つのシナリオで検討します。 SparkジョブからHDFSへテーブルをオフロードする 上記のジョブを自動化し、メタデータ駆動型の取り込みフレームワークに変換してテーブルリストを操作する SparkジョブからHDFSへテーブルをオフロードする このシナリオでは、Apache Sparkと次のような一般的なQueryステートメントを使用して、データベーステーブルから抽出したデータをHDFSに移動する非常に一般的なジョブを作成しています。 “SELECT concat_ws (‘” + context.FIELD_SEPARATOR + “‘,” + context.column_list + “) as my_data FROM my_table”. ) As my_data FROM my_table “. Context.FIELD_SEPARATOR …

Read Article

ビッグデータガバナンスとメタデータ管理を成功させるためのTalendの5本の柱

| 2016年10月10日 | Data Management / Data Governance Hadoop MDM / Metadata ビッグデータ統合

  本シリーズの前回の記事では、データガバナンスによりビッグデータイニシアティブを持続可能な成功に導くための6つの鍵を検討しました。 これらの6つのステップは、TDWIが最近発表した「Governing Big Data and Hadoop(ビッグデータの管理とHadoop)」というレポートで明らかにされたものです。 このレポートは、独立した立場から課題とベストプラクティスについて取り上げていますが、Talendによる課題への具体的な取り組みについては明記していません。シリーズ第2回となるこの記事では、前回述べた6つの重要課題に対して、Talend Data Fabricの統一プラットフォームを構成する各主要コンポーネントがどのように対処できるかについて説明します。これを、メタデータ管理のためのTalendの5本柱と呼びます。 Talend Studioで設計するメタデータ メタデータがなければ、情報サプライチェーンの包括的で活用可能なビューを作成する方法はありません。 メタデータがなければ、情報サプライチェーンの包括的で活用可能なビューを作成する方法はありません。 メタデータは、場合によっては遡ってエンジニアリングすることもできますが、作成後のメタデータを即座にソースで収集、処理、保守、追跡する方がはるかに簡単です。 Talendを使用する場合、データフローはビジュアルなメタデータ駆動型環境で設計されます。 これによって、開発と展開が加速するだけではありません。データフローが実行されると、情報サプライチェーンの詳細なビュー(データの元の場所、保存場所、データポイント間の依存関係)が提供されます。 Map ReduceやSpark等の多くの強力なデータ処理環境は、SQL等の従来のデータ管理標準と違ってメタデータ駆動型ではないため、これはビッグデータの領域では非常に重要です。 Talend Open Studioのような高レベルの抽象化を提供し、ゼロコーディングアプローチを採用しているツールがなければ、Hadoopのデータ駆動型プロセスの管理、ガバナンス、保護は非常に難しくなります。 Talend Open Studioとその集中リポジトリは、常に最新のバージョンのデータフローを維持してデータ設計者や開発者の間で共有し、Cloudera Navigator、Apache Atlas、Talend Metadata Manager等の他のツールにエクスポートして、より広範なデータワーカーに公開できます。この最後の点に関する詳細は後述します。 さらにTalendは、開発者がデータ管理の全ての分野(データ統合、ビッグデータ統合、アプリケーション統合、クラウド統合、データクオリティ及びMDM、セルフサービス型データプレパレーション)を単一プラットフォームで使用することを可能にしています。これによってIT部門は、オンプレミスまたはクラウドの従来のデータとビッグデータの両方で、保存データと実行データの両方についてデータフローのグローバルビューを提供できます。 Talend Metadata Bridgeを使用してデータプラットフォーム全体でメタデータを同期する Talend Metadata Bridgeを使用すると、開発者はTalend Studio(及び、同様にTalend Metadata Manager)からメタデータをインポート及びエクスポートすることができ、ほぼ全てのデータプラットフォームのメタデータにアクセスできます。 100以上のコネクターが用意されているTalend Metadata Bridgeは、モデリングツール(Erwin、Embarcadero等)、ETLツール(Informatica、IBM DataStage等)、SQL及びNoSQLデータベース、Hadoop、人気の高いBI及びデータ検出ツール(Tableau、Qlik、BusinessObjects等、XMLまたはCobol構造等)からメタデータを取得するのに役立ちます。 これらのブリッジにより、開発者は一度設計したデータ構造を、さまざまなツールやプラットフォームにわたって繰り返し伝播させることができます。 これにより、ほとんどのサードパーティツールやプラットフォームからTalendにデータ形式を変換できるため、標準仕様を容易に適用し、変更を伝播させ、移行を容易にすることができます。 たとえば、Oracleテーブルを使用してTalendにインポートし、それをRedshift等の別のサードパーティプラットフォームに伝播させることが可能です。Talend Big Dataは、従来のETLジョブをネイティブのHadoopプロセスに簡単にオフロードできます。 Talend Big DataによりHadoopのガバナンスの課題に対応する Hadoopは、データの拡散を加速するよう設計されています。 また、データ、データ操作、及び関連メタデータの単一の参照ポイントとなる従来のデータベースとは異なり、Hadoopは複数のストレージ及びデータ処理オプションを組み合わせています。 さらに、高可用性戦略の一環として、Hadoopは多くのノードにわたってデータを複製し、処理ステップ間に生データの中間コピーを作成するうえで役立ちます。 …

Read Article