ライファイゼンバンクのビッグデータ

みなさんこんにちは！ この記事では、Raiffeisenbankのビッグデータについて説明します。 しかし、ポイントに移る前に、ビッグデータ自体の定義を明確にしたいと思います。 実際、過去数年間で、この用語は多くの文脈で使用されてきたため、用語自体の境界があいまいになり、コンテンツが失われています。 Raiffeisenbankでは、ビッグデータに関連する3つの領域を特定しました。







（このスキームは非常にシンプルに見えますが、多くの「境界線」のケースがあることに注意してください。発生した場合は、専門家の評価に頼って、入ってくる問題を解決するためにビッグデータテクノロジーが必要かどうか、またはソリューションを省くことができるかどうかを評価します。 「クラシック」RDBMSテクノロジーに基づいています）。



この記事のフレームワークでは、主に使用されるテクノロジーと、それらの助けを借りて開発されたソリューションに焦点を当てます。



最初に、テクノロジーへの関心の前提条件についてのいくつかの言葉。 ビッグデータが開始されるまでに、銀行にはデータを操作するためのいくつかのソリューションがありました。

• データウェアハウス（DWH、エンタープライズデータウェアハウス）
• 運用データストア（ODS、運用データウェアハウス）

ビッグデータに目を向けた理由は何ですか？

IT部門では普遍的なソリューションが期待されていました。これにより、銀行が利用できるすべてのデータを可能な限り効率的に分析して、デジタル製品を作成し、カスタマーエクスペリエンスを向上させることができました。



当時、DWHとODSにはいくつかの制限があり、これらのソリューションをすべてのデータを分析するための汎用ツールとして開発することはできませんでした。

1. DWHの厳しいデータ品質要件は、リポジトリ内のデータの関連性に大きく影響します（データは翌日分析に利用できます）。
2. ODSの履歴データの不足（定義による）。
3. ODSおよびDWHでリレーショナルDBMSを使用すると、構造化データのみを操作できます。 DWH / ODS（書き込み時スキーマ）への書き込み中にデータモデルを定義する必要があるため、追加の開発コストが必要になります。
4. 水平スケーリングソリューションの欠如、制限された垂直スケーリング。

これらの制限に気付いたとき、ビッグデータ技術に目を向けることにしました。 その瞬間、この分野のコンピテンシーが将来的に競争上の優位性を提供することは明らかだったので、内部の専門知識を増やす必要がありました。 当時、世銀には実用的な能力がなかったため、実際には2つの選択肢がありました。



-または（外部から）市場からチームを編成します。

-または、実際の拡張なしで、内部移行を通じて愛好家を見つけます。



2番目のオプションを選択したのは、 彼は私たちにもっと保守的に見えた。



さらに、ビッグデータは単なるツールであり、このツールで特定の問題を解決するための多くのオプションがあることを理解するようになりました。 解決する問題には、次の要件があります。

1. さまざまな形式や形式のデータを一緒に分析できる必要があります。
2. フラットな決定論的レポートからエキゾチックな視覚化や予測分析に至るまで、幅広い分析上の問題を解決できる必要があります。
3. 大量のデータとそれらをオンラインで分析する必要性との間で妥協点を見つける必要があります。
4. （理想的には）多数の従業員からの要求に対応できる、無制限のスケーラブルなソリューションが必要です。

文献を研究し、フォーラムを読み、入手可能な情報に精通した後、これらの要件を満たすソリューションが、確立されたアーキテクチャテンプレートの形ですでに存在し、「データレイク」と呼ばれることがわかりました。 Data Lakeの実装を決定した後、管理レポート、運用統合、予測分析など、データに関連するタスクを解決できる自給自足のエコシステム「DWH + ODS + Data Lake」の取得を目指しました。



Data Lakeのバージョンは、入力データが2つのレイヤーに分割される典型的なラムダアーキテクチャを実装しています。







-主にストリーミングデータが処理され、データボリュームが小さく、変換は最小限ですが、イベントの発生と分析システムでの表示間の最小遅延が達成される「速度」層。 データ処理には、Spark Streamingを使用し、結果の保存にはHbaseを使用します。



-データがバッチで処理される「バッチ」レイヤー。一度に数百万件のレコードを含めることができます（たとえば、営業日の終了結果に基づくすべてのアカウントの残高）。これには時間がかかる場合がありますが、かなり大量のデータ（スループット）。 データをHDFSのバッチレイヤーに保存し、データにアクセスするには、タスクに応じてHiveまたはSparkを使用します。



それとは別に、Sparkについて言及したいと思います。 データ処理に広く使用されており、最も重要な利点は次のとおりです。

• ETLファンドとして使用できます。
• 標準のMapReduceジョブよりも高速です。
• Hive / MapReduceと比較して、より高速なコード記述 DataFramesやSparkSQLライブラリを使用するなど、コードは冗長ではありません。
• MapReduceパラダイムよりも柔軟性が高く、より複雑な処理パイプラインをサポートします。
• PythonおよびJVM言語がサポートされています。
• 組み込みの機械学習ライブラリ。

「スキーマオンリード」アプローチを実装して、データを元の未加工の形式でデータレイクに保存しようとします 。 プロセス制御では、Oozieをタスクスケジューラとして使用します。



構造化された入力データをAVRO形式で保存します。 これには利点があります。

• データスキームはライフサイクル中に変更される可能性がありますが、これはこれらのファイルを読み取るアプリケーションのパフォーマンスを妨げることはありません。
• データスキーマはデータと共に保存されるため、個別に記述する必要はありません。
• 多くのフレームワークのネイティブサポート。

ユーザーがBIツールを使用して作業するデータマートの場合、ParquetまたはORC形式を使用する予定です。 ほとんどの場合、これにより、列のストレージが原因でデータのサンプリングが高速化されます。



アセンブリとして、HadoopはClouderaとHortonworksを検討しました。 Hortonworksが選択されたのは、その配布に独自のコンポーネントが含まれていないためです。 さらに、Hortonworksはそのままで、Sparkの2番目のバージョンとClouderaで利用可能です-1.6のみ。



Data Lakeデータを使用する分析アプリケーションの中で、2つ注意します。



1つ目は、Pythonとインストールされた機械学習ライブラリを備えたJupyterハブです。これは、データサイエンティストが予測分析とモデル構築に使用します。



2番目の役割として、現在、ユーザーがテーブル、グラフ、円グラフ、ヒストグラムなどの標準的な遡及レポートのほとんどを個別に準備できるセルフサービスBIクラスのアプリケーションを検討しています。 ITの役割は、データレイクにデータを追加し、アプリケーションとユーザーにデータへのアクセスを提供すること、そしてそれだけであることが理解されています。 ユーザーは自分で残りの作業を行うことができます。これにより、特に、関心のある質問に対する回答を見つけるための最終時間の短縮が期待されます。



結論として、これまでに達成したことをお伝えしたいと思います。

• バッチレイヤーブランチをProdに持ち込み、遡及的分析（つまり、データを使用するアナリストが「ここでどのように送信するか」という質問に答えようとします）と予測分析の両方に使用されるデータを読み込みます。 ATMでの現金引き出しと回収サービスの最適化。
• 彼らはJupyter Hubを提起し、ユーザーに最新のツール（scikit learn、XGBoost、Vowpal Wabbit）でデータを分析する機会を与えました。
• Prodで「スピードレイヤー」ブランチを積極的に開発および準備し、データレイクでリアルタイムの意思決定クラスシステムを実装しています。
• 製品バックログをコンパイルしました。その実装により、ソリューションの成熟度を最速で高めることができます。 計画中：
  
  
  
  
  1. 災害耐性。 現在、ソリューションは1つのデータセンターに展開されており、実際、サービスの継続性を保証するものではありません。また、データセンターで発生した場合、蓄積されたデータを不可逆的に失う可能性があります（この確率は小さいですが、まだ存在しています）。 問題が発生しました：組み込みのHDFSでは、異なるデータセンターで保証されたデータストレージを実現できません。 この点で改訂があり、その運命はまだ不明であり、独自のソリューションを実装する予定です。
  2. メタデータエンリッチメント（Atlas）、メタデータベースのデータ管理/ガバナンス、メタデータベースの役割ベースのアクセス。
  3. 選択したアーキテクチャコンポーネントの代替案を調べます。 最初の候補：Oozieの代替としてのAirflow、リレーショナルDBMSからデータをアップロードするためのScoopの代替としてのより高度なCDC。
  4. CI / CDパイプラインの実装。 さまざまなテクノロジーとツールが使用されているため、配信の品質を保証しながら、コードの変更を可能な限り迅速に生産環境に自動的に展開できるようにしたいと考えています。


Raiffeisenbankでビッグデータを使用する計画はまだたくさんあります。それについて説明します。

ご清聴ありがとうございました！