摘要： 本文次要是探讨 OLAP 关系型数据库框架的数据仓库平台如何设计双集群零碎，即加强零碎高可用的保障水准。
以后社会、企业运行当中，大数据分析、数据仓库平台已逐步成为生产、生存的重要位置，不再是一个从属的可有可无的剖析零碎，内部监控要求、企业外部服务，涌现少量要求 7 *24 小时在线的利用，逐渐呈现不同等级要求的双集群零碎。
数据仓库支流数据库平台均已存在多重高牢靠保障措施设计，如硬盘冗余的 raid 设计、数据表冗余、节点备用冗余、机柜备用数据穿插等，以及加上服务过程高可用冗余设计，其最大化水平满足数据仓库服务继续在线。
但事实场景，如数据库软件缺陷、定期加固补丁、产品迭代、硬件降级这些产品事实因素，以及来自机房、数据中心、地区、网络的内部劫难故障因素，均在升高数据仓库可用性服务水平。
鉴于数据仓库存在大量数据吞吐，针对不同数据库、不同可用性要求，若须要设计双集群冗余设计，可选技术手段别离有数据同步模式、双 ETL 模式、双活模式，具体探讨如下：
1. 数据同步模式
a) 架构
因为数据库 IO 能力无限、且两个数据库间带宽无限，除了首次全量同步之后，后续通常思考增量同步技术，即如何精确、高效获取“变动数据”，个别存在日志同步技术、备份增量同步技术、逻辑数据同步；
b) 日志同步技术
日志同步技术，有业内最驰名 Oracle Golden Gate，大部分厂家也有本人的实现形式，像 Teradata 近年来推出 Unity CDM（变动数据播送）技术，而我司 GaussDB for DWS 可采纳 xlog 及 page 进行变动数据同步。
劣势： 间接同步变动数据增量，数据量少，要求带宽低，但目前市面技术大都只适宜数据每日变动量较少的数据仓库环境；
劣势： 事实的技术门槛高，应答各类异样场景适应能力差，对主数据库侵入性能要求高，一旦主库忙碌，同步时效低；面对全删全插等变动数据量大场景，同步吃力；
c) 备份增量同步技术
次要利用各数据库平台备份恢复能力，进行数据增、全量备份、复原；通常源库备份数据压缩之后，经网络传输后，解压复原到指标库；对应 GaussDB for DWS 可采纳 roach 备份复原工具实现；
劣势： 利用同一技术实现增、全量数据同步，逻辑清晰，各场景容错能力强；
劣势： 要求数据库反对增备能力，且往往锁期待重大；
d) 逻辑数据同步
该项次要波及较高的业务侵入性，即充沛获取 ETL 调度数据流元数据，对应数据库当日数据稳固之后，发动数据表导出 - 导入操作，针对数据表加工个性，抉择增全量同步规定，进行数据准实时同步。
劣势： 较上述同步技术，能够实现多样选择性同步，同步过程由施行我的项目自身管制，做到表级数据同步，不须要全零碎同步，即可实现局部业务双集群；
劣势： 客户化同步逻辑，操作前置依赖多，施行投入人力多，较难推广；
2. 双 ETL 模式
a) 架构
即采纳两套独立调度平台进行数据加工，抽取同一个数据源（往往是落地稳固的数据交换平台），采纳同一套 ETL 代码依赖逻辑调度，各自生成指标数据，往往批量过程中，采取主库对外继续服务，待主备库数据准实时或批后校验统一后，再凋谢备库对外服务。
若双集群数据产生不统一场景，次要以主库数据为准，笼罩备库。该同步过程，须要应用到“数据同步模式”相干同步技术。
b) 参照落地架构
c) 加载源数据思考
为保障两套 ETL 调度加载数据源统一及数据复用，往往要求搭建一个数据交换平台。因为至多存在一个文件被两套调度读取，要求数据交换平台两倍过往吞吐能力；且禁止加载的数据文件被二次笼罩，导致两套零碎加载不统一；
d) 调度依赖程序思考
因为 ETL 作业调度关系没有配置齐备，即存在 A 作业应用 B 作业的数据，但不配置依赖关系（绝大部分的状况是 A 作业可容忍 B 数据的时效，是否最新数据均能够应用，故为时效，业务上不配置依赖关系；当然也存在物理工夫上，通常 B 远远早于 A 执行），导致两套零碎 A 作业生成数据不统一。
该场景下，在一套调度平台无奈发现此问题，但存在两套零碎的校验比对，即发现数据不统一；
该问题倡议用户补全依赖关系，确认执行程序一致性；
当然若心愿灵便应用依赖关系，则需二次开发，管制两套调度当日时序一致性；
e) ETL 代码服务器思考
为了防止两套 ETL 调度代码保护不统一，需思考对立保护渠道，蕴含不限于同一个代码存储源、版本服务器，以及代码变更机会
f) 存在不确定值的 SQL 函数返回
ETL 代码中往往存在 sample、random、row_number 排序这种同一份数据产生不同后果集的函数，造成两套零碎数据不统一；
该问题倡议用户应用代替函数、明确取值、惟一排序，确保最终数据一致性；
同时，该设计逻辑正确状况下，哪份数据均可被业务采信，若该数据对上游影响少，可每日批后从主库同步备库，拉平数据；
g) 报错修数逻辑思考
其中一套零碎的数据产生报错、修数行为，会波及到另一套零碎的保护行为；
可选作法是保留操作逻辑，待另一套零碎产生报错时反复执行一次；
其它交给数据品质校验（DQC）、数据校验去复查；
h) 干涉重跑修数逻辑思考
若批后重跑，两套零碎重跑逻辑统一，波及重复劳动（或撑持平台优化），绝对简略；
但波及批量过程中发现局部数据须要重跑，因为两套调度进度不统一，会导致
i) 数据校验
i. 校验机会
批后校验，逻辑清晰，对调度依赖少，即依据整体调度进度，做到分层、分库或整体数据校验；
准实时校验，即侵入调度环节，在每个作业实现时，均发动日志解析，提取每个 SQL 影响记录数，若相应作业 SQL 存在影响记录数不统一场景，即停止较晚实现的调度平台调度后续作业；
ii. 校验伎俩
增全量校验，即针对不同加工逻辑的数据表，辨别增、全量数据值，以最小代价笼罩所有业务表
iii. 校验办法
通常作法有记录数、汇总值、checksum 校验；
汇总值校验，通过是数值型字段间接 sum、字符型计算字符长度的 sum、工夫类型则转换成数值相加的比对；
Checksum 校验，针对全表或局部字段，进行 md5 或 hash 运算，实现两套零碎一致性比对；
对于关系型数据库，校验开销代价逐渐递增（记录数 < 汇总值 < checksum 校验）；往往是联合增量校验、联合重要指标，辨别维度校验，日常增量逻辑校验，定期全量校验，在校验数据一致性和零碎性能之间获得平衡点。
j) 优化考量
i. 校验改良
即嵌入调度平台，提取 ETL 代码运行日志，通过执行 SQL 影响的记录值，实时进行两套零碎实现作业日志比对，发现记录值影响，立刻进行备库调度，采纳人工或主动形式修复数据，持续后续批量。
该作法最大益处是，即时发现数据异样，防止问题放大，保障备库更高可用性；
ii. 引入对立保护平台
即缩小人为双系统维护操作，代码变更平台化，修数逻辑平台化，由平台别离下发两套调度平台、两套数据库。
3. 双活模式
以下基于 Teradata Unity 产品理念的延长构想
a) 架构
b) 双活性能点
i. 拜访路由能力
客户端间接将中间件作为数据库登陆，放弃原来登陆逻辑不变；
中间件依据登陆用户及附加参数实现回绝登陆、双系统登陆、或单零碎登陆，实现写登陆、读登陆，实现受控形式登陆、或非受控形式登陆；即实现受控和非受控形式的零碎读写；
同时兼顾思考异样路由抉择或同步路由抉择，满足最大化异样执行及少部分同步需要场景；
ii. SQL 散发能力
经中间件发送的 SQL 指令，失常发送到相应数据库，并承受数据库响应信息；
iii. 批量导入、导出能力
针对数据大批量的导入，须要思考采纳更加高效的加载协定进行数据加载，并思考经中间件复制数据块，异步散发两个数据库；
数据导出，须要思考高效数据导出协定，从其中一套数据库正确导出数据；
iv. 更新类 SQL 校验能力
Delete、Update、Insert、Merge 等更新类 DML SQL 进行 SQL 影响记录数校验；
DDL/DCL 执行返回码验证一致性能力；
v. 对象注册性能
通过路由及创建对象的 DDL 语句，实现对象动静注册；
通过命令行指令实现对象注册；
适当减少对象索引、束缚索引的注册信息，用于扩大细粒度对象锁能力，进步数据仓库 ETL SQL 并发能力；
* 数据仓库环境下，只须要思考到表级双活的能力，不倡议施行字段级、记录级双活；
vi. 对象锁能力
依据 SQL 指令给相应对象动静加锁、开释锁；
同时依据数据库自带的锁特色，至多辨别读、写锁管制，以及局部数据库的脏读性能锁；
vii. 对象状态控制能力
进行治理的多套数据库在线状态管制；
进行对象状态管制性能，蕴含不限于在线、离线、只读、只写、被动中断缓存中、被动中断缓存中、不可用等状态；
viii. 缓存能力
进行 SQL 指令流缓存能力，以及缓存复原执行的能力；
进行 SQL 与加载数据联合缓存、以及缓存复原执行的能力；
ix. SQL 异样控制能力
思考用户体验，始终由返回响应正确的 SQL 指令返回客户端；
两个数据库返回均胜利，但返回的影响记录数不统一，则响应慢的数据库对应 SQL 及波及对象被设置成不可用状态；
若两套数据库其中一套执行胜利，另一套执行失败，则执行失败的数据库 SQL 和波及对象被设置为被动中断缓存中，同时缓存 SQL，定时重试 SQL；
若两套数据库返回均报错，才告诉客户端报错；
若 SQL 波及对象已解决非在线状态，则新提交的 SQL 被缓存，新提交 SQL 相应对象被设置为被动中断缓存中。
针对中间件和数据库之间，存在数据库已执行完、但中间件未收到信号场景，需思考闪环该场景（如减少事务锁等）；
c) Teradata Unity 参照落地架构
次要通过 Unity 实现多集群 SQL、数据散发与治理；
Data Mover 实现集群间数据同步；
Eocsystem Manager 实现数据批后主动校验及不统一重同步事件触发；
Viewpoint 实现零碎平台透视图展示与保护，并对接用户告警平台；
d) 中间件高可用思考
因为引入了中间件（前置）服务，即该服务的稳固、牢靠对双活模式至关重要。
数据库单套零碎自身曾经具备极高的可用性，引入中间件后，因为所有数据库拜访行为均通过该中间件，中间件任何异样均同时影响两套数据库拜访能力。
除了中间件自身所有相干服务须要满足高可用之外，还需思考极其场景下 bypass 能力，此项能力在于极其异样条件下，能够保障系统继续服务的能力。
高可用场景中，存在管制节点脑裂与主动升主场景，需借鉴仲裁机制缩小脑残裂产生；
e) 数据重同步思考
即利用“数据同步模式”相干同步技术，实现两套数据库数据重同步能力；
f) 不确定值的 SQL 函数思考
最佳计划，是采纳“数据同步模式”的数据日志重同步技术，间接将第一套数据库 SQL 执行后果的日志信息同步到第二套数据库中，打消返回后果不统一；
局部简略的零碎工夫函数，间接通过中间件改写，保障 SQL 执行后果一致性；
另外，则通过 SQL 改写，保障 row_number 函数进行主键或全字段排序，保障 SQL 执行后果一致性；
g) 异样会话重放能力
针对异样会话过程的 SQL，可能须要从会话建设后，可视化抉择，倒回前几个 SQL 从新执行，并指定过程 SQL 是否参加后果集校验，以及 SQL 回放完结的确认动作，让异样场景解决伎俩更加丰盛。
4. 实用场景
a)“数据同步模式”– 日志同步技术
实用数据变动量小、数据传输压力小的数据场景，通常只实用于小型数据仓库平台；
对于规模小的平台，RPO、RTO 能够靠近 0；
b)“数据同步模式”– 备份增量同步技术
适宜大数据量同步场景，实现形式容易被用户了解；
往往须要数据库备份工具具备增量备份恢复能力；同时考验备份工具打消相干硬件限度条件，让该技术计划更加灵便；
双集群的初始化同步往往采纳全备全恢的逻辑实现，能够最大化、最快拉平存量数据；
对于规模大的平台，RPO 往往须要小时级别，RTO 最好水准也在分钟、10 分钟以上；同时主集群须要保障肯定资源量供数据同步应用，对主集群开销大；
c)“数据同步模式”– 逻辑数据同步技术
实用灵便同步场景，往往数据同步量不会太大，或同步工夫可容忍场景；
此场景往往适宜于用户对其数据仓库 ETL 过程元数据信息清晰、残缺，依赖客户开发能力，相干同步数据存在清晰 ETL 算法，联合调度作业运行进度，动静发动相干数据表增、全量同步；
对于中等规模的平台，RPO 能够做到分钟、半小时，RTO 能够维持在分钟级；
d)“双 ETL 模式”
须要两套 ETL 调度环境，整体老本翻倍，但调度逻辑清晰、易于了解和保护；
较容易匹配不同规模的数据仓库平台驳回；
较难实现数据实时比对，以及数据产生不统一之后的管制逻辑（若须要实现，对于调度逻辑侵入性大）；
ETL 调度批量中途，较难实现两套调度链路协调重跑；
同时数据不统一，依赖于”数据同步模式”技术辅助施行；
因为主备调度进行不统一，无奈做到主备对立视图展示；
若双集群硬件相当，RPO、RTO 均能够维持在分钟级别；
e)”双活模式“
须要独立中间件、且重大依赖数据库本身厂商，中间件实现难度大；
中间件的高可用（稳定性）成为它落地的最大阻碍；
“双 ETL 模式”的升级版，能适应各类数据仓库双集群场景；
绝大部分场景下，RPO、RTO 均能够靠近 0，特地是双活同时在线能力，不存在双集群的主备切换，RTO 能够做到 0；同时存在对立视图，不会因为其中一个集群故障，造成前后同一个查问返回后果不统一场景；
5. 总结比对
点击关注，第一工夫理解华为云陈腐技术~