使用flashback query巧妙抽取指定数据(r5笔记第75天)

在生产环境中存在着大量的数据,和业务是密切相关的。比如系统中的某个业务流程出现了问题,如果想复现就会显得非常困难,甚至是不太可能的,比如电信系统中存在着大量的客户信息,相关联的表的数据量都基本在千万,亿级。 如果要抽取,是全量抽取还是增量抽取。全量抽取可行,但是实际操作起来也不现实,如果要在测试环境中复现,可能需要大量的存储空间,而且相比来说也显得有些浪费,同事对于数据安全也是很大的隐患,毕竟我们不愿意客户信息这么轻易的暴露出来。 如果增量的,问题的关键是怎么增量,比如从100万客户信息中抽取一个客户的信息,按照这个要求抽取某个表的数据还是可行,但是如果很多表之间存在依赖,存在关联,很多表抽取就会是一个很大的困扰,毕竟对于dba来说,要控制这个抽取过程而且还要兼顾业务,是很困难的。 除此之外,还有一个主要问题就是在大批量数据中,怎么保证数据的事务一致性,比如存在表customer,subscriber,一个客户customer下可以对应多个用户subscriber,如果我们定位customer下的某个subscriber,这个时候,可能会有很多的事务在运行,我们需要同时保证subscriber相关的表的数据在同一个事务内是一致的。这对于抽取数据复现来说就是最基本的数据保证了。所以从抽取难度上和数据完整性上我们需要做一些工作。 其实我们可以巧妙的利用flashback query来完成这个看似不可能完成的任务。 我画了如下的图标进行解释。 首先在数据源头的schema中存在着一些表,我们假设为table1,table2,table3... table1,table2,....这些表之间是存在着一些对应关系的。比如customer表的customer_id和subscriber表中的customer_id是对应的。subcriber表的subscriber_id和产品订购表是存在关联的,这些关联关系至关重要。 即图中绿色的部分,这些都是一些表关系的定义,根据表中的字段进行映射。这样一个几百万数据的表根据映射关系可能就会过滤出来很少的数据来。 这个抽取的过程怎么保证事务数据的完整性呢,这个时候就需要flashback query来完成。在抽取的时候我们会根据需要的时间戳来作为数据抽取的基准时间,所有的关联的表都会基于这个时间戳进行抽取。 比如对于customer表,我们提供了customer_id=100 抽取customer表就会是下面的样子。 select * from customer as of timestamp xxxxx where customer_id=100; 如果customer和subscriber的映射关系是customer_id 则抽取subscriber就是 select *from subscriber as of timestamp xxxxx where customer_id=100; 以此类推,中间的蓝色柱子就代表抽取的基线时间。

如果抽取的进展顺利,这些数据是能够很快抽取抽起来的,那么问题来了,怎么生成dump文件呢,这个时候我们可以考虑使用一个临时的schema来存在这些抽取的表数据,因为抽取的数据量是很小的,所以可以考虑使用一个临时的schema,直接在这个schema中导出数据即可。 即图中右半边的temp schema。 有了临时的schema,那么抽取的数据是怎么放到临时的schema中呢,还是使用最普通的ctas 对于customer表使用 create table customer nologging as select * from customer as of timestamp xxxxx where customer_id=100; 对于subscriber表使用 create table subscriber nologging as select *from subscriber as of timestamp xxxxx where customer_id=100; 因为这个schema的临时使用,实在找不出需要更多日志的理由,所以可以考虑直接使用logging选项来,加快临时表的生成速度。这样数据就会顺利在temp schema中生成,这个时候就跟钢铁导入磨具已经成型了,后期的加工就更加灵活了。 在哪个测试环境需要我们就可以灵活的使用exp/expdp来导出dump,根据需要导入制定的环境了。 整个过程还是比较简单的,但是其中还是有很多的细节需要注意,一个是抽取的逻辑,这个需要和开发,业务部门进行配合,把表的依赖,关联关系确认,另外就是抽取的粒度,尽量保证抽取的粒度要小,即最好提供限定的个别id来,如果抽取的数据量大了,对于系统的负载来说也是很高,得不偿失。

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2015-06-21

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏腾讯技术工程官方号的专栏

腾讯容器云平台GaiaStack亮相kubeCon

KubeCon + CloudNativeCon 首次登陆中国上海。这意味着中国Kubernetes 爱好者们齐聚上海来参与这场全球范围内最大的 Kuberne...

13K3
来自专栏AI研习社

在树莓派上实现人脸识别

预计在不久后的将来,人脸识别和身份认证技术将在我们的日常生活中扮演一个非常重要的角色。这项技术为我们开辟了一个全新的世界,它几乎适用于我们生活的方方面面。面部识...

5861
来自专栏蓝鸟资源分享网

关于服务器性能的一些思考

平常的工作中,在衡量服务器的性能时,经常会涉及到几个指标,load、cpu、mem、qps、rt,其中load、cpu、mem来衡量机器性能,qps、rt来衡量...

4605
来自专栏马洪彪

eml文件解析实例,简历信息抓取工具

先上工具效果图,如下图所示: ? 背景 某公司使用58同城进行人员招聘,当有应聘人员通过58同城给该公司投简历后,58同城会发送一份邮件到该公司的注册邮箱,邮件...

4197
来自专栏美团技术团队

人工智能在线特征系统中的生产调度

前言 在上篇博客《人工智能在线特征系统中的数据存取技术》中,我们围绕着在线特征系统存储与读取这两方面话题,针对具体场景介绍了一些通用技术,此外特征系统还有另一个...

56910
来自专栏钱塘大数据

钱塘干货 | 数据收集和处理工具一览

进入大数据时代,调查报道愈加成为信息战。从哪里收集有效数据?如何抽取、筛选、整合、分类大量琐碎的信息?如何分享、存储数据,并实现随取随用?钱塘君整理了一张数据收...

4537
来自专栏AI研习社

如何在 Kaggle 中高效搜索数据集?快吃下这枚安利

对于关注数据科学的同学来说,Kaggle 上庞大的数据集是一个极好的资源池,但是这么多的数据,如何进行更精准的搜索?近日,Kaggle 官方博客就刊登了 Rac...

2854
来自专栏机器之心

机器之心实操 | 亚马逊详解如何使用MXNet在树莓派上搭建实时目标识别系统

选自AWS 机器之心编译 参与:思源 在过去的五年中,深度神经网络已经解决了许多计算困难的问题,特别是计算机视觉。因为深度神经网络需要大量的计算力来训练模型,所...

4009
来自专栏逍遥剑客的游戏开发

VR中物理的网络同步

之前做VR游戏时也是尝试了几种物理的同步方案, 最近看到Oculus Blog上也分享了一些, 经验, 做个笔记.。

3336
来自专栏大数据

掌握数据处理的新方法!

来自:数据观 https://www.shujuguan.cn/?from=qiehao 一提到数据处理,我们首先想到的就是excel,作为日常必备的办公软件,...

2086

扫码关注云+社区

领取腾讯云代金券