新しいHP Vertica：クレーンNo. 7

2013年12月、HP Verticaの新しい7番目のバージョンがリリースされました。 「小さなデータではなく」大規模な構築の伝統を継承して、このバージョンは「クレーン」と呼ばれていました（6番目のバージョンは「ブルドーザー」と呼ばれていました）。 この記事では、新しいバージョンでの変更点について説明します。

非構造化データの操作-フレックスゾーン

HP Verticaの新しいバージョンでビッグデータを使用する際の最も重要なステップは、CSVおよびJSON形式の非構造化データを使用した直接作業のサポートの登場です。 6番目のバージョンでは、CSVファイルからのデータのロードと外部グローバルテーブルとしてのクエリをサポートしていました。 ファイルデータに以前は不明なフローティング構造があった場合、Verticaでそのようなデータをダウンロードして操作する唯一の方法は、ETLツールなどの外部アプリケーションで前処理することでした。

Verticaは、構造化データと同じくらい簡単に非構造化データを操作できるようになりました。 次のようになります。


HP Vertica Flex Zoneは、非構造化データを保存および処理するための専用エリアです。 Verticaデータベースでは、フレックステーブルを作成し、CSVおよびJSON形式のファイルからデータをロードし、それらに対してクエリを実行し、このデータをVerticaリレーショナルテーブルと組み合わせます。 フレックステーブルに読み込まれたデータは、特別な形式でサーバークラスターのノードに保存されますが、リレーショナルデータベースデータと同じ原理に基づいています。 また、データ圧縮、ミラーリング、およびデータセグメンテーション（クラスターノード間の分散）もサポートしています。 このようなストレージを使用すると、処理中の非構造化データはVertica MPPアーキテクチャを最大限に活用し、フォールトトレラントなスケーラブルアーキテクチャで動作し、バックアップに参加します。

Flex Zoneの大きな利点は、Vertica（HDFS / Hadoopコネクタなど）と統合された外部ソリューションではなく、非構造化データに対する独自のネイティブサポートであるということです。 これにより、柔軟性と、外部製品のエラーおよびバージョン変更への依存がなくなります。 また、構造化データと非構造化データのテーブルを使用したクエリでのハイブリッド処理中の作業速度の保証も提供します。

Flexゾーンはどこで役立ちますか？ 簡単な例：動的（フローティング）構造のファイルをアップロードする必要があります。 さらに、どのデータが分析にさらに必要で、どのデータが必要でないかは事前にはわかりません。 Verticaの6番目のバージョンでこの問題を解決するためのオプションは次のとおりです。

1. ファイルに存在する可能性のあるすべてのフィールドを使用して、データベースにテーブルを作成します。 ファイル内の新しい列の外観を追跡し、それらをテーブルに追加します。 JSON形式の場合、形式を解析してデータをテーブルに書き込む追加のデータローダーを作成および管理します。 このソリューションは生産的ですが、開発と保守に費用がかかります。
2. 処理済みファイルを解析してCSV形式で書き込むタスクをHadoopで作成し、処理結果をHDFSに保存します。 結果のファイルを外部テーブルとしてHDFSでVerticaに接続し、処理に必要なフィールドを指定します。 新しいフィールドが表示されたら、構造を変更した外部テーブルの接続を再作成します。 このソリューションは開発が迅速ですが、保守が高価で生産的ではありません。

Verticaの7番目のバージョンでは、このファイルの処理、保存、および作業のタスクは、次の2つのSQLステートメントに削減されます。

1. フレックステーブルの定義（テーブルの作成）
2. データをフレックステーブルにアップロード（コピー）

Verticaでは、フレックステーブルでマテリアライズされた列を即座に記述できます（テーブルの作成/変更）。 これらの列は、列構造のVerticaテーブルの標準列としてロードおよび保存されると、すぐに値が入力されます。 残りの列は、作成されたビューを介して動的にアクセスできます。ビューは、特殊な機能によって再配置できます。 このアプローチにより、クエリの重要なフィールドとキーフィールドを具体化し、クエリ処理中に格納された残りの非構造化データを取得できます。 このハイブリッドアプローチにより、非構造化データに対しても高いクエリ実行速度を維持できます。

まとめると、フレックスゾーンを使用すると、非構造化データを簡単かつ確実に格納し、必要に応じてデータを抽出できます。 これにより、そのようなデータを処理するソリューションの開発と保守の複雑さが軽減され、さまざまなデータの分析の分野で優れた機会が提供されます。

FlexゾーンはVerticaクラスターサーバーで実行され、同じ場所で保存および処理されるため、構造化データと同じ方法で、つまりソースデータのボリュームに応じてライセンスが付与されます。 ここで、このようなライセンスの大きな欠点に気付きたいと思います。構造化データとは異なり、フレックステーブルは、データベースに保存するためにファイルデータのボリューム全体をロードします。つまり、ダウンロードしたものすべてがライセンスされます。 構造化されていないファイルのフィールドの半分しか使用されていない場合、そのようなデータを保存することはライセンスの観点から高価です。 そのような場合でも、非構造化HDFSファイルをストレージとして使用し、Hadoopで処理して、処理結果をVerticaに配信する方が便利であることがわかりました。 ただし、ライセンススキームはドキュメントにあまりにも曖昧に記述されているため、その条項を明確にし、将来的には登録を解除します。

HCatalogを使用したHDFSファイルの操作

Verticaの6番目のバージョンには、HDFSからフラットファイルをダウンロードする機能がありました。 外部テーブルとしてクエリに分析用のそのようなファイルを含めることもできました。 ここでの主な欠点は、HDFSからロードされたファイルの構造を正確に記述する必要があることです。 Verticaの新しいバージョンでは、フラットHDFSファイルの操作のサポートが拡張され、HCatalogインターフェイスへのコネクタを介してフラットテーブルを記述するメタデータがサポートされます。これは、Apache Hiveのフラットファイル（メタデータ）の構造の説明を格納します。 次のようになります。


HDFSファイルからデータをダウンロードするか、接続された外部テーブルとしてクエリを実行すると、VerticaはHCatalogサーバーからファイルのメタデータを受け取ります。 サーバーは、HDFSクラスターからファイルデータ自体をダウンロードして処理します。 Hadoop / Hive処理機能は使用されません。 Verticaのドキュメントでは、データ分析の分野での効率的なサーバーソリューションにより、Hadoop側で行うよりもVertica側でデータを取得してさらに処理する方が収益性が高いとされています。 このアプローチの追加の利点は、開発とメンテナンスのコストと呼ばれます。 ちなみに、同じドキュメントでは、大規模で重いデータ処理の場合はHadoopで行うことをお勧めしていると書かれていますが、ここではVerticaの効率が低下します。 したがって、ある意味で、VerticaはHadoopと統合するだけでなく、分析データ処理の分野でも置き換えを試みており、独自の非構造化データ処理アルゴリズムとFlexゾーンでのデータストレージの両方を提供しようとしています。

大規模なクラスター管理

MPPの時間Xは常に遅かれ早かれ、メッセージ転送とネットワーク調整のコストがシステムのボトルネックになり始めると、クラスターサーバーの数が重要な値に達します。 どうやら、HP Verticaサーバーは、数百および数千のサーバーが奇跡ではなく働く瞬間の企業に成長したようです。 そのため、第7バージョンでは、クラスターサーバーのネットワーク機能が大幅に拡張されました。 これで、Verticaの通常のブロードキャスト操作モードに加えて、「大規模クラスター配置」モードを有効にできます。これにより、多数のサーバーを持つクラスターのVerticaの操作を最適化できます。 Verticaのドキュメントでは、クラスター内の120台のサーバーと、それらの間に高いネットワークアクティビティがある場合は少数のサーバーの両方で使用することを推奨しています。 大規模クラスターモードの原則は、そのノードがネットワーク相互作用のコーディネーターが割り当てられるグループに結合されることです。 各グループ内で、ノードは互いに通信し、グループ間では、グループコーディネーターがネットワーク通信を担当します。

大規模なクラスターにとって重要な別のMPP問題があります。サーバーのグループのフォールトトレランス（ラック）です。 ご存知のように、Verticaは隣接ノード間でデータをミラーリングします。 7番目のバージョンまで、これは自動的に行われ、ミラーリングの順序を示すことはできませんでした。 これにより、多数のサーバーラックがあり、ラックの1つが切断された場合、クラスター全体の動作が危険にさらされました。 隣接ノードがクラスターから消え、作業を強制的に停止することが判明しました。 7番目のバージョンでは、この問題は「障害グループ」を使用して解決されました。 ここで、データベースについては、ラック上のサーバーのグループをペイントし、それらの作業クラスターノードをペイントする機会があります。


データをセグメント化するとき、Verticaサーバーは、サーバーデータのミラーが異なるフォールトトレラントグループに保存されるようにします。 したがって、サーバーの1つのグループ（ラック）をオフにしてもクラスターは停止しません。これは、他のグループがクラスターを操作するために接続できるミラーを持つためです。

JDBC API Key-Value

当初、HP Verticaは分析データサーバーとして設計されており、大量のデータをすばやく分析できます。 サーバーの機能は徐々に成長し、Verticaはすでに本格的なBigDataサーバーと呼ばれるようになり、構造化データと非構造化データの両方を処理できるようになりました。 BigDataサーバーは、データをすばやく分析できるだけでなく、キーごとに値を検索できる必要があります。つまり、Key-Valueサーバーとして機能して、データへの高速アクセスをサポートする必要があります。 Verticaチームは、製品のすべてのBigData要件をカバーすることを真剣に決定し、Vertica JDBCドライバーの拡張を通じてこの機会を実現しました。 最初は、Verticaのキーによる情報の検索は、キーによるWHEREのフィルターを備えたデータベース内の通常のSELECTクエリのように見えました。その結果、クエリはクラスターサーバー間で分散され、クラスターノードの1つが目的の結果を見つけて呼び出したクライアントセッションに返すまで全員が作業を開始しました。 。 次のようになります。


これで、Key-Valueインターフェイスを使用して、次のようにデータを要求できます。

VGet get = conn.prepareGet("public", "users"); get.addPredicate("id", 5); ResultSet rs = get.execute(); 

このコードが実行されると、JDBCインターフェースは、クラスター内のどのサーバーに必要なレコードが含まれているかをすぐに判断し、受信します。


レコードをセグメント化するための特定のルールと、処理されたテーブル内のPK / UKキーの存在により、Key-Valueで作業が達成されます。 処理中のテーブルでこれらのルールがないと、このメソッドは機能しません。

要約すると、Key-Valueインターフェイスを使用すると、CPU時間、ディスク、およびネットワークアクティビティでクラスターサーバーに不必要な負荷をかけることなく、多くのセッションで特定のキーのデータをすばやく検索および取得するための非常に効率的な方法を編成できます。 これは、主にWebに関連する企業に高く評価されていると思います。キーに基づいて情報を見つける速度は常に重要です。

クライアントドライバー

JDBC 4標準のサポートがVertica JDBCドライバーに追加され、これは主にJNDIを使用するソリューションに役立ちます。 ドライバを介したデータベースメタデータの取得のサポートも拡張され、接続プールの操作が改善されました。

すべてのドライバーについて、「接続フェイルオーバー」および「接続負荷分散」のサポートが導入されています。 リスト内の前のホストが使用可能でなかった場合、順番に接続できるホストのリストを指定できます。 また、接続の場合、接続のバランスをとるオプションを指定できます。 次に、リストで最初に利用可能なホストに接続すると、接続されたサーバーは、クライアントの接続を別のよりビジーでない利用可能なホストにリダイレクトできます。 これらの機能により、サードパーティのロードバランサーの機能が実質的に不要になります。

ユーザーを識別するために、Kerberos 5プロトコルもクライアントドライバーで使用できます。

ドライバは、バッチ挿入用に最適化されています。 ベンダーによると、挿入速度ははるかに速くなり、クライアント側で必要なリソースが少なくなりました。

パフォーマンスと復元力

サーバー障害の場合に最適化されたクラスター操作。 これは、クラスターの他のノード間で計算負荷が均一に再分散されるために達成されます。 以前は、ミラーを含むネイバーは障害が発生したノードで動作する必要があり、2つのノードで動作しているノードが自身とフォールドネイバーの計算を行っている間、動作中のノードを待機するため、クラスターのパフォーマンスが全般的に低下しました。

多数のレコードを持つテーブルの一意のフィールド値の数を計算する処理を高速化するために、エラーのある量の概算の関数が追加されています。 これにより、エラーが許可されている場合、クエリの実行を大幅に高速化できます。

オプティマイザーは、GROUPBY PIPELINEDアルゴリズムとGROUPBY HASHアルゴリズムのハイブリッドを使用して、グループの部分的なソートのための新しいアルゴリズムをサポートするようになりました。 これにより、ソートされた列の一部を使用したより効率的なデータ集約クエリが可能になり、メモリ消費とハッシュ用のディスクスワップが削減されます。

MERGE演算子は、データと、挿入および変更のための同じ列と値のセットを結合するために使用されるPK / UKキーを持つテーブルに対して高速化されています。 これらの条件が満たされない場合、最適化なしで以前のバージョンのアルゴリズムに従ってテーブルが結合されます。

COPYデータローダーの動作が改善され、ダウンロードされたファイルの解析と解析は、ファイルをいくつかの部分に分割し、ノードのカーネル間で並列処理することにより、より効率的になりました。

SDK拡張

Verticaの以前のバージョンでは、独自のスカラー（単純）関数、データ変換関数（olap）、およびCOPYおよびCREATE EXTERNAL TABLEステートメントでロードされたデータを処理するための関数を記述することにより、Cでサーバーの機能を拡張できました。 現在は、Javaプラットフォームでも使用できます。 特にこのために、HP Verticaの新しいバージョンにはJava SDKが含まれています。

その他の拡張機能

Webコンソール（管理コンソール）の機能を大幅に拡張しました。 このツールは、システム監視ツールから本格的なクラスター管理ツールにますます変換されています。 現在、コンソールはプランとクエリ実行プロファイルの表示をサポートし、デザイナーを起動して新しいプロジェクションを最適化および作成します。 コンソールスキンのサポートも追加されましたが、これが必要な理由はわかりません。

Database Designer自体が大幅に改善されました。 列のセグメンテーションとパッキングの最適な候補を決定するための再設計されたアルゴリズム。 列の相関関係（列間の密接な関係）を分析する機能が追加されました。つまり、データプロファイリングが分析で実際に使用されます。 指定されたテーブルとクエリのデザイン領域をプログラムで作成し、それらを分析して新しい投影を追加したり、より最適な構造で既存の投影を変更したりできる機能が追加されました。 これにより、データ要求を実行するチューニング作業を自動化できます。 たとえば、指定された時間に大量のクエリのコレクションを独自に開発および計画し、それらを分析して、データベースに自動的に適用するか、将来手動で実行するためのスクリプトとして保存することで、データ構造を最適化するための推奨事項を取得できます。 さらに、クエリグループの概念が導入されているため、設計者は一般的なクエリを識別し、使用頻度の重みを考慮して最適化を実行できます。 これにより、たとえば、1日に1回実行された場合に、夜間の重いクエリで不要な予測を作成しないようにできます。

サーバーインストールシステムの改善。 現在、Verticaは、より多くのOS設定を個別にチェックし、それらを修正しようとします。 不可能な場合は、インストール中に手動設定の推奨事項が発行されます。

SQL言語、関数、サービステーブル、構成パラメータなどの機能も拡張されました。 これらはすべて、HP Verticaのドキュメントで詳細に見つけることができます。

記事の要約

HP Verticaは、低出力のブルドーザーから高出力のクレーンにまで成長しました。 BigDataの構築は本格的です。 拡張機能を備えた6番目のバージョンのパックが引き続き適切に機能することを考えると、変更の量は本当に印象的です。

著者Konstantinov Aleksey
データウェアハウスアーキテクト
EasyData Company

記事の情報を使用する場合は、著者に問い合わせてください。