精华内容
下载资源
问答
  • 同步的含义
    千次阅读
    2019-12-17 23:07:22

    这里的数据实时同步是指近乎实时的将数据从源端数据库同步到其它目的端数据库的一种方式,比如 MySQL 中的数据在发生变化时,系统能够尽可能实时的将这部分变化的数据同步到 HBase 中或其他目的端。与离线数据同步不同的是,数据实时同步面对的是随时都可能发生改变的数据,它除了需要保证数据能够正确到达目的端之外,还需要保证数据的正确性、时序性、可接受的延迟范围等情况,所以这篇博客主要用户记录数据实时同步过程中需要关注的一些关键点。

    在这里插入图片描述

    一、高效的数据同步模型

    所谓高效,即既要保证高吞吐量,也要保证低延迟,这样才能保证即使源端数据变化量过大,也能尽可能短时间、实时的将数据传输到目的端。

    而数据实时同步的最基本原理,就是将增量/变化数据从源端读出,然后再将数据写入目的端。在这中间则可以增加数据统计、转换、过滤、限流等功能,以此丰富数据同步的过程或适应更多的业务场景。那么我们应该如何保证这个过程的高效呢?

    就我目前的了解一些同步系统而言,数据同步模型几乎都参考或类似于阿里 DataX 的数据同步模型,我喜欢叫它流式 + 批次的数据同步模型以及多任务多通道的线程模型。

    1. 流式 + 批次的数据同步模型

    与传统的在单个线程中读取数据然后写入数据的流程不同,这里使用了流式计算的一些原理,数据的读取与写入分别位于两个独立的线程,它们通过管道(channel)传输数据。数据的读取方每读取到一个结果数据,都将其发送至管道,而数据的写入方每接收到一个新的结果数据,都会立即作出处理,这样做的一个好处在于,数据的写入方不必等待读取方的一次查询完成后才能开始处理数据,它可以在读取方读取数据的过程中,同时进行数据处理,尤其是数据读取可能需要经过多次网络传输时,这种方式能够更及时的处理数据。

    批次数据处理的目的在于减少数据写入时的网络传输,不管是将数据写入 HBase 还是 Kafka 或其它目的端,合并多条数据并统一发送,都是减少网络传输以提高吞吐量的一种有效方式,所以数据写入方在处理完成一条数据后,通常都需要根据情况等待后面的数据,再统一发送。

    2. 多任务多通道/单通道的线程模型

    多通道多任务的线程模型主要用于并发读取数据与写入数据,从而进一步提高系统的吞吐量,它的同步模型大致如下图所示:

    在这里插入图片描述
    上图是阿里 DataX 的系统架构设计,虽然它是离线数据同步,但是数据同步模型却是类似的。一个 Job 被拆分成多个 Task,每个 Task 则负责与之对应的数据的读取与写入,Reader 对应数据的读取,Writer 对应数据的写入,它们运行在相互独立的线程之中,通过 Channel 传输数据,每个 Reader、Writer、Channel 是一一对应的,所以我管它叫多通道多任务的数据同步模型。

    与多任务多通道类似的另外一种模型,也是我在系统中应用的一种模型,即多任务单通道数据模型,它的同步模型大致如下图所示:

    在这里插入图片描述

    Reader 与 Writer 之间没有一一对应,而是公用一个 Channel,这样做的目的在于,因为源端读取数据与目的端写入数据的速度不一致,通过合理的配置 Reader 与 Writer 的任务数量,能尽可能的减少数据库连接数。

    二、数据的一致性与时序性

    数据的一致性是系统最基本的保障,不容有失。保证数据的一致性主要有两种依赖方式,一种是依赖于数据同步系统本身,在保证数据不丢失的前提下,通过将数据有序的传递给目的端,从而保证数据最终会达成与源端一致;二是依赖于目的端数据库的特性来实现,比如在 HBase 中,数据可以依赖于时间戳来确定数据是否为最新的,所以只需要在同步的过程中,针对每次操作都有固定的时间戳与之对应,那么不管操作顺序如何,只要最后的操作有应用在 HBase 之上,那么获取的数据总会是最新的。

    上面提到的依赖于数据本身来保证数据的最终一致,应该是数据同步系统的一个最基本实现,因为我们不可能要求所有的目的端都能够像 HBase 那样,也不可能要求所有的数据都能传递一个固定的时间戳。那么这里就会涉及到一个操作顺序的问题,我们简单的将数据时序性分为两种类型:

    1. 数据全局有序,即不同行的数据的操作顺序必须与源端一致
    2. 数据以主键为单位的顺序一致,即仅保证单行数据的操作顺序必须与源端一致

    1. 数据全局有序

    数据全局有序是指数据的所有操作都按照先后顺序依次同步至目的端,即使不同数据行之间的操作顺序也必须一致。事实上,这样的业务场景相对比较罕见,如果真的需要满足这样的场景,那么通常的做法是将数据的读取与写入均设置为单任务即单线程模式,带来的影响是系统的吞吐量会相对变得低下。

    2. 数据以主键为单位的顺序一致

    数据以主键为单位的顺序一致是大多数业务场景需要的实现,同时它能使用多任务并发模式,有利于系统的吞吐量。而对于主键顺序一致,主要有两种情况:1) 数据可以回退,只需要保证数据的最终一致性;2) 数据不允许回退,只要更新为最新值后,便不能再更新回过去的值;

    针对于上述两种情况,主要发生在系统异常时。在系统正常的情况下,数据的操作顺序应该总是有序的被应用于目的端,而异常的情况,主要是因为 Job 作为一个长期运行的作业,难免会发生重试的情况,比如对于 OP_1 -> OP_2 操作,可能会由于重试而产生 OP_1 -> OP_2 -> OP_1 -> OP_2 这样反复的操作,这就给时序性带来了一种新的可能。下面以 MySQL 和 SQLServer 为源端的数据同步为例。

    • 在 MySQL 中,通常通过伪装从库并接收和解析 binlog 日志,来实现数据的监听和同步,此时拿到的是所有变更数据,它将直接被发送到目的端,所以当发生操作重发时,它的数据也会被重发,比如 OP_1(id=1, version=1) -> OP_2(id=1, version=2) 的两次操作,可能到目的端会变成 OP_1(id=1, version=1) -> OP_2(id=1, version=2) -> OP_1(id=1, version=1) -> OP_2(id=1, version=2) 的四次操作,其中 version 属性列会发生数据回退的现象;
    • 在 SQLServer 中,因为它闭源的原因,通常使用 trigger 或者 CT/CDC 的方式来监听数据变动,为了减少系统负载, trigger 或者 CT 表中通常只会记录表的主键信息,在监听到数据变动时,会根据主键信息再去源表中查询全部所需的信息,此时对于 OP_1(id=1, version=1) -> OP_2(id=1, version=2) 的两次操作,可能到目的端会变成 OP_1(id=1, version=1) -> OP_2(id=1, version=2) -> OP_1(id=1, version=2) -> OP_2(id=1, version=2) 的四次操作,尽管操作发生了改变,但是数据却未发生回退现象。这种现象在《SQLServer 数据异构实时同步之数据时序的问题》中也有讨论过“数据操作的重复发送与影响”,在此不再熬述。

    三、游标与断点续传

    引起数据重发的原因,一方面是由于系统运行中,由于网络等原因引起的,另一方面也可能是由于手动停止然后再启动而引起的。对于手动停止或者异常停止,都会牵扯到断点续传的功能;

    数据实时同步的过程是一个源源不断的将变化数据从源端流入目的端的过程,它可能会由于某种原因而中止同步,比如应用异常停止或者手动停止,不管如何,只要重启 Job,都得保证它能继续上一次停止的地方继续前进,而不是重头开始。

    保证系统能够断点续传,有两个必要条件:一是变更数据必须有一个类似于主键的用来标识其唯一性的值,以便于系统在重启后能够知道从哪里继续,这里管这个唯一的值为游标,二是系统必须能够持久化这个值,并且只能在数据被确认写入目的端后,才能保存这个值,否则可能发生数据丢失的风险。

    那么如何实现呢?这里简单介绍两种方式,一种是在数据写入时,同时保存游标值,但是需要注意的写入端为多任务时,游标的顺序问题,如果仅保存一份游标值,那么必须保证它的值是有序的更新;二是参考 Storm 的 ACK 机制 + Kafka 的定时提交 offset 机制,系统在监听到数据变化时,注册 ACK 元祖,在写入完成后,响应对应的元祖,并由固定的监听程序来更新游标值,游标值更新在内存中,通过定时刷新游标值来将其刷新到磁盘,这样做的好处是,刷新游标几乎不会影响到数据写入的时间,但是不好的是,在系统停止时,游标值可能会落后更多,而导致数据发生更多的重发。具体如何实现,需要根据业务特点来做判断。

    四、总结

    上述主要围绕如何构建高效的数据同步模型,以及数据同步的过程中,关于数据一致性、时序性以及断点续传的问题来讨论,真正实现的过程中,需要注意的细节远比这里讨论的更多,后面在慢慢总结总结吧。

    下面是了解到的几个开源的数据同步系统,如果能满足你的需求,就可以免得自己开发了:

    • DataX: 阿里开源的离线数据同步工具/平台;
    • DataLink: 神州租车的一个满足各种异构数据源之间的实时增量同步,分布式、可扩展的数据交换平台;
    • FlinkX: 袋鼠云内部广泛使用的基于flink的分布式离线数据同步框架;
    • Porter: 随行付内部广泛使用的数据同步工具/平台;
    • Bifrost: MySQL 同步到 Redis, MongoDB等服务的异构中间件;
    更多相关内容
  • 1、 掌握二极管平衡电路同步解调电路的组成与基本工作原理。 2、 熟悉二极管平衡电路同步解调电路的测试方法。 3、 熟知同步检波各个技术参数的含义
  • 集合的含义与表示同步练习
  • 集合的含义及表示同步练习.doc
  • 我们在编程的时候,有时会使用多线程来解决问题,比如你的程序需要在后台处理一大堆数据,但还要使用户界面处于可操作...它只能在变量一级做同步,volatile的含义就是告诉处理器, 不要将我放入工作内存, 请直接在主
  • 集合的含义与表示同步练习题.pdf
  • 算法的含义同步练习苏教版必修32精选.doc
  • 集合的含义与表示同步练习[精选].doc
  • ClickHouse副本同步及分布式DDL的原理

    千次阅读 2021-01-13 19:22:09
    基本上所有的分布式存储系统都有一个共同的特点,将...简单来说它们的副本同步机制是通过Zookeeper的监听机制实现的,当我们向Node1发送写入操作请求,Node1会推送操作日志到zookeeper集群中,Node2通过监听发现Nod.

    相信了解大数据的小伙伴们都知道,基本上所有的分布式存储系统都有一个共同的特点,将庞大的数据量分成多个小块存储在不同的机器上,通常称为分片,每个分片为了保证它数据不丢失,它们又有各自副本。ClickHouse也不例外,一起来看看ClickHouse是怎么实现的

    副本同步原理

    副本同步的原理其实我们在前面的篇幅中我们已经提到过,现在再用一张手画图复习一下
    在这里插入图片描述
    简单来说它们的副本同步机制是通过Zookeeper的监听机制实现的,当我们向Node1发送写入操作请求,Node1会推送操作日志到zookeeper集群中,Node2通过监听发现Node1有新的数据写入,于是从zookeeper上下载操作日志,然后从Node1下载副本到本地。下面我们就动手实验一下,看看具体现象。

    实操

    创建副本实例

    我们在server1下执行以下建表语句

    CREATE TABLE user_order
    (
        `id` UInt32,
        `uid` UInt32,
        `price` Float64,
        `create_time` DateTime
    )
    ENGINE = ReplicatedMergeTree('/clickhouse/tables/01/user_order', 'server1')
    PARTITION BY toYYYYMM(create_time)
    ORDER BY id
    

    在server2下执行以下建表语句

    CREATE TABLE user_order
    (
        `id` UInt32,
        `uid` UInt32,
        `price` Float64,
        `create_time` DateTime
    )
    ENGINE = ReplicatedMergeTree('/clickhouse/tables/01/user_order', 'server2')
    PARTITION BY toYYYYMM(create_time)
    ORDER BY id
    

    在这里插入图片描述
    解释一下上面执行的建表语句的含义,首先字段名和类型这里就不赘述了大家都懂,这里介绍以下我们上面使用的表引擎是ReplicatedMergeTree,该引擎会自动同步副本,MergeTree的话是ClickHouse的一大特色,它会将具有相同特征的数据进行合并,极大提高查询效率。使用该引擎需要传入两个参数,第一个参数是元数据在zookeeper的存在路径,第二个参数节点的名称。
    执行完建表语句后,我们向server1插入一条数据,看看server2是否会自动同步

    副本同步验证

    在server1节点上插入数据

    insert into table user_order values(2,101,3800,'2020-08-07 14:33:28');
    

    登录server2验证同步副本数据:
    在这里插入图片描述
    由图可见,server2已经正常同步了server1的数据。下面我们来看看具体同步的原理。

    副本同步原理

    当我们在server1执行插入语句,第一个副本实例会推送log日志到zookeeper指定目录下,我们可以到zk上查看具体的日志信息,使用我们上一章节提到的知识点,zk的内容可以直接在ClickHouse查询到

    select * from system.zookeeper where path='/clickhouse/tables/01/user_order/log';
    

    在这里插入图片描述
    可以清晰的看到,我们操作的事件,源副本所在的节点,以及数据所在的文件名,都能准确的呈现。
    那么此时server2就监听到了/clickhouse/tables/01/user_order/log该路径下发生变化,便会触发日志的拉取并更新/clickhouse/tables/01/user_order/replicas/server2/log_pointer该路径下指示的日志下标,可以看到这里日志的下标是2,因为我之前插入过一条数据了,所以更新为2
    在这里插入图片描述

    副本选择策略

    这里存在一个问题,当副本可以从多个不用节点下载时,会如何选择,这里ClickHouse有一个选择算法:
    (1)首先server2会从/clickhouse/tables/01/user_order/replicas获取所有副本节点
    (2)遍历所有副本后,选择其中一个。选择的策略是,选取log_pointer下标最大且/queue子节点数量最少的副本。log_pointer越大,说明该副本执行的日志最多,数据最完整;/queue子节点最少,说明该副本最空闲。

    在整个插入数据过程中,zookeeper不会进行任何实质性数据传输本着谁执行谁负责的原则,server1将数据写入本地分区之后,接着推送log日志,然后通知其他副本下载数据,其他副本接收到log日志后,会选择一个最合适的副本,实现点对点下载分区数据。server1接收到server2的调用请求后,server1会根据参数将本地分区202008_0_0_0发送给server2,server2写入本地磁盘

    存在问题

    其实我们上面使用的这种方式有点挫,因为我们是在每个节点上手动创建每个副本表,如果我有成百上千个节点,是绝对不可能使用这种方式的,下面就给大家介绍分布式DDL的实操

    分布式DDL实操

    我们之前在metrika.xml中定义的集群信息在这里就派上用场了。

    前置条件

    先来看看我们metrika.xml中的集群信息
    在这里插入图片描述
    我们定义了集群名为cluster_1shards_1replicas,其中一个分片下有两个副本,分别是server1和server2。
    以及宏变量
    server1的宏变量
    在这里插入图片描述
    server2的宏变量
    在这里插入图片描述

    执行分布式DDL语句

    有了以上前置条件之后,我们可以执行分布式DDL语句了

    CREATE TABLE my_order_local ON CLUSTER cluster_1shards_1replicas(id UInt32,uid UInt32,price Float64,create_time DateTime) engine = ReplicatedMergeTree('/clickhouse/tables/{shard}/my_order','{replica}') PARTITION BY toYYYYMM(create_time) ORDER BY id;
    

    在这里插入图片描述
    这样我们的分布式DDL操作的执行完成了

    原理

    推送DDL日志

    分布式DDL的原理其实和副本同步是类似的,**当我们在server1执行分布式DDL语句时,本着谁执行谁负责的原则,server1节点负责创建日志并将日志推送到zookeeper,同时也由serve1节点负责监控任务的执行进度。**推送的日志对应zookeeper的以下路径:
    在这里插入图片描述

    拉取日志并执行

    看一下操作日志中都有什么内容,zk路径

    get /clickhouse/task_queue/ddl/query-0000000001
    

    在这里插入图片描述
    可以看到这个日志中的信息包含版本号,执行的语句以及需要执行该语句的hosts列表。其它节点监听到此操作日志后,后判断自己是否在该hosts列表内,如果包含,则进入执行流程,执行完毕后写入
    /clickhouse/task_queue/ddl/query-0000000001/finished
    在这里插入图片描述
    从上图我们可以看见finished下存在server1和server2,说明它们都已经执行完成了。

    确认执行进度

    在第一步客户端执行DDL语句之后,客户端会阻塞等待180秒,以期望所有节点都执行DDL完毕。如果等待事件大于180秒,则会转入后台线程继续等待。

    这样我们的分布式表就创建成功了,是不是很简单。

    今天ClickHouse副本同步及分布式DDL的原理和实操就到这里啦,下一篇讲给大家介绍分片的原理以及实操

    微信公众号:喜讯Xicent

    image

    展开全文
  • 1、 掌握二极管平衡电路同步解调电路的组成与基本工作原理。 2、 熟悉二极管平衡电路同步解调电路的测试方法。 3、 熟知同步检波各个技术参数的含义
  • svn 同步图标含义 全 所有图标含义 svn 同步图标含义 全 所有图标含义
  • 进程同步实验报告

    2018-04-02 19:09:06
    (1)了解操作系统进程同步的基本概念和准则。 (2)理解信号量机制及P、V操作含义。 (3)了解经典进程同步问题,掌握信号量方法解决进程同步问题的方法。 包括实验目的,截图,心得体会,代码
  • 主要介绍了Java同步代码块和同步方法原理与应用,结合具体案例形式分析了使用java同步代码块和同步方法实现买票功能的相关原理与操作技巧,需要的朋友可以参考下
  • (数学试卷高一)1.1算法的含义同步练习(苏教版必修3).doc
  • 1、添加同步定时器方法 2、同步定时器界面解释 3、同步定时器使用场景举例

    一、添加同步定时器

    1、选中http取样器,右击添加

     2、同步定时器所放位置,需要对哪个请求进行同时并发则放在哪个取样器之下

    二、同步定时界面解释

    同步定时器作用:用来保证我们的取样器在同一时刻向服务器发起负载

    1、模拟用户组的数量:设置并发用户数,如果设为0,则代表线程组的线程数

    2、超时时间:设置并发用户数等待的时间

    举例:模拟用户组数据设置为10,超时时间设置为5S,运行登录脚本:

    用户1第一个到达后,同步定时器开始计时

    如果3S到了,10个用户均已到达,就一起释放执行后续的请求,意味着10个线程同一时间完成登录

    如果5S到了,只到达了7个用户,那么7个一起释放执行后续的请求,超过设置的最大等待时间5S后还没达到模拟用户组中设置的值,线程组将不再等待,释放已到达的线程

    【特殊情况】

    超时时间设置为0,表示到达用户数不能达到模拟用户组的数量,则无限等待

    线程数必须大于同步定时器的模拟用户组数量

    三、实战举例

    1、线程数设为5,循环次数设为20,添加监听器-用表格查看结果

    可看到同样的请求参数5个线程的请求时间Start Time差最多为毫秒级,目的已达到

     

    展开全文
  • 部分内部字段含义说明: 1、userid指OA人员用户ID值(唯一)与AD域用户英文缩写:Initials(也设置唯一)对应,可参考更改其他值作为依据。 2、AD域中userAccountControl为人员状态值(546为禁用,66080为启用)可...
  • 表格中"Source Offset To Cente"(灰色显示)部分表示数据源相对中间位置的偏移量,即如果数据延时可以调整,那么需要调整多大延时才可以让时钟位于数据中间,时序图中标出了这个偏移量的含义。在这个例子中都是负值...
  • 数学:1.1《集合的含义及其表示》同步练习二(苏教版必修1).docx
  • 【成才之路】高中数学 1-1集合的含义与表示同步检测 北师大版必修1.doc
  • 【成才之路】高中数学 1-1 集合的含义与表示同步练习 北师大版必修1.doc
  • 同步精品课堂2019_2020学年高中数学第1章集合与函数概念1.1.1集合的含义与表示第1课时集合的含义练习新人教A版必修12019121841
  • 如何针对不同的应用选择不同的产品,需要我们必须清楚数据库同步和数据库复制的具体含义。  无论概念如何定义,我们都必须清楚,这两种操作的基础是数据库中的数据,但是包含的数据内容却有所不同  数据库同步,...
  • 学高中数学人教A必修四同步辅导与检测平面向量数量积的物理背景及其含义PPT学习教案.pptx
  • 本篇文章是对减少mysql主从数据同步延迟的问题进行了详细的分析介绍,需要的朋友参考下
  • 高中地理第一章区域地理环境与人类活动第一节区域的基本含义区域结构同步练习湘教版必修320180827350
  • 西门子同步伺服电机1FT7电机系列pdf,西门子同步伺服电机1FT7电机系列:1FT7 高动态型电机中心高为 63 ~ 80,静扭矩为 17 ~ 61Nm,额定转速为 3000 ~ 4500 转/ 分。具有极低的质量转矩比和超高的动态性能。
  • ISE软件中为源同步

    2021-01-19 23:10:22
    表格中"Source Offset To Cente"(灰色显示)部分表示数据源相对中间位置的偏移量,即如果数据延时可以调整,那么需要调整多大延时才可以让时钟位于数据中间,时序图中标出了这个偏移量的含义。在这个例子中都是负值...
  • 2014届高中数学《1.1.1集合的含义与表示 1.1.2集合间的基本关系》同步测试题 新人教A版必修1
  • 四川省成都市高中数学第一章集合与函数第1课时集合的含义与表示同步练习新人教A版必修1

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 191,481
精华内容 76,592
关键字:

同步的含义