一連の記事
記事ディレクトリ
この記事は、主にデータ製品とデータサービスのセクションのデータリソースとサービスに関連しています。この記事の内容は次のとおりです。
1.アプリケーションシナリオ
背景：このビジネスがMeituanアプリ全体にどのように影響するかを理解したいと思います。
「GrowthHacker」は、本質的に漏斗状の分解とトラフィック変換の分析である海賊モデル手法について言及しました。ユーザー獲得からユーザー変換およびアクティブ化までのステップと、対応する分析方法が含まれています。
ただし、メソッドだけでは不十分であり、対応するデータサポートが必要です。データはどのように編成されていますか？これは5つの部分に分かれています。
これらの分析を行うとき、私たちは何をすべきですか？
次のSQLに依存します。
最初にFROM、関連注文テーブル、都市テーブル、都市ディメンションテーブル
を見て、次にWHEREを見て、バス事業を選択し、8月18日から8月19日の間に注文を買い戻し、次に
GROUPBYとSUMを見てください。基本的には明らかです。アップ。
ここでは、前述のOLAP分析を使用します。OLAP分析の方法は何ですか？ここで言及されているのは5種類あります。
- ドリル（ドリルダウン）：寸法を大きくし、問題をより細かく分析します。（長方形の平行パイプが1つの層を持ち、3つの層に拡張すると仮定します）
- ロールアップ（ドリルアップ）：寸法を縮小し、マクロ（相対）の観点から問題を確認できるようにします。（キューブに3つのレイヤーがあり、1つのレイヤーに圧縮されていると仮定します）
- スライス：同じ次元で、1つの値のみが表示されます。（キューブに3つのレイヤーがあるとすると、1つのレイヤーのみが保持されます）
- ダイシング：同じ寸法、わずかな値のみ。（キューブに3つのレイヤーがあるとすると、2つのレイヤーだけが残ります）
- ローテーション：ランク変換。
一部の商用BIシステム
2、システムアーキテクチャ
2.1。システムアーキテクチャレビュー-Presto
広く使用されている代表的なデータベースの紹介に焦点を当てて、分散SQLステートメントがどのように実行されるかを確認します。
まず、Meituanのデータベース選択のアイデアを紹介します。主に次の3つのシナリオに分けられ
ます。次の段階で紹介するPrestoは、主にアドホッククエリの部分です。興味があれば、プレストの進化の歴史を見てみましょう。
簡単に言うと、設計コンセプトは信頼性とパフォーマンスのトレードオフです。前に説明したSparkとMap Reduceはシャッフルプロセスに配置されるため、ノードがダウンしている場合でも、以前のベースですばやく構築できます。実行し、以前のデータを可能な限り再利用します。しかし、プレストはこの問題を考慮していませんでした。彼の位置付けは、ハイブとスパークの超大規模シナリオに関連しています。
それからあなたがそれを保持することができないならば、あなたは速く失敗するでしょう。他のタイプのデータベースのデータを関連付けることもできます。
マクロの観点から見ると、全体の構造は上図のようになっています。青いものはPresto自体のサービスであり、前面はMySQLコマンドラインと同様のクライアントタイプのコントロールです。MetaStoreは基本的に、テーブルとライブラリのメタデータをHDFSに保存します。（人形は禁止されています）
Prestoは依然としてマスタースレーブ構造であり、Cordinatorはコーディネーターであり、Workerはワーカーです。
詳細な構造を図に示します。
クライアントは、コーディネーターでSQL、分析、計画、分割、およびスケジュールを送信し、各ワーカーが管理するモジュールを送信します。各ワーカーがタスクを取得した後、データはHDFSからスキャンされ、計算されます。各ワーカーが集計された後、ストリームインターフェイスがクライアントに返されます。
重要なのはコーディネーターの内部処理です。
文法を解析する方法は？これには実際にはコンパイルの原則の知識が含まれ、字句分析、文法分析などを通じて構文ツリーが生成されます。
構文ツリーはどのように見えますか？おそらく
、SQLexplainデータベースでステートメントを作成するのが好きで、次に実行する方法がわかります。上で得られた構文ツリーに従って、実行プロセスの論理計画が構築されます。
Prestoによるデータソースへのアクセスの要約は次のとおりです。SQL自体はデータの読み取り層でシールドされています。これには、データソースにアクセスするためのいくつかの構成が必要です。
これがSQLの最適化部分です。pvは、ユーザーが表示するテーブルです。
通常、SQLを作成するプロセスは、pvとuserを関連付けてから、適格な行を選択することです。ここで最適化できますか？もしそうなら、それを最適化する方法は？
データが多い場合は、関連付けテーブルの前に必要なデータを除外すると便利です。Prestoでは、関連付ける前に、テーブルをスキャンするときにすべてのデータが取り出されるわけではなく、siteIdとuseridのみが関連付けに使用されるため、より効率的になります。
これらの最適化を達成する方法は？最初にいくつかのルールを定義し、次にこれらの論理プランのツリー構造に基づいてこれらの最適化された戦略を繰り返し実行しますが、同様の構造が見つかった場合はいつでも、論理プランのツリーを調整してSQL全体をより効率的にすることができます。
論理計画を最適化した後、論理計画を物理的に実装する方法を検討する必要があります。
この分割は、主にオプティマイザーの抽象化に基づいています。次に、セグメンテーションが終了した後、いくつかのシャッフルとグループ化およびHashJoinが実行されます。
こちらのシャッフルは販売しておりません。
質問：シャッフル中に注文しない場合、SQLはどのような制限を課しますか？（ヒント：参加時/グループバイ）
回答：関連付けまたはマージするとき
に、同じノードで同じキーのデータを計算したいのですが、データスキューが発生すると、データが多すぎるとノードのメモリが爆発します。
次に、各ノードで個別に実行されるようにスケジュールされた分散実行プランを取得します。これは、コーディネーター内の詳細な実行ロジックです。
以下は、物理的な計画のスケジュールです。
Prestoは、codegenなどのいくつかの物理レベルのプログラムも実行します。主な機能はランタイムコンパイラです。
もう1つの最適化は、部分ストレージレイヤー、データインデックス、およびデータ編成構造の最適化です。行ベースのストレージ構造から列ベースのストレージ構造（ORC、寄木細工など）を導出します。
2.2。分散型OLAPシステム拡張テクノロジー
一部のシステムのアーキテクチャ設計を実装する場合、いくつかのトレードオフを導入します。主に、Kylin、Druid、Clickhouse、Dorisの4つのシステムを紹介します。
2.2.1キリンとキューブの事前集計
オープンソースバージョンと商用バージョンがあります。特定の機能は予備重合です。どういう意味ですか？
ファクトテーブルには多くの次元があると仮定すると、多くの場合、これらの次元に従って集計する必要があり、Kylinはそれを見つける前に集計します。見つかったら、Kylinに移動して選択します。これは、データキューブ分析で一般的に使用されます。
2.2.2 Druidとストリーミング書き込みの分離、ディメンション列が反転します
Druid自体も列ストレージであり、最も極端なのは反転インデックスです。これは、ビットマップを使用して列の値を格納するインデックスです。
たとえば、列の広告主には2つの値があり、列全体をスキャンしてビットマップを取得します。{"bing.com"：[0,0,0,1]、 "google.com"：[1、1、1、0] }。配列の長さは、列の行数です。bing.comに対応する[0,0,0,1]は、4番目の行に表示されるbing.comの値を意味します。なぜ4なのですか？配列内の1の位置/インデックスは4（インデックス1から開始）であるためです。また、google.comに対応する[1、1、1、0]は、google.comが1、2、および3行目に表示されることを意味していることも簡単にわかります。
このようにWHERE、and操作直後に複数の条件が取れる場合、操作効率はになります。
2.2.3クリックハウスとSIMD
これは主に、ハードウェアとメモリを使用して、CPUを最大限に活用できるオンサイトコンピューティング機能を向上させることによるものです。
2.2.4ドリスと私たちの統合計画
ドリスはまとまりがあり、主要な外部依存関係はありません。MySQLプロトコルと互換性があります。（以前はPaloと呼ばれていましたが、OLAPの逆です）
フロントエンドはPrestoの水平拡張コーディネーターと見なすことができ、Bankendは水平拡張ワーカーとストレージを追加したものと見なすことができます。
LSMツリーモードを使用します。高速で大規模なバッチを作成するときの全体的なスループット容量を改善しながら、KVクエリの結果をより速くしたいという問題を解決しました。
3、変換の場合
3.1 Presto on Yarn
Prestoの柔軟なスケーリング、クエリスケジューリング、およびYARNをバインドします。
3.2統合ADhocクエリ1つのSQL
主に複数のエンジンの異なる方言の問題を解決するために
再構築されたアーキテクチャを図に示します:(
トレーニング決定ツリーモデルもあり、そのデータベースで特徴判断文の抽出が高速になり、対応するエンジン方言が生成されます）
3.3統合OLAP構築
3.4データベースの比較方法
多次元の観点からデータベースを比較することにより、データベースのコンテンツとSQLの構造を構築し、その構造を使用してデータベースの実装をテストするのに役立つ2つの方法があります。
これは、変換後のパフォーマンスの比較です。
学ぶことは簡単ではなく、賞賛と収集です。