昨年の急速な発展の後マンモスビッグデータプラットフォームは、もともとコアとして管理をスケジュールするためにそのようなプラットフォームのウェブサイトの開発のためのポータルとして位置付け、企業における多くの製品のための選択のビッグデータ開発ツールとなっている、同社はでてきましたいくつかのビッグデータ統合ツール、視覚的なユーザーインターフェース、統一されたユーザーの権利管理機構を提供します。開発プロセスのユーザーへの原油の洞察力はそうでマンモス、DSへのアクセス、アップロードおよびMRスケジューリング制御タスクでは非常に身近な感じ、HIVEクエリとを見つけることができます。ユーザーからのフィードバックとして、マンモスは常により多くのコンポーネントは、インタラクティブかつ継続的な改善プロセスの中にカバーされ、進化しています。しかし、マンモスの究極の形がそうであるようなフレームワークはありますか？答えは氷山の大生態学データの先端にだけ垣間見るマンモスの前に、スタッキングデバイスは真のエコシステムが、累積的なツールになることができない、それは言うことができる、自然に負です。プラットフォームは、大規模データの開発を使用してプロセス全体に大きな役割を果たしているようにするために、より近いビジネスへの公共サービスで補充した完全なワークフロー・ソリューションを、形成するために一緒にさまざまなコンポーネントの唯一の有機的統合。
本論文では、主にプラットフォーム、クライアント、コア、サービス形態のいくつかの異なる側面からのビッグデータのための理想的なプラットフォームについて説明します。
1つのサブディビジョンクライアントビッグデータプラットフォームオブジェクト実際のサービスは、これらの人々であるべきである、ちょうど絶えずのことを考えていました。このプロジェクトの開始時に個人的な問題です。
マンモスの名も最も古いバージョンから、主な目的は、各プロジェクト内のマンモスデータサービス会社の開発者であることを意味する「マンモスビッグデータ開発プラットフォーム」、です。会社のデータ開発作業がETLである（エキス・ロードを変換）、同期は、各データソースに微細であり、又はMRの使用は、ハイブが操作スケジューリング・システムをデータ・バインディングは、ストリームのセットを維持、データ変換を抽出行います。データは、データシステムの開発の中核とも言えます。彼らは、データと究極の目的のデータアプリケーションブリッジ間のデータプロセッサです。
しかし、マンモスのより多くのユーザーとして、プラットフォームおよび基礎となるシステムますます重要間の依存関係、ユーザーの重要なクラスでも巨大なプラットフォーム管理者。もう一つの目標は、全体としてマンモスプラットフォーム、ビッグデータプラットフォームのみ入り口に、すべてのタスクとスケジュールは、管理などを引き継ぐために、監査機関によってマンモス、マンモスにより提出されています。Hadoopの管理者、DBA、などのいくつかに続くプラットフォーム管理の役割もマンモスの管理と統計クエリに参加する強い意志を持って、ロード、表示だけでなく、運用・保守の一部と他のオペレーティングシステムから提出されたタスクのステータスを容易にすることができますように。
データ開発、システム管理者に加えて、利用者の第三のカテゴリーがあり、マンモスは現在、まだアカウントにユーザーを取るされていません - ユーザーデータを、比例して、製品の操作でデータが成長しているよう。より多くの人々は、アナリストや通常の業務の意思決定者を含むデータを、使用することを始めました。特定のデータの知識を持つ人々、彼らは単純なデータのいくつかの自己の助けを得ることができれば、圧力データが遊離開発者になります。今日では、データ取得要求のすべてのモードのための統一プロセスは無理がある開発者はデータを過ぎて、それが拡張可能ではありません。このモードでは、データは非常に遅い応答となり、データの開発がボトルネックになることも非常に簡単です、彼らの貴重な時間を簡単にビジネスの多様さに圧倒することができますが、データが、可能性を構築する本当の課題は棚上げされます。
サービス部門は、これは意味がありません。今後の動向、ユーザーのニーズを検討する緊急の必要があるすべての文字がプラットフォームの問題を使用して簡単に感じるようにする方法、同じではないです。機能モジュールプラットフォームを分割するユーザの異なるカテゴリー、それが異なる入口ガイドを介して、ユーザデータの開発およびデータにマンモス最新バージョンに分割された、実行可能な解決策です。
コア2データプラットフォーム
インタラクティブUI基盤システムのセットに基づいているビッグデータプラットフォームの実際のコアバリューとは何ですか？もちろんそうではありません。タスクのスケジューリング？ただ、そう？ビッグデータプラットフォーム本当のコアとは何ですか？
データウェアハウスは、はい、私はそれがデータウェアハウスのデータプラットフォームの本当の核心だと思います。ここでいうデータ・ウェアハウスは、データ・ウェアハウスは、変換プロセスを介して複数のデータベースや他のソースからのデータを格納するために使用されていることを指摘しておかなければ、広義の定義であり、アプリケーションの完全なクエリを統一されたユーザインタフェースを提供し、データを分析しますシステムのセット。米国InMonは位置の数を定義：データ・ウェアハウスは、サブジェクト指向、統合された、時変及び意思決定プロセスの管理を支援するデータの不揮発性のコレクションです。
データウェアハウスは、データ管理の範疇で、中心付近のデータウェアハウス、開発プロセスの最も重要な側面は、データのETLであり、以下の点をETLの上に常に周りに開いていないが、簡単にトピックを見過ごすことができます。
-
メタデータ管理
最初は、メタデータを管理しています。メタデータの役割は、これらの側面に反映され、すべてのメタデータの第1のメタデータに続いて必要性が、ユーザーがデータを理解するのに役立つデータ統合され、その後、メタデータは、データの品質を確保するための鍵となり、その後、それはあなたがデータのインとアウトを理解するのに役立ちます。最後に、データ要件の変更をサポートするための基盤であるメタデータ。特に、メタレベルのメタ情報の情報技術とビジネスのレベルを含むデータ、これらの記述を管理するためのメタデータ管理システムが必要です。例えば、データは、ポリマー層に属する、と詳細テーブル属する階層モデルのレコードデータウェアハウス、。各テーブル内の各フィールドの意味は、ディメンションテーブルであるファクトテーブル、ある標準形式、多次元解析モデルは、次元レベルものであるものに対応し、レベル、属性、指標、及びフィルタを定義します。データの流れ、および従ってが親族データを追跡しなければならないです。すぐにこれらに基づいてメタデータを取得するためのメカニズムを持っている必要があり、ユーザーが迅速に所望のデータ取得を見つけやすくするために、データウェアハウスに精通していません。
メタデータ管理システムの良いセットは、以下のものが完了する必要がありますされています。
-
完全なデータ・ディクショナリ・リポジトリ
-
データ親族
データウェアハウスは、生データを含む中間データ、幅データテーブル、データマートなどを処理します。合理的なデータ・ウェアハウスは、高速かつ正確なデータの追跡と管理が更新サイクル、粒度のレベルに応じて差別化によって、またはデータの整合性と説明の一貫性のより高いレベルで、トピックごとのデータに属して行わなければなりません。過去には、学生は多くの場合、データテーブル、ウィキやGitのようなツールを使用して記録されたデータファイルを記述するためのデータを開発します。これは、最初はデータの比較的自由な形式の記述が統一されたデータウェアハウスのメタデータ要件の観点から説明することができないで、2つの問題がある。第二に、このメタデータは、タイムリーなアップデートを取得することは困難であり、一回データウェアハウス内の他のユーザーがありますメタデータは、それがタイムリーかつ信頼性の高い応答することは困難であり、変更され、最終的には、メタデータ、失敗や混乱を遅れにつながるだろう。
マンモスの場合は、最新バージョンでは、データ管理機能の一部に追加されました。ヘルプユーザーがこの層にデータを理解するために、マンモステーブルは、テーブルには、フィールド、レコード、検索、収集、他の機能を提供し、すでに存在しているマンモスハイブテーブルを関連付けることができ、学生を開発するためのデータは、データ・ディクショナリ表ハイブに関連することができますリポジトリ、データ、タグの分類、さらに説明および図示。通常のデータのユーザーは迅速にデータディクショナリを取得し、独自のデータテーブル、データ列に助けを得ることができます。将来、マンモスも親族データの機能が付属して、データ系統は、データが開発したデータに基づいて縦方向の追跡を行います。親族は、ように、入力と出力ジョブ・スケジューリング・システム、実行ログとを取得するために、各タスクによれば、コアのタスクのスケジューリングシステムです。有向非巡回グラフ（DAG）に編成され、各入力項目に関連付けるタスク、DAGノードの出力は、DAGは、スケジューリングシステムジョブに登録されている側で、入力および出力ファイルです。実現のため、MR求人スパークRDDがあるか、血縁関係が含まれている、ハイブorg.apache.hadoop.hive.ql.tools.LineageInfoは、入力と出力のテーブルのコンテキストを取得することができ、特別なツールを持っています。
-
データ品質管理
メタデータの管理に加えて、データの品質を監視することは、データの品質の非常に重要な側面では、4つの基本要素の完全性、一貫性、正確性と適時で構成することができます。プロファイリング、監査、三つの重要なプロセスの修正を含みます：
プロファイリング：データ、データが利用可能であるかどうかを確認するために、統計やその他の情報やデータ収集の概要分析。従来のデータベースと同様の分析、より包括的なプロファイリングが収集、最大値と最小値、最大値及び最小長、カーディナリティ、ヌル数、平均値、中央値、分布情報等のユニークな値のレコードの数を含みます。データは、潜在的な外れ値をキャプチャする機能の重要定量的指標の数から得た、といくつかのツールも、データ品質スコアを与えることができます。
監査：データ品質の四つの基本的な側面に基づいて、データのレビュー、検証は、適時直接比較は、タスクETL、整合性とフィールドの整合性を含むレコードの整合性を監視することによって達成されます。最も一般的な異常の整合性フィールドは、統計上のNULL値の過剰な数である一般的な例外のフルバージョンがあまりにも多くのレコード数、少なすぎるとその他の異常などが記録されます。論理規則と同一の符号化規則を含む一貫同じ符号化規則が確立されたルールに基づいて決定されてもよいし、データの論理的な整合性は、比較的複雑であり、定期的な属性は、属性のうちのルールが存在します。質問データの精度は、一般的に文字化けの大きトランケーションの注文、文字このような間違いであり、中央値を分析することができ、平均異常へのデータ配信、
重複レコード、一貫性のあるデータを削除して、欠損値を埋めるなど、データ補正をし、異常なデータを修正：修正します。再フェッチされた元のデータから、レコードを行方不明の場合は、不足している分野は、予測や制約に一意の値を判断するために必要な重量に推定値を欠落しているために必要な、一貫性のないレコードは、指定された花のデータソースに精通に依存する必要があります。ルール。一般に、異常データのほとんどは補正が困難である、異常なデータの多くは百パーセントの削減になることはほとんどありません。最後に、異常データのフィルタリング、干渉を避けるために、データウェアハウスから除外異常なデータです。
監視データの品質管理のマンモス現在、ETLタスク、マンモスできる各タスクETLの、でも、Hadoopのジョブの監視、警報または障害タイムアウトタスクのための仕事。しかし、一貫性、整合性、真実性が空白で、この1は次の段階に焦点を当てた巨大な開発作業です。データは主観や不確実性を考慮して補正し、データの品質保証マンモスは、できるだけ早く、ユーザーはユーザーができるだけ早く救済措置として起動することができ、異常なデータを見つけることを期待して、プロファイリングとオーディションに焦点を当てました。プラグインモジュールの巨大なデータの品質保証は、オプションの内蔵型タスクスケジューリングシステムを可能にします。データの重要度が高いため、コンピューティングリソースは、比較的裕福ユーザは、データの品質保証がよく、サービス体験を向上させることができ、データ・ウェアハウス・システムの正常な動作を確保するためです。
3つのデータ開発モデルチェンジ
従来のデータ処理において、データ統合、ETLやELTの開発は、プロの援助専門家によって提供されるデータは、等オラクルOWB、MS SSISとして、完了します。Hadoopの時にビッグデータ、コアデータウェアハウスの時代には、ジョブを支援するために、もし適切なオープンソースETLツールはありません。私たちは、MapReduceのデータクレンジング、データ変換など、一連の手書きの学生の開発を完了するために、大量のデータを見ることができます。コードのこのセットを維持し、操作が現代のアプリケーション開発のようなものです大きなプロジェクトであり、それは通常のようにするには、開発者は、アセンブリコードの同じセットを維持します！
手書きのMapReduceショートボードは、明らかであろう基本的なAPIとしての高い複雑さ、自由度が比較的高いです。非常に高い自由度と同様に、コード仕様の可読性には、保守性が問題となります。それはパフォーマンスを最適化したい場合にはMapReduceのコードが良いですが、可読性、保守性に比べてますが、これらの約束のパフォーマンス上の利点が最も重要ではありません。多くの場合、仕事の転送で見ることができ、実際のプロジェクトでは、MRプロジェクトコードの山は恐る恐る修正の時に同僚を引き継ぐために、維持することは非常に困難です。最後に、開発効率が非常に低い、コードは多くの問題にまで及ぶ引き継ぐことを望んでいます。
この問題を解決するために、社会はさまざまなツールを持っています。ハイブは、などをカスケード、ハイブは、UDAFをハイブスケーラブルUDF組み合わせた複雑なタスクMRを、要約するSQL言語を使用することができ、SQLは、ETL開発作業のすべてを引き受けるために、より簡潔に、より一般的な言語といえますメンテナンスSQLは、効果的に手書きのMapReduceの問題を解決するだけでなく、SQLの非常に広い聴衆として、更なるデータは、むしろ基礎となるコードを維持するのに苦労の束よりも、ビジネス・プロセスのより集中開発することができ、参入障壁を軽減することができます。
マンモスはまた、開発者は、この便利な方法は、データウェアハウスを構築するためのより高速なエントリの開発を支援することを願って、ETLツールのSQLの範囲を提供しようとします。データ記憶装置からのこのような変換は、開発プロセス全体コアアイデアの、「データ構造」を開始します。ユニットからのHadoop HDFSファイル転送中のデータはまた、優れたデータウェアハウスベースのETL処理などの従来のリレーショナルデータベースとリンクアップすることができる2次元テーブルとなっています。新しい開発モデルでは、マンモスは、データウェアハウスを見て、ファイルの視点に終止符を打つ、HDFS分散ファイルシステムの非表示の背後で動作する必要があります。データストリームSerdeからユーザログデータをインポートする前にログを指定する必要があり、テーブル定義、およびこのツールの嵐ストリーミングによるあるいはデータの前処理をストリーミングスパーク。分析で述べたものに接触データ系統、ハイブツールを使用すると、すぐにテーブルとリンクテーブルの上にSQLステートメントを構築するために使用することができます。データ間で共有し、UDF UDAFを開発することができ、ユーザーはマンモスUDF / UDAF開発フレームワーク、すぐに書かれたユーザー定義関数を提供することが可能である一方で、共通のグループを許可する、マンモスUDF UDAFと一元管理を編集する必要があります。
4データ管理プラットフォーム
ここではそれは、現在のユーザーのリソース割り当てを含めマンモス管理機能を果たし、単なるデータ管理プラットフォームのシステム管理プラットフォームのためではありません。ユーザーディレクトリのパーミッションの承認、ユーザーグループ管理。これらのみでは十分ではありません。
プラットフォーム管理機能は、プラットフォーム上で各プロジェクトの操作をすべての人に公開する必要があります。含みます：
-
ユーザー・リソース・フットプリント
ユーザーのリソースは、ストレージ、コンピューティングなど、ストレージリソース、すべてのユーザーファイルが多くのスペース分散ファイルシステムを取っていることをより良く理解が含まれ、このデータは、より良いストレージリソースプランニングクラスタに役立ちます、量があまりにも成長することがわかりましたその合理的な計画のリソースを助けるために高速なユーザー。各種テーブル、運用、保守要員のトップランクのプロジェクトが一目に現在のクラスタの状態を読み込むことができます。コンピューティングリソースを測定することは比較的より困難である、それが唯一の使用ユーザー・キューに基づいて取得することができます。
-
ユーザタスク操作
タスクスケジューリングシステムでの動作を取得するためのユーザーのタスク、タスク、どのくらいの各タスクの仕事とのクマは、仕事を障害があるあなたが実行する必要が個別にどのくらいの時間をどのような種類、各ジョブ/タスク、そのジョブの失敗の確率が最も高いため、どのように多くのユーザー何がそうで、これらの統計は非常に重要です。マンモス現在アズカバンスケジューリングシステムを計画することは困難とシステムリソースの量、現在、すべてのユーザーディスパッチシステムを使用するために、分離されたスケジューリングスケジューリングシステム自体の欠如のために十分なリソースが存在しない場合にユーザー間であると言うことができ、それは言うことができますそれはあなたがこれらの統計よりに頼る必要が合理的な計画管理タスクスケジューリングリソースのためのプラットフォームとして、脆弱です。ジョブの故障解析が緊急の問題であり、経験の浅い開発者は多くの場合、エラーのデータの効率的な原因を突き止める一つの理由は、高いものではなく、プラットフォームは間違った理由を推測、エラーログ情報を抽出するためのルールの効果的なシステムを提供することができます。一緒に。ユーザーがメモリ不足のため、特定のJOB非常に高い周波数を表示された場合は失敗し、それはシステムが補正に到達するために、拡張またはトリガ時間を調整するためにユーザを支援することがありますコミット。データベース権限Sqoopタスクを結果として複数の出現が失敗した場合は、できるだけ早くACLまたはホワイトリストを欠落している問題を解決するために、DBAに連絡することができます。
5今後の
完全なビッグデータプラットフォームは、基本的な技術に基づいており、ユーザーのニーズが発展を更新し続け、マンモスはアイデアのための完全なソリューション、データのための人々のさまざまなグループのニーズを満たすために、より良い機能やツールの導入を提供する必要があります。リアルタイムデータ処理と豊富なデータの同期、検索、です。KeyValueシステムのログを、アルゴリズムモジュールは、コンテンツを紹介する今後の計画です。データのためのユーザーの需要は、ビッグデータの時代に新鮮リクルートソリューションではありません、とだけ断片的な措置を講じ、シーンの主なセグメントをより多くの豊かな対象とし、1つのブレークずつでは最近の開発方向であります。マンモスの心は、ビッグデータサービスを使用して簡単に、より包括的に提供するために、ビッグデータのしきい値を減らし、変更されません。