支付宝双11的功臣-分布式关系型数据库(oceanbase)

图片 3

2.2使用LastUPstamp作为过滤条件,查询>源DB的源表中时间戳字段,这样就可以查询出自上一次同步触发点到当前时间待同步的记录(增、改)

3、全表删除插入方式

按照业务特点将数据拆分:

            try
            {
                SqlConnection obConnSrc = new SqlConnection(connLMSStr);
                SqlConnection obConnDest = new SqlConnection(mconnCCSStr);

                string lastTamp = ClsDatabase.gGetFieldValue(obConnSrc, "update TS_SyncUptime set UPTime=GETDATE() OUTPUT (deleted.LastUPstamp) as oldtamp FROM TS_CCSUptime WHERE TableName=N'tableNameA'", "oldtamp");


                string selectSql = @"SELECT id,aaa,bbb,ccc,ddd,eee,fff  
                                  FROM tableNameA WHERE 其它同步过滤查询条件 AND CONVERT(bigint,sys_tamp)>{0}";

                selectSql = string.Format(selectSql, lastTamp);

                master.TransferBulkCopy(selectSql, obConnSrc,
                                "tableNameA", obConnDest,
                                 (stable) =>
                                 {
                                     var colMaps = new Dictionary<string, string>();
                                     foreach (DataColumn col in stable.Columns)
                                     {
                                         colMaps.Add(col.ColumnName, col.ColumnName);
                                     }
                                     return colMaps;
                                 },
                                 (tempTableName, stable, destConn, srcConn) =>
                                 {
                                     StringBuilder saveSqlBuilder = new StringBuilder("begin tran" + Environment.NewLine);

                                     string IUSql = master.BuildInsertOrUpdateToDestTableSql("tableNameA", tempTableName, new[] { "id" }, stable.ExtendedProperties[master.MapDestColNames_String], 2);
                                     saveSqlBuilder.Append(IUSql);

                                     saveSqlBuilder.AppendLine("commit");

                                     ClsDatabase.gExecCommand(destConn, saveSqlBuilder.ToString());


                                     ClsDatabase.gExecCommand(srcConn, "update TS_SyncUptime set UPTime=GETDATE(),LastUPstamp=CONVERT(bigint,sys_tamp) FROM TS_SyncUptime WHERE TableName=N'tableNameA'");

                                     return false;
                                 });


            }
            catch (Exception ex)
            {
                writeLog(ex);//记错误日志
            }

 

————————————————————-华丽的分割线————————————————————-

有些场景下,需要隔离不同的DB,彼此DB之间不能互相访问,但实际的业务场景又需要从A
DB访问B DB的情形,这时怎么办?我认为有如下常规的三种方案:

8、比较和分析

这个方案完全不行,原因不多说了。

上述三种方案,第1、2方案基本都是定制化的常规方案,我(梦在旅途,)今天要分享的是第3种方案:跨DB增量(增、改)同步两张表的数据,注意是增量同步,其中删除这个我没有说明,原因是如果DB表中记录是物理删除(即:真实的DELETE),那就无法简单的通过程序代码获取到删除的记录,除非在DB中加入DELETE触发器记录删除记录的主键到临时表或开启更改追踪(CHANGE_TRACKING)或DB日志分析,故本文讲的是不给表、DB增加额外负担的情况实时增量同步,至于删的同步这个我认为最好是逻辑标记删除(过期最后清理【真实删除】),而不要物理删除。

1、触发器方式
触发器方式是普遍采取的一种增量抽取机制。该方式是根据抽取要求,在要被抽取的源表上建立插入、修改、删除3个触发器,每当源表中的数据发生变化,就被相应的触发器将变化的数据写入一个增量日志表,ETL的增量抽取则是从增量日志表中而不是直接在源表中抽取数据,同时增量日志表中抽取过的数据要及时被标记或删除。为了简单起见,增量日志表一般不存储增量数据的所有字段信息,而只是存储源表名称、更新的关键字值和更新操作类型(KNSEN、UPDATE或DELETE),ETL增量抽取进程首先根据源表名称和更新的关键字值,从源表中提取对应的完整记录,再根据更新操作类型,对目标表进行相应的处理。

方案二、数据拆分(分库分表)

 之前的文章同步主要是基于TranFlag标记字段
或触发器来实现同步,这种方式必需对表数据的增、删、改逻辑都有要求与规范,也就是增、改必需更改TranFlag=0,删必需记录表删除临进表中,这样才能实现同步逻辑,而今天是在这个同步基础上(BCP),不给表、DB增加额外负担的情况实时增量同步,对数据源的插入、改动没有要求。

该方式通过分析数据库自身的日志来判断变化的数据。关系犁数据库系统都会将所有的DML操作存储在日志文件中,以实现数据库的备份和还原功能。ETL增晕抽取进程通过对数据库的日志进行分析,提取对相关源表在特定时间后发生的DML操作信息,就可以得知自上次抽取时刻以来该表的数据变化情况,从而指导增量抽取动作。有些数据库系统提供了访问日志的专用的程序包(例如ORACLE的LOGMINDER),使数据库日志的分析工作得到大大简化。

基于上面描述,OB整个系统架构:

2.3利作BCP执行同步(详见之前文章说明)

这样,对表T的所有DML操作就记录在增量日志表DML_LOG中,注意增量日志表中并没有完全记录增量数据本身,只是记录了增量数据的来源。进行增量ETL时,只需要根据增量日志表中的记录情况,反查源表得到真正的增量数据。
SQL代码
(1)创建增量日志表DML_LOG:
CREATE TABLE DML_LOG(
ID NUMBER PRIMARY KEY, //自增主键
TABLE NAME VARCHAR2(200). //源表名称
RECORD ID NUMBER, //源表增量记录的主键值
DML TYPE CH根(1)。∥增量类型,I表示新增:U表示更新;D表示删除
EXECUTE DATE DATE //发生时间
);

更新操作写入内存,当内存数据量超过一定值时,生成快照存储在SSD中。

1.双方提供RESET
API,需要访问不同DB数据时,可以通过API来获取指定数据;

在我从事的ETL工作中,大部分都是采用时间戳方式进行增量抽取,如银行业务,VT新开户,使用时间戳方式,可以在固定时间内,组织人员进行数据抽取,进行整合后,加载到目标系统。而触发器方式,虽然可以自动进行抽取,但是执行频率过多,影响效率!第三种方式对于大数据量来说是非常不可取的,尤其是对于一些银行、电信行业,因为数据全量比较大,所以进行增量校对是比较耗时的,总起来说,个人趋向使用时间戳方式进行增量抽取,当然具体情况要看工作的使用环境!

方案三、参考google的bigtable

如上步骤即可实现可靠的同步,有人可能有疑问,这样就能实现可靠同步吗?我这里解释一下:

可见,ETL在进行增量抽取操作时,有以上各种机制可以选择。现从兼容性、完备性、性能和侵入性3个方面对这些机制的优劣进行比较分析。数据抽取需要面对的源系统,并不一定都是关系型数据库系统。某个ETL过程需要从若干年前的遗留系统中抽取EXCEL或者CSV文本数据的情形是经常发牛的。这时,所有基于关系型数据库产品的增量机制都无法工作,时间戳方式和全表比对方式可能有一定的利用价值,在最坏的情况下,只有放弃增量抽取的思路,转而采用全表删除插入方式。完备性方面,时间戳方式不能捕获DELETE操作,需要结合其它方式一起使用。增量抽取的性能因素表现在两个方面,一是抽取进程本身的性能,二是对源系统性能的负面影响。触发器方式、日志表方式以及系统日志分析方式由于不需要在抽取过程中执行比对步骤,所以增量抽取的性能较佳。全表比对方式需要经过复杂的比对过程才能识别出更改的记录,抽取性能最差。在对源系统的性能影响方面,触发器方式由于是直接在源系统业务表上建立触发器,同时写临时表,对于频繁操作的业务系统可能会有一定的性能损失,尤其是当业务表上执行批量操作时,行级触发器将会对性能产生严重的影响;同步CDC方式内部采用触发器的方式实现,也同样存在性能影响的问题;全表比对方式和日志表方式对数据源系统数据库的性能没有任何影响,只是它们需要业务系统进行额外的运算和数据库操作,会有少许的时间损耗;时间戳方式、系统日志分析方式以及基于系统日志分析的方式(异步CDC和闪回查询)对数据库性能的影响也是非常小的。对数据源系统的侵入性是指业务系统是否要为实现增抽取机制做功能修改和额外操作,在这一点上,时间戳方式值得特别关注该方式除了要修改数据源系统表结构外,对于不支持时间戳字段自动更新的关系型数据库产品,还必须要修改业务系统的功能,让它在源表T执行每次操作时都要显式的更新表的时间戳字段,这在ETL实施过程中必须得到数据源系统高度的配合才能达到,并且在多数情况下这种要求在数据源系统看来是比较“过分”的,这也是时间戳方式无法得到广泛运用的主要原因。另外,触发器方式需要在源表上建立触发器,这种在某些场合中也遭到拒绝。还有一些需要建立临时表的方式,例如全表比对和日志表方式。可能因为开放给ETL进程的数据库权限的限制而无法实施。同样的情况也可能发生在基于系统日志分析的方式上,因为大多数的数据库产品只允许特定组的用户甚至只有DBA才能执行日志分析。闪回查询在侵入性方面的影响是最小的.

这里,我主要想揭秘下oceanbase,因为整个支付宝的交易的库都是依赖于它。oceanbase究竟是什么?用官方的话是这样的:OceanBase是一个支持海量数据的高性能分布式数据库系统,实现了数千亿条记录、数百TB数据上的跨行跨表事务,由淘宝核心系统研发部、运维、DBA、广告、应用研发等部门共同完成。那么以前在没有使用ob之前,支付宝都用的什么呢?mysql或者oracle。这两个一个是开源的数据库,一个是甲骨文公司的商业付费数据库。简单的来说都是人家老外搞得!其实这两个数据库已经很强大了,支付宝以前的框架都是基于这两种数据库的。但是随着业务的发展,这两种数据库也带来了弊端。

关于程序代码实现跨DB同步表数据方案,之前已有总结过,详见:https://www.cnblogs.com/zuowj/p/6264711.html 
—》4.利用BCP(sqlbulkcopy)来实现两个不同数据库之间进行数据差异传输(即:数据同步)

IF DELETING THEN
INSERT INTO DML_LOG(ID,TABLE_NAME,RECORD—
ID,EXECUTE_DATE,DMLJYPE)
VALUES(SEQ_DML_LOG.NEXTVAL,’TEST ,:OLD.ID,SYSDATE,
L_DML_TYPE);
ELSE
INSERT INTO DML_LOG(ID,TABLE_NAME,RECORD_
ID,EXECUTE_DATE,DMLJYPE)
VALUES(SEQ_DML_LOG.NEXTVAL,。TEST ,:NEW.ID,SYSDATE,L
TIROL_TYPE);
ENDIF;
END;

为什么分为定期合并和数据分发?

3.3当然如果某个时间点的数据或某个DB有问题,导致一直同不不成功,可能会出现一直同步不过去的情况,这种情况可以加上预警+人工干预,这个是概率的事情。

、特定数据库方式(ORACLE)
以下介绍常见的针对特有数据库系统的增景抽取方式。
7.1
ORACLE改变数据捕获(CHANGEDDATACAPTURE,CDC)方式:ORACLECDC特性是在ORAELE9I数据库中引入的。CDC能够帮助识别从上次抽取之后发生变化的数据。
利用CDC,在对源表进行INSERT、UPCLATE或DELETE等操作的同时就可以提取数据,并且变化的数据被保存在数据库的变化表中。这样就可以捕获发生变化的数据,然后利用数据库视图以一种可控的方式提供给ETL抽取进程,作为增量抽取的依据。CDC方式对源表数据变化情况的捕获有两种方式:同步CDC和异步CDC。同步CDC使用源数据库触发器来捕获变更的数据。这种方式是实时的,没有任何延迟。当DML操作提交后,变更表中就产生了变更数据。异步CDC使用数据库重做日志(REDOLOG)文件,在源数据库发生变更以后,才进行数据捕获。
7.2
ORACLE闪回查询方式:ORACLE9I以上版本的数据库系统提供了闪回查询机制,允许用户查询过去某个时刻的数据库状态。这样,抽取进程可以将源数据库的(BI)
当前状态和上次抽取时刻的状态进行对比,快速得出源表数据记录的变化情况。

我们都知道阿里双11,除了创造了世界史上的交易奇迹之外,也创造了世界技术史上的奇迹。支付宝的峰值达到了每秒12万笔,这在技术界简直是一个奇迹。为什么说他是一个奇迹呢?简单的来解释一下:其实在日常开发中,打交道最多的就是数据库,好多开发都戏称只会增、删、改。但是千万不要小看增、删、改,因为假设你只有一个用户访问的你的数据库,你怎么写都可以,但是如果有几十万,上百万,上千万,乃至上亿用户呢?如果操作不当,那么你的数据库一定会down掉。所以看上去简单的东西其实一点都不简单,就好像风清扬一样,简单的剑招却蕴含着上千变化。

 图片 1

5、日志表方式

那么可以这么解决。采用单台服务器记录最近一段时间的修改增量(内存中记录),而以前的数据不变(基线数据)。写事务只在单台服务器写,避免了2PC,高效的实现了跨行跨表事务。然后定期合并修改增量到基线数据服务器。

3.通过程序代码实现两个DB的数据同步(增、删、改、查),如:可以定时轮询源DB的A表,然后获取变更的记录(一般是:增、删、改的记录),再通过程序代码把源DB的A表的变更记录批量更新(若是新增、则是插入,若是修改,则是更新,若是删除,则是删除)到目的DB的A表中。

对于建立了业务系统的生产数据库,可以在数据库中创建业务日志表,当特定需要监控的业务数据发生变化时,由相应的业务系统程序模块来更新维护日志表内容。增量抽取时,

2、updateserver通知rootserver数据版本变化,rootserver心跳通知chunkserver。

3.1同步触发时记录当前触发时间点,并取得上一次的触发时间点(这里的上一次触发时间点是指上一次开始准备同步的记录时间点,确保从上一次查询到同步完成之间的时间点都包括其中,防止漏数据)

4、全表比对方式

2、金融账务系统每天要记录很多的流水,但是考虑到一半在线上保存一年的流水,那么每天新增的几乎占比很小。

2.具体关键同步逻辑如下:

时间戳方式是指增量抽取时,抽取进程通过比较系统时间与抽取源表的时间戳字段的值来决定抽取哪些数据。这种方式需要在源表上增加一个时间戳字段,系统中更新修改表数据的时候,同时修改时间戳字段的值。有的数据库(例如SQL
SERVER)的时间戳支持自动更新,即表的其它字段的数据发生改变时,时间戳字段的值会被自动更新为记录改变的时刻。在这种情下,进行ETL实施时就只需要在源表加上时间戳字段就可以了。对于不支持时间戳自动更新的数据库,这就要求业务系统在更新业务数据时,通过编程的方式手工更新时间戳字段。使用时间戳方式可以正常捕获源表的插入和更新操作,但对于删除操作则无能为力,需要结合其它机制才能完成。

这样的话,方案就生成了,参考bigtable,在hbase的开源基础上自己开发一套。后来经过验证发现不行,因为,首先hbase的开源不彻底,每台单机支持的数据有限,然后是必须引入分布式事务2PC,一般时间在2~5s左右,因为对于hbase这种nosql只保证单行事务,如果要跨行跨表操作是支持不了的。并且分布式事务太耗时,所以这个方案只能抛弃!

1.TS_SyncUptime表用于记录与管理同步任务的信息,主要包含如下几个字段:

图片 2

在chunkserver中,一般存储子表,而一个子表由多个sstable过程,每个sstable的容量4k~64(主键有序)。

TableName:要同步的表名,UPTime每一次同步的触发时间点(可更改),sys_tamp行变更时间戳(不可更改),LastUPstamp行最后有效变量时间戳(可以更新)

全表比对即在增量抽取时,ETL进程逐条比较源表和目标表的记录,将新增和修改的记录读取出来。优化之后的全部比对方式是采用MD5校验码,需要事先为要抽取的表建立一个结构类似的MD5临时表,该临时表记录源表的主键值以及根据源表所有字段的数据计算出来的(BI)

————————————————————-华丽的分割线————————————————————-

代码如下:(以下同步适用于SQL SERVER 不同DB的表增量同步)

6、系统日志分析方式

以上就是我对ob的原理的总结,其中也看出一些问题,首先updateserver需要非常大的内存,第二为了避免单点,应该是主备切换,这里面用了zookeeper中的paxos算法,选举主机。整个ob还是非常复杂的,如果想深入探究还需要花费很大的功夫啊!

这种方案的优点是:可以根据实际情况灵活定制同步的表数据,不局限于某一张表或某一个DB,可以保证不同DB间同步表的数据一致性,让本来跨DB操作表变成了同一个DB的事情,而且可以增、删、改、查,功能不受限;缺点是灵活性太强,程序代码实现可靠的跨DB的实时同步逻辑的实现复杂度较高,对于开发人员的要求较高,如果写的同步逻辑无法保证实时、可靠、高可用,那对于业务来讲是灾难性的。

全表删除插入方式是指每次抽取前先删除目标表数据,抽取时全新加载数据。该方式实际上将增量抽取等同于全量抽取。对于数据量不大,全量抽取的时间代价小于执行增量抽取的算法和条件代价时,可以采用该方式。

图片 3

这种方案优点是隔离性、定制性强,统一出入口,只能通过指定的API访问指定的数据;缺点与优点是对立的,也就是定制性太强,导致每次业务发生变更,需要访问不同数据的时候,需要双方更改API的入参或返参,降低了开发效率;而且无法使用表JOIN,这样在某些情况下也会导致查询数据效率变低。目前主流的方案都是建议使用API方案

例如,对于源表为ORACLE类型的数据库,采用触发器方式进行增量数据捕获的过程如下:

3、每台chunkserver启动定期合并或数据分发,从updateserver获取每个子表对应的增量更新数据。

 上述同步代码逻辑很简单,可以参照之前的文章,这里主要是说明几个重要点:

MD5校验码,每次进行数据抽取时,对源表和MD5临时表进行MD5校验码的比对,如有不同,进行UPDATE操作:如目标表没有存在该主键值,表示该记录还没有,则进行INSERT操作。

updateserver:

You can leave a response, or trackback from your own site.

Leave a Reply

网站地图xml地图