序文
この本を読むことで、独自のビッグデータ開発知識システムとグラフを確立し、データ開発のさまざまなテクノロジー（関連する概念、原則、アーキテクチャ、実際の開発と最適化のスキルなどを含む）を習得し、実際のプロジェクトのデータを分析できます。ガイダンスとリファレンスを作成して提供します。個人的には、Bangzhong氏によるこの本はまだ非常にエキサイティングで、読む価値があると思います（•̀ω•́）✧
次に、オフラインデータ処理技術、リアルタイムデータ処理技術、データ開発の最適化、ビッグデータモデリング、およびデータ階層化システム構築の観点から要約して学習します。
大局
主にデータ全体の観点から、データ収集から消費までの4つの主要なプロセスと組み合わせて、関連するデータ技術を紹介し、描写します。
-
データは原油であり、データはデータとテクノロジーによって推進される生産手段です。人類はIT時代からDT時代に移行しています。データの戦略的性質はますます認識されています。ますます多くの企業、機関、組織、特にインターネット企業が構築しています。独自のデータプラットフォーム。
-
オープンソーステクノロジーに基づく自己研究、自己構築、成熟したビジネスソリューションの購入、プライベートデータセンターまたはパブリッククラウド、自己構築チームまたはサービスアウトソーシングのいずれであっても、データプラットフォームは次々に構築されています。これらのデータプラットフォームすべてのデータ資産を物理的に運ぶだけでなく、データ開発エンジニア、データアナリスト、アルゴリズムエンジニア、ビジネスアナリスト、およびその他の関連データ担当者の日常の作業プラットフォームおよび環境にもなります。
-
したがって、データプラットフォームは、企業や組織内で「データを見る」「データを利用する」ための重要なインフラストラクチャであり、水、電気、石炭と同様に不可欠であり、データの実現を可能にするのはそれらの存在です。
1.データフロー
ファッショナブルなビッグデータであろうと、以前の従来のデータウェアハウスであろうと、最も広く使用されているオフラインデータであろうと、ますます注目を集めているリアルタイムデータであろうと、そのエンドツーエンドのプロセスには、データの生成、データの収集と送信、データの保存が含まれます。処理とデータ適用の4つの主要なプロセス、特定のデータフローチャートとその主要なリンクを図に示します。
1.1データ生成
データ生成はデータプラットフォームのソースです。さまざまなタイプのソースシステムに応じて、データ生成のソースを次のタイプに分類できます。
（1）ビジネスシステム
ビジネスシステムとは、スーパーマーケットのPOS販売システム、注文/在庫/サプライチェーン管理のERPシステム、顧客関係管理のCRMシステム、金融システムなど、企業のコアビジネスまたは内部担当者が企業の正常な運用を確保するために使用するITシステムを指します。さまざまな管理システムに関係なく、バックエンドデータは通常バックエンドデータベースに保存されます。
（2）Webシステム
Webシステムには、さまざまな形式のデータを格納するためのバックエンドデータベースもありますが、さらに、ユーザーがこのWebサイトにアクセスした方法（検索エンジン、Web URLの直接入力、その他）などのさまざまなユーザー行動ログもあります。システムジャンプなど）、Webサイトにはどのような動作がありますか（どのWebページにアクセスしたか、どのボタンがクリックされたか、どのくらいの時間表示されたか）。Cookieとさまざまなフロントエンド埋め込みテクノロジを介して、これらのユーザーの動作を記録し、対応するログファイルに保存できます。
（3）モバイルアプリ、外部システム、手動ソートなど。
1.2データの収集と送信
ビジネスシステムのWebシステム、モバイルアプリなどによって生成されたデータファイル、ログファイル、および埋め込みログは、さまざまなシステムやサーバーに散在しており、データ収集および送信ツールとシステムの助けを借りてのみ、相関と分析のために一元化された領域に集約できます。
この適時性に注意を払う必要があります。データの収集と送信のツールとシステムがビッグデータの時代の重要なインフラストラクチャになっていると言っても過言ではありません。
1.3データの保存と処理
データの収集と同期後、データは原始的で乱雑になり、クリーンアップ、相関、標準化、慎重に整理およびモデル化する必要があります。後続のデータ分析またはデータサービスを使用する前に、データ品質テストに合格する必要があります。これは、データプラットフォーム構築の3番目の重要なジョイントであるデータの保存と処理です。
これは、データ分野で最もエキサイティングで開花している分野でもあります。さまざまなオープンソーステクノロジーのフレームワークとイノベーションが際限なく出現していますが、それらは常に変化しています。ダウンストリームのデータユーザーの適時性に応じて、データストレージ処理ツールとテクノロジーをオフライン処理に分割できます。 、ニアライン処理およびリアルタイム処理では、処理されたデータは、オフラインデータウェアハウス、ニアラインデータストレージ領域、およびリアルタイムデータストレージ領域に対応して格納されます。
オフライン処理は通常、毎日データ処理を実行します。毎日の早朝に収集および同期されたデータが配置された後、関連するデータ処理タスクは事前に設計されたETL（抽出、変換、読み込み、通常はデータのクリーニング、相関、標準化などのデータ処理プロセスとETLタスク間のトポロジ関係が順番に呼び出され、最終的なデータがオフラインデータウェアハウスに書き込まれます。オフラインデータウェアハウスのデータは通常、特定のモデリングアイデア（最も一般的に使用されるのは次元モデリングアイデア）に従って慎重に編成されます。これにより、ダウンストリームユーザーは非常に直感的で使いやすくなりますが、データ処理プロセスも非常に便利になります。拡張と変更。
分散コンピューティングに関するGoogleの3つの論文の発表と、オープンソースのHadoopエコシステムの台頭（HDFS、MapReduce、HBaseのGoogleの3つの論文に対応）により、ビッグデータの時代が到来しました。
現在、ビッグデータの時代におけるデータの使用は、オフラインデータ分析に限定されなくなりました。リアルタイムデータはますます重要になり、これはプロのストリームコンピューティングツールとフレームワークの助けを借りてのみ達成できます。現在、最も人気があり、広く使用されているのは、SparkStreamingとFlinkです。
これらのオープンソースフレームワークを使用する一方で、主要な国内および海外のメーカーは、独自の手法を組み合わせて、安定性、スケーラビリティ、パフォーマンスなどのさまざまなレベルからこれらのストリームコンピューティングフレームワークを改善および革新しています。しかし、著者は、これらの中で最も革新的なのはSQL抽象化レイヤーの出現であると考えています.SQL抽象化レイヤーは、リアルタイム開発ユーザーがリアルタイム処理ロジックを開発するためにJavaまたは他のプログラミング言語を作成する必要をなくし、リアルタイム開発の効率を大幅に加速するだけでなく、大幅に削減しますリアルタイム開発のしきい値。
1.4データアプリケーション
注意深いデータの埋め込み、大規模なオフラインデータの同期、ミリ秒レベルのリアルタイムデータ収集、面倒なデータ処理、および綿密なデータモデリングにより、データ使用の強固な基盤が築かれましたが、データの最終的な価値はデータアプリケーションのリンクに依存します。
最も広く使用されているデータアプリケーションの方法は、企業/部門のビジネス日報、ビジネス週報、意思決定者と管理者が定期的に閲覧するビジネス月報、運用指標と最前線のオペレーターが閲覧するレポートなどを「監視」することです。アナリストはビジネスの意思決定とビジネスを提供します運用参照データ分析レポート、およびアナリストやビジネス担当者によるアドホック分析。
これらのデータレポートは、企業マネージャー、製品およびプロジェクトマネージャー、および最前線のオペレーターが企業製品およびプロジェクトの問題、隠れた危険、および方向性を特定し、正しい傾向を確認した後、方向性を修正するか、投資を増やすための早期対策を講じるのに役立ちます。誇張すると、企業がデータを「見る」能力は、企業のデータアプリケーション機能のレベルを表しており、その中核的な競争力の1つでもあります。
ビッグデータの時代の到来と人工知能の急増により、データはGoogleのスーパー検索ボックス、Taobaoの「数千人と数千人の顔」のパーソナライズされた推奨システム、ニュース集約推奨アプリを「見る」ことに限定されなくなりました。今日の見出しはすべてデータを表しており、アルゴリズムの組み合わせの成功。また、データ+アルゴリズムの力にも焦点を当てています。データマイニングマシン学習アルゴリズム、ディープラーニングアルゴリズム、およびオンラインデータサービスの助けを借りて、データはオンライン生産システムの一部になりました。
二、データ技術
主に、オフラインおよびリアルタイムのデータプラットフォームアーキテクチャと関連テクノロジーをデータプラットフォームの観点から紹介します。
現在、ビッグデータ関連の技術は繁栄していると言えますが、切り離せないものです。これらの技術がどのように変化し、名詞がどれほど斬新であっても、それらはすべて上記の特定のプロセスとリンクに属しており、他にも多くのオープンソースがあります。技術的な枠組みが1つずつ繰り返されることはありません。
しかし、これらすべてのデータテクノロジーが一緒になって、現在のビッグデータエコシステムを構成しています。さまざまなテクノロジーによって、私はあなたの中に、あなたは私の中にいて、お互いから学び、刺激し合っています。実際、多くのテクノロジーとその基本原則は似ています。それらが独立するのは、商業的、コミュニティ、または私的な理由のためだけです。おそらく、ビッグデータのエコシステム全体の繁栄と繁栄に貢献したのはまさにこれです。詩が言うように、Xinxinは上向きに動いています。「花だけが春を意味するのではなく、庭は紫と赤でいっぱいです。」
2.1データの収集と送信の主な技術
データの収集と送信のツールとテクノロジーは、主にオフラインバッチ処理とリアルタイムのデータ収集と送信の2つのカテゴリに分類されます。名前が示すように、オフラインバッチ処理は、主にデータを一度にバッチで収集およびエクスポートすることです。オフラインバッチ処理は現在最も有名で一般的に使用されているツールはSqoopであり、ダウンストリームユーザーは主にオフラインデータ処理プラットフォーム（Hiveなど）です。最も一般的に使用されるリアルタイムのデータ収集と送信はFlumeとKafkaであり、それらのダウンストリームユーザーは通常、Storm、Spark、Flinkなどのリアルタイムストリーム処理プラットフォームです。
（1）Sqoop
オープンソースのオフラインデータ転送ツールとしてのSqoopは、主にHadoop（Hive）と従来のデータベース（MySQL、PostgreSQLなど）との間のデータ転送に使用されます。
（2）フルーム
Flume Clouderaは、大規模なログの収集、集約、および送信のための、可用性と信頼性の高い分散システムを提供します。現在、Apacheのトップレベルのサブプロジェクトです。Flumeを使用すると、ログや時間などのデータを収集し、これらのデータリソースを一元的に保存できます。ダウンストリームで使用するため（特に、Stormなどのストリーム処理フレームワーク）。
（3）カフカ
一般的に、Flumeがデータを収集する速度とダウンストリーム処理の速度は通常同期されないため、リアルタイムプラットフォームアーキテクチャはメッセージミドルウェアを使用してバッファリングします。この点で最も人気があり、広く使用されているのは間違いなくKafkaです。
Kafkaは、LinkedInによって開発された分散メッセージングシステムであり、水平方向のスケーラビリティと高スループットのために広く使用されています。現在の主流のオープンソース分散処理システム（Storm Sparkなど）は、Kafkaとの統合をサポートしています。
2.2データ処理の主な技術
データ処理は、データオープンソーステクノロジーが盛んな分野です。オフラインおよび準リアルタイムツールには、主にMapReduce、Hive、Sparkが含まれます。ストリーム処理ツールには、主にStormが含まれ、最近ではより人気のあるFlinkとBeamが含まれます。
（1）MapReduce
MapReduceは、Googleのコアコンピューティングモデルです。大規模クラスターで実行される複雑な並列コンピューティングプロセスを、mapとreduceの2つの関数に高度に抽象化します。MapReduceの最大の利点は、通常の開発者がビッグデータを処理できることです。これにより、開発者は分散プログラミングの知識がなくても、分散システムでプログラムを実行して大量のデータを処理できます。
（2）ハイブ
HiveはFacebookによって開発され、Hadoopオープンソースコミュニティに貢献しました。これは、Hadoopアーキテクチャに基づいて構築されたSQL抽象化です。
Hiveは、主要な国際企業（Facebookの国内BATなど）を含むインターネット企業が使用する
主流のオフラインデータ処理ツールです。
（3）スパーク
MapReduce Hiveは、大量のデータのバッチ処理のほとんどを完了し、ビッグデータの時代にエンタープライズビッグデータ処理に推奨されるテクノロジーになりましたが、そのデータクエリの遅延は批判されており、反復コンピューティングやDAG（指示）にも非常に適していません。非周期的グラフ）計算。Sparkは、スケーラビリティ、メモリベースのコンピューティングの特性を備えており、Hadoopで任意の形式のデータを直接読み書きできるため、リアルタイムのデータクエリと反復分析のニーズをより適切に満たすため、ますます普及しています。
（4）しっかり
データ処理の分野では、バッチ処理タスクとリアルタイムストリームコンピューティングタスクは一般に2つの異なるタスクと見なされます。データプロジェクトは通常、これらのタスクの1つのみを処理するように設計されています。たとえば、Stormはストリーム処理タスクのみをサポートしますが、MapReduceはHiveはバッチ処理タスクのみをサポートします。では、2つは1つの技術フレームワークで達成できますか？バッチ処理はストリーム処理の特殊なケースですか？
Apache Flinkは、分散リアルタイムストリーム処理とバッチデータ処理を同時に行うためのオープンソースコンピューティングプラットフォームです。同じFlinkランタイム（Flinkランタイム）に基づいて、ストリーム処理とバッチ処理をサポートする機能を提供できます。Flinkは完全にサポートします。ストリーム処理、バッチ処理は特別なストリーム処理と見なされますが、その入力データストリームは制限付きとして定義されます。
2.3データストレージの主なテクノロジー
（1）HDFS
Hadoop分散ファイルシステム（略してHDFS）は、分散ファイルシステムです。これは
、GoogleのGoogleファイルシステム（GFS）にちなんでGoogleに触発されたDougCuttingによって開発されたGFSのようなファイルシステムです。高度な耐障害性を備え、高スループットのデータアクセスを提供します。これは、大規模なデータセットのアプリケーションに非常に適しています。HDFSは、高い耐障害性と高いスループットを備えた大規模なデータストレージソリューションを提供します。
（2）HBase
HBaseは、HDFS上に構築された分散型の列指向ストレージシステムです。リアルタイムの読み取りと書き込み、超大規模データセットへのランダムアクセスなどのシナリオでは、HBaseは現在市場で主流のテクノロジーの選択肢です。
実際、従来のデータベースソリューション、特にリレーショナルデータベースでも、レプリケーションとパーティショニングによってシングルポイントのパフォーマンス制限を高めることができますが、これらはすべて後知恵であり、インストールとメンテナンスは非常に複雑です。HBaseは、別の観点からスケーラビリティの問題を処理します。つまり、ノードを下から上に直線的に追加することでスケールアップします。
HBaseはリレーショナルデータベースではなく、SQLもサポートしていません。HBase内のテーブルには、通常、次の特性があります。
- 大：テーブルには、数億の行と数百万の列を含めることができます
- 列指向：リスト（クラスター）ストレージとアクセス制御、列（クラスター）に依存しない取得
- スパース：空（NULL）列はストレージスペースを占有しないため、テーブルを非常にスパースになるように設計できます
- モードレス：各行には、並べ替え可能な主キーと任意の数の列があります。列は必要に応じて動的に追加でき、テーブル内の異なる行は完全に異なる列を持つことができます
- データの複数のバージョン：各セルに複数のバージョンのデータが存在する可能性があります。デフォルトでは、バージョン番号が自動的に割り当てられます。これは、セルが挿入されたときのタイムスタンプです。
- 単一のデータタイプ：HBaseのすべてのデータはタイプのない文字列です
2.4データアプリケーションの主な技術
固定レポート、リアルタイム分析、データサービス、データ分析、データマイニング、機械学習など、データを適用する方法はたくさんあります。
3、まとめ
この章では主に、データの生成から消費までの4つの主要なプロセス（データの生成、データの収集と送信、データの保存と処理、データの適用）を含む、データ全体の概要を説明します。各プロセスには、多くのテクノロジ、オープンソースフレームワーク、およびツールが含まれます。そしてプラットフォーム。
たとえば、主なオフラインデータ処理テクノロジーはHadoop MapReduceに基づくHiveであり、HiveはSQL on Hadoopテクノロジーですが、ClouderaのImpala、Apache DruidとPresto、Sharkなど、Hadoopテクノロジーとフレームワークに類似したSQLが多数あります。 、初心者は1つのテクニックに集中し、他の関連するテクニックの理解を支援する必要があります。そうしないと、簡単に集中力を失い、途方に暮れてしまいます。