`

Talend Blog


ガートナーのマジッククアドラントがなぜ開発者の秘密の武器となるのか

  2017 Gartner Magic Quadrant for Data Integration Toolsは、「最もよく守られている秘密」だったあなたの最新のTalendプロジェクトを、組織的に認知された天才の例という状態にするために、一役かうことができるでしょう。 私たちは皆、「誰にも言えない小さな秘密」を持っています。高校時代には両親が旅行中の家でパーティーをしましたよね。大学でジョン・トラボルトの子供だと思って付き合っていた友人は、本当は単に同じ姓だっただけかもしれません。住んでいる場所とは別の校区に子供を入れたくて、偽の住所で申し込みをしたことがある人はいませんか? 私たちはみな「ルールを破っている」可能性のある小さなことをやっていますが、それをする理由はもっと大きいものです。 私が2、3のシャドーITプロジェクトを自分で持っていなかったと言えば、嘘になるでしょう(そしてTalendの ITの誰かがこれを読んでいたら、すみません…という感じです)。私たちは、物事を修正したり、新しい問題を解決したいという好奇心を持っていて、技術的ではない部分でイノベーションが邪魔されるのが好きではありません。 特に、時間的な制限がある時などには特にそうです。単に計算に合わないのです。Talend Open StudioをITチームの陰で使用してデータ統合ジョブを構築するのは、多くの場合、オープンソースツールが企業のIT部門、つまり言うなれば「却下庁」によってぶち壊されることが多いためだと思います。 ダウンロード>> Talend Open Studio for Data Integration あなたが進めている最新のオープンソースベースのデータ統合プロジェクトの価値をITチームが理解し、そしてそのまま継続させてくれるようにするために、最新の2017 Gartner Magic Quadrant for Data Integration Toolsを彼らと共有することをお勧めします。レポートは無料でこちらからダウンロード<link to the download form>できます。我々は、本レポートは「ホーリーハンドグレネード」であると信じており、もしあなたもそう信じるなら、このレポートは開発者がTalendを使用するためのビジネスケースを構築することに役立つでしょう。本レポートは、「ビジョンの完全性」と「実行能力」の両方で、Talendを「リーダー」クアドラントに位置づけています。また、Talendは「リーダー」クアドラントに残っているベンダーの中で唯一オープンソースを提供するベンダーであることも重要なポイントです。 リーダークアドラントでの位置付けの向上は、当社のソリューションの深みと幅、現代のクラウドおよびビッグデータ環境向けに構築されたオープンソースベースの統合プラットフォームを提供する能力を示しています。 あなたのような開発者にとって、それはどういう意味をもつのでしょうか?あなたが実行したシャドーITプロジェクトにスポットライトを当て、十分実証することができるのです。自信を持って ITマネージャーを呼び出し、「オープンソースソフトウェアを使って何をしているのか見てください。われわれはデータから多くの価値を得て、市場投入までの時間を短縮し、コストを下げている(というか無料)、しかもそれをガートナーのマジック・クアドラントのリーダーでやっている」 ということができるのです(クイックヒント:デスクの上にレポートを置いておくと、彼らがレポートを検索する手間が省けます)。 必ずしもITマネージャーに伝える必要はありませんが、同様に重要なことがあります。Talend Open Studioのようなオープンソース製品を使用することは、あなたのキャリアにとって素晴らしいことです。 数分の時間を使って、Talendのさまざまな製品とビジネスの強みを具体的に列挙したレポートを詳しく見てみてください。Talendを使っていることがなぜ誇らしいのか、その理由がもっと見つかるでしょう。 すでにTalend Open Studioを使っていても、あるいは(闇に紛れて)その機能を研究し始めたところであっても、Talendを使っていることをオープンにする必要があります。 Caddyshackの一場面を覚えていますか?今はあなたが水しぶきをあげる時です。先に進んで思い切ってあなたのオープンソースプロジェクトを披露してください…ただ、ベビールースは家においてきてください。 (訳注:Caddyshackとは1980年制作のアメリカ合衆国のコメディ映画) # # # ** Gartner does not endorse […]







機械学習について知っておくべきこと

  この数か月間、人工知能、特に機械学習について、多くの意思決定者と話をする機会がありました。 彼らの多くは、機械学習(ML)の戦略、そしてMLをすでに実装している領域について、投資家から質問を受けたことがあると話していました。このように技術的なトピックが、突如として企業役員の間で取り上げられるようになったのはなぜでしょうか。 コンピューターは、人間に代わってタスクをこなすことを期待されています。 コンピューターに指示をする従来の方法は、手順を「プログラミング」することです。つまり、問題解決のための適切なアルゴリズムを人間がコンピューターに教えるのです。アルゴリズムは、料理のレシピのように手順を詳細に説明するものです。 アルゴリズムによって、多くのタスクを効果的に記述できます。 たとえば、小学校では足し算のアルゴリズムを学習します。 コンピューターは、アルゴリズムを迅速かつ完璧に実行するうえで人間よりもはるかに優れています。   ただし、この手順には限界があります。たとえば、猫の写真を識別するにはどうしたらよいでしょうか。 これは簡単そうに思えるタスクですが、アルゴリズムとして構造化することは困難です。 これがどういうことが、考えてみましょう。 たとえば、「足が4本ある」や「目が2つある」といった単純な命令すらも、完璧ではありません。これらの部分が隠れていたり、猫の一部しか写真に移っていなかったりする場合には機能しないためです。さらに、足や目を識別するというタスクも、猫を特定するのと同様に困難です。 このようなタスクで強みを発揮するのが機械学習です。問題を解決するためのアルゴリズムを開発する代わりに、コンピューターは例を使用して自らアルゴリズムを学習します。コンピューターの訓練には、サンプルを使用します。猫を識別する場合は、適切にラベル付けされた多数の猫の写真を使ってシステムを訓練します(教師あり学習)。 これによってアルゴリズムが進化・成熟し、最終的には、初めて見る写真でも猫を識別できるようになります。 実際に、このような状況では、コンピューターは通常、従来のプログラムを学習するよりも、モデル内のパラメータ(たとえばネットワーク内のエッジの重み)を学習します。この原理は、人間の脳で神経細胞(ニューロン)間の接続が順応する学習プロセス(少なくとも人間が理解する限りにおいて)と比較することができます。つまり、コンピューターのプログラムとはちがって、人間にはエッジの重みを持つネットワークを解釈することが事実上不可能です。   このように、プログラムよりもモデル内のパラメーターを優先的に学習するというコンピューターの特性を活したディープラーニングと呼ばれる人工ニューラルネットワークの特殊な学習手法が特に成果を上げています。ディープラーニングは、機械学習の一分野です。機械学習は、コンピューターサイエンスの主要研究分野である人工知能の一分野です。. 2012年には、Google社の研究チームが、16,000台のコンピューターを使ったネットワークに対して1,000万のYouTube動画のイメージから猫(及び他のオブジェクトカテゴリ)を識別する訓練に成功しています。 ここで使用された手順はディープラーニングでした。 練習関連の多くの問題は、「足し算」というカテゴリよりも「猫の識別」というカテゴリに分類されるため、人間によって書かれたアルゴリズムでは適切に解決できません。しばしば、データに含まれるパターンの識別が問題になります。たとえば、イメージ内のオブジェクト、言語のテキスト、トランザクションデータの不正行為を認識するといったことです。 簡単な例として、予測的保守について考えてみましょう。多数のセンサーからデータストリームが送られ、たまにマシンが故障することがある場合、故障を引き起こすデータストリームのパターンを学習することが課題となります。 この学習により、正常な動作が行われているときにパターンを特定できるようになるので、潜在的な故障を予測して防止できます。 機械学習の原理は新しいものではありませんが、現在その人気が急速に高まっています。これには主に3つの理由があります。第1に、適用領域と訓練に必要な大量のデータ(「ビッグデータ」)を利用できるようになったことです。第2に、特にクラウドにおいて、高いコンピューティング能力を獲得したことです。 第3に、さまざまなオープンソースプロジェクトによって、ほとんど誰もがアルゴリズムを利用できるようになったことです。 機械学習は、従来のプログラミングを置き換えるものではなく、補完するものです。これまで習得が困難または不可能だった問題の主要カテゴリに、新たに対処できるツールとなります。これによって新しいチャンスがもたらされていますが、既存のシステムも機械学習機能を組み込むようになっています。 パターンに従う繰り返し処理は、その典型的な例です。たとえば、複雑な一連のメニューを介して100の機能を使えるコンピュータープログラムがあり、ユーザーが日常的に使用している機能が数種類だけの場合、コンピューターはユーザーの通常の手順を観察して学習することで、ユーザーの次の操作を予測し、効率を上げることができます。または、データの割り当てと変換(たとえば、データウェアハウスへのデータ投入のためのETLジョブ)では、コンピューターが繰り返しのデータ及びオブジェクトを「学習」することで、多くのステップを自動化して高速化することができます。 その他にも、学生個人向けの学習教材の適切なカスタマイズ(特に「MOOC」と呼ばれる誰でも無料で受講できる大規模なオンラインでの講義)、病気の早期診断、オンラインマーケティングのための適切なターゲットグループ、顧客の解約、データ品質問題の自動識別、出会い系サービスのユーザープロファイルのマッチング等、ほぼ全ての領域で例を挙げることができます。. 高度なツールが使用できるSpark(Hadoopとの組み合わせ)は、機械学習分野におけるビッグデータの主要フレームワークとして確固たる地位を築いています。 このアプローチは、Talendでも追求していますが、(訓練と実稼働での展開の両方について)モデリングジョブによりさらに高いレベルで抽象化されています。 モデリングは複雑さを軽減し、それと同時に基盤技術から一定程度の独立性を実現します。急速に変化を続ける基盤技術には、限られた専門家しかアクセスできないためです。 機械学習の分野では、アルゴリズムの細部を実際に理解する必要があるのは、ごく少数のスペシャリストだけです。一方、MLとは基本的に例からパターンを学習し新しいデータセットでこれらのパターンを使用できることである、というMLの概念を理解することは誰にとっても有益です。最終的には、マシンが処理することで、特に意思決定プロセスによって、自動化できる問題のカテゴリが拡大します。 つまり、コンピューターの学習とは、訓練データから蓄積した知識に基づいて新しいデータに関する決定を下すことです。 また、ビジネスやさまざまな活動で意思決定を自動化することで、機械学習を有用に活用することができます。 また、ビジネスやさまざまな活動で意思決定を自動化することで、機械学習を有用に活用することができます。 機械学習について、ここでは次の点を強調して締めくくりたいと思います。コンピューターは、明確な命令(足し算等)を処理するだけでなく、例から学習(サンプル画像を使った訓練による猫の識別等)する能力を持つようになっています。 どちらの手順が適切かは課題によって異なりますが、 両方の手順を組み合わせる方法は無限にあり、これによってさらなる自動化のチャンスがもたらされます。 著者紹介:Gero Presser博士 Gero Presser博士は、ドイツのドルトムントに拠点を置くQuinScape社の共同設立者であり、マネージングパートナーを務めています。 QuinScape社は、ドイツ市場におけるTalend、Jaspersoft/Spotfire、Kony、及びIntrexxプラットフォームの主要システムインテグレーターであり、100名のスタッフがSME、大規模企業、公共機関を含む厚い顧客層にサービスを提供しています。Gero Presser博士は、人工知能分野の意思決定理論で博士号を取得しました。QuinScape社では、分析と統合に焦点を当ててビジネスインテリジェンス分野の事業開発を担っています。







TalendとApache Beamを使用したデータレイクでのデータプレパレーション

  最近、Apache Beam(バージョン2.0)の最初の安定版が最近リリースされたことは、皆さんもすでにご存じかと思います。 Apache Beamは、バッチ及びストリーミングのデータ処理用に設計された高度な統一プログラミングモデルです。非常に強力でポータブルであることから、Talendでも当初から積極的にプロジェクトに貢献してきました。 Talendは最近、Apache BeamをTalend Data Preparationに統合しました。このリリースの新機能については、François Lacasがブログで紹介しているので、ぜひお読みください。ここでは、Apache BeamがTalend Data Preparation製品で実際にどのように動作するのかを説明します。 Apache Beam入門 Apache Beamとは、根本的に、ユーザーが統合パターンと実際のランタイム環境から抽象レイヤーを提供する方法です。この抽象化レイヤーによりBeam SDKを使用したデータ統合プロセスのコーディングが可能になります。プロセスを実行するには、必要な処理アーキテクチャーやランタイム向けにBeamランナーと呼ばれるものを選択します。 これは、Spark、Google Data Flow、Flink等、将来データを処理するために使用する任意のものを選ぶことができます。Beamはさらに、バッチとストリーミングの両方のワークロードに使用できます。Beamは接続先に応じて使用可能なランナーのタイプを認識するということです。コミュニティは、さまざまなプラットフォーム向けに多様なランナーを構築しています。これによって、統合コードからランタイム環境への真の抽象化が実現します。 Beamでデータプレパレーションを強化 次のビデオでは、Talend Data Preparationの2つの主要機能を紹介しています。後半ではBeamの活用を取り上げています。 HDFSファイルシステムから直接データを読み取る 完全なデータセットをエクスポートする、またはHDFSの別の場所に書き戻す HDFSからParquetファイルを読み取るため、Talendの新しいコンポーネントカタログフレームワークとSDKを使用しています。ビデオで使用している例では、Parquetにフォーマットされたファイルがメタファイルとデータファイルから成るマルチパートファイルである点に注目してください。Talend Data Preparationはメタデータを読み取り、列ヘッダー名をツールに取り込むことができるようになりました。また、複数のファイル部分全てからサンプリングを行い、データセット全体の品質の高いサンプルをユーザーに提供できます。この操作はビデオで確認できます。 ビデオの後半では、データをHDFSにエクスポートして戻すという素晴らしい機能を紹介しています。背景ではTalend Data Preparationサーバーが、完全なエンドツーエンドのSpark処理ジョブを構築し、そのSparkジョブを前述のとおりにBeamとSparkランナーを使用してクラスターに送信しています。 Talend Data Preparationツールで「エクスポート」を選択し、完全なデータセットをHDFSへエクスポートするよう選択すると、インポートプロセス(コンポーネントカタログ)からの接続情報、準備ステップ(データプレパレーションに必要な変更の「レシピ」)、エクスポート先となるSparkクラスターの場所がエクスポートされます。Talend Data Preparationサーバーはこの情報を全てフローランナーに送信し、フローランナーは全ての情報を取得してApache Beamコードに変換します。 その後、Apache BeamコードがSparkジョブサーバーに送信されます。これは、ユーザーのIT管理チームが設定した適切なセキュリティとアクセス権を使用してSparkクラスターに接続するように構成されたBeam Sparkランナーです。 Sparkジョブサーバー、またはBeamランナーは、ジョブを(ネイティブのSparkコードとして)クラスターのリソースマネージャーに送信し、クラスター内で必要に応じて実行します。Sparkジョブサーバーは、リソースマネージャーのジョブのステータスを監視し、終了時に完了ステータスを報告します。Talend Data Preparationサーバーは、実行したプレパレーションのエクスポート履歴ダイアログで完了ステータスを提供します。 現在のテクノロジーに対応し、将来に備える このように、Talendはテクノロジーの最先端にあります。ユーザーは、データプレパレーション処理のバックエンドでApache Beamを使用することによって、準備の実行のために使用するソリューションを選択できます。これは、現在はApache Sparkであったとしても、将来はFlinkまたはApexかもしれません。Apache Beamの素晴らしさは選択肢の一つです。どのような処理テクノロジーを選ぶ場合でも、Talend Data Preparationによって、最新データツールを使用するデータの処理とクレンジングが可能になるのです。







Talend CTOからの助言:マルチクラウド環境で成功するための戦略

  6月末にTalend Summer ’17リリースが正式に公開されました。これは、Talendの過去最大のクラウドリリースです。AWS向けにすでに提供しているEMR、Redshift、Aurora等の堅牢なコネクターに加えて、今回のリリースでは、Google Cloud PlatformとMicrosoft Azure用の包括的なコネクターセットを提供しており、データウェアハウジング、Hadoop、NoSQL、ストレージ、及びデータレイク分野のサービスが含まれています。 Talend Summer ’17リリースの詳細は、こちらをご覧ください。 Talendのお客様の中には、地理的に分散したマルチクラウド環境を管理する戦略の策定について、差し迫った問題を抱えている方もいらっしゃいます。マルチクラウド環境は、社内の各部門がそれぞれに異なるベンダープラットフォームを利用してクラウドの使用を開始し、そのまま既存環境を引き継ぐ形で構築されてきました。一見すると、ITリーダーにとってマルチクラウドの世界は、管理上の問題に過ぎないかもしれません。しかし実際には、多くのチャンスと課題の両方が内在しています。グローバル企業としてのアプローチでクラウド管理体制を構築するには、これらのチャンスと課題を慎重に検討する必要があります。今回はこのような状況を受けて、マルチクラウドの世界での成功を目指す企業のベストプラクティスについて、TalendのCTO、Laurent Brideから豊富な経験に基づく提言をお届けします。 以下に紹介する3つの短いビデオクリップでは、マルチクラウド環境を管理する上で、今日のITリーダーが直面している3つの重要な問題について解説しています。 マルチクラウド環境を維持するうえでの3つのメリットとは? マルチクラウド環境によって顧客が抱える3つの課題とは?  地理的に分散したマルチクラウド環境を管理する際に考慮すべき3つの重要事項とは? マルチクラウドのメリット 顧客は、マルチクラウド環境(既存環境の継承か、新規構築かを問わず)から最大の価値を引き出すために、ベンダーロックインを回避しつつ、それぞれのクラウドベンダーが得意とするサービスを活用することができます。例えば、あるクラウドベンダーはストレージ等のイノベーションに強く、別のベンダーはデータウェアハウジング、または人工知能の専門知識に強い、といったケースです。 複数のクラウドプラットフォームを利用することで、ストレージやコンピューティング等の市販のローエンドのサービスから、データベースやビッグデータ等のハイエンドサービス等、各ベンダーが提供する最高のサービスを選択できます。クラウドベンダーは、タイムコミットメントとオープン市場のスポット価格をベースに、各サービスを様々な価格で提供しています。したがって、顧客は、最低価格で最高のパフォーマンスを引き出し、そのコストを時間で計画し、ビジネス要件の変化に応じてベンダーを切り替えることができます。 マルチクラウド環境で考慮すべき課題 確かにマルチクラウド環境からはさまざまなメリットを得られますが、その一方で、予期し、計画すべき課題も数多く存在します。 多くの組織は、各クラウドベンダーが特に適しているシナリオを見極めようとしています。 たとえば、機械学習や人工知能では、GoogleがTensor Flowによって大きな進歩を遂げており、特にディープラーニングで強みを持っています。 パブリッククラウドとプライベートクラウドの両方で高性能なサービスを求める組織にとっては、AWSがVPC(仮想プライベートクラウド)とパブリッククラウド間のシームレスなワークロードの移動を可能にします。 さらに、オンプレミスへの投資と新しいクラウドへの投資の統合については(特にオンプレミス投資でのMicrosoftの比重が大きい場合)、まぎれもなくMicrosoft Azureが選択肢となります。Microsoftは、オンプレミスのビジネスアプリケーションスイートと緊密に統合されたクラウドファースト戦略を実施する顧客を支援すべく継続的に取り組んでいます。 その他にも、マルチクラウドソリューションには、ガバナンスとセキュリティを満たすうえでの課題も存在します。企業は、急速に変化するビジネスプロセスが統合にどのように影響するかを細部にわたり検討し、イベント、ID管理、コンプライアンスを追跡・監査するための堅牢なフレームワークを実装する必要があります。クラウドで膨大なデータが生成されている現在、メタデータの整合性を確保することは、全ての企業IT部門の最重要タスクの1つとなっています。 地理的な場所と将来のビジネス拡大 グローバル企業のIT責任者は、複数地域の対応という課題にも取り組まなければなりません。地理的に分散されたマルチクラウド戦略を構築するには、クラウドデータが存在するさまざまな国の、複数の規則や規制に準拠する必要があります。たとえば、欧州では、データプライバシーを重視するGDPRの規制があり、違反に対して厳しい罰金が課せられます。また、アプリケーション性能の高速化に対する期待も生まれています。遅延の短縮のために、地域の最適なクラウドサービスプロバイダーを選択すれば、データの格納場所でデータを最適に処理できるようになります。また、データ移動を考慮して、実際のコンピューティングは、データの格納場所のそばで行うようにしましょう。







TalendとCloudera Altusの連携が簡単な理由

  ご存じの方も多いかと思いますが、Talendは先日、新たにリリースされたCloudera Altusのサポートを発表しました。Cloudera Altusは、大規模データ処理アプリケーションのパブリッククラウドでの実行を簡素化するPlatform-as-a-Service(PaaS)ソリューションです。 Talendのお客様がクラウドのメリットであるコスト、利便性、スケーラビリティの実現を目指していることを考えると、Altusをリリース当初からサポートすることは最も簡単な決定でした。Talend Studioでデータパイプラインを構築してテストし、Altusクラスターに直接展開できるので、作業が大幅に単純化されます。 Talendは、Cloudera Altusのサポートを提供する初めての統合プロバイダーです。Talendは、Cloudera Altusのサポートを提供する初めての統合プロバイダーです。 Cloudera Altusが解決する課題 Cloudera Altusは、データエンジニアリングのワークロードをクラウドで簡単に実行できるようにするマネージドサービスです。.その特長として、次の3つの機能を挙げることができます。 Altusによって展開されたクラスターは、データの格納場所で実行されます。これらのクラスターに対して実行されるジョブは、Amazon S3のデータを直接読み書きでき、別の場所からデータをコピーしたりロードする必要がありません。 Altusは従量制モデルを採用しているので、ユーザーはデータ処理の費用対効果を高めることができます。 最後に、AltusはエンタープライズClouderaプラットフォームに基づいているため、既存のClouderaユーザーは、オンプレミス環境とクラウド環境の間でワークロードを容易に移行できます。 Altusは、当初はAWSでのClouderaクラスターの展開を提供します。Cloudera社は今後、Microsoft Azure等のパブリッククラウドへとサポートを拡大する予定です。 AltusとTalendの連携がもたらすメリット プレスリリースに記載のとおり、Altusはビッグデータプロジェクトの展開を劇的に高速化し、運用サポートを大幅に削減するため、クラウドへ移行するTalendのお客様にとって重要な役割を果たします。そしてTalendは、Altusプラットフォームでのインテリジェントなデータパイプラインを簡単に構築し、迅速に展開できるようにするので、Altusを使用することの価値をさらに高めます。 開発者はコードを記述する必要がなくなり、データパイプラインの設計に専念できます。それとともに、Altusはクラスターの管理と運用に対応します。 AltusとTalendを使用する このソリューションについて、さらに詳しく見ていきましょう。Altusの機能を活用して、クラウドでのビッグデータアプリケーションの実行を管理・監視する方法について、説明します。 前述のとおり、AltusはAWS上で実行されます。つまり、Altusにより展開されたクラスターに対して実行されるジョブは、S3オブジェクトストアのデータを使用できます。 構成されたサービスでは、ユーザーのAWS認証情報が使用されます。 たとえば、Altusは、ユーザーが定義した構成に基づいて、Sparkクラスターのプロビジョニングを実行できます。 注意:クラスターは一時的なものです。したがって、データの格納場所を管理する必要があり、また、ジョブの実行ごとにIPアドレスが変わることを考慮する必要もあります。 Cloudera Altusでは、クラスターのセットアップ・構成及びユーザーアカウントの管理のために、管理コンソールとコマンドラインインターフェイスが提供されます。 FTalendユーザーは、Talend Studioを使用するだけでAltusと連動できます。TalendとAltusのシームレスな統合により、Talend Studioで任意の構成(ワーカーノードの数、Amazonインスタンスのタイプ、AWS S3バケットの場所等)を入力するだけで、新しいCloudera Altusクラスターのプロビジョニングを簡単に実行できます。 ジョブの準備が整ったら、Talend StudioからCloudera Altusにジョブを送信します。ジョブの実行はAltusのコンソールで監視でき、処理されたデータはS3に直接保存されます。 AltusでのSAPデータの分析 まず、Altusのコンソールで、すでに展開されているTalendジョブを表示できます。Altus環境には、AWSのリソース(使用しているリージョン等)がカプセル化されています。 たとえば、開発、テスト、本番といった必要な環境を、必要な数だけ使用できます。 クラスターの構成は、AWSの認証情報を入力するだけです。 Altusは、AWSのクロスアカウントアクセスロールを利用して信頼関係を確立し、ユーザーアカウント内でアクションを実行します。 ここに示す単純な例では、大規模な顧客データを集計して、月末の連結収益を計算しています。 Talendでは、次の2つのジョブを作成する必要があります。 SAPからデータを抽出し、Amazon S3にロードする Cloudera AltusでSparkジョブを実行し、SAPデータを集計する 最初のジョブは、ローカルのSAPインスタンスからデータを取得し、クラウドのS3に移します。これはCloudera Altusを使用するための前提条件となります。 注意:このような取り込みジョブの設計と実行のオーケストレーションは、Talend Integration Cloudを使用して簡単に実行できます。 2番目のジョブはAltusを利用します。最初のジョブでAmazon S3バケットに格納されたデータを、Altusによって展開されたSparkクラスターを使用して処理します。 技術的な観点では、Talendは、開発者がジョブを設計するための一連のグラフィカルコンポーネントを提供しています。 ジョブは、Cloudera Altus APIを介して、Altusクラスターでネイティブに実行されるSparkプログラムに変換されます。 […]







TalendとAmazon Web Services(AWS)を活用してビジネス変革を達成するには

変革をやり遂げるのは容易ではありません。しかし、競争優位性を獲得するためには、データ駆動型への変革が不可欠であるという認識が、一般的になってきています。 どのようなビジネス変革においても、組織変革のためには人 – プロセス – テクノロジーの連携を最適化することが重要ですが、同時に、これらは改造が最も難しい部分でもあります。デジタルの可能性を最大限に引き出すには、事業部門とIT部門の組織的連携が必要です。またIT部門は、セキュアな方法で迅速かつ俊敏にグローバル規模でのアプリケーションとデータの統合ができなければなりません。 Talendが最近公開した『クラウドアーキテクトのためのハンドブック』では、TalendとAWSのソリューションを活用してアプリケーションとデータの統合の課題を克服し、ビジネス変革を成功させた企業の事例を複数紹介しています。 今日は、それぞれの事例で各社がTalendとAWSのアーキテクチャーをどのように利用しているかをご紹介します。 ユースケース1:グローバル製薬企業における運用報告システムの変革 企業の成長のためには、長期的な戦略を立てることが重要です。長期的戦略により、取り組みの焦点を絞り、それに向かってチームの連携を図ることができます。 正確なデータを使って必要なインサイトを得ることは、確実な戦略を策定するための基盤となります。 最初のユースケースは、成長計画の策定が難航していた大手の製薬企業の事例です。戦略の定義を最適化するために、グローバルで運用している複数のシステムを統合し、正確なKPIデータをタイムリーに取得することが急務でした。 複雑な統合ソリューションを経験したことのない企業では、時間的な制約だけでなく、コストや部門ごとにサイロ化されたデータという問題が統合プロセスを困難にすることがあります。幸い、この製薬企業はTalendと提携することで、迅速に統一され、かつ拡張性の高いデータ統合を実現しました。 今回のプロジェクトでは、Amazon S3でTalend Data Integration及びTalend Application Integrationプラットフォームを展開し、Amazon VPC(Virtual Private Cloud)、Amazon Aurora、AWS Elastic Beanstalk等のAWS製品を使用して、クラウドベースの最新の運用報告インフラストラクチャを設計・構築しました。これによって、最小限のコストでニアリアルタイムの正確なデータ分析のインサイトを得ることができます ユースケース 2: 臨床試験研究の公開データセットを使用した治療の改善   癌や腫瘍の治療薬といった新薬の市場投入は、どの製薬企業にとっても時間と費用がかかり、徹底的な精査の対象となる取り組みです。 新薬の市場投入期間を短縮する方法の1つは、詳細な臨床研究情報を含む公開データセットを利用することです。2番目のユースケースもグローバル製薬企業の事例です。この企業は臨床試験に関する複雑で階層化された膨大なXMLファイルを合理化・変換しなければならないという難題を抱えていました。 課題に対応するため、Talend Big Data Platform、Amazon S3、Amazon VPC、AWS Auto Scaling Group、そして最後にAmazon Redshiftが使用されました。このAmazon Redshiftは、ペタバイト規模に対応する完全に管理された高速のクラウドデータウェアハウスであり、既存のビジネスインテリジェンスツールを使用してデータを高い費用対効果で簡単に分析するという重要な機能を提供するAWS製品です。これらの製品の活用によって、この製薬企業は臨床試験情報のXMLファイル52,000件を合理化し、米国食品医薬品局(FDA)と共有可能な形式に変換することができるようになり、製品の市場投入期間が大幅に短縮されました。 ユースケース 3:ターゲットを絞ったキャンペーンの開発におけるリアルタイムのソーシャル/モバイルデータの活用 ターゲットを絞ったマーケティングキャンペーンのためにモバイルデータやソーシャルデータを活用することは、デジタルに精通した企業では一般的となっています。 フォーチュン500にランクインする大手の飲食料品小売企業は、最終消費者の好みや購買行動をさらに理解するために、小売データだけでなく、消費者が利用するモバイルアプリケーションやソーシャルメディアチャネルのデータを分析することにしました。しかし、従来のETL(Extract, Transform, Load)システムでは機能が充分ではなく、ビジネスユーザーのデータ分析能力が活かすことができませんでした。 このユースケースでは、Apache HadoopやSparkのようなビッグデータフレームワークの実行を簡素化する、Amazon EMR等の完全に管理されたクラスタープラットフォームを使用することが重要でした。  さらに、Talend Real-Time Big Data PlatformをAmazon S3及びAmazon EMRと組み合わせることで、セキュアなAWSクラウド環境で1,000万人のアプリケーションユーザーのサンプルセットに基づいて予測分析を実行し、最終消費者を対象にターゲットを絞ったマーケティングキャンペーンを開発することができました。 […]







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 […]







ビッグデータ活用の第1歩を踏み出すには

ビッグデータ活用の第1歩を踏み出すには 全世界のデータ量が2年ごとに倍増している背景で大きな原動力となっているのは、ソーシャルメディアに続くトレンドとなっているIoT(モノのインターネット)です。[1] 同時に、データ処理の速度と能力はますます重要になってきています。これは、食料品と似て、一定の期間が経過するとデータの妥当性が失われてしまうためです。 さらに現在では、多様化する構造化データ、非構造化データ、半構造化データ(画像、テキスト、ビデオ、音声等)の取得及び分析が容易になりつつあります。 ビッグデータは、量、速度、多様性という3つの主要要素で定義されます。[2] この3つの要素を制御できる企業は、データを活用して大きな価値を引き出すことができ、デジタルの成熟度が劣る企業と比較すると、より大きな成功を実現していくでしょう。[3] 包括的なデータ取得戦略を成功させて競合他社との差別化を図ることに成功している企業があります。例えば、Amazon社、Netflix社、Uber社等がその一例としてあげられるでしょう。 ビッグデータ技術に向けた適切なプラットフォームを構築することも、その戦略の一環として必要です。 O’Reillyのレポート、「The Big Data Market 2016」[4] によると、大企業(従業員数5,000人以上)は中堅中小企業に比べてはるかに迅速にHadoopやSpark等のビッグデータ技術を導入しています。 しかし、中小規模の組織が今日の最新データプラットフォームを活用して「デジタルリーダー」になるチャンスも多くあります。 Cloudera社によると、Hadoopのエコシステムが成熟することで、コスト削減を達成できるだけでなく、より戦略的なデータ利用による新たなビジネスチャンスが生まれる可能性もあります。ビッグデータは、顧客に対する理解を深め、製品やサービスを改善し、より効果的なプロセスを実現し、品質保証の改善と問題検出の強化によってリスクを低減するために主に活用されます。[5] 順調なスタートを切るために ビッグデータプロジェクトを開始するのは難しいと思われがちです。 日々の業務でビッグデータ技術を何となく検討してはいるものの、具体的なプロジェクトを開始するまでには至っていない中規模の企業を多数目にしています(ドイツ語圏の市場での話です)。では、ビッグデータプロジェクトを開始する最善の方法とは何でしょうか。 経験から言って、一般的に最も成功するアプローチは、実際のビジネスに関連した明確に定義された小さなプロジェクトプランを作成し、そこから始めることです。当社の顧客の多くは、新しいデータソースから得られる、増加を続けるデータを保存するという課題に直面しています。 多くは機械からのデータであり、ソーシャルメディアデータも時に含まれます。原則的には、データをリレーショナルデータベースに格納することも、既存のデータウェアハウスに格納することも可能です。 しかし、それではコストが高くなるため、代替案を検討する必要があります。つまり、それら従来の方法は、現在では適切であるとは言えないのです。 小さなプロジェクトは、ビッグデータ技術の使用経験を積むために効果的と考えるのが一般的です。 リスクを回避しながら新しい技術を初めて使用するうえでは、比較的小さく、管理しやすく、隔離されたプロジェクトが基本的には適しています。 Volume(量)、Velocity(速度)、Variety(多様性)という3つのVが全て完全に満たされるかどうかは、重要ではありません。一方で、制御可能な適切かつ妥当なビッグデータのユースケースを使用し、成否を判断するための基準を設け、パイロットから本番稼働環境に迅速に移行できるようにすることが重要です。[6] 仮に、充分に実績のある技術を使用してビッグデータプロジェクトに対応できるとしても、新しいビッグデータ技術を試してみる機会があれば、それを逃すべきではありません。新しい技術を制御しやすい規模で試しておかなければ、より大規模で複雑なプロジェクトに対処できないという事態に陥りかねません。 ビッグデータ技術はすでに成熟し、利用しやすいものであるため、ビッグデータプロジェクトのアーキテクチャーも通常は対処しやすいものです。データストレージには、Hadoopディストリビューションが使用されます。 データは、最初にソースで収集され、場合によっては変換され(ビッグデータについては変換せずに生データを保存することが推奨されます)、その後でHadoopにロードされます。 Talend Big Data Platformは、このようなモデルに基づいて実装するために必要な、全ての機能を提供します。これによって生成される高性能なネイティブコードを使用して、チームは短期間でApache Hadoop、Apache Spark、Spark Streaming、及びNoSQL技術を活用できるようになります 最終的に、データは生データレベルに対して直接、または前処理済みデータが格納されたデータマートを経由して検証されるのが一般的です。続いて、データマートへのデータ格納はTalendによって行われます評価には現在適切なツールを使用していればそれを利用することもできますが、データの可視化、発見、及び高度分析等の新しいツールを導入する良い機会でもあります。 開始、拡大、そして機会創出 ビッグデータと従来型データウェアハウスの関連性は高まりつつあります。 理論的には、Hadoop等のビッグデータ技術を活用して、データウェアハウス全体を近代化することが可能です。これによって、多くの場合は大幅なコスト削減を実現しながら、新しいチャンスを創出できます。 一方で、時間をかけて従来のデータウェアハウスにビッグデータの領域を統合することも可能です。 Oビッグデータインフラストラクチャを構築した後は、Hadoopとデータウェアハウスを簡単にリンクできます(どちらの方向も可能です)。 データウェアハウスは、Hadoopに格納されているデータのソースとして機能します。  同様に、Hadoopからデータを読み取って変換し、最終的にデータウェアハウスに格納することもできます。 これら2つの領域を相互に隔離する必要はなく、統合することで最終的にはビッグデータ技術に基づくデータウェアハウスを実現できます。 千里の道も、常に最初の一歩から始まります。 ビッグデータ技術は成熟し、利用しやすくなりました。しかし、何事にも当てはまることですが、具体的に動かなければ前進もありません。 したがって、そのようなプロジェクトを積極的に見つけることをお勧めします。 実際に第1歩を踏み出して技術を調査し、インフラストラクチャを構築できれば、そこで生まれる新しいチャンスからすぐに利益がもたらされます。これによって、データ駆動型企業に有利な現代の環境で、競争力を維持していくことができます。 References [1] https://www.emc.com/leadership/digital-universe/2014iview/executive-summary.htm [2] https://en.wikipedia.org/wiki/Big_data [3] https://www.idc.com/getdoc.jsp?containerId=prAP40943216 [4] https://www.oreilly.com/ideas/the-big-data-market [5] http://www.cloudera.com/content/dam/www/marketing/resources/whitepapers/the-business-value-of-an-enterprise-data-hub.pdf.landing.html [6] http://www.gartner.com/newsroom/id/3466117 [7] https://talend.com/products/big-data About the author Dr. Gero […]