月別: January 2017

エールフランス‐KLMグループ: データ活用が実現する「自分だけの旅」の体験

エールフランス‐KLMは、年間9,000万人が利用する航空会社グループであり、マイレージプログラム「フライング・ブルー」の会員数は2,700万人にのぼります。 ここ数年で、データの急増によって市場の競争が様変わりしました。特にソーシャルメディアが大きな影響を及ぼす中、同グループはFacebookに1,600万人のファン、Twitterに3百万人のフォロワーを抱えています。 好きなように旅する 多くの航空会社が同じ路線に就航している状況においては、サービスのレベルが重要な差別化要因となります。顧客が航空会社に求めているのは、「飛行機で運ばれる」ことではなく、「好きなように旅する」ことです。 エールフランス‐KLMの最大の課題は、全ての顧客情報をグループ会社全体で共有できるように再集中化することでした。 そこで実装されたのが、Hadoopを使用して社内開発されたビッグデータプラットフォームです。 データ管理でのTalendの活用 360°のカスタマービュー実現を目指すエールフランス‐KLMグループは、そのためのデータプラットフォームを編成してデータ管理の課題に対応するために、Talendを導入しました。 データ品質を検証するための完全なデータ品質ポリシーを実装するうえで使用したのは、Talend Data Qualityです。 このツールを使用すると、毎月最大100万件のデータエントリーを修正できます。 処理対象データには顧客の個人情報が含まれ、データ保護が必須であるため、データセキュリティも課題となっていました。データマスキングは、データ分析のために顧客データを部分的に匿名化する処理です。 さらにエールフランス‐KLMは、Talend Metadata Managerを実装することで、グループ内で情報を共有し、これによってデータの場所、送信元、送信先の判断にかかる時間が従来の1/10倍まで短縮されました。 卓越した旅の体験を提供する360°のカスタマービュー 私たちの目標は、データを活用して、お客様のご旅行の全行程を、安心できる旅としてご提供することです」と、最高顧客データ責任者のGauthier Le Masne氏は説明します。 「たとえば、位置情報を使用して、お客様の自宅から空港までの所要時間を通知します。 お客様が空港に到着されたときに搭乗ゲートが変更されていれば、変更された搭乗ゲートをFacebook Messengerで自動的に通知します。」 顧客がエールフランス‐KLMを利用する都度、目的地や嗜好の履歴が学習され、そのデータから、興味のありそうな次の旅行先を選んでそのフライト情報を案内することもできます。 Gauthier Le Masne氏は、次のように結びます。「 当グループは、それぞれのお客様との体系的なやりとりを目指しています。そのためには、我々のチームと、お客様が使用されているタブレットとの間での対面的なやりとりが必要になります。もしお客様がスマートフォンアプリケーションを使用されているなら、お客様への直接の連絡も必要です。 アプリケーションを使用していないお客様とは、ソーシャルメディア経由でつながる必要もあります。」 目標は、新しいデータプラットフォームで数千万人の顧客に、それぞれの旅を提供することです。エールフランスKLM社は如何にしてカスタマーの360°ビューを実現したか (JP) from Talend on Vimeo.


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 each Row(行ごとに再ロード – キャッシュ)– ソースレコードごとに該当する行を読み込み、キャッシュに格納します ソースとの結合を目的にメモリにロードされたルックアップデータは、非常に高速です。ただし、メモリに制限があってルックアップデータを大量に読み込めない場合や、すべてのロックアップデータのロードが必要ないユースケースでは、「Reload at each […]