クラウドへの移行 2018年はクラウドの年であり、クラウドテクノロジーに移行する企業が増えるにつれて、ビジネスがクラウドを最大限に活用する方法を理解することが重要となります。企業が今日抱えている大きな問題の1つは、オンプレミスのデータベースからクラウドデータストレージへのデータの移行です。適切なツールがなければ、これは時間のかかる退屈なプロセスになります。幸いなことに、ここでTalendを役立てることができます。 Talendでは、オンプレミスのデータベースであるMySQLをクラウドストレージのAmazon S3に移行する必要がありました。Apache Sqoopの複雑さに対処する代わりに、いつでも新しいデータをクラウドへ移行できるジョブをTalend内に作成することにしました。この方法を使用することで貴重な時間を節約でき、その分を新しく移行したデータの分析に使用できました。このブログでは、このジョブをどのように構築したかを振り返ります。早速始めましょう。 接続の作成 Talendのジョブと同様に、最初に接続を作成します。MySQLデータベースに対しては、tMysqlConnectionコンポーネントを使用します。また、tS3Connectionを使用してS3クラウドストレージへの接続を作成する必要があります。このジョブを実行するたびに、毎回MySQLとS3の両方に接続することになるので、両方のコンポーネントの前にtPrejobを追加する必要もあります。 Talendはコード生成ツールであり、tPrejobを使用することで、常に最初にコンパイルするものを制御でき、常にデータベースに接続できるようになります。両方の接続コンポーネントを構成した後、次のスクリーンショットのようにtPrejob、tMysqlConnection、tS3Connectionを接続できます。 テーブルの取得と動的スキーマの設定 両方のストレージプラットフォームに接続したので、MySQLからAmazon S3へのクラウド移行プロセスを開始できます。まず、データベースから移動する、すべてのテーブルのリストを取得する必要があります。tMysqlTableListを使用して、「WHERE句」を使用してリストするテーブルを指定できます。ただし、今回は顧客テーブルからのみ取得します。 転送対象の全テーブルのリストを取得したので、次にそのテーブル内の列のリストを取得します。 「tMysql」グローバル変数を使用することは、コンポーネントから値を取得するのに最適な方法です。これらのグローバル変数は、他のコンポーネントが使用する「tMysql」コンポーネントからデータを取得できます。この場合、((String)globalMap.get(“tMysqlTableList_1_CURRENT_TABLE”))は、tMysqlTableListコンポーネントによって収集されるテーブルからコンポーネントに列を取得させます。Talendでは、グローバル変数を記憶しなくとも簡単に検索できます。「tMysql」と入力してCtrl + スペースキーを押すだけで、すべての「tMysql」グローバル変数がリストに表示され、必要な変数を選択できます。 次に、tFixedFlowInputを追加して、「tableName」列と「columnName」列を生成する必要があります。最初にこれらの列のスキーマを構成した場合、値はtFixedFlowInputコンポーネント内にのみ表示されます。スキーマを設定したら、これらの列の値を設定できます。「tableName」については((String)globalMap.get(“tMysqlTAbleList_1_CURRENT_TABLE”))、「columnName」については((String)globalMap.get(“tMysqlTAbleList_1_COLUMN_NAME”))になります。 固定フローの後にtLogRowを追加すると、実行コンソールに情報を表示することで、ジョブの取得元であるテーブルと列の名前を確認できます。以下は、これまでのジョブを示すスクリーンショットです。 次に、オンプレミスデータベースからデータを取得するときに、データが使用する動的スキーマを設定します。名前が示すように、動的スキーマは、その時点で読み取られる列に応じて変化するスキーマタイプであり、ジョブに不可欠です。 動的なスキーマを設定するには、tSetDynamicSchemaというコンポーネントを使用します。tSetDynamicSchemaを使用すると、値「columnName」に基づいてスキーマを動的に設定できます。スキーマが動的になったので、各テーブルを個別に移動する必要はなくなり、複数の異なるテーブルを簡単に移動できます。 データの読み取りとテーブルの書き込み 動的スキーマを設定したら、tSetDynamicSchemaコンポーネントから作成された動的タイプを使用して、テーブルデータの読み取りを開始する準備ができました。オンプレミスのデータベースからデータを読み取るため、MySQLデータベースのtMysqlInputから読み取る入力コンポーネントを使用する必要があります。最初に、tMysqlInputコンポーネントのスキーマを編集して、動的DBタイプを使用する必要があります。このスキーマの列に「dynamic_row」という名前を付け、タイプは（もちろん）「Dynamic」、DBタイプは「VARCHAR」を指定します。 スキーマを設定したら、tMysqlInputコンポーネントを構成し、tMysqlTableListによってリストされている現在のテーブルからデータが取得されることを確認します。 テーブル内のデータは現在リストされている現在のテーブルから読み取られますが、依然としてデータをCSVファイルに書き出す必要があります。このために、tFileOutputDelimitedを使用します。「ファイル名」が正しいファイルパスに従っていることを確認する必要があります。 もう少しで終わります。以下は、これまでに作成したジョブを示すスクリーンショットです。 Amazon S3へのファイルの配置 これまでのところ、このジョブはcustomerという名前のすべてのテーブルを読み取り、指定されたフォルダー内のCSVファイルに書き込みます。オンプレミスのデータベースにあるテーブルからデータを取得できるようになったので、これらのファイルをAmazon S3に移動してジョブを完了します。 tFileListを使用すると、指定したフォルダー内に含まれる全ファイルのリストを取得できます。ここでは、オンプレミスデータベースから取得した全テーブルのリストを取得できます。ファイルを配置するディレクトリを指定する必要があるだけです。 すべてのファイルのリストを取得したら、それらをS3バケットに移動し始めることができます。そのために、tS3Putコンポーネントを使用します。「Bucket」、「Key」、および「File」を指定するだけです。「Key」はS3内のファイルの名前であり、「File」はS3にアップロードされるファイルの名前です。 tFileListとtS3Putの構成が完了したので、あとは、クラウド移行ジョブに最後の仕上げをするだけです。ジョブの最初に開いた接続を覚えていますか？ tPostjob、tMysqlClose、tS3Closeを使用すると、ジョブが実行されるたびに開いた接続を閉じることができます。ここでも、メインループがコンパイルされた後に何が起こるかを制御でき、tPostjobコンポーネントの意義が発揮されます。簡単ですね。完成したジョブは、次のようになります。 ジョブの実行 ジョブが実行され、すべてが正常に処理すると、実行コンソールは下のスクリーンショットと一致するはずです。ご覧のとおり、コンソールには、読み取りおよび書き込み中のテーブルと、対応する列名が表示されます。 ジョブが完了したので、テーブルごとに複数のジョブを作成したり、厄介なハンドコーディングに煩わされたりすることなく、オンプレミスデータベースからクラウドストレージに任意のテーブルを移動できます。クラウド対応の準備が整うのは気持ちの良いことです。 デモをライブで視聴 このデモをライブで視聴するには、3月22日（木）にTalendのFacebookページに参加してください。#TalendDevLive ではジョブを構築する手順を紹介し、質問にも答えます。お見逃しなく！
Read Article
データモデルとは何を指すのでしょうか。毎日データモデルに接して熟知している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の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のカスタマーサクセスアーキテクトチームに加わる前の数年間は、サポートエンジニアとして、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
先日Talendに入社したカスタマーサクセスアーキテクトのSundaramです。Talendによるデータ戦略を管理するためのアーキテクチャーのガイドラインとベストプラクティスをお客様に提供しています。Talendに入社する前にデータウェアハウスの実装を何件か担ったことがありましたが、そのような場合にはETLツールとしてInformatica PowerCenterが一般的に採用されていました。あるテクノロジーから別のテクノロジーへの移行は、大きな課題となることがあります。しかし、PowerCenterでのやり方をTalendにそのまま「複製」するのではなく、一歩引いて、Talendの仕組みや機能、PowerCenterとの違いを理解することが重要です。このブログでは、Informaticaから移行して先端的な統合プラットフォームを導入した経験をご紹介し、皆さんがInformaticaからTalendに移行する際の作業を最小限に抑えるうえでの参考にしていただきたいと思います。 Talend vs. Informatica PowerCenter：両者の違いについて どちらのツールも本質的にはデータをソースからターゲットに移行するという同じ機能を果たしますが、その実現方法が異なっています。それぞれの方法にはそれぞれのメリットがあります。ETLジョブを設計する前に、これらの方法の長所と短所を理解することが重要です。 まず、どちらのツールもグラフィカルユーザーインターフェイスを提供し、ソースからデータを抽出してトランスフォーメーションを行い、ターゲットにロードしますが、実装が異なることを理解する必要があります。TalendはネイティブJavaコードを生成するので、どこでも実行できます。一方、PowerCenterは、Informatica独自のエンジンが実行に使用するメタデータを生成してRDBMSリポジトリに格納します。 Talendがコードジェネレーターであることを理解しておくことが重要です。つまり、ETL（独自のスタンドアロンサーバーで実行）エンジンとしても、ELT（ターゲットサーバーでネイティブに実行）エンジンとして実行できます。Talendによって生成されたJavaコードは、Javaをサポートするプラットフォームであれば、どこでも（データセンターのサーバーでも、クラウド上でも、またはラップトップ上でも）実行できます。どちらのプラットフォームもデータ統合に必要なタスクの大半を処理するコンポーネントを提供していますが、カスタマイズが必要な場合もあります。そのためにカスタムコーディングが行われますが、このプロセスがPowerCenterを使用する際のやっかいで非効率的な点です。一方、Talend Open Studioの場合はお客様独自のカスタムコンポーネントをJavaで構築し、面倒なく統合できます。これらが、データ統合ジョブを設計する際に重要となる考慮事項です。 ダウンロード >> Talend Open Studio for Data Integration ジョブの設計方法 ジョブの構築方法が異なる点も重要です。PowerCenterの場合は、まずマッピング（本質的には「データフロー」）を開発します。この段階で、ソースとターゲットの間のマッピングとトランスフォーメーションロジックが定義されます。マッピングが検証され、そのメタデータがリポジトリに保存されると、セッションとワークフロー（「プロセスフロー」）が作成されます。その後、ソースとターゲットのオブジェクトへの物理接続が割り当てられ、タスクが実行順に並べ替えられ、エラー処理/通知手順が実装されます。 Talendでは、データフローとプロセスフローの両方がシームレスに実装されます。「データフロー」を実装する特定機能を提供するさまざまなコンポーネントを使用して、「プロセスフロー」を定義するジョブを構築します。「プロセスフロー」は、特定のスキーマに基づく「行」を使用するコンポーネント間の「トリガー」と「データフロー」を使用して実装されます。 理解しやすいように、PowerCenterとTalendの概念を対応させて説明します。 Informatica PowerCenter Talend Studio 説明 リポジトリ プロジェクトリポジトリ PowerCenterリポジトリとTalendプロジェクトリポジトリには、再利用可能なメタデータオブジェクト（ジョブ、DB接続、スキーマ定義など）が含まれます。Talendの場合は、独自のソースコード管理システムを使用するのではなく、SVNまたはGITのソースコード管理システムにシームレスに統合されます。 フォルダー フォルダー フォルダーは、機能に基づいてオブジェクトを整理するのに役立ちます。PowerCenterの場合はサブフォルダが許可されませんが、Talendでは許可されます。 ワークフロー ジョブ ワークフロー/ジョブは、すべての接続と依存関係が定義されたETLプロセスフローを実装します。Talendの場合、ジョブはプロセスフローとデータフローの両方を表します。 ワークレット/再利用可能セッション ジョブレット ワークフロー/ジョブで再利用可能な一連のタスクの組み合わせです。エラー処理、通知、繰り返し可能プロセスなどの再利用可能コードに使用できます。 セッションとマッピング コンポーネント PowerCenterでは、接続、ファイルの場所、エラー処理がセッションで個別に定義されます。一方Talendでは、マッピングとセッションの機能が結合され、コンポーネントまたはプロセス/データフローによりリンクされたコンポーネントセットに実装されます。 トランスフォーメーション コンポーネント Talendにはコンポーネントの大規模ライブラリーがあり、これがさまざまなトランスフォーメーションをサポートします。たとえば、頻繁に使用されるコンポーネントのtMapは、Informaticaの式、ルックアップ、ルーター、ジョイナーのトランスフォーメーションを組み合わせたものとなります。 ソースとターゲット …
Read Article
ビジネスアプリケーション、データ統合、マスターデータ管理、データウェアハウジング、ビッグデータデータレイク、機械学習といったものは、いずれもデータモデルが共通の基本的要素となります（または、そうあるべきです）。この点を常に念頭に置きましょう。あるいは、（よく見られることですが）完全に無視することがないように注意してください。 データモデルこそが、Eコマースから、PoS、財務、製品、顧客管理、ビジネスインテリジェンス、IoTまで、Talendの高価値でミッションクリティカルのビジネスソリューションのほとんどすべての支柱です。適切なデータモデルがなければ、ビジネスデータはおそらく失われてしまうでしょう！ Talendのジョブ設計パターンとベストプラクティスについて取り上げたブログシリーズ（第1部、第2部、第3部、第4部）では、32のベストプラクティスを紹介し、Talendでジョブを構築する最善の方法について述べました。その中で予告したデータモデリングについて、以下に述べたいと思います。 データモデルとデータモデリングの方法論は、ずっと以前（コンピューティングが始まった頃）からありました。構造は、データが意味を成すために必要であり、コンピューターが実際に処理するうえでの一手段を提供します。確かに、今日では非構造化データや半構造化データも処理されるようになっています。しかし、それは単に、一層洗練された規範へとデータ処理が進化したことを意味するだけではないでしょうか。したがって、データモデルの意義は現在も変わるものではなく、高度なビジネスアプリケーションを構築するための基盤となっています。Talendのベストプラクティスと同様、データモデルとデータモデリングの手法にも真剣に向き合う必要があります。 ダウンロード >> Talend Open Studio for Data Integration 新たな洞察を得るべく、データモデリングの歴史を振り返ってみましょう。 データモデルの進化 「コンピューティングの暗黒時代」には、フラットなレコードのレイアウト（配列）が使用され、すべてのデータは後で取得できるようにテープや大規模ディスクドライブに保存されていました。しかし、1958年に、J. W. YoungとH. K. Kentが、情報システムのモデリングは「データ処理の問題の情報的かつ時間的特徴を規定するための正確で抽象的な方法」であると論じました。その後すぐに（1959年）、CODASYL（Conference/Committee on Data Systems Languages）というコンソーシアムがミネソタ大学のチャールズ・バベッジ研究所により結成されました。これを契機として、COBOLのような標準プログラミング言語が作成され、1960年代にはGE/Honeywell社でIntegrated Data Store（IDS）という初期のデータベーステクノロジーがチャールズ・バックマンによって設計されました。IDSは使いにくいものであったため、Integrated Database Management System（IDMS）がB. F. Goodrich（米国のタイヤメーカーですが、当時は航空宇宙製造企業）により開発され、Cullinane Database Systemsにより販売されました（現在はComputer Associatesが所有）。これら2つのデータモデリングの方法論は、それぞれ「階層型データモデル」と「ネットワーク型データモデル」と呼ばれ、50年にわたってメインフレームコンピューティングで広く使用されてきました。現在でも使用しているケースがあります。 1960年代末、当時IBM社の社員だったエドガー・F・コッドは、クリス・J・デイト（『An Introduction to Database Systems』の著者）と協力し、自身の革新的なデータモデリング理論を確立して、1970年に「A Relational Model of Data for Large Shared Data Banks（大規模共有データバンクのデータ関係モデル）」という論文を発表しました。コッドは、ベンダーが方法論を正しく実装できるよう推進するため、1985に有名な「Twelve …
Read Article
Azure SQL Data Warehouseは、リレーショナルと非リレーショナルの両方の大規模データを処理可能なクラウドベースのスケールアウト型データベースです。 Massively Parallel Processing（MPP）アーキテクチャーに基づくSQL Data Warehouseは、どのようなエンタープライズワークロードでも処理できます。 リアルタイムのビジネス意思決定への注目が高まる中でパラダイムシフトが起こり、データウェアハウスシステムを最新の状態に維持するだけでなく、ロード時間を短縮することが重視されるようになっています。SQL Data Warehouseにデータをロードする最速で最適な方法は、PolyBaseを使用してAzure BLOBストレージからデータをロードすることです。 PolyBaseは、SQL Data WarehouseのMassively Parallel Processing（MPP）設計を使用して、Azure BLOBストレージから並列にデータをロードします。 Talendの主な差別化要因として、オープンソースであること、そして社内開発のコンポーネントを使用したり、オープンソースコミュニティにより開発されたコンポーネントをTalend Exchangeを介して活用したりできることが挙げられます Tここでは、このようなカスタムコンポーネントの1つであるtAzureSqlDWBulkExecに焦点を当て、Talendがこれを利用してPolyBaseでSQL Data Warehouseにデータをロードする方法を説明します。 Download >> Talend Open Studio for Data Integration わかりやすくするために、次の2つのシナリオで検討します。 任意のソースからSQL DWにデータをロードする Azure HDInsightとSparkを活用しながらSQL DWにデータをロードする 任意のソースからSQL DWにデータをロードする このシナリオでは、Talendジョブの一部として1つ以上のソースからデータを取り込むことができます。Talendがすぐに利用できるように提供している多様な処理及びデータ品質のコネクターを使用して、必要に応じてデータの変換、クレンジング、エンリッチメントが行われます。 出力は、tFileOutputDelimitedを使用して区切り文字付きファイル形式に準拠させる必要があります。 次に、出力ファイルは、tAzureStoragePutを使用してAzure BLOBストレージにロードされます。 ファイルがBLOBにロードされると、tAzureSqlDWBulkExecを利用して、区切り文字付きファイルからSQL Data Warehouseテーブルにデータがバルクロードされます。 Azure …
Read Article
ビッグデータの分野では、従来のデータウェアハウスを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のジョブ設計パターンとベストプラクティス第1部と第2部）をお読みください。それぞれ異なるテーマを取り上げています。 ジョブ設計パターンとベストプラクティスの解説を始める前に、お知らせがあります。これまでのコンテンツを90分のテクニカルプレゼンテーションにまとめました。このプレゼンテーションは、「Talend Technical Boot Camps」にて、世界中で視聴いただけます。地域のイベントスケジュールは、TalendのWebサイトでご確認ください。プレゼンテーションでお会いできることを楽しみにしています。 このシリーズの内容について、コメント、質問、論点をお寄せください。ディスカッションを膨らませ、Talendコミュニティで展開できれば、と思います。「標準」ではなく「ガイドライン」であることを思い出してください。どうか、ご意見をお寄せいただき、ご協力をお願いいたします。 テーマを深める Talendプロジェクトをはじめとするソフトウェアライフサイクルを成功へと導くには、「開発者のガイドライン」の確立が不可欠であることを理解いただけたと思います。では、次に進みましょう。開発者のガイドラインの確立、チームによる採用、規律の段階的な浸透は、Talendで極めて大きな成功を収めるための鍵である、という点を解説します。これに、異論を唱える人はいないでしょう。Talendジョブの作成には、複雑な手順が必要です（ここでは詳しい説明はしません）。したがって、「ビジネスユースケース」、「テクノロジー」、「手法」を理解することによって、成功の確率が高くなります。時間をかけて、チームのガイドラインを作成することには十分な価値がありますし、成果があるはずです。 Talendユーザーが取り組んでいるユースケースの多くは、何らかの形でデータ統合プロセスに関連しています。データ統合はTalendのコアコンピテンシーであり、データの移動を意味します。データフローはさまざまな形態で発生するため、処理や操作の方法が重要になります。その重要性は非常に大きく、作成するあらゆるジョブの本質であるとも言えます。ビジネスデータの移動というユースケースにおいてTalendをテクノロジースタックの不可欠な要素として使用する場合、どのような手法を使用すればよいでしょうか。それはもちろん、これまでに解説したSDLCベストプラクティスなのですが、それだけではありません。データに関連する手法ですから、データモデリングも含まれます。これは、私の専門分野でもあります。私は、25年以上にわたるデータベースアーキテクトという経験の中で、数え切れないほどのデータベースソリューションの設計と構築に携わってきました。ですから、データベースシステムにもライフサイクルがあることを実感しています。フラットファイル、EDI、OLTP、OLAP、STAR、Snowflake、データボルトといったスキーマを問わず、データとそのスキーマが生成され、廃棄に至るまでのプロセスを無視することは、チームにとって弱点になり、最悪の場合は大惨事につながるのです。 このブログではデータモデリング手法は扱いませんが、適切なデータ構造設計を採用し、それに沿って使用することが非常に重要です。ぜひデータボルトのシリーズの記事をお読みいただき、今後掲載予定のデータモデリングの記事もご覧ください。現時点では、DDLC（Data Development Life Cycle）はベストプラクティスです。このことについて考えていただければ、私の意図を後で理解できるでしょう。 さらなるジョブ設計のベストプラクティス では、Talendのジョブ設計について、「ベストプラクティス」をさらにいくつかご紹介します。ここまでで、16のベストプラクティスを解説しました。あと8つあるのでお楽しみに（このシリーズには第4部があります。すべてを盛り込むことはできないので、記事を読みやすく分割しています）。 さらに検討すべき8つのベストプラクティス コードルーチン 状況によって、Talendコンポーネントではプログラミングのニーズを満たせない場合があります。それでも問題はありません。TalendはJavaコードジェネレーターです。キャンバスに配置し、プロセスやデータフローで使用できるPure Javaコンポーネントもあります。それでもニーズに対応できない場合があるはずです。そのようなときには、コードルーチンが役立ちます。これは、プロジェクトリポジトリに追加可能なJavaメソッドです。基本的に、ユーザー定義のJava関数であり、ジョブ内のさまざまな場所で使用できます。 Talendは数多くのJava関数を備えています。すでに使用されていると思います。 getCurrentDate – sequence(String seqName, int startValue, int step) – ISNULL(object variable) ジョブ、プロジェクト、ユースケースの全体像を考えた場合、コードルーチンにはさまざまな用途があります。ここで基本となるのは、再利用可能なコードです。それには、汎用な方法でジョブを合理化できるコードルーチンを作成することを、常に念頭に置く必要があります。適切なコメントを指定すれば、関数を選択する際に役立つテキストとして表示されます。 リポジトリスキーマ プロジェクトリポジトリのMetadataセクションでは、再利用可能なオブジェクトを作成することが可能です。これは、重要な開発ガイドラインですね。リポジトリスキーマは、ジョブで再利用可能なオブジェクトを作成する強力な手法です。以下が含まれます。 – ファイルスキーマ – さまざまなフラットファイル形式のマッピングに使用します。 Delimited Positional RegEx XML Excel JSON – 汎用スキーマ …
Read Article
If you’ve ever started working with new software, you know it can be challenging to start taking full advantage of features and functionality right away. At Talend, we want you to get up and running quickly with our data integration software. Therefore, we’ve introduced a new …
Read Article