注目の投稿

データの健全性、予後から治療まで

詳細情報
注目の投稿

正しいデータについての問題をついに解決できます。

詳細情報
注目の投稿

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

詳細情報
注目の投稿

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

詳細情報
注目の投稿

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

詳細情報

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]タブでは、設定可能なさまざまなオプションが論理的に次のカテゴリに分類されています。 クラスターのバージョン 構成 認証 調整 …

続きを読む

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 …

続きを読む

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 …

続きを読む

Informatica PowerCenter開発者の視点で考えるTalendの機能

| 2017年6月16日 | Database Integration Developer Step-by-Step ETL / ELT

先日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の式、ルックアップ、ルーター、ジョイナーのトランスフォーメーションを組み合わせたものとなります。 ソースとターゲット …

続きを読む

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

| 2017年5月5日 | Database Integration Developer Step-by-Step ETL / ELT

ビジネスアプリケーション、データ統合、マスターデータ管理、データウェアハウジング、ビッグデータデータレイク、機械学習といったものは、いずれもデータモデルが共通の基本的要素となります(または、そうあるべきです)。この点を常に念頭に置きましょう。あるいは、(よく見られることですが)完全に無視することがないように注意してください。 データモデルこそが、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 …

続きを読む

PolyBaseとTalend ETLを使用してMicrosoft Azure SQL Data Warehouseにデータをロードする方法

| 2017年2月8日 | Cloud Integration Developer Step-by-Step Integrations / Connectors

  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 …

続きを読む

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 …

続きを読む

Talendのジョブ設計パターンとベストプラクティス(第4部)

  Talendのジョブ設計とベストプラクティスという取り組みは、新たな岐路にさしかかっています。役立つコンテンツの提供という私の努力は、1つの形になりました。好評をいただいているブログシリーズ(まだお読みになっていない方は、第1部、第2部、第3部をぜひご覧ください)、Technical Boot Campプレゼンテーション(参加いただいた方、ありがとうございます)、コンテンツの直接配信から、社内から組織の変革を求める声が生まれています。 この記事では引き続き、ジョブ設計パターンとベストプラクティスについて解説を進めます。まず、シンプルでありながら見逃されがちな事実をお伝えしましょう。それは、Talendは、Javaコードジェネレーターであり、開発者ガイドラインを確立することで、ジョブ設計パターンによって生成されるJavaコードを強化および合理化できる、という点です。これは明白な事実ですが、この概念に基づいてキャンバスを操作し、緻密なジョブ設計を行ってクリーンなJavaコードを生成することが、最善の結果への近道です。私はこれを、「成功主導のプロジェクト」と呼んでいます。 成功主導のTalendプロジェクト Talendジョブの作成は、非常に簡単な場合と、非常に複雑な場合があります。実装を成功へと導く秘訣は、良い習慣と必要な規範を採用し、適合させることにあります。 このシリーズの冒頭で「基本的指針」でお伝えしたように、私の目標は、ベストプラクティスに関する自由なディスカッションを行い、便利なジョブ設計パターンを確立することにあります。ジョブ設計および親子オーケストレーションは、ほとんどのユースケースにメリットをもたらします。そして、再利用可能なコードを含めることで、プロジェクト全体の成功が加速されます。もちろん、どの方法を選択するかは皆さんの自由ですが、一貫性の維持だけは必ず留意してください。 データベース開発ライフサイクル(DDLC) このシリーズではジョブ設計のみを扱ってきましたが、データについてはどうでしょうか。ジョブで処理するのはデータであり、ほとんどのデータはデータベースに格納されています。データベースにベストプラクティスは必要でしょうか。これは、修辞的な質問でしょうか。データモデル(スキーマ)は時間と共に変化しますから、データベース設計にもライフサイクルがあるのは当然です。 データベースは進化するので、開発者はこれに対応しなければなりません。われわれはSDLCプロセスを採用していますから、データベース開発ライフサイクルの必要性も簡単に理解できるはずです。環境(DEV/TEST/PROD)がどうであれ、データベースのサポートは必要です。 新規インストール – スキーマの現在のバージョンに基づきます アップグレード – アップグレードによりデータベースオブジェクトを削除/作成/変更します データ移行 – 破壊的な「アップグレード」(テーブルの分割など)を行います データベースライフサイクルと、それがジョブ設計にもたらす影響を理解することは、非常に重要です。ここで鍵となるのが、データベースモデルのバージョン管理です。規定された設計プロセスに従い、設計をグラフィック化し、「データ辞書」または「グロッサリー」を作成して変更履歴を追跡します。このトピックについては、ブログの別の記事でさらに詳しく解説する予定ですので、お楽しみに。それまでは、データベースモデルを作成する際には次のプロセスを検討してください。高度な規範ではありますが、効果的です。   さらなるジョブ設計のベストプラクティス では、すぐに役立つジョブ設計のパターンとベストプラクティスをさらにご紹介しましょう。よく使用するTalend機能やあまり使用頻度の高くない機能を詳しく解説します。ぜひ参考にしてください。 さらに検討すべき8つのベストプラクティス: tMapルックアップ ご存知のように、tMapの必須コンポーネントは強力な変換機能を備えているため、Tatlendジョブで広く使用されています。 tMapコンポーネントの最も一般的な用途は、ソース入力からターゲット出力へのデータフロースキーマのマッピングです。これは、シンプルな処理です。ソースとターゲットに複数のスキーマデータフローを使用することもできるため、データフローの複雑な結合や分割にも対応できます。また、変換式を使用すれば、どの入力データをどのような方法でダウンストリームに分割するかを制御できます。tMapコンポーネント内の式は、ソースとターゲットのスキーマに適用できます。また、tMapコンポーネントで定義した変数を使用することも可能です。以上の操作方法は、「Talend Components Reference Guide」で詳しく解説されています。使用する際には、「大いなる力には大きな責任が伴う」ことを念頭に置いてください。 tMapコンポーネントには、ソースデータフローと結合するルックアップを使用するという素晴らしい用途もあります。tMapコンポーネントに適用できるルックアップに物理的な上限はありませんが、実際には配慮すべき項目があります。 この基本的な例をご覧ください。ソースとルックアップという2つの行が生成されます。実行時には、まずルックアップデータが生成され、次にソースデータが処理されます。 ルックアップデータの結合が[Load Once]に設定されているため、レコードすべてがメモリにロードされ、ソースデータの結果セットに対して処理が行われます。これはデフォルト設定であり、結合で優れたパフォーマンスを発揮でき、非常に効率的です。 また、数百万のルックアップ行と数十のカラムをロードする場合には、かなりのメモリ容量が必要になります。数百万行のルックアップを複数回実行する場合はどうでしょうか。メモリ容量はどの程度必要でしょうか。レコード数が多い場合やカラム数が数百にのぼる場合には、ルックアップを慎重に検討してください。 では、メモリとパフォーマンスのトレードオフについて考えてみましょう。ルックアップには、3つのモデルがあります。 Load Once(一括ロード)– 該当するすべてのレコードをメモリに読み込みます Reload at each Row(行ごとに再ロード)– ソースレコードごとに該当する行を読み込みます Reload at …

続きを読む

センサー、環境、モノのインターネット(IoT)

Jacob Morgan氏は、「インターネットに接続可能なすべてのものは、今後接続されるようになる」と述べています。「クラウド」と「ビッグデータ」は一時期、単なる流行語だと見なされていました。しかし今では、この2つの主要なテクノロジーが、世界中のあらゆる業界のビジネスに劇的な影響を与えていることを目の当たりにしています。そして多くの人が今、「同じことがIoTにも当てはまるのか」と考えています。個人的には、世界を一変させる影響力を持つトレンドやテクノロジーを一時的な盛り上がりだと捉えるべきではないと考えています。 2006年、私はRFIDの使用に関する研究調査を行っており、自動データ整理機能とリマインダーテクノロジーを使用して、雑然としたオフィス文書を整理する方法を紹介しました。このトピックに関しては、「Document Tracking and Collaboration Support using RFID(RFIDを使用した文書追跡とコラボレーションサポート)」と題した論文を発行しました。私が初めてセンサーとのやり取りを経験したこの研究で、私と共同研究者はM2M(マシンツーマシン)に、その後はコラボレーション環境との統合に焦点を合わせました。そして、SoT(Subnet of Things)の研究へとつながっていきました。スマートホーム、スマートカー、スマートシティなど当時誕生したアイデアが、現在では実現しつつあります。IDCの推測では、2020年までに280億台のセンサーが使用され、その経済的価値は1.7兆ドルになるとされています。応用シナリオをご紹介する前に、センサー通信のスコープとその3つのカテゴリについて概説します。 M2M マシンツーマシンは、スコープとドメインの点でIoTとは異なります。通常、この2つは可用性が制限されており、データに基づいて運用上の規定が事前に定義されています。わかりやすい例として、製造ユニットと内蔵されているさまざまなセンサーとの通信を挙げることができます。身近な例では、自動車に搭載されたその車専用の暖房センサーがあります。 SoT SoT(Subnets of Things)は、組織レベルまたはエンタープライズレベルにスコープを設定できます。ファイルごとや書籍ごとにRFIDが存在する上記の例のように、SoTもコラボレーションプラットフォームを使用して組織内に配置が可能です。たとえば、自動車はデータを送信してコンポーネントの品質と稼働状況を測定し、より良い操作と安定した運転を提供します。 IoT 2013年、IoT-GSI(Global Standards Initiative on Internet of Things)は、IoTを「情報社会のインフラストラクチャ」と定義しました。IoT(モノのインターネット)とは、一意の識別子が付与され、人対人または人対コンピューターの対話を必要とせずにネットワーク上でデータを転送できるコンピューティングデバイス、機械、デジタルマシン、オブジェクト、動物、または人が相互に関連するシステムです。IoTは、無線技術、MEMS(Micro-Electromechanical System:微小電気機械システム)、マイクロサービス、そしてインターネットの融合によって進化してきました。 センサーのデータ型とネットワークの課題 サンフランシスコに出張した際、SAPのIoT研究開発リーダーにお会いし、私たちの日常生活がビッグデータによってどのように変化しているのかという非常に興味深いお話を伺いました。たとえば、航空機システムでは数千台のセンサーがデータを送信しており、小数点以下8桁から16桁までの計算を数分の1秒でする必要があるとのことです。センサーのおかげで膨大なデータが利用可能となった今、リアルタイムのビッグデータインサイトを活用する能力のある企業の成長を阻害する要因は、現行のテクノロジーインフラストラクチャだけです。 IT部門の意思決定者は、インフラストラクチャを構築し、ネットワークを利用できなかったために保持されていたデータの処理が可能なソリューションを活用する必要があります。通信ネットワークが整っていないことや、信号妨害などが原因で接続できないこともあるため、ITリーダーはネットワークが利用可能になりデータを転送できるようになるまでの間、データを保持し続けられるインフラストラクチャを構築しなければなりません。 センサーデータには、さまざまなソースからのデータと同様に、クレンジング、分析、およびガバナンスが必要です。それに加えて、特徴的な性質ももっています。通常、センサーデータは時間と対置される情報(値)のストリームです。すべてのデータに意味があるわけではありませんが、収集時にその価値が不明であったとしても、すべてのデータには必ず価値が生まれるため、データを破棄することはできません。したがって、データ圧縮の際に厳密ではないアルゴリズムや疑わしいアルゴリズムを使用しないでください。次のような方法を用いることで、このような状況を克服できる可能性があります。 必要な場合に限り、フィルタリングされたデータを送信する 異常値のみを送信する 根拠のない/テストされていないアルゴリズムを使用せずにデータを圧縮する IoT研究者は、さらに次のように述べています。「この瞬間もここでは大量のデータが生成されています。何らかのイベントが起きた場合や、コンポーネントに障害が発生した場合も、それ以前に生成されたデータは非常に重要です。なぜなら、これは完全なエコシステムだからです。データを失えば、今後同様のイベントを予測することはできなくなります。したがって、コストを抑えるには、可逆圧縮を使用してデータを圧縮するという選択肢しかありません(唯一の選択肢は、コストが高すぎます)。データが重複していたり、データ頻度が高すぎたりする場合、多くのオーバーヘッドが発生しますが、やはりバックエンドシステムが受信したすべての情報を処理できてしかるべきです。センサーレベルで高速フーリエ変換などの曲線適合法を適用すれば、集計値を得ることができます。センサーデータは、データレイクと呼ばれる低コストのスケールアウトシステムに保管するのが最も適しています。生データは、その価値が証明されていないため、通常はデータウェアハウスに保存されませんが、セキュリティなどの明確なガバナンスが必要です」 センサーが日常生活に与える影響 センサーは私たちの生活のほぼあらゆる面に影響を与えています。人感センサーから製造ユニットまで、あらゆるものが日々スマートになっています。近い将来私たちに影響を与えるIoTの基本的な例をいくつか見ていきましょう。 スマートマニュファクチャリング 製造業は年間12兆ドル規模の世界的産業です。ロボットがある場所から別の場所に商品を移動し、自動車部品工場や組立ラインで稼働している金属プレス機の全動作はセンサーによって追跡されます。工業生産業とも呼ばれるこのセクターは、すでに著しい成長率を示しています。さまざまなプロセスから収集されたデータは、予定外のダウンタイムを防止するためにも、売上予測に基づいて供給ニーズを予測するためにも役立ちます。 スマートトランスポート 自動車業界の統合は、家電にとって新たなフロンティアだともてはやされています。Gartner社の予測によれば、無人自動車は2030年までに熟年市場の乗用車の約25%を占めるようになります。無人自動車は、レガシーデザインを継承したハンドルを「マシンオーバーライド」の目的のためだけに装備していますが、最終的に手動での制御はなくなるでしょう。ブレーキ、速度計などのインジケーター、加速などの従来の制御はすべて、センサー、レーダー、GPSマッピング、およびさまざまなAI(人工知能)に基づいて行われるようになり、自動運転、駐車、事故を回避する最も安全なルート選びが実現します。この素晴らしいテクノロジーは、車の制御だけでなく、道路状況や車両との関係に基づいた路上で他の車との通信にも重点を置いています。外部ネットワークを必要とする通信は、ルート計算、車両の状態、eコール、および保険やデータのバックアップに基づくbコールの使用など、インターネットベースサービスを可能にします。 スマートエネルギー 送電網が稼働を開始したのは1890年代ですが、当時は非常に集約型で隔離されていました。その後、送電網は拡張され、発電所は技術的な停止(バックアップとリカバリー)に備えて負荷シフトテクノロジーとつながりました。風車や太陽エネルギーのような小型発電ユニットの多くは現在、状況に応じてさまざまな容量の発電を行っています。今日では家庭でも発電が行われていることもあり、送電網が対応する電源は以前よりも増えています。そのため、送電網にプレッシャーがかかっているだけでなく、集約型のシステムの管理が困難になっています。 主要な電力会社は、システムの状態に基づいて、現時点で最も安価な電力源を決定し、不要な発電とコストを回避するために石炭または燃料ベースの電力源を停止できます。同様に、スマートメーターが導入されている現在、使用量に基づいて顧客に課金していますが、将来的に接続先が増えれば、これらのセンサーは最も安価な電力源を判断できるようになる可能性があります。 スマートホームとスマートシティ スマートシティは、非常に興味深いIoTの応用例です。スマートホームとスマートシティは相互に接続しています。スマートシティはコミュニケーションのための優れたインフラストラクチャを提供し、メリットをもたらすことが期待されています。すでにプロジェクトが進行しているシカゴ、リオデジャネイロ、ストックホルムでは、政府が民間企業と共同でIoTを活用して、路上に設置した資産(街灯など)からデータを収集し、修理の必要性を判断しています。スクールバスの監視からゴミの収集まで、IoTは社会の機能のしかたを変えています。 「スマートホーム」とは、相互通信が可能で、家のどの部屋からでも、また電話やインターネットを使って世界中のどこからでもタイムスケジュールに基づいて制御可能な、家電、照明、暖房、エアコン、テレビ、コンピューター、エンターテインメントオーディオ/ビデオシステム、セキュリティ、およびカメラシステムを備えた住居を示す用語です。次世代のスマートホームは、冷蔵庫の在庫管理を行うようになり、在庫が少なくなったと判断すると牛乳や卵を自動発注できます。あるいは、電気、水道、さらにはネットワーク接続の中断を認識して、サービス提供者に修理を要請するようになります。また、スマートゴミ箱はいっぱいになると、ゴミ収集車に自動的に通知するようになります。 一言でまとめるならば、データ駆動型の現在の社会は「スマートシステム」にシフトしつつあります。現在のインフラストラクチャは、データの生成、取り込みから分析にいたるまで、困難な課題を克服する力を与えてくれました。上記のスマートシナリオに加えて、GPSチップなどの個人用身体センサー、健康/活動モニターによって生活水準は向上しています。今後数か月から数年の間に、IoTは急成長することが予測されます。 …

続きを読む

過去10年の成長を振り返って

  創業10周年とIPOの成功を祝う機会に恵まれた今、Talendの豊かな歴史を振り返り、クラウド及びビッグデータソフトウェアの世界的リーダーとしての地位確立に尽力した人々に敬意を表したいと思います。 語りつくされた感があることですが、Talendの成功は、本質的には当社に加わって現在でも「ファミリー」の一員として活躍している多くの人々の貢献によるものです。 Talendは、経営陣の選択にとどまらず、投資家、経営陣、そして当然のことながら顧客、パートナー、従業員から絶大な支持を得ています。 初期:独自のアプローチ Talendがフランスで創業した当時、データ統合のグローバル市場は大きな岐路に立っていました。 データをめぐっては、複雑さ、量、統合が必要な種類、さらには企業の多様なニーズ(特に分析に関して)に劇的な変化が起こっていました。 Talendのプラットフォームを開発し始めた当初の私たちには、情報管理が企業情報システムの要となることに疑問の余地はないという直感がありました。 SAP、IBM、Oracle等の従来のモノリシックなITソリューションに対応する中で、ビジネスユーザーの統合のニーズはますます厳しくなり、具体化していくであろうと理解したのです。 かし、これらのベンダーが提案するソリューションは手頃な価格のものになっていくどころか、ますますコストがかかり、配備が難しくなっていきました。 独占的で排他的なアプローチを開発している既存大手ベンダーとの競合に直面したTalendは、確立された秩序、主流の技術、ビジネスモデル、市場ポジションを切り崩すことにに投資しました。 当時の習わしとは対照的に、Talendはオープンソース、そして集中型ではなく分散型のアーキテクチャーを採用する道を選択しました。また、データ量やCPU使用率ではなく、ユーザー数に基づいて価格体系を採用しました。このように、Talendは当初からローカルではなくグローバルのアプローチをとってきたのです。今考えると、これらの選択の妥当性は明らかです。しかし、Red HatとSalesforce.comが市場のイノベーターとして登場してきた2005年当時、状況は違っていました。 T Talendはビジョンの正当性を確信していましたが、このアプローチの評価と支援で大きな役割を果たしたのが、最初の投資家であるGalileo Partners社のRégis Saleur氏とAGF Private Equity社(現在のIdInvest社)のJean-François Galloüin氏でした。市場の慣習(私の知る限り、現在のように財務的支援を受けるオープンソースベンダーは当時は存在しませんでした)に逆らう形で取引成立に尽力した両氏の当時の支援は、Talendの長期的成功に欠かせないものとなりました。 初期の投資家からの支援とともに、顧客もTalend創業当初に決定的な役割を果たしました。 Citibankのリテールバンキング業務を担うCiti社をはじめとする重要顧客は、 Hadoopによってかつてない量のデータを処理できるようになった分析分野に大きなチャンスを見出しました。 Citi社との経験は貴重なものであり、HadoopのリーダーとしてのTalendの評価を確立するきっかけとなりました。 成熟、そしてさらなる(持続的な)選択肢の拡大 2006年10月に最初のソリューションを投入した後、ダウンロードの大部分が米国からのものであることを認識したTalendは、この地域で成長に勢いをつける絶好の機会であると考えました。 従来のテクノロジー企業が販売の見込み客を増やすために販促に予算を投じる必要があるのに対して、Talend等のオープンソース企業は無料オープンソース版や試用版を提供することで見込み客を獲得します。 もちろん、ダウンロードの見込み客を得るという商業的な機会にとどまらず、支援のエコシステムを形成するうえでも、シリコンバレーに拠点をかまえることが必要でした。 このため、2008年までにシリコンバレーに最初のオフィスを開設したことには、単なる資金調達手段としてではなく、企業戦略の核心をさらに推進させる意図がありました。 会社の成長に伴い、協働する能力を持つ最高の人材を採用することに努めました。 私たちの大きな要求に呼応するように、従業員も尊敬、野心、個人の卓越性に基づく力強い企業文化、人格、環境を持つこの企業に加わりました。 そして現在も、Talendが最初に採用した開発者15名は社内で活躍しています。 将来採用する従業員についても、これまでと同様にスキルだけではなくマインドセットも重視していきます。このやり方が成果を上げていることは実装済みです。 人的要素を重視する姿勢は、前述したように投資家の選択にも、そして取締役会のメンバーの選択にも反映されています。 これらの役割に対しても、Talendは最高の人材を求めました。 Business Objects社を創業したBernard Liautaud氏は、フランスで設立した会社を米国で大きく発展させるという経緯を持ち、このモデルに明確かつ独自に適合しています。 さらに、Ascential Software社の創業者であり、この市場で大きな影響力を持つPeter Gyenes氏をはじめとして、強力な人々の支援を受けました。 このような人材の多様性は、経営、課題、野望の複雑さを生む一方で、Talendの躍進(平均して毎年約2倍の勢いで成長)も可能にしました。 さらにTalendは、ビッグデータがもたらした技術革新の重要性を直ちに「感知」しました。数年前にTalendが策定した計画は、ビッグデータの市場機会が遅かれ早かれ現実のものとなるという予測を考慮するものでした。 ApacheのようなパートナーとTalendにとって、ビッグデータの台頭は特に重要な動きであり、. 今後の展望 後悔はないかとよく尋ねられますが、 最初に思い浮かぶ返答は「No」です。どのような革新的な企業でも同じでしょうが、間違いがなかったわけでは当然ありません。 そのような失敗がなければ一層順調に成長できたであろうことは確かですが、 代わりにTalendは間違いを謙虚に認めて直ちに軌道修正することを選択しました。 …

続きを読む