月別: October 2019

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 Designerでユーザーが自身のPythonスキルを活用し、ツールを拡張して必要なカスタム変換に対応できるようにすることを目指しました。そのためPipeline Designerは、カスタマイズ可能な変換のためにPythonをスクリプト化するためのPythonコンポーネントを埋め込んでいます。 データ活用をさらに推進 Pipeline Designerのさらに良い点は、スタンドアロンアプリケーションでもシングルポイントソリューションでもないことです。Talend Data Fabricプラットフォームの一部であり、データバリューチェーンの複雑な側面をエンドツーエンドで解決します。Data Fabricを使用することで、システム全体でデータを収集し、それを管理して適切な使用を確保し、新しいフォーマットに変換し、品質を向上させ、社内外のステークホルダーと共有できます。 […]


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

クラウドへの移行 2018年はクラウドの年であり、クラウドテクノロジーに移行する企業が増えるにつれて、ビジネスがクラウドを最大限に活用する方法を理解することが重要となります。企業が今日抱えている大きな問題の1つは、オンプレミスのデータベースからクラウドデータストレージへのデータの移行です。適切なツールがなければ、これは時間のかかる退屈なプロセスになります。幸いなことに、ここでTalendを役立てることができます。 Talendでは、オンプレミスのデータベースであるMySQLをクラウドストレージのAmazon S3に移行する必要がありました。Apache Sqoopの複雑さに対処する代わりに、いつでも新しいデータをクラウドへ移行できるジョブをTalend内に作成することにしました。この方法を使用することで貴重な時間を節約でき、その分を新しく移行したデータの分析に使用できました。このブログでは、このジョブをどのように構築したかを振り返ります。早速始めましょう。 接続の作成 Talendのジョブと同様に、最初に接続を作成します。MySQLデータベースに対しては、tMysqlConnectionコンポーネントを使用します。また、tS3Connectionを使用してS3クラウドストレージへの接続を作成する必要があります。このジョブを実行するたびに、毎回MySQLとS3の両方に接続することになるので、両方のコンポーネントの前にtPrejobを追加する必要もあります。 Talendはコード生成ツールであり、tPrejobを使用することで、常に最初にコンパイルするものを制御でき、常にデータベースに接続できるようになります。両方の接続コンポーネントを構成した後、次のスクリーンショットのようにtPrejob、tMysqlConnection、tS3Connectionを接続できます。 テーブルの取得と動的スキーマの設定 両方のストレージプラットフォームに接続したので、MySQLからAmazon S3へのクラウド移行プロセスを開始できます。まず、データベースから移動する、すべてのテーブルのリストを取得する必要があります。tMysqlTableListを使用して、「WHERE句」を使用してリストするテーブルを指定できます。ただし、今回は顧客テーブルからのみ取得します。 転送対象の全テーブルのリストを取得したので、次にそのテーブル内の列のリストを取得します。 「tMysql」グローバル変数を使用することは、コンポーネントから値を取得するのに最適な方法です。これらのグローバル変数は、他のコンポーネントが使用する「tMysql」コンポーネントからデータを取得できます。この場合、((String)globalMap.get(“tMysqlTableList_1_CURRENT_TABLE”))は、tMysqlTableListコンポーネントによって収集されるテーブルからコンポーネントに列を取得させます。Talendでは、グローバル変数を記憶しなくとも簡単に検索できます。「tMysql」と入力してCtrl + スペースキーを押すだけで、すべての「tMysql」グローバル変数がリストに表示され、必要な変数を選択できます。 次に、tFixedFlowInputを追加して、「tableName」列と「columnName」列を生成する必要があります。最初にこれらの列のスキーマを構成した場合、値はtFixedFlowInputコンポーネント内にのみ表示されます。スキーマを設定したら、これらの列の値を設定できます。「tableName」については((String)globalMap.get(“tMysqlTAbleList_1_CURRENT_TABLE”))、「columnName」については((String)globalMap.get(“tMysqlTAbleList_1_COLUMN_NAME”))になります。 固定フローの後にtLogRowを追加すると、実行コンソールに情報を表示することで、ジョブの取得元であるテーブルと列の名前を確認できます。以下は、これまでのジョブを示すスクリーンショットです。 次に、オンプレミスデータベースからデータを取得するときに、データが使用する動的スキーマを設定します。名前が示すように、動的スキーマは、その時点で読み取られる列に応じて変化するスキーマタイプであり、ジョブに不可欠です。 動的なスキーマを設定するには、tSetDynamicSchemaというコンポーネントを使用します。tSetDynamicSchemaを使用すると、値「columnName」に基づいてスキーマを動的に設定できます。スキーマが動的になったので、各テーブルを個別に移動する必要はなくなり、複数の異なるテーブルを簡単に移動できます。 データの読み取りとテーブルの書き込み 動的スキーマを設定したら、tSetDynamicSchemaコンポーネントから作成された動的タイプを使用して、テーブルデータの読み取りを開始する準備ができました。オンプレミスのデータベースからデータを読み取るため、MySQLデータベースのtMysqlInputから読み取る入力コンポーネントを使用する必要があります。最初に、tMysqlInputコンポーネントのスキーマを編集して、動的DBタイプを使用する必要があります。このスキーマの列に「dynamic_row」という名前を付け、タイプは(もちろん)「Dynamic」、DBタイプは「VARCHAR」を指定します。 スキーマを設定したら、tMysqlInputコンポーネントを構成し、tMysqlTableListによってリストされている現在のテーブルからデータが取得されることを確認します。 テーブル内のデータは現在リストされている現在のテーブルから読み取られますが、依然としてデータをCSVファイルに書き出す必要があります。このために、tFileOutputDelimitedを使用します。「ファイル名」が正しいファイルパスに従っていることを確認する必要があります。 もう少しで終わります。以下は、これまでに作成したジョブを示すスクリーンショットです。 Amazon S3へのファイルの配置 これまでのところ、このジョブはcustomerという名前のすべてのテーブルを読み取り、指定されたフォルダー内のCSVファイルに書き込みます。オンプレミスのデータベースにあるテーブルからデータを取得できるようになったので、これらのファイルをAmazon S3に移動してジョブを完了します。 tFileListを使用すると、指定したフォルダー内に含まれる全ファイルのリストを取得できます。ここでは、オンプレミスデータベースから取得した全テーブルのリストを取得できます。ファイルを配置するディレクトリを指定する必要があるだけです。 すべてのファイルのリストを取得したら、それらをS3バケットに移動し始めることができます。そのために、tS3Putコンポーネントを使用します。「Bucket」、「Key」、および「File」を指定するだけです。「Key」はS3内のファイルの名前であり、「File」はS3にアップロードされるファイルの名前です。 tFileListとtS3Putの構成が完了したので、あとは、クラウド移行ジョブに最後の仕上げをするだけです。ジョブの最初に開いた接続を覚えていますか? tPostjob、tMysqlClose、tS3Closeを使用すると、ジョブが実行されるたびに開いた接続を閉じることができます。ここでも、メインループがコンパイルされた後に何が起こるかを制御でき、tPostjobコンポーネントの意義が発揮されます。簡単ですね。完成したジョブは、次のようになります。 ジョブの実行 ジョブが実行され、すべてが正常に処理すると、実行コンソールは下のスクリーンショットと一致するはずです。ご覧のとおり、コンソールには、読み取りおよび書き込み中のテーブルと、対応する列名が表示されます。 ジョブが完了したので、テーブルごとに複数のジョブを作成したり、厄介なハンドコーディングに煩わされたりすることなく、オンプレミスデータベースからクラウドストレージに任意のテーブルを移動できます。クラウド対応の準備が整うのは気持ちの良いことです。 デモをライブで視聴 このデモをライブで視聴するには、3月22日(木)にTalendのFacebookページに参加してください。#TalendDevLive ではジョブを構築する手順を紹介し、質問にも答えます。お見逃しなく!


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

以前のブログで、Hadoopでのデータクオリティ(DQ)プロセスを設計する際に留意すべき重要なヒントをいくつか紹介しました。その際に説明したデータプロセスとフレームワークは、データクオリティプログラムだけでなく、データガバナンスプログラム(導入している場合)にも影響するために重要です。皆さんの組織では、データガバナンスプログラムを導入していますか。概念としてのデータガバナンスは、十分に理解されているものではありません。そのため、この質問に答えるのは簡単ではありません。すでに何らかのデータガバナンスを導入していても、そのことに気づいていない場合があります。では、データガバナンス(DG)とは、どのようなものでしょうか。 Data Governance Instituteの定義によると、データガバナンスとは、「誰がどの情報を使用して、いつ、どのような状況で、どの方法を使用するかを説明する合意モデルに従って実行される、情報関連プロセスの決定権と説明責任のシステム」です。多くのことが盛り込まれていますが、結局のところデータガバナンスとは、標準、ポリシー、再利用可能なモデルに関するものです。このことを念頭に置いてください。 データの知見を得るための従来のアプローチであるデータウェアハウス(DW)を使用している場合は、おそらく、ディメンションテーブルの標準を用意することで、いくつかのデータガバナンスフレームワークと標準がすでに用意されています。したがって、DGのベストプラクティスについて話すときの最初のステップは、皆さん自身の企業がDGを導入する実際の意義を理解することです。 皆さんの企業にとってのデータガバナンス DGはMDMと同じようなものであると耳にすることがあります。その発言に問題があるわけではありませんが、不完全です。データガバナンスは、1つのプラットフォームまたは1つの概念である必要はありません。実際、健全なデータガバナンスアプローチには、複数のプラットフォームまたはプロジェクトが含まれる可能性があります。DGは、データに関連する事柄のルールと基準を設定する企業内のプログラムです。たとえば、ビジネスに売上レポートソリューションが必要な場合には、次のようなガバナンスの課題があります。 どの内部データベースにこの情報が含まれているか? 誰がアクセスできるか? 「顧客」または「ベンダー」と呼ぶものを定義したか? 販売データの構造はすでに定義されているか? ソースデータの品質は? データサイズに関する評価指標はあるか? ITチームはプロジェクトのソリューションを提供し、開発およびインフラストラクチャのサービスを提供する責任があります。しかし、データ関連のポリシーと標準について、ITチームに何らかのガイダンスを提供するのは、データガバナンスチームの責任となります。これにより、次の重要な考慮事項が導き出されます。 データガバナンス評議会 評議会は、データガバナンスのフレームワークの設定を担当します。DGフレームワーク自体は、企業の特定のニーズに合わせてカスタマイズする必要がありますが、一般的にフレームワークには、データニーズの決定、データポリシーとガイドラインの開発、データ管理プロジェクトの計画などの戦略計画タスクが含まれます。さらに、データ関連の問題の管理と解決、データポリシーの監視、データ資産の価値の促進など、継続的な制御タスクも含まれます。 ITプロジェクトのリーダーシップチームと同様に、データガバナンス評議会のメンバーには、ビジネスおよびITのメンバーを含める必要があります。企業がこのプログラムを確実に支持し、DGタスクに積極的に関与することが重要です。 また、評議会に柔軟な組織構造を持たせることも重要です。評議会のリーダーシップがガバナンスを推進するトップダウンのアプローチと並行して、ビジネスアナリストとデータスチュワードがポリシーを実装することをお勧めします。データスチュワードは、リーダーシップに必要なフィードバックを提供する責任を担います。 コミュニケーション DGの実装は、組織の大きな変化を伴います。これは、DG評議会がビジネスの利益と一致し、実装チームの強みを考慮したミッションを考え出すことが不可欠である理由です。DGプログラムのミッションは、組織内のDGの主な要因を明確かつ簡潔に伝える必要があります。ミッションは、さまざまな手段を使用し、繰り返し一貫性をもって伝達する必要があります。 フォーカスエリア:データガバナンスプログラムには、多数のフォーカスエリアを含めることができます。企業にとって最も価値のあるエリアを選択することが重要です。これらのイニシアチブは、エンタープライズレベルまたはプロジェクトレベルで推進できます。以下に、いくつかのフォーカスエリアと簡単な説明を示します。 標準とポリシー:この種のプログラムは、標準を収集し、既存の標準をレビューして企業標準に照らし合せます。もう1つの主な活動は、企業のデータ戦略を定義し、エンタープライズ環境に参加しようとするサイロ化されたプロジェクトをサポートすることです。 データクオリティ(DQ):この種類のプログラムは、企業内のデータ品質の問題を検出、修正、監視します。これらのプログラムには通常、プロファイリング、クレンジング、およびマッチングエンジン用のソフトウェアが含まれます。DQイニシアチブは、マスターデータを定義し、顧客やベンダーなどのドメインの360°ビューを提供するマスターデータ管理(MDM)プロジェクトにもつながります。 データのセキュリティとプライバシー:すべての企業にはコンプライアンスと規制の要件があり、このプログラムは、アクセス管理権、情報セキュリティ制御、データプライバシー手順などを、特に機密データについて設定することで、これらの問題に対処することを目指します。 アーキテクチャー/統合:このフォーカスエリアは、データモデリング、マスターデータモデリング、サービス指向アーキテクチャーなどのデータ統合アーキテクチャーコンポーネントを簡素化することにより、運用効率を達成することを目的としています。 DWおよびビジネスインテリジェンス(BI):このプログラムは、データウェアハウスおよびデータマートの構築の使用を促進し、履歴レポートと未来的なレポートをサポートします。 セルフサービスアーキテクチャー:この種のプログラムは、スチュワードとデータプレパレーションの課題を考慮し、組織で頻繁に発生する「シャドウIT」の規範を制限するワークフローを構築することを目的としています。 それは旅であり、目的地ではない データガバナンスは、コーポレートガバナンスと同様、プロジェクトではなく継続的なプロセスであることを理解することが重要です。進行中のプロセスでは、目標を定義し、プログラムの進捗を測定する方法が必要です。このために推奨されるアプローチは、データガバナンス成熟度モデルに対して進捗状況をスキャンすることです。DGプログラム用に選択したフォーカスエリアに応じて、プログラムの成功を測定するための指標も定義する必要があります。アジャイルのプラクティスを使用することもお勧めします。継続的デリバリー、ITとビジネス間の絶え間ないコラボレーション、変化を歓迎する姿勢、テクノロジーの卓越性と優れた設計に継続的に注意を払うなどのアジャイル手法は、データガバナンスのプラクティスに完全に適合するものです。 進化 プロセスや人と同じように、テクノロジーはデータガバナンスの大きな部分を占めており、テクノロジーは常に変化しています。ビジネスであれITであれ、テクノロジーのイノベーションを受け入れることをお勧めします。機械学習、クラウド、ビッグデータの分野での新しいイノベーションにより、データガバナンスのイニシアチブが効果的になります。たとえば、Hadoopにデータレイクを構築すると、マスターデータとDWデータのストレージが安価になり、処理が高速になります。 皆さんの企業でも、データガバナンスのいずれかのイニシアチブがすでに実装されているのではないかと考えられます。それをベースとして使用し、他のフォーカスエリアを実装することをお勧めします。企業のデータガバナンスのビジョンを持ち、ビジネスとITのリーダーシップから賛同を得て、ITとビジネスのコラボレーションを改善します。これらの最初の手順を実施することにより、DGの進化を成功させ、組織に真の価値を提供できます。 参考文献: https://www.sas.com/en_us/insights/articles/data-management/what-is-a-data-governance-framework.html http://www.datagovernance.com/the-dgi-framework/ http://tdan.com/a-ten-step-plan-for-an-effective-data-governance-structure/19183 https://www.isaca.org/chapters3/Atlanta/AboutOurChapter/Documents/GW2014/Implementing%20a%20Data%20Governance%20Program%20-%20Chalker%202014.pdf http://dbhids.org/wp-content/uploads/2016/03/OCIO-DBHIDS-DG-Framework-Strategic-Plan-v1.01.pdf


IoTセンサーでの機械学習の応用

リアルタイムストリーミングIoT(モノのインターネット)のデータの分析に関するデモをすでにご覧になっている方は、ユーザーアクティビティを予測するために分類モデルをどのように訓練したのか疑問を持ったのではないでしょうか。ここでは、最初にデモの背景、そしてデータの分類方法を説明し、最後に適切なモデルの選択について検討していきます。 背景 IoTデモの目的は、Talendのリアルタイムストリーミングと機械学習の機能を実証することです。つまり、Talendは携帯電話から加速度センサーデータをリアルタイムで受信し、データをメッセージキューにプッシュし、分析のためにデータを分類するための機械学習を実行します。これはすべて、ハンドコーディングなしで実行されます。 処理側では、Talendを使用してRESTエンドポイントが作成され、そこにセンサーデータが送信されます。センサーデータは解析され、メッセージキュー(Kafka)にプッシュされます。データがメッセージキューに格納されると、Talend Big Data Streamingのジョブがスライディングウィンドウを使用してキューからメッセージを読み取り、機械学習モデルにデータを渡し、視覚化のためにデータを準備します。 データの表示 処理中のデータは、モバイルデバイスの加速度センサーから取得されます。より具体的には、X、Y、Z軸の線形加速度を処理しています。センサーデータのグラフから簡便な分析を実行するだけで、次のようなデータが表示されます。 各軸の加速度は、m/s2でグラフ化されています。アクティビティには、それぞれ低、中、高の3つのフェーズがあることを視覚的に推測できます。これを機械学習モデルに変換するために、選択したモデルがセンサーデータを低、中、高に分類できると期待します。機械学習における分類とは、観測値が属するカテゴリーを識別することを指します。Spark MLibから分類モデルを選択する演習を開始するために、一般的なモデル(ナイーブベイズ、ロジスティック回帰、ランダムフォレスト)を調べます。 モデルの選択 ナイーブベイズモデルは、一般的にテキストの分類に多く使用されます。また、ここでは10進数を扱っているため、うまく適合しません。次に、ロジスティック回帰モデルは、低、中、高のアクティビティに必要なマルチクラス分類に対応しません。最後に、ランダムフォレストモデルでは、各軸に対して分類を処理できます。さらに、ランダムフォレストモデルは大規模なデータセットでも効率的であり、数千の入力変数を処理できます。 ランダムフォレストモデルでは、トレーニングセットを取得し、ランダムサンプリングを実行してデータのサブセットまたはランダムな「木」を作成します。多くの木が作成されると、ランダムな「森」が作成されます。多くの木を持つことの利点は、データの分類をより正確に予測できることです。たとえば、森の中にある10本の木のうち7本が特定のセンサーイベントが歩行していることを示唆している場合、分類は歩行であると予想されます。 Talend Real-Time Big Data Platformには、機械学習のコンポーネントが組み込まれています。ランダムフォレストモデルを使用する最初のステップは、手作りの分類を使用して訓練することです。これは、簡便な分析からデータを取得し、アクティビティラベルを追加することを意味します。このトレーニングセットはモデルエンコーダーによって使用され、ストリーミング中のアクティビティの分類に使用されるモデルが出力されます。トレーニングセットのラベルは、人間の活動、特に休憩、歩行、およびランニングに関連付けられます。トレーニングセットは次のようになります。 このモデルの生成に使用されるトレーニングセットには、アクティビティごとに約150のイベントがありました。生成されたモデルを取得し、手作りの分類ラベルを出力と比較すると、97%の精度が得られました。これは予想どおりです。 機械学習モデルの精度を評価するために、K-分割交差検証の手法を使用して、10個の学習の演習を実行します。各演習はトレーニングセットのパーティションを取り、検証データとして使用します。この手法により、選択したモデルで95%の精度が得られました。今後のブログでは、この検証手法を検討し、Talend Studioを使用して構築する方法を紹介します。 最後のステップは、デモのストリーミング部分のモデルを使用してデータを分類することです。データを分類する前に、将来の分析のためのアーカイブ用にキャプチャーして保存することも可能です。分類されたデータは、視覚化のために準備されます。 ビデオをご覧ください: Analytics Dashboard — Talend IoT Demo. まとめ この演習の最も注目すべき点は、ハンドコーディングが不要だったことです。データを取得するRESTサービスの作成から、機械学習モデルを実装するSpark Streamingジョブまで、すべてがグラフィカルユーザー環境を使用して設計されました。デモをまだご覧になっていない場合は、Talendにご連絡ください。皆さんの次のビッグデータプロジェクトでTalendを簡単に使用する方法をご案内します。


Microsoft AzureとTalendによって完全なエンドツーエンドのCI/CDパイプラインを自動化する

Talendは、CI/CDの実装を進化させ、簡素化し続けています。このブログでは、Talend Cloud on Microsoft Azureを利用することで、どのように継続的統合(CI)およびデリバリーのパイプラインの完全な自動化、ゼロインストール、およびエンドツーエンドデリバリーを実現して、すべてのDevOpsの目標を達成できるか説明します。 これまでの経緯 Microsoft AzureでのエンドツーエンドのCI/CDパイプラインの構築について詳しく説明する前に、当社のCI/CDの歴史について説明します。Talendは、2016年夏に最初の継続的インテグレーション機能を展開しました。このとき、統合プロジェクトのデリバリーまでの時間を短縮する進化が始まったのでした。データインテグレーターは、単体テスト機能とMaven互換性標準をTalend Studioに組み合わせることで、Jenkinsなどの使い慣れたCIオーケストレーションツールを利用して、自動的なビルド、単体テスト、および成果物リポジトリへのTalendジョブのパッケージングを行えるようになりました。これは大きな第一歩ですが、継続的デリバリーの要素をすべて満足させるものではありませんでした。さらに、Jenkins内で大幅な構成が必要であるとともに、追加のソフトウェアを手動でインストールする必要がありました。 現在では、データ駆動型企業は、より多くのデータに関する知見を絶えず得ようとし、短時間での信頼性の高いデータプロセスを開発チームに求めています。このような需要の増大に対応するため、IT組織は、ダウンタイムゼロの完全なエンドツーエンドCI/CDパイプラインを含むDevOps手法を活用しています。   進化した点 TalendをCI/CDプロセスに統合することは、決して目新しいことではありません。実際、私は今年のこれまでに、Microsoft Azure DevOpsとTalendを活用してCI/CDパイプラインを構築した例について記事を書いています。ただし、Talend CI Builderサービスをホストするために、Azureプラットフォームでホステッドエージェントを構築して構成するには大変な労力が必要でした(「記事」を参照)。ほんの数か月後、TalendはゼロインストールCI機能を提供しました。この機能によって、その労力は不要になり、これまでにないほど容易にクラウドで継続的インテグレーション(CI)を実現できるようになりました。現在、Talend Cloud on Microsoft Azureの最新の機能によって、TalendのゼロインストールCI機能を利用したAzure DevOps Orchestrationエンジンと新しいネイティブクラウドサービスという2つのそれぞれの長所を組み合わせて、完全に自動化された方法で、継続的インテグレーション(CI)、継続的デプロイ、および継続的デリバリーという最終的な目標を達成できます。   技術的詳細 具体的な例について見ていきましょう。Microsoftホステッドエージェントを使用するために、ゼロインストールCI機能を活用して、AzureパイプラインにCIパイプラインを作成します。以下のステップは、エージェントの設定以外は以前の記事「TalendとAzure DevOpsを使用したCI/CDパイプラインの構築」で説明したステップと基本的に同じです。この記事では、エージェントを設定する必要はありません。Azure DevOpsプラットフォームによって提供されるエージェントを使用します。目標は、CIパイプラインを利用して、ジョブをTalend Cloudにパブリッシュすることです。 以前の記事で詳しく説明しているため、ここでは最初のステップについて詳しく扱いません。ここでは、ゼロインストールCIの使用に関する詳細についてのみ説明します。   ファイルはGitHubのこちらにあります。 1.前提条件 主に次の2つの前提条件があります。 Talend StudioおよびNexusからのサードパーティライブラリを同期してCIが機能するように、Nexusを設定する必要があります。詳細については、このページでブログの「Configure the Nexus for third-party libraries(サードパーティライブラリ向けのNexusの設定)」を参照してください。 第2の要件は、P2リポジトリと呼ばれるものをホストする必要があることです。その内容とその目的についてはこの記事で既に説明しました。ライセンス電子メールまたはTalend CloudからこのP2リポジトリをダウンロードしたら、たとえば、通常のHTTPサーバーやAzure Blob Storageでホストする必要があります。 Azure Blob Storageでホストする場合は、次の手順を確認してください。それ以外の場合は、この部分はスキップしてください。 a) Storageアカウントを作成して、静的ファイルホスティングを有効にします。   B) プライマリエンドポイントをコピーして、貼り付けます。これは、P2リポジトリを指すURLになります。$webコンテナが作成されます。解凍済みのP2リポジトリの内容をこの新しく作成したBlob Storageフォルダーにアップロードします。数秒以内に、P2リポジトリがホストされ、使用可能になります。   […]