注目の投稿

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

詳細情報
注目の投稿

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

詳細情報
注目の投稿

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

詳細情報
注目の投稿

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

詳細情報
注目の投稿

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

詳細情報

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

Pipeline Designerがリリースされました。この次世代クラウドデータ統合設計環境を使用することで、開発者はデータパイプラインを数分で開発/展開し、バッチとストリーミングのユースケース全体でシームレスに設計し、最新のハイブリッドおよびマルチクラウドテクノロジーでネイティブに拡張できます。 Talend Cloud Pipeline Designer あらゆる業界でデータが企業の競争力になっていることは周知の事実です。そして、競争力を維持するために、組織は3つのことを保証する必要があります。 最高の知見をもたらすデータを残さず収集すること データに依存するビジネス部門がタイムリーにデータを受け取り、迅速な決定を下すこと 新しいデータ要件が発生した場合には、拡張および革新できる簡単な手段があること 多数の新しいデータタイプとテクノロジーが出現したことを考えると、これを達成することは非常に困難です。たとえば、今日の企業が直面している大きな課題の1つは、あらゆる種類のストリーミングデータに対応し、ソーシャルメディア、Web、センサー、クラウドなどからあらゆる場所に浸透する新タイプのデータを処理することです。企業は、リアルタイムでデータを処理・提供することがリアルタイムの知見を可能にする革新を起こすと考えていますが、このデータを簡単に収集・変換することは実際には困難です。 たとえば、クリックストリームデータの場合、データはWebサイトから絶えず送られ、データのストリームは止まることなく常に流れています。確定的なデータの「開始」と「停止」に依存するデータの取り込みや処理の典型的バッチアプローチは、ストリーミングデータによって時代遅れとなり、データに対するリアルタイムの反応性が持っている潜在的価値を奪います。たとえば、オンラインショップは、クリックストリームデータに基づいて、Webサイトに対するユーザーのエンゲージメントを把握します。これは、各ユーザーに合致した商品を提示する方法を理解するために不可欠です。利益幅が非常に小さい業界では、市場シェアを獲得するための迅速な意思決定を行うために、顧客の活動と競合他社の価格データをリアルタイムで把握することが不可欠です。 また、さまざまなアプリケーションからのデータに依存している場合、企業のデータ統合ツールはデータフォーマットの変更にうまく対応できず、ソースデータに新しいフィールドが追加されるたびにデータパイプラインが破損する可能性があります。ITがデータの動的な性質に対応できたとしても、データにアクセスする必要があるビジネス部門は、他のビジネスにもデータを提供しなければならない担当者の作業量増大により、実用的な知見を得るまでに何週間も待たなければならない場合があります。 実際、最近のデータサイエンティストの調査では、データサイエンティストの30%以上が、データが利用できないこととデータへのアクセスが困難であるということが最大の課題であると報告しています。また、実用的なデータへのアクセス拡大に対して、市場の要求が高まっており、データサイエンティストに比べてデータエンジニアの求人が4倍に上っている状況にも反映されています。 データエンジニアリングのスキルセット(あらゆる種類のデータに対するアクセス、収集、変換、およびビジネスへのデリバリー)が必要とされており、今日のデータエンジニアは、絶えず変化するデータ環境で活動しながら、これまで以上に生産性を高める必要があります。同時に、アドホックインテグレーターについても、データにアクセスして統合し、ITに依存せずに活動できるように権限を強化する必要があります。 そして最後に、より多くのビジネスがより転機で成果を出すことを要求しているため、データエンジニアとアドホックインテグレータの両方がデータをすぐに統合する必要があり、データ統合ツールはこれらの新しい需要を満たすのに役立つ必要があります。データエンジニアとアドホックインテグレーターには、利用しやすく直感的なだけでなく、日常的に使用する多種多様で大量のデータを処理できる、クラウドネイティブの統合ツールが必要になっています。 途方もない問題に直面しているように感じられるかもしれませんが、心配は無用です。ここまで説明しておきながら、解決策を提示しないわけがありません。 Pipeline Designerの紹介 このようなシナリオが繰り返される中で、既存/将来のお客様の問題解決を支援するためにTalendが構築したのが、このPipeline Designerです。 Pipeline Designerは、クラウドに組み込まれたセルフサービスのWeb UIです。誰もが使いやすいクラウドアプリケーションを期待し、データの量、種類、テクノロジーが一見不可能なペースで増大している今日、より速く、より簡単に、より利用しやすいデータ統合を可能にします。 データエンジニアは、データのクラウドデータウェアハウスへの変換とデリバリー、ストリーミングデータのクラウドデータレイクへの取り込みと処理、SnowflakeとAmazon Redshiftへのバルクロードなど、軽量の統合のユースケースに迅速かつ簡単に対処できます。Pipeline Designerの最新のアーキテクチャーにより、ユーザーは、バッチデータとストリーミングデータの両方で作業できます。増加するデータ量やデータフォーマットの変更に対応するためにパイプラインを完全に再構築することを心配する必要もなく、今までにない速度でデータの変換とデリバリーを実現できます。 Pipeline Designerはどのような特長を備えているのでしょうか。皆さんと特に共有したい主要ポイントを以下に紹介します。 ライブプレビュー Pipeline Designerのライブプレビュー機能により、継続的なデータ統合設計を行うことができます。データの外観を確認するために、パイプラインを設計、コンパイル、展開、実行する必要がなくなりました。 代わりに、まったく同じ設計キャンバスで、設計プロセスのすべてのステップでデータの変更をリアルタイムで確認できます。パイプライン内の任意のプロセッサーをクリックし、変換前後のデータを確認し、出力データが期待するものに合致していることを確認します。これにより、開発時間が劇的に短縮され、デジタルトランスフォーメーションプロジェクトがスピードアップします。 簡単な例として、以下のようなPythonの変換について、入力と出力を見てみましょう。 スキーマレス設計 スキーマオンリードは、最新のデータ統合のためのデータ統合戦略です。ビッグデータプラットフォーム、メッセージングシステム、NoSQLへのデータのストリーミングなど、多くの場合に構造化されていな受信データを固定のスキーマにマッピングする必要がないため、時間を節約できます。 Pipeline Designerは、スキーマオンリードのサポートを提供し、パイプラインを構築する前にスキーマを定義する必要を排除し、スキーマが変更されたときにパイプラインの復元力を維持します。Pipeline Designerで接続またはデータセットを定義する場合、スキーマの強力な定義は存在しません。データの構造は、パイプラインが実行される時点で推測(データを収集し、その構造を推測)されます。ソーススキーマに変更がある場合、次の実行時に、パイプラインは変更を考慮に入れて適応します。これは、スキーマが動的に検出されるため、データの操作をすぐに開始し、データソースを「オンザフライ」で追加できることを意味します。要するに、「硬直的」なメタデータ定義と比較して、より高い復元力と柔軟性をもたらします。 比類のない移植性であらゆるデータを統合 Talendは、「将来に対応」する開発を長年にわたって主導しています。パイプラインをモデル化し、それを実行するプラットフォーム(オンプレミス、クラウド、またはビッグデータ)を選択できます。また、要件が変更された場合は、別のプラットフォームを選択するだけで済みます。たとえば、コードジェネレーターをMapReduceからSparkに変更した場合は、数回クリックするだけで、最適化されたネイティブのSparkを実行できるようにジョブを変更できます。しかも、今回はさらに強力な機能を利用できるようになりました。オープンソースプロジェクトのApache Beamに基づいて構築することによって、Talendは設計とランタイムを切り離すことに成功しました。つまり、パイプラインを実行する処理エンジンを考慮することなく、パイプラインを構築できます。 さらに、ストリーミングとバッチパイプラインの両方を同じパレットで設計できます。 したがって、SQLクエリなどの境界のあるソース、またはメッセージキューなどの境界のないソースに同じパイプラインを接続でき、データのソースに基づいて、バッチパイプラインまたはストリームパイプラインとして機能します。実行時には、データが置かれたクラウドプラットフォームでネイティブに実行するよう選択でき、さらに究極のスケーラビリティのためにEMRで実行することも選択できます。Pipeline Designerは、真の意味で「一度設計すればどこでも実行可能」であり、複数のクラウドでスケーラブルな方法で実行できます。 組み込みのPythonコンポーネント Pythonは最も急速に成長しているプログラミング言語であり、データエンジニアが一般的に使用するプログラミング言語でもあります。したがってTalendは、Pipeline …

Read Article

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

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

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

Read Article

Talend 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

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