金融セクター企業における興味深いビッグデータ実装の事例の概要

ビッグデータのケーススタディ

金融セクターの企業で

なぜこの記事ですか？



このレビューでは、「ライブ」プロジェクトの例を使用して、実生活でのビッグデータの実装とアプリケーションのケースについて説明します。 いくつかの、特に興味深い、あらゆる意味で、私はあえてコメントを述べます。



レビュー対象のケースの範囲は、Cloudera Webサイトで公開されている例に限定されています 。

ビッグデータとは？

テクニカルサークルでは、ビッグデータは強力なラップトップ上のExcel 2010では不十分なデータであるというジョークがあります。 つまり、シートあたり100万行以上、または16,000列以上で操作する必要がある問題を解決する場合、おめでとうございます。データは「Big」のカテゴリに属します。



より多くの厳格な定義の中で、たとえば、以下を提供します。「ビッグデータ」-従来の処理ツールを使用できないほど膨大で複雑なデータセット。 この用語は通常、予測分析の方法またはデータから値を抽出する他の方法が適用されるデータを特徴づけ、データの量とのみ相関することはめったにありません。



ウィキペディアの定義：ビッグデータとは、2000年代後半に登場し、従来のデータベース管理システムに代わる水平スケール（英語のスケールアウト）ソフトウェアツールによって効果的に処理される、膨大な量と非常に多様な構造化および非構造化データの指定ですビジネスインテリジェンスデータとソリューション。



ビッグデータ分析



つまり、データの効果を得るためには、データから貴重な情報、できれば予測プロパティを処理、分析、抽出する必要があります（つまり、将来を予測して予測しようとします）。



データまたは単に「ビッグデータ分析」からの貴重な情報の分析と抽出は、分析モデルを通じて実装されます。



モデルの品質または利用可能なデータの依存関係を識別する品質は、特定のモデルが機能するデータまたは「学習する」データの量と多様性によって大きく決定されます。



ビッグデータインフラストラクチャ。 データの保存と処理のための技術プラットフォーム



例外を無視する場合、Big Data Analyticsの基本的なルールは、データが多様になるほど、モデルの品質が向上することです。 量は品質になります。 大量のデータを保存および処理するための技術的能力の向上という問題は、深刻な問題です。 対応するパワーは、コンピューティングクラスタとGPUグラフィックアクセラレータの組み合わせによって提供されます。



ビッグデータインフラストラクチャ。 データの収集と準備



ViktorMayer-Schönberger著の本「ビッグデータ：生き方、働き方、考え方を変える革命」によれば、ビッグデータプロジェクトに関わるすべての労働の80％までがインフラストラクチャタスクに費やされ、技術プラットフォーム、プラットフォーム、コレクション、トランスフォーメーションを提供していますデータ、データ品質管理。 そして、わずか20％-分析自体、モデリング、機械学習に直接。

金融セクター企業のビッグデータのケーススタディ

1.大陸間取引所（ICE）、

ニューヨーク証券取引所（NYSE）-取引所

ケースリンク

会社へのリンク



会社概要



ICE-先物、株式、オプションを取引するための最大のプラットフォームを提供し、清算とデータサービスを提供します。 ナイセ



プロジェクトトピック： ＃インフラストラクチャ、＃コンプライアンス、＃データ管理。



プロジェクト目標：



取引所はその業務の過程で膨大なデータセットを生成します。このデータの使用は、市場と顧客の増え続ける需要を最適化して満たすために重要です。 既存のDataLakeインフラストラクチャが新規および既存のデータのタイムリーな処理を許可しなかった時期が来ると、データ分離（データサイロ）の問題が発生しました。



プロジェクトの結果によると：



更新されたテクノロジープラットフォーム（Cloudera Enterprise DataHub）は、内部および外部のユーザーが20ペタバイトを超えるリアルタイムデータ（毎日30テラバイトが追加される）にアクセスできるようにします。これにより、市場の状況を監視し、そのメンバーの取引ルールのコンプライアンスを監視するプロセスを改善します（コンプライアンス）。 レガシーデータベースはApache Impala CDH製品に置き換えられ、データサブスクライバーがDataLakeのコンテンツを分析できるようになりました。



コメント：



ケースのテーマは興味深いものであり、間違いなく需要があります。 多くのサイトは、運用分析を必要とするリアルタイムのデータストリームを生成します。

ケースはもっぱらインフラストラクチャーであり、分析については語られていません。 ケースの説明では、プロジェクトのタイミング、新技術への切り替えの難しさについては何も述べていません。 一般に、詳細を調べて参加者を知ることは興味深いでしょう。

2. Cartao Elo-ブラジルのプラスチックカードの製造および保守会社

ケースリンク

会社へのリンク



会社概要：



Cartao Eloは、ブラジルで発行されたすべてのプラスチック支払いカードの11％を所有し、1日あたり100万件を超える取引を行っている会社です。



プロジェクトテーマ： ＃インフラストラクチャ、＃マーケティング、＃ビジネス開発。



プロジェクト目標：



同社は、顧客との関係をパーソナライズされたオファーのレベルにするという目標を設定しています。 追加の製品やサービスを提供するために、短期間で顧客の希望を予測することさえできます。 モバイルデバイスからの顧客の位置に関する地理位置情報データ、気象データ、交通渋滞、ソーシャルネットワーク、支払いカードの取引履歴、店舗やレストランのマーケティングキャンペーンなどのソースからのリアルタイムデータを処理できる分析プラットフォームが必要です。



プロジェクトの結果によると：



同社は、ClouderaプラットフォームにDataLakeを導入しました。これは、トランザクションデータに加えて、ソーシャルネットワーク、顧客のモバイルデバイスの地理的位置、天候、交通渋滞からの「非構造化」情報を保存します。 DataLakeは7 TBの情報を保存し、最大10 GBが毎日追加されます。 パーソナライズされた製品オファーが顧客に提供されます。



コメント：



個人向け製品の提供は、特にロシアの金融サービス市場で大きな需要があるトピックであり、多くが開発中です。 プロジェクトがどのようにリアルタイムモードでトランザクションデータ（およびソーシャルネットワークとジオロケーション）の処理を保証したかは不明です。 メイントランザクションアカウンティングシステムからのデータは即座にDataLakeに到達するはずです。その場合、彼らはそれについて控えめに黙っていますが、その量とカードデータ保護の要件を考えると、これは非常に困難です。 また、「ビッグデータ倫理」のトピックは公開されていません。製品が提供されると、この提案に基づいて、彼は「フォロー」されていると理解し、単に刺激から製品を直観的に拒否します。 そして、それはクレジットカードを完全に変えるかもしれません。 結論として、トランザクションデータの95％、ソーシャルネットワークデータの5％などがDataLakeに格納されている可能性があります。 これらのデータモデルに基づいて構築されます。 私は個人的にはリアルタイムの製品提供を信じていません。

3.銀行マンディリ。 インドネシア最大の銀行

ケースリンク

会社へのリンク

会社概要：



バンクマンディリはインドネシア最大の銀行です。



プロジェクトテーマ： ＃インフラストラクチャ、＃マーケティング、＃ビジネス開発。



プロジェクト目標：



顧客向けのデータに基づいてパーソナライズされた製品オファーを形成する技術ソリューションを導入することにより、競争上の優位性を実現します。 実装の結果に基づいて、ITインフラストラクチャの全体的なコストを削減します。



プロジェクトの結果によると：



ケースに書かれているように、データ駆動型分析ソリューションClouderaの実装後、ITインフラストラクチャのコストは99％削減されました！..顧客はターゲットを絞った製品オファーを受け取り、クロスセルおよびアップセルの販売キャンペーンの結果を改善します。 よりターゲットを絞ったモデリングにより、キャンペーン費用が大幅に削減されます。 ソリューションのビッグデータスケールは13テラバイトです。



コメント：



実装の結果に応じて、同社は製品提供をモデル化するためのリレーショナルデータベースのインフラストラクチャを完全に放棄したことを示唆しているように思えます。 ITコストを最大99％削減しました。



技術的ソリューションのデータソースは、27のリレーショナルデータベース、顧客プロファイル、プラスチックカード上のトランザクションデータ、および（予想どおり）ソーシャルネットワークデータです。

4. MasterCard。 国際決済システム

ケースリンク

会社へのリンク



会社概要：



MasterCardは、世界210か国にある22,000の金融機関を統合する支払いシステムとしてだけでなく、サービスを取得するためのアプリケーションを検討する際に、金融機関（支払いシステムの参加者）による取引相手（取引先）の金融リスクを評価するためのデータプロバイダーとしても獲得しています。



プロジェクトトピック： ＃詐欺、＃データ管理。



プロジェクト目標：



顧客を支援するために、金融機関は、以前に支払不能であり、ID（名前、住所、またはその他の特性）を変更することにより支払いシステムに戻ろうとした取引相手を特定します。 MasterCardは、この目的のためにMATCHデータベース（高リスク商人を制御するMasterCard Alert）を作成しました。 このデータベースには、「何億もの」詐欺企業の話が含まれており、MasterCardの支払いシステムの参加者（取得者）は、MATCHデータベースに対して毎月最大100万件のクエリを実行します。



この製品の競争上の優位性は、クエリ結果の短い待ち時間の要件と、要求の対象の検出の品質によって決まります。 ボリュームの増加と履歴データの複雑化により、既存のリレーショナルDBMSは、クライアントリクエストの数と質の向上の中でこれらの要件を満たすことをやめました。



プロジェクトの結果によると：



検索アルゴリズムのロードと複雑さを動的にスケーリングおよび管理する分散データストレージおよび処理（CDH）プラットフォームが導入されました。



コメント：



このケースは興味深く、実際に需要があります。 アクセス制御とセキュリティのインフラストラクチャを確保するための重要かつ時間のかかるコンポーネントについて熟考し、言及しました。 新しいプラットフォームへの移行のタイミングについては何も言われていません。 一般的に、非常に実用的なケースです。

5. Experian。 世界で3大信用調査機関の1つ。

ケースリンク

会社へのリンク



会社概要：



Experianは、信用調査機関の3大グローバル企業（いわゆるBig Three）の1つです。 約10億人の借り手（個人および法人）の信用履歴に関する情報を保存および処理します。 米国だけで、2億3500万人の個人と2500万の法人の信用関係書類。



直接的なクレジットスコアリングサービスに加えて、同社は、組織のマーケティングサポートサービス、借り手のクレジット履歴へのオンラインアクセス、詐欺防止、個人情報の盗難を販売しています。



マーケティングサポートサービス（Experian Marketing Services、EMS）の競争上の優位性は、蓄積されたデータと物理的および法的な借り手という会社の主な資産に基づいています。 EMS。



プロジェクトテーマ： ＃インフラストラクチャ、＃マーケティング、＃ビジネス開発。



プロジェクト目標：



EMSは、蓄積された地理的、人口統計的、社会的データを使用してモデリングすることにより、マーケティング担当者がターゲットオーディエンスに独自のアクセスを獲得するのに役立ちます。 「最後に完了した購入」、「ソーシャルネットワークでのアクティビティ」などのリアルタイムデータを含むマーケティングキャンペーンをモデル化する際に、借り手に関する累積（大）データを適用するのは正しいことです。



このようなデータの蓄積と適用には、これらのさまざまなデータを迅速に処理、保存、分析できる技術的なプラットフォームが必要です。



プロジェクトの結果によると：



数か月の研究の後、プラットフォーム開発、つまり非ベースの分散データベースであるHbaseテクノロジーに基づいたCross Channel Identity Resolution（CCIR）エンジンが選択されました。 Experianは、IBM DB2、Oracle、SQL Server、Sybase IQなどの多数の社内メインフレームサーバーおよびリレーショナルDBMSからETLスクリプトを介してCCIRエンジンにデータをアップロードします。



ケースの作成時点では、50億行を超えるデータがHiveに保存されていましたが、近い将来に10倍の成長が見込まれています。



コメント：



ケースの詳細は非常に魅力的であり、非常にまれです。



-クラスターノードの数（35）、

-プロジェクトの実施条件（6か月未満）、

-ソリューションのアーキテクチャは簡潔かつ有能に提示されます。



Hadoopコンポーネント：HBase、Hive、Hue、MapReduce、Pig

クラスターサーバー：HP DL380（商品以上）

データウェアハウス：IBM DB2

データマート：Oracle、SQL Server、Sybase IQ

-負荷特性（1時間あたり1億件のレコードが処理され、生産性が500％向上します）。

PS



「忍耐強く、たくさんトレーニングする」というアドバイスは、Hadoop / Hbaseでのソリューションの産業開発に着手する前に笑顔になります。



非常によく提示されたケース！ 個別に読むことをお勧めします。 特に、主題の人々の行の間に隠されているものがたくさんあります！

6.ウエスタンユニオン。 国際送金市場のリーダー

ケースリンク

会社へのリンク



会社概要：



ウエスタンユニオンは、国際送金市場の最大のオペレーターです。 当初、同社は電信サービスを提供していました（モールス信号の発明者-サミュエル・モールスは、その設立の原点に立っていました）。



送金トランザクションの一環として、会社は送信者と受信者の両方に関するデータを受け取ります。 平均して、同社は毎秒29回の転送を行い、合計ボリュームは820億ドル（2013年のデータによる）です。



プロジェクトのテーマ： ＃インフラストラクチャ。 ＃マーケティング、＃事業開発



プロジェクト目標：



長年にわたり、同社は大量のトランザクション情報を蓄積してきました。これを使用して、製品の品質を改善し、市場での競争上の優位性を強化する予定です。



複数のソースからの構造化および非構造化データを統合および処理するためのプラットフォームを実装します（Cloudera Enterprise Data Hub）。 非構造化データには、「クリックストリームデータ」（会社のウェブサイトを開いたときのクライアントサーフィンに関するデータ）、「センチメントデータ」（自然言語処理-人間の相互作用ログの分析など）チャットボット、製品とサービスの品質に関する顧客調査（調査）、ソーシャルネットワークからのデータなど）。



プロジェクトの結果によると：



データハブは、ストリーミングダウンロード（Apache Flume）、バッチダウンロード（Apache Sqoop）、および古き良きETL（Informatica Big Data Edition）を介して作成され、構造化および非構造化データが入力されます。



データハブは顧客データの同じリポジトリであり、正確で正確な製品オファーを作成できます。たとえば、サンフランシスコでは、WUが代表者向けに個別のターゲット製品オファーを作成します。



-地元のチャイナタウン支店のクライアントのための中国文化、

-デーリーシティ地域に住んでいるフィリピンからの移民

-ミッション地区のラテン系アメリカ人とメキシコ人



たとえば、プロポーザルの送信は、これらの国家グループの米ドルに対する原産国の有利な為替レートにリンクされています。



コメント：



クラスターの特性が言及されています-100ノード（ノード-Cisco Unified Computing Systemサーバー）に増加する見込みの64ノード、データ量は100tBです。



セキュリティの確保とユーザーへのアクセスの制限（Apache SentryおよびKerberos）に特に重点が置かれています。 それは、よく考え抜かれた実装と、作業結果の実際の実用化について語っています。



一般に、プロジェクトは現在フル稼働しておらず、データの蓄積段階があり、分析モデルを開発および適用する試みもいくつかあると想定しますが、一般に、モデルの開発時に非構造化データを正しく体系的に使用する可能性は非常に誇張されています。

7.トランスアメリカ。 生命保険および資産管理グループ

ケースリンク

会社へのリンク



会社概要：



トランスアメリカは保険および投資会社のグループです。 サンフランシスコに本社を置きます。



プロジェクトトピック： ＃Infrastructure、＃Marketing、＃Business development



プロジェクト目標：



事業の多様性のため、顧客データはさまざまなグループ会社の会計システムに存在する場合があり、分析処理が複雑になる場合があります。

マーケティング分析プラットフォーム（Enterprise Marketing＆Analytics Platform、EMAP）を実装します。これは、グループ内のすべての企業からの独自のクライアントデータと、サードパーティサプライヤ（たとえば、すべて同じソーシャルネットワーク）からの顧客データの両方を保存できます。 このEPAMプラットフォームに基づいて、検証済みの製品オファリングを形成します。



プロジェクトの結果によると：



ケースで述べたように、次のデータがダウンロードされ、EPAMで分析されます。



-自分の顧客データ

-CRMの顧客データ

-過去の保険支払いに関するデータ（勧誘データ）

-サードパーティパートナーからの顧客データ（商用データ）。

-会社のインターネットポータルからのログ

-ソーシャルメディアデータ。



コメント：



-データはInformatica BDMを使用してのみダウンロードされます。これは、ソースの多様性とアーキテクチャの多様性を考えると疑わしいものです。

-「ビッグデータ」の規模は30テラバイトであり、これは非常に控えめです（特に、2億1,000万人の顧客が自由に利用できるという言及を考慮）。

-クラスターの特性、プロジェクトのタイミング、実装で発生する問題については何も言われていません。

8. mBank。 ポーランドで4番目に大きい資産銀行

会社へのリンク

ケースリンク



会社概要：



mBankは1986年に設立され、現在ではヨーロッパに500万の小売店と2万の法人顧客がいます。



プロジェクトのテーマ： ＃インフラストラクチャ、＃。



プロジェクト目標：



既存のITインフラストラクチャは、増え続けるデータ量に対応できませんでした。 データの統合と体系化の遅れにより、科学者がデータをT-1モード（つまり昨日）で処理することを余儀なくされた日付。



プロジェクトの結果によると：



Clouderaプラットフォームのインフラストラクチャ上にデータウェアハウスが構築され、さまざまなソースからの300 GBの情報で毎日満たされました。



データソース：



•フラットソースシステムファイル（主にOLTPシステム）

•Oracle DB

•IBM MQ



ストレージへのデータ統合の期間は67％減少しました。

ETLツール-Informatica



コメント：



Hadoopテクノロジーを使用して銀行の金庫を構築するまれなケースの1つ。 顧客データの正確な分析によるインフラストラクチャのTCOの大規模な削減や新しい市場の獲得について、「株主にとって」不要な表現はありません。 実生活からの実用的で信頼できる事例。