注目の投稿

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

詳細情報
注目の投稿

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

詳細情報
注目の投稿

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

詳細情報
注目の投稿

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

詳細情報
注目の投稿

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

詳細情報

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

| 2017年5月5日 | Database Integration Developer Step-by-Step ETL / ELT

ビジネスアプリケーション、データ統合、マスターデータ管理、データウェアハウジング、ビッグデータデータレイク、機械学習といったものは、いずれもデータモデルが共通の基本的要素となります(または、そうあるべきです)。この点を常に念頭に置きましょう。あるいは、(よく見られることですが)完全に無視することがないように注意してください。 データモデルこそが、Eコマースから、PoS、財務、製品、顧客管理、ビジネスインテリジェンス、IoTまで、Talendの高価値でミッションクリティカルのビジネスソリューションのほとんどすべての支柱です。適切なデータモデルがなければ、ビジネスデータはおそらく失われてしまうでしょう! Talendのジョブ設計パターンとベストプラクティスについて取り上げたブログシリーズ(第1部、第2部、第3部、第4部)では、32のベストプラクティスを紹介し、Talendでジョブを構築する最善の方法について述べました。その中で予告したデータモデリングについて、以下に述べたいと思います。 データモデルとデータモデリングの方法論は、ずっと以前(コンピューティングが始まった頃)からありました。構造は、データが意味を成すために必要であり、コンピューターが実際に処理するうえでの一手段を提供します。確かに、今日では非構造化データや半構造化データも処理されるようになっています。しかし、それは単に、一層洗練された規範へとデータ処理が進化したことを意味するだけではないでしょうか。したがって、データモデルの意義は現在も変わるものではなく、高度なビジネスアプリケーションを構築するための基盤となっています。Talendのベストプラクティスと同様、データモデルとデータモデリングの手法にも真剣に向き合う必要があります。 ダウンロード >> Talend Open Studio for Data Integration 新たな洞察を得るべく、データモデリングの歴史を振り返ってみましょう。 データモデルの進化 「コンピューティングの暗黒時代」には、フラットなレコードのレイアウト(配列)が使用され、すべてのデータは後で取得できるようにテープや大規模ディスクドライブに保存されていました。しかし、1958年に、J. W. YoungとH. K. Kentが、情報システムのモデリングは「データ処理の問題の情報的かつ時間的特徴を規定するための正確で抽象的な方法」であると論じました。その後すぐに(1959年)、CODASYL(Conference/Committee on Data Systems Languages)というコンソーシアムがミネソタ大学のチャールズ・バベッジ研究所により結成されました。これを契機として、COBOLのような標準プログラミング言語が作成され、1960年代にはGE/Honeywell社でIntegrated Data Store(IDS)という初期のデータベーステクノロジーがチャールズ・バックマンによって設計されました。IDSは使いにくいものであったため、Integrated Database Management System(IDMS)がB. F. Goodrich(米国のタイヤメーカーですが、当時は航空宇宙製造企業)により開発され、Cullinane Database Systemsにより販売されました(現在はComputer Associatesが所有)。これら2つのデータモデリングの方法論は、それぞれ「階層型データモデル」と「ネットワーク型データモデル」と呼ばれ、50年にわたってメインフレームコンピューティングで広く使用されてきました。現在でも使用しているケースがあります。 1960年代末、当時IBM社の社員だったエドガー・F・コッドは、クリス・J・デイト(『An Introduction to Database Systems』の著者)と協力し、自身の革新的なデータモデリング理論を確立して、1970年に「A Relational Model of Data for Large Shared Data Banks(大規模共有データバンクのデータ関係モデル)」という論文を発表しました。コッドは、ベンダーが方法論を正しく実装できるよう推進するため、1985に有名な「Twelve …

Read Article

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

| 2017年2月8日 | Cloud Integration Developer Step-by-Step Integrations / Connectors

  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 …

Read Article

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

| 2017年2月1日 | Data Migration Database Integration Developer Step-by-Step ビッグデータ統合

ビッグデータの分野では、従来のデータウェアハウスを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 …

Read Article

Talendのジョブ設計パターンとベストプラクティス(第4部)

  Talendのジョブ設計とベストプラクティスという取り組みは、新たな岐路にさしかかっています。役立つコンテンツの提供という私の努力は、1つの形になりました。好評をいただいているブログシリーズ(まだお読みになっていない方は、第1部、第2部、第3部をぜひご覧ください)、Technical Boot Campプレゼンテーション(参加いただいた方、ありがとうございます)、コンテンツの直接配信から、社内から組織の変革を求める声が生まれています。 この記事では引き続き、ジョブ設計パターンとベストプラクティスについて解説を進めます。まず、シンプルでありながら見逃されがちな事実をお伝えしましょう。それは、Talendは、Javaコードジェネレーターであり、開発者ガイドラインを確立することで、ジョブ設計パターンによって生成されるJavaコードを強化および合理化できる、という点です。これは明白な事実ですが、この概念に基づいてキャンバスを操作し、緻密なジョブ設計を行ってクリーンなJavaコードを生成することが、最善の結果への近道です。私はこれを、「成功主導のプロジェクト」と呼んでいます。 成功主導のTalendプロジェクト Talendジョブの作成は、非常に簡単な場合と、非常に複雑な場合があります。実装を成功へと導く秘訣は、良い習慣と必要な規範を採用し、適合させることにあります。 このシリーズの冒頭で「基本的指針」でお伝えしたように、私の目標は、ベストプラクティスに関する自由なディスカッションを行い、便利なジョブ設計パターンを確立することにあります。ジョブ設計および親子オーケストレーションは、ほとんどのユースケースにメリットをもたらします。そして、再利用可能なコードを含めることで、プロジェクト全体の成功が加速されます。もちろん、どの方法を選択するかは皆さんの自由ですが、一貫性の維持だけは必ず留意してください。 データベース開発ライフサイクル(DDLC) このシリーズではジョブ設計のみを扱ってきましたが、データについてはどうでしょうか。ジョブで処理するのはデータであり、ほとんどのデータはデータベースに格納されています。データベースにベストプラクティスは必要でしょうか。これは、修辞的な質問でしょうか。データモデル(スキーマ)は時間と共に変化しますから、データベース設計にもライフサイクルがあるのは当然です。 データベースは進化するので、開発者はこれに対応しなければなりません。われわれはSDLCプロセスを採用していますから、データベース開発ライフサイクルの必要性も簡単に理解できるはずです。環境(DEV/TEST/PROD)がどうであれ、データベースのサポートは必要です。 新規インストール – スキーマの現在のバージョンに基づきます アップグレード – アップグレードによりデータベースオブジェクトを削除/作成/変更します データ移行 – 破壊的な「アップグレード」(テーブルの分割など)を行います データベースライフサイクルと、それがジョブ設計にもたらす影響を理解することは、非常に重要です。ここで鍵となるのが、データベースモデルのバージョン管理です。規定された設計プロセスに従い、設計をグラフィック化し、「データ辞書」または「グロッサリー」を作成して変更履歴を追跡します。このトピックについては、ブログの別の記事でさらに詳しく解説する予定ですので、お楽しみに。それまでは、データベースモデルを作成する際には次のプロセスを検討してください。高度な規範ではありますが、効果的です。   さらなるジョブ設計のベストプラクティス では、すぐに役立つジョブ設計のパターンとベストプラクティスをさらにご紹介しましょう。よく使用するTalend機能やあまり使用頻度の高くない機能を詳しく解説します。ぜひ参考にしてください。 さらに検討すべき8つのベストプラクティス: tMapルックアップ ご存知のように、tMapの必須コンポーネントは強力な変換機能を備えているため、Tatlendジョブで広く使用されています。 tMapコンポーネントの最も一般的な用途は、ソース入力からターゲット出力へのデータフロースキーマのマッピングです。これは、シンプルな処理です。ソースとターゲットに複数のスキーマデータフローを使用することもできるため、データフローの複雑な結合や分割にも対応できます。また、変換式を使用すれば、どの入力データをどのような方法でダウンストリームに分割するかを制御できます。tMapコンポーネント内の式は、ソースとターゲットのスキーマに適用できます。また、tMapコンポーネントで定義した変数を使用することも可能です。以上の操作方法は、「Talend Components Reference Guide」で詳しく解説されています。使用する際には、「大いなる力には大きな責任が伴う」ことを念頭に置いてください。 tMapコンポーネントには、ソースデータフローと結合するルックアップを使用するという素晴らしい用途もあります。tMapコンポーネントに適用できるルックアップに物理的な上限はありませんが、実際には配慮すべき項目があります。 この基本的な例をご覧ください。ソースとルックアップという2つの行が生成されます。実行時には、まずルックアップデータが生成され、次にソースデータが処理されます。 ルックアップデータの結合が[Load Once]に設定されているため、レコードすべてがメモリにロードされ、ソースデータの結果セットに対して処理が行われます。これはデフォルト設定であり、結合で優れたパフォーマンスを発揮でき、非常に効率的です。 また、数百万のルックアップ行と数十のカラムをロードする場合には、かなりのメモリ容量が必要になります。数百万行のルックアップを複数回実行する場合はどうでしょうか。メモリ容量はどの程度必要でしょうか。レコード数が多い場合やカラム数が数百にのぼる場合には、ルックアップを慎重に検討してください。 では、メモリとパフォーマンスのトレードオフについて考えてみましょう。ルックアップには、3つのモデルがあります。 Load Once(一括ロード)– 該当するすべてのレコードをメモリに読み込みます Reload at each Row(行ごとに再ロード)– ソースレコードごとに該当する行を読み込みます Reload at …

Read Article

センサー、環境、モノのインターネット(IoT)

Jacob Morgan氏は、「インターネットに接続可能なすべてのものは、今後接続されるようになる」と述べています。「クラウド」と「ビッグデータ」は一時期、単なる流行語だと見なされていました。しかし今では、この2つの主要なテクノロジーが、世界中のあらゆる業界のビジネスに劇的な影響を与えていることを目の当たりにしています。そして多くの人が今、「同じことがIoTにも当てはまるのか」と考えています。個人的には、世界を一変させる影響力を持つトレンドやテクノロジーを一時的な盛り上がりだと捉えるべきではないと考えています。 2006年、私はRFIDの使用に関する研究調査を行っており、自動データ整理機能とリマインダーテクノロジーを使用して、雑然としたオフィス文書を整理する方法を紹介しました。このトピックに関しては、「Document Tracking and Collaboration Support using RFID(RFIDを使用した文書追跡とコラボレーションサポート)」と題した論文を発行しました。私が初めてセンサーとのやり取りを経験したこの研究で、私と共同研究者はM2M(マシンツーマシン)に、その後はコラボレーション環境との統合に焦点を合わせました。そして、SoT(Subnet of Things)の研究へとつながっていきました。スマートホーム、スマートカー、スマートシティなど当時誕生したアイデアが、現在では実現しつつあります。IDCの推測では、2020年までに280億台のセンサーが使用され、その経済的価値は1.7兆ドルになるとされています。応用シナリオをご紹介する前に、センサー通信のスコープとその3つのカテゴリについて概説します。 M2M マシンツーマシンは、スコープとドメインの点でIoTとは異なります。通常、この2つは可用性が制限されており、データに基づいて運用上の規定が事前に定義されています。わかりやすい例として、製造ユニットと内蔵されているさまざまなセンサーとの通信を挙げることができます。身近な例では、自動車に搭載されたその車専用の暖房センサーがあります。 SoT SoT(Subnets of Things)は、組織レベルまたはエンタープライズレベルにスコープを設定できます。ファイルごとや書籍ごとにRFIDが存在する上記の例のように、SoTもコラボレーションプラットフォームを使用して組織内に配置が可能です。たとえば、自動車はデータを送信してコンポーネントの品質と稼働状況を測定し、より良い操作と安定した運転を提供します。 IoT 2013年、IoT-GSI(Global Standards Initiative on Internet of Things)は、IoTを「情報社会のインフラストラクチャ」と定義しました。IoT(モノのインターネット)とは、一意の識別子が付与され、人対人または人対コンピューターの対話を必要とせずにネットワーク上でデータを転送できるコンピューティングデバイス、機械、デジタルマシン、オブジェクト、動物、または人が相互に関連するシステムです。IoTは、無線技術、MEMS(Micro-Electromechanical System:微小電気機械システム)、マイクロサービス、そしてインターネットの融合によって進化してきました。 センサーのデータ型とネットワークの課題 サンフランシスコに出張した際、SAPのIoT研究開発リーダーにお会いし、私たちの日常生活がビッグデータによってどのように変化しているのかという非常に興味深いお話を伺いました。たとえば、航空機システムでは数千台のセンサーがデータを送信しており、小数点以下8桁から16桁までの計算を数分の1秒でする必要があるとのことです。センサーのおかげで膨大なデータが利用可能となった今、リアルタイムのビッグデータインサイトを活用する能力のある企業の成長を阻害する要因は、現行のテクノロジーインフラストラクチャだけです。 IT部門の意思決定者は、インフラストラクチャを構築し、ネットワークを利用できなかったために保持されていたデータの処理が可能なソリューションを活用する必要があります。通信ネットワークが整っていないことや、信号妨害などが原因で接続できないこともあるため、ITリーダーはネットワークが利用可能になりデータを転送できるようになるまでの間、データを保持し続けられるインフラストラクチャを構築しなければなりません。 センサーデータには、さまざまなソースからのデータと同様に、クレンジング、分析、およびガバナンスが必要です。それに加えて、特徴的な性質ももっています。通常、センサーデータは時間と対置される情報(値)のストリームです。すべてのデータに意味があるわけではありませんが、収集時にその価値が不明であったとしても、すべてのデータには必ず価値が生まれるため、データを破棄することはできません。したがって、データ圧縮の際に厳密ではないアルゴリズムや疑わしいアルゴリズムを使用しないでください。次のような方法を用いることで、このような状況を克服できる可能性があります。 必要な場合に限り、フィルタリングされたデータを送信する 異常値のみを送信する 根拠のない/テストされていないアルゴリズムを使用せずにデータを圧縮する IoT研究者は、さらに次のように述べています。「この瞬間もここでは大量のデータが生成されています。何らかのイベントが起きた場合や、コンポーネントに障害が発生した場合も、それ以前に生成されたデータは非常に重要です。なぜなら、これは完全なエコシステムだからです。データを失えば、今後同様のイベントを予測することはできなくなります。したがって、コストを抑えるには、可逆圧縮を使用してデータを圧縮するという選択肢しかありません(唯一の選択肢は、コストが高すぎます)。データが重複していたり、データ頻度が高すぎたりする場合、多くのオーバーヘッドが発生しますが、やはりバックエンドシステムが受信したすべての情報を処理できてしかるべきです。センサーレベルで高速フーリエ変換などの曲線適合法を適用すれば、集計値を得ることができます。センサーデータは、データレイクと呼ばれる低コストのスケールアウトシステムに保管するのが最も適しています。生データは、その価値が証明されていないため、通常はデータウェアハウスに保存されませんが、セキュリティなどの明確なガバナンスが必要です」 センサーが日常生活に与える影響 センサーは私たちの生活のほぼあらゆる面に影響を与えています。人感センサーから製造ユニットまで、あらゆるものが日々スマートになっています。近い将来私たちに影響を与えるIoTの基本的な例をいくつか見ていきましょう。 スマートマニュファクチャリング 製造業は年間12兆ドル規模の世界的産業です。ロボットがある場所から別の場所に商品を移動し、自動車部品工場や組立ラインで稼働している金属プレス機の全動作はセンサーによって追跡されます。工業生産業とも呼ばれるこのセクターは、すでに著しい成長率を示しています。さまざまなプロセスから収集されたデータは、予定外のダウンタイムを防止するためにも、売上予測に基づいて供給ニーズを予測するためにも役立ちます。 スマートトランスポート 自動車業界の統合は、家電にとって新たなフロンティアだともてはやされています。Gartner社の予測によれば、無人自動車は2030年までに熟年市場の乗用車の約25%を占めるようになります。無人自動車は、レガシーデザインを継承したハンドルを「マシンオーバーライド」の目的のためだけに装備していますが、最終的に手動での制御はなくなるでしょう。ブレーキ、速度計などのインジケーター、加速などの従来の制御はすべて、センサー、レーダー、GPSマッピング、およびさまざまなAI(人工知能)に基づいて行われるようになり、自動運転、駐車、事故を回避する最も安全なルート選びが実現します。この素晴らしいテクノロジーは、車の制御だけでなく、道路状況や車両との関係に基づいた路上で他の車との通信にも重点を置いています。外部ネットワークを必要とする通信は、ルート計算、車両の状態、eコール、および保険やデータのバックアップに基づくbコールの使用など、インターネットベースサービスを可能にします。 スマートエネルギー 送電網が稼働を開始したのは1890年代ですが、当時は非常に集約型で隔離されていました。その後、送電網は拡張され、発電所は技術的な停止(バックアップとリカバリー)に備えて負荷シフトテクノロジーとつながりました。風車や太陽エネルギーのような小型発電ユニットの多くは現在、状況に応じてさまざまな容量の発電を行っています。今日では家庭でも発電が行われていることもあり、送電網が対応する電源は以前よりも増えています。そのため、送電網にプレッシャーがかかっているだけでなく、集約型のシステムの管理が困難になっています。 主要な電力会社は、システムの状態に基づいて、現時点で最も安価な電力源を決定し、不要な発電とコストを回避するために石炭または燃料ベースの電力源を停止できます。同様に、スマートメーターが導入されている現在、使用量に基づいて顧客に課金していますが、将来的に接続先が増えれば、これらのセンサーは最も安価な電力源を判断できるようになる可能性があります。 スマートホームとスマートシティ スマートシティは、非常に興味深いIoTの応用例です。スマートホームとスマートシティは相互に接続しています。スマートシティはコミュニケーションのための優れたインフラストラクチャを提供し、メリットをもたらすことが期待されています。すでにプロジェクトが進行しているシカゴ、リオデジャネイロ、ストックホルムでは、政府が民間企業と共同でIoTを活用して、路上に設置した資産(街灯など)からデータを収集し、修理の必要性を判断しています。スクールバスの監視からゴミの収集まで、IoTは社会の機能のしかたを変えています。 「スマートホーム」とは、相互通信が可能で、家のどの部屋からでも、また電話やインターネットを使って世界中のどこからでもタイムスケジュールに基づいて制御可能な、家電、照明、暖房、エアコン、テレビ、コンピューター、エンターテインメントオーディオ/ビデオシステム、セキュリティ、およびカメラシステムを備えた住居を示す用語です。次世代のスマートホームは、冷蔵庫の在庫管理を行うようになり、在庫が少なくなったと判断すると牛乳や卵を自動発注できます。あるいは、電気、水道、さらにはネットワーク接続の中断を認識して、サービス提供者に修理を要請するようになります。また、スマートゴミ箱はいっぱいになると、ゴミ収集車に自動的に通知するようになります。 一言でまとめるならば、データ駆動型の現在の社会は「スマートシステム」にシフトしつつあります。現在のインフラストラクチャは、データの生成、取り込みから分析にいたるまで、困難な課題を克服する力を与えてくれました。上記のスマートシナリオに加えて、GPSチップなどの個人用身体センサー、健康/活動モニターによって生活水準は向上しています。今後数か月から数年の間に、IoTは急成長することが予測されます。 …

Read Article

過去10年の成長を振り返って

  創業10周年とIPOの成功を祝う機会に恵まれた今、Talendの豊かな歴史を振り返り、クラウド及びビッグデータソフトウェアの世界的リーダーとしての地位確立に尽力した人々に敬意を表したいと思います。 語りつくされた感があることですが、Talendの成功は、本質的には当社に加わって現在でも「ファミリー」の一員として活躍している多くの人々の貢献によるものです。 Talendは、経営陣の選択にとどまらず、投資家、経営陣、そして当然のことながら顧客、パートナー、従業員から絶大な支持を得ています。 初期:独自のアプローチ Talendがフランスで創業した当時、データ統合のグローバル市場は大きな岐路に立っていました。 データをめぐっては、複雑さ、量、統合が必要な種類、さらには企業の多様なニーズ(特に分析に関して)に劇的な変化が起こっていました。 Talendのプラットフォームを開発し始めた当初の私たちには、情報管理が企業情報システムの要となることに疑問の余地はないという直感がありました。 SAP、IBM、Oracle等の従来のモノリシックなITソリューションに対応する中で、ビジネスユーザーの統合のニーズはますます厳しくなり、具体化していくであろうと理解したのです。 かし、これらのベンダーが提案するソリューションは手頃な価格のものになっていくどころか、ますますコストがかかり、配備が難しくなっていきました。 独占的で排他的なアプローチを開発している既存大手ベンダーとの競合に直面したTalendは、確立された秩序、主流の技術、ビジネスモデル、市場ポジションを切り崩すことにに投資しました。 当時の習わしとは対照的に、Talendはオープンソース、そして集中型ではなく分散型のアーキテクチャーを採用する道を選択しました。また、データ量やCPU使用率ではなく、ユーザー数に基づいて価格体系を採用しました。このように、Talendは当初からローカルではなくグローバルのアプローチをとってきたのです。今考えると、これらの選択の妥当性は明らかです。しかし、Red HatとSalesforce.comが市場のイノベーターとして登場してきた2005年当時、状況は違っていました。 T Talendはビジョンの正当性を確信していましたが、このアプローチの評価と支援で大きな役割を果たしたのが、最初の投資家であるGalileo Partners社のRégis Saleur氏とAGF Private Equity社(現在のIdInvest社)のJean-François Galloüin氏でした。市場の慣習(私の知る限り、現在のように財務的支援を受けるオープンソースベンダーは当時は存在しませんでした)に逆らう形で取引成立に尽力した両氏の当時の支援は、Talendの長期的成功に欠かせないものとなりました。 初期の投資家からの支援とともに、顧客もTalend創業当初に決定的な役割を果たしました。 Citibankのリテールバンキング業務を担うCiti社をはじめとする重要顧客は、 Hadoopによってかつてない量のデータを処理できるようになった分析分野に大きなチャンスを見出しました。 Citi社との経験は貴重なものであり、HadoopのリーダーとしてのTalendの評価を確立するきっかけとなりました。 成熟、そしてさらなる(持続的な)選択肢の拡大 2006年10月に最初のソリューションを投入した後、ダウンロードの大部分が米国からのものであることを認識したTalendは、この地域で成長に勢いをつける絶好の機会であると考えました。 従来のテクノロジー企業が販売の見込み客を増やすために販促に予算を投じる必要があるのに対して、Talend等のオープンソース企業は無料オープンソース版や試用版を提供することで見込み客を獲得します。 もちろん、ダウンロードの見込み客を得るという商業的な機会にとどまらず、支援のエコシステムを形成するうえでも、シリコンバレーに拠点をかまえることが必要でした。 このため、2008年までにシリコンバレーに最初のオフィスを開設したことには、単なる資金調達手段としてではなく、企業戦略の核心をさらに推進させる意図がありました。 会社の成長に伴い、協働する能力を持つ最高の人材を採用することに努めました。 私たちの大きな要求に呼応するように、従業員も尊敬、野心、個人の卓越性に基づく力強い企業文化、人格、環境を持つこの企業に加わりました。 そして現在も、Talendが最初に採用した開発者15名は社内で活躍しています。 将来採用する従業員についても、これまでと同様にスキルだけではなくマインドセットも重視していきます。このやり方が成果を上げていることは実装済みです。 人的要素を重視する姿勢は、前述したように投資家の選択にも、そして取締役会のメンバーの選択にも反映されています。 これらの役割に対しても、Talendは最高の人材を求めました。 Business Objects社を創業したBernard Liautaud氏は、フランスで設立した会社を米国で大きく発展させるという経緯を持ち、このモデルに明確かつ独自に適合しています。 さらに、Ascential Software社の創業者であり、この市場で大きな影響力を持つPeter Gyenes氏をはじめとして、強力な人々の支援を受けました。 このような人材の多様性は、経営、課題、野望の複雑さを生む一方で、Talendの躍進(平均して毎年約2倍の勢いで成長)も可能にしました。 さらにTalendは、ビッグデータがもたらした技術革新の重要性を直ちに「感知」しました。数年前にTalendが策定した計画は、ビッグデータの市場機会が遅かれ早かれ現実のものとなるという予測を考慮するものでした。 ApacheのようなパートナーとTalendにとって、ビッグデータの台頭は特に重要な動きであり、. 今後の展望 後悔はないかとよく尋ねられますが、 最初に思い浮かぶ返答は「No」です。どのような革新的な企業でも同じでしょうが、間違いがなかったわけでは当然ありません。 そのような失敗がなければ一層順調に成長できたであろうことは確かですが、 代わりにTalendは間違いを謙虚に認めて直ちに軌道修正することを選択しました。 …

Read Article

ビッグデータガバナンスとメタデータ管理を成功させるためのTalendの5本の柱

| 2016年10月10日 | Data Management / Data Governance Hadoop MDM / Metadata ビッグデータ統合

  本シリーズの前回の記事では、データガバナンスによりビッグデータイニシアティブを持続可能な成功に導くための6つの鍵を検討しました。 これらの6つのステップは、TDWIが最近発表した「Governing Big Data and Hadoop(ビッグデータの管理とHadoop)」というレポートで明らかにされたものです。 このレポートは、独立した立場から課題とベストプラクティスについて取り上げていますが、Talendによる課題への具体的な取り組みについては明記していません。シリーズ第2回となるこの記事では、前回述べた6つの重要課題に対して、Talend Data Fabricの統一プラットフォームを構成する各主要コンポーネントがどのように対処できるかについて説明します。これを、メタデータ管理のためのTalendの5本柱と呼びます。 Talend Studioで設計するメタデータ メタデータがなければ、情報サプライチェーンの包括的で活用可能なビューを作成する方法はありません。 メタデータがなければ、情報サプライチェーンの包括的で活用可能なビューを作成する方法はありません。 メタデータは、場合によっては遡ってエンジニアリングすることもできますが、作成後のメタデータを即座にソースで収集、処理、保守、追跡する方がはるかに簡単です。 Talendを使用する場合、データフローはビジュアルなメタデータ駆動型環境で設計されます。 これによって、開発と展開が加速するだけではありません。データフローが実行されると、情報サプライチェーンの詳細なビュー(データの元の場所、保存場所、データポイント間の依存関係)が提供されます。 Map ReduceやSpark等の多くの強力なデータ処理環境は、SQL等の従来のデータ管理標準と違ってメタデータ駆動型ではないため、これはビッグデータの領域では非常に重要です。 Talend Open Studioのような高レベルの抽象化を提供し、ゼロコーディングアプローチを採用しているツールがなければ、Hadoopのデータ駆動型プロセスの管理、ガバナンス、保護は非常に難しくなります。 Talend Open Studioとその集中リポジトリは、常に最新のバージョンのデータフローを維持してデータ設計者や開発者の間で共有し、Cloudera Navigator、Apache Atlas、Talend Metadata Manager等の他のツールにエクスポートして、より広範なデータワーカーに公開できます。この最後の点に関する詳細は後述します。 さらにTalendは、開発者がデータ管理の全ての分野(データ統合、ビッグデータ統合、アプリケーション統合、クラウド統合、データクオリティ及びMDM、セルフサービス型データプレパレーション)を単一プラットフォームで使用することを可能にしています。これによってIT部門は、オンプレミスまたはクラウドの従来のデータとビッグデータの両方で、保存データと実行データの両方についてデータフローのグローバルビューを提供できます。 Talend Metadata Bridgeを使用してデータプラットフォーム全体でメタデータを同期する Talend Metadata Bridgeを使用すると、開発者はTalend Studio(及び、同様にTalend Metadata Manager)からメタデータをインポート及びエクスポートすることができ、ほぼ全てのデータプラットフォームのメタデータにアクセスできます。 100以上のコネクターが用意されているTalend Metadata Bridgeは、モデリングツール(Erwin、Embarcadero等)、ETLツール(Informatica、IBM DataStage等)、SQL及びNoSQLデータベース、Hadoop、人気の高いBI及びデータ検出ツール(Tableau、Qlik、BusinessObjects等、XMLまたはCobol構造等)からメタデータを取得するのに役立ちます。 これらのブリッジにより、開発者は一度設計したデータ構造を、さまざまなツールやプラットフォームにわたって繰り返し伝播させることができます。 これにより、ほとんどのサードパーティツールやプラットフォームからTalendにデータ形式を変換できるため、標準仕様を容易に適用し、変更を伝播させ、移行を容易にすることができます。 たとえば、Oracleテーブルを使用してTalendにインポートし、それをRedshift等の別のサードパーティプラットフォームに伝播させることが可能です。Talend Big Dataは、従来のETLジョブをネイティブのHadoopプロセスに簡単にオフロードできます。 Talend Big DataによりHadoopのガバナンスの課題に対応する Hadoopは、データの拡散を加速するよう設計されています。 また、データ、データ操作、及び関連メタデータの単一の参照ポイントとなる従来のデータベースとは異なり、Hadoopは複数のストレージ及びデータ処理オプションを組み合わせています。 さらに、高可用性戦略の一環として、Hadoopは多くのノードにわたってデータを複製し、処理ステップ間に生データの中間コピーを作成するうえで役立ちます。 …

Read Article

データガバナンスとメタデータ管理によりHadoopの道のりを切り開く6つのステップ

  この記事は、ビッグデータとHadoopの管理に焦点を当てた2部構成シリーズの第1回です。 データ駆動の旅に出発する準備ができていますか。 ビジネスケースとプロジェクトの青写真が明確に定義され、デジタルの変革に向けて経営幹部の支援もすでに取り付けています。 Hadoopに基づく最新のデータプラットフォームを実行する準備も整い、チームはビッグデータの明るい展望を組織内でより広く提供するためにスタート台についています。 しかし、まったく新しい挑戦を想像して躊躇しています。ビッグデータのスピードに対応する準備はできていますか。データレイクのデータの拡散から必然的に生じるリスクを制御する準備はできていますか。現在は少数のデータサイエンティストだけがアクセス可能なデータラボを、誰でもアクセスでき、重要なビジネスプロセスにシームレスに接続する、広く共有されるセルフサービス型のセンターオブエクセレンス(CoE)に拡張する準備はできていますか。 好むと好まざるとにかかわらず、セキュリティ、文書化、監査、トレーサビリティに関してエンタープライズが抱える従来の課題に対処しない限りは、取り組みを成功させる準備が整っているとは言えません。その一方で、ビジネス上の大きなメリットをもたらすための最新の方法として、データガバナンスによりHadoopイニシアチブを活用できるという朗報があります。 多様な新しいビッグデータの管理における6つ緊急課題への対応 Hadoopのデータガバナンスに関連する潜在的な利点とベストプラクティスを完全に理解するためにTalendが委託したTDWIのレポートでは、ビッグデータプロジェクトの成功を保証するための6つの柱が明らかにされています。 1.  データを危険にさらすことなく、幅広いユーザーにビッグデータのアクセシビリティを提供する。 セルフサービス型のアプローチとツールにより、ITリーダーは、データワーカーやアナリストが自律的に独自のデータプロビジョニングを実行できるように推進できます。しかし、このサービスを管理された拡張性の高い方法で提供するガバナンスの枠組みを最初に構築することなく、データ準備ツールをビジネスユーザーに引き渡すことは適切ではありません。 2.  スマートな発見と探索によりデータの取り込みを加速する。既存のデータプラットフォームを使用して新しいデータセットをオンボードし、適切なオーディエンスに公開するには、数週間、場合によっては数か月かかります。 現在、新しい「スキーマオンリード」のアプローチにより、ITとデータの専門家はデータのオンボードをデータ到着時に実行できます。 これが完了すると、すぐにデータワーカーのコミュニティ全体がデータに即時にアクセスできるようになり、いつでも臨機応変にデータの発見、モデリング、接続、調整を柔軟に実行できます。 3.  これが完了すると、すぐにデータワーカーのコミュニティ全体がデータに即時にアクセスできるようになり、いつでも臨機応変にデータの発見、モデリング、接続、調整を柔軟に実行できます。メタデータは、データ駆動型アプリケーションの重要要素であり、文書を埋め込むことでデータアクセシビリティを高め、生データにコンテキストを組み合わせて解釈を強化し、異種データポイント間を接続してデータから意味と知見を引き出します。 さらに、情報サプライチェーン全体の制御とトレーサビリティを実現します。現代のデータプラットフォームは、メタデータのキャプチャー、ステッチ、クラウドソース、及びキュレーションの新しい方法を提供します。 4.  データ管理の分野を共通のプラットフォームに統合する。 サイロはエンタープライズデータの価値を破壊し、品質とセキュリティの両方のリスクをもたらします。 T多様な統合形式にわたって一元的な制御とアクセスを確立しながら、データユーザーの責任を分散する必要があります。 5.  Hadoopの柔軟性を検討する一方で、ガバナンスの課題に注意する。 Hadoopは、より大規模で多様なデータをより迅速に処理して、より俊敏な方法でより多くのユーザーに配信できます。 しかし、極端に大規模、高速、広範囲での運用が可能になった現在、データのトレーサビリティと監査性、保護、文書化、ポリシー適用等を習得する必要があります。これらの課題に完全に対応するため、メタデータ駆動型プラットフォームと併せてApache AtlasやCloudera Navigatorのような環境を検討する必要があります。 6.  変化、継続的なイノベーション、多様性に対する準備を整える。ITシステムは、モノリシックからマルチプラットフォームへと進化しています。SQLデータベースはもはや、データのモデリング、保存、リンク、処理、アクセスの全てに対応する環境ではありません。   SQLデータベースはもはや、データのモデリング、保存、リンク、処理、アクセスの全てに対応する環境ではありません。 このシリーズの第2回では、Talend Big Data、Metadata Manager、Talend Data Preparation、及びTalend Data Fabricを使用して、Talendがどのようにこれらの課題に取り組むかをご案内します。

Read Article

Talendのジョブ設計パターンとベストプラクティス(第3部)

| 2016年10月5日 | Developer Step-by-Step ETL / ELT

このトピックに関する前回のブログ記事は大変好評だったようです。熱心な読者の皆様、ありがとうございます。 過去のブログ記事をまだ読んでいない方は、まずはこちら(Talendのジョブ設計パターンとベストプラクティス第1部と第2部)をお読みください。それぞれ異なるテーマを取り上げています。 ジョブ設計パターンとベストプラクティスの解説を始める前に、お知らせがあります。これまでのコンテンツを90分のテクニカルプレゼンテーションにまとめました。このプレゼンテーションは、「Talend Technical Boot Camps」にて、世界中で視聴いただけます。地域のイベントスケジュールは、TalendのWebサイトでご確認ください。プレゼンテーションでお会いできることを楽しみにしています。 このシリーズの内容について、コメント、質問、論点をお寄せください。ディスカッションを膨らませ、Talendコミュニティで展開できれば、と思います。「標準」ではなく「ガイドライン」であることを思い出してください。どうか、ご意見をお寄せいただき、ご協力をお願いいたします。 テーマを深める Talendプロジェクトをはじめとするソフトウェアライフサイクルを成功へと導くには、「開発者のガイドライン」の確立が不可欠であることを理解いただけたと思います。では、次に進みましょう。開発者のガイドラインの確立、チームによる採用、規律の段階的な浸透は、Talendで極めて大きな成功を収めるための鍵である、という点を解説します。これに、異論を唱える人はいないでしょう。Talendジョブの作成には、複雑な手順が必要です(ここでは詳しい説明はしません)。したがって、「ビジネスユースケース」、「テクノロジー」、「手法」を理解することによって、成功の確率が高くなります。時間をかけて、チームのガイドラインを作成することには十分な価値がありますし、成果があるはずです。 Talendユーザーが取り組んでいるユースケースの多くは、何らかの形でデータ統合プロセスに関連しています。データ統合はTalendのコアコンピテンシーであり、データの移動を意味します。データフローはさまざまな形態で発生するため、処理や操作の方法が重要になります。その重要性は非常に大きく、作成するあらゆるジョブの本質であるとも言えます。ビジネスデータの移動というユースケースにおいてTalendをテクノロジースタックの不可欠な要素として使用する場合、どのような手法を使用すればよいでしょうか。それはもちろん、これまでに解説したSDLCベストプラクティスなのですが、それだけではありません。データに関連する手法ですから、データモデリングも含まれます。これは、私の専門分野でもあります。私は、25年以上にわたるデータベースアーキテクトという経験の中で、数え切れないほどのデータベースソリューションの設計と構築に携わってきました。ですから、データベースシステムにもライフサイクルがあることを実感しています。フラットファイル、EDI、OLTP、OLAP、STAR、Snowflake、データボルトといったスキーマを問わず、データとそのスキーマが生成され、廃棄に至るまでのプロセスを無視することは、チームにとって弱点になり、最悪の場合は大惨事につながるのです。 このブログではデータモデリング手法は扱いませんが、適切なデータ構造設計を採用し、それに沿って使用することが非常に重要です。ぜひデータボルトのシリーズの記事をお読みいただき、今後掲載予定のデータモデリングの記事もご覧ください。現時点では、DDLC(Data Development Life Cycle)はベストプラクティスです。このことについて考えていただければ、私の意図を後で理解できるでしょう。 さらなるジョブ設計のベストプラクティス では、Talendのジョブ設計について、「ベストプラクティス」をさらにいくつかご紹介します。ここまでで、16のベストプラクティスを解説しました。あと8つあるのでお楽しみに(このシリーズには第4部があります。すべてを盛り込むことはできないので、記事を読みやすく分割しています)。 さらに検討すべき8つのベストプラクティス コードルーチン 状況によって、Talendコンポーネントではプログラミングのニーズを満たせない場合があります。それでも問題はありません。TalendはJavaコードジェネレーターです。キャンバスに配置し、プロセスやデータフローで使用できるPure Javaコンポーネントもあります。それでもニーズに対応できない場合があるはずです。そのようなときには、コードルーチンが役立ちます。これは、プロジェクトリポジトリに追加可能なJavaメソッドです。基本的に、ユーザー定義のJava関数であり、ジョブ内のさまざまな場所で使用できます。 Talendは数多くのJava関数を備えています。すでに使用されていると思います。 getCurrentDate – sequence(String seqName, int startValue, int step) – ISNULL(object variable) ジョブ、プロジェクト、ユースケースの全体像を考えた場合、コードルーチンにはさまざまな用途があります。ここで基本となるのは、再利用可能なコードです。それには、汎用な方法でジョブを合理化できるコードルーチンを作成することを、常に念頭に置く必要があります。適切なコメントを指定すれば、関数を選択する際に役立つテキストとして表示されます。 リポジトリスキーマ プロジェクトリポジトリのMetadataセクションでは、再利用可能なオブジェクトを作成することが可能です。これは、重要な開発ガイドラインですね。リポジトリスキーマは、ジョブで再利用可能なオブジェクトを作成する強力な手法です。以下が含まれます。 – ファイルスキーマ – さまざまなフラットファイル形式のマッピングに使用します。 Delimited Positional RegEx XML Excel JSON – 汎用スキーマ …

Read Article