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

TalendがThe Forrester Wave™: Enterprise Data Fabric.Q2 2020でリーダーの一社に選ばれたことを発表できてうれしく思います。データ統合、整合性、およびガバナンスを単一プラットフォームに結合する、Talendのデータ管理への統合アプローチは、データの明確さと確実性を実現するための最善の方法です。2015年にTalend Data Fabricを発表して以来、当社は、データ統合と管理は、静的なサイロ化したエンタープライズソフトウェアソリューションでは解決できないと強く感じています。企業とデータユーザーは、柔軟で、ニーズと共に拡大でき、組織全体が使用してそこから利益を得るのに十分統合されたソリューションが必要です。しかし、このトピックは複雑なので、今日はこれらを少しかみ砕いてお話ししたいと思います。     Enterprise Data Fabricが解決できる課題についての、深く掘り下げた調査から始めましょう。Forresterによると、従来のデータ統合へのアプローチは、「リアルタイムで接続されたデータ、セルフサービス、および高度な自動化、スピード、およびインテリジェンスの組み合わせを必要とする新しいビジネス要件に対処できません。様々なソースからデータを収集することは比較的容易ですが、顧客、パートナー、製品、および従業員の包括的な視点を提供するために、複数のソースを使ってデータを統合、処理、整理、および変換するのに苦労する企業は多数あります。」   私たちはこれに全く同感です。カスタマー360ソリューションまたはエンドツーエンドのマーケティング活動ソリューションを構築している場合、多数のサイロ化したツールやスタンドアロンアプリケーションを使ってこれを効果的に行うことはできません。データの管理だけでなく、メタデータとプロセスを含めたプラットフォーム全体を管理するためにも、完全なエンタープライズデータファブリックが必要です。アストラゼネカ およびをはじめとする多くのお客様がこのアプローチを採用しています。規制が厳しい環境で、アストラゼネカは、データ統合と変換を中心にして活性化した成長軌道に戻るための戦略的イニシアティブを考案しました。同社はTalend Data Fabricを使って、APIによるポイントツーポイント接続の促進、データカタログによるメタデータの活用、データクオリティによるデータの信頼性向上、そしてデータパイプラインの自動化を可能にしたため、コストとリスクが大幅に軽減しました。   Talendは、データ統合とデータ管理がこれまで存在した場所ではなく、これから向かう場所に焦点を当てることで、市場リーダーとしての立場を維持できていると信じています。当社は、ビジネスに不可欠なデータの信頼性を検証するための、誰にとっても使いやすいシステムを構築しています。ビジネスを管理しているアナリティクスとシステムの間につながりを生み出して、相互牽制させ、データの品質とコンプライアンスを確実にしています。データの信用スコアでは、データクオリティ、データの評判、およびユーザー定義の評価に基づいて、データの健全性と精度を瞬時に評価できます。これによって、データの関連性と信頼性を一目で評価することが可能になります。また、クラウドに焦点を絞ること(クラウドにおけるTalendのデプロイメント、およびハイブリッド環境とマルチクラウド環境のサポート)は、過去数年間にわたり、Talendが注目するもう1つの重要な領域になっています。このため、当社はオンプレミスとクラウドにおけるTalend Data Fabric –データ統合、ガバナンス、および共有のための統合プラットフォーム – の構築を続けてきました。また、徐々に機械学習ベースの機能を多数追加して、データクオリティのタスクを自動化し、データパイプラインの知能を高め、非技術系ユーザーがデータへのセルフサービスアクセスを得るのを可能にしています。 当社の見解では、Talendが短期間で、高い定評のあるEnterprise Data Fabricリーダーの一社になるのを後押ししたのは、継続的な強化と素早い変化へのこうした集中です。Talendは、「Current Offering(現行サービス)」カテゴリのレポートでベンダーの中で最高スコアを獲得し、データクオリティ、データリネージ、およびデータカタログなどの基準で、そして当社のロードマップに対しての最高スコアを獲得しました。当社は、これらの高いスコアは、Talendのビジョンとミッションの正当性を示していると信じています。つまり企業としての皆さんは、当社を利用することで、Enterprise Data Fabricの追求において成功を収めることができます。Forresterレポート全体はこちらでお読みいただけます。  

Read Article

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

| 2020年3月12日 | データインテリジェンス

  Talendのカスタマーサクセスストーリーの中で私が好きなものの1つは、国際調査報道ジャーナリスト連合(ICIJ)の例です。その理由は、ICIJがデータを使って調査ジャーナリズムに革命を起こし、パナマ文書でピューリッツァー賞を受賞し、不法な脱税により失われた何十億ドルという巨額を取り戻すのを助けたからだけではありません。この事例は、ジャーナリズム史上最大のデータリークから入手した、まったく性格の異なる不明なデータを解読してインテリジェンスを引き出すことに成功した、興味深いストーリーでもあるのです。ICIJは、Talendを始めとする革新的なデータ管理ツールを使って膨大な量のデータをレトロエンジニアリングすることで、世界的な意味を持つストーリーを暴いたのです。 これこそ、データインテリジェンスのパワーです。では、データインテリジェンスとは何なのでしょうか。IDCのStewart Bond氏は、最近の必読ブログで、データインテリジェンスを「データからのインテリジェンスではなく、データについてのインテリジェンス」と位置づけています。さらに、「 “データインテリジェンスは、事業、技術、関係、オペレーションのメタデータを活用して、データのプロファイルや分類、品質、場所、リネージ、コンテキストの透明性を高めます。 そうして、人間やプロセス、テクノロジーを、信頼性の高いデータで支援します」と述べています。 IDCは、Stewart氏の指揮の下、このようなデータインテリジェンスの概念を、データ統合およびインテリジェンスソフトウェアという分類法に基づいた市場カテゴリ、つまりデータインテリジェンスソフトウェアに結び付けているのです。 私たちは、Talend Data FabricのWinter’20リリースが、データインテリジェンスのパワーをレベルアップするものになると確信しています。だからこそ、このブログや3月18日と19日に各地で開催する一連のウェビナーで、その重要性を強調したいのです。. デジタルトランスフォーメーションにデータインテリジェンスが欠かせない理由 デジタルトランスフォーメーションの成否を決めるのは、データであり、データが売上の推進やイノベーションの加速、顧客エクスペリエンスの変革、コストとリスクの低減など、ビジネスのあらゆる面に影響を与えるということは、共通の認識になりつつあります。 しかし、ICIJのように真の変革を実現できた企業はまだわずかです。データインテリジェンスにはギャップがあります。データが膨大に増えてサイロ化されるにつれ、せっかくの活用チャンスが、必要なデータが見つからない、見つかったとしても品質が悪くて使えないというデータの混乱の中で失われてしまいがちです。つまり、ほとんどの企業は手持ちのデータが管理できていないのです。 これは同時に、効率と生産性の危機をも意味します。IDCは、データ*インテリジェンス調査の一端として、データ専門家の時間の67%がデータの検索や準備に費やされ、具体的なビジネス成果への変換に必要な洞察を生む作業には12%しか費やされていないことを示しました。 最後に、深刻なデータ人材の不足があげられます。データエンジニア、AI専門家、DevOpsエンジニア、データアナリストおよびデータ保護責任者といったデータ専門家は、2020年に全世界で最も希少で最も需要の高い人材となっています。企業は、このような人材を惹き付け、従業員のスキルアップを図るだけでなく、既存のチームの業績を伸ばす方法も見いださなければなりません。 Talend Winter’20で、データからインテリジェンスを引き出す では、Winter’20はこのような課題にどう対応しデータからインテリジェンスを引き出すためのお客様の努力を支えることができるのでしょうか。 前出のデータの混乱については、データ全体のあらゆるデータポイントから一目でデータインテリジェンスを捉えることで対処できます。新しい(多数のコネクタが導入・拡張された)Talend Data Inventoryなら、膨大な数のデータソースに接続して自動的にメタデータを抽出し、それを1か所で共有データセットとして文書化することができます。次にTalendは、データ品質プロファイリングや人気度、クラウドソーシング評価と推奨事項に基づいてデータインテリジェンススコアを自動計算します。 効率の危機は、データエンジニアリングを高速化することで克服できます。Talend Pipeline Designerには多数のスマートな新機能が導入されています。データエンジニアやシチズンデータインテグレーターは、一元化されたクラウドネイティブなアプリケーションを用いて、あらゆるデータを統合、標準化、クレンジングおよびエンリッチすることが可能になる一方、「データ品質の常時維持」により、データが消費または複製される前に品質上の問題を解消することができます。コーディングや複雑な変換が不要なため、開発やメンテナンスの生産性が向上します。それにより、データ専門家は短時間で必要なデータにアクセスでき、生産性とデータインテリジェンスを高めることができます。 さらに、Winter’20リリースでは、Talend Data Fabricプラットフォーム全般でArtificial Intelligence (AI)の使用が拡大されています。AIを駆使したマジックフィルでデータの切り口を自由に操作できるため、誰もがデータインテリジェンスを利用できるようになります。インテリジェントなデータクオリティ機能がAIループに人間を関与させることで、より速くかつ正確にデータをマッチングし、大規模なデータインテリジェンスを実現します。 今すぐData Fabricをお試しください! Winter’20は、お手持ちのデータからインテリジェンスを引き出す、Talend Data Fabricの最新版です。このブログで紹介した以外にも、何百もの新機能が搭載されています。詳しくはこちらをご覧ください。トランスフォーメーションは、ここで終わりではありません。私たちは、クラウドの威力を活用してデータ統合やデータの完全性、データインテリジェンスの継続的なイノベーションを可能とし、デジタルトランスフォーメーションに向けたあらゆる取り組みを最良な形でサポートします。Data Fabricのオンプレミスバージョン、Talend 7.3もこのリリースに含まれています。 Talend Data Fabricの大きな特徴は、イノベーションが、サイロ化された製品一式ではなくあらゆる種類のデータを一元管理できる1つのプラットフォームを通じて提供される点です。Talend Data Fabricは、データの統合、品質、ガバナンス、関係者間でのデータ共有に、統一されたアプローチをもたらします。 さらに、Talend Data FabricはiPaaSとして提供されるため、わずかな操作でお持ちのデータからインテリジェンスを引き出し、ICIJを始めとする大勢のTalendのお客様と同様に、データ活用を通じてビジネスを変革することができます。今すぐWinter’20をお試しください!

Read Article

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

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

| 2019年10月17日 | Developer Step-by-Step

クラウドへの移行 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 ではジョブを構築する手順を紹介し、質問にも答えます。お見逃しなく!

Read Article

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

| 2019年10月17日 | Data Management / Data Governance

以前のブログで、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

Read Article

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

| 2019年10月17日 | IoT Machine Learning

リアルタイムストリーミング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を簡単に使用する方法をご案内します。

Read Article

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

| 2019年10月14日 | Azure Cloud Integration

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 …

Read Article

データモデルの設計とベストプラクティス(第2部)

| 2019年5月20日 | Database Integration Developer Step-by-Step ETL / ELT ビッグデータ統合

  データモデルとは何を指すのでしょうか。毎日データモデルに接して熟知しているTalendの開発者は、以下のようにデータモデルを定義しています。 ビジネスシステムデータの構造的定義 ビジネスデータのグラフィカルな表現 ビジネスソリューションを構築するためのデータ基盤 これらはいずれも真実かもしれません。しかしあえて言うなれば、いずれも本質的な定義ではありません。それぞれ単独では、データモデルが本来実現すべき核心/目的あるいは目標に到達するものではなく、末梢的であるためです。 では、何が本当にデータモデルであると言えるのでしょうか。あれこれ思いつくものの、やはり一点に尽きるのではないでしょうか。私にとって、データモデルは、ビジネス情報システムをグラフィカルな方法で明確に特徴付けるものとして表現される構造基盤です。どう思われますか? 上記の定義と同一というわけではありませんね。この定義は、すべての要素を単一の目的に包含します。つまり、データだけでなく、構造的にビジネスのユースケースに関する情報を識別するための手段なのです。 このブログシリーズの第1部では、50年間のデータモデリングの歴史を4つの短い段落にまとめました。省いた部分もありますが、前任者から学んだ教訓と改善の結果として、データモデリングに関する私たちの知識や達成がどのように実現したのかを理解できるのではないでしょうか。今日、ほとんどの企業が要件を検証するために活用してるデータモデルには、真のビジネス価値があります。しかし、これらの企業が正しい方法を理解しているかどうかを疑問に思うことがよくあります。多くの場合、永続性のあるデータモデルに対する幻想は、とりあえずモデルが存在するという事実のみによって推定され、それが正しいかどうかは確認または検証されていないのです。 私は、データアーキテクチャーとデータベース設計の実務家として、あまりにも多くの粗悪なデータモデルを目にしてきたため、ほとんどのデータモデルには何らかの問題があると言わざるを得ません。その一方で優れたモデルも多く見てきましたが、それではデータモデルの良し悪しをどのように判断できるのでしょうか。それは重要なことなのか、データの出入りに問題がなければ十分ではないのか、と疑問に思われるかもしれません。しかし、データモデルの良し悪しは明らかに重要なのです。データモデルを基盤として/データモデルと協調して運営されるビジネスシステムを確実に成功させるためには、データモデル自体が優れたものである必要があります。データモデルはビジネスの本質です。したがって、包括的であり、非の打ちどころがなく、回復力のあるものでなければなりません。 このことから、優れたデータモデルを使用する動機は明らかです。Talend StudioのようなETL/ELTツールを使ってデータを出し入れし始めると、それが明らかになります(ほとんどの人には)。どのようなソフトウェアプロジェクトでも、データモデルは欠かすことのできない3つの技術的要素の1つです。ほかの2つの要素は、アプリケーションコードとユーザーインターフェイスです。 本シリーズの第1部では、私が設計するすべてのデータモデルで採用されているデータベース開発ライフサイクル(DDLC)の方法論を取り上げましたが、お読みいただいたでしょうか。この方法論は私にとって役立つものであり、データベース開発に本気で取り組んでいるすべてのチームはぜひとも採用すべきです。このプロセスを理解して採用することで、データモデルの実装と保守を合理化/自動化/改善できます。しかし、このプロセスについては、ほかの事柄も検討する必要あります。ビジネスに貢献する信頼性、柔軟性、正確性を備えたデータモデルを促進できる、追加のベストプラクティスをご紹介します。 データモデリングのベストプラクティス 多くのデータモデルは、モデラーが論理モデルを作成してから物理モデルを作成するプロセスによって設計されます。通常、論理モデルは実体と属性、および両者を結び付ける関係を記述して、データのビジネス目的を明確に表現します。続いて、物理モデルは論理モデルを実装します(論理モデルは、テーブル、列、データ型、索引として、簡潔なデータ整合性規則と共に実装されます)。これらの規則は、プライマリーキーと外部キー、およびデフォルト値を定義します。さらに、必要に応じて実装をサポートするために、ビュー、トリガー、ストアドプロシージャーが定義されることがあります。物理モデルは、ほとんどのホストシステム(Oracle、MS SQL Server、MySQLなど)が提供する特定の構成オプションに基づいて、ディスク上のストレージ割り当ても定義します。 納得できることですね。それにもかかわらず、私は論理モデルと概念モデルの違いをめぐる激しい議論を何度も経験してきました。多くの人は、これら2つは同じであり、どちらもビジネスデータの実体と属性を提示するものであると言います。私も同意見です!概念モデルは、データに対するビジネス上の理解(技術的な理解ではありません)についてコンテキストを提供することを目的とします。概念モデルはすべてのステークホルダーが理解できるものであり、多くの人が実体と属性に取り組んでいます。適切な概念モデルは、すべての関係者にとってビジネスデータのコミュニケーションのために最善のツールになります。統一モデリング言語(UML)の側面を使用することで、概念モデルを図解して、細かい事柄にとらわれずにシンプルに保持できます。詳細は論理モデルと物理モデルで不可欠ですが、それぞれで洗練させればよいでしょう。 一般的に多くのアプリケーションシステムを使用しているエンタープライズビジネスでは、データのモデル化で高次の懸念が生じます。概念モデル、論理モデル、物理モデルだけでは十分ではありません。そこで登場するのが、全体論的データモデル(少なくとも、私がそれを改造したモデル)です! 全体論的データモデルの目的は、企業全体でデータサイロを識別・抽象化することです。これにより、データサイロが存在する場所、必要な場所、相互に関連する場所、そして最も効果的に使用するために体系づける方法を大局的に説明します。 データモデリングプロセスの4つの階層 企業内に4タイプの異なるデータモデルが存在する可能性を考慮して、定義、理解の洗練化、および具体的な設計のために、「階層」としてトップダウン型で従うデータモデリングプロセスを次のように提案します。各レベルの主要な役割については、プロセスのどこで誰が関与したかを明確にします。 全体論的データモデル: 全体論的な層は、全社的なデータサイロの抽象的な環境を表します。このデータモデルは、広範なビジネスデータガバナンスを確立する機会を生み出し、それによって企業に固有のすべてのデータ関係に対する理解を深めることができます。それらのサイロは、社内外のアプリケーションからのデータを取り込むことを目的としています。バブルチャートを使用すると、全体論的データモデルを図解できます。以下のように設計します。 バブルチャート – データサイロ バブルチャートは、一意のデータサイロを表す単純なバブルで構成されます。2つ(2つだけ)のバブルを結ぶ線(「リンク」)は、2つの間に何らかの関係が存在することを示します。基本的には、バブルの各集合(多くの場合、放射状の「スポーク」を持つ中心の「ハブ」として示されます)は、企業全体で識別された特定のデータサイロのセットを具体化するものであり、それ以上でもそれ以下もありません。要素の詳細は以下のとおりです。 青色の実線で表されたリンクは、2つのデータサイロ間の直接的な関係を示します。赤色の破線で表されたリンクは、2つのデータサイロ間の間接的な関係を示します。緑色の点線で表されたリンクは、2つのデータサイロ間の拡張された関係を示します。これらのリンクは、複数の関係(概念層で定義)を表すことがあるため、主観的に使用します。単に関係が存在すると定義します。 バブルの周囲を、より大きいバブルが囲むことがあります。大きい方のバブルは、そのデータサイロに固有の分類を体系化するオントロジーが存在する(または存在すべきである)ことを意味します。オントロジーとその分類メタデータは、それが囲むサイロへの有意義なマッピングを提供します。これは、データを高度に検索可能にするのに大いに役立つものであり、この層で識別されるべきです。 バブルチャートは、ビジネス情報の特定の集合を定義します。その目的は、サポート対象のアプリケーション、実装または技術的詳細がない情報を識別、単純化、統合することです。全体論的データモデルのメリットは、すべてのオーディエンスが単一の包括的かつ単純化されたビューで企業データ環境を理解でき、基盤となるデータモデルをほとんど/まったく中断することなく新しいデータを識別してモデルに挿入する(後述)ための柔軟な出発点を提供できることです。 ここに示したのは、完全に定義された全体論的データモデルの図解の一例です。プリンターで大きく印刷して壁に貼り、皆で検討することで、活発で生産的な会話が生まれ、それがビジネスにとって効果的で価値ある資産になります。 概念データモデル: 概念層は、ビジネスデータ要素とそれらの関係の抽象的な定義を表します。このデータモデルは、アプリケーションの観点から企業データ環境のセマンティクスを定義し、これによって基盤となるビジネス情報の理解が深まります。UMLは、このモデルを設計するためのグラフィカルな手段となります。要素オブジェクトから成る概念データモデルは、全体論的モデルのデータサイロから抽出された情報クラスを定義します。基本的には、これを情報モデルと考えることができます。以下のように設計します。 UML情報アーキテクチャー 各要素オブジェクトは、データサイロの特定部分と、2つ(やはり2つだけ)の要素間の関係を定義する接続線(「リンク」)をカプセル化します。特定の要素項目(「特性」)は、オブジェクトの理解と目的をさらに支援するために定義され、以下のいずれかになります。 保護(値は事前に決定) パブリック(値は可変) プライベート(値の使用が制限) 直接的に相互接続された要素オブジェクトは、グレーの実線のリンクと意図的なラベルによって示される「関連付け」を持つと見なされます。これらの関連付けは、親要素に付けられた菱形により、次のいずれかの関係を表します。 単純(菱形なし) 共有(塗りつぶしのない菱形) 複合(塗りつぶされた菱形) 子要素が「ナビゲート可能」な場合は、矢印と関係基数(0.* = ゼロから多数、など)で示されます。 要素オブジェクトは、「一般化」を持つこともできます。つまり、オブジェクトのインスタンスは、特定または一意の特性や関係を持つことができます。この例では、オブジェクトは1つの親要素のサブクラスに似ており、親のすべての特性に加えて、関連する一意の特性をすべて追加的に含みます。サブクラス要素は、その名前と表現の両方で洗練化されることで、抽象化された全体論的データサイロの理解しやすい洗練化を提供します。要素オブジェクトに結合する一般化は、親オブジェクトに閉じた矢印が付いた青色の実線のリンクで示され、ラベルは不要です。 …

Read Article

『データプレパレーションに関するガートナーマーケットガイド2019』の3つの重要点

Jean-Michel Franco          2019年4月26日 ガートナーは、データプレパレーションに関するマーケットガイド2019([1])(2019 Market Guide for Data Preparation)を公表しました。マーケット黎明期の2015年、データプレパレーションが主にセルフサービスのユースケースを支援することを想定していた時代に初めて作られたガイドで、今回が第4版となります。 マジック・クアドラントと比較すると、この マーケットガイドシリーズは主に初期、成熟、または小規模なマーケットを取り上げており、ベンダー間の競争の位置づけに関する情報は少ないですが、マーケットの状況や長期的に見た市場の発展についての情報は充実しています。このような資料では、多くの人がまずベンダーのプロフィールをチェックされるかと思います(Talend Data Preparation も詳細なプロフィールと一緒に紹介されています)。このレポートが提供するリーダーシップについての思考と市場分析にもぜひ注目していただけると幸いです。 組織内でのデータプレパレーションの価値と拡張を成功させる方法について、著者のEhtisham ZaidiとSharat Menonのコメントも参考にしてください。 このレポートを調べた後に、私はデータプレパレーションという刺激的なマーケットでのお客様のニーズに対応する3つの重要な点をお伝えしたいと考えました。   データプレパレーションは、データ管理をチームスポーツへ データプレパレーションの市場が誕生したきっかけは、セルフサービス機能がトレンドになったことでした。これは、TableauやPower BIといった最新のデータディスカバリーツールを使用して権限が与えられていても、ビジネスユーザーが知見を得る前に新しいデータソースを効率よく見つける方法がなかったことから発生しました。ビジネスユーザーはIT部門に頼るか、ガバナンスの十分ではない方法でMicrosoft Excelなどのツールを使用してデータをサイロ化するしかありませんでした。データプレパレーションツールはこうした生産性の面での課題に対応するものでした。 レポートによると、データ専門家やビジネスアナリストは、データから実際に知見を引き出せるようにするために、データの検索や保護の準備に業務時間の80%を費やしています。データプレパレーションは、より多くの関係者がデータ統合やデータ品質管理を利用できるようにすることによって、このような状況を改善するために登場したのです。これは21世紀初頭では大きな課題でしたが、それ以降、データ関連業務はより規模の大きなゲームになっていきました。個人の生産性の問題ではなくなり、データ駆動型の知見の活用に向けた企業文化の育成も重要になってきています。 ガートナーのマーケットガイドは、このような動向に焦点をあて強調したことにあります。手法やツールが完成しつつある現在、データプレパレーションを社内とIT部門の誰もが連携してデータを活用できるチームスポーツにすることが主な課題になっています。結果として、もっとも重要なことは運用です。 ビジネスユーザー、ビジネスアナリスト、データサイエンティストやデータエンジニアが別々にその場しのぎで行っていることを集約し、生産時に十分にガバナンスされた方法で繰り返し実行できる、社内全体で活用できる資産にする必要があります。 最終的にこのアプローチは、データ統合、データ分析やビジネスインテリジェンス、データサイエンス、データウェアハウス構築、データ品質管理といった会社全体での取り組みに役立ちます。   スマートな人にはスマートなツールを…逆もまたしかり ガートナーのマーケットレポートでは、データカタロギング、パターン認識、スキーマオンリード、機械学習といった最新鋭のテクノロジーがツールに組み込まれていることも強調しています。 これによってスキルの低いユーザーでもデータを使って複雑な活動ができるようになり、一方でデータ変換、統合、照合や復旧は、それらが繰り返し作業になった時点で自動化できるようになりました。 さらに興味深いのは、ガートナーがこうしたテクノロジーのイノベーションを市場の収束に結び付けているということです。レポートでは次のような予測が書かれています。 「2024年までには、機械学習によって強化されたデータプレパレーション、データカタログ、データ統一化およびデータ品質管理ツールは、統合された最新のエンタープライズ情報管理プラットフォームにまとめられるだろう」。 実際、データプレパレーションを特定のビジネスユーザーを対象にした単独の規律であると考えるのは思い違いといえるでしょう。むしろ、潜在的にはあらゆる人が作業に関与できるようにする機能が整っていることから、情報管理における革新的テクノロジーとみなすべきです。革新的なテクノロジーを活用し、企業は新しい共同作業を通じてデータバリューチェーンを組織することができます。 Talendでは「コラボレーション型データ管理」と呼び、このマーケットガイドでのガートナーを含む一部のアナリストはDataOpsとして言及している手法です。 データ品質管理を例にとってみましょう。 多くの企業では、データ品質の対応に苦労しています。中央IT部門やCDOオフィスといった中央組織の少人数しかいないデータ品質管理の専門家に頼りすぎるアプローチをとっているためです。こうした専門家は、データ品質プロファイリングの調整や復旧では重要な役割を果たしますが、社内で最もデータを熟知しているというわけではありません。データの取得源に近いところで働いている同僚に、データクリーニング作業の一部を依頼する必要があります。こうした人々が手軽なデータプレパレーションツールを使えると、データ品質管理の効率は非常に高くなります。   ハイブリッドクラウドの価値 ガートナーはまた、革新的なPaaS(Platform as a Service)デプロイメントモデルを通じて提供されるデータプレパレーションに対する顧客の需要の高まりを把握しています。ガートナーが強調するのは、基本的なSaaSを超えるはるかに洗練されたデプロイメントモデルが必要であるということです。 レポートでは「企業が必要としているのは、事前にデータを移動させなくても、もっとも意義のある場所でデータプレパレーションを行うことができるような柔軟性が必要である」と説明しています。 …

Read Article

TalendでCI/CDとコンテナー型仮想化を使用してサーバーレスアーキテクチャに移行する

| 2018年8月13日 | Cloud Integration Containers

CI/CDとコンテナーの重要性 CI/CD(継続的インテグレーション・デリバリー・デプロイ)は、ソフトウェアプロジェクトを成功させるための重要な要素であり、プロジェクトを進めるうえで明らかにメリットがあります。既に、コンテナーは現在あらゆる場所で使用され、開発者から絶大な人気を博しています。CI/CDを使用するユーザーは、構築しているアプリケーションを自動的かつ継続的にテスト/検証できるので、アプリケーションの品質を確かなものにします。一方で、コンテナーは、企業が採用する標準的な手順に基づき、一度構築すれば「どこにでも」デプロイできるので、ソフトウェアの配布と実行をより俊敏に行えます。このような一般的なDevOpsプラクティスにより、「特定のマシンしか動作しない」という状況は、回避されます。結果として、サービスを市場投入するまでの時間が短縮されるとともに、デリバリーの頻度を高めることができます。 Talendのシステム環境へどのように適応できるか? Talendでは、CI/CDとコンテナーの両方のメリットを利用できます。Talend 7.0のリリース以降では、標準的なMavenビルドにより、Dockerイメージ内でTalendジョブをビルドできるようになりました。そして、このプロセスをCI/CDのパイプラインにスムーズに接続できます。 サーバーレスアーキテクチャとは? 最後の段階で活用されるのはサーバーレスアーキテクチャです。Talendでは、サーバーレスでジョブがデプロイされます。実際に、ジョブをコンテナー内で送ることによって、統合ジョブを任意の場所に自由にデプロイできるようになりました。様々な選択において、サーバーレスとして定義される新しいサービスのカテゴリーが登場しています。AWS FargateやAzure Container Instancesなど、ほとんどの大手クラウドプロバイダーはコンテナー用のサーバーレスサービスの提供を開始しています。これらのサービスを利用すると、コンテナーを実行する際にインフラストラクチャ(サーバーやクラスター)を管理する必要がなくなります。発生するコストはコンテナーの使用料だけです。 これらの新しい機能は、Talend Connect US 2018の基調講演で紹介され、AWS FargateやAzure ACIでジョブのビルドから実行までのパイプライン全体のデモンストレーションを使用して解説されました。このブログでは、Jenkinsを利用してCI/CDパイプラインを作成する方法について説明します。最初にDockerイメージ内でジョブをビルドし、Dockerレジストリでイメージを利用できるようにします。そしてAWS FargateやAzure ACIを呼び出してイメージを実行します。 このプロセスを再現する方法を見ていきましょう。 まず、次の要件を満たしていることを確認して下さい。 Talend Studio 7.0 以降 Talend Cloud Spring 18’ 以降 Jenkinsサーバーを利用できること Jenkinsサーバーが、同じマシンにインストールされたDockerデーモンにアクセスできること Talend CommandLineがJenkinsのマシンにインストールされていること Nexus version 2 または 3 Talend CI BuilderがTalend CommandLineと共に構成されていること * 上記のTalendコンポーネントは全て、Talend Cloudの30日間の試用版で利用できます。 Talend環境 Talendを初めて使用する方向けに、各コンポーネントの概要について説明します。Talend Cloudから使用を開始し、Talend …

Read Article