戦闘技術：単一のテーブル千億ビッグデータ通信シーン、+スパークを使用すると、インパラケースを交換CarbonData

個人ブログのナビゲーションページ（クリック、右側にリンク個人のブログを開くために）：ダニエルは、テクノロジ・スタックにあなたを取ります 

[背景]

国内の携帯ゲームポイントインパラは、アセンブリ、一日の100TBの詳細を処理し、単一通信サービスの詳細を使用して処理し、単一のテーブルのレコードのレベルよりも大きい百億日の詳細、インパラプロセスの使用に問題があります：

1. 単一のストレージ・フォーマットの寄せ木詳細を使用して、データテーブル+ MSISDN番号がインパラのクエリを使用して、時間パーティションを行い、クエリのシナリオは、パーティションを使用していない、クエリのパフォーマンスが比較的貧弱です。
2. インパラを使用しての過程で、あなたは、（スローシンクロメタデータ内のカタログのメタデータ拡張の結果として）パフォーマンス上の問題の多くは、と同時クエリのパフォーマンスの低下を満たしています。
3. インパラはMPPアーキテクチャに属し、同時クエリの数は、一般的に約20に達したときのみ、百個のノードレベルを行うことができ、システム全体のスループットは、拡張ノードは、スループットを向上させることができない、フル容量に達しています。
4. Hadoopクラスタは、インパラ、スパーク、ハイブおよびその他のコンポーネントを共有する動的なリソースを達成することはできませんのでYARNリソースは、リソース管理スケジューリングを統一することはできません。単一のクエリ機能の第三者への公開の詳細は、リソースの分離を行うことはできません。

[ソリューション]

私たちは、お客様に適切なソリューションを提供モバイルゲームポイント、上記の問題の範囲については、我々は上記の問題のためにビッグデータのチームを分析し、メイク技術の選択は、プロセスでは、我々はいくつかのイニングこのポイントに移動します入力として、典型的なビジネスシナリオは、それぞれ+ CarbonData、Impala2.6、HAWQ、Greenplumは、SybaseIQプロトタイプ検証、パフォーマンスチューニング、当社のビジネスシナリオデータロードのパフォーマンスの最適化CarbonData、オープンソースコミュニティCarbonDataへのクエリのパフォーマンスと貢献をスパーク最終的に我々はスパーク+ CarbonDataプログラムを選んだ、これはHadoopのソリューションの典型的なSQLですが、また、間接的なHadoop移行上のSQLへの従来のデータウェアハウスの傾向を確認しました。私たちの検証テストと理解した上で組み合わせたリファレンスコミュニティ公式サイトのデータ、：CarbonDataは、大幅にスパークで行われ、綿密な統合を加速するために、特に大量のデータの場合には、ビッグデータHadoopの生態高性能データ・ストレージ・ソリューションである、スパークはすべての生態系の機能（と互換性がありますSQL、ML、データフレームなど）、ビジネスシナリオのさまざまなニーズを満たすためにスパーク+ CarbonDataデータは、次の機能が含まれています。

1. ストレージ：ラインメモリアブロと同様列格納寄木、ORCに似た行、列、ファイルストレージ、、。法案、丸太、水やその他のデータに対して複数のインデックス構造をサポートします。
2. 計算：エンジンのスパーク深い統合と最適化と計算;サポートとプレスト、FLINK、ハイブや他のエンジンドッキング。
3. インタフェース：
   1. API：互換性DATAFRAME、MLlib、Pyspark他のネイティブAPIインタフェース;
   2. SQLは：スパークは、基本的な文法と互換性があり、構文拡張はCarbonSQL（更新プログラムのアンインストール、インデックス、事前集計テーブルなど）をサポートしています。
4. データ管理：
   1. サポート増分データ・ウェアハウス、バッチデータ管理（経年変化管理）
   2. サポート・データの更新、削除
   3. サポートとカフカのドッキング、ほぼリアルタイムストレージ

       詳細な導入とキーテクノロジーの使用は、文書https://carbondata.apache.org/を表示するために公式サイトをご覧ください  

[はじめに]技術選択

ここで究極の解決策として、Hadoopの技術上のSQLを選択した理由を説明し、補完。

大規模な人の連絡先データが5Vのビッグデータ機能、モバイル・インターネット・データへの従来のインターネットからのデータがあることを知って、今非常に人気のIoTに、実際には、業界のあらゆる進歩で、データ量の面で2表示されます。成長の三桁まで。ボリューム、ベロシティ、バラエティ、価値、真実性：そして今、データの成長は今、モバイルインターネット、ビッグデータなど、モノのインターネット、を含む、前方5つの機能を入れて、成長加速の傾向を示しています。データウェアハウスの成長の挑戦伝統的なデータ量でより多く発生しました。

従来のデータ・ウェアハウスの課題：

データシステムは、常に進化している間

•ストレージの進化：オフライン、ニアライン - >すべてのオンライン

•ストレージ・インフラの進化：集中ストレージ - >分散ストレージは、

•ストレージの進化のモデル：固定構造物 - >柔軟な構造。

進化データ処理モード

•固定アルゴリズムモデルを修正 - >柔軟なアルゴリズムの柔軟なモデル

進化のデータ処理タイプ

•構造シングルソースが計算集中 - >マルチ構造のマルチソース分散コンピューティング

データ処理アーキテクチャの進化

•スタティックデータベース処理 - >データのリアルタイム/ストリーミング/質量処理

キンボールは、データベースの変更の親のために上述した観点を作りました。

   キンボールのコアアイデア：

  処理するデータの数と伝統的な倉庫、Hadoopのに切り離さ3に従来のデータベース処理装置を変更するのHadoop。

•ストレージ層：HDFS

•メタデータ層：Hcatalog

•クエリ層：ハイブ、インパラ、スパークSQL

より多くのユーザーが選択するために読むのスキーマ：

•元の形式のインポートでデータ記憶層

•メタデータ層を介してターゲットデータ構造を管理します

•クエリレイヤからデータを抽出するタイミングを決定します

•長期的な探査やデータに精通しているユーザーの後、あなたがテーブルの真ん中を硬化させる書き込みモードにスキーマを取ることができますが、クエリのパフォーマンスを向上させます

いいえ。	RDBMSベースのデータ処理モード	データ処理モードのHadoopに基づきます
1	強い整合性	より効率的なデータ処理の最終的な一貫性、正確性
2	データは変換する必要があります、またはフォローアッププロセスを続行できません	データは元の形式で変換、長期保存を行うことはできません
3	データはパラダイム、洗浄しなければなりません	データは、クリーニングと正規化のために推奨されていません
4	基本的には物理テーブルに格納されたデータ、ファイルアクセスの効率が低いです	ファイルに格納されたデータのほとんどは、テーブルには、物理​​的に構造化文書に相当します
5	メタデータは、辞書テーブルに限定しました	拡張サービスメタデータHCatalog
6	SQLデータ処理エンジンは、一種類のみです	オープンデータ処理エンジン：SQL、NOSQL、のJava API
7	データ処理は完全にITスタッフによって制御され、	データエンジニア、データ科学者、データアナリストは、データ処理に参加することができます

HadoopのデータウェアハウスのSQL

データ処理・解析

     Hadoopの上•SQL

     •クーズーインパラ+、スパーク、HAWQ、プレスト、ハイブ等

•データモデリングとストレージ

           •スキーマを読んで

           •アブロ＆ORC＆寄木＆CarbonData

•ストリーム処理

           •水路+カフカ+スパークストリーミング

SQLオンHadoopの変更のための技術開発と成熟

テクニカル分析上記の後、我々は最終的には当社のプラットフォームの将来の方向として、技術のHadoopのデータウェアハウスの進化にSQLを選んだ、誰かが、我々はまた、HadoopのとMPPDBにSQLを置くここで、なぜMPPDBにこの技術を選択しないでください、お願いするがなければならないこと比較分析を通じて（注インパラは技術類似MPPDB実際には）：

比較項目	Hadoopの上のSQL	MPPDB
フォールトトレランス	きめの細かい作業ですきめ細かいフォールトトレランス、寛容、のサポートが自動的に再試行失敗します、していないクエリ全体を再送信	粗粒フォールトトレラント、下位ノード（落伍者ノード）を処理することはできません。フォールトトレランスは、粗粒度のタスクの実行の失敗は、クエリ全体が失敗する原因になります結果を得るために再度提出するクエリ全体のシステムです
拡張性	クラスタノードの数は、数百あるいは数千に拡張することができます	（我々は32以上Greenplumは機械性能の低下を使用する前に、認証など）は、一般に50個のノードについて、100の以上のノードに拡張することは困難
同時実行	利用可能なリソースの増加クラスタサイズ、同時ほぼ直線的な成長の数と	MPPDBは、クエリのパフォーマンスを改善するためのクエリをリソースを最大限に活用し、同時の数がサポートさゆえ低くすると、同時クエリの数は、一般的に20に達し、システム全体のスループットは、全負荷状態に達しています
クエリの遅延	図1に示すように、データサイズが1PB、単一表10億レコードレベル未満である、単一のクエリレイテンシは10Sの周囲に通常 図2に示すように、データサイズがそのクエリのパフォーマンスを確実にするためにクラスタリソースを増加させることによって、1PBよりも大きいです	図1に示すように、データサイズが単一のテーブル1000000000録音レベルは、1PB未満である、単一のクエリは、ミリ秒あるいは数秒以内に、典型的にMPP遅延クエリ結果を返すことができます 図2に示すように、データサイズが1PB、建築制限を受けるよりも大きい、クエリのパフォーマンスは急激な減少を表示されること
データ共有	ストレージ及び計算別、共通ストレージフォーマットは異なるデータ解析エンジンをサポートすることができる、データマイニングを含みます	独自のストレージフォーマットMPPDBデータベースは、他のデータ解析エンジンを直接使用することはできません

[効果]スキームの実施形態は、

   CarbonDataまたインパラがピーク時に、これまでに書類日あたり100TBより量以上の処理を実行した後にラインスパーク+の端9でゲームポイント2018は、インパラ平均単60メガバイト前のデータロードのパフォーマンスは、/のS /インターネット、単一の100メガバイトによ一般的なビジネスシナリオ、20回の同時クエリでクエリのパフォーマンスでパフォーマンス、ゲームポイント、スパーク+ CarbonDataのクエリのパフォーマンスが倍以上インパラ+の寄木細工です。

次の問題に対処しながら：

1. Hadoopのクラスタリソースの共有、インパラ糸リソースはリソース・スケジューリング管理を統一することができない、スパーク+ CarbonDataは、ダイナミックリソーススパーク、ハイブおよび他の成分のような他の人と共有し、ユニフォーム・リソース・スケジューリング管理を糸ことができます。
2. Hadoopのクラスタ拡張の問題は、今+ CarbonDataがクラスタ規模で数千のノードを行うことができますスパーク、インパラ・マシンの前にのみ百台を使用しています。

注実装プロセスアイテム：

1. データは、小さなファイルのあまり大規模なクラスタで回避問題へ順に、負荷への道のCarbonData地元の並べ替えを使用してロードされ、ロードのみ、指定されたデータは、テーブルに圧密のレベルを指定することができ、各テーブルのロードのために少量のデータに加えて、マシンの数が少ない上にロードされます小さなファイルは、プロセスで生成された負荷をマージします。
2. クエリトラフィック特性は、フィルタは、多くの場合（例えば、電気通信サービス加入者しばしば番号照会など）ソート列属性データテーブルにクエリフィールドであり、クエリ頻度の最初のフィールドに配置されたソート列を降順にフィールドの順序を設定します、クエリ周波数以下の場合、ハイからローに異なる値フィールドに応じて、クエリのパフォーマンスを向上させます。
3. 、ブロック・サイズを提供し、単一のデータテーブルのファイルブロックサイズがTABLEPROPERTIESによって定義することができるMB、デフォルト値1024メガバイトで単位のデータテーブルを作成します。このあなたが私たちの経験に基づいて、実際のデータテーブルをロードするデータの量たびに応じて：一般的な推奨データテーブルのブロックサイズは256メガバイト、512メガバイトに設定されているブロックサイズのデータ​​テーブルを大量に設定されているの少量。
4. チューニングクエリのパフォーマンスだけでなく、ビジネスのクエリの特性は、そのようなデータマップとしてクエリ高周波フィールドは、クエリのパフォーマンスを向上させるためにブルームフィルタを作成します。
5. データのロードとクエリのためのいくつかのスパーク関連するパラメータは、意図的なパラメータを、一つ一つが導入されていないパラメータに関連する目標の調整でパフォーマンスのボトルネック第1の合成SparkUIポイントを、分析、パフォーマンスチューニングは、技術であることを念頭に置いておくと、目標との調整、1つまたは複数のパラメータを転送するために関連した調整を調整するために、効果を見ては、パラメータの数が多すぎ1時間調整を覚えていない、調整背面に有効になりません。

付属のJava / C / C ++ /機械学習/アルゴリズムとデータ構造/フロントエンド/アンドロイド/パイソン/プログラマ読み/シングル書籍図書Daquanは：

（乾燥した個人ブログでそこ開くには、右クリックしてください）：技術的なドライ開花を
===== >> ①[Javaのダニエルは、高度なへの道であなたを取る] << ====
===== >> ②[+ ACMアルゴリズムデータ構造ダニエルは、高度なへの道であなたを取る] << ===
===== >> ③[データベースダニエルは高度への道であなたを取る] << == ===
===== >> ④[ダニエルWebフロントエンドの高度への道であなたを取るために] << ====
===== >> ⑤[機械学習のPythonとダニエルあなたにエントリを取ります高度なロード] << ====
===== >> ⑥[建築家ダニエルは高度への道であなたを取る] << =====
===== >> ⑦[C ++ダニエルは、道路上をお連れに進ん] << ====
===== >> ⑧[ダニエルは高度への道であなたを取るのiOS] << ====
=====> > ⑨[ウェブセキュリティダニエルは、高度なへの道であなたを取る] ===== <<
===== >> ⑩[Linuxオペレーティングシステムを、ダニエルは高度への道であなたを取る] = << ====

何の未収果物はありません、あなたの若い友人は、友人がテクニックを学びたい願って、道路の方法ですべての障害を克服することは、技術に結びつける本を理解して、コードをノック、原理を理解し、実践を行くことになります決定しましたそれはあなたの将来、あなたの夢を生活、あなたの仕事をもたらすでしょう。