月別: May 2017

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プログラムに変換されます。 […]


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

ビジネスアプリケーション、データ統合、マスターデータ管理、データウェアハウジング、ビッグデータデータレイク、機械学習といったものは、いずれもデータモデルが共通の基本的要素となります(または、そうあるべきです)。この点を常に念頭に置きましょう。あるいは、(よく見られることですが)完全に無視することがないように注意してください。 データモデルこそが、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 Rules of the Relational Model(リレーショナルモデルの12の規則)」を発表しました。これは、実際には規則0から規則12まであり、13の規則です。コッドは、当時のコンピューター領域で明らかに卓越した知識を持っていました。リレーショナルモデルは、「正規化」の概念ももたらし、「5つの正規形」が定義されました。現在でも「3NF」(第3正規形)について広く議論されていますが、その定義方法をご存知でしょうか。これら2つのリンクを読み進めて、自分の知識が確かなものか確認できます。最後にクイズもあります…というのは冗談です。 次に登場した画期的なデータモデリング方法論は、1996年にラルフ・キンボール(現在は引退)によって、「The Data Warehouse […]