あなたはそれが強力なOLAPデータベース（下）である必要がある|あなたは、リアルタイムの倉庫の数を必要としません

前の章では、我々は今日のビッグデータに、インターネット技術の開発をリアルタイムデータウェアハウスの構築について話しました、基本的なフィールドが成熟してきた、私たちの選択のためのソリューションの広い範囲があります。

リアルタイムで倉庫建設の数は、ソリューションが成熟し、メッセージがカフカ、Redisを、HBaseのいくつかのライバルは、ほぼ独占状態となっているキューに入れます。位置の数のリアルタイムOLAPの選択の全体の容量が制限されています。この章私たちは、分析のために最も人気のあるオープンソースのOLAPエンジンデータの一部を選択しているオープンソースの精神は、今日、我々は、OLAPデータベースまぶしいの選択および使用のために、技術の選択はあなたを提供するために、希望と将来のインフラストラクチャのアップグレードを与えるために行われていることができますいくつかの助け。

本論文では、一般的に使用されるオープンソースのOLAPエンジンの性能評価：
https://blog.csdn.net/oDaiLiDong/article/details/86570211

競合OLAP

OLAPの概要

また、オンライン分析処理（オンライン分析処理）システムとして知られているOLAPは、時々、私たちは、データウェアハウスと呼んでいるもの、DSSの意思決定支援システムと呼ばれます。これに対し、OLTP（オンライントランザクション処理）、オンライントランザクション処理システムです。

オンライン分析処理（OLAP）の概念は、1993年に初めて親EFCoddリレーショナルデータベースによって提案されました。OLAPは、明らかなオンライントランザクション処理（OLTP）と製品の別のクラスとして大きな反響、OLAPを引き起こし提案しています。

コッドは、オンライン・トランザクション処理（OLTP）データベースは、ユーザ分析のニーズを満たすことができないだけで、大規模なデータベース上のエンドユーザーのクエリと分析要件、SQLクエリを満たすことができないと思います。ユーザーの意思決定分析結果、およびクエリの結果を取得するには、リレーショナルデータベースの多数の計算を必要とし、調達政策立案者のニーズを満たすことができません。したがって、コッドは、そのOLAPを多次元および多次元データベースの分析の概念を提案しました。

OLAPオンライン分析処理の委員会の定義は以下のとおりです。生データから出て変換、ユーザーが真に理解し、情報データと呼ばれる多次元のビジネスデータの真の性質を反映することができ、アナリスト、管理職や幹部を有効にすることができますから、データをより良く理解するソフトウェア技術のタイプを取得するように、角度情報データの土地への高速、一貫性のある、インタラクティブなアクセス、さまざまな。OLAPの目標は満たすか多次元意思決定支援環境固有のクエリーおよびレポートのニーズは、そのコア技術は、「次元」のコンセプトであるため、OLAP多次元データ分析ツールのコレクションであると言うことができることです。

OLAP基準および特性

EFCoddは、OLAPのための12本のガイドラインを提案しました。

• ガイドライン1 OLAP多次元モデルは、概念図を提供しなければなりません
• 2つの透明基準をガイドライン
• 指針3つのアクセス性能基準
• 4つの安定したレポート機能をガイドライン
• ガイドライン5クライアント/サーバアーキテクチャ
• 6次元の等価基準をガイドライン
• 疎行列処理ガイドライン7動的
• 8マルチユーザーサポート機能の基準をガイドライン
• クロス次元無制限のオペレーティングガイドライン9
• 直感的なデータ操作基準10
• 11柔軟なレポート生成をガイドライン
• 12の無制限の寸法および集約レベルをガイドライン

一言で言えば：

OLTPデータベースのメモリシステムは、メモリのコマンドレートの指標を重視バインド変数を強調し、同時動作を強調し、トランザクションを強調し、効率を重視し、
OLAPデータ分析システムが強調され、長い-SQLの実行を強調し、I / Oを、パーティションを強調したディスクを強調しました。

オープンソースのOLAPエンジン

現在、市場の主流オープンソースにOLAPエンジンがこれらに限定されない含まれていますなどハイブ、Hawq、プレスト、麒麟、インパラ、Sparksql、ドルイド、Clickhouse、Greeplum、単一のエンジンは、データの量、柔軟性とパフォーマンスの程度に完璧になることはできませんがあると言うことができますユーザーが自分のニーズに応じて選択を実行する必要があります。

コンポーネントおよび機能の紹介

巣箱

https://hive.apache.org/

ハイブは、Hadoopのデータウェアハウスのツールに基づいて、データベース・テーブルにデータファイルの構造をマップし、完全なSQLクエリ機能を提供することができ、あなたはMapReduceのタスクを実行するSQL文を変換することができます。利点は、データウェアハウスは、統計分析のために非常に適している、あなたはすぐに特化したMapReduceアプリケーションを開発することなく、SQL文の種類によって、単純なMapReduceの統計を達成することができ、学習の低コストです。

ハイブは、主にOLAPアプリケーションを目的としているため、それは分散ファイルシステムの根底にあるHDFSで、ハイブは一般のみ統計分析のために使用しない一般的なCUD操作は、ハイブは、既存のデータベースまたはログから最終HDFSに同期させるために必要ファイルシステム、リアルタイムの同期を行うには、現在の増分は非常に困難です。

ハイブ利点は、高い拡張性を簡単にように数千ノードまで拡張することができ、完全なSQLのサポート、低学習コスト、カスタムデータ形式です。

いくつかの重要なデータのインデックスがないので、しかし、いずれの治療にデータをロードするプロセスでハイブないデータがあっても、データをスキャンしません。条件を満たすために特定の値のハイブデータにアクセスするには、データベース全体をスキャンする暴力を必要とする高遅延にアクセスします。

ハイブは本当に遅いです。データ集計計算やコンティンジェンシー・テーブル、クエリ、大量の、ハイブは、ある瞬間に、計算に数百時間を要し、私もそれがOLAP「国籍」から追放されたいが、ハイブのHadoopベースのシステムを是認する必要がありませんまだ最も広く使用されていますOLAPエンジン。

ホーリー

http://hawq.apache.org
https://blog.csdn.net/wzy0623/article/details/55047696
https://www.oschina.net/p/hawq

HawqネイティブのHadoopは、大規模並列SQL解析エンジン、Hawq用いMPPアーキテクチャ、Hadoopのための改善されたコストベースのクエリオプティマイザです。内部データ自体の効率的な処理に加えて、だけでなく、PXFを介してHDFS、ハイブ、HBaseの、JSONや他の外部データソースにアクセスします。SQL UDFを書くことができ、標準SQLと完全に互換性HAWQも、単純なSQLデータマイニングや機械学習を実行するために使用することができます。それは機能、またはパフォーマンスであるかどうか、HAWQは、Hadoopの分析データ・ウェアハウス・アプリケーションを構築するためのより適切です。

典型的Hawqクラスタコンポーネント次のように

Hawqとハイブクエリのパフォーマンス比較テストにネットワーク上の一部の人々は、全体的に、ハイブ（4-50倍）よりもはるかに高速Hawq内部テーブルを使用します。
オリジナルリンク：https://blog.csdn.net/wzy0623/article/details/71479539

スパークSQL

https://spark.apache.org/sql/

以前シャーク、SQLクエリとして知られており、それがプログラムをスパークシームレスに統合されますSparkSQLは、RDDデータクエリのスパークとして構成することができます。生態系のスパークとしてSparkSQLは開発を続け、より長いハイブが、互換性のハイブに限定されません。

次のようにSQLシステム全体スパークスパーク場所は次のとおりです。

次のようにSparkSQLアーキテクチャは次のとおりです。

：生徒に精通スパークスパークSQLは、理解し始めるのは簡単である
スパークRDDのAPIに比べ、SQLは構造化データとその操作の詳細は、スパークSQLの使用の追加については、この情報が含まれているスパークより効率的で便利な構造化データの動作を最適化。
SQLはハイブ、アブロ、寄木張り、ORC、などのさまざまなデータソースにアクセスする一般的な方法を提供 JSON、およびJDBCを。
ハイブの優れた互換性。

プレスト

https://prestodb.github.io/

Presto is an open source distributed SQL query engine for running interactive analytic queries against data sources of all sizes ranging from gigabytes to petabytes.
Presto allows querying data where it lives, including Hive, Cassandra, relational databases or even proprietary data stores. A single Presto query can combine data from multiple sources, allowing for analytics across your entire organization.
Presto is targeted at analysts who expect response times ranging from sub-second to minutes. Presto breaks the false choice between having fast analytics using an expensive commercial solution or using a slow "free" solution that requires excessive hardware.

これは公式の紹介プレストです。プレストは、インタラクティブな分析クエリのFacebookのビッグデータ、オープンソースの分散SQLクエリエンジンである、などHDFS、RDBMS、KAFKA、を含むデータソースの大規模な数をサポートすることができ、また、データソースコネクタ、非常にフレンドリーなインターフェイスの開発を提供します。

プレストは、複雑なクエリ、重合（集約）を含む、標準のANSI SQLをサポートし、接続（参加）と窓関数（ウィンドウ関数）。別のハイブと豚（豚とハイブクエリはHDFS MapReduceのデータパイプ流によって行われる）ように、プレストデータそのものが格納されていないが、支持カスケードを介してデータ・ソースおよびデータソースの様々なアクセスすることができます。クエリ。

https://blog.csdn.net/u012535605/article/details/83857079
プレストは、MapReduceのを使用していない、それはカスタムクエリ実行エンジンと行われています。また、高いパフォーマンスのためにその主な理由であるメモリ内のすべてのクエリ処理、です。プレストとスパークSQLは、ハイブその最も基本的な違いと違って、非常に似ています。

しかし、メモリベースプレスト以来、ハイブは、ディスク上の読みハイブよりもはるかに高速プレストので、それをメモリに基づいて計算されるため、複数のテーブルの女王協会操作メモリエラーにつながることができています。

https://www.cnblogs.com/tgzhu/p/6033373.html

麒麟

http://kylin.apache.org/cn/
https://www.infoq.cn/article/kylin-apache-in-meituan-olap-scenarios-practice/は
麒麟はROLAPとMOLAPの話をする必要があります言及しました。

• 従来ROLAP（リレーショナルOLAP）にOLAPデータストレージとMOLAP（マルチディメンションOLAP）に依存

• ROLAPリレーショナルデータモデルはマルチ分析、小さな記憶容量、柔軟クエリが、欠点も明らかである利点として格納され、各クエリデータは欠点、RO​​LAPの使用を改善するために、重合を計算するために必要列メモリ、パラレルクエリ、クエリの最適化、ビットマップインデックス技術。

• MOLAPは、物理的形状、構造形成された立方体の多次元配列に格納されたデータを分析します。プロパティ値は、多次元配列の添字または添字範囲にマッピングさ寸法、アレイ、多次元アレイ部に格納された値が、利点は、急速問い合わせがあるという事実が、欠点は、データの量を制御することが容易ではない、問題の寸法爆発が発生する可能性があります。

MOLAPシステム自体は麒麟であると、キューブ（MOLAPキューブ）は十数億のユーザーを有効にするために設計されたデータモデルのデータセットを定義し、麒麟に予備重合キューブデータを構築します。

Apacheの麒麟™は、大規模データ、独自に開発し、オープンソースコミュニティへのeBay Inc.から寄贈を支援するためのHadoop /スパーク上でSQLクエリインターフェイスおよび多次元分析（OLAP）機能を提供するオープンソースの分散分析エンジンです。これは、サブ秒でハイブ巨大なテーブルを照会することができます。

麒麟の利点は以下のとおりです。

• ANSI-SQLインタフェースを提供します
• 対話型クエリ機能
• MOLAPキューブのコンセプト
• BIツールとのシームレスな統合

だから、麒麟のためのシナリオは次のとおりです。

• ユーザデータは、リレーショナル・データ、データの膨大な量の、少なくとも500GとしてHDFSハイブファイルアクセスデータを利用HadoopのHDFSに存在しています
• 毎日、でも数十G Gの増分データのインポート
• 10は、多かれ少なかれ固定次元解析を持っています

緯度の各組み合わせは、緯度のセットを定義することによって予め算出して記憶するために簡単に説明すると、データキューブ麒麟のアイデアは、時間空間です。Nラチチュードがあり、2 N回の組み合わせが存在することになります。ストレージ・ボリュームが悲惨な結果で、爆発的な成長の緯度と大きくなりますので、だから、緯度の量最善の制御です。

インパラ

https://impala.apache.org/

インパラはまた、HadoopのクエリツールのSQLで、迅速な対話型のSQLクエリをサポートするMPPの技術に基づいています。共有メタデータストレージおよびハイブ。Impaladは、プロセスの中核であり、問​​い合わせや、より多くのデータノード配信タスクを受信する責任があります。statestoredプロセスは、すべてのImpaladプロセスを監視する責任、およびクラスタレポートImpaladプロセス内の各ノードの状態です。catalogd通知プロセスは、最新の情報メタデータを放送する責任があります。

次のようにインパラのアーキテクチャは次のとおりです。

インパラの機能が含まれます：

• サポート寄木張り、アブロ、テキスト、のrcfile、SequenceFileや他のファイル形式
• 運用サポートのHDFS、HBaseの、アマゾンS3に格納されたデータ
• 圧縮符号化の様々なサポート：スナッピー、Gzipで、デフレート、Bzip2で、LZO
• UDFおよびUDAFをサポートしています
• 自動的に最も効率的なシーケンステーブルに参加
• それは、クエリプライオリティキューイング戦略を定義することができます
• マルチユーザー同時クエリをサポートしています
• これは、データのキャッシュをサポートしています
• コンピューティングの統計情報を提供します（COMPUTE STATS）
• これは、高度な分析をサポートするために、窓関数（NTILE等PARTITION、RANK、LEAD、LAG、OVER重合）を提供します
• 重合操作をサポートし、接続ディスクと、メモリオーバーフロー使用に操作ディスク
• WHERE句でのサブクエリの使用を可能にします
• これは、増分統計を可能に - 唯一の新しいまたは変更されたデータのデータに統計的計算を実行します
• サポートマップ、構造体、アレイ上の複雑なネストされたクエリ
• インパラは、HBaseのを挿入または更新するために使用することができます

同様に、インパラ、しばしばハイブは、プレストは、比較を行うために一緒に入れ、インパラの欠点も明らかです。

• インパラは、シリアライズとデシリアライズのためのあらゆるサポートを提供していません。
• インパラはテキストファイルのみを読むことができる、バイナリファイルは、カスタムを読み込むことができません。
• 新しいレコード/ファイルがHDFS内のデータディレクトリに追加されるたびに、テーブルは更新する必要があります。この欠点は、SQLクエリにつながることができ、クエリが動かない、リフレッシュ遭遇ハング実行されています。

ドルイド

https://druid.apache.org/
https://blog.csdn.net/warren288/article/details/80629909

ドルイドは、サブ秒問合せ履歴データとリアルタイム・データ・ストレージを提供するレベルです。ドルイドのサポート低レイテンシのデータ取り込み、柔軟なデータ分析は、高性能データ集約、簡単に水平方向のスケーリングを探索します。大量のデータ、分析照会システムの拡張性の高容量の要件に適しています。

対処ドルイドの問題が含まれます：高速なデータクエリおよびデータの迅速な取り込みを。
だから、ドルイドを理解するために、それは、2つのシステム、すなわち入力システムおよび照会システムとして理解する必要があります。

次のようにドルイドのアーキテクチャは次のとおりです。

ドルイド機能は次のとおりです。

• ドルイドリアルタイム消費データ、消費データの真のリアルタイム、リアルタイムクエリ結果
• ドルイドサポートPBレベルのデータは、千億高速なイベント処理は、毎秒同時クエリの数千人をサポート
• 時間の統計分析のシーンのために非常に適しDruidの中核時系列、バッチで保存された時系列データ、
• タイムスタンプカラム寸法、指標列：ドルイドデータ列は3つのカテゴリに分類されています
• ドルイドは、マルチテーブルの結合をサポートしていません。
• データドルイドは、良好な低レベルの統計情報を考慮することが期待されている一般的な使用の他の計算フレームワーク（スパーク、等）であります
• ドルイドクエリシナリオは透視次元複合体での処理には適していません
• ドルイドは、比較的単純なクエリの種類に速度の一般的なステートメントドルイドでいくつかの一般的なSQL（GROUPBY、など）を専門に
• ドルイドのサポート低レイテンシのデータの挿入、更新、しかし、HBaseのよりも、はるかに遅い従来のデータベース

こうした不足など、他のタイミングのデータベースと同様に、ドルイドは、大量のデータの下にヒットクエリであり、パフォーマンスの問題が発生した場合も、ソートや重合能力は、一般的に十分な柔軟性と拡張性、非常に良いではないではないことはように、サブクエリが参加して。

私たちの現在では、その後すぐに、クエリの結果は、歴史を含んで、きれいな良いエントリのリアルタイム記録、（参加をサポートしていません）私の個人的な理解では、ドルイド、ドルイドは、リアルタイムデータが書き込まれたことを確認することですが、SQLサポートへの問い合わせは完璧ではありませんビジネスは実用的ではありません。

ドルイドアプリケーションが参照できる：
「使用シナリオにドルイドの賞賛と応用持つ」https://blog.csdn.net/weixin_34273481/article/details/89238947を

Greeplum

https://greenplum.org/

https://blog.csdn.net/yongshenghuang/article/details/84925941
https://www.jianshu.com/p/b5c85cadb362

Greenplumは、オープンソース超並列データ解析エンジンです。MPPアーキテクチャでは、複雑なSQLの実行速度の解析速く大規模なデータセット上の多くのソリューションよりも。

GPDBは完全にANSI SQL 2008標準および拡張SQLのOLAP 2003をサポートし、ODBCやJDBCをサポートするアプリケーション・プログラミング・インタフェースから話します。総合的な標準規格のサポートは、システム開発、保守管理が大幅に便利ですなります。サポート分散トランザクション、ACIDのためのサポート。強い一貫性がデータを保証します。分散型データベースとして、優れたリニアなスケーラビリティを持ちます。GPDB音エコシステムは、SASなど、Cognosの、インフォマティクス、タブローのような多くのエンタープライズクラスの製品と統合することができ、また、そうでPentahoの、才能として、オープンソースソフトウェアの多種多様を統合することができます。

GreenPulmアーキテクチャ次のように：

次のようにGreenPulm技術的な特徴は以下のとおりです。

• 大容量データストレージおよび処理のためのサポート
• ジャストインタイムBIでサポート：準リアルタイム、リアルタイムのデータ・ロード、動的なデータウェアハウス（ADW）を実現するために、データウェアハウスのリアルタイム更新を達成するために、動的データ・ウェアハウスに基づいて、ビジネスユーザーがBIリアルタイム分析を行うことができます（ただ、現在のビジネス・データの）時間BIで
• サポート主流のSQL構文、使用することは非常に便利、低コストの学習
• スケーラブル、多言語サポートのカスタム関数やカスタムタイプ
• メンテナンスツールの数を提供しています、メンテナンスが使いやすいです
• 線膨張をサポート：MPPは、並列処理アーキテクチャを使用。MPPノード構造を増やすとの線形記憶容量と処理能力提供システムとすることができます
• より優れた並行処理及びハードウェアレベルのRAID技術を提供することに加えて、高可用性をサポートするためのサポートだけでなく、マスター・ノード・エラーは、継続ノードによってスタンドに切り替えることができる場合耐性機構マスタノード障害、スタンドバイ/保護データベース層のミラー機構のマスターを提供サービス
• MapReduceのサポート
• 内部データベースの圧縮

重要なメッセージ：GreenplumはPostgresqlのに基づいては、それはあなたがOLTPとOLAPで統一することにしたい、同様のGreenPulmとTiDBの位置です。

ClickHouse

https://clickhouse.yandex/
https://clickhouse.yandex/docs/zh/development/architecture/
http://www.clickhouse.com.cn/
https://www.jianshu.com/p/a5bf490247ea

ClickHouse公式ウェブサイト：

ClickHouse is an open source column-oriented database management system capable of real time generation of analytical data reports using SQL queries.

ロシアの会社が開発したClickhouseのYandexの。オンラインデータ分析と設計のために設計されています。Yandexのは、ロシアの検索エンジンの会社です。公式文書テーブル、ClickHouse毎日処理レコード番号「10億。」

特性：列記憶手段と、データ圧縮、支持断片化、及び異なるスライス同一のコンピューティングタスク上で並列に実行することができる、完成した計算結果を集約します。SQLをサポートし、分割表のクエリをサポートし、リアルタイムの更新、自動の複数のコピー同期;サポートインデックス、分散ストレージクエリ。

、軽量、高速：nginxの私たちは、人気のある機能が含まれ、国家のオープンソースソフトウェアを戦って、それに慣れていません。

ClickHouse最大の特徴は、高速、速く、速く、重要な単語3倍！
Hadoopのと比較すると、これらの巨大なコンポーネントをスパーク、ことを特徴としている非常に軽量ClickHouse、：

• 列のデータベースストレージ、データ圧縮
• リレーショナル、SQLのサポート
• 単一の性能を制限する絞っ並列分散コンピューティング、
• ハイアベイラビリティ
• 順番にPBレベルのデータ
• リアルタイムのデータ更新
• 指数

使用ClickHouseも含め、独自の制限があります：

• 高周波の欠如、低レイテンシが存在するデータを変更または削除する機能を持っています。バッチ削除、またはデータを変更するのみを使用することができます。
• いいえ、完全なトランザクションのサポートはありません
• これは、セカンダリインデックスをサポートしていません。
• 限定SQLのサポート、異なる達成参加
• ウィンドウ関数はサポートされていません。
• メタデータ管理は、維持するために、人間の介入を必要とし

概要

上記のいくつかの一般的に使用されるOLAPエンジンを与え、彼らそれぞれが独自の特徴を持って、私たちはグループにそれらは以下となります。

• ハイブ、Hawq、インパラ - Hadoopの上ベースのSQL
• プレストと同様のSQLスパーク - SQLの構文解析メモリに基づいて実行計画を
• 麒麟 - 時間のためのスペースで、事前計算
• ドルイド - リアルタイムのサポートデータの取り込み
• ClickHouse - HBaseのOLAPフィールド、単一テーブルのクエリの巨大なパフォーマンス上の利点
• Greenpulm - PostgresqlのOLAPフィールド

あなたのシーンがオフラインコンピューティングタスクHDFSに基づいている場合は、ハイブ、HawqとImaplaは、あなたの研究の目的である、
あなたのシーンは、分散クエリの問題を解決する場合は、リアルタイム要件のある程度があり、その後、プレストとは、あなたのSparkSQLに沿って、以上であってもよいです;期待して
、あなたの要約寸法が比較的固定した場合、高いリアルタイム要件、ユーザー+指標によって構成することが可能な寸法が考慮されることが予想されるので、同様に試してみて、麒麟ドルイドかもしれません。
ClickHouseが他よりもはるかに多く、センターステージ上の単一テーブルのクエリのパフォーマンスでありますOLAPデータベース、
リレーショナルデータベース製品としてGreenpulmは、パフォーマンスはデータ分析のためのより適切な、クラスタの拡大に伴って直線的に増加させることができます。

米国のグループは、麒麟の調査報告書で言ったように：

OLAPシステムは、さまざまなシナリオのニーズを満たすことができる何のクエリはありません。
その理由は、その性質上、何のシステムがデータ、パフォーマンス、および三つの側面の柔軟性の量は、各システムは、設計時にこれらの3の間で選択を行う必要があると同時に、完璧ではないということです。

私の社会的関心のスキャンコード番号へようこそ、返信] [JAVAPDFは200秋のトリックインタビューの質問を取得することができます！