月別: January 2017

ビッグデータ活用の第1歩を踏み出すには

ビッグデータ活用の第1歩を踏み出すには 全世界のデータ量が2年ごとに倍増している背景で大きな原動力となっているのは、ソーシャルメディアに続くトレンドとなっているIoT(モノのインターネット)です。[1] 同時に、データ処理の速度と能力はますます重要になってきています。これは、食料品と似て、一定の期間が経過するとデータの妥当性が失われてしまうためです。 さらに現在では、多様化する構造化データ、非構造化データ、半構造化データ(画像、テキスト、ビデオ、音声等)の取得及び分析が容易になりつつあります。 ビッグデータは、量、速度、多様性という3つの主要要素で定義されます。[2] この3つの要素を制御できる企業は、データを活用して大きな価値を引き出すことができ、デジタルの成熟度が劣る企業と比較すると、より大きな成功を実現していくでしょう。[3] 包括的なデータ取得戦略を成功させて競合他社との差別化を図ることに成功している企業があります。例えば、Amazon社、Netflix社、Uber社等がその一例としてあげられるでしょう。 ビッグデータ技術に向けた適切なプラットフォームを構築することも、その戦略の一環として必要です。 O’Reillyのレポート、「The Big Data Market 2016」[4] によると、大企業(従業員数5,000人以上)は中堅中小企業に比べてはるかに迅速にHadoopやSpark等のビッグデータ技術を導入しています。 しかし、中小規模の組織が今日の最新データプラットフォームを活用して「デジタルリーダー」になるチャンスも多くあります。 Cloudera社によると、Hadoopのエコシステムが成熟することで、コスト削減を達成できるだけでなく、より戦略的なデータ利用による新たなビジネスチャンスが生まれる可能性もあります。ビッグデータは、顧客に対する理解を深め、製品やサービスを改善し、より効果的なプロセスを実現し、品質保証の改善と問題検出の強化によってリスクを低減するために主に活用されます。[5] 順調なスタートを切るために ビッグデータプロジェクトを開始するのは難しいと思われがちです。 日々の業務でビッグデータ技術を何となく検討してはいるものの、具体的なプロジェクトを開始するまでには至っていない中規模の企業を多数目にしています(ドイツ語圏の市場での話です)。では、ビッグデータプロジェクトを開始する最善の方法とは何でしょうか。 経験から言って、一般的に最も成功するアプローチは、実際のビジネスに関連した明確に定義された小さなプロジェクトプランを作成し、そこから始めることです。当社の顧客の多くは、新しいデータソースから得られる、増加を続けるデータを保存するという課題に直面しています。 多くは機械からのデータであり、ソーシャルメディアデータも時に含まれます。原則的には、データをリレーショナルデータベースに格納することも、既存のデータウェアハウスに格納することも可能です。 しかし、それではコストが高くなるため、代替案を検討する必要があります。つまり、それら従来の方法は、現在では適切であるとは言えないのです。 小さなプロジェクトは、ビッグデータ技術の使用経験を積むために効果的と考えるのが一般的です。 リスクを回避しながら新しい技術を初めて使用するうえでは、比較的小さく、管理しやすく、隔離されたプロジェクトが基本的には適しています。 Volume(量)、Velocity(速度)、Variety(多様性)という3つのVが全て完全に満たされるかどうかは、重要ではありません。一方で、制御可能な適切かつ妥当なビッグデータのユースケースを使用し、成否を判断するための基準を設け、パイロットから本番稼働環境に迅速に移行できるようにすることが重要です。[6] 仮に、充分に実績のある技術を使用してビッグデータプロジェクトに対応できるとしても、新しいビッグデータ技術を試してみる機会があれば、それを逃すべきではありません。新しい技術を制御しやすい規模で試しておかなければ、より大規模で複雑なプロジェクトに対処できないという事態に陥りかねません。 ビッグデータ技術はすでに成熟し、利用しやすいものであるため、ビッグデータプロジェクトのアーキテクチャーも通常は対処しやすいものです。データストレージには、Hadoopディストリビューションが使用されます。 データは、最初にソースで収集され、場合によっては変換され(ビッグデータについては変換せずに生データを保存することが推奨されます)、その後でHadoopにロードされます。 Talend Big Data Platformは、このようなモデルに基づいて実装するために必要な、全ての機能を提供します。これによって生成される高性能なネイティブコードを使用して、チームは短期間でApache Hadoop、Apache Spark、Spark Streaming、及びNoSQL技術を活用できるようになります 最終的に、データは生データレベルに対して直接、または前処理済みデータが格納されたデータマートを経由して検証されるのが一般的です。続いて、データマートへのデータ格納はTalendによって行われます評価には現在適切なツールを使用していればそれを利用することもできますが、データの可視化、発見、及び高度分析等の新しいツールを導入する良い機会でもあります。 開始、拡大、そして機会創出 ビッグデータと従来型データウェアハウスの関連性は高まりつつあります。 理論的には、Hadoop等のビッグデータ技術を活用して、データウェアハウス全体を近代化することが可能です。これによって、多くの場合は大幅なコスト削減を実現しながら、新しいチャンスを創出できます。 一方で、時間をかけて従来のデータウェアハウスにビッグデータの領域を統合することも可能です。 Oビッグデータインフラストラクチャを構築した後は、Hadoopとデータウェアハウスを簡単にリンクできます(どちらの方向も可能です)。 データウェアハウスは、Hadoopに格納されているデータのソースとして機能します。  同様に、Hadoopからデータを読み取って変換し、最終的にデータウェアハウスに格納することもできます。 これら2つの領域を相互に隔離する必要はなく、統合することで最終的にはビッグデータ技術に基づくデータウェアハウスを実現できます。 千里の道も、常に最初の一歩から始まります。 ビッグデータ技術は成熟し、利用しやすくなりました。しかし、何事にも当てはまることですが、具体的に動かなければ前進もありません。 したがって、そのようなプロジェクトを積極的に見つけることをお勧めします。 実際に第1歩を踏み出して技術を調査し、インフラストラクチャを構築できれば、そこで生まれる新しいチャンスからすぐに利益がもたらされます。これによって、データ駆動型企業に有利な現代の環境で、競争力を維持していくことができます。 References [1] https://www.emc.com/leadership/digital-universe/2014iview/executive-summary.htm [2] https://en.wikipedia.org/wiki/Big_data [3] https://www.idc.com/getdoc.jsp?containerId=prAP40943216 [4] https://www.oreilly.com/ideas/the-big-data-market [5] http://www.cloudera.com/content/dam/www/marketing/resources/whitepapers/the-business-value-of-an-enterprise-data-hub.pdf.landing.html [6] http://www.gartner.com/newsroom/id/3466117 [7] https://talend.com/products/big-data About the author Dr. Gero […]


エールフランス‐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 […]