Yonghong在大数据、分布式计算、数据分析等领域具备核心竞争力、自主**并拥有多项发明**。Yonghong研发团队推出的商业智能平台Yonghong Z-Suite，是由一系列基于MPP架构的商业智能产品组成。

Yonghong Z-Suite是发现型的商业智能产品，她具备丰富的数据分析能力。当用户访问数据应用的时候，如果看到商业活动的异常或者变化时，除了数据展现，我们更需要的是能够通过即席的、深入的分析以获取现象背后的深层次原因。基于Z-Suite，用户可以不断地与数据对话(Talk)，深入分析信息(Analyze)，直到得到满意的答案。

Yonghong Z-Suite具有高性能的大数据分析能力，她完全摒弃了向上升级(Scale-Up)，**支持横向扩展(Scale-Out)。Yonghong Z-Suite主要通过以下核心技术来支撑TB/PB级的大数据。

1、Yonghong Z-Suite技术架构

1.1关键技术

1.1.1并行计算(MPP Computing)

Yonghong Z-Suite是基于MPP架构的商业智能平台，她能够把计算分布到多个计算节点，再在指定节点将计算结果汇总输出。Yonghong Z-Suite能够充分利用各种计算和存储资源，不管是服务器还是普通的PC，她对网络条件也没有严苛的要求。作为横向扩展的大数据平台，Yonghong Z-Suite能够充分发挥各个节点的计算能力，轻松实现针对TB/PB级数据分析的秒级响应。

1.1.2库内计算(In-Databa******puting)

Yonghong Z-Suite支持各种常见的汇总，还支持几乎全部的专业统计函数。得益于库内计算技术，Yonghong Z-Suite数据分析引擎将找寻出**化的计算方案，继而把所有开销较大的、昂贵的计算都移动到数据存储的地方直接计算，称之为库内计算(In-Database)。这一技术大大减少了数据移动，降低了通讯负担，保证了高性能数据分析。

1.1.3列存储 (Column-Based)

Yonghong Z-Suite是列存储的。基于列存储的数据集市，不读取无关数据，能降低读写开销，同时提高I/O 的效率，从而大大提高查询性能。另外，列存储能够更好地压缩数据，一般压缩比在5 -10倍之间，这样一来，数据占有空间降低到传统存储的1/5到1/10 。良好的数据压缩技术，节省了存储设备和内存的开销，却大大了提升计算性能。

1.1.4内存计算(In-Memory Computing)

得益于列存储技术和并行计算技术，Yonghong Z-Suite能够大大压缩数据，并同时利用多个节点的计算能力和内存容量。一般地，内存访问速度比磁盘访问速度要快几百倍甚至上千倍。通过内存计算，CPU直接从内存而非磁盘上读取数据并对数据进行计算。内存计算是对传统数据处理方式的一种加速，是实现大数据分析的关键应用技术。

1.1.5分布式通讯(Distribute IO)

分布式通讯比较底层，是介绍得比较少的领域。不过，中间计算结果能否在集群中稳定且高效地传输，是整个集群能否达到实时计算的关键。

可复用的TCP/IP连接：系统的TCP/IP连接是可复用的，不像传统方式一样，一个信息传递需要建立一个连接，而信息交换的接收与发出逻辑对应的软件进程/线程是可复用的。这一方法降低了整个系统的TCP/IP负载，以及线程/进程开销。

多路的信息传输：系统的信息传输是多路的。这类似于高速公路的多车道。如果一个TCP/IP连接不够，可以增加TCP/IP连接。而如果闲置，可以收回多余的连接以释放网络、CPU、内存资源。

异步的信息传输：系统的信息传输是异步的。发出信息的请求方不会占据着TCP/IP连接，而是在发出信息之后立即释放资源。以异步的消息通知机制等待返回处理结果，这一异步机制让系统在等待返回处理结果时不会白白耗费资源，在接收方处理信息时也不会占据TCP/IP连接和相应的线程/进程资源。系统以异步信息交换的方式，成功地消除了信息处理与信息传输之间的耦合。提升了信息交换能力，但有效地降低了信息交换所需要的网络资源、CPU、或者内存资源。

稳定的内存使用：由于整个通讯过程中Socket通道是复用的，而Socket通道对应的读内存块和写存块也是复用的，很少有内存的申请和释放操作。这提升了整个系统的性能和稳定性。

健壮的信息传输：系统的TCP/IP连接是可自修复的。网络可能会有各种问题导致连接出错，为了避免数据流里可能丢失了数据，给每个数据流的头部加了标识位，在任何找不到标识位的情况下，连接都会自动关闭。系统会自动重新建立连接。

1.1.6执行计划的优化算法

可以做到三个层面的执行计划的优化：基于Block Meta的高层优化：粗粒度索引， 基于每个Block的每个Column的中层优化：读取文件头;基于计算强度进行SQL改写的底层优化：根据计算强度，来改写优化。

1.1.7商业智能(BI)

数据仓库+OLAP时代的商业智能系统，要求用户预先提出的分析及统计的需求。以此为基础，展开数据建模工作，进而导入数据，然后再创建Cube。这些工作完成以后，才能开发商业智能应用，这是典型的数据驱动模式。

Yonghong Z-Suite支持业务驱动的商业智能系统，直接导入细节数据，不再要求用户预先提出具体的分析及统计需求，也不再有创建Cube的过程，这大大简化了数据层的工作，缩短了数据层的响应周期，整个商业智能系统由数据驱动转化为业务驱动。在数据仓库+OLAP时代，一个新的分析需求也许要用一个月的时间去实现，现在Yonghong Z-Suite支持只需几天或几个小时。

2.与Hadoop架构比对

Hadoop目前几乎是大数据的代名词，很多企业都基于Hadoop搭建自己的大数据业务。

以下是Hadoop的主要优点：

1)Hadoop集群的扩展性是其一大特点，Hadoop可以扩展至数千个节点，对数据持续增长，数据量特别巨大的需求很合适。

2) Hadoop的成本是其另一大优势，由于Hadoop是开源项目，而且不仅从软件上节约成本，硬件上的要求也不高。目前去IOE潮流风行，低成本的Hadoop也是一大推手。

3) Hadoop生态群活跃，其周边开源项目丰富，HBase, Hive，Impala等等基础开源项目众多。

那么Hadoop的不足有哪些呢?

Hadoop不适合做实时分析系统。

1. 从通讯层的技术上来说有如下原因：

任务分配Server不会将信息Push到计算Node，而是让计算Node通过心跳去Pull任务。

基于框架的通用性，MapReduce代码也会在HDFS中传送，在各计算Node展开，再通过启动新JVM进程装载并运行。

类似的JVM进程启停有5、6次之多。

Reduce Task只能在全部Map Task完成之后才能启动。

2.缺乏专业的支持服务

因为是开源项目，缺少专业的商业支持服务，公司需要储备专业Hadoop知识的专家来保证系统的正常运转。

Hadoop可以支持百亿的数据量，但很难应对秒级响应的在线分析需求，一般作为离线分析系统

即使是数亿的数据量，Hadoop也只适合做分钟级别的离线分析系统。

而百亿级别数据量，又需要秒级响应的案例，需要什么系统支持呢?下面介绍下大数据实时分析工具Yonghong Z-Suite。

通过结合多种Yonghong自有的**技术，在几个节点下，Yonghong Z-Suite就能担负起几十亿，乃至上百亿数据量的实时分析和展现。

Yonghong Z-Suite相对Hadoop有哪些不足呢?Hadoop能支撑PB级大数据，数千节点的大规模集群。对于Yonghong Z-Suite这种实时大数据分析系统，一般支撑TB~PB级的大数据，节点数一般不超过100。

除了提供**的前端BI工具之外，Yonghong Z-Suite让用户可以选购分布式数据集市来支持实时大数据分析。

3.典型场景使用

3.1场景一

Hadoop仓储中心已经搭建，存储了几百TB数据到上PB级数据。需要实时统计分析一段范围的数据。利用HBase或Hive无法满足实时需求。也许还需要跟关系型数据库中的维度表做关联再分析。

3.1.1数据存储层

几百TB甚至上PB级细节数据存储在Hadoop集群中。通过Hive或者HBase访问数据。

3.1.2数据抽取入集市

将数据按照主题建立成多个集市导入到MPP集群中。

如果采用Hive方式访问数据，可以采取ODBC/JDBC的方式直接建立连接读取数据。 如果采用HBase方式访问数据，可以定制一个Customized Query来读取数据。如果是直接访问HDFS文件来导出数据，可以定制一个Customized Query来读取数据。

ETL过程中可以做数据清洗，格式转换，还可以跟其他库的维度表进行关联，形成宽表入库。入库时还能根据时间或者区域来给数据打上粗粒度标签，便于以后做数据优化调整使用。历史数据集中导入，增量数据自动导入，增量更新的时间粒度根据系统对实效性的要求，可以是每分钟，每小时，每天。

ETL的客户端可以是多节点同时导入集市，以此来提高导入效率。

3.1.3MPP数据集市

根据需要计算的数据量和计算的强度来估算一个需要搭建的机器数量。假设需要10台机器。每台机器承担不同的角色，如果一台机器的任务量不大，可以承担多个角色。

Naming Node: 负责命名工作。它知道当前有多少台Map Node和Reduce Node，及这些Server的配置状况。Map Node和Reduce Node会定期发送各自配置情况，workload (工作量) ，CPU，内存等信息。Naming Node 通常是一台机器，但可以做冷备份。

Map Node: 负责处理Map Task。原始数据和Map Task的代码文件集被预先部署到Map Node上。当它接收到Client Node发送的Map Task，可以直接执行该任务。Map Node可以有多台机器。

Reduce Node: 负��处理Reduce Task。它被预先部署了Reduce Task的代码文件集，可以直接执行该任务。Reduce Node可以有多台机器，而且可以指定某台干固定的任务。

大量的细节数据在压缩后，以文件的形式被分布式存储在集群的硬盘中。当计算时，会把被打中的数据拉入到内存中，也就是热点数据会常驻内存。当发生数据失效时，会将新数据交换到内存中参与计算。

3.1.4数据应用层

应用层的客户端可以是多台机器，也就是说一套数据集市可以支撑多个应用系统，每个应用系统用不同的客户端来做数据展现。 例如一个系统是专门来做固定报表定时推送的， 另外一个系统是专门来做BI展现前端，用户通过账号登陆进去，访问可视化的界面，并做实时的数据分析和交互。

3.2场景二

没有建立Hadoop仓储中心，几十上百TB的数据或许以日志文件形式存储在文件系统中，或许存储在传统数据仓库中。需要实时统计分析一段范围的数据。利用传统数据仓库无法满足实时统计分析的需求。也许还需要跟关系型数据库中的维度表做关联再分析。

3.2.1数据存储层

1)几十上百TB的数据通过前置机采集到日志文件，并按照一定规则存储在文件系统中。

2)几十上百TB的数据通过生产系统收集到传统数据仓库中，例如My SQL集群或Oracle集群中。

3.2.数据抽取入集市

将数据按照主题建立成多个集市导入到MPP集群中。

如果访问的是日志文件系统，需要一个日志文本的解析器Parser，将二进制流或CSV等格式的文本解析出来，抑或跟维度信息关联后入库。 如果访问的是传统数据仓库，可以采取ODBC/JDBC的方式直接建立连接读取数据。

ETL过程中可以做数据清洗，格式转换，还可以跟其他库的维度表进行关联，形成宽表入库。入库时还能根据时间或者区域来给数据打上粗粒度标签，便于以后做数据优化调整使用。历史数据集中导入，增量数据自动导入，增量更新的时间粒度根据系统对实效性的要求，可以是每分钟，每小时，每天。

ETL的客户端可以是多节点同时导入集市，以此来提高导入效率。

3.2.3MPP数据集市

根据需要计算的数据量和计算的强度来估算一个需要搭建的机器数量。假设需要10台机器。每台机器承担不同的角色，如果一台机器的任务量不大，可以承担多个角色。

Naming Node: 负责命名工作。它知道当前有多少台Map Node和Reduce Node，及这些Server的配置状况。Map Node和Reduce Node会定期发送各自配置情况，workload (工作量) ，CPU，内存等信息。Naming Node 通常是一台机器，但可以做冷备份。

Map Node: 负责处理Map Task。原始数据和Map Task的代码文件集被预先部署到Map Node上。当它接收到Client Node发送的Map Task，可以直接执行该任务。Map Node可以有多台机器。

Reduce Node: 负责处理Reduce Task。它被预先部署了Reduce Task的代码文件集，可以直接执行该任务。Reduce Node可以有多台机器，而且可以指定某台干固定的任务。

大量的细节数据在压缩后，以文件的形式被分布式存储在集群的硬盘中。当计算时，会把被打中的数据拉入到内存中，也就是热点数据会常驻内存。当发生数据失效时，会将新数据交换到内存中参与计算。

3.2.4数据应用层

应用层的客户端可以是多台机器，也就是说一套数据集市可以支撑多个应用系统，每个应用系统用不同的客户端来做数据展现。 例如一个系统是专门来做固定报表定时推送的， 另外一个系统是专门来做BI展现前端，用户通过账号登陆进去，访问可视化的界面，并做实时的数据分析和交互。

4.硬件要求说明

入门级服务器数台到数十台。每台服务器内存32G以上，CPU 4 Processor以上，独立硬盘1TB以上，千兆或万兆网卡。集群搭建后，可以做到热插拔的方式横向扩展。