永洪Bi架构部署与集群部署

永洪Bi架构部署与集群部署

​ 永洪Bi是一款先进的数据技术与数据可视化的一站式大数据分析平台。他的优势在于：1、可靠的多数据源对接能力；2、丰富精致的数据图表样式；3、灵活高效的可视化探索式分析；4、易用的自服务操作；5、可靠的任务调度能力；5、更规范安全的企业级管控；6、扎实提升的计算性能；7、多屏切换，无缝衔接。

永洪产品介绍

​ 永洪Bi的产品种类主要有：1、Z—Suite：运用这款产品企业可以在一个统一的平台上完成全流程数据分析任务，极大降低了实施、集成、培训的成本；2、X—Suite：并发量100以内，这款产品主要面向部门级或中小企业的自助分析应用，快速整合海量数据，提供易用、高效的数据可视化分析；3、Desktop：这是一款桌面智能数据分析工具，提供一站式、敏捷、高效的数据治理及可视化分析能力。

永洪Desktop的优势

​ 永洪Desktop是一款轻量级桌面智能数据分析工具，他的优势在于：1、基于本机安装，无需复杂的环境部署，64位操作系统，4G或8G内存的都可以安装（基本上现在的笔记本电脑都符合安装条件）；2、支持特殊环境下的离线分析工作；3、数据分析过程不占用Server端资源，用户之间的自助式分析互不干扰；4、功能完善，内嵌高性能计算引擎，支持高性能计算和AI深度分析；5、分析结构可以快速共享到Server端。

永洪MPP数据集市

​ 永洪MPP数据集市：是大数据高性能计算引擎，可以实现从千万到百亿级数据分析的秒级相应。他的特点是：1、一款服务于数据存储，数据处理的数据集市产品；2、通过库内计算、内存计算和分布式计算引擎提升BI报表制作及加载性能；3、列存储，支持横向扩展节点。

MPP集群部署适合的场景

​ 1、大并发的数据运算分析；2、大规模数据集的分析运算；3、更快的分析型运算速度。

MPP数据集市优势

​ 1、列存储：大幅度压缩数据，减少磁盘IO，降低内存及CPU开销；

​ 2、库内计算：库找寻出最优化的计算方案，继而把所有开销较大的、昂贵的计算都移动到数据存储的地方直接计算。计算步骤主要分两步；第一步：入集市之前，我们的SQL是尽量压缩下推到数据库里面的，这样可以通过数据库计算来降低操作界面的加载压力；第二步：集市的数据是存储在M节点上的，大多数计算也是发生在M节点上，从而减少了数据网络传输上的消耗和时间上的消耗。

​ 3、内存计算：按需内存计算，采用冷热数据交替算法，加载常用的数据至内存中，再次降低企业硬件成本。根据数据使用场景，使用频次，将使用频次多的保存在内存里，将使用频次少的从内存释放，从而提升效率。

​ 4、分布式并行计算：Map Reduce架构是一个通用处理并行计算的架构，利用多节点的并行计算提高计算效率（通俗来说就是人多办事快，多人一起来完成一件事情）。

​ 5、分布式通讯：提高各个节点的调配效率，按照前端展示要求，自动缓存中间及结果数据，并在后台自动更新，再次提高展示性能且降低计算资源消耗。

永洪AI可视化深度分析

​ 永洪AI可视化深度分析：连通探索式分析和深度分析，提供一站式数据分析洞察能力。他的优势是：1、这是一款可视化操作界面，降低AI应用门槛；2、内置了很多经典的机器学习算法（逻辑回归，决策树，关联分析，K-Means聚类，HoltWinters时序分析，R模型，Python模型），这些机器学习算法可以直接使用；3、高性能的深度分析；4、将AI与BI深度融合在一起看，支持将AI计算结果保存为数据集，然后直接用这些数据集进行BI展示应用，即预测结果的BI应用；5、多行业场景应用。

数据仓库DW

​ 通常在业务系统比较多，数据来源比较多，数据质量比较差的情况下，我们需要建立数据仓库DW。建立数据仓库DW的目的：在对原有分散的数据进行抽取和清理的基础上经过系统加工，汇总和整理，消除源数据中的不一致性，提供一致的全局信息。如腾讯的TBDS（客户有数据仓库/大数据平台需求时，首先推荐）大数据平台和Snova数仓，华为的MRS大数据平台和DWS数仓。

​ 使用数据仓库DW的优势是：1、整合多业务系统、多来源的数据；2、实现对数据的业务理解和技术实现的一致性；3、提升数据质量；4、贴近业务分析，方便使用；5、数据调用性能提升。

如何识别一个项目是BI项目

​ 如何识别一个项目是不是BI项目呢？通常情况下，满足如下一个或多个需求都可能是一个BI项目：

​ 1、有领导驾驶舱，明确的大屏，可视化展示，数据分析，报表的需求。

​ 2、有运营监控和指标监控的需求。

​ 3、有自助式（自服务）分析的需求。

​ 4、有数据预测的需求或数据挖掘的需求。

​ 5、已有报表系统或数据平台，想找一个前端数据分析工具。

​ 6、有数据填报并对填报数据进行分析的需求。

​ 7、客户的各个系统积累了大量的数据，但是不知道怎么利用数据。

​ 8、需求某一个业务方面的总体解决方案，但是方案中包含上述的一项或多项需求。

永洪节点类型

​ C节点，全称为Client，功能描述：1、接受终端客户请求，并将请求提交给N节点；2、接受R节点的汇总计算结果并展示；3、与原始数据源相连接，抽取原始数据，并存入数据集市；4、不使用集市时，直接从业务数据库获取数据并进行展现。

​ C节点部署时，需要考虑的因素有1、并发量；2、报告的计算量和计算复杂程度；3、报告的组件个数；4、是否有高可用需求。

​ N节点（管理者），全称为Naming，功能描述：1、负责统一调度各个节点工作，使各个节点工作压力相当，达到Map节点计算负载均衡；2、整个集群中只会有且只有一个N节点。

​ M节点，全称Map，功能描述：1、负责存储数据集市中的分布式数据文件；2、执行N节点分派的计算任务；3、整合集群中的多个M节点，M节点承担了集群的大部分计算工作。

​ R节点：全称Reduce，功能描述：1、多个M节点将同一计算任务的计算结果发送给同一个R节点，由该R节点对计算结果进行汇总；2、集群中有很多个R节点。

​ 注意：1、C节点最好和R节点部署在一起（但是在C节点压力小，集市节点数量比较少的情况下，也可以将N节点和C节点部署在一起）；2、N节点与M节点的个数比为1:3；3、R节点与M节点的个数比为1:3；4、N节点最好单独放在一个机器上。

永洪节点测算

​ C节点测算：以并发量测算，通常单个C节点（通常的4核配置）可以承载的并发用户数在50-100之间。如果并发量较大，则建议拆分为多个C节点，通过集群和负载均衡来实现。单个节点能够承载的并发量通常与报告的组件个数、计算量、计算复杂程度有关。

​ N节点测算：高可用场景需要有一主一备两个N节点，其他场景一般一个主N节点即可。

​ M节点测算：根据入集市的原始数据量（注意：不是原始数据库的存储容量，）进行测算（以G为单位），原始数据量与集市数据存储空间之比约为3:1至4:1，M集群内存大小应该在原始数据量的1/10至1/3。

​ R节点测算：通常配置R节点的数量为M节点的1/3至1/6。

集群与高可用

​ 集群：解决并发压力大或者计算压力大的问题，其中双C节点或者多C节点是一种C节点的集群部署方式，而MPP集群则是MPP的集群部署方式。集群部署虽然解决单个C挂掉后不影响后续运行的问题，但是没有解决负载均衡Nginx或配置数据库挂掉后从而影响后续运行的问题。

​ 高可用：避免因为单点故障导致系统不可用。注意：高可用需要保证每个类型的节点都至少有2个（C、M、N、R、Nginx、配置数据库、DW高可用），此处的Nginx和配置数据库均需要至少双节点配置，因此需要更多的服务器。

​ 下面是集群部署与高可用部署的对比图：

BI架构部署

纯BI架构

​ 纯BI项目：不涉及到MPP、AI、DW，仅仅需要前端的数据统计分析和可视化。

​ 纯BI项目的特点：1、数据来源比较单一，来自于同一个数据库，或者是已经构建了统一的大数据平台或者数据仓库；2、数据质量高，不需要做太多的数据清洗和处理；3、数据量较小或者是现有数据平台的速度已经可以满足客户的期望；4、没有数据预测等AI方面的需求。

部署架构选择

​ 1、单节点：并发（多人干同一件事情）量比较小（例如小于100），并且没有高可用的要求。

​ 2、多节点：并发量大或者有高可用的要求。

单节点集群部署

​ 可以选择使用Z—Suite或者X—Suite（X—Suite限定为4核）；业务分析人员或者数据分析人员建议搭配永洪Desktop使用。

多节点集群部署

​ 必须使用Z—Suite；业务分析人员或者数据分析人员建议搭配永洪Desktop使用。

​ 大家访问的时候，先到Nginx负载均衡服务器，再由Nginx负载均衡服务器分配到各个C节点上去。

高可用部署

​ 必须使用Z—Suite；业务分析人员或者数据分析人员建议搭配永洪Desktop使用。

BI+MPP架构

​ BI+MPP项目：数据量较大或者执行效率差，需要提升数据查询和统计分析的效率。

​ BI+MPP项目的特点：1、已有数据库或数据平台可以直接取数；2、数据质量高，不需要做太多的数据清洗和处理；3、数据量大，现有平台计算性能低，或者需要隔离（出于数据安全考虑，不希望直接使用客户数据）或减少对于原有系统的影响；4、实时性要求不高（不能当天看当天，但是可以当天看昨天数据），可以接受数据更新，有一定程度的延迟。

部署架构选择

​ 从数据量和计算压力两个方面来对部署架构进行选择。

​ 一、单机BI + 本地集市：特点是：1、永洪BI使用单机部署；2、数据量相对较小，计算压力较轻；3、没有高可用的要求。

​ 二、单机BI + 分布式集市：特点是：1、并发用户少，用户BI使用单机部署；2、数据量大，计算压力大，计算频次高；3、没有高可用的要求。

​ 三、BI集群 + 分布式集市：特点是：1、永洪BI使用集群部署；2、数据量大，计算压力大，计算频次高；3、没有高可用的要求。

​ 四、BI集群 + 高可用分布式集市：特点是：1、并发用户数大；2、数据量大，计算压力大，计算频次高；3、有高可用的要求。

单机BI + 本地集市部署

​ 可以选择使用Z—Suite或者X—Suite（X—Suite和MPP均限定为4核）；业务分析人员或者数据分析人员建议搭配永洪Desktop使用。

单机BI + 分布式集市

​ 必须使用Z—Suite；业务分析人员或者数据分析人员建议搭配永洪Desktop使用。

BI集群 + 分布式集市

​ 必须使用Z—Suite；业务分析人员或者数据分析人员建议搭配永洪Desktop使用；对比上面的《单机BI + 分布式集市》章节，增加了C节点的个数。

BI集群 + 高可用分布式集市

​ 必须使用Z—Suite；业务分析人员或者数据分析人员建议搭配永洪Desktop使用。

BI+AI+MPP架构

​ BI+AI+MPP项目：已有数据积累，希望通过数据挖掘或者预测来发掘数据价值，辅助决策。

​ BI+AI+MPP项目的特点：1、已经积累了一定的历史数据，数据一致性较好；2、有客户画像、行为分析、精准营销、预测（例如销售预测，需求预测等），风险识别等方面的需求；3、AI深度分析通常都是在积累了大量的历史数据的基础上进行的，需要进行大量的数据探索，一般要用到MPP。

部署架构选择

​ 除去有没有AI的需求这个条件外，其他基本跟上面《BI+MPP项目》章节相同。

​ 一、单机BI + AI + 本地集市：特点是：1、永洪BI使用单机部署；2、数据量相对较小，计算压力较轻；3、没有高可用的要求。

​ 二、单机BI + AI + 分布式集市：特点是：1、并发用户少，用户BI使用单机部署；2、数据量大，计算压力大，计算频次高；3、没有高可用的要求。

​ 三、BI集群 + AI + 分布式集市：特点是：1、永洪BI使用集群部署；2、数据量大，计算压力大，计算频次高；3、没有高可用的要求。

​ 四、BI集群 + AI + 高可用分布式集市：特点是：1、并发用户数大；2、数据量大，计算压力大，计算频次高；3、有高可用的要求。

单机BI + AI + 本地集市部署

​ 可以选择使用Z—Suite或者X—Suite（X—Suite和MPP均限定为4核）；业务分析人员或者数据分析人员建议搭配永洪Desktop使用。

单机BI + AI + 分布式集市

​ 必须使用Z—Suite；业务分析人员或者数据分析人员建议搭配永洪Desktop使用。

BI集群 + AI + 分布式集市

​ 必须使用Z—Suite；业务分析人员或者数据分析人员建议搭配永洪Desktop使用；

BI集群 + AI + 高可用分布式集市

​ 必须使用Z—Suite；业务分析人员或者数据分析人员建议搭配永洪Desktop使用。

BI+AI+MPP+DW架构

​ BI+AI+MPP+DW项目：已有数据积累，数据来源众多，质量和一致性都不好，需要帮忙建立数据仓库。

​ BI+AI+MPP+DW项目的特点：1、已有多个业务系统，各个业务系统间数据分散；2、没有统一的数据视图，各个业务系统的数据一致性不高，数据质量差；3、希望构建跨多项业务的分析指标体系或者运营指标体系。

部署架构选择

​ 从“要不要建数仓”来对部署架构进行选择；另外纵使用户建立了数仓，也可以使用数据集市，因为集市可以作为补充，解决灵活性问题，而且数仓性能不高，集市提供高性能计算，可以更好的提升性能，提高灵活性。

​ 一、单机BI + AI + 本地集市 + DW：特点是：1、永洪BI使用单机部署；2、数据量相对较小，计算压力较轻；3、没有高可用的要求。

​ 二、单机BI + AI + 分布式集市 + DW：特点是：1、并发用户少，用户BI使用单机部署；2、数据量大，计算压力大，计算频次高；3、没有高可用的要求。

​ 三、BI集群 + AI + 分布式集市 + DW：特点是：1、永洪BI使用集群部署；2、数据量大，计算压力大，计算频次高；3、没有高可用的要求。

​ 四、BI集群 + AI + 高可用分布式集市 + DW：特点是：1、并发用户数大；2、数据量大，计算压力大，计算频次高；3、有高可用的要求。

单机BI + AI + 本地集市 + DW部署

​ 可以选择使用Z—Suite或者X—Suite（X—Suite和MPP均限定为4核）；业务分析人员或者数据分析人员建议搭配永洪Desktop使用。

单机BI + AI + 分布式集市 + DW

​ 必须使用Z—Suite；业务分析人员或者数据分析人员建议搭配永洪Desktop使用。

BI集群 + AI + 分布式集市 + DW

​ 必须使用Z—Suite；业务分析人员或者数据分析人员建议搭配永洪Desktop使用。

BI集群 + AI + 高可用分布式集市 + DW

​ 必须使用Z—Suite；业务分析人员或者数据分析人员建议搭配永洪Desktop使用。

BI架构部署配置推荐和注意事项

​ 如图所示为配置推荐表，其前提为：1、假设维度列/指标列之比为1:2；2、假设维度列平均长度为30个中文字符；3、数据存储包含1个备份；4、磁盘读取速度对于集市影响很大，建议通过多机集群部署的方式而不是一味提升机器的硬件配置。例如使用16Core64G内存的服务器。

数据集市的最佳实践

​ 从性能优化角度来看，数据集市的最佳实践：1、尽量减少入集市的列，使用频次多的，经常用的字段入集市；2、尽量将明细数据变成汇总数据入集市；3、尽量避免在集市中做大表Join；4、避免入集市后在数据集或者报表侧创建细节/维度表达式（即需要建细节表达式或者值映射，尽量在入集市之前进行）；5、能使用增量抽取就尽量使用增量抽取或打《Meta》（相当于打标签）的过程。通过《Meta》过滤是能够极大的降低集市阶段的压力。

集群

集群相关概念

单机

​ 简单的说，单机可以理解为将永洪部署到一台服务器上，所有的请求都有这台服务器处理，可以部署的方式有单C以及单机本地集市，但是当业务增长到一定程度，服务器的硬件无法满足业务需求，这个时候就需要用到集群。

集群

​ 集群是一组协同工作的服务实体，用以提供比单一服务实体更具扩展性与可用性的服务平台。在客户端看来，一个集群就像是一个服务实体，但事实上集群由一组服务实体组成。与单一服务实体相比较，集群提供了以下两个关键特性：可扩展性（即如果功能不够，可以快速增加节点来达到功能）和高可用（即高容错性，一台坏了，还有其他继续工作）。

​ 集群是单机的多实例，在多个服务器上部署多个服务，每个服务就是一个节点，这些节点的集合就叫做集群。

​ 永洪的集群可大可小，但是有一个特点，一个集群中要包含c、n、m、r 4个节点，其中n节点（相当于人的大脑）有且只有一个，c、m、r至少一个。

永洪节点角色介绍

节点名称	节点简称	功能描述
Naming节点	N节点	1. 负责统一调度各节点工作，使各节点压力相当，达到Map节点计算负载均衡 2. 整个集群中只能有一个N节点（这里指的是正在工作的N节点，双N系统中的备N是备用节点，在没有成为主N之前是没有加入集群的）
Map节点	M节点	1.负责存储数据集市中的分布式数据文件。 2.执行Naming节点分派的计算任务（集市计算，如果直接连接数据库，则下推到数据库里面计算）。 3.整个集群中有N个Map节点，Map节点承担了集群的大部分计算工作。
Reduce节点	R节点	1.多个M节点将同一计算任务的计算结果发送给同一个R节点，由该R节点对计算结果进行汇总。 2.集群中有多个R节点。
Client节点	C节点	1.接受终端客户请求，并将请求提交给N节点。 2.接受R节点的汇总计算结果并展现（登录，制作/查看报告都在C节点）。 3.与原始数据源相连接，抽取原始数据，并存入数据集市。

直连数据库查询跟集市查询的对比

​ 场景：一个相同的报表，在数据集入集市（集市查询）和未入集市（直连数据库）的情况下打开报表的过程如下：

直连数据库

​ A. Client节点接收到客户端请求，将报表中组件对应的sql发送给数据库

​ B. 数据库接收到sql后进行执行，执行后将结果返回给Client节点

​ C. Client节点接收到返回的数据，展示到报表中，客户端就看到这个报表打开了

​ 备注：对于直连数据库的报表，报表开的的快慢很大程度取决于数据库执行sql的速度以及返回数据的速度，前端渲染的时间一般不会太久。数据库执行的sql也不完全是sql数据集的sql，会在这个基础上进行拼接，通常查询的是一个汇总的结果。

集市查询

​ D. 客户端将该分析请求发送给Naming节点，请求执行该分析请求

​ E. Naming节点将分析任务分派到各个Map节点

​ F. 各Map节点接收naming节点分派的计算任务，并在本节点存储的数据中执行计算任务

​ G. 各Map节点计算完成后，将计算结果发送至同一个Reduce节点

​ H. Reduce节点接受各Map节点发送过来的计算数据，并将这些数据合并成一个结果，反馈给Client节点

​ I. Client节点接受汇总数据，同时将其展示到报表中，客户端就看到这个报表打开了

用直连数据库的一些常见场景

​ 1、对数据实时性要求比较高，大屏实时监控等。eg:数据库表的数据频繁更新，且要求报表能马上体现出来。

​ 2、数据库本身性能比较好，查询速度可以满足要求。

用集市查询的一些常见场景

​ 1、数据库性能不满足需求，主要表现是报表打开慢。集市是列存储，走集市查询可以提升查询速度。

​ 2、数据量大，且对数据的实时性要求不是太高（可以接受每天追加前一天的数据，或者几个小时前的数据）。

​ 3、历史数据分析。

集群部署

部署方式

​ 集群部署一般有两种方式，mpp方式直接部署集群，以及本地集市修改为集群的方式（推荐）。两种方式各有优缺点具体如下：

mpp方式

​ 优点：可视化界面方式部署，不涉及底层文件修改

​ 缺点：需要对部署很熟悉，部署前需要有一个完整的规划，节点ip，内存，端口，jdk等等都要先考虑好。如果部署的过程中一旦部署错了，就只能删掉重新部署，或者还是需要去底层配置进行修改。且这种方式部署的集群，修改节点（比如节点从c修改为cm）不能只修改节点信息还要修改其他。

本地集市方式

​ 优点：单个节点部署的时候全部以本地集市的方式进行安装，更加快速。对于部署的时候没有考虑到的点直接可以走配置文件修改。节点改动的时候直接修改节点类型就可以。

​ 缺点：需要对linux有一定程度的了解，涉及到各种文件修改。

本地集市方式部署集群

​ 以最简单的集群为例，cmr+ n两个节点的集群。

准备工作

​ 1、服务器上部署jdk，从V8.5+之后，要求jdk最好为jdk11,且尽量不要是openjdk。

​ 2、产品安装包（尽量是一个版本最新的稳定版本安装包，而不是最初的发布版本）

​ 3、各个节点license

​ 4、集群规划

id	ip	节点	端口
1	192.168.0.101	crm	8080/8005
2	192.168.0.102	n	8080/8005

分别在两台机器上部署两个本地集市

​ 1、给安装包设置执行权限，sh运行安装包，选择语言，一般为中文（如果选择中文后面出现中文乱码，不要重新用英文安装，这个时候服务器字体或者编码可能有问题，要先解决中文乱码再安装）

​ 2、一直按回车直到输入安装密钥（license）

​ 3、设置安装目录（通常是安装在服务器磁盘空余最多的盘，且保证路径不带中文，空格等，尽量在目录上带上节点或者版本；如果服务器已经安装过别的版本的产品，安装的时候请不要覆盖安装，一定要安装到新目录）

​ 4、设置服务端口（启动端口和关闭端口默认为8080,8005，需要保证这两个端口不被占用，或者换别的能用的端口）

​ 5、设置jdk/jre路径（jdk9+部署后不会有jre目录，因此jdk和jre路径都给一样的，给jdk路径）

​ 6、设置产品内存（默认为服务器内存的1/2，一般调整为服务器剩余内存的1/2-2/3，不可以更多了，也不是越多越好，服务器运行本身也是需要内存的）

​ 7、选择安装类型（选择数据集市-本地集市）

​ 8、后面的一直回车直到安装完成。

本地集市修改为集群

​ 简单来说就是修改两个配置文件（bi.properties和global_bi.properties）就可以将两个本地集市修改为集群。

​ 1、Yonghong/bihome/bi.properties

​ 2、Yonghong/bihome/global_bi.properties

​ 修改的具体内容和配置解释如下：

​ 针对CRM节点电脑：

​ 针对N节点电脑：

​ 备注：如果集群中存在一台服务器部署多个节点的情况，集群内部默认通信端口是5083和5066，由于在一台服务器上，其中一个节点的端口需要进行偏移。Eg:103服务器上部署了两个节点，分别是n和cmr，通常是对非N节点进行端口偏移，偏移的方式是需要偏移的这个节点bi.properties中添加dc.port.offset=1配置，表示使用的内部通信端口是5083+1（5084）以及5066+1（5067）。

集群成功部署标志

​ 查看集群是否配置启动成功的方法：1、linux看启动日志命令：

[root@localhost bin]# sh startup.sh
[root@localhost bin]# tail -f ../logs/catalina.out

​ 查看集群是否配置启动成功的方法：2、直接使用浏览器网页打开看是否能够正确访问：

​ 首先部署本地集市，接下来修改配置文件变成一个集群，修改完成后，开始启动集群，启动顺序：N→M→C（R通常不会单独部署，是跟其他节点一起，如果有备N的话，备N放在C之后启动），然后从C节点，系统监控-系统监控概览-集市节点状态查看节点情况，如果可以看到所有节点，那么集群理论上是没有问题了。

​ 在“管理系统”→“监控预警”→“集市节点状态”下查看节点状态：

​ **需要注意的是系统监控需要有C节点才能查看，且单独的C节点是不会显示在集市节点状态的。**eg:对于这样的集群（104 N，105 cmr ,106 c），在106和105上是可以查看系统监控的，而104不行。且105上查看集市节点状态，不会看到105节点，只能看到105和104；而在106上查看集市节点状态是可以看到3个节点104,105,106。

注意事项

​ 一个集群的节点之间需要通信，需要保证内部通信端口可用。

集群的高可用方案

高可用的概念

​ 通常用来描述一个系统通过专门的设计，从而减少停工的时间，而保持其服务的高度可用性。从产品中来讲，可以更加简单的理解为，一个集群由若干个节点组成，当某个节点出现故障，集群仍然具有可用性，就需要集群具有冗余性。常见的方式有：

​ 1、主从方式，主机工作，备机处于监控准备状态，当主机宕机时，备机接管主机的一切工作，待主机恢复正常后，使用者通过自动或手动的方式将服务切换到主机上运行。其中要解决的问题就是主备机之间数据的一致性。

​ 2、双机双工方式，两台主机同时运行各自的服务工作且相互监测情况，当一台主机宕机时，另一台主机立即接管它的一切工作，保证工作实时，关键数据在两台主机之间应该共享。

​ 3、集群工作方式，多台主机各自运行一个或多个服务，当某个主机故障时，运行在其上的服务就可以被其他主机接管。

各个节点的高可用方案

​ 简单的理解，只要一个集群中c、n、m、r至少存在一个，集群就应该能正常工作，但是并不是绝对的，还要结合节点本身的功能来进行更全面的考虑。

节点名称	节点简称	功能描述
Naming节点	N节点	3. 负责统一调度各节点工作，使各节点压力相当，达到Map节点计算负载均衡 4. 整个集群中只能有一个N节点（这里指的是正在工作的N节点，双N系统中的备N是备用节点，在没有成为主N之前是没有加入集群的）
Map节点	M节点	1.负责存储数据集市中的分布式数据文件。 2.执行Naming节点分派的计算任务。 3.整个集群中有N个Map节点，Map节点承担了集群的大部分计算工作。
Reduce节点	R节点	1.多个M节点将同一计算任务的计算结果发送给同一个R节点，由该R节点对计算结果进行汇总。 2.集群中有多个R节点。
Client节点	C节点	1.接受终端客户请求，并将请求提交给N节点。 2.接受R节点的汇总计算结果并展现。 3.与原始数据源相连接，抽取原始数据，并存入数据集市。

C节点高可用

原理：

​ 根本硬性条件：保障bihome内容的文件夹共享，C节点是咱们用于访问的节点，承担了以下工作：制作报告，查看报告，执行任务等等。**C节点高可用的方式保证有多个C同时工作，当一个C出现问题，还有其他的C节点可以顶上。**这种方式就涉及到一个问题，多个C节点上的资源（用户，权限，报表，数据集等）要保证一致，才能保证一个C出现故障的时候，另外的C可以接管它的工作。

方案：

共享资源的方式：

​ 共享的资源有哪些，咱们先看一下：

文件夹	含义
action	控制认证授权上操作的显示
dashborad	非“我的仪表盘”下的报表及报表目录
dashboard_MY_DB_	我的仪表盘，按照用户存储
excel	excel query上上传的excel文件
export	定时任务导出csv文件，导出任务的相对存储路径
geomap	col存放mapping信息，data存放地图的形状数据
image	产品中用到的图片
pdf	放FontsCJK.properties
protal	存放protal样式，及最终做好的用户门户
protalCell	存放门户组件
prefer	个性化设置信息
query	所有查询及查询目录
scheduler	所有作业、任务、触发器
secure	所有user group,role
sharedGMAP	存放char标记组：color,texture
table_style	所有table style
theme	所有主题
bi.properties	属性文件
global_bi.properties	数据集市共享的属性文件
permission	授权编辑信息

​ A. 多C节点做数据库系统，将资源（bihome的内容）都存储到数据库，保证多个C节点资源一致（都在数据库里面）。

​ 部署步骤如下：

​ a. 准备工作：

​ 一个数据库用于存储共享的资源，即bihome的内容，支持的数据库有oracle，db2，sqlserver，mysql，derby，postgresql

​ 集群规划

id	ip	节点	备注
1	192.168.0.107	n
2	192.168.0.108	crm	数据库系统
3	192.168.0.109	crm	数据库系统

​ b. 节点192.168.0.108和（192.168.0.109）做数据库系统

id	192.168.0.108-操作	192.168.0.109-操作
1	配置数据库连接信息	配置数据库连接信息
2	测试连接正常	测试连接正常
3	保存连接	保存连接
4	创建表
5	同步文件，文件系统同步到数据库
6	检查数据库生成的表，以及数据，确认无乱码
7	切换到数据库系统	切换到数据库系统
8	重启tomat	重启tomat
9	检查数据库管理，Yonghong/db.properties	检查数据库管理，Yonghong/db.properties

​ 在“管理系统”→“系统设置”→“数据空间配置”下查看“共享文件配置”（注意：这里有2个CRM节点，所以需要进行两次数据空间配置，两次的数据库名称等配置内容要一模一样，但是如果第一次配置时创建了表，第二次配置时就不需要再创建表了，因为他们的表是共享的。）：

​ c. 验证：在192.168.0.108新建一个报表，保存后，在192.168.0.109查看，如果可以查看，则为正常，反过来也测试一下（在192.168.0.109新建一个报表，保存后，在192.168.0.108查看）

​ d. 注意事项

​ 从数据库系统切换到文件系统：

​ 同步数据库的文件到文件系统，会将数据库中所有的数据copy并overwrite文件系统中bihome下的内容；会将db.file.system设为false，需要单独配置的信息写入bi.properties中，从db.properties删除这些配置。

​ db.properties的属性优先级高于bi.properties，所以当在数据库的环境下时，“需要单独配置的信息”需要在db.properties中修改并重启tomcat才能生效。如：当数据空间为数据库时，如果要修改license信息，需要修改db.properties里的license。

​ 如要修改bi.properties的内容

​ 1、下载，进入系统管理-> 数据库管理，选择bi.properties，点击下载；

​ 2、上传，本地修改bi.properties之后，选择修改后的文件，点击上传。

​ 3、重启集群。

​ 尽量保证数据库性能好一点，否则可能会有明显感觉数据库系统相对文件系统更慢。且该数据库最好跟业务库分开。

​ 硬性要求：做数据库系统的多个C一定要保证系统时间一致，误差不能超过1s。

多C负载方式：

​ 通过nginx，F5等方式做多C节点负载

N节点高可用

原理

​ N节点负责统一调度，如果N节点出现宕机，所有集市相关的功能均不能正常使用。（直连数据库的报表不受影响，因为他的计算是下推到数据库的，而不是在集市）

方案s

​ 基于Zookeeper的Naming双活方案，当主N节点出现宕机，备份N节点自动转换为主N节点，宕机的N节点需要手动去启动，然后作为备N节点。

Zookeeper是什么

​ ZooKeeper是一个分布式协调技术，它是集群的管理者，监视着集群中各个节点的状态，根据节点提交的反馈进行下一步合理操作。

为什么使用zookeeper

​ 开源免费；在Hadoop、Storm、HBase、Solr等大型分布式项目中都将Zookeeper作为其核心组件，用于分布式调度；从性能，易用性，还是稳定性上来说Zookeeper都达到了工业产品的标准；Zookeeper提供了数据存储系统和通知机制两个功能，通过基于这两个功能上API，能够实现命名服务、分布式锁、集群管理和Master选举等功能。

Zookeeper选举原理

Zookeeper部署规则

​ 在奇数个节点部署Zookeeper 并配置相应的属性，组成一个ZooKeeper 集群。奇数个的原因是Zookeeper过半存活即可用特性：集群中只要有过半的机器是正常工作的，那么整个集群对外就是可用的。所以我们建议配置奇数个（至少3个，通常也是3个）。

Zookeeper默认端口

​ 2181：对client端提供服务

​ 3888：选举leader使用

​ 2888：zookeeper集群内机器通讯端口（Leader监听此端口）

产品内置zookeeper

​ 因为产品内置了zookeeper，所以不需要单独配置zookeeper，只需要修改一下配置即可。

部署

A. 集群规划

​ 配置zookeeper之前，因为之前已经配置过集市，所以需要先停掉，然后再配置。

id	ip	节点	备注
1	192.168.0.108	n	主N，部署zookeeper节点
2	192.168.0.100	crm	部署zookeeper节点
3	192.168.0.105	crm	部署zookeeper节点
4	192.168.0.100+1	n	备N

B. Zookeeper部署

Yonghong/bihome/bi.propeties

ip	节点	bi.properties
dc.io.ip	dc.node.types	dc.port.offset	dc.backup
192.168.0.108	n	192.168.0.108	n		false
192.168.0.100	crm	192.168.0.100	crm
192.168.0.105	crm	192.168.0.105	crm
192.168.0.100+1	n	192.168.0.100	n	1	true

dc.io.ip表示本机ip，也就是当前节点ip

dc.node.types表示节点类型

dc.backup表示是否是备份N节点，只有N节点需要添加该配置，主N为false,    备N为true

dc.port.offset表示节点偏移，当一台机器部署多个节点需要该配置对集群通 信    端口进行偏移
配置好后，wq退出编辑

Yonghong/bihome/global_bi.propeties

rpc.repeat=false

zk.conn.hosts=192.168.0.106\:2181,192.168.0.107\:2181,192.168.0.100\:2181

dc.node.naming=192.168.0.107

dc.use.backup=true

dc.io.local=false

dc.io.local 表示是否是本地集市，true表示本地集市，false表示是集群

dc.node.naming 表示N节点的ip

dc.use.backup=true表示使用naming节点双活机制

zk.conn.hosts表示ZooKeeper连接地址 ip：zookeeper端口号（对应zoo.cfg中clientPort）,一台服务器配置多个zookeeper，要注意端口号不要冲突

Zookeeper/conf/zoo.cfg

此文件默认没有，需要手动新建，配置如下：

[root@localhost conf]# vi zoo.cfg进入编辑状态

server.1=192.168.0.106:2888:3888

server.2=192.168.0.107:2888:3888

server.3=192.168.0.100:2888:3888

initLimit=10

syncLimit=5

tickTime=2000

clientPort=2181

dataDir=/yonghong/yh902cmr/zookeeper/data

dataLogDir=/yonghong/yh902cmr/zookeeper/log
wq退出编辑

Server.1对应的集群节点配置 ip：通讯端口：选举端口；一台服务器配置多个zookeeper要注意端口号，默认2888，3888；server后的数字和myid中的值保持一致。

clientPort,ZooKeeper 端口 : 用于与 CNMR 节点进行通信的端口号

dataDir,存储快照文件 snapshot 的目录

dataLogDir,日志目录：ZooKeeper 日志输出目录

Zookeeper/data/myid

​ 集群节点编号：直接vi myid进入编辑状态后，在编辑状态下分别在对应IP节点输入对应的myid数字即可。

ip	节点	myid
192.168.0.108	n	1
192.168.0.100	crm	2
192.168.0.105	crm	3
192.168.0.100+1	n

C. Zookeeper启停

​ a. 启动顺序：启动所有节点zookeeper（zookeeper之前无先后区分）→等待zookeeper集群稳定（查看zookeeper日志无报错）→启动tomcat集群（主N→M→C→备N）

​ b. 启动方式：

​ 进入安装路径下的Yonghong/zookeeper/bin；

对zkServer.sh文件赋予权限-----chmod +x  zkServer.sh；

启动-----sh zkServer.sh start；

日志-----启动目录下zookeeper.out

​ Zookeeper启动后，再去启动产品集群，启动产品集群依然是先启动N节点，具体步骤通上面章节。

D. 主N宕机后处理

​ a. 备N自动切转换成主N，需要手动去启动宕机的N（这是旧版本操作，新版本会自己自动修改，不需要手动）

​ b. 启动宕机的N之前修改配置，bi.properties中dc.backup=false修改为true；global_bi.properties中dc.node.naming=ip改为备N节点ip

E. 常见问题

1、启动zkServer.cmd会报错：

​ Zookeeper集群采用的是选举算法，当集群中其他节点还没有启动的时候，选举算法就会出现异常，因为至少三台能选举出一个leader，2n+1台机器，可以选举n个leader，当全部启动起来后，就不会报异常，所以上述的报错是可以忽略的，尽管启动这三个节点即可。

2、启动zkServer.cmd/zkServer.sh闪退

​ 可在zkServer.cmd中endlocal前加句“pause”，当再启动zkServer.cmd时就会将异常信息打印在进程中：

3、重启Zookeeper无法启动

​ 在启动Zookeeper后，/zookeeper/data文件夹中会生成zookeeper_server.pid文件，在异常情况下，会导致无法成功重启Zookeeper。需要手动删除该pid文件，重新启动Zookeeper。

4、提高Zookeeper集群的可用性

​ 尽量避免一大批机器同时down掉的风险，最好能够为每台机器配置互相独立的硬件环境。如果大部分机器都挂在同一个交换机上，一旦出现问题，将会对整个集群服务造成严重影响。其它类似的还有：供电线路，散热系统等。

​ 在真正的实践过程中，如果条件允许，通常建议尝试跨机房部署。

m节点高可用

原理

​ 从M节点作用说起，M节点是主要承担的是计算任务，计算使用的集市文件是存储在M节点Yonghong/cloud文件下，集市文件是通过同步（增量）任务生成，默认文件只生成一份，存储在其中一个M节点，当这个M节点宕机，对应的集市文件就读取不到，数据就出现问题。要实现M节点的备份，首先想到的对集市文件进行备份，咱们M节点的高可用策略就是让集市文件生成的时候生成两份，存储在两个不同的M上，其中一个M出现问题，还有另一个可以使用，尽量保证数据的完整性。

方案

​ 在集群有多个M的情况下，在所有节点global_bi.properties添加配置dc.fs.dup=2，实现集市文件生成两份。

要求和限制

​ 首先集群要有多个M，同时网络传输压力更大，原因是同样的文件要传输两份，另外同步（增量）任务执行的时间会更长，导数C节点的压力会更大，对磁盘的要求更高。

r节点高可用

原理

​ R节点主要用于汇总M节点的计算结果，也不存储集市文件，所以理论上R节点只要有多个，就能满足高可用。

典型集群方案

1. cnmr

​ 最小集群——本地集市，报表可以选择直连数据库也可以直连集市。比较常用，一般来说本地集市就可以满足很多客户要求，如果不满足要求，则再采用集群的方法。

2. c+c

​ 两个及其以上c节点做数据库系统共享文件，也就是报表直连数据库。适用于并发访问量比较大的情况，但是要求数据库性能比较好。

3. cnmr+cmr

​ 最小集群，相当于两个节点的集群。要求服务器内存比较高，对服务器内存和CPU都有一定要求。

4. cnmr（负载）+cmr（负载）+cnm（导数）

​ 包含所有高可用的最小集群。特点：服务器数量少，且需要做高可用的情况下使用，既有双c负载，也有naming双活。适用于服务器配置高，cpu和内存均要比较充足，c、m、r对内存cpu的要求比较高。

5. cr(访问)+cr(访问)+c(导数)+m+m+m+n+n

​ 至少需要3个M节点，他是大集群方案，适用于大数据量，满足c节点高可用，隔离访问和导数，naming双活，可扩展性强。