スターロック build

スターロックスビルド

2024-07-12

同社は新しいビッグデータアーキテクチャの使用を望んでおり、海外のビッグデータプラットフォームを国内のものに置き換える計画を立てている。そこで、doris を使用するか starrocks を使用するかで迷っています。doris を使用すると、将来的にはクラウドベンダーを直接使用できます。スターロックを使用する場合は自分で構築する必要がありますが、将来的には必ず商品化され、お金を請求する必要があります。 dorisは使ったことがありますが、starRocksは使っていませんでした。本当に下の参考リンクと同じくらい高性能なのか試してみたかったので、starrocksを選びました。以前の CDH の hive-presto または kudu-impala を置き換えるデータウェアハウスとして使用します。

starRocks がハイブの代わりになると思いますか?それは可能だと思います。Hadoop セットは 20 年前にうんざりしていました。Hadoop セットには非常に多くのコンポーネントが含まれており、過去 20 年間に発生したほとんどすべてのバグが修正されているということです。。 Hadoop を使用する必要はまったくなく、代わりに starRocks を使用できます。

CPUが対応しているか確認する

cat /proc/cpuinfo | grep avx2

何も印刷されない場合は、CPU を変更できます。

Be が計算を担当します。この命令セットがなければ、デプロイできません。

導入

startrocksは、従来のハイブに代わる【データ分析】のための【データウェアハウス】です。ベクトル化，MMP アーキテクチャのカラムストレージエンジン、サポートリアルタイム分析、同時コンピューティング。mysqlプロトコルと互換性があり、使用可能mysqlクライアントのドッキング。サポート横展開。システム全体には外部依存関係がありません。つまり、Zookeeper が管理する必要も、メタデータが mysql に存在する必要もなく、システム自体を維持するだけで十分です。

ログデータや健康診断レポートなど、分析に使用されるデータは書き込まれた後に変更されないため、更新などのトランザクション操作には適していません。

ベクトル化: データをベクトル化した後、CPU は 1 つのアイテムしか処理できませんでしたが、現在は複数のアイテムを同時に処理できるようになるという事実を指します。

MPP アーキテクチャ: 大規模な並列処理アーキテクチャ。データを複数のマシンに分割して一緒に実行し、大量のデータを処理します。

列ストレージエンジン: 列を管理し、幅の広いテーブルストレージと分析をサポートします。MySQL はフィールドが多すぎると高速で、列をリアルタイムで更新できます。

リアルタイム分析: クエリ分析速度は比較的速く、ミリ秒レベル

Mysql クライアントのドッキング: たとえば、navicat または jdbc はそれに直接リンクできますか?検証対象

水平方向の拡張: 1 台のマシンでは弱すぎるため、分析能力を強化するためにマシンを追加し続けることができます。

サポート次のBIドッキング: Tableau、Power BI、FineBI、Smartbi を含みます。

リアルタイムデータウェアハウスとして、彼ができることは [第 2 レベル】データの同期、リアルタイムにできる【ミリ秒レベル】お問い合わせ。

システム構成（保守・構築時に必読）

システムのコアには、FE (フロントエンド)、BE (バックエンド)、または CN (計算ノード) プロセスのみがあります。

フロントエンド（表示インターフェース）、バックエンド（ロジック制御）、ノード

3.0 以降では、ストレージと計算の分離がサポートされており、永続データは HDFS に保存する必要があります。もちろん、ストレージと計算を統合することも選択できます。

3.0 は両方のアーキテクチャもサポートしています。

両者の違いは何ですか? ストレージと計算が統合されている場合は、データを startRocks にコピーする必要があります。ストレージと計算が分離されている場合は、HDFS のデータを直接使用できます。ストレージとコンピューティングを分離することで、コストとディスクが節約され、拡張時にストレージについて心配する必要がなく、コンピューティングノードを直接拡張するだけで済みます。欠点は、追加の外部データセットを維持する必要があることです。

ハイブリッド展開はサポートされていません。ストレージとコンピューティングが統合されている場合、ストレージとコンピューティングを分離することはできません。

Fe はコーディネートとカタログ管理を担当します

統合されたストレージと計算

責任を持ってくださいストレージそして計算する

Fe（詳細版）：

管理責任者メタデータ、クライアント接続の管理、クエリプランニング、クエリのスケジュール設定。

FE メタデータはメモリに保存され、ディスク上にもコピーが存在します。

FEにはリーダー、フォロワー、オブザーバーの3つの役割がある

リーダーは選出され、読み書きの責任を負います。書き込み後、メタデータが更新され、フォロワーとオブザーバーに同期されます。成功するのはフォロワーの半分だけです。

フォロワーには書き込み権限がなく、読み取り権限のみがあります

オブザーバーはフォロワーと同様に展開がオプションであり、クエリ速度を向上させることができ、選挙には参加しません。これはトラにさらに強力な権限を追加するのと同じです。

Be（詳細版）：

各 BE は同じです (リーダーやフォロワーはありません) が、すべての BE が完全なデータを持っているわけではありません。FE がデータを BE に割り当て、BE がデータを保存してインデックスを生成します。

計算では SQL を文法的な意味に従って論理単位 (コードレベル) に分割し、データ配信によると物理ユニット (ハードウェアレベル) になり、ローカルで実行されます。

メタデータ: 正直に言うと、Xiaobai の世話をするためだけに、これを書きたくありません。たとえば、データの種類は何ですか? 文字列か数値か? これはメタデータ、つまりデータを変更するために使用されるデータです。

クエリプランニング: プランがどの程度のパフォーマンスを消費するか、どの SQL を使用し、最適化し、物理プランに変換する必要があるか

クエリのスケジューリング: この物理計画を実行するものを選択します

保管・計算・引出しのデータを統合管理

starRocks の最小のストレージユニットはタブレットと呼ばれます。自分自身をパーティション化してからバケットを指定できます。

画像を時間列で区切って、4つのフィールド（4列、実際には1列でも可）にバケットを指定し、コピーを3つ指定し、各列のデータとデータ単位を指定します。異なる配下ノードに分散されます。 A-1、A-2、A-3はすべて同じデータであり、Aのバックアップです。

拡張時にサービスを停止する必要はなく、ノードを追加すると自動的に移行され、ノード数が減少するとデータは自動的に均等に分散されます。

記憶と計算の分離

紹介された【キャッシュ】概念では、Be は計算 [のみ] を担当します。Cnに名前変更(計算ノード-計算ノード)

キャッシュ: データはクエリ頻度に基づいて自動的にキャッシュされます。動的な変化

動的変更: メモリ、ローカル、外部ソースの 3 つのレベルに分かれています。最もホットなデータがメモリ内にあり、次に残りがローカルディスク上にあり、次にコールドデータ (使用頻度が低い) が外部ソースにあります。アクセス頻度に基づいた動的なデータ調整

個別のストレージと計算を使用してテーブルを作成する場合は、キャッシュを有効にするかどうかを指示する必要があります。

次のバックエンドストレージがサポートされています。

AWS S3プロトコルと互換性のあるオブジェクトストレージシステム（AWS S3、Google GCP、Alibaba Cloud OSS、Tencent Cloud COS、Baidu Cloud BOS、Huawei Cloud OBS、MinIOなどの主流のオブジェクトストレージシステムをサポート）
Azure BLOB ストレージ
従来のデータセンターに導入された HDFS

公式ウェブサイトのシステムアーキテクチャについて、すべての文章を私自身の言葉で書き終えました。以下から構築を開始します。