選択方法[A] CTOは、多くのインテリジェントなデータ解析システムの寸法を話してプッシュします

「最近の文章を見た：」キーは、建築設計の考え方や選択肢、批判的思考と論理プログラミングを決定することであるが、深い思考」の実現です！
ウェン|プッシュCTOアンソン

はじめに
以前のレビュー：「インテリジェント・データ時代：自然と技術システム要件」このシリーズの最初の記事としては、一般的にデータの知的理解と対応するコア技術のシステム要件の導入について説明します。

インテリジェントデータは、開発中の人々のためのデータに基づいて、知識を獲得する、多数のからデータを抽出探索する大規模なデータ処理、データマイニング、機械学習、人間とコンピュータの相互作用、視覚化および他の技術を組み合わせることにより、生産手段としてのデータであります、知性の支援に効果的な意思決定を提供削減や不確実性を排除します。

下記に示すように、データの定義の観点からインテリジェントなデータインテリジェント技術システムは、少なくともいくつかの側面が含まれている必要があります。

▲データ・インテリジェンス・システムが構成します

どこ知性に記載されたデータのデータ資産管理、データ品質保証、安全なコンピューティング・システムは記事のフォローアップシリーズに焦点を当てます。

しかし最近では、実際には、我々はすべての会社のリソースの後に皆をテストするために、特に基盤となるシステム損失の種類の選択のために、実際のビジネス上の問題いくつかの本当の問題を解決するための多次元データ分析をどのように扱うかいあまりありません。

したがって、私はチームと一緒に勉強するだけでなく、情報の一部に描くことを期待して外に、ご参考のため、このシリーズのアドレスにおける第二の記事この問題、「多次元解析システム選定方法」のメインテーマの作者、彼らは、判定時間を短縮します。

テキストコンテンツ

検討因子分析システム

我々はすでに精通しているCAP理論は、CAPの間で両方の、唯一のトレードオフを持つことができません。分析システムにおける三つの要素、三つの要素データの量、すなわち、柔軟性と性能との間の妥協とバランスする同じ必要性。

三つの要因を考慮すべき▲解析システム

いくつかのシステムでは、データの量は、それが単純な分析が必要であっても、そのような処理要件を満たすことができない同じ状況のリソースよりもPのレベルなどの特定の量に達します。

灵活性主要指操作数据时的方式是否灵活，比如对于一般的分析师而言，使用SQL来操作是首选，没有太多的约束，如果使用特定领域的语言 (DSL) 相对就比较受限；另外一个意思是操作是否受预先条件的限制，譬如是否支持在多个维度下进行灵活的即席(Ad-Hoc)查询；最后一个就是性能要求，是否满足多并发操作、能否在秒级进行响应。

数据查询的过程分析

对数据进行聚合类型的查询时，一般按照以下三个步骤进行：

▲实时查询过程

首先，需要用索引检索出数据所对应的行号或者索引位置，要求能够从上亿条数据中快速过滤出几十万或几百万的数据。这方面是搜索引擎最擅长的领域，因为一般关系型数据库擅长用索引检索出比较精确的少量数据。

然后从主存储按行号或者位置进行具体数据的加载，要求能够快速加载这过滤出的几十上百万条数据到内存里。这方面是分析型数据库最擅长的领域，因为一般它们采用列式存储，有的还会采用mmap的方式来加快数据的处理。

最后进行分布式计算，能够把这些数据按照GROUP BY和SELECT的要求计算出最终的结果集。而这是大数据计算引擎最擅长的领域，如Spark、Hadoop等。

架构的比较和分析

结合以上两方面的要素，在架构方面目前主要是三类：

MPP (Massively Parallel Processing)
基于搜索引擎的架构
预计算系统架构

MPP架构
传统的RDBMS在ACID方面具有绝对的优势。在大数据时代中，如果你的数据大部分依然还是结构化的数据，并且数据并不是如此巨大的话，不一定非要采用类似Hadoop这样的平台，自然也可以采用分布式的架构来满足数据规模的增长，并且去解决数据分析的需求，同时还可以用我们熟悉的SQL来进行操作。

这个架构就是MPP(Massively Parallel Processing)–大规模并行处理。

当然实际上MPP只是一个架构，其底层未必一定是RDBMS, 而可以是架设在Hadoop底层设施并且加上分布式查询引擎(由Query Planner、Query Coordinator和Query Exec Engine等组成)，不使用MapReduce这样的批处理方式。

这个架构下的系统有：Greenplum、Impala、Drill、Shark等，其中Greenplum (一般简称GP) 使用PostgreSQL作为底层数据库引擎。

基于搜索引擎的架构
相对比MPP系统，搜索引擎在进行数据（文档）入库时将数据转换为倒排索引，使用Term Index、Term Dictionary、Posting 三级结构建立索引，同时采用一些压缩技术来进行空间的节省。

这些数据（文档）会通过一定的规则（譬如对文档ID进行哈希算法）分散到各个节点上。在进行数据检索的时候，采用Scatter-Gather计算模型，在各个节点上分别进行处理后，集中到发起搜索的节点进行最终聚合。

这个架构下的系统主要有：ElasticSearch、Solr，一般采用DSL进行操作。

预计算系统架构
类似Apache Kylin这样的系统就是预计算系统架构。其在数据入库时对数据进行预聚合，通过事先建立一定的模型，对数据进行预先的处理，形成“物化视图”或者数据Cube，这样对于数据的大部分处理实际是在查询阶段之前就完成了，查询阶段相当于进行二次加工。

这个架构下的系统主要有: Kylin，Druid。虽然Kylin和Druid都属于预计算系统架构，两者之间还是有不少差别。

Kylin是使用Cube的方式来进行预计算（支持SQL方式），一旦模型确定，要去修改的成本会比较大，基本上需要重新计算整个Cube，而且预计算不是随时进行，是按照一定策略进行，这个也限制了其作为实时数据查询的要求。

ドルイドは、リアルタイムシステム、アドホックすばやくデータをフィルタリングして処理することができますので、メインインデックスモードとしてビットマップを使用して、クエリ（現在SQLをサポートしていません）、しかし、複雑なクエリのために、性能比麒麟に適していますさらに悪いです。

上記の分析に基づいて、麒麟一般オフラインOLAPエンジンメインプッシュリアルタイムで大量のデータ、ドルイドOLAPエンジンメインプッシュのデータの大量。

3つのアーキテクチャの比較
システムのMPPアーキテクチャ：
そこにデータやサポートの柔軟性の良い量があるが、応答時間は必ずしも保証されません。ときに、データおよび計算の複雑さの増加量は、レベル分に第二のレベルから、応答時間が遅くなり、またはさらに時間が可能レベルです。

システムの検索エンジンのアーキテクチャ：
相対比MPPシステム、良好なパフォーマンスと引き換えにある程度の柔軟性を犠牲にして検索クエリクラスには、サブ秒の応答を行うことができます。しかしながら、スキャンベースのクエリ重合、データの処理量の増加に伴って、応答時間が数分に低下します。

事前計算システム：
予備重合時のデータ記憶装置は、さらに大規模なデータセットに応答して第2のレベルを達成するために、パフォーマンスのための柔軟性を犠牲にします。

上記の分析の組み合わせ、上記の3つである：
小から大までのデータ量をサポートするための
柔軟性降順
ローからハイに大量のデータと性能

したがって、我々は実際のトラフィックデータのサイズに基づいてすることができ、柔軟性とパフォーマンスの要件を総合的考慮すべき。GPの使用は、ほとんどの企業のニーズを満たすことができるかもしれなど、データ麒麟の大量の使用は、需要を満たします。

結論は、
深い思考「キーは、建築デザイン思考と選択を決定することで、批判的思考とロジックプログラミングはの実現である」：最近、一つの文章を見ました！

将来的には、我々は技術チームは、私たちの開発者のためのより良いサービスを提供するために、いつものように、あなたと一緒に議論する、多次元分析システムの選択方法を模索していきます押してください。

詳細については、注意してください：技術のプッシュ研究所