入門
ドルイドは、大規模なデータクエリとすぐに大規模なデータを扱うように設計された高耐障害性、高性能なオープンソース分散システムの分析、および高速のクエリーと分析を達成する能力を持つリアルタイムです。特に、システムダウンの発生符号配備、機械の誤動作や他の製品のような状況に遭遇したとき、ドルイドはまだでき、100％の稼働率を維持します。インタラクティブなクエリーと分析を実施するためのHadoopを使用しようとすると、クエリの待ち時間の問題を解決するために主にあるDruidの本来の意図を作成し、リアルタイム分析のニーズを満たすことは困難です。ドルイドは、対話的に2は、特別な保存形式を採用し、データとクエリの柔軟性と性能のトレードオフをアクセスする機能を提供します。
ドルイドは同様PowerDrillドレメルと単一表照会を可能にするだけでなく、そのようなカラムストレージフォーマットは、部分的にネストされたデータ構造で提供するなどの新しい機能を追加し、インデックス作成を迅速に濾過し、リアルタイムクエリ取り込み、高いフォールト・トレランスの分布風の建築のように。
プロパティ
分析と設計のために：フィルタリング、集約し、クエリのクラスの様々なサポートするために構築されたOLAP分析のワークフローを検討します。
迅速な対話型のクエリ：低レイテンシデータアーキテクチャのドルイド摂取がそれらをミリ秒以内に照会することができるイベントを作成することができます。
高可用性：システムアップデートは、拡張し、小型化は、データの損失が発生することはありませんときドルイドのデータはまだ利用可能です。
スケーラブル：ドルイドは毎日イベントとTB-レベルデータの十億を処理することができる達成されました。
利用シナリオ
1、データ照会の大量のインタラクティブかつ急速な重合が必要です。
2、リアルタイムクエリ分析を必要とします。
3、こうした日々の10Tデータの数を増やし、一日あたりのイベント数億を追加するなど、大量のデータを持っています。
4、リアルタイムのビッグデータ分析では特にデータ。
図5は、高可用性、耐障害性の高い、高パフォーマンスのデータベースが必要です。
アーキテクチャ
歴史：非リアルタイムデータストレージやクエリ処理のために、
リアルタイム：リアルタイムの取り込みデータは、入力データストリームを監視します
コーディネータ：履歴監視ノード
ブローカー：外部クライアントからの問い合わせを受け、かつリアルタイムにクエリを転送し、歴史的
インデクサ：インデックスサービスは責任があります
コントラスト
スパーク+ Redisの+ HBaseのリアルタイムなデータ探索
以下のような問題点を代入します：
-
ピークトラフィックの処理遅延
-
緯度クロス分析、柔軟性のありません
-
資源の大量消費
-
システム障害、遅い再計算
这是第一代、消耗大、系统故障，在大内存情况下很容易导致崩溃。马蜂窝之前就遇到突发，一组三台，每一台 512 个 G，这个时候内存太大了，哪天一个内存条坏的话，这一天的数据可能就要重新算，而且对于现在当前整个实时数据量来看，完全就不符合当前的现状，算一天需要十几个小时。
当时考虑到，在数据量大的情况下，是不是我们可以去牺牲 UV 的计算。所以就引入在 Druid 里面。把 Druid 引入到 MES，误差基本上保持在 2% 左右。后面我们又通过雅虎提供的data sketch,可以精确调控 UV 的计算，它的默认值是 16384，16384 以下可以是精确的。当然这个值是可以控制的，就是 2 的 N 次幂，当前我们是调到特别大，800 多万。但 Druid 里面不支持MES第一代的虚拟 key。
在 Druid 里面对于datasource 有一个按时间密度去分的，我们历史数据在查询力度这个层面，只能让他查到按每小时去查，其他按天去分配。最新的数据就在最近 15 天，我们可以让他精确到一分钟的查询，对于历史数据，力度越精确，数据量到 Druid 里面越大。
在离线批量导入，现在 Druid 支持，T+1 的数据校正。如果在 PSPARK+TRANQUILITY 这一阶段，因为 SPARK 的 task 失败的话，可能会导致这个数据到 Druid 里面 PV 会上升。所以说需要每天凌晨通过批量导入的方法把上一天的数据做一个数据校准。同样的是需要打平在 attr 里打平所有工程师上报的数据制定的值。
｜Druid 集群注意事项
在 Druid 里面配置，
1、维度不要太多，像蚂蜂窝最开始 700 多个维度。每天导进去将近 100 个 G，导进去十分耗时。
2、维度大小，不要太大。比如你来一个维度值几兆的，这个不行。
3、合理的な配分比率に行きます。初めに、我々は全体のドルイドのデータ・ストレージ・ノードとして10 Tディスクを設置する前にノードを取っていますが、タスクを確認するか、過去のデータをチェックしようとしているかどうかを確認することができました。10 Tディスクは、さまざまなタイムアウトを照会し、様々な応答を維持することはできません。
4、ディスクの選択。実際には、ソリッドステートディスクの使用は、基本的に私たちの現在の構成のように、256 Gメモリ、1.2Tソリッドステートディスクです。この構成では、あなたが速いかどうかをデータの全体の歴史、または他のデータのクエリを照会するために行く、アップしています。
図5に示すように、セグメントのサイズは、我々は、100 G、日によって開始され、バック時間に分割する指します。数Gのこの時間は、いくつかのGが動作しない、我々はいくつかのGに分割しようとしている、最後のクエリと同等の約300〜700メガバイトです。
図6は、ドルイドここで、コンマは、底部で分離ドルイドコンマで使用されるように、サポートしていません。
7、ドルイドのバージョンをアップグレードするための優先順位。私たちは、ゆっくりと早くても0.6から0.8へのアップグレード、私たちが使用しているが0.9です。ドルイドの髪のすべてのバージョンでは、多くのことを最適化。あなたが問題になっている各クエリを考えて、またはあなたがより速く行くデータを照会したいですか、あなたが行くと上記Druidのgithubのの最新の状態を確認するためにどのような優先順位を付けることができます。
これは、あなたと物事の一部を共有するために、今日です。もちろん、我々は、プロセスのドルイド全体で使用され、実際には、また、他の多くの問題を満たしています。私はドルイドが良く得ることができると思います。
他の
2.0プロトコルのオープンソースコードはgithubの上でホストされているドルイドは、Apacheライセンスに基づいて、最新の安定版は0.7.11でてきた、63のContributerコードとほぼ2,000フォロワーはすでに存在します。主な要因ドルイドは、広告分析スタートアップ企業Metamarketsの、動画ストリーミングサイトMetflix、Yahooや他の企業が含まれます。などシャーク、にVertica、カサンドラ、Hadoopの、スパーク、Elasticsearchてドルイド公式ドルイドは、耐障害性、柔軟性、およびクエリのパフォーマンスの観点から説明比較しました。