AI時代なのに、まだビッグデータが分からない？

[[322803]]

近年、IT 業界でどの技術方向が最もホットであるかと聞かれれば、それは ABC、つまり AI + ビッグデータ + クラウド、つまり人工知能、ビッグデータ、クラウドコンピューティングであるに違いありません。

近年、インターネットブームが底をつき、伝統的な企業がデジタル変革を遂げる中、ほぼすべての企業がデータの価値をさらに活用し、企業の業務効率を向上させる方法を検討しています。このような傾向の中で、ビッグデータ技術はますます重要になってきています。そのため、AI時代にビッグデータを理解していなければ本当にOUTです！

AI やクラウドコンピューティングと比較すると、ビッグデータは技術的なハードルが低く、ビジネスとの関連性が高くなります。個人的には、数年後にはビッグデータ技術が現在の分散技術のように基本的なスキル要件になると感じています。

数日前、私はチーム内でビッグデータ技術共有セッションを開催し、ビッグデータ知識に関するリテラシーキャンペーンの提供と学習ガイドの提供に重点を置きました。この記事では、共有された内容をもとに体系的に整理していきます。ビッグデータに興味のある学生の皆さんのお役に立てれば幸いです。内容は以下の5つのパートに分かれています。

1. ビッグデータの発展の歴史

2. ビッグデータの中心概念

3. ビッグデータプラットフォームの一般的なアーキテクチャと技術システム

4. ビッグデータの一般的な処理フロー

5. ビッグデータにおけるデータウェアハウスアーキテクチャ

01 ビッグデータの発展の歴史

「ビッグデータ」の概念を説明する前に、まずは5つの段階を経てきたビッグデータの約30年にわたる発展の歴史を見てみましょう。では、ビッグデータは各段階で歴史的にどのような位置づけにあるのでしょうか。どのような問題点に直面したのでしょうか。

1.1 啓蒙段階: データウェアハウスの出現

1990 年代に、ビジネスインテリジェンス (私たちがよく知っている BI システム) が誕生しました。これは、企業の既存のビジネスデータを知識に変換し、上司がビジネス上の意思決定を行うのに役立ちます。たとえば、小売業のシナリオでは、合理的な購買計画を策定するために、商品の販売データと在庫情報を分析する必要があります。

明らかに、ビジネスインテリジェンスはデータ分析と切り離せないものであり、データ分析では複数のビジネスシステム (トランザクションシステムやウェアハウスシステムなど) からデータを集約し、大量のデータに対して範囲クエリを実行する必要があります。従来のデータベースはすべて、単一のビジネスに関するデータの追加、削除、変更、クエリを目的としており、この需要を満たすことができません。そのため、データウェアハウスの概念が生まれました。

従来のデータウェアハウスでは、初めてデータ分析のアプリケーションシナリオが明確に定義され、ビジネスデータベースに依存しない個別のソリューションを使用して実装されました。

1.2 技術の変化: Hadoop の誕生

2000 年頃、PC インターネット時代が到来し、膨大な量の情報をもたらしましたが、その典型的な特徴は次の 2 つです。

データの規模は拡大しており、Google や Yahoo などのインターネット大手は 1 日に何億もの行動データを生成できます。
多様なデータタイプ: 構造化されたビジネスデータに加えて、膨大なユーザー行動データや、画像やビデオで表されるマルチメディアデータもあります。

明らかに、従来のデータウェアハウスでは、インターネット時代のビジネスインテリジェンスをサポートできません。 2003 年に、Google は、分散処理テクノロジ MapReduce、列指向ストレージ BigTable、分散ファイルシステム GFS を含む 3 つの先駆的な論文 (一般に「Google Three」として知られています) を発表しました。これら 3 つの論文は、現代のビッグデータテクノロジーの理論的基礎を築きました。

残念ながら、Google はこれら 3 つの製品のソースコードをオープンソース化せず、詳細な設計書のみを公開しました。 2005 年、Yahoo はこれら 3 つの論文に基づいて Hadoop のオープンソース実装に資金を提供しました。この技術的変化により、ビッグデータ時代の幕が正式に開きました。

Hadoop には、従来のデータウェアハウスに比べて次のような利点があります。

完全に分散されており、安価なマシンを使用してクラスターを構築できるため、大量のデータのストレージニーズを完全に満たすことができます。
データ形式を緩和し、データモデルとデータストレージを分離することで、異種データの分析ニーズを満たすことができます。

Hadoop テクノロジが成熟するにつれ、2010 年の Hadoop World Conference で「データレイク」の概念が提案されました。

データレイクは、データを生の形式で保存するシステムです。

企業は Hadoop に基づいてデータレイクを構築し、データを企業の中核資産とみなすことができます。その結果、データレイクは Hadoop の商用化の幕を開けました。

1.3 データファクトリー時代: ビッグデータプラットフォームの台頭

商用 Hadoop には 10 を超えるテクノロジが含まれており、データ開発プロセス全体が非常に複雑です。データ需要開発を完了するには、データ抽出、データ保存、データ処理、データウェアハウスの構築、多次元分析、データの視覚化など、一連のプロセスが必要です。この高い技術的ハードルは、明らかにビッグデータ技術の普及を制限するでしょう。

このとき、ビッグデータプラットフォーム (サービスとしてのプラットフォーム、PaaS の概念) が誕生しました。これは、R&D シナリオ向けのフルリンクソリューションであり、データの R&D 効率を大幅に向上させ、データを組立ラインと同じくらい迅速に処理できます。生のデータは指標となり、さまざまなレポートやデータ製品に表示されます。

1.4 データ価値時代: アリババがデータミドルプラットフォームを提案

2016年頃からモバイルインターネットの時代に入り、ビッグデータプラットフォームの普及に伴い、ビッグデータの応用シーンも数多く登場しています。

この時点で、いくつかの新しい問題が浮上し始めました。ビジネスニーズに迅速に対応するために、煙突型の開発モデルにより、異なるビジネスラインでデータが完全に分離されました。これにより、大量のデータ指標が繰り返し開発され、研究開発の効率が低下するだけでなく、ストレージとコンピューティングリソースが浪費され、ビッグデータのアプリケーションコストがますます高くなりました。

先見の明のあるジャック・マー氏はその後、「データミドルプラットフォーム」という概念を提唱し、「One Data, One Service」というスローガンがビッグデータ業界全体に響き始めました。データミドルプラットフォームの核となる考え方は、データの繰り返し計算を回避し、データサービスを通じてデータ共有機能を向上させ、ビジネスを強化することです。

02 ビッグデータの基本概念

ビッグデータの発展の歴史を理解した後、ビッグデータのいくつかの中核となる概念について説明しましょう。

2.1 ビッグデータとは何か?

ビッグデータは、大規模で急成長している多様な情報資産であり、より強力な意思決定とプロセス最適化機能を実現するには、新しいストレージおよびコンピューティングモデルが必要です。

ビッグデータの典型的な特徴は次の 4 つです。

ボリューム: データ規模が PB または EB レベルに達する大規模なデータスケール。
多様性: 異種データタイプには、構造化データだけでなく、ログファイル、画像、オーディオ、ビデオなどの半構造化データや非構造化データも含まれます。
速度: データフローが高速で、データ生成および処理速度が非常に速いです。
価値: 価値密度が低く、価値のあるデータの割合が非常に小さい。新しい知識を発掘するには、人工知能などの方法が必要です。

2.2 データウェアハウスとは何ですか?

データウェアハウスは、主題指向で統合され、時間的に変化し、比較的安定したデータの集合です。

簡単に言えば、データウェアハウスはビッグデータを整理する形式であり、大量のデータの保守とさらなる分析に役立ちます。

トピック指向: トピックまたはビジネスシナリオ別にデータを整理することを意味します。
統合: 複数の異種データソースからデータを収集し、抽出、処理、統合します。
時間の経過による変化: 重要なデータは時間属性でマークする必要があります。
比較的安定: データの削除や変更はほとんど行われず、新しいデータのみが追加されます。

2.3 従来のデータウェアハウスと新世代データウェアハウス

ビッグデータ時代の到来により、従来のデータウェアハウスと新世代のデータウェアハウスの間には多くの違いが生まれています。以下では、2 つの世代のデータウェアハウスの類似点と相違点をさまざまな観点から比較します。

03 ビッグデータプラットフォームの一般的なアーキテクチャ

ビッグデータに関連する技術は数十種類あると前に述べました。では、ビッグデータプラットフォームの一般的なアーキテクチャを通じて、技術システム全体を理解しましょう。

3.1 データ転送層

Sqoop: RDBMS と HDFS 間の双方向データ移行をサポートし、通常はビジネスデータベース (MySQL、SQLServer、Oracle など) から HDFS にデータを抽出するために使用されます。
Cannal: MySQL binlog を監視することで増分データサブスクリプションとほぼリアルタイムの同期を実装する Alibaba のオープンソースデータ同期ツール。
Flume: 大量のログ収集、集約、転送に使用され、生成されたデータを HDFS または HBase に保存します。
Flume + Kafka: リアルタイムのストリーミングログを処理できます。その後、Spark Streaming などのストリーミング処理技術を通じて、ログのリアルタイム解析と適用を完了できます。

3.2 データストレージ層

HDFS: 分散コンピューティングにおけるデータストレージ管理の基盤となる分散ファイルシステム。Google GFS のオープンソース実装であり、安価な商用マシンに導入できます。高いフォールトトレランス、高いスループット、高いスケーラビリティを備えています。
HBase: 分散型の列指向 NoSQL KV データベース。Google BigTable のオープンソース実装であり、ファイルストレージシステムとして HDFS を使用します。ビッグデータのリアルタイムクエリ (IM シナリオなど) に適しています。
Kudu: HDFS と HBase の中間に位置する分散データベース。ランダム読み取りと書き込み、OLAP 分析の両方をサポートするビッグデータストレージエンジンです (HBase がバッチ分析に適していないという問題点を解決します)。

3.3 リソース管理層

Yarn: Hadoop のリソースマネージャー。Hadoop クラスターリソースの統合管理とスケジュール設定を担当し、コンピューティングプログラム (MR タスク) にサーバーコンピューティングリソース (CPU、メモリ) を提供し、MR、Spark、Flink などの複数のフレームワークをサポートします。
Kubernetes: Google によってオープンソース化された、クラウドプラットフォーム用のコンテナ化されたオーケストレーションエンジンです。アプリケーションのコンテナ化された管理を提供し、異なるクラウドや異なるバージョンのオペレーティングシステム間で移行できます。現在、Spark と Storm はすでに K8S をサポートしています。

3.4 データコンピューティング層

ビッグデータコンピューティングエンジンは、コンピューティング効率を決定し、ビッグデータプラットフォームの中核部分です。おおよそ次の4世代の開発を経ており、オフラインコンピューティングフレームワークとリアルタイムコンピューティングフレームワークに分けられます。

3.4.1 オフラインコンピューティングフレームワーク

MapReduce: ビッグデータを並列処理するためのコンピューティングモデル、フレームワーク、プラットフォーム (コンピューティングをデータに近づけ、データ転送を削減する、この設計アイデアは非常に巧妙です)。
Hive: HDFS に保存されたデータを管理できるデータウェアハウスツールです。構造化データファイルをデータベーステーブルにマッピングし、完全な SQL クエリ機能を提供します (実際の操作では、Hive SQL は MapReduce タスクに変換されます)。オフラインの非リアルタイムデータ分析に適しています。
Spark SQL: RDD (Resilient Distributed Dataset) の特殊なデータ構造を導入し、SQL を RDD 計算に変換し、計算の中間結果をメモリに保存します。そのため、Hive よりもパフォーマンスが高く、リアルタイム性が求められるデータ分析シナリオに適しています。

3.4.2 リアルタイムコンピューティングフレームワーク

Spark Streaming: リアルタイムストリーミングデータ処理フレームワーク（タイムスライスによって小さなバッチに分割され、sレベルのレイテンシ）。Kafka、Flume、HDFSなどのデータソースからリアルタイム入力データを受信し、処理後に結果をHDFS、RDBMS、HBase、Redis、ダッシュボードなどに保存できます。
Storm: リアルタイムストリームデータ処理フレームワーク、真のストリーム処理。各データが計算をトリガーし、レイテンシが低い (ミリ秒レベルのレイテンシ)。
Flink: より高度なリアルタイムストリームデータ処理フレームワーク。Storm と比較して、レイテンシが低く、スループットが高くなります。また、順序外処理や遅延調整もサポートします。

3.5 多次元分析レイヤー

Kylin: 数秒以内に巨大な Hive テーブルをクエリできる分散分析エンジン。多次元の組み合わせ計算の結果をキューブに保存し、事前計算 (スペースと時間の交換) を通じて HBase に格納します。ユーザーが SQL クエリを実行すると、SQL は高速クエリと高い同時実行機能を備えたキューブクエリに変換されます。
Druid: 数十億行のテーブルに対して数秒で任意の集計分析を実行できる、リアルタイムデータ分析用の耐障害性に優れた高性能オープンソース分散システムです。

04 ビッグデータの一般的な処理フロー

ビッグデータプラットフォームの一般的なアーキテクチャと技術システムを理解した後、オフラインデータとリアルタイムデータを処理するためにビッグデータテクノロジがどのように使用されるかを見てみましょう。

上図は一般的なビッグデータ処理フローであり、主に次の手順が含まれます。

データ収集: これはビッグデータ処理の最初のステップです。データソースは主に 2 つのカテゴリに分類されます。1 つ目のカテゴリは各業務システムのリレーショナルデータベースで、Sqoop や Cannal などのツールを通じて定期的に抽出されるか、リアルタイムで同期されます。2 つ目のカテゴリはさまざまな埋め込みログで、Flume を通じてリアルタイムで収集されます。
データ保存: データを収集したら、次のステップは HDFS にデータを保存することです。リアルタイムログストリームの場合は、Kafka を介して後続のストリームコンピューティングエンジンに出力されます。
データ分析: このステップは、オフライン処理やストリーム処理を含むデータ処理の中核リンクです。対応するコンピューティングエンジンには、MapReduce、Spark、Flink などがあります。処理された結果は、事前に設計されたデータウェアハウス、または HBase、Redis、RDBMS などのさまざまなストレージシステムに保存されます。
データアプリケーション: データの視覚化、ビジネス上の意思決定、AI などのさまざまなデータアプリケーションシナリオが含まれます。

05 ビッグデータにおけるデータウェアハウスアーキテクチャ

データウェアハウスは、ビジネスの観点から見たデータ編成の形式です。ビッグデータアプリケーションとデータミドルプラットフォームの基盤となります。データウェアハウスシステムは、一般的に、下図に示す階層構造を採用します。

ご覧のとおり、データウェアハウスシステムは、ソースデータレイヤー、データウェアハウスレイヤー、データマートレイヤー、データアプリケーションレイヤーの 4 つのレイヤーに分かれています。このような階層構造の使用は、複雑な問題を単純化するソフトウェア設計の階層化概念に似ています。各層には単一の責任があり、保守性と再利用性が向上します。各レイヤーの具体的な機能は次のとおりです。

ODS: ソースデータレイヤー、ソーステーブル。
DW: データウェアハウスレイヤー。ディメンションテーブルとファクトテーブルを含みます。ディメンションテーブルは、都市テーブル、製品カテゴリテーブル、バックエンド追跡ポイント詳細テーブル、フロントエンド追跡ポイント詳細テーブル、ユーザーワイドテーブル、製品ワイドテーブルなどのソーステーブルをクリーンアップした後に形成されるワイドデータテーブルです。
DM: ユーザーグループ分析テーブルやトランザクションフルリンクテーブルなど、さまざまなビジネス関係者が共同で構築し、軽量粒度でデータを集約するデータマート層。
ADS: データアプリケーション層。実際のアプリケーション要件に応じて生成されるさまざまなデータテーブル。

さらに、各レイヤーのデータテーブルは、統一された命名規則を使用して標準化された方法で管理され、テーブル名には、階層化、サブジェクトドメイン、ビジネスプロセス、およびパーティションの情報が含まれます。たとえば、トランザクションドメインの下のエクスポージャーテーブルの場合、名前は次のようになります。