本地有一个小的环境，今天照例登上sqlplus，突然发现报了如下的错误。一看原来归档满了。我记得前几天做一个批量操作临时把temp文件resize了很大，限于本...
本文将带来直播回顾第五篇《银行核心海量数据无损迁移：TDSQL数据库多源异构迁移方案》。 视频内容 关于TDSQL异构数据同步与迁移能力的建设以及应用方面的整个内容分四个部分： l 一是异构数据库方面包括数据分发迁移同步的背景——我们为什么要发展这一块的能力以及现在这部分服务的基本架构 事实上，作为国产自研的成熟的分布式数据库产品，TDSQL对内稳定支撑腾讯海量计费业务，对外开放5年来也通过云服务为微众银行等超过600家金融政企机构提供高性能、高可用、高可靠、强一致的分布式数据库服务。 当然，除了支持数据库迁移，多源异构迁移方案也支撑数据汇总、分发等业务场景，这也是TDSQL具备完善的产品服务体系的体现。 我们原先的策略是全量上报到消息队列，有的时候会带来一些问题，比如说业务去清理一些历史的表，比如说一些流水的大表可能去做日志的删除等等，会批量去做一些操作，这个时候会产生一些疯狂往消息队列上打一些业务并不关心
2核2G云服务器首年95元，GPU云服务器低至9.93元/天，还有更多云产品低至0.1折…
对于大型项目中海量数据使用sqlloader是一种全新的方式，不过很明显,sqlloader的可扩展性更强，但是基于oracle平台的数据迁移来说，外部表的性能也不错。 对于数据迁移来说也是一个很好的方案。 使用外部表来做数据迁移，可以“动态”加载数据，能够很方便的从数据库中加载数据，对于数据校验来说就显得很有优势了，而对于sqlloader来说，可能得等到数据加载的时候才知道是不是有问题，如果对于数据的准确性要求极高 ，可以使用外部表动态加载数据到备库，和现有的数据做比对，减少在升级过程中带来的灾难。 还有关于数据类型，对于clob,blob的加载，大家都比较头疼，在sqlloader中可能需要做一些额外的工作，来外部表中就和操作普通的表没有什么区别。 先来说说数据抽取的部分。
在之前的章节中，讨论过了通过 分区+并行等方式来进行超大的表的切分，通过这种方式能够极大的提高数据的平均分布，但是不是最完美的。 比如在数据量再提高几个层次，我们假设这个表目前有1T的大小。 有10个分区，最大的分区有400G,那么如果我们想尽可能的平均的导出数据，使用并行就不一定能够那么奏效了。 比方说我们要求每个dump文件控制在200M总有，那样的话400G的分区就需要800个并行才能完成，在实际的数据库维护中，我们知道默认的并行数只有64个，提高几倍，也不可能超过800 所以在数据量极大的情况下 如果想数据足够平均，就需要在rowid上做点功夫。 我们先设定一个参数文件，如下的格式。 可以看到表memo数据量极大，按照200M一个单位，最大的分区（P9_A3000_E5）需要800个并行。 AAB4VPAA4AACP5/EJA' 10, where rowid between 'AAB4VPAA4AACQCAAAA' and 'AAB4VPAA5AACHx/EJA' 然后我们来看看数据是否足够平均
数据库作为系统的重要节点，其稳定性和性能格外重要，数据库的全力保障是一个大的挑战。电商大促，这场没有硝烟的战争很多人已有体会，在此不再赘述。 现在，我们直接切入主题--数据库如何 积极应对，全力保障 大促活动。这个题目分解为三个部分进行讲解： 第一部分，准备工作；第二部分，大促进行时；第三部分，大促后复盘。 “功夫在诗外”，同样，大促活动下数据库稳定、顺畅的运行，主要工作在大促前的准备上，所以，准备工作是重点。 一.大促前准备工作 1.对大促活动应该尽可能地去了解，去熟悉。 2.梳理大促活动用到的系统链路，对链路上的系统和应用有个较为清晰的了解，制作大促活动全链路的数据库流程图。 3.梳理链路上的数据库资源。 比如，为应对大促活动的系统请求，SA可能会增加应用的部署。 13.大促期间数据库性能阈值预估。合理的阈值是准确衡量大促情况下数据库健康程度的温度计。 14.梳理可降级的应用。
数据分析，大数据应用的一个主要场景，通过数据分析指标监控企业运营状态，及时调整运营和产品策略。大数据平台上运行的绝大多数大数据计算都是关于数据分析的，各种统计、关联分析、汇总报告，都需要大数据平台。 公司角度，运营数据是公司运行发展的管理基础，既可通过运营数据了解公司目前发展的状况，又可以通过调节这些指标对公司进行管理，即数据驱动运营。 而运营数据的获得，需要在应用程序中大量埋点采集数据，从数据库、日志和其他第三方采集数据，对数据清洗、转换、存储，利用SQL进行数据统计、汇总、分析，才能最后得到需要的运营数据报告。 数据可视化图表与数据监控 数据以图表方式展示，可以更直观展示和发现数据的规律，互联网运营常用可视化图表有如下几种。 1. 折线图 横轴为时间，展示在时间维度上的数据变化规律。 2. 监控大屏： 做展示用，在公司显眼的位置放一个大屏幕，显示主要的运营指标和实时的业务发生情况，给公众和参观者展示直观的公司商业运营情况。
一年一度的双十一又双叒叕来了，给技术人最好的礼物就是大促技术指南！ 而经过这些年的发展，大促早已不仅仅局限于电商行业，现在各行各业其实都会采用类似方式做运营活动，汽车界有 818，电商有 618 、11.11 等等，各种各样的大促场景，对包括数据库在内的基础软件提出了很多新挑战 最后是海量数据的处理，中通有很多消息源的接入，需要针对每一票进行全链路路由和时效的预测，定位到每一票的转运环节，数据量很大，对时效的要求也很高。 大促对于企业而言，除了支持业务创新，也是一次对自身技术架构的大练兵和全链路演练。通过大促的极致考验，企业的 IT 架构、组织流程、人才技能都获得了大幅提升。 而在大促中的经验和思考，也会加速企业日常的业务创新节奏，提升技术驱动的创新效率，打造增长新引擎。
在优化的过程中，就涉及到了迁移的问题。 一般来说，业界针对升级和迁移，会提供热迁移和冷迁移两种方案： 冷迁移：冷迁移需要对数据库先进行停机，等迁移完成后，再重启数据库。 热迁移：热迁移无需对数据库进行停机，整个迁移过程中，数据库可以持续对外提供服务。用户对于热迁移无感知。 云开发作为基础服务提供商，是无法进行冷迁移的，因此，对于云开发来说，思考如何在现有的架构基础之上做好热迁移势在必行。 想要对云开发的数据库进行热迁移，首先，需要理解云开发数据库的底层架构。 热迁移的基础是数据库底层的迁移能力，而数据库底层的迁移分为三个状态： 数据同步：对快照和数据库的 oplog 进行拷贝和追踪； 数据割接：在 oplog 几乎追上时，进行数据割接； 目标集群可用：完成割接后 生产环境下目前迁移用户请求如图所示： ? 以上便是基于小程序云开发自身的数据库架构设计的数据库底层热迁移实现方案概述。 如果你对上文有任何疑问，欢迎在下方评论区留言。
对于数据迁移来说，无论准备工作准备的多么充分，在测试和正式生产环境中，心里还是会对冲突的数据有一些疑虑，心里感觉没底，因为生产的数据也是在不断变化的，要迁移的数据也在做相应的改动，在这样的环境中，其实数据抽取的工作还是顾虑比较少的 可能会有一些紧急的数据更改任务，数据的稽核等等。。 对于主键相关的数据排查，如果在数据迁移前能够发现，是最好的了，这样可以极大的减少dba的工作量。 个人就是在这种窘境中这样设想了一个方法，首先通过查询主键信息，得到主键索引相关的列，然后通过Intersect来查询那些主键字段的数据在生产和迁移库上有冲突，这个过程可以创建一个临时的用户来加载外部表， 所以省去了创建额外的数据空间，而且可以考虑在备库上执行。 基本思路就是通过如下的sql语句来找到冗余的数据。
一、缓存技术简介 1、缓存是指将被频繁访问的热点数据存储在距离计算最近的地方，以方便系统快速做出响应。 方案 三、扩展，深度了解JVM堆内内存和堆外内存（转载） 1、什么是堆内内存 Java 虚拟机在执行Java程序的过程中会把它在主存中管理的内存部分划分成多个区域，每个区域存放不同类型的数据。 所以，操作系统并不能直接得到堆内内存区域所存储的数据在主存中的正确地址。在一些特定的时间点，Java虚拟机会进行一次彻底的垃圾回收（full gc）。 这意味着：这样一次垃圾收集对Java应用造成的影响，跟堆内内存所存储的数据的多少是成正比的，过大的堆内内存会影响Java应用的性能。 2. 同时因为这部分区域直接受操作系统的管理，别的进程和设备（例如GPU）可以直接通过操作系统对其进行访问，减少了从虚拟机中复制内存数据的过程。
在之前的博文中分享了关于数据抽取流程的一些思路，整体来说，数据的抽取是辅助，数据的加载是关键。加载的过程中每一步需要格外关注，稍有偏差就可能造成数据的损坏或者丢失。 通过比较只读用户（即目标数据）和外部表用户中的外部表数据(源数据)，可以灵活的匹配主键列，非唯一性约束列可以很有效的进行数据的冗余比较。 有了这种方式，在多次的数据迁移中，都可以在数据加载前提前进行数据检查。着实让人放心不少，对于提升自信心是很有帮助的。一旦发现了数据问题，就可以及时发现，提前发现，让专门的团队及时修复数据。 至于最关键的数据加载，就是外部表用户和目标数据用户之间的数据关联了。可以通过insert append的方式进行数据的导入。可以根据数据情况进行切分粒度的控制。 比如我们有一个表test特别大，有500G，我们就可以把这个大表在收据抽取的时候进行细粒度的切分，比如我们通过启用并行生成了500个dump文件，这样每个dump文件就基本上是1G的标准，每1G的数据加载我们及时提交
采用外部表抽取数据的流程图如下： ? 大体标注了一下抽取的基本结构，我们会尽量保证不去碰原本的数据源，会创建两个临时的用户，一个是只读用户，这个用户上只有同义词，只具有数据源中的select权限。 这就对应上面红色标注的1，而另外一个用户是外部表用户，所有通过创建外部表都会在这个用户下进行，生成了dump文件之后，我们可以随时删除外部表，这个时候为了保证相关的drop操作不会牵扯到数据源，外部表用户会继承只读用户中的 当开始抽取数据的时候，会去查找是否有权限读取数据，会找到只读用户，最终能够读取数据源的数据，这就对应红色标注的3,4 当满足了基本的条件，就开始生成外部表的dump，可以为一个表生成多个dump，而且这个过程是并行的
欢迎您关注《大数据成神之路》 本文将简单总结下一些处理海量数据问题的常见方法。当然这些方法可能并不能完全覆盖所有的问题，但是这样的一些方法也基本可以处理绝大多数遇到的问题。 根据这个问题我们来计算下内存的占用，4G=2^32大概是40亿*8大概是340 亿，n=50亿，如果按出错率0.01算需要的大概是650亿个bit。 四、堆 适用范围：海量数据前n大，并且n比较小，堆可以放入内存 基本原理及要点：最大堆求前n小，最小堆求前n大。 六、数据库索引 适用范围：大数据量的增删改查 基本原理及要点：利用数据的设计实现方法，对海量数据的增删改查进行处理。 当然在更新每条数据的出现次数的时候，我们可以利用一个堆来维护出现次数最多的前N个数据，当 然这样导致维护次数增加，不如完全统计后在求前N大效率高。 如果数据无法放入内存。
在海量的数据迁移中，如果某个表特别大，可以考虑对表中的分区进行切分，比如某个表有100g,还有100个分区，那么可以考虑针对这100个分区，那么可以考虑把这100个分区看成100个表进行并行抽取，如果某个分区数据比较多 目前生成了如下的数据报告，我们需要基于这个报告来对如下的表/分区进行切分。 REEMENT这个表不是分区表，所以在分区信息的地方填写了默认值'x',在数据加载的时候会进行过滤。 在数据加载的时候就可以先加载21号dump，然后22号dump,23号dump MEMO partition(P0_A1000_E3) 3 21..23 MEMO partition(P0_A1000
在之前的章节中分享过一些数据迁移中并行抽取的细节，比如一个表T 很大，有500G的数据，如果开启并行抽取，默认数据库中并行的最大值为64，那么生成的dump文件最50多为64个，每个dump文件就是7.8G ，还是不小，况且在做数据抽取的时候，资源被极大的消耗，如果资源消耗紧张，可能可用的并行资源还不到64个。 生产中500G的大表肯定是做了分区操作，而且分区数可能还比较多。我们就设定为100个吧。 分区表的数据基本都是分散在各个分区的，考虑数据的不均匀分布，那么每个分区的数据可能在5~10G吧。 参照这个思想，假设开启并行，比如200M为一个基准点来切分分区表，比如分区表的某个分区含有5G的数据，那么需要开启25个并行即可，文件就会被切分为200M的很多细粒度的dump文件。 11 SUBSCRIBER x 5 对于大表的分区
618年中促进程过半，天猫、京东商城、苏宁易购促销方式各有不同，都希望借助新品爆品吸引流量，配合大促期间的满减打折，提高转化率。 ? ? ? ? ? ? 来源：中国大数据
在前几篇中讨论过海量数据的并行加载，基本思路就是针对每一个物理表都会有一个对应的外部表，在做数据迁移的时候，如果表有上百G的时候，一个物理表对应一个外部表性能上会没有任何提升。 如果需要做数据插入的时候，对undo是极大的挑战，从某种程度上而言，性能应该要比datapump要差。这个时候可以考虑一个物理表对应多个外部表，比如一个表有100G。 可以考虑生成100个external dump 文件，然后加载生成100个外部表，每个dump文件对应一个外部表，这样做数据的插入的时候就相对容易控制了。 每一个外部表的数据加载到目标库之后，commit一次，就能及时的释放Undo资源，提高性能。
在近期的数据侠线上实验室中，大数据服务提供商“网聚宝”品牌数据部首席数据分析师宋剑豪为我们带来了一场“接地气”的零售数据典型分析方法分享。干货满满，本文为其分享实录。 ▍如何才能发挥电商零售数据的最大价值？ 最近几年，天猫双11的销售额翻了好几番。从零售数据的意义上看，这意味着什么呢？ 这代表着更多的线下数据被不断引到线上来，消费者的数据更多地被品牌方沉淀下来。 这些“小阶梯”实质上反映的是双11的大促。 通过生命周期分析，我们还可以比较精准地去找到某一些类目的用户的购买习惯，然后去针对他的购买习惯，对其做一些特定的影响和营销的活动。 我们经过分析后得出了结论：一是从2015年到2016年，随着市场的变化，用户对大促的趋向性明显增加。二是这家店铺平日拉新客的难度越来越高了。 第三，我们发现他们的新客维护也可能存在一些问题。 作者 | 宋剑豪 编辑 | 胡世龙 ： hushilong@dtcj.com 题图 | 视觉中国 ▍数据侠门派 本文数据侠宋剑豪，花名火狐，大数据服务提供商“网聚宝”公司品牌数据部首席数据分析师。
“ 在大数据时代面对海量的本地文件时，随着云存储的普及，越来越多的用户需要把海量数据从传统的本地存储迁移到新的分布式云基础设施上，这就需要快速高效安全的迁移方法。” 原文发布于微信公众号：腾讯云存储（关注有惊喜） 操作场景 对于拥有本地 IDC 的用户，对象存储 COS 在不同迁移类型上支持以下迁移方式，帮助用户将本地 IDC 的海量数据快速迁移至对象存储 COS。 下图展示的是使用线上迁移时预估的时间消耗，可以看出，若此次迁移周期超过10天或者迁移数据量超过50TB，我们建议您选择线下迁移，否则，请选择线上迁移。 用户可以考虑使用多台机器安装 COS Migration 并分别执行不同源数据的迁移任务。 二、云数据迁移CDM 线下迁移 迁移操作步骤： 1.前往云数据迁移 CDM 控制台提交申请。 3.收到设备后，按照迁移设备手册把数据拷贝至设备。 4.完成数据拷贝后，在控制台提交回寄申请并等待腾讯云把数据迁往对象存储 COS。 详情请参见云数据迁移 CDM产品文档。
随着存储数据信息量的飞速增长，越来越多的人开始关注存储数据的缩减方法。数据压缩、单实例存储和重复数据删除等都是经常使用的存储数据缩减技术。 重复数据删除往往是指消除冗余子文件。 不同于压缩，重复数据删除对于数据本身并没有改变，只是消除了相同的数据占用的存储容量。重复数据删除在减少存储、降低网络带宽方面有着显著的优势，并对扩展性有所帮助。 的重复检测机制来替代Netapp原有的重复检测环节，文中提到的基于重复检测的Hadoop工作流包含如下几个环节： 将数据指纹（Fingerprint）由存储控制器迁移到HDFS 生成数据指纹数据库，并在 HDFS上永久存储该数据库 使用MapReduce从数据指纹记录集中筛选出重复记录，并将去重复后的数据指纹表保存回存储控制器。 数据指纹是指存储系统中文件块经过计算后的哈希索引，通常来说数据指纹要比它代表的数据块体积小的多，这样就可以减少分布式检测时网络中的数据传输量。
云原生数据库 TDSQL-C（Cloud Native Database TDSQL-C）。TDSQL-C 是数据库产品中心自研的新一代高性能高可用的云原生数据库。
扫码关注腾讯云开发者
领取腾讯云代金券
云服务器
即时通信 IM
网站备案
对象存储
实时音视频
