云社区 博客 博客详情

【数据仓库】双集群系统方案探讨

wzhyalfa 发表于 2020-06-16 14:09:18 2020-06-16
4
3

【摘要】 本文主要是探讨OLAP关系型数据库框架的数据仓库平台如何设计双集群系统,即增强系统高可用的保障水准。

本文主要是探讨OLAP关系型数据库框架的数据仓库平台如何设计双集群系统,即增强系统高可用的保障水准。

 

当前社会、企业运行当中,大数据分析、数据仓库平台已逐渐成为生产、生活的重要地位,不再是一个附属的可有可无的分析系统,外部监控要求、企业内部服务,涌现大批要求7*24小时在线的应用,逐步出现不同等级要求的双集群系统。

 

数据仓库主流数据库平台均已存在多重高可靠保障措施设计,如硬盘冗余的raid设计、数据表冗余、节点备用冗余、机柜备用数据交叉等,以及加上服务进程高可用冗余设计,其最大化程度满足数据仓库服务持续在线。

 

但现实场景,如数据库软件缺陷、定期加固补丁、产品迭代、硬件升级这些产品现实因素,以及来自机房、数据中心、地域、网络的外部灾难故障因素,均在降低数据仓库可用性服务水平。

 

鉴于数据仓库存在大量数据吞吐,针对不同数据库、不同可用性要求,若需要设计双集群冗余设计,可选技术手段分别有数据同步模式、双ETL模式、双活模式,具体探讨如下:

 

1.       数据同步模式

a)         架构

由于数据库IO能力有限、且两个数据库间带宽有限,除了首次全量同步之后,后续通常考虑增量同步技术,即如何准确、高效获取“变化数据”,一般存在日志同步技术、备份增量同步技术、逻辑数据同步;

b)        日志同步技术

日志同步技术,有业内最著名Oracle Golden Gate,大部分厂家也有自己的实现方式,像Teradata近年来推出Unity CDM(变化数据广播)技术,而我司GaussDB for DWS可采用xlogpage进行变化数据同步。

优势:直接同步变化数据增量,数据量少,要求带宽低,但目前市面技术大都只适合数据每日变化量较少的数据仓库环境;

劣势:现实的技术门槛高,应对各类异常场景适应能力差,对主数据库侵入性能要求高,一旦主库繁忙,同步时效低;面对全删全插等变化数据量大场景,同步吃力;

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代码中往往存在samplerandomrow_number排序这种同一份数据产生不同结果集的函数,造成两套系统数据不一致;

该问题建议用户使用替代函数、明确取值、唯一排序,确保最终数据一致性;

同时,该设计逻辑正确情况下,哪份数据均可被业务采信,若该数据对下游影响少,可每日批后从主库同步备库,拉平数据;

g)         报错修数逻辑考虑

其中一套系统的数据发生报错、修数行为,会涉及到另一套系统的维护行为;

可选作法是保留操作逻辑,待另一套系统发生报错时重复执行一次;

其它交给数据质量校验(DQC)、数据校验去复查;

h)         干预重跑修数逻辑考虑

若批后重跑,两套系统重跑逻辑一致,涉及重复劳动(或支撑平台优化),相对简单;

但涉及批量过程中发现部分数据需要重跑,由于两套调度进度不一致,会导致

i)           数据校验

 i.              校验时机

批后校验,逻辑清晰,对调度依赖少,即根据整体调度进度,做到分层、分库或整体数据校验;

准实时校验,即侵入调度环节,在每个作业完成时,均发起日志解析,提取每个SQL影响记录数,若相应作业SQL存在影响记录数不一致场景,即中止较晚完成的调度平台调度后续作业;

ii.              校验手段

增全量校验,即针对不同加工逻辑的数据表,区分增、全量数据值,以最小代价覆盖所有业务表

iii.              校验方法

通常作法有记录数、汇总值、checksum校验;

汇总值校验,通过是数值型字段直接sum、字符型计算字符长度的sum、时间类型则转换成数值相加的比对;

Checksum校验,针对全表或部分字段,进行md5hash运算,完成两套系统一致性比对;

对于关系型数据库,校验开销代价逐步递增(记录数 < 汇总值 < checksum校验);往往是结合增量校验、结合重要指标,区分维度校验,日常增量逻辑校验,定期全量校验,在校验数据一致性和系统性能之间取得平衡点。

j)           优化考量

i.              校验改进

即嵌入调度平台,提取ETL代码运行日志,通过执行SQL影响的记录值,实时进行两套系统完成作业日志比对,发现记录值影响,立即停止备库调度,采用人工或自动方式修复数据,继续后续批量。

该作法最大好处是,即时发现数据异常,避免问题放大,保障备库更高可用性;

ii.              引入统一维护平台

即减少人为双系统维护操作,代码变更平台化,修数逻辑平台化,由平台分别下发两套调度平台、两套数据库。

3.       双活模式

以下基于Teradata Unity产品理念的延伸构想

a)         架构

b)         双活功能点

i.              访问路由能力

客户端直接将中间件作为数据库登陆,保持原来登陆逻辑不变;

中间件根据登陆用户及附加参数实现拒绝登陆、双系统登陆、或单系统登陆,实现写登陆、读登陆,实现受控方式登陆、或非受控方式登陆;即实现受控和非受控方式的系统读写;

同时兼顾考虑异常路由选择或同步路由选择,满足最大化异常执行及少部分同步需求场景;

ii.              SQL分发能力

经中间件发送的SQL指令,正常发送到相应数据库,并接受数据库响应信息;

iii.              批量导入、导出能力

针对数据大批量的导入,需要考虑采用更加高效的加载协议进行数据加载,并考虑经中间件复制数据块,异步分发两个数据库;

数据导出,需要考虑高效数据导出协议,从其中一套数据库正确导出数据;

iv.              更新类SQL校验能力

DeleteUpdateInsertMerge等更新类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)         数据同步模式” – 日志同步技术

适用数据变化量小、数据传输压力小的数据场景,通常只适用于小型数据仓库平台;

对于规模小的平台,RPORTO可以接近0

b)         数据同步模式” – 备份增量同步技术

适合大数据量同步场景,实现方式容易被用户理解;

往往需要数据库备份工具具备增量备份恢复能力;同时考验备份工具消除相关硬件限制条件,让该技术方案更加灵活;

双集群的初始化同步往往采用全备全恢的逻辑实现,可以最大化、最快拉平存量数据;

对于规模大的平台,RPO往往需要小时级别,RTO最好水准也在分钟、10分钟以上;同时主集群需要保障一定资源量供数据同步使用,对主集群开销大;

c)         数据同步模式” – 逻辑数据同步技术

适用灵活同步场景,往往数据同步量不会太大,或同步时间可容忍场景;

此场景往往适合于用户对其数据仓库ETL过程元数据信息清晰、完整,依赖客户开发能力,相关同步数据存在清晰ETL算法,结合调度作业运行进度,动态发起相关数据表增、全量同步;

对于中等规模的平台,RPO可以做到分钟、半小时,RTO可以维持在分钟级;

d)         ETL模式

需要两套ETL调度环境,整体成本翻倍,但调度逻辑清晰、易于理解和维护;

较容易匹配不同规模的数据仓库平台采纳;

较难实现数据实时比对,以及数据发生不一致之后的控制逻辑(若需要实现,对于调度逻辑侵入性大);

ETL调度批量中途,较难实现两套调度链路协调重跑;

同时数据不一致,依赖于数据同步模式技术辅助实施;

由于主备调度进行不一致,无法做到主备统一视图展现;

若双集群硬件相当,RPORTO均可以维持在分钟级别;

e)         双活模式

需要独立中间件、且严重依赖数据库自身厂商,中间件实现难度大;

中间件的高可用(稳定性)成为它落地的最大障碍;

ETL模式的升级版,能适应各类数据仓库双集群场景;

绝大部分场景下,RPORTO均可以接近0,特别是双活同时在线能力,不存在双集群的主备切换,RTO可以做到0;同时存在统一视图,不会因为其中一个集群故障,造成前后同一个查询返回结果不一致场景;

5.       总结比对


登录后可下载附件,请登录或者注册

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区),文章链接,文章作者等基本信息,否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件至:huaweicloud.bbs@huawei.com进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容。
评论文章 //点赞 收藏 3
点赞
分享文章到微博
分享文章到朋友圈

上一篇:【DWS】MPP架构下数据倾斜率分析

下一篇:8种ETL算法汇总大全!看完你就全明白了

评论 (4)


xuxugod

1楼2020-06-16 15:00:49

cb-lion

2楼2020-06-16 15:13:24

彩虹上的水瓶座

3楼2020-06-16 16:25:40
学习了,特别赞!

DWS殿阁大学士

4楼2020-11-25 16:28:35

登录后可评论,请 登录注册

评论