月別: February 2017

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

  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 HDInsightとSparkを活用しながらSQL DWにデータをロードする   データ量が増加すると、データをより高速で処理する必要が生じます。  Apache Sparkは、Hadoopと互換性のある高速で汎用の処理エンジンであり、信頼できるビッグデータ処理フレームワークとして一部のデータ駆動型企業で使用されています。 Azure HDInsightは、Spark用の最適化されたオープンソース分析クラスターを提供する、完全に管理されたクラウドのHadoop製品です。Talend Studioを使用してHDInsightクラスターに接続する方法については、How […]


エッジ分析 – ローカルで即座にインサイトを得ることのメリットとデメリットについて

IoTでのデータの保存と処理を取り上げた前回のブログに関連して、多くのデータサイエンティストから質問が寄せられました。その多くは、データの扱いについて困っているという内容のものでした。企業内のデータを保存すべきか破棄すべきか、また、保存する場合に戦略的資産とするための最善策は何かということが、共通の課題となっているのです。 センサーが普及しているとは言え、インダストリアルIoT(IIoT:産業分野に適用されるIoT)は、その大部分が収集後に分析されません。これは嘆かわしい状況です。 既存のIoTプラットフォームソリューションの多くには、速度が遅く、コストがかかり、リソースを浪費するという問題があるため、データ分析が非常に困難になっています。 Gartner社は、データの90%が活用されていないと報告し、Experian社は、米国企業が保有するデータの約32%が不正確であると報告しています。 どの企業にとってもデータは最も価値ある資産であるということを忘れてはなりません。したがって、データを完全に破棄したり、使わないデータレイク内に放置したりするのは残念なことです。 全てのデータサイエンティストは、増大し続けるIoTデータを活用してさまざまなエンドポイントから意味を引き出し、ビジネス拡大のための結論を導くための支援をすべきです。したがって、データを処理せずに破棄することに、私は反対です。 前回のIoTの記事でも述べましたが、数年後にはデータを生成するエッジデバイスの数が現在より150~400億台も増えます。[1]. このことが新たな課題を引き起こします。データをデータレイクに転送し、処理のためにハブに転送するには、どのようなインフラストラクチャが必要でしょうか。処理負荷は今後急激に増加し続け、現在のインフラストラクチャがいつまで活用可能かという別の問題も生じます。 データから利益を得るには、それが「モノ」であれ監視カメラであれ、トラフィックを分析することが不可欠です。 タイムリーなデータ利用が不可欠な状況においては、この分析を遅らせると、「手遅れ」の状況にも陥りかねません。遅延は、ネットワークの可用性が制限される、中央システムの負荷が大きすぎる等、さまざまな理由で発生します。 これらの問題に対処するために、「エッジ分析」という比較的新しいアプローチが使用されています。 基本的に、これはデータが生成されている場所で分析を実行することを指します。 つまり、ローカルでリアルタイムの分析を実行するのです。「モノ」のアーキテクチャーを設計するうえでは、データ分析機能を組み込むことを考慮する必要があります。たとえば、列車や停止信号に取り付けられ、交通のインテリジェントな監視や管理を提供するセンサーには、近くの消防署や警察に警報を出すことが可能な強力なデータ分析機能が求められます。 また、防犯カメラも、ライブ映像を送信する以外に何の処理も実行しないのであれば、ほとんど役に立ちません。 変化を検知するアルゴリズムがあり、新しいイメージを前のイメージから生成できれば、変化分のみを送信することができます。したがって、これらのイベントについては、データをネットワークで送信してから分析するよりも、ローカルで処理する方が理にかなっています。 エッジ分析が有意義となる場所を把握すること、また「デバイス」がローカルでの処理に対応していない場合は最寄りの地点でセンサーやデバイスから生成されるデータから意味を導き出すようにネットワーク接続を構築することが非常に重要です。 Cisco社、Intel社等はエッジコンピューティングを支持し、エッジコンピューティングデバイスとして自社のゲートウェイの提供を推進しています。IBM社とCisco社の共同プロジェクトであるIBM WatsonのIoTは、どこでも実行可能な強力な分析機能を提供することで、データ分析アーキテクチャーの設計を大きく変えています。サーバー/ハードウェアの大手ベンダーであるDell社は、分析エッジをサポートする特殊デバイス(Dell Edge Gateway)を開発しました。 Dell社が構築したデータ分析用システムは、1つの場所またはクラウドで分析モデルを作成してエコシステムの他の部分に展開できるように、ハードウェアとソフトウェアを完備しています。 しかし、エッジ分析では妥協しなければならない点もいくつかあることを考慮する必要があります。 処理及び分析の対象となるのはデータのサブセットのみであり、 分析結果はネットワークを介して送信されます。これは、生データの一部を事実上破棄し、一部の知見を失う可能性があることを意味します。したがって、この「損失」を容認できるかどうかという問題が生じます。全てのデータが必要なのでしょうか。または、その分析によって生成された結果だけで十分なのでしょうか。 この損失によってどのような影響があるのでしょうか。これに対して一般化できる答えはありません。これに対して一般化できる答えはありません。そのようなケースでも、運航中のデータ転送は都合の良いことではありません。このため、運航中にデータのオフライン収集とエッジ分析を行うアプローチを取ることが、より望ましいと言えます。 フォールトトレランスが組み込まれているケースでは、全てのデータを分析しないことも許容可能です。その場合、組織がIoT分析のこの新しい領域で結果を検討していく中で、経験から学ぶ必要があります。 最後に、改めてデータの価値を強調します。 パターンを検出したり市場分析を行ったりするには、全てのデータを分析する必要があります。データ駆動型の企業は、そうでない企業に比べて、はるかに前進しています。 IoTのエッジ分析は刺激的な領域であり、多くの大企業が投資している中で、データの保守と有用性の課題に対する解決策を提供しています。 IoTに関するIDC FutureScapeの報告では、2018年までに、IoTデータの40%がネットワークに転送される前に、作成された場所で保存、処理、分析、処理されるようになると報告しています。[2]. データ転送にはコストがかかり、タイムリーな意思決定の品質に影響を与えずにコストを削減する必要があります。エッジ分析は、この課題に対する確かな答えとなります。 Sources: [1] “The Data of Things: How Edge Analytics and IoT go Hand in Hand,” September 2015. [2] Forbes article by Bernard Marr, “Will Analytics on the Edge be […]


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

ビッグデータの分野では、従来のデータウェアハウスを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  は、ジョブレベルが‘,’、‘;’等に設定されたコンテキスト変数です。context.column_listは、抽出する必要のあるFIELD(例:field1、field2、field3…)の連結であるコンテキスト変数です。 このオフロードジョブは、Sparkを使用してHadoop上でネイティブにクエリステートメントを実行します。 生成されたコードは、YARNを介して直接展開されます。 上記のジョブを自動化し、メタデータ駆動型の取り込みフレームワークに変換してテーブルリストを操作する オフロード準備プロセスは、データベースから開始します。次に、テーブルリストとテーブル内の列リストの抽出とコンテキスト化が行われます(オフロードジョブに送信される変数の準備)。 これが完了すると、テーブルの反復処理によりオフロードジョブへの単純な呼び出しが行われ、Hadoopへのオフロードが実行されます。 オフロードプロセスは、前述の「SparkジョブからHDFSへテーブルをオフロードする」セクションで説明したジョブです。 Download >> Talend Open […]