且谈企业当今四大数据分析场景（一）

转载自微信公众号：BeagleData_

作者：张秋剑

随着我国的经济建设的运行周期下行，GDP进入“6时代”，我们的企业发展和社会经济建设已经从过去粗犷的红利爆发期，逐步到了所谓的“L”型拐点。国家倡导进入到数字化转型时期，在数字化转型期内，最为核心的是精细化运营。也就是说，企业开始转向关注数据，通过数据使得运营如何提升效率、优化生产。这样，数据分析变的越来越重要。所谓的分析，我们过去指的主要是：报表、BI，以及其他OLAP类型的分析，其实都是查询的不同表现形式。近年来，企业的业务部门对于取数的时效、维度、深度以及交互的方式方法（移动、托拉拽、操作的友好体验）等方面要求就越来越高。于是，就逐步衍生出来丰富的数据分析场景，这些分析的需求，使得我们对大数据平台所能提供的算力、计算和存储组件、调度等要求变得复杂。

 

一、商业智能分析（BI）

 

商业智能，简称BI，泛指用于对一个企业的原始数据进行分析的各种各样的软件系统。商业智能（BI）是由若干相关的活动组成的领域，包含数据分析，查询和报表等。企业用商业智能（BI）来提高决策制定，降低成本和识别新的商机。对于个人而言，可以自主式的对数据进行分析，提高工作效率。商业智能分析的方法有：

统计分析。提供基本的数据统计方法，进行基本的最大值、最小值、算数平均数等常规的数据统计。选择分析的变量或指标，系统会自动生成分析变量的运算指标。

同比分析。同比分析是将今年的数据与往年的数据进行对比，根据对比结果，生成合适的同比对比分析图。

环比分析。环比分析是将本期数据与上期数据进行对比，形成时间序列图。在一个环路中进行分析。

趋势分析。趋势分析是对时间序列数据转化为柱形图，折线图。根据图像的趋势走向进行预测分析，得出最终的结论。

相关分析。相关分析是针对不同的经济变量主体进行相关性的分析。由此判断两组数据的关联性与替代性。

差异分析。差异分析是分析两组数据的差异程度，运用雷达图是进行差异分析常用的手段。

结构分析。结构分析主要是分析指标的构成结构和指标结构，层次分明的对数据进行解析，有助于用户更好的使用BI.

预警分析。预警分析是对一些设置超过警戒线的数据进行警示，为方案的制定者提供一个提前预估风险的手段。

如此多的分析方法，目前企业主要借助于BI分析工具来实现，代表如Tableau、永洪BI等。

BI分析工具是一种可以提供数据可视化(Visualization)，致力于将信息以尽可能多的形式展现出来，目的是使决策者通过图形这种直观的表现方式迅速获得信息中蕴藏的知识，如趋势、分布、密度等要素。例如，可以依托于地理信息系统，展现各地区的属性值，例如人口密度，工业产值，人均医院数量等等，这种可视化工具部分与BI数据可视化应用重合，并形成有力补充，有时可以在一个项目中互相搭配。例如用户可以通过点击地图上的某一个省，钻取到这个省各个城市的信息，这种可交互性是BI与普通图片生成软件的显著差异。

可视化可以是C/S架构，也可以是B/S架构，支持浏览器的全拉拽界面，把查询条件自己来组织，如永洪BI的Z-Suite 的数据查询界面Query Editor，允许用户通过纯浏览器界面，以鼠标拖拽操作定义数据查询要素，并以报表和图表等多种方式展现数据。但是基本的底层还是基于当前应用的数据库SQL查询。

 

二、联机分析（OLAP）

 

联机分析也叫多维数据分析，是直接仿照用户的多角度思考模式，预先为用户组建多维的数据模型，在这里，指的是用户的分析角度。例如对销售数据的分析，时间周期是一个维度，产品类别、分销渠道、地理分布、客户群类也分别是一个维度。一旦多维数据模型建立完成，用户可以快速地从各个分析角度获取数据，也能动态的在各个角度之间切换或者进行多角度综合分析，具有极大的分析灵活性。这也是联机分析处理被广泛关注的根本原因，它从设计理念和真正实现上都与旧有的管理信息系统有着本质的区别。

联机分析处理的概念最早由关系数据库之父E．F．Codd于1993年提出。Codd认为，联机事务处理已不能满足终端用户对数据库查询分析的要求，SQL对大容量数据库的简单查询也不能满足用户分析的需求。用户的决策分析需要对关系数据库进行大量的计算才能得到结果，而查询的结果并不能满足决策者提出的需求。因此，Codd提出了多维数据库和多维分析的概念，即OLAP。OLAP委员会对联机分析处理的定义为：使分析人员、管理人员或执行人员能够从多种角度对从原始数据中转化出来的、能够真正为用户所理解的、并真实反映企业特性的信息进行快速、一致、交互的存取，从而获得对数据更深入了解的一类软件技术。

OLAP系统按照其存储器的数据存储格式可以分为关系OLAP（RelationalOLAP，简称ROLAP）、多维OLAP（MultidimensionalOLAP，简称MOLAP）和混合型OLAP（HybridOLAP，简称HOLAP）三种类型。

ROLAP

通常，解决OLAP有两种思路。最常见的思路是，在业务库之外再拷贝一份数据，搭建数据仓库。大多数数仓都采用分布式MPP架构，MPP全称是Massively Parallel Processing，即大规模并行处理，顾名思义是用多节点并行计算的方式来加速复杂查询计算；另一方面，数仓大多使用share-nothing架构，数据被分片存储到各个节点上：

这种思路有时也被称为ROLAP。ROLAP将分析用的多维数据存储在关系数据库中并根据应用的需要有选择的定义一批实视图作为表也存储在关系数据库中。不必要将每一个SQL查询都作为实视图保存，只定义那些应用频率比较高、计算工作量比较大的查询作为实视图。对每个针对OLAP服务器的查询，优先利用已经计算好的实视图来生成查询结果以提高查询效率。同时用作ROLAP存储器的RDBMS也针对OLAP作相应的优化，比如并行存储、并行查询、并行数据管理、基于成本的查询优化、位图索引、SQL的OLAP扩展(cube,rollup)等等。

MOLAP

与ROLAP相对的，另一种方案是跳出查询本身：MOLAP通过对数据进行预建模来加速查询。例如，我们通常选择时间维度、加上若干个业务维度，对它们的各种组合方式预先做好聚合。

下图就是一个例子：

从(year, item, city)三个维度枚举出8种组合方式，我们对这8种方式的聚合都进行预先计算，这有时也被形象地称为Data Cube。MOLAP将OLAP分析所用到的多维数据物理上存储为多维数组的形式，形成“立方体”的结构。维的属性值被映射成多维数组的下标值或下标的范围，而总结数据作为多维数组的值存储在数组的单元中。如果用户查询与预建模匹配，只需要在之前聚合结果的基础上再做计算就行了，显然，查询代价大大减少。MOLAP的典型代表是IBM Cognos。由于MOLAP采用了新的存储结构，从物理层实现起，因此又称为物理OLAP（PhysicalOLAP）；而ROLAP主要通过一些软件工具或中间软件实现，物理层仍采用关系数据库的存储结构，因此称为虚拟OLAP（VirtualOLAP）。很显然，MOLAP所能计算的查询严格受建模方式限制，这让它的门槛大大提高。所以综合来看，使用的不如ROLAP广泛。

HOLAP

由于MOLAP和ROLAP有着各自的优点和缺点（如下表所示）,且它们的结构迥然不同，这给分析人员设计OLAP结构提出了难题。为此一个新的OLAP结构——混合型OLAP（HOLAP）被提出，它能把MOLAP和ROLAP两种结构的优点结合起来。迄今为止，对HOLAP还没有一个正式的定义。但很明显，HOLAP结构不应该是MOLAP与ROLAP结构的简单组合，而是这两种结构技术优点的有机结合，能满足用户各种复杂的分析请求。

 

三、自助分析（Self-Service）

 

自助分析也叫灵活查询。BI分析中我们提到，虽然BI把查询条件自己来组织，允许用户通过纯浏览器界面，以鼠标拖拽操作定义数据查询要素，并以报表和图表等多种方式展现数据。但是基本的底层还是基于当前应用的数据库SQL查询。也就是说，BI分析是受约束的，为了有限而高度标准化的分析方法（如4.4.1）而牺牲了数据查询的灵活性。这种分析方法主要面向一线业务人员，而非专业的数据分析师，专业数据分析师会去用SAS EG或者Hadoop HUE、或者商业SQL数据分析工具来进行更加深度的数据分析和对数据的挖掘与探查。

专业数据分析师对业务和数据都有比较深入的理解，普通BI分析工具反而会影响他们对数据的思考，降低了他们分析数据的效能。通过直接开发SQL的方式，可以非常灵活的查询到自己想要的数据，自助式得到想要的数据答案。

然而，提高了灵活性就等于提高了对数据的要求，数据必须能够支持复杂的SQL计算，例如多表关联的Join操作、笛卡尔积、count、group by、distinct等等，这些在BI分析时可以避免，如果有大量数据分析师同时提交大表之间的关联查询就会对底层数据库代理巨大的性能压力。

通过HTAP数据库，可以解决灵活查询的性能问题。HTAP数据库以HDFS为底层，采用列式存储技术，无需将数据加工成宽表，并提供多种接口服务于企业中具有自主性查询要求的系统应用。为企业提供良好的高并发的数据自主分析的解决方案，最大程度的保障了企业业务处理的流畅，促进企业的高效运作。

 

四、即席查询（Ad Hoc）

 

即席查询（Ad Hoc）是用户根据自己的需求，灵活的选择查询条件，系统能够根据用户的选择生成相应的统计报表。即席查询与普通应用查询最大的不同是普通的应用查询是定制开发的，而即席查询是由用户自定义查询条件的。

用户在使用系统时，根据自己当时的需求定义的查询。即席查询生成的方式很多，最常见的就是使用即席查询工具。一般的数据展现工具都会提供即席查询的功能。通常的方式是，将数据仓库中的维度表和事实表映射到语义层，用户可以通过语义层选择表，建立表间的关联，最终生成SQL语句。即席查询与通常查询从SQL语句上来说，并没有本质的差别。它们之间的差别在于，通常的查询在系统设计和实施时是已知的，所有我们可以在系统实施时通过建立索引、分区等技术来优化这些查询，使这些查询的效率很高。而即席查询是用户在使用时临时生产的，系统无法预先优化这些查询。这对底层数据库的性能要求也同样很高。

通过HTAP数据库，可以解决即席查询的性能问题。HTAP数据库以Hadoop作为底层，采用分布式技术，对数据进行有效合理的处理，根据企业自身应用的需要，提供多种接口服务于企业中具有实时性查询要求的系统应用。为企业提供良好的海量数据即席查询的解决方案，最大程度的保障了企业业务处理的流畅，促进企业的高效运作。

多元数据分析需求

综上分析，我们可以看到，我们所面临企业数据分析需求，已经是一个非常多元化的数据分析场景，我们面对多元分析，是诸如实时性、时效性，所见即所得的相应级别。比如，前端业务人员要做实时分析，提供运营人员实时查询当前经营数据；再比如，企业数据中台的建设人员需要一个统一存储及计算平台当做保存和实时更新大量数据以供高并发SQL复杂查询访问。

这个时候上述的无论是RDBMS或者是MPP架构都不能够一站式满足需求。我们需要一个全新的底座来满足多元分析。那么近年来比较流行的一些数据库架构或组件呢？

数据库底座选择

首先，我们来看看使用NoSQL是否可行？

我们知道HBASE和SOLR、ES都是常用的NoSQL组件，但通常将他们用于高并发的单条查询或者综合性的检索服务。面对复杂分析他们不是最好的选择。例如复杂查询。它们需要用程序描述写复杂查询逻辑；再例如多维查询。需要手动维护多维索引等问题。

我们在来看看使用Hadoop怎样？

Hadoop常用SQL执行和存储组件是Hive、spark-sql、Phoenix和Impala等。因为没有很好的索引功能等支持面对高并的发读取，基本都需要借助预计算回写RDBMS或者NoSQL的架构组合来实现，解决不了跨库的性能延时问题，同时使得架构复杂、难以维护。由于都是善于做批量的引擎，如果需要做Update这类的操作，那么需要手动维护变更数据。

我们最后再来看看使用传统关系型数据库，这个结论就不言而喻了。承载大量数据首先RDBMS是力不从心的，其次算力水平扩展不能尽如人意。

综上，我们通过单一数据库或者大数据组件首先是无法完成任务的，于是绝大多数企业选择搭建混合架构来完成数据分析的多元化的任务，然而我们也说了跨库和多组件又会引来的问题。那么能不能通过一款数据库就能完美的承载多元数据分析需求，同时又能实现易维护和轻维护，并且性能不输任何一款数据库产品呢？

 

答案呼之欲出，就是NewSQL数据库——HTAP。我们将在下一篇中给大家带来。