注目の投稿

データは健全ですか?

詳細情報
注目の投稿

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

詳細情報
注目の投稿

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

詳細情報
注目の投稿

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

詳細情報
注目の投稿

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

詳細情報

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を呼び出します。パーティションの最大サイズは、最終的にはエグゼキューターの利用可能なメモリーによって決まります。 適切な再パーティション化キーを使用してデータを均等に分散することが不可能な場合もあります。そこで、新しい「偽の」キーを追加し、現在のキーと一緒に使用することでデータを均等に分散させるソルトなどの方法を使用します。次に例を示します。 …

続きを読む

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は急成長することが予測されます。 …

続きを読む