很荣幸能参与到华为鲲鹏众智计划的项目中，这次项目的经历让我收获很多。开源使能-分布式存储软件适配项目主要是完成开源分布式存储组件Lustre、FastDFS、MinIO和BeeGFS在鲲鹏平台的兼容性工作，对开源分布式存储组件在鲲鹏平台进行编译安装、基本功能用例和性能用例的测试，查找适配过程中可能出现的问题并对功能异常进行说明，同时自动化用例输出自动化测试脚本。       千里之行始于足下，项目最困难的往往是开始阶段，如何规划项目进度以及团队分工十分重要。最开始也最繁琐的Lustre文件系统适配几乎占据了项目的一半时间。网上很少有Lustre在ARM架构上适配的相关资料，Lustre又需要对系统内核上打补丁，这涉及了给内核源码打补丁以及内核源码编译的问题，而Lustre文件系统网络的配置也十分繁琐，这个过程遇到了很多问题，我们通过查询相关资料以及咨询相关领域的专家慢慢地解决了问题，并对问题进行了记录。在对实际分布式存储软件情况调研和进一步的实践验证中，我们与华为对接的专家讨论了项目具体要求版本等信息，使得合作的任务需求更加完善。一个分布式存储软件的适配需要团队分工完成，合理地对任务进行分配能够极大地提升团队效率，通过第一个分布式存储软件的适配，渐渐找到了团队配合的方式，最终使得项目顺利完成。        项目实践的过程也是学习的过程，通过文件系统的适配过程，我不仅了解了每个文件系统的优缺点以及适用的场景，也熟练掌握了每个文件系统具体的编译安装流程和参数配置。问题带来的不只有烦恼，还有收获。例如在对BeeGFS文件系统适配过程中，进行磁盘随机读写测试时会出现内核崩溃情况，检查发现是armv8.2的PAN和UAO特性限制了用户空间的访问，这让我进一步了解了armv8.2架构和Linux内核空间和用户空间的知识；由于性能用例测试需要多个客户端，而由于机器数量的限制，就考虑使用多个kvm虚拟机进行测试。实践和解决问题的过程让我拓宽了思路，开阔了眼界，为我今后的道路打下了基石。       从鲲鹏916到鲲鹏920芯片，华为逐步把鲲鹏系列推向市场，做大ARM生态。与X86相比，ARM架构虽然具有低功耗、IP授权等方面优势，但生态环境堪忧。而生态系统需要广大的开发者一起构建，华为的鲲鹏众智计划正是汇集学界和产业界的诸多力量，构建鲲鹏平台的基础软件生态、实现生态共建共享。我很荣幸能够参与到鲲鹏众智计划中来，为鲲鹏生态系统的完善作出微薄贡献，希望能够在不远的未来见证鲲鹏计算生态的繁荣发展。                                                                                                                  兰州大学-高性能计算系统与应用研究团队-张强强，指导老师：张洋老师，陈文波老师

>摘要：GaussDB(DWS)提供了两个集群级别的视图快速识别和查询锁等待和分布式死锁信息，可实现此类问题的秒级问题的定位和分析。本文分享自华为云社区《[GaussDB(DWS)运维 -- 一键式锁等待和分布式死锁检测](https://bbs.huaweicloud.com/blogs/331625?utm_source=csdn&utm_medium=bbs-ex&utm_campaign=ei&utm_content=content)》，作者：譡里个檔。 锁是GaussDB(DWS)实现并发管理的关键要素，GaussDB(DWS)锁类别有表级锁、分区级锁(和表级锁一致)、事务锁、咨询锁等，当前业务最常用的是表级锁、分区级锁(和表级锁一致)、事务锁。不同的SQL语句执行时需要申请并持有对应的锁，当这些锁资源存在互斥时，对应的业务SQL就会产生等待；这种等待会产生下面几种后果： 1. 持锁的一方释放锁(一般对应的动作为持锁的事物提交)，等待锁的一方申请到锁，然后继续执行 2. 持锁的一方事物长时间未提交，等待锁的一方因为锁等待超时导致作业报错 3. A实例上持锁事物和申请锁的事物在B实例上角色互换，产生分布式死锁(具体见下文介绍)。这种场景下需要首先达到锁等待超时的事物报错回滚时释放锁资源，然后另外一个事物申请到才能正常进行 从上述的描述可以看到，锁等待特别是分布式死锁对业务影响很大，轻则产生等待导致业务性能抖动和下降，甚至业务报错。GaussDB(DWS)提供了两个集群级别的视图快速识别和查询锁等待和分布式死锁信息，可实现此类问题的秒级定位和分析。 # 1）锁等待检测视图pgxc_lock_conflicts 【功能】查询当前库里面不同节点上的锁等待信息  【解析】执行如下查询结果 postgres=# SELECT * FROM pgxc_lock_conflicts ORDER BY nodename,dbname,locktype,nspname,relname,partname; locktype | nodename | dbname | nspname | relname | partname | page | tuple | transactionid | username | gxid | xactstart | queryid | query | pid | mode | granted -----------+----------+----------+---------+-----------------------+----------+------+-------+---------------+-----------+----------+-------------------------------+--------------------+----------------------------------------------------------+-----------------+---------------------+--------- partition | cn_5001 | postgres | public | table_partition_num_3 | p1 | | | | dfm | 24097147 | 2022-02-17 17:56:03.113194+08 | 104145741383084190 | alter table table_partition_num_3 truncate partition p1; | 140160505136896 | AccessExclusiveLock | f partition | cn_5001 | postgres | public | table_partition_num_3 | p1 | | | | dfm | 24102679 | 2022-02-17 18:41:36.580348+08 | 0 | alter table table_partition_num_3 truncate partition p1; | 140160568055552 | AccessExclusiveLock | t relation | cn_5002 | postgres | public | xxx | | | | | dfm | 24102679 | 2022-02-17 18:41:36.580348+08 | 175921860444402398 | truncate xxx; | 140418767369984 | AccessShareLock | f relation | cn_5002 | postgres | public | xxx | | | | | dfm | 24097147 | 2022-02-17 17:56:03.113194+08 | 0 | truncate xxx; | 140420489144064 | AccessExclusiveLock | t (4 rows) 如上的SQL显示 - 在节点cn_5001的postgres里面的表public.table_partition_num_3的分区p1上存在分区级别(partition)的锁冲突。在当前的锁冲突中线程140160568055552持有锁(mode = true)，锁级别是AccessExclusiveLock，执行语句为alter table table_partition_num_3 truncate partition p1。线程140160568055552在等待(mode = false)AccessExclusiveLock锁，等待锁的语句也是alter table table_partition_num_3 truncate partition p1。 - 在节点cn_5002的postgres里面的表http://public.xxx上存在表级别(relation)的锁冲突。线程140420489144064持有锁AccessExclusiveLock(mode = true)，线程140418767369984在等待(mode = false)AccessShareLock锁 # 2）分布式锁等待检测视图pgxc_deadlock 【功能】查询当前库里面不同节点上的分布式死锁信息  【解析】执行如下查询结果 postgres=# SELECT * FROM pgxc_deadlock ORDER BY nodename,dbname,locktype,nspname,relname,partname; locktype | nodename | dbname | nspname | relname | partname | page | tuple | transactionid | waitusername | waitgxid | waitxactstart | waitqueryid | waitquery | waitpid | waitmode | holdusername | holdgxid | holdxactstart | holdqueryid | holdquery | holdpid | holdmode ----------+----------+----------+---------+---------+----------+------+-------+---------------+--------------+----------+-------------------------------+--------------------+-----------------------------------------------------+-----------------+-----------------+--------------+----------+-------------------------------+-------------+--------------+-----------------+--------------------- relation | cn_5001 | postgres | public | t2 | | | | | j00565968 | 24112406 | 2022-02-17 20:01:57.421532+08 | 104145741383110084 | EXECUTE DIRECT ON(dn_6003_6004) 'SELECT * FROM t2'; | 140160505136896 | AccessShareLock | j00565968 | 24112465 | 2022-02-17 20:02:24.220656+08 | 0 | TRUNCATE t2; | 140160421234432 | AccessExclusiveLock relation | cn_5002 | postgres | public | t1 | | | | | j00565968 | 24112465 | 2022-02-17 20:02:24.220656+08 | 175921860444446866 | EXECUTE DIRECT ON(dn_6001_6002) 'SELECT * FROM t1'; | 140418784151296 | AccessShareLock | j00565968 | 24112406 | 2022-02-17 20:01:57.421532+08 | 0 | TRUNCATE t1; | 140421763163904 | AccessExclusiveLock (2 rows) 如上的SQL显示，在postgres库里面 - 节点cn_5001上 事务24112465通过线程140160421234432持有表public.t2的AccessExclusiveLock锁 事务24112406通过线程140160505136896在等待申请表public.t2的AccessShareLock锁 - 节点cn_5002上 事务24112465通过线程140418784151296在等待申请表public.t1的AccessShareLock锁 事物24112406通过线程140421763163904持有表public.t1的AccessExclusiveLock锁 如果我们把资源的持有情况按照持有到申请定义一个防线的话，可以形成如下表格  从上述可以看出，事务24112465在节点cn_5001持有表public.t2的AccessExclusiveLock锁，等待申请申请表public.t1的AccessShareLock锁；事务24112406在节点cn_5002上持有表public.t1的AccessExclusiveLock锁，等待申请申请表public.t2的AccessShareLock锁；事务24112406和事务24112465只有等待彼此提交才能申请到锁资源，让自己继续执行，这种在多个实例上的分布式等待关系形成了一个环状，我们称这种现象为分布式死锁。 # 3) 锁等待和分布式死锁的区别 对于分布式死锁，只能一个事务因为锁等待（参数lockwait_timeout）超时回滚的时候，另外一个事务才能进行下去；或者人工干预kill或者cancel其中一个事务，让另外一个事务进行下去。 对于没有分布式死锁的锁等待，这种一般不需要人工干涉，等待持锁事务正常执行完成之后另外一个事务就可以正常执行；但是如果事务持锁时间超过锁等待超时参数（参数lockwait_timeout），等待锁的事务会因为锁等待超时失败。

>摘要：一致性哈希是什么，使用场景，解决了什么问题？本文分享自华为云社区《[16 张图解 ｜ 一致性哈希算法](https://bbs.huaweicloud.com/blogs/333158?utm_source=csdn&utm_medium=bbs-ex&utm_campaign=other&utm_content=content)》，作者：小林coding。 ## 如何分配请求？ 大多数网站背后肯定不是只有一台服务器提供服务，因为单机的并发量和数据量都是有限的，所以都会用多台服务器构成集群来对外提供服务。 但是问题来了，现在有那么多个节点（后面统称服务器为节点，因为少一个字），要如何分配客户端的请求呢？  其实这个问题就是「负载均衡问题」。解决负载均衡问题的算法很多，不同的负载均衡算法，对应的就是不同的分配策略，适应的业务场景也不同。 最简单的方式，引入一个中间的负载均衡层，让它将外界的请求「轮流」的转发给内部的集群。比如集群有 3 个节点，外界请求有 3 个，那么每个节点都会处理 1 个请求，达到了分配请求的目的。  考虑到每个节点的硬件配置有所区别，我们可以引入权重值，将硬件配置更好的节点的权重值设高，然后根据各个节点的权重值，按照一定比重分配在不同的节点上，让硬件配置更好的节点承担更多的请求，这种算法叫做加权轮询。 加权轮询算法使用场景是建立在每个节点存储的数据都是相同的前提。所以，每次读数据的请求，访问任意一个节点都能得到结果。 但是，加权轮询算法是无法应对「分布式系统」的，因为分布式系统中，每个节点存储的数据是不同的。 当我们想提高系统的容量，就会将数据水平切分到不同的节点来存储，也就是将数据分布到了不同的节点。比如**一个分布式 KV（key-valu） 缓存系统，某个 key 应该到哪个或者哪些节点上获得，应该是确定的**，不是说任意访问一个节点都可以得到缓存结果的。 因此，我们要想一个能应对分布式系统的负载均衡算法。 ## 使用哈希算法有什么问题？ 有的同学可能很快就想到了：**哈希算法**。因为对同一个关键字进行哈希计算，每次计算都是相同的值，这样就可以将某个 key 确定到一个节点了，可以满足分布式系统的负载均衡需求。 哈希算法最简单的做法就是进行取模运算，比如分布式系统中有 3 个节点，基于 hash(key) % 3 公式对数据进行了映射。 如果客户端要获取指定 key 的数据，通过下面的公式可以定位节点： `hash(key) % 3` 如果经过上面这个公式计算后得到的值是 0，就说明该 key 需要去第一个节点获取。 但是有一个很致命的问题，**如果节点数量发生了变化，也就是在对系统做扩容或者缩容时，必须迁移改变了映射关系的数据**，否则会出现查询不到数据的问题。 举个例子，假设我们有一个由 A、B、C 三个节点组成分布式 KV 缓存系统，基于计算公式 hash(key) % 3 将数据进行了映射，每个节点存储了不同的数据：  现在有 3 个查询 key 的请求，分别查询 key-01，key-02，key-03 的数据，这三个 key 分别经过 hash() 函数计算后的值为 hash( key-01) = 6、hash( key-02) = 7、hash(key-03) = 8，然后再对这些值进行取模运算。 通过这样的哈希算法，每个 key 都可以定位到对应的节点。  当 3 个节点不能满足业务需求了，这时我们增加了一个节点，节点的数量从 3 变化为 4，意味取模哈希函数中基数的变化，这样会导致**大部分映射关系改变**，如下图：  比如，之前的 hash(key-01) % 3 = 0，就变成了 hash(key-01) % 4 = 2，查询 key-01 数据时，寻址到了节点 C，而 key-01 的数据是存储在节点 A 上的，不是在节点 C，所以会查询不到数据。 同样的道理，如果我们对分布式系统进行缩容，比如移除一个节点，也会因为取模哈希函数中基数的变化，可能出现查询不到数据的问题。 要解决这个问题的办法，就需要我们进行**迁移数据**，比如节点的数量从 3 变化为 4 时，要基于新的计算公式 hash(key) % 4 ，重新对数据和节点做映射。 假设总数据条数为 M，哈希算法在面对节点数量变化时，**最坏情况下所有数据都需要迁移，所以它的数据迁移规模是 O(M)**，这样数据的迁移成本太高了。 所以，我们应该要重新想一个新的算法，来避免分布式系统在扩容或者缩容时，发生过多的数据迁移。 ## 使用一致性哈希算法有什么问题？ 一致性哈希算法就很好地解决了分布式系统在扩容或者缩容时，发生过多的数据迁移的问题。 一致哈希算法也用了取模运算，但与哈希算法不同的是，哈希算法是对节点的数量进行取模运算，而**一致哈希算法是对 2^32 进行取模运算，是一个固定的值**。 我们可以把一致哈希算法是对 2^32 进行取模运算的结果值组织成一个圆环，就像钟表一样，钟表的圆可以理解成由 60 个点组成的圆，而此处我们把这个圆想象成由 2^32 个点组成的圆，这个圆环被称为**哈希环**，如下图：  一致性哈希要进行两步哈希： - 第一步：对存储节点进行哈希计算，也就是对存储节点做哈希映射，比如根据节点的 IP 地址进行哈希； - 第二步：当对数据进行存储或访问时，对数据进行哈希映射； 所以，**一致性哈希是指将「存储节点」和「数据」都映射到一个首尾相连的哈希环上**。 问题来了，对「数据」进行哈希映射得到一个结果要怎么找到存储该数据的节点呢？ 答案是，映射的结果值往**顺时针的方向的找到第一个节点**，就是存储该数据的节点。 举个例子，有 3 个节点经过哈希计算，映射到了如下图的位置：  接着，对要查询的 key-01 进行哈希计算，确定此 key-01 映射在哈希环的位置，然后从这个位置往顺时针的方向找到第一个节点，就是存储该 key-01 数据的节点。 比如，下图中的 key-01 映射的位置，往顺时针的方向找到第一个节点就是节点 A。  所以，当需要对指定 key 的值进行读写的时候，要通过下面 2 步进行寻址： - 首先，对 key 进行哈希计算，确定此 key 在环上的位置； - 然后，从这个位置沿着顺时针方向走，遇到的第一节点就是存储 key 的节点。 知道了一致哈希寻址的方式，我们来看看，如果增加一个节点或者减少一个节点会发生大量的数据迁移吗？ 假设节点数量从 3 增加到了 4，新的节点 D 经过哈希计算后映射到了下图中的位置：  你可以看到，key-01、key-03 都不受影响，只有 key-02 需要被迁移节点 D。 假设节点数量从 3 减少到了 2，比如将节点 A 移除：  你可以看到，key-02 和 key-03 不会受到影响，只有 key-01 需要被迁移节点 B。 因此，**在一致哈希算法中，如果增加或者移除一个节点，仅影响该节点在哈希环上顺时针相邻的后继节点，其它数据也不会受到影响**。 上面这些图中 3 个节点映射在哈希环还是比较分散的，所以看起来请求都会「均衡」到每个节点。 但是**一致性哈希算法并不保证节点能够在哈希环上分布均匀**，这样就会带来一个问题，会有大量的请求集中在一个节点上。 比如，下图中 3 个节点的映射位置都在哈希环的右半边：  这时候有一半以上的数据的寻址都会找节点 A，也就是访问请求主要集中的节点 A 上，这肯定不行的呀，说好的负载均衡呢，这种情况一点都不均衡。 另外，在这种节点分布不均匀的情况下，进行容灾与扩容时，哈希环上的相邻节点容易受到过大影响，容易发生雪崩式的连锁反应。 比如，上图中如果节点 A 被移除了，当节点 A 宕机后，根据一致性哈希算法的规则，其上数据应该全部迁移到相邻的节点 B 上，这样，节点 B 的数据量、访问量都会迅速增加很多倍，一旦新增的压力超过了节点 B 的处理能力上限，就会导致节点 B 崩溃，进而形成雪崩式的连锁反应。 所以，**一致性哈希算法虽然减少了数据迁移量，但是存在节点分布不均匀的问题**。 ## 如何通过虚拟节点提高均衡度？ 要想解决节点能在哈希环上分配不均匀的问题，就是要有大量的节点，节点数越多，哈希环上的节点分布的就越均匀。 但问题是，实际中我们没有那么多节点。所以这个时候我们就加入**虚拟节点**，也就是对一个真实节点做多个副本。 具体做法是，**不再将真实节点映射到哈希环上，而是将虚拟节点映射到哈希环上，并将虚拟节点映射到实际节点，所以这里有「两层」映射关系。** 比如对每个节点分别设置 3 个虚拟节点： - 对节点 A 加上编号来作为虚拟节点：A-01、A-02、A-03 - 对节点 B 加上编号来作为虚拟节点：B-01、B-02、B-03 - 对节点 C 加上编号来作为虚拟节点：C-01、C-02、C-03 引入虚拟节点后，原本哈希环上只有 3 个节点的情况，就会变成有 9 个虚拟节点映射到哈希环上，哈希环上的节点数量多了 3 倍。  你可以看到，**节点数量多了后，节点在哈希环上的分布就相对均匀了**。这时候，如果有访问请求寻址到「A-01」这个虚拟节点，接着再通过「A-01」虚拟节点找到真实节点 A，这样请求就能访问到真实节点 A 了。 上面为了方便你理解，每个真实节点仅包含 3 个虚拟节点，这样能起到的均衡效果其实很有限。而在实际的工程中，虚拟节点的数量会大很多，比如 Nginx 的一致性哈希算法，每个权重为 1 的真实节点就含有160 个虚拟节点。 另外，虚拟节点除了会提高节点的均衡度，还会提高系统的稳定性。**当节点变化时，会有不同的节点共同分担系统的变化，因此稳定性更高**。 比如，当某个节点被移除时，对应该节点的多个虚拟节点均会移除，而这些虚拟节点按顺时针方向的下一个虚拟节点，可能会对应不同的真实节点，即这些不同的真实节点共同分担了节点变化导致的压力。 而且，有了虚拟节点后，还可以为硬件配置更好的节点增加权重，比如对权重更高的节点增加更多的虚拟机节点即可。 因此，**带虚拟节点的一致性哈希方法不仅适合硬件配置不同的节点的场景，而且适合节点规模会发生变化的场景**。 ## 总结 不同的负载均衡算法适用的业务场景也不同的。 轮训这类的策略只能适用与每个节点的数据都是相同的场景，访问任意节点都能请求到数据。但是不适用分布式系统，因为分布式系统意味着数据水平切分到了不同的节点上，访问数据的时候，一定要寻址存储该数据的节点。 哈希算法虽然能建立数据和节点的映射关系，但是每次在节点数量发生变化的时候，最坏情况下所有数据都需要迁移，这样太麻烦了，所以不适用节点数量变化的场景。 为了减少迁移的数据量，就出现了一致性哈希算法。 一致性哈希是指将「存储节点」和「数据」都映射到一个首尾相连的哈希环上，如果增加或者移除一个节点，仅影响该节点在哈希环上顺时针相邻的后继节点，其它数据也不会受到影响。 但是一致性哈希算法不能够均匀的分布节点，会出现大量请求都集中在一个节点的情况，在这种情况下进行容灾与扩容时，容易出现雪崩的连锁反应。 为了解决一致性哈希算法不能够均匀的分布节点的问题，就需要引入虚拟节点，对一个真实节点做多个副本。不再将真实节点映射到哈希环上，而是将虚拟节点映射到哈希环上，并将虚拟节点映射到实际节点，所以这里有「两层」映射关系。 引入虚拟节点后，可以会提高节点的均衡度，还会提高系统的稳定性。所以，带虚拟节点的一致性哈希方法不仅适合硬件配置不同的节点的场景，而且适合节点规模会发生变化的场景。

分类内容主题URLBoostkitltp-full-20160510 编译测试参考https://bbs.huaweicloud.com/forum/thread-176468-1-1.html使用BenchmarkSQL v5.0 测试数据库mysql和mysql调优https://bbs.huaweicloud.com/forum/thread-178027-1-1.htmlvlc-3.0.16移植指南（Centos7.6）https://bbs.huaweicloud.com/forum/thread-178371-1-1.htmlDevkit鲲鹏调优助手-鲲鹏开发套件中的瑞士军刀https://bbs.huaweicloud.com/forum/thread-177197-1-1.htmlDFX【故障注入第一期】计算故障注入背景现状https://bbs.huaweicloud.com/forum/thread-178890-1-1.html【故障注入第二期】业界故障注入工具现状https://bbs.huaweicloud.com/forum/thread-178923-1-1.html【故障注入第三期】DemonCAT实现原则及故障注入流程https://bbs.huaweicloud.com/forum/thread-178929-1-1.html【故障注入第四期】DemonCAT组网和架构https://bbs.huaweicloud.com/forum/thread-178935-1-1.html【故障注入第五期】DemonCAT架构原理指导https://bbs.huaweicloud.com/forum/thread-178938-1-1.htmlHPC鲲鹏计算精度白皮书 1.0正式发布https://bbs.huaweicloud.com/forum/thread-176980-1-1.html基因数据分析软件迁移-Sambamba-0.7.0https://bbs.huaweicloud.com/forum/thread-178010-1-1.html基因数据分析软件迁移-Kobas3https://bbs.huaweicloud.com/forum/thread-178013-1-1.htmlopenEuleropenEuler21.09配置samba服务器完整版https://bbs.huaweicloud.com/forum/thread-178525-1-1.htmlLibreoffice 7.1.8.1（aarch64）编译指导 for openEuler 20.03 LTS SP1https://bbs.huaweicloud.com/forum/thread-178626-1-1.htmlLibreoffice 7.2.2.2（aarch64）编译指导 for openEuler 20.03 LTS SP1https://bbs.huaweicloud.com/forum/thread-178628-1-1.html数据库openGauss 助力邮储银行分布式新核心迈向智能运维时代https://bbs.huaweicloud.com/forum/thread-176897-1-1.htmlGBASE南大通用正式开始研发基于openGauss的分布式事务型数据库https://bbs.huaweicloud.com/forum/thread-177059-1-1.html2022年1月国产数据库排行榜：TiDB霸榜两年势头不减，openGauss与OceanBase分数大涨https://bbs.huaweicloud.com/forum/thread-177145-1-1.html红遍全球的云原生数据库，未来将走向何方？https://bbs.huaweicloud.com/forum/thread-177270-1-1.html2022年的5个主要的数据迁移趋势https://bbs.huaweicloud.com/forum/thread-177292-1-1.html数据库领域下的新跃迁：百家争鸣背后的数据碎片化格局https://bbs.huaweicloud.com/forum/thread-177463-1-1.html非结构化数据将在2022年继续影响数据管理https://bbs.huaweicloud.com/forum/thread-177593-1-1.html使用虚拟机在CentOS上安装部署openGauss数据库指导（上）https://bbs.huaweicloud.com/forum/thread-177622-1-1.html使用虚拟机在CentOS上安装部署openGauss数据库指导（下）https://bbs.huaweicloud.com/forum/thread-177661-1-1.html使用虚拟机在CentOS上安装部署数据库使用https://bbs.huaweicloud.com/forum/thread-177663-1-1.htmlNeo4j 针对2022图数据平台发展的十大预测https://bbs.huaweicloud.com/forum/thread-177859-1-1.html原生分布式数据库与分库分表中间件、云原生数据库有何区别https://bbs.huaweicloud.com/forum/thread-178099-1-1.html使用虚拟机在CentOS上安装部署openGauss数据库基本操作https://bbs.huaweicloud.com/forum/thread-178151-1-1.html10个大数据挑战以及应对方法https://bbs.huaweicloud.com/forum/thread-178206-1-1.html回顾与展望：开源、智能化、隐私安全等八大数据库发展趋势https://bbs.huaweicloud.com/forum/thread-178306-1-1.html将PostgreSQL插件移植到openGauss指导https://bbs.huaweicloud.com/forum/thread-178393-1-1.html国产分布式数据库在证券行业的应用及实践https://bbs.huaweicloud.com/forum/thread-178558-1-1.htmlopenGauss数据库开发调试工具指导https://bbs.huaweicloud.com/forum/thread-178560-1-1.html分布式数据中心面临的4大挑战https://bbs.huaweicloud.com/forum/thread-178595-1-1.html金融行业分布式数据库选型及实践经验https://bbs.huaweicloud.com/forum/thread-178658-1-1.htmlopenGauss助力中国移动获 “ICT优秀案例”https://bbs.huaweicloud.com/forum/thread-178841-1-1.html华为云苏光牛：未来分布式数据库凭事务+存储破局，HTAP是特性但非万能丨新创访谈https://bbs.huaweicloud.com/forum/thread-178987-1-1.htmlopenGauss数据库日志管理指导https://bbs.huaweicloud.com/forum/thread-179011-1-1.html编译器编译gcc 7.3.0报fatal error: sys/ustat.h: No such file错误解决方法https://bbs.huaweicloud.com/forum/thread-177311-1-1.htmllibreoffice执行make编译去除不能直接用root账号编译方法https://bbs.huaweicloud.com/forum/thread-177617-1-1.html编译libreoffice-7.2.2.2报messages.po文件missing问题解决方法https://bbs.huaweicloud.com/forum/thread-177730-1-1.htmllibreoffice执行make编译报error: size of array 'arg' is negative解决方法 https://bbs.huaweicloud.com/forum/thread-177731-1-1.htmllibreoffice执行make编译报error: cannot guess build type解决方法https://bbs.huaweicloud.com/forum/thread-177739-1-1.htmllibreoffice执行make编译报cannot use gawk builtin `namespace' 解决方法https://bbs.huaweicloud.com/forum/thread-177740-1-1.htmlSPECjvm2008生成结果报X11错误解决方案https://bbs.huaweicloud.com/forum/thread-177854-1-1.htmllibreoffice编译报sysconfigdata...does not exist in the tarball解决方法https://bbs.huaweicloud.com/forum/thread-178344-1-1.html透明大页测试学习总结https://bbs.huaweicloud.com/forum/thread-177848-1-1.html其他 叮咚！小萌新的2021总结https://bbs.huaweicloud.com/forum/thread-177078-1-1.htmlC 语言总复习 （1）https://bbs.huaweicloud.com/forum/thread-177737-1-1.html使用虚拟机在CentOS上安装部署Linux操作系统相关命令https://bbs.huaweicloud.com/forum/thread-177801-1-1.html往期【场景案例与技术干货汇总】：https://bbs.huaweicloud.com/forum/thread-170921-1-1.html

大家好！我是酷哥，数据库相关资讯，带您速览，欢迎大家阅读。 **本期整理如下：** ------------------------------------------------ **本期精选** ------------------------------------------------ - “东数西算”工程全面启动 - 国内首个事务型数据库性能测试工具正式开源 - 第二届全球数据压缩大赛完美收官，进一步逼近数据压缩极限 - SphereEx与京东科技-推进多行业数据库产业生态建设 - Oracle Autonomous 云数据库获MongoDB API支持 - 亚马逊云科技推出内存数据库 Amazon MemoryDB for Redis - 57亿元、Akamai 收购 IaaS 提供商 Linode - 工信部拟规定：对各类数据实施分级防护 - “热搜”中的分布式数据库 - 为什么2022年仍然存在数据孤岛 ------------------------------------------------ **资讯全文** ------------------------------------------------ - “东数西算”工程全面启动 **摘要：** 国家发改委2月17日消息，国家发改委、中央网信办、工业和信息化部、国家能源局近日联合印发通知，同意在京津冀、长三角、粤港澳大湾区、成渝、内蒙古、贵州、甘肃、宁夏等8地启动建设国家算力枢纽节点，并规划了10个国家数据中心集群。至此，全国一体化大数据中心体系完成总体布局设计，“东数西算”工程正式全面启动。 国家发改委高技术司相关负责人答记者问时表示，实施“东数西算”工程，推动数据中心合理布局、优化供需、绿色集约和互联互通，有利于提升国家整体算力水平，有利于促进绿色发展，有利于扩大有效投资，有利于推动区域协调发展。 **文章详情：** [https://bbs.huaweicloud.com/forum/thread-179908-1-1.html](https://bbs.huaweicloud.com/forum/thread-179908-1-1.html) - 国内首个事务型数据库性能测试工具正式开源 **摘要：** 2 月 17 日，由信通院主办的国内首款金融数据库性能测试工具开源发布会在线上召开。会上，定位于国家高端专业智库、产业创新发展平台的信通院宣布开源了该测试工具，并详细阐述了开源此工具的背景、初心、历程以及愿景。信通院云大所副所长魏凯表示，将该款测试工具开源出来，也是希望借助平台的力量推动我国数据库产业健康、可持续地发展。项目开源地址：https://gitee.com/caict-bigdata/databench-t 四年磨一剑，力求打造中国 TPC，从 2018 年年底开始，信通院联合了北京银行、建设银行一起来开发，并邀请了来自腾讯、华为、中兴等企业的多位专家来共同参与该款工具的总体设计和实现。此次发布的 Databench-T 工具，也是希望能从根本上推动我国 ICT 领域健康、快速发展，使工具能更快、更好地为相关方服务。 **文章详情：** [https://bbs.huaweicloud.com/forum/thread-179907-1-1.html](https://bbs.huaweicloud.com/forum/thread-179907-1-1.html) - 第二届全球数据压缩大赛完美收官，进一步逼近数据压缩极限 **摘要：** 2月16日，第二届全球数据压缩大赛（GDCC2021）颁奖仪式举行，此次比赛共设置5个方向13个类别，吸引了来自全球40多个国家的1万多名存储研究人员关注，200多名参赛者报名，提交了79种算法，22人获奖。所有获奖算法的性能都优于业界已知的同类型压缩算法。部分算法的压缩比超过业界基准算法30%以上，进一步接近数据压缩极限。 2020年华为联合莫斯科国立大学举办的首届全球数据压缩大赛受到全世界算法界的广泛关注。 **文章详情：** [https://tieba.baidu.com/p/7730728099](https://tieba.baidu.com/p/7730728099) - SphereEx与京东科技-推进多行业数据库产业生态建设 **摘要：** 2022 年 1 月 31 日，SphereEx 与京东科技签署战略合作协议。协议中指出，双方将在数据库领域达成深度协作，在数据库服务领域实现优势互补，探索在线交易、在线分析、弹性伸缩、同城多活、异地灾备等技术应用与落地，形成产品的联合解决方案。推进多行业数据库产业生态建设。 **文章详情：** [https://tieba.baidu.com/p/7729633815](https://tieba.baidu.com/p/7729633815) - Oracle Autonomous 云数据库获 MongoDB API支持 **摘要：** 甲骨文近期发布了Oracle Database API for MongoDB。MongoDB是一种流行的NoSQL文档数据库，通常用作启用应用程序的后端数据存储。 通过这个新API，甲骨文使其用户能够在Oracle Autonomous JSON数据库及其旗舰Oracle Autonomous数据库云服务上迁移和运行基于MongoDB的数据应用程序。 使用这个API，用户可以连接现有的基于MongoDB的应用程序，并在Oracle平台内运行数据，而无需实际运行MongoDB数据库。2021年10月，甲骨文首次发布Oracle Database API for MongoDB的技术预览版。 **文章详情：** https://tieba.baidu.com/p/7726658029 - 亚马逊云科技推出内存数据库 Amazon MemoryDB for Redis **摘要：** （全球TMT2022年2月14日讯）亚马逊云科技宣布通过与光环新网和西云数据的紧密合作，在中国区域（北京与宁夏）推出完全托管的、兼容Redis的内存数据库Amazon MemoryDB for Redis。 Amazon MemoryDB for Redis具有高可用性和高持久性，可为客户提供超高性能，尤其适用于需要亚毫秒级低延迟响应的关键业务应用。 **文章详情：** [https://tieba.baidu.com/p/7727599669](https://tieba.baidu.com/p/7727599669) - 57亿元、Akamai 收购 IaaS 提供商 Linode **摘要：** Akamai今天宣布同意斥资约9亿美元（57亿人民币）收购基础设施即服务（IaaS）平台提供商Linode。Akamai表示，收购AWS的这个竞争对手将帮助该公司将自己打造成“世界上最具特色的分布式计算平台”。 **文章详情：** [https://tieba.baidu.com/p/7729639009](https://tieba.baidu.com/p/7729639009) - 工信部拟规定：对各类数据实施分级防护 **摘要：** 2月10日，工信部网站发布再次公开征求对《工业和信息化领域数据安全管理办法(试行)》的意见，其中提到，工业和信息化领域数据处理者应当对数据处理活动负安全主体责任，对各类数据实行分级防护。 意见称，工信部组织制定工业和信息化领域数据分类分级、重要数据和核心数据识别认定、数据分级防护等标准规范，指导开展数据分类分级管理工作，制定行业重要数据和核心数据具体目录并实施动态管理。 **文章详情：** [https://tieba.baidu.com/p/7726673062](https://tieba.baidu.com/p/7726673062) - “热搜”中的分布式数据库 **摘要：** “一个数据库包打天下的时代已经结束了”四川省农村信用社联合社信息科技中心高级工程师桂俊鸿在采访中表示。事务型、联机型、NoSQL、文档型、列式存储、时序数据库、图数据库……在近年来这些数据库热词背后，是数据库技术及产品在面向不同业务场景逐渐细化分类，发挥长处，最终助力企业实现数字化目标。由于传统数据库在扩展性、容量等方面不能满足日益增长的数字化需求，架构层面从集中式向分布式转型的分布式数据库及相关产品备受关注。 **文章详情：** [https://tieba.baidu.com/p/7727904283](https://tieba.baidu.com/p/7727904283) - 为什么2022年仍然存在数据孤岛 **摘要：** 企业摆脱数据孤岛并不容易。人们需要了解什么是数据孤岛、为何难以消除数据孤岛以及如何克服这些挑战。 好消息是，如今可供企业使用的数据比以往任何时候都多。从客户注册在线帐户到向企业提供他们的详细信息，信息对于帮助企业做出关键业务决策非常宝贵。 但是，数据存储效率低下可能会给企业带来一些问题。数据孤岛不仅会让企业的团队感到沮丧，还会导致销售损失和决策不准确。 **文章详情：** [https://tieba.baidu.com/p/7726637694](https://tieba.baidu.com/p/7726637694) [上一期：【技术之声】第八期（20220214）一周精选](https://bbs.huaweicloud.com/forum/thread-179748-1-1.html) *声明：文章源于第三方公开的信息，如内容中涉嫌侵权或存在信息不实时，请及时联系删除。* |整理者：酷哥

锁是GaussDB(DWS)实现并发管理的关键要素，GaussDB(DWS)锁类别有表级锁、分区级锁(和表级锁一致)、事务锁、咨询锁等，当前业务最常用的是表级锁、分区级锁(和表级锁一致)、事务锁。不同的SQL语句执行时需要申请并持有对应的锁，当这些锁资源存在互斥时，对应的业务SQL就会产生等待；这种等待会产生下面几种后果持锁的一方释放锁(一般对应的动作为持锁的事物提交)，等待锁的一方申请到锁，然后继续执行持锁的一方事物长时间未提交，等待锁的一方因为锁等待超时导致作业报错A实例上持锁事物和申请锁的事物在B实例上角色互换，产生分布式死锁(具体见下文介绍)。这种场景下需要首先达到锁等待超时的事物报错回滚时释放锁资源，然后另外一个事物申请到才能正常进行从上述的描述可以看到，锁等待特别是分布式死锁对业务影响很大，轻则产生等待导致业务性能抖动和下降，甚至业务报错。GaussDB(DWS)提供了两个集群级别的视图快速识别和查询锁等待和分布式死锁信息，可实现此类问题的秒级问题的定位和分析1）锁等待检测视图pgxc_lock_conflicts【功能】查询当前库里面不同节点上的锁等待信息字段名称数据类型字段描述locktypetext被锁定对象的类型，当前支持relation、partition、transactionid三种类型的锁类型nodenamename被锁定对象的节点的名称dbnamename被锁定对象的数据库的名称。如果被锁定对象是事务，则为NULLnspnamename被锁定对象的命名空间的名称relnamename被锁定对象对应的relation的名称。如果被锁定对象既不是relation，也不是relation的一部分，则为NULLpartnamename被锁定对象对应的分区的名称。如果被锁定对象不是分区，则为NULLpageinteger被锁定对象对应的页面的编号。如果被锁定对象既不是页面，也不是元组，则为NULLtuplesmallint被锁定对象对应的元组的编号。如果被锁定对象不是元组，则为NULLtransactionidxid被锁定对象对应的事务的ID。如果被锁定对象不是事务，则为NULLusernamename当前线程所处session的用户名，一般也是当前线程执行语句的用户名称gxidxid当前线程所处事物的事物IDxactstarttimestamptz当前线程所处事务的事物开始时间queryidbigint申请锁的线程的最新查询的queryidquerytext申请锁的线程的最新查询语句pidbigint申请锁的线程的IDmodetext锁的级别grantedbooleanTRUE表示当前线程持有上述指定的锁FALSE表示当前线程正在申请锁，但是没有申请上，处在等待锁的状态【解析】执行如下查询结果postgres=# SELECT * FROM pgxc_lock_conflicts ORDER BY nodename,dbname,locktype,nspname,relname,partname; locktype | nodename | dbname | nspname | relname | partname | page | tuple | transactionid | username | gxid | xactstart | queryid | query | pid | mode | granted -----------+----------+----------+---------+-----------------------+----------+------+-------+---------------+-----------+----------+-------------------------------+--------------------+----------------------------------------------------------+-----------------+---------------------+--------- partition | cn_5001 | postgres | public | table_partition_num_3 | p1 | | | | dfm | 24097147 | 2022-02-17 17:56:03.113194+08 | 104145741383084190 | alter table table_partition_num_3 truncate partition p1; | 140160505136896 | AccessExclusiveLock | f partition | cn_5001 | postgres | public | table_partition_num_3 | p1 | | | | dfm | 24102679 | 2022-02-17 18:41:36.580348+08 | 0 | alter table table_partition_num_3 truncate partition p1; | 140160568055552 | AccessExclusiveLock | t relation | cn_5002 | postgres | public | xxx | | | | | dfm | 24102679 | 2022-02-17 18:41:36.580348+08 | 175921860444402398 | truncate xxx; | 140418767369984 | AccessShareLock | f relation | cn_5002 | postgres | public | xxx | | | | | dfm | 24097147 | 2022-02-17 17:56:03.113194+08 | 0 | truncate xxx; | 140420489144064 | AccessExclusiveLock | t (4 rows)如上的SQL显示在节点cn_5001的postgres里面的表public.table_partition_num_3的分区p1上存在分区级别(partition)的锁冲突。在当前的锁冲突中线程140160568055552持有锁(mode = true)，锁级别是AccessExclusiveLock，执行语句为alter table table_partition_num_3 truncate partition p1。线程140160568055552在等待(mode = false)AccessExclusiveLock锁，等待锁的语句也是alter table table_partition_num_3 truncate partition p1。在节点cn_5002的postgres里面的表public.xxx上存在表级别(relation)的锁冲突。线程140420489144064持有锁AccessExclusiveLock(mode = true)，线程140418767369984在等待(mode = false)AccessShareLock锁2）分布式锁等待检测视图pgxc_deadlock【功能】查询当前库里面不同节点上的分布式死锁信息字段名称数据类型字段描述locktypetext被锁定对象的类型，当前支持relation、partition、transactionid三种类型的锁类型nodenamename被锁定对象的节点的名称dbnamename被锁定对象的数据库的名称。如果被锁定对象是事务，则为NULLnspnamename被锁定对象的命名空间的名称relnamename被锁定对象对应的关系的名称。如果被锁定对象既不是关系，也不是关系的一部分，则为NULLpartnamename被锁定对象对应的分区的名称。如果被锁定对象不是分区，则为NULLpageinteger被锁定对象对应的页面的编号。如果被锁定对象既不是页面，也不是元组，则为NULLtuplesmallint被锁定对象对应的元组的编号。如果被锁定对象不是元组，则为NULLtransactionidxid被锁定对象对应的事务的ID。如果被锁定对象不是事务，则为NULLwaitusernamename等待锁的用户的名称waitgxidxid等待锁的事务的IDwaitxactstarttimestamptz等待锁的事务的开始时间waitqueryidbigint等待锁的线程的最新查询IDwaitquerytext等待锁的线程的最新查询语句waitpidbigint等待锁的线程的IDwaitmodetext等待的锁的级别holdusernamename持有锁的用户的名称holdgxidxid持有锁的事务的IDholdxactstarttimestamptz持有锁的事务的开始时间holdqueryidbigint持有锁的线程的最新查询IDholdquerytext持有锁的线程的最新查询语句holdpidbigint持有锁的线程的IDholdmodetext持有的锁的级别【解析】执行如下查询结果postgres=# SELECT * FROM pgxc_deadlock ORDER BY nodename,dbname,locktype,nspname,relname,partname; locktype | nodename | dbname | nspname | relname | partname | page | tuple | transactionid | waitusername | waitgxid | waitxactstart | waitqueryid | waitquery | waitpid | waitmode | holdusername | holdgxid | holdxactstart | holdqueryid | holdquery | holdpid | holdmode ----------+----------+----------+---------+---------+----------+------+-------+---------------+--------------+----------+-------------------------------+--------------------+-----------------------------------------------------+-----------------+-----------------+--------------+----------+-------------------------------+-------------+--------------+-----------------+--------------------- relation | cn_5001 | postgres | public | t2 | | | | | j00565968 | 24112406 | 2022-02-17 20:01:57.421532+08 | 104145741383110084 | EXECUTE DIRECT ON(dn_6003_6004) 'SELECT * FROM t2'; | 140160505136896 | AccessShareLock | j00565968 | 24112465 | 2022-02-17 20:02:24.220656+08 | 0 | TRUNCATE t2; | 140160421234432 | AccessExclusiveLock relation | cn_5002 | postgres | public | t1 | | | | | j00565968 | 24112465 | 2022-02-17 20:02:24.220656+08 | 175921860444446866 | EXECUTE DIRECT ON(dn_6001_6002) 'SELECT * FROM t1'; | 140418784151296 | AccessShareLock | j00565968 | 24112406 | 2022-02-17 20:01:57.421532+08 | 0 | TRUNCATE t1; | 140421763163904 | AccessExclusiveLock (2 rows)如上的SQL显示，在postgres库里面节点cn_5001上        事务24112465通过线程140160421234432持有表public.t2的AccessExclusiveLock锁        事务24112406通过线程140160505136896在等待申请表public.t2的AccessShareLock锁节点cn_5002上        事务24112465通过线程140418784151296在等待申请表public.t1的AccessShareLock锁        事物24112406通过线程140421763163904持有表public.t1的AccessExclusiveLock锁如果我们把资源的持有情况按照持有到申请定义一个防线的话，可以形成如下表格节点事务24112465方向事务24112406cn_5001持有表public.t2的AccessExclusiveLock锁→申请表public.t2的AccessShareLock锁cn_5002申请表public.t1的AccessShareLock锁←持有表public.t1的AccessExclusiveLock锁从上述可以看出，事务24112465在节点cn_5001持有表public.t2的AccessExclusiveLock锁，等待申请申请表public.t1的AccessShareLock锁；事务24112406在节点cn_5002上持有表public.t1的AccessExclusiveLock锁，等待申请申请表public.t2的AccessShareLock锁；事务24112406和事务24112465只有等待彼此提交才能申请到锁资源，让自己继续执行，这种在多个实例上的分布式等待关系形成了一个环状，我们称这种现象为分布式死锁。3) 锁等待和分布式死锁的区别对于分布式死锁，只能一个事务因为锁等待（参数lockwait_timeout）超时回滚的时候，另外一个事务才能进行下去；或者人工干预kill或者cancel其中一个事务，让另外一个事务进行下去。对于没有分布式死锁的锁等待，这种一般不需要人工干涉，等待持锁事务正常执行完成之后另外一个事务就可以正常执行；但是如果事务持锁时间超过锁等待超时参数（参数lockwait_timeout），等待锁的事务会因为锁等待超时失败。

锁是GaussDB(DWS)实现并发管理的关键要素，GaussDB(DWS)锁类别有表级锁、分区级锁(和表级锁一致)、事务锁、咨询锁等，当前业务最常用的是表级锁、分区级锁(和表级锁一致)、事务锁。不同的SQL语句执行时需要申请并持有对应的锁，当这些锁资源存在互斥时，对应的业务SQL就会产生等待；这种等待会产生下面几种后果持锁的一方释放锁(一般对应的动作为持锁的事物提交)，等待锁的一方申请到锁，然后继续执行持锁的一方事物长时间未提交，等待锁的一方因为锁等待超时导致作业报错A实例上持锁事物和申请锁的事物在B实例上角色互换，产生分布式死锁(具体见下文介绍)。这种场景下需要首先达到锁等待超时的事物报错回滚时释放锁资源，然后另外一个事物申请到才能正常进行从上述的描述可以看到，锁等待特别是分布式死锁对业务影响很大，轻则产生等待导致业务性能抖动和下降，甚至业务报错。GaussDB(DWS)提供了两个集群级别的视图快速识别和查询锁等待和分布式死锁信息，可实现此类问题的秒级问题的定位和分析1）锁等待检测视图pgxc_lock_conflicts【功能】查询当前库里面不同节点上的锁等待信息字段名称数据类型字段描述locktypetext被锁定对象的类型，当前支持relation、partition、transactionid三种类型的锁类型nodenamename被锁定对象的节点的名称dbnamename被锁定对象的数据库的名称。如果被锁定对象是事务，则为NULLnspnamename被锁定对象的命名空间的名称relnamename被锁定对象对应的relation的名称。如果被锁定对象既不是relation，也不是relation的一部分，则为NULLpartnamename被锁定对象对应的分区的名称。如果被锁定对象不是分区，则为NULLpageinteger被锁定对象对应的页面的编号。如果被锁定对象既不是页面，也不是元组，则为NULLtuplesmallint被锁定对象对应的元组的编号。如果被锁定对象不是元组，则为NULLtransactionidxid被锁定对象对应的事务的ID。如果被锁定对象不是事务，则为NULLusernamename当前线程所处session的用户名，一般也是当前线程执行语句的用户名称gxidxid当前线程所处事物的事物IDxactstarttimestamptz当前线程所处事务的事物开始时间queryidbigint申请锁的线程的最新查询的queryidquerytext申请锁的线程的最新查询语句pidbigint申请锁的线程的IDmodetext锁的级别grantedbooleanTRUE表示当前线程持有上述指定的锁FALSE表示当前线程正在申请锁，但是没有申请上，处在等待锁的状态【解析】执行如下查询结果postgres=# SELECT * FROM pgxc_lock_conflicts ORDER BY nodename,dbname,locktype,nspname,relname,partname; locktype | nodename | dbname | nspname | relname | partname | page | tuple | transactionid | username | gxid | xactstart | queryid | query | pid | mode | granted -----------+----------+----------+---------+-----------------------+----------+------+-------+---------------+-----------+----------+-------------------------------+--------------------+----------------------------------------------------------+-----------------+---------------------+--------- partition | cn_5001 | postgres | public | table_partition_num_3 | p1 | | | | dfm | 24097147 | 2022-02-17 17:56:03.113194+08 | 104145741383084190 | alter table table_partition_num_3 truncate partition p1; | 140160505136896 | AccessExclusiveLock | f partition | cn_5001 | postgres | public | table_partition_num_3 | p1 | | | | dfm | 24102679 | 2022-02-17 18:41:36.580348+08 | 0 | alter table table_partition_num_3 truncate partition p1; | 140160568055552 | AccessExclusiveLock | t relation | cn_5002 | postgres | public | xxx | | | | | dfm | 24102679 | 2022-02-17 18:41:36.580348+08 | 175921860444402398 | truncate xxx; | 140418767369984 | AccessShareLock | f relation | cn_5002 | postgres | public | xxx | | | | | dfm | 24097147 | 2022-02-17 17:56:03.113194+08 | 0 | truncate xxx; | 140420489144064 | AccessExclusiveLock | t (4 rows)如上的SQL显示在节点cn_5001的postgres里面的表public.table_partition_num_3的分区p1上存在分区级别(partition)的锁冲突。在当前的锁冲突中线程140160568055552持有锁(mode = true)，锁级别是AccessExclusiveLock，执行语句为alter table table_partition_num_3 truncate partition p1。线程140160568055552在等待(mode = false)AccessExclusiveLock锁，等待锁的语句也是alter table table_partition_num_3 truncate partition p1。在节点cn_5002的postgres里面的表public.xxx上存在表级别(relation)的锁冲突。线程140420489144064持有锁AccessExclusiveLock(mode = true)，线程140418767369984在等待(mode = false)AccessShareLock锁2）分布式锁等待检测视图pgxc_deadlock【功能】查询当前库里面不同节点上的分布式死锁信息字段名称数据类型字段描述locktypetext被锁定对象的类型，当前支持relation、partition、transactionid三种类型的锁类型nodenamename被锁定对象的节点的名称dbnamename被锁定对象的数据库的名称。如果被锁定对象是事务，则为NULLnspnamename被锁定对象的命名空间的名称relnamename被锁定对象对应的关系的名称。如果被锁定对象既不是关系，也不是关系的一部分，则为NULLpartnamename被锁定对象对应的分区的名称。如果被锁定对象不是分区，则为NULLpageinteger被锁定对象对应的页面的编号。如果被锁定对象既不是页面，也不是元组，则为NULLtuplesmallint被锁定对象对应的元组的编号。如果被锁定对象不是元组，则为NULLtransactionidxid被锁定对象对应的事务的ID。如果被锁定对象不是事务，则为NULLwaitusernamename等待锁的用户的名称waitgxidxid等待锁的事务的IDwaitxactstarttimestamptz等待锁的事务的开始时间waitqueryidbigint等待锁的线程的最新查询IDwaitquerytext等待锁的线程的最新查询语句waitpidbigint等待锁的线程的IDwaitmodetext等待的锁的级别holdusernamename持有锁的用户的名称holdgxidxid持有锁的事务的IDholdxactstarttimestamptz持有锁的事务的开始时间holdqueryidbigint持有锁的线程的最新查询IDholdquerytext持有锁的线程的最新查询语句holdpidbigint持有锁的线程的IDholdmodetext持有的锁的级别【解析】执行如下查询结果postgres=# SELECT * FROM pgxc_deadlock ORDER BY nodename,dbname,locktype,nspname,relname,partname; locktype | nodename | dbname | nspname | relname | partname | page | tuple | transactionid | waitusername | waitgxid | waitxactstart | waitqueryid | waitquery | waitpid | waitmode | holdusername | holdgxid | holdxactstart | holdqueryid | holdquery | holdpid | holdmode ----------+----------+----------+---------+---------+----------+------+-------+---------------+--------------+----------+-------------------------------+--------------------+-----------------------------------------------------+-----------------+-----------------+--------------+----------+-------------------------------+-------------+--------------+-----------------+--------------------- relation | cn_5001 | postgres | public | t2 | | | | | j00565968 | 24112406 | 2022-02-17 20:01:57.421532+08 | 104145741383110084 | EXECUTE DIRECT ON(dn_6003_6004) 'SELECT * FROM t2'; | 140160505136896 | AccessShareLock | j00565968 | 24112465 | 2022-02-17 20:02:24.220656+08 | 0 | TRUNCATE t2; | 140160421234432 | AccessExclusiveLock relation | cn_5002 | postgres | public | t1 | | | | | j00565968 | 24112465 | 2022-02-17 20:02:24.220656+08 | 175921860444446866 | EXECUTE DIRECT ON(dn_6001_6002) 'SELECT * FROM t1'; | 140418784151296 | AccessShareLock | j00565968 | 24112406 | 2022-02-17 20:01:57.421532+08 | 0 | TRUNCATE t1; | 140421763163904 | AccessExclusiveLock (2 rows)如上的SQL显示，在postgres库里面节点cn_5001上        事务24112465通过线程140160421234432持有表public.t2的AccessExclusiveLock锁        事务24112406通过线程140160505136896在等待申请表public.t2的AccessShareLock锁节点cn_5002上        事务24112465通过线程140418784151296在等待申请表public.t1的AccessShareLock锁        事物24112406通过线程140421763163904持有表public.t1的AccessExclusiveLock锁如果我们把资源的持有情况按照持有到申请定义一个防线的话，可以形成如下表格节点事务24112465方向事务24112406cn_5001持有表public.t2的AccessExclusiveLock锁→申请表public.t2的AccessShareLock锁cn_5002申请表public.t1的AccessShareLock锁←持有表public.t1的AccessExclusiveLock锁从上述可以看出，事务24112465在节点cn_5001持有表public.t2的AccessExclusiveLock锁，等待申请申请表public.t1的AccessShareLock锁；事务24112406在节点cn_5002上持有表public.t1的AccessExclusiveLock锁，等待申请申请表public.t2的AccessShareLock锁；事务24112406和事务24112465只有等待彼此提交才能申请到锁资源，让自己继续执行，这种在多个实例上的分布式等待关系形成了一个环状，我们称这种现象为分布式死锁。3) 锁等待和分布式死锁的区别对于分布式死锁，只能一个事务因为锁等待（参数lockwait_timeout）超时回滚的时候，另外一个事务才能进行下去；或者人工干预kill或者cancel其中一个事务，让另外一个事务进行下去。对于没有分布式死锁的锁等待，这种一般不需要人工干涉，等待持锁事务正常执行完成之后另外一个事务就可以正常执行；但是如果事务持锁时间超过锁等待超时参数（参数lockwait_timeout），等待锁的事务会因为锁等待超时失败。

大家好！我是酷哥，一周精选，带您速览，欢迎大家关注。 **本期整理如下：** ------------------------------------------------ **本期精选** ------------------------------------------------ - 中国信通院云原生数据湖首批评测正式启动 - 中山大学联合创邻科技Galaxybase破万亿数据挖掘世界纪录 - IDC FutureScape：2022年中国数据与内容技术十大预测 - 国产分布式数据库在证券行业的应用及实践 - 金融行业分布式数据库选型及实践经验 - openGauss助力中国移动获 “ICT优秀案例” - 未来分布式数据库凭事务+存储**，HTAP是特性但非万能丨新创访谈 ------------------------------------------------ **资讯全文** ------------------------------------------------ - 中国信通院云原生数据湖首批评测正式启动 **摘要：** 大数据技术的内涵伴随着传统信息技术和数据应用的发展不断演进，而大数据技术体系的核心始终是面向海量数据的存储、计算、处理等基础技术。支撑数据存储计算的软件系统起源于20世纪60年代的数据库；70年代出现的关系型数据库成为了沿用至今最常用的数据存储计算系统；80年代末，专门面向数据分析决策的数据仓库理论被提出，成为接下来很长一段时间内发掘数据价值的主要工具和手段。2000年前后，面向非结构化数据的NoSQL数据库兴起。2010年前后，对于大量异构数据源进行统一存储使用的需求催生了数据湖概念。同时随着云计算技术的深入应用，大数据技术完成了从私有化部署到云上部署再向云原生的转变。 中国信通院云计算与大数据研究所依托中国通信标准化协会大数据技术标准推进委员会（CCSA TC601），联合腾讯云、阿里云、华为、星环、百度、海康威视、亚信、中国移动云能力中心等企业的二十余位专家共同参与编制完成了《云原生数据湖技术要求与测试方法》，帮助大数据产品供应商及用户方评估云原生数据湖的技术能力和研发方向。 **文章详情：** [https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=178460](https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=178460) - 中山大学联合创邻科技Galaxybase破万亿数据挖掘世界纪录 **摘要：** 数字经济时代，数据成为关键生产要素。企业从海量数据中挖掘商业价值的需求越发迫切。但这些高维、异构、复杂关联的数据给传统大数据处理和关系型数据库产品带来了极大挑战。中山大学联合创邻科技 “Galaxybase”图数据库，完成了万亿规模交易数据智能挖掘性能测试，为图数据库赋能的智慧互联数字化未来开启了新**。“超级算力+创新存储技术”，推动大数据智能革命。 **文章详情：** [https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=178835](https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=178835) - IDC FutureScape：2022年中国数据与内容技术十大预测 **摘要：** IDC近日发布了《IDC FutureScape: 全球数据和内容技术2022年预测 – 中国启示》，报告提供了 IDC 对数据和内容技术的 2022 年十大预测，主要关注数据和内容为企业所创造的价值，代表未来几年对数据、内容及分析技术的部署和使用具有最大潜在影响的预期趋势。 本报告基于全球预测提供对中国市场的启示，预测内容的主题分别为：数据运维、实时流式数据、AI增强分析及知识网络、规范事物命名、决策平台、视频内容分析、数据共享、数据文化、智能文档处理和图数据库。 **文章详情：** [https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=178655](https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=178655) - 国产分布式数据库在证券行业的应用及实践 **摘要：** 近年来，证券行业线下服务转型线上化进程加速，包括营销获客的方式、AI单向智能开户、非现场业务的办理、在线直播、小程序、小视频等互联网方式的使用等，同时近年证券市场行情火爆，证券用户数量和并发量大幅提升，从而对支撑业务的IT系统及数据库提出了更高要求；伴随在证券公司进入全面创新发展阶段，证券业务品种也日渐增加、业务流程复杂度不断提高，现有非国产集中式数据库架构在满足新业务、新监管规定以及今后一段时期内部控制管理的高效率监控及管理的需求方面已逐渐困难。 但随着国产分布式数据库产品不断的更新优化和技术发展，可以为我们带来越来越多的可适配场景。国产分布式数据库可在证券行业产生越来越多的应用价值。 **文章详情：** [https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=178558](https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=178558) - 金融行业分布式数据库选型及实践经验 **摘要：** 随着企业数字化转型深化，数据在企业中扮演着愈发重要的作用。数据无论从存储规模、还是计算要求都有着较之以往更高的需求。 金融行业，作为数据应用的“高地”，这一点表现尤为突出。如何在新时期，满足对数据基础设施更高的要求，成为各金融机构首要面对的问题。分布式数据库，作为一种新的数据库架构，经过近十余年的高速发展，已逐步成熟，并开始在一些金融机构中投产使用。但这种新的架构，较之以往的传统架构有着诸多不同。本文尝试从建设背景、技术趋势、落地实践、典型产品等多角度，分析当前分布式数据库与金融行业背景想结合，如何实现更好的落地实践。 **文章详情：** [https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=178658](https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=178658) - openGauss助力中国移动获 “ICT优秀案例” **摘要：** 中国移动在线营销服务中心是中国移动连接亿万客户的桥梁，拥有全球最大的融合智能泛呼叫中心。依托数字化、云化、智能化的服务营销能力，实现热线与互联网融通，多媒体智能交互应用；构建起全国一体化线上运营能力，支持数万客服云上生产。已将数智化的营销服务能力产品化，赋能社会千行百业助力经济社会发展。作为线上渠道的生产运营者、在线服务的全网提供者、全网生态合作运营的支撑者、智能化营销服务能力的构建者，正积极推动中国移动营销服务体系改革开启新征程。 近日，中国移动在线营销服务中心联合华为共同申报的“中国移动在线营销服务中心全栈自主可控基础软件最佳实践”荣获了《人民邮电报》2021年“ICT优秀案例”“强基筑魂卓越创新标杆”称号。 **文章详情：** [https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=178841](https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=178841) - 未来分布式数据库凭事务+存储**，HTAP是特性但非万能丨新创访谈 **摘要：** 承载着业务快速发展与数据体量激增的重压，数据库在可用性、扩展性、兼容性、稳定性等核心能力上被投注了越来越多的诉求与期望，面对这些由时代赋予数据库厂商和企业用户的新命题，解法显然不止一种，但思路却终归一致——顺势而为，应变而变。由此，近年来，我们看到了分布式架构带来的降本增效、云原生技术带来的弹性便捷，还看到了国产数据库从外围到核心业务系统应用的渐入佳境。这些看得见的变化仅仅只是开端，那些还未企及的变革，我们或许能从华为云数据库服务总经理苏光牛的本次专访中得到启发。 专访过程中，苏光牛多次表现出对国产数据库核心技术、用户适配度的信心和肯定，但他同时也指出，展望未来发展，一款真正的企业级分布式数据库，必定要在分布式事务和分布式存储上取得更大的改进和突破，才能从根本上解决用户的核心需求。此外，在国产数据库后续的大浪淘沙中，生态建设及人才培养将是制胜关键，需要持之以恒的投入。 **文章详情：** [https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=178987](https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=178987) [上一期：【技术之声】第六期（20220124）一周精选](https://bbs.huaweicloud.com/forum/thread-178517-1-1.html) *声明：文章源于第三方公开的信息，如内容中涉嫌侵权或存在信息不实时，请及时联系删除。* |整理者：酷哥

文章目录多租户介绍计算资源：cpu管控计算资源：内存管控存储资源：磁盘空间正文一、什么是多租户？    所谓多租户：就是我们一套集群内，可以有多个用户使用，比如说云上，一个集群中有多个用户，大家都有自己的业务要运行，假如其中某个用户A运行了一些很吃资源的业务，一个人就把cpu、内存等资源用得淋漓尽致，那么其他人就只能看着了，自己的业务完全受阻，这时候，就需要多租户手段，去限制A用户所使用的资源，比如规定好让他最多使用1G的内存，最多使用30%的cpu，这样的话他的作业跑起来也不会影响到其他人，大家相安无事，好好工作。二、GaussDB for DWS多租户概述    GaussDB for DWS 用两层用户架构组织租户。一个父租户下有多个子租户，一个子租户只能属于一个父租户。我们通过给父租户分配资源配额，同时限定附属于该父租户的子租户的资源使用。其中，子租户也可以分配父租户分配到的资源。    主要涉及的资源有以下几种：    1）计算资源：CPU资源、内存资源。    2）存储资源：磁盘空间。    下面我们分别对各种资源的分隔方式进行一个技术分享。三、计算资源CPU资源管控   GaussDB for DWS的CPU管控机制，是基于linux自带机制:CGroup来实现的，CGroup是Linux内核提供的一种限制、记录、隔离进程组所使用的物理资源（如CPU、 Memory、I/O等）的机制。  我们以一种树的形式，组织各个分配了资源的租户，如下图所示：      图中是控制组的一个挂载树，从最上层开始，就分为了两部分，一部分是属于Gaussdb的资源，一部分是留给系统其他进程使用的资源，我们使用的资源如图所示，都是挂载到Gaussdb:gaussdba的，其中第一层又分为两个控制组，Backend用来预留资源给数据库常驻的各个工作线程，Class控制组的资源用来分配给各个用户进行作业执行。    我们每创建一个父租户，就会对应创建一个UserClass1-n挂载到Class控制组下，去从Class控制组分到对应配额的CPU资源。而我们创建的子租户，会从他们的父租户那里分配资源，当前我们支持两层的架构，父租户对应数据库中的组用户，子租户对应数据库中的业务用户。    总体来说可以这样表述：给父租户分配40%的CPU，此时子租户将父租户的40%当做100%来分配，比如子租户A设置配额为50%，那么实际上是相当于分配了整体CPU资源的40%*50%=20%。    2.内存资源管控     Gaussdb for DWS数据库当前的架构由最早的多进程架构，演变为多线程架构，因此单独一个数据库实例，比如一个coordinator或者datanode，都是作为一个进程运行，进程中会用多个线程去负责各种不同的工作，比如有的用来执行用户作业，有的用来处理后台的任务，各个cn与dn互相之间由一套独特的通信架构进行联络（基于TCP协议），由cn解析下发客户端发过来的作业，下推给dn去执行，结果再返回汇总到cn，完成各种业务。    DWS会直接在数据库进程启动的时候，就为其分配好内存，为实例分配的一整块内存中，会根据不同的需要，划分为各种不同的内存上下文，其中有一块内存，叫做dynamic_workload_memory，作为作业运行时可以使用的内存，总体大小也会在一开始被规定好，举个例子，整个进程分配到20G内存，可以给dynamic_workload_memory根据算法从中分配对应的内存，比如会分配20G中的15G用于作业执行。    而我们要说的多租户内存管控机制，就是从这15G的内存中，按照租户规定的百分比，对一个租户可以使用的资源进行限制。当给一个租户设置了一定额度的内存之后，数据库中会对他使用的内存进行一个记录，当他运行的作业所使用的内存要超过对应的内存的时候，就会不再执行，作业进入排队状态，等待资源释放之后再继续执行。四、存储资源    存储资源主要就是指磁盘空间上的管控，在实际使用的过程中，很容易出现由一条坏SQL一直执行，持续下盘，导致整个磁盘到达使用率100%的状态，后果非常严重，因此，DWS也为了避免出现这种状况，提供了磁盘管控的功能，在内核8.0版本中，一共提供了三种类型的磁盘空间管控：永久表空间管控、临时表空间管控、以及SQL执行时的算子罗盘使用的临时空间管控。日常使用过程中进行下盘的无非这三种场景，我们已经都可以对其进行磁盘额度限制，这个额度和用户绑定，我们在使用过程中，创建用户或者修改用户，都可以指定该用户可以使用的永久空间，临时表空间，算子落盘空间。使一个用户所使用的磁盘空间在可控制的范围内，一旦超过限制，该用户将不能再进行落盘的操作，并且如果是当前正在执行的语句导致的磁盘空间膨胀，数据库内核也会把他找到并且干掉。    具体内部机制可以这样描述：内核中会记录每个用户使用的空间大小，并且在用户进行落盘等使用到磁盘空间操作时也进行对应记录，直到用户所使用的空间达到限额时，内核就会做出对应的策略，不允许该用户再进行落盘。    此外，内核中还有一个保护机制，就是当某个dn实例使用率达到90%时，整个集群会进入只读状态，为防止磁盘达到100%后的未知后果，直接禁止所有的写入操作。五、后记    与此同时，对于用户所使用的资源，DWS也提供了监控功能，从页面上可以看到当前用户的资源使用情况，同样也可以在内核中查询视图：pg_total_user_resource_info进行查看。    希望通过本文可以加深读者对于DWS多租户功能的认识理解。

承载着业务快速发展与数据体量激增的重压，数据库在可用性、扩展性、兼容性、稳定性等核心能力上被投注了越来越多的诉求与期望，面对这些由时代赋予数据库厂商和企业用户的新命题，解法显然不止一种，但思路却终归一致——顺势而为，应变而变。由此，近年来，我们看到了分布式架构带来的降本增效、云原生技术带来的弹性便捷，还看到了国产数据库从外围到核心业务系统应用的渐入佳境。这些看得见的变化仅仅只是开端，那些还未企及的变革，我们或许能从华为云数据库服务总经理苏光牛的本次专访中得到启发。专访过程中，苏光牛多次表现出对国产数据库核心技术、用户适配度的信心和肯定，但他同时也指出，展望未来发展，一款真正的企业级分布式数据库，必定要在分布式事务和分布式存储上取得更大的改进和突破，才能从根本上解决用户的核心需求。此外，在国产数据库后续的大浪淘沙中，生态建设及人才培养将是制胜关键，需要持之以恒的投入。而对于企业用户如何应对海量数据挑战，进行数据库改造和国产化替代，苏光牛一语中的，指出大多数企业的担忧并不在于数据库本身，而在于“变化”，担忧作出变化后带来不可预测和不可控制的风险。他建议企业抛开传统思想，用辩证的思维综合衡量规模、成本、效率、安全、运维难度等问题，致力于将更多精力集中在应用和业务当中。以下内容整理自dbaplus社群联合发起人、新炬网络董事/副总经理程永新与华为云数据库服务总经理苏光牛的独家对话，希望能同时给到国产数据库厂商和企业用户更具体、更详实、更适用的数据库应用策略与发展建议。新 创 访 谈受访嘉宾：苏光牛，华为云数据库服务总经理，负责华为云数据库业务的战略制定与发展，负责华为云数据库服务产品与解决方案的研发、运营和运维等。在数据库领域、IT基础设施、虚拟化和底层软件具备丰富的开发经验和团队管理经验，长期负责华为公司IT基础设施的研究与开发、虚拟化、数据库等解决方案的交付。采访者：程永新，dbaplus社群联合发起人，新炬网络董事/副总经理，拥有超过20年IT行业管理经验，计算机本科、工商管理硕士及EMBA。何为真正面向未来的分布式数据库?——分布式事务+分布式存储齐头并进，HTAP是趋势但并非万能程永新：作为一种新兴技术产品，分布式数据库的成熟度还有待提升，很多人依然保持观望态度，尤其是应用于核心系统，对此您有什么建议？苏光牛：从技术角度以及企业发展来看，随着业务的快速发展和数据量的爆发式增长，传统数据库在容量、扩展性、可用性等方面都遇到了巨大的挑战，只有分布式才能解决这些问题，才能满足企业的核心需求。所以在技术层面，分布式数据库是大势所趋，是未来。从产品创新的角度来看，传统数据库以Oracle为代表，在集中式架构上已经做得非常成熟和完善，而基于企业客户当前的真实需求，分布式架构正是时代给予数据库产品的新命题。从商业落地的现状来看，业界要对分布式数据库有信心，要给分布式数据库更多机会。以华为云GaussDB为例，当前已经在1500+政企客户规模商用，其中包括对数据库产品综合能力要求最为严苛的金融行业，GaussDB已经在国有6大行中的4家商用，并且应用在其核心业务系统中。经历更多核心业务系统的打磨，产品能力也将进一步得以完善成熟。程永新：分布式数据库目前有多种技术路线在同步发展，不同人口中的“分布式数据库”可能代表不同的技术栈，主要被归纳为分布式中间件、分布式事务、分布式存储这三大类。您认为未来的趋势是这种多样化持续发展，还是会最终统一为一种形态？或者说怎么才是真正的分布式数据库架构？苏光牛：分布式中间件是介于上层应用和数据库之间的一层架构，或者说更贴近于应用层。实际上，分布式中间件会造成应用复杂度的提升，而通过底层数据库来实现分布式，应用开发者只需要关注数据库提供的API和开放能力，降低了应用的复杂度，企业可以将更多资源投入到应用以及业务本身。我们认为真正的分布式数据库应该是分布式事务与分布式存储的深度融合，这是分布式数据库的典型特征。首先，分布式事务最大的特点就是解决性能问题，分布式数据库要确保高可用必须在分布式事务上进行更多的改进；其次，分布式存储也要重点突破，要做到在存储上具备一定的计算能力，让存储去理解一定的数据结构。华为云GaussDB在分布式事务以及分布式存储层面做了大量优化和创新，在分布式事务层面提升性能和数据一致性；在存储层面充分利用存储的计算能力，创新性地推出了近存储数据处理（NDP, Near Data Processing），并结合并行处理（PQ, Parallel Processing），进一步提升了分布式数据库性能。程永新：不少企业在经历了数据库拆分后，随着对数据一致性和实时性要求的进一步提高，发现对数据库整合的需求越来越强烈，最终又想回到集中式架构的怀抱。您认为企业该如何避免盲目跟风为了拆而拆，重新审视数据库架构选型的合理性？苏光牛：相比较集中式数据库，分布式数据库的扩展性、可靠性、可用性以及灾备能力的增强，可以给企业的运维以及系统设计带来更大的弹性。但这不意味着一个分布式数据库就可以满足企业的所有诉求，而是要从业务、安全、容灾、性能以及运维角度出发，综合考量，选择适合自身业务和应用场景的数据库，设计合适的数据库架构，不能为了拆而拆。程永新：说到合还是分这个话题，不得不提到近年来许多国内外数据库厂商都在聚焦的HTAP，您如何看待这种可同时支持OLTP和OLAP的混合负载能力？会是未来数据库主流发展方向吗？苏光牛：HTAP是未来数据库发展的一个方向，一个数据库同时满足企业对OLTP和OLAP的诉求，保证了查询和分析结果的实时性，更好地支持业务决策的实时性和敏捷性，但是需要注意以下三点：分布式数据库是实现HTAP的最佳方案；HTAP有一定的适用范围，是在TP的基础上增强了其AP能力，支持对查询分析有时效性诉求的业务场景。另外，一个数据库不可能存储企业所有的数据；从企业的业务角度出发，复杂决策需要汇聚不同来源、不同类型的数据在一个集中点，需要通过专业的数据仓库、数据湖或者湖仓一体的方案来构建专业的数据分析系统。数据库迁移的风险防控与选型建议 ——兼容Oracle是个移动靶，还容易把自身产品做成“四不像”程永新：更换数据库存在不少挑战，一是新产品、新架构带来的风险，二是迁移改造中的不确定性，三是产品本身在稳定性上潜在的问题。应对这些情况，有没有较为稳妥的迁移方式？苏光牛：数据库是底层软件，上面是应用和中间件，下面是操作系统和硬件，所以数据库尤其是异构数据库的替换是一个非常复杂的系统性工程，在替换过程中会遇到各种各样的问题，这些问题的解决不是靠某个工具或某个人就能搞定的，比较稳妥的方式是把整个迁移过程细化、分解，针对每个阶段都制定详细的方案并做好验证，能工具化的一定要工具化，因为工具出错的概率比人要低很多，不能工具化的一定要找对应的专家来解决，过程中做好风险管理，及时闭环。为了帮助客户迁移，我们提供了多种工具，比如：数据库迁移工具UGO，实现异构数据库对象和应用迁移，语法的转化率达到90%以上；提供14类核心对象的采集，是当前业界最全的对象采集工具；数据在线迁移工具DRS，能帮助客户实现数据的在线迁移、数据校验；流量回放工具，可实现对源端业务流量抓取，然后在目标端进行回放能力，确保迁移后业务的稳定性和性能。程永新：在不少“去O”项目中，为了尽量减少迁移工作，会选择兼容Oracle语法、甚至存储过程的产品。此类产品确实减少了迁移工作量，但从长远角度来看会是一个很好的选择吗？苏光牛：的确，现在有很多数据库厂商为了减少迁移工作量，主动或被动选择了兼容Oracle这个策略，但显然这不是最好的选择。首先，兼容Oracle是一个移动靶，永远不可能做到100%兼容，因为Oracle本身也在演进；其次，做Oracle兼容很容易把自己的产品做成一个“四不像”，今天兼容Oracle，明天就有可能兼容DB2或SQL Server，这么做反而会牺牲掉自身产品原生设计的优势；另外，Oracle兼容也可能存在法律风险，尤其是兼容Oracle特有的语法，要慎重。程永新：站在用户的角度看，目前各分布式数据库厂商在产品技术实现上存在较大差异，并且没有通用的使用标准，您有什么选型建议？苏光牛：我认为在产品选型时应该考虑以下几个方面：厂商层面：产品是否是长期战略投入以及具备规模商用能力，是否有完整的产业生态、未来人才储备，确保厂商有能力长期服务客户并保证市场人才供给；技术层面：产品的成熟度如何，是否经过核心商业系统对高可靠性、高可用性、安全性的打磨和考验，是否有规模应用案例；外围工具：是否提供数据迁移、容灾备份，以及完善的管理监控工具来帮助客户更好地使用和管理数据库；生态开放：数据库能力开放，客户不被封闭生态所绑定。云化及国产化的势在必行——拥抱云架构，借助国产数据库优势，应变而变才能乘势而上程永新：数据库上云是大势所趋，但鉴于中国国情等特殊原因，金融、电信、政务等行业的数据不可能完全搬到公有云上，混合云将成为中国企业用云的主流模式。然而由于不同的云资源壁垒难以打通，各业务系统架构也缺乏规模效应，会使混合云运维与运营更加复杂，稳定性、数据一致性等问题得不到保障，可有较好的解决方法？苏光牛：数据库上云已经是业界共识，即使客户因为特殊原因无法将业务部署到公有云，最终也会采用混合云或者云化架构。如今，我们面临的是愈加庞大的IT系统场景，如果企业没能及时转变到云架构的设计思路，依然用传统思维去建设和应对大规模复杂IT系统，当遇到机器故障时就很容易酿成事故。混合云或云架构的弹性和易用性给企业运维带来的好处是显而易见的，但既然选择这种特殊方式，就免不了要接受一定的运维成本，但相对于企业自行搭建一套负载均衡等平台，无论是从人员成本、运维成本还是使用难度来说，整体下来其实都比用公有云要高。为了满足不同的客户诉求，华为云数据库以公有云和华为云Stack形式提供服务，客户可以选择适合业务模式的部署形式；而且云上云下版本、技术栈、API保持一致，客户可以在合适的时间在混合云和公有云之间迁移。程永新：圈子里不乏这样一些声音，说目前市面上不少国产数据库都是由MySQL和PostgreSQL魔改而来的，倒不如直接用MySQL或PostgreSQL。对此您有什么看法？苏光牛：这是一个产品应用场景的问题，开源数据库产品和自研产品针对的应用场景和客户诉求是不同的。直接使用开源数据库产品，要求企业自身具备一定的人才储备和技术能力，熟悉产品的使用场景和技术细节，可以在产品出现问题而社区没有修复的情况下，有能力解决问题。开源数据库对于初创期的数据库厂商来说，的确是一个很好的范本和参考对象，但要作为一款企业级数据库推出市面，真正满足企业实际需求，其实需要做很多非功能性的属性，包括性能、可安装、可用性、易用性、安全性等，这些非功能性需求对数据库来说占比非常高，但开源产品是不具备的。在华为云上，我们提供了不同的数据库服务来满足不同应用场景的客户诉求：华为云RDS for MySQL、RDS for PostgreSQL、DDS文档数据库服务（文档类型Mongo），基于开源打造的数据库服务，主要面向数据规模较小、对性能要求不高的业务场景，提供极致性价比的解决方案。华为GaussDB系列，立足创新与自研，一方面拥抱并兼容MySQL等生态，另一方面打造开放的openGauss生态，主要面向政企客户，满足对高性能、高可靠、高安全以及服务能力等方面的诉求。 程永新：如今，数据库国产化替代已不再停留于能不能的问题，而是对谁能交付得更快、投入成本更少、安全性更高的考量。您认为目前国产数据库与Oracle为代表的国外商用数据库还存在哪些差距？接下来国产数据库该如何在技术、生态等层面消除用户的后顾之忧？苏光牛：首先，以Oracle为代表的传统数据库产品，经过多年发展和积累，产品能力完善，生态成熟。与之相比，目前国产数据库在特性上仍然存在不少差距，但在实际的企业使用中，已经足够满足包括接口上、数据迁移上、应用改造上等大多数需求。而且随着业务的增长，企业对数据库的可用性、可靠性、性能以及扩展性提出了新的要求，传统数据库已经无法满足，而云原生、分布式，则更适合企业当下及未来对数据库的诉求，这也是以GaussDB为代表的国产数据库的优势所在。在技术层面，其实国产数据库的性能已不是问题，当然也不能盲目追求性能数字，很多特殊的优化手段在实际应用中根本无法使用，多数企业更多的担忧其实在于变化，担心变化后带来不可预测和不可控制的风险。所以正如我前面所说，业界要给国产数据库更多信心和机会，只有经历过核心系统的不断打磨，才能促进产品技术能力的进一步成熟。在生态层面，以GaussDB为例，我们通过产学研用全面结合，为业界培养未来数据库人才，同时为开发者提供全方位的资源支持，上线GaussDB从初级到专家的培训认证，以及与合作伙伴联合开发解决方案，从全产业链打造生态，确保为用户提供可靠的、持续的服务和支持。以开源打造数据库根技术——开源需要持之以恒的投入，国产数据库亟需人才的培养程永新：开源是近年数据库领域非常火的一个词，2020年华为就开源了openGauss，对于这种投入巨大且短期内较难收益的举措，你们是出于怎样的考量要和开发者、伙伴一起共建openGauss开源社区？苏光牛：华为一直积极参与开源社区，是多个全球顶级开源项目的重要成员，在开源领域贡献排名国内公司第一。说到数据库，华为在2001年就开始做数据库，当时是为了满足运营商业务需求，做的是一个内存数据库。从2011年开始战略投入，荟聚全球7大研究所、1000多名数据库专业人才，结合华为软硬全栈协同方面的优势，先满足华为自身极度复杂业务场景的需求。在当前的大环境下，中国需要发展自己的数据库根技术。基于华为多年参与、支持开源社区的积累，我们将GaussDB单机主备能力开源，与合作伙伴、客户、开发者共建、共享、共治openGauss开源社区，共同促进国内数据库行业的快速发展，打造数据库根技术。程永新：在开源至今一年多的时间里，开源给你们带来了什么？苏光牛：数据库是一个生态型的产品，只有把生态做起来，才能形成共赢的局面。从2020年6月开源到现在，openGauss社区吸引了2500多开发者、30000多用户、20个兴趣小组、6个城市用户组，12家合作伙伴基于openGauss发布了自有品牌数据库，100家头部企业加入社区，我们看到了一个蓬勃发展、越来越活跃的openGauss开源社区。程永新：您如何看待国产数据库相继开源的热潮及未来发展？苏光牛：开源将会促进国产数据库的快速发展，对整个数据库行业以及数据库从业者都是有利的。但是开源需要真正的开源，不是简单的开放代码，而是需要长期的、大量的人员和资源投入，与业界共建社区、不断改进产品。长远来看，只有像华为这样将开源当作业务来做的才得以促进开源的持续发展，获得生态的成功。纵观当下国产数据库百花齐发的态势，未来要想真正将数据库产品做大做强，我认为核心在于人才。因为数据库是一个对工程化要求特别高的东西，对代码精细化程度有非常高的标准，如何把成熟的理论在代码层面实现出来，既满足高可用，又满足高性能，还要满足数据一致性等基本要求，并不是一件简单的事情。所以国产数据库想保持向上的势头，未来发展必须注重数据库内核人才的引入和培养。

>摘要：Apache Flink是为分布式、高性能的流处理应用程序打造的开源流处理框架。本文分享自华为云社区《[【云驻共创】手把手教你玩转Flink流批一体分布式实时处理引擎](https://bbs.huaweicloud.com/blogs/317816?utm_source=csdn&utm_medium=bbs-ex&utm_campaign=other&utm_content=content)》，作者： 萌兔之约。 Apache Flink是为分布式、高性能的流处理应用程序打造的开源流处理框架。Flink不仅能提供同时支持高吞吐和exactly-once语义的实时计算，还能提供批量数据处理。相较于市面上的其他数据处理引擎，它采用的是基于流计算来模拟批处理。 # 一、Flink原理及架构 ## Flink简介 Apache Flink是为分布式、高性能的流处理应用程序打造的开源流处理框架。Flink不仅能提供同时支持高吞吐和exactly-once语义的实时计算，还能提供批量数据处理。主要由Java代码实现，支持实时流处理和批处理，批数据只是流数据的一个极限案例。支持了迭代计算，内存管理和程序优化。  相较于市面上的其他数据处理引擎，Flink和Spark都可以同时支持流处理和批处理。但是,Spark的技术理念是基于批处理来模拟流的计算;而Flink则完全相反，它采用的是基于流计算来模拟批处理。 ## Flink关键机制  四个机制:状态、时间、检查点、窗口 Flink中有四种最重要的关键机制，这些关键机制在后面我们也会来进行详细的介绍，这里我们主要介绍它的基本概念以及主要用途。首先Flink中最重要的一个机制是状态机制(State)，Flink是一种有状态的流计算引擎。状态的作用主要是我们Flink是一种流计算，它需要存储节点的中间计算结果。另外状态的保存还有利于Flink进行容错恢复。状态有密切关系的是Flink的Checkpoint，也就是检查点的机制，Checkpoint能够去把Flink的状态进行存储，相当于是做一次快照，方便Flink进行容错恢复。另外因为Flink它是一种流计算引擎，它的数据是不间断产生的，是没有界限的，因此我们需要有一种机制能够对数据进行切分，我们会采用的时间(Time)作为切分点，另外Flink进行容错性的恢复，它也需要知道从哪个时间点来进行恢复。所以说时间也是Flink中一种很重要的机制。最后是窗口window，在Flink中需要使用的窗口对数据进行切分，也方便对数据进行聚合计算。 ## Flink核心理念 Flink与其他流计算引擎的最大区别，就是状态管理。 Flink提供了内置的状态管理，可以把工作时状态存储在Flink内部，而不需要把它存储在外部系统。这样做的好处: - 降低了计算引擎对外部系统的依赖，使得部署、运维更加简单; - 对性能带来了极大的提升。 ## Flink Runtime整体架构  Flink运行时架构从下至上可以分为了三层，在最下层是Flink的一些配置方式，Flink可以采用单机的方式安装，也可以采用的集群的方式安装，另外也可以采用云的方式部署。在大多数情况下，Flink都是采用的集群的方式进行配置和安装的。其中呢它支持了两种集群模式，一种是Standalon，这种方式是采用了Flink自身提供的资源调度管理器。另外一种方式是基于YARN的方式进行了配置安装。 YARN提供了专用的资源管理器。在中间层次是Flink的计算引擎，这个计算引擎它同时能够支持流处理和批处理，可以接收了上层的api提交给它做作业 。Runtime这个引擎上面可以分为了两个模块，一个模块是DataStream api，一个是DataSet api。Flink向dataset和datastream，也就是批数据集以及流数据集是分开处理的，但是都是公用下面的计算引擎。基于两种类型的api，Flink又提供了更多的上层的抽象的api，API越抽象，它的表达能力越弱，但是它对数据的处理能力、抽象性也越强。在针对于上层Table api和SQL，它是主要是针对关系运算的，那针对关系数据的查询，Flink提供了统一的接口，基于流数据api，同时提供了复杂事件处理api。复杂事件指的就是说对不能够用时间去表示事件的开始、次序以及结束这样的事件进行处理的api接口。另外针对于数据及api，它提供了机器学习api以及图计算的api。 ## Flink核心概念- DataStream  DataStream: Flink用类DataStream来表示程序中的流式数据。用户可以认为它们是含有重复数据的不可修改的集合(collection)，DataStream中元素的数量是无限的。 从图中我们可以发现，对DataStream可以使用一些算子，例如KeyBy这样的算子，对它进行处理转换之后，它会转换成另外一种数据流，也称为keyedstream。那么基于keyedstream，我们进一步可以使用窗口算子，这主要是Flink程序设计中对数据流的一些处理方式。 ## Flink核心概念- DataSet DataSet : Flink系统可对数据集进行转换（例如，过滤，映射，联接，分组)，数据集可从读取文件或从本地集合创建。结果通过接收器( Sink)返回，接收器可以将数据写入(分布式）文件或标准输出（例如命令行终端) ## Flink程序  Flink程序由Source、Transformation和Sink三部分组成，其中Source主要负责数据的读取，支持HDFS、kafka和文本等;Transformation主要负责对数据的转换操作; Sink负责最终数据的输出，支持HDFS、kafka和文本输出等。在各部分之间流转的数据称为流( stream ) 。 ## Flink数据源 批处理： Files：HDFS,Local file system，MapR file system；Text，CSV，Avro，Hadoop input formats JDBC、HBase和 Collections 流处理： Files、Socket streams、Kafka、RabbitMQ、Flume、Collections、 Implement your own和SourceFunction.collecto # Flink程序运行图  Flink是一种master-Slave架构，它在启动的时候就会产生了JobManger以及TaskManager。事实上在Flink程序中还包含两个组件，这两个组件一个叫resource manager，主要负责了资源的调度与管理，另外一个称为Dispatcher。主要是用来进行client，要把JobManager进行分发公布。我们来看一看具体的运行流程。 首先是用户提交Flink程序，这个Flink程序就会转换成逻辑数据流图。客户端接收到逻辑数据流图之后，然后连同jar包以及一些依赖包就会提交给了JobManger，JobManger接收到逻辑数据流图之后会转成物理数据流图，这个物理数据流图是真实的可执行的，能够具体的将任务放置在TaskManager上，在TaskManager中会将它所拥有的资源划分成一个一个的TaskSlot。每个TaskSlot实际上就相当于是jvm，它的一个具体的线程。每个TaskSlot占用了TaskManager的一部分资源，这里的资源主要是以内存进行划分的，TaskSlot不对cpu的资源进行划分，因此没有对cpu的资源进行隔离。 ## Flink作业运行流程(一)  用户首先提交Flink程序到JobClient，经过JobClient的处理、解析、优化提交到JobManager，最后由TaskManager运行task。 在Flink中它通过了JobClient提交了任务，做过JobClient提交的任务进一步的进行优化、解析以及处理，提交给了JobManager。JobManager会将jobClient提交了逻辑数据流图转换成物理数据流图，然后将这些任务分配给taskmanager。taskmanager接受到任务之后就相应地进行处理，并且汇报了task的状态给JobManager，JobManager最后就把结果反馈给jobClient。 JobClient是Flink程序和JobManager交互的桥梁。主要负责接收程序、解析程序的执行计划、优化程序的执行计划，然后提交执行计划到JobManager。在Flink中主要有三类Operator。 Source Operator:数据源操作，比如文件、socket、Kafka等。 Transformation Operator:数据转换操作，比如map，flatMap，reduce等算子。 Sink Operator:数据存储操作。比如数据存储到HDFS、Mysql、Kafka等等。 ## 一个完整的Flink程序---java   ## Flink的数据处理 Apache Flink它同时支持批处理和流处理，也能用来做一些基于事件的应用。 首先Flink是一个纯流式的计算引擎，它的基本数据模型是数据流。流可以是无边界的无限流，即一般意义上的流处理。也可以是有边界的有限流，就是批处理。因此Flink用一套架构同时支持了流处理和批处理。 其次，Flink的一个优势是支持有状态的计算。如果处理一个事件(或一条数据）的结果只跟事6件本身的内容有关，称为无状态处理;反之结果还和之前处理过的事件有关，称为有状态处理。 ## 有界流与无界流 无界流:有定义流的开始，但没有定义流的结束。数据源会无休止地产生数据。无界流的数据必须持续处理,即数据被读取后需要立刻处理。不能等到所有数据都到达再处理，因为输入是无限的，在任何时候输入都不会完成。处理无界数据通常要求以特定顺序摄取事件，例如事件发生的顺序，以便能够推断结果的完整性。  有界流:有定义流的开始，也有定义流的结束。有界流可以在读取所有数据后再进行计算。有界流所有数据可以被排序，所以并不需要有序摄取。有界流处理通常被称为批处理。 ## 批处理示例  批处理是流处理的一种非常特殊的情况。在流处理中，我们为数据定义滑动窗口或滚动窗口，并且在每次窗口滑动或滚动时生成结果。批处理则不同，我们定义一个全局窗口，所有的记录都属于同一个窗口。举例来说，以下代码表示一个简单的Flink程序，它负责每小时对某网站的访问者计数，并按照地区分组。 如果知道输入数据是有限的，则可以通过以下代码实现批处理。  如果输入数据是有限的，那么下面代码与上面代码的运行结果相同。  ## Flink批处理模型  Flink通过一个底层引擎同时支持流处理和批处理。 在流处理引擎之上，Flink 有以下机制： - 检查点机制和状态机制：用于实现容错、有状态的处理； - 水印机制：用于实现事件时钟； - 窗口和触发器：用于限制计算范围，并定义呈现结果的时间。 在同一个流处理引擎之上，Flink 还存在另一套机制，用于实现高效的批处理。 - 用于调度和恢复的回溯法：由 Microsoft Dryad 引入，现在几乎用于所有批处理器； - 用于散列和排序的特殊内存数据结构：可以在需要时，将一部分数据从内存溢出到硬盘上； - 优化器：尽可能地缩短生成结果的时间。 流与批处理机制 两套机制分别对应各自的API（DataStream API 和 DataSet API）；在创建 Flink 作业时，并不能通过将两者混合在一起来同时 利用 Flink 的所有功能。 Flink支持两种关系型的API，Table APl和sQL。这两个API都是批处理和流处理统一的APl，这意味着在无边界的实时数据流和有边界的历史记录数据流上，关系型API会以相同的语义执行查询，并产生相同的结果。 - **Table API / SQL** 正在以流批统一的方式成为分析型用例的主要 API。 - **DataStream API** 是数据驱动应用程序和数据管道的主要API。 # 二、Flink的Time与Window ## 时间背景 在流处理器编程中,对于时间的处理是非常关键的。比如计数的例子，事件流数据（例如服务器日志数据、网页点击数据和交易数据）不断产生，我们需要用key将事件分组，并且每隔一段时间就针对每一个key对应的事件计数。这就是我们熟知的“大数据”应流处理中的时间分类 在数据流处理过程中，我们经常使用系统处理时间即: processing time作为某个事件的时间，而实际上系统时间processing time是我们强加给事件的时间，由于网络延迟等原因并不能较好的反应事件之间发生的先后顺序。 在实际场景中，每个事件的时间可以分为三种: - event time，即事件发生时的时间; - ingestion time，即事件到达流处理系统的时间; - processing time，即事件被系统处理的时间。 ## 三种时间示例 例如，一条日志进入Flink的时间为2019-11-1210:00:00.123，到达window的系统时间为2019-11-1210:00:01.234，日志的内容如下: 2019-11-0218:37:15.624 INFO Fail over to rm2 2019-11-0218:37:15.624是Event Time; 2019-11-1210:00:00.123是Ingestion Time; 2019-11-1210:00:01.234是Processing Time; ## 三种时间的区别 实际情况中事件真正发生的先后顺序与系统处理时间存在一定的差异，这些差异主要由网络延迟、处理时间的长短等造成。如图所示:  横坐标代表Event time，纵坐标代表processing time。理想情况下,eventtime和processing time构成的坐标应该形成一条倾斜角为45度的线。但实际应用过程中，processing time要落后与eventtime，造成事件到来的先后顺序不一致。 ## Flink支持的时间语义  Processing Time是指事件数据被Operator处理时所在机器的系统时间，它提供了最好的性能和最低的延迟。 Event Time是指在数据产生时该设备上对应的时间，这个时间在进入Flink之前已经存在于数据记录中了。 Ingestion Time指的是事件数据进入到Flink的时间。 ## Window概述 流式计算是一种被设计用于处理无限数据集的数据处理引擎，而无限数据集是指一种不断增长的本质上无限的数据集，而Window是一种切割无限数据为有限块进行处理的手段。Window是无限数据流处理的核心，它将一个无限的stream拆分成有限大小的"buckets"桶，我们可以在这些桶上做计算操作。 ## Window类型 Window根据应用类型可以分成两类: - CountWindow:数据驱动，按照指定的数据条数生成一个Window，与时间无关。 - TimeWindow:时间驱动，按照时间生成Window。 Apache Flink是一个天然支持无限流数据处理的分布式计算框架，在Flink中 Window可以将无限流切分成有限流。Flink中 Window可以是Time Window，也可以是Count Window。 # TimeWindow分类 TimeWindow可以根据窗口实现原理的不同分成三类:滚动窗口（Tumbling Window ) .滑动窗口( Sliding Window)和会话窗口( Session Window)。 ## 滚动窗口 将数据依据固定的窗口长度对数据进行切片。特点:时间对齐，窗口长度固定，没有重叠。 适用场景:适合做Bl统计等（做每个时间段的聚合计算）。 举一个例子，假设要对传感器输出的数值求和。一分钟滚动窗口收集最近一分钟的数值，并在一分钟结束时输出总和，如下图所示。  ## 滑动窗口 滑动窗口是固定窗口的更广义的一种形式，滑动窗口由固定的窗口长度和滑动间隔组成。特点∶时间对齐，窗口长度固定，有重叠。 适用场景:对最近一个时间段内的统计（求某接口最近5min的失败率来决定是否要报警）。 示例:一分钟滑动窗口计算最近一分钟的数值总和，但每半分钟滑动一次并输出结果，如下图所示。  ## 会话窗口 会话窗口由一系列事件组合一个指定时间长度的timeout间隙组成，类似于web应用的session，也就是一段时间没有接收到新数据就会生成新的窗口。特点:时间无对齐。  ## 代码定义 在Flink中，一分钟滚动窗口的定义如下: `stream.timeWindow(Time.minutes(1));` 在Flink中，每半分钟(即30秒）滑动一次的一分钟滑动窗口，如下所示: `stream.timeWindow(Time.minutes(1),Time.seconds(30));` # 三、Flink的Watermark ## 乱序问题 流处理从事件产生，到流经source，再到operator，中间是有一个过程和时间的，虽然大部分情况下，流到operator的数据都是按照事件产生的时间顺序来的，但是也不排除由于网络、分布式等原因，导致乱序的产生，所谓乱序，就是指Flink接收到的事件的先后顺序不是严格按照事件的Event Time顺序排列的。  此时出现一个问题，一旦出现乱序，如果只根据eventTime决定window的运行，我们不能明确数据是否全部到位，但又不能无限期的等下去，此时必须要有个机制来保证一个特定的时间后，必须触发window去进行计算了，这个特别的机制，就是Watermark。 ## 乱序示例 例子:某App会记录用户的所有点击行为，并回传日志（在网络不好的情况下，先保存在本地，延后回传）。A用户在11:02对App进行操作，B用户在11:03对App进行操作，但是A用户的网络不太稳定，回传日志延迟了，导致我们在服务端先接受到B用户11:03的消息，然后再接受到A用户11:02的消息，消息乱序了。 # 水位线（Watermark） 对于无穷数据集，我们缺乏一种有效的方式来判断数据完整性，因此就有了Watermark,它是建立在事件时间上的一个概念，用来刻画数据流的完整性。如果按照处理时间来衡量事件，一切都是有序的、完美的，自然而然也就不需要Watermark了。换句话说事件时间带来了乱序的问题，而Watermark就是用来解决乱序问题。所谓的乱序，其实就是有事件延迟了，对于延迟的元素，我们不可能无限期的等下去，必须要有一种机制来保证一个特定的时间后，必须触发Window进行计算。这个特别的机制,就是Watermark,它告诉了算子延迟到达的消息不应该再被接收。 - Watermark是一种衡量Event Time进展的机制。 - Watermark是用于处理乱序事件的，而正确的处理乱序事件，通常用Watermark机制结合window来实现。 - 数据流中的Watermark用于表示timestamp小于Watermark的数据，都已经到达了，因此，window的执行也是由Watermark触发的。 - Watermark可以理解成一个延迟触发机制，我们可以设置Watermark的延时时长t，每次系统会校验已经到达的数据中最大的maxEventTime，然后认定eventTime小于maxEventTime - t的所有数据都已经到达，如果有窗口的停止时间等于maxEventTime – t，那么这个窗口被触发执行。 - watermark 用来让程序自己平衡延迟和结果正确性 # Watermark的原理 Flink怎么保证基于event-time的窗口在销毁的时候，已经处理完了所有的数据呢?  这就是watermark的功能所在。watermark会携带一个单调递增的时间戳t，Watermark(t)表示所有时间戳不大于t的数据都已经到来了，未来小于等于t的数据不会再来，因此可以放心地触发和销毁窗口了。  当Flink,接收到数据时，会按照一定的规则去生成Watermark，这条Watermark就等于当前所有到达数据中的maExertT me"-延N时长，也就定说，Watermark是基于数据携带的时间戳生成的，一旦Watermark比当前未触发的窗口的停止时间要晚，那么就会触发相应窗口的执行。由于eventtime是由数据携带的，因此，如果运行过程中无法获取新的数据，那么没有被触发的窗口将永远都不被触发。 上图中，我们设置的允许最大延迟到达时间为2s，所以时间戳为7s的事件对应的Watermark 是 5s，时间戳为12s的事件的Watermark是10s，如果我们的窗口是1s-5s，窗口2是6s~-10s，那么时间戳为7s的事件到达时的Matermarker.恰好触发窗口1，时间戳为 12s的事件到达时的Watermark恰好触发窗口2。 Watermark就是触发前一窗口的“关窗时间”，一旦触发关门那么以当前时刻为准在窗口范围内的所有所有数据都会收入窗中。只要没有达到水位那么不管现实中的时间推进了多久都不会触发关窗。 ## 延迟的数据 Watermark能够应对乱序的数据，但是真实世界中没法得到一个完美的 Watermark数值。要么没法获取到，要么耗费太大，因此实际工作中会近似 Watermark(t)之后，还有较小的概率接受到时间戳t之前的数据，在Flink中将这些数据定义为“late elements”，同样可以在Window中指定允许延迟的最大时间（默认为О)，可以使用下面的代码进行设置:  ## 延迟数据处理机制 延迟事件是乱序事件的特例，和一般乱序事件不同的是它们的乱序程度超出了水位线( Watermark)的预计，导致窗口在它们到达之前已经关闭。 延迟事件出现时窗口已经关闭并产出了计算结果，对于此种情况处理的方法有3种: - 重新激活已经关闭的窗口并重新计算以修正结果。 - 将延迟事件收集起来另外处理。 - 将延迟事件视为错误消息并丢弃。 Flink默认的处理方式是第3种直接丢弃，其他两种方式分别使用Side Output和AllowedLateness。 ## Side Output机制 Side Output机制可以将延迟事件单独放入一个数据流分支，这会作为Window计算结果的副产品，以便用户获取并对其进行特殊处理。 side Output获取延迟数据： 设置allowedLateness之后，迟来的数据同样可以触发窗口，进行输出，利用Flink的sideoutput机制，可以获取到这些延迟的数据，使用方式如下:  ## Allowed Lateness机制 Allowed Lateness机制允许用户设置一个允许的最大延迟时长。Flink会在窗口关闭后一直保存窗口的状态直至超过允许延迟时长，这期间的延迟事件不会被丢弃，而是默认会触发窗口重新计算。因为保存窗口状态需要额外内存，并且如果窗口计算使用了ProcessWindowFunction APl还可能使得每个延迟事件触发一次窗口的全量计算，代价比较大，所以允许延迟时长不宜设得太长，延迟事件也不宜过多。 # 四、Flink的容错 ## Flink容错机制 为了保证程序的容错恢复以及程序启动时其状态恢复，Flink任务都会开启Checkpoint或者触发Savepoint进行状态保存。 - Checkpoint机制。这种机制保证了实时程序运行时，即使突然遇到异常也能够进行自我恢复。Checkpoint对于用户层面，是透明的，用户会感觉不到Checkpoint过程的存在。 - Savepoint机制。是在某个时间点程序状态全局镜像，以后程序在进行升级，或者修改并发度等情况，还能从保存的状态位继续启动恢复。Savepoint可以看做是Checkpoint在特定时期的一个状态快照。 ## Checkpoint Flink 如何保证exactly-once呢?它使用一种被称为“检查点( Checkpoint )”的特性，在出现故障时将系统重置回正确状态。Flink状态保存主要依靠Checkpoint机制,Checkpoint会定时制作分布式快照，对程序中的状态进行备份。 ## Checkpoint检查点机制 Flink中基于异步轻量级的分布式快照技术提供了Checkpoints容错机制，分布式快照可以将同一时间点Task/Operator的状态数据全局统一快照处理。Flink会在输入的数据集上间隔性地生成checkpoint barrier，通过棚栏( barrier)将间隔时间段内的数据划分到相应的checkpoint中。当应用出现异常时，Operator就能够从上一次快照中恢复所有算子之前的状态，从而保证数据的一致性。 对于状态占用空间比较小的应用，快照产生过程非常轻量，高频率创建且对Flink任务性能影响相对较小。Checkpoint过程中状态数据一般被保存在一个可配置的环境中，通常是在JobManager节点或HDFS上。 ## Checkpoint配置  默认情况下Flink不开启检查点，用户需要在程序中通过调用enableCheckpointing(n)方法配置和开启检查点，其中n为检查点执行的时间间隔，单位为毫秒。 **exactly-once和at-least-once语义选择** exactly-once:保证端到端数据一致性，数据要求高，不允许出现数据丢失和数据重复，Flink的性能也相对较弱; at-least-once:时延和吞吐量要求非常高但对数据的一致性要求不高的场景。 Flink默认使用exactly-once模式，可以通过setCheckpointingMode()方法来设定语义模式。 env.getCheckpointConfig().setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE) **Checkpoint超时时间** 指定每次Checkpoint执行过程中的上限时间范围，一旦Checkpoint执行时间超过该阈值，Flink将会中断Checkpoint过程,并按照超时处理。 该指标可以通过setCheckpointTimeout方法设定，默认10分钟。 env.getCheckpointConfig().setCheckpointingTimeout(60000) **检查点之间最小时间间隔** 设定两个Checkpoint之间的最小时间间隔，防止出现状态数据过大而导致Checkpoint执行时间过长，从而导致Checkpoint积压过多，最终Flink应用密集地触发Checkpoint操作，会占用大量计算资源而影响到整个应用的性能。 env.getCheckpointConfig().setMinPauseBetweenCheckpoints(500) **最大并行执行的检查点数量** 设定能够同时执行的Checkpoint数量。在默认情况下只有一个检查点可以运行，根据用户指定的数量可以同时触发多个Checkpoint，从而提升Checkpoint整体的效率。 env.getCheckpointConfig().setMaxConcurrentCheckpoints(500) **外部检查点** 设定周期性的外部检查点，然后将状态数据持久化到外部系统中，使用这种方式不会在任务停止的过程中清理掉检查点数据，而是一直保存在外部系统介质中，也可以通过从外部检查点中对任务就行恢复。 env.getCheckpointConfig().enableExternalizedCheckpoints(ExternalizedCheckpointCleanup.RETAIN_ON_CANCELLATION) # 作业如何恢复数据? Flink在Cancel时允许在外部介质保留Checkpoint;另一方面，Flink还有另外一个机制是SavePoint. Savepoints是检查点的一种特殊实现，底层其实是使用Checkpoints的机制。Savepoints是用户以手工命令的方式触发，并将结果持久化到指定的存储路径中，目的是帮助用户在升级和维护集群过程中保存系统中的状态数据，避免因为停机运维或者升级应用等正常终止应用的操作而导致系统无法恢复到原有的计算状态的情况，从而无法实现端到端的Exactly-Once语义保证。 ## Savepoint与Checkpoint  checkpoint的侧重点是“容错”，即Flink作业意外失败并重启之后，能够直接从早先打下的checkpoint恢复运行，且不影响作业逻辑的准确性。而savepoint的侧重点是“维护”，即Flink作业需要在人工干预下手动重启、升级、迁移或A/B测试时，先将状态整体写入可靠存储，维护完毕之后再从savepoint恢复现场。 savepoint是“通过checkpoint机制”创建的，所以savepoint本质上是特殊的checkpoint。 checkpoint面向Flink Runtime本身，由Flink的各个TaskManager定时触发快照并自动清理，一般不需要用户干预；savepoint面向用户，完全根据用户的需要触发与清理。 - 触发管理方式上，Checkpoint是由Flink自动触发并管理；Savepoint由用户手动触发并管理 - 主要用途上，Checkpoint在Task发生异常时快速恢复，例如网络抖动导致的超时异常；Savepoint有计划的进行备份，例如修改代码，调整并发 - 从特点上看，Checkpoint轻量，自动从故障中恢复，在作业停止后默认清除；Savepoint持久，以标准格式存储,允许代码或配置发生改变，手动触发从Savepoint的恢复。 ## 状态的存储方式-MemoryStateBackend 构造方式： MemoryStateBackend(int maxStateSize, boolean asynchronousSnapshots) 存储方式： - State: TaskManager内存;Checkpoint: JobManager内存。 容量限制： 单个state maxStateSize默认5M； maxStateSize=akka.framesize ，默认10 M。·总大小不超过JobManager的内存 推荐使用的场景:本地测试;几乎无状态的作业，比如ETL。 ## 状态的存储方式- FsStateBackend 构造方式： FsStateBackend(URI checkpointDataUri ,boolean asynchronousSnapshots) 存储方式： State: TaskManager内存； CHeckpoint:外部文件存储系统（本地或HDFS)。 容量限制： ·单TaskManager 上state总量不超过它的内存; ·总大小不超过配置的文件系统容量。 推荐使用的场景:常规使用状态的作业，例如分钟级别窗口聚合、Join；需要开启HA的作业;可以在生产场景使用。 ## 状态的存储方式- RocksDBStateBackend 构造方式： RocksDBStateBackend(URI checkpointDataUri ,boolean enableIncrementalCheckpointing) 存储方式： State: TaskManager上的KV数据库（实际使用内存+磁盘); CHeckpoint:外部文件存储系统(本地或HDFS)。 容量限制： 单TaskManager 上State总量不超过它的内存+磁盘; 单Key最大2G; 总大小不超过配置的文件系统容量。 推荐使用的场景:超大状态的作业，例如天级别窗口聚合;需要开启HA的作业;要求不高的作业;可以在生产场景使用。 # 总结 本章主要讲述了Flink的架构及技术原理，以及Flink程序的运行过程。重点在于Flink流处理与批处理的不同方式，从长远来看，DataStream API应该通过有界数据流完全包含DataSet APl。

在Hive流行之前，企业大多采用传统的并行数据仓库架构。传统的数据仓库一般采用国外知名厂商的大型服务器和成熟的解决方案，不仅价格昂贵且可拓展性较差，而且平台工具与其他厂商难以适配，用户操作体验也比较差、开发效率不高，当数据量达到TB级别后基本无法得到很好的性能。而且，传统数据仓库基本只擅长处理结构化或半结构化数据，对于非结构化数据的处理并不能很好地支持。Hive的出现，为企业提供了更加廉价且优质的解决方案。Hive的主要组件包括UI组件、Driver组件(Complier、Optimizer和Executor)、Metastore组件、JDBC/ODBC、Thrift Server和Hive Web Interface（HWI）等，接下来分别对这几个组件进行介绍。(1) Drvier组件: 该组件是Hive的核心组件，该组件包括Complier(编译器)、Optimizer(优化器)和Executor(执行器),它们的作用是对Hive SQL语句进行解析、编译优化、生成执行计划，然后调用底层MR计算框架。(2) MetaStore组件: 该组件是Hive用来负责管理元数据的组件。Hive的元数据存储在关系型数据库中，其支持的关系型数据库有Derby和Mysql，其中Derby是Hive默认情况下使用的数据库，它内嵌在Hive中，但是该数据库只支持单会话，在生产中并不适用，在我们日常的开发中，需要支持多会话，因此采用Mysql作为元数据库，Hive内部对Mysql提供了很好的支持。(3) Thrift Server：该组件提供JDBC和ODBC接入的能力，用来进行可扩展且跨语言的服务开发。Hive集成了该服务，能让不同的编程语言调用Hive的接口。(4) Web Interface：该组件是Hive客户端提供的一种通过网页方式访问Hive所提供的服务。

       Hive 是基于Hadoop构建的一套数据仓库分析系统，用来进行数据提取、转化、加载，这是一种可以存储、查询和分析存储在Hadoop中的大规模数据的机制。Hive数据仓库工具能将结构化的数据文件映射为一张数据库表，并提供SQL查询功能，能将SQL语句转变成MapReduce任务来执行。Hive的优点是学习成本低，可以通过类似SQL语句实现快速MapReduce统计，使MapReduce变得更加简单，而不必开发专门的MapReduce应用。       Hive十分适合对数据仓库进行统计分析，Hive支持了绝大多数的语句如DDL、DML以及常见的聚合函数、连接查询、条件查询。它还提供了一系列的方法，进行数据提取转化加载，用来存储、查询和分析存储在Hadoop中的大规模数据集，并支持UDF（User-Defined Function）、UDAF(User-Defnes AggregateFunction)和UDTF（User-Defined Table-Generating Function），也可以实现对map和reduce函数的定制，为数据操作提供了良好的伸缩性和可扩展性。       Hive不适合用于联机(online)事务处理，也不提供实时查询功能。它最适合应用在基于大量不可变数据的批处理作业。Hive的特点包括：可伸缩（在Hadoop的集群上动态添加设备）、可扩展、容错、输入格式的松散耦合。

文章摘要：随着企业数字化转型深化，数据在企业中扮演着愈发重要的作用。数据无论从存储规模、还是计算要求都有着较之以往更高的需求。金融行业，作为数据应用的“高地”，这一点表现尤为突出。如何在新时期，满足对数据基础设施更高的要求，成为各金融机构首要面对的问题。分布式数据库，作为一种新的数据库架构，经过近十余年的高速发展，已逐步成熟，并开始在一些金融机构中投产使用。但这种新的架构，较之以往的传统架构有着诸多不同。本文尝试从建设背景、技术趋势、落地实践、典型产品等多角度，分析当前分布式数据库与金融行业背景想结合，如何实现更好的落地实践。1. 金融业分布式数据库建设背景1） 多元素驱动数据库架构升级数字化转型随着全行业数字化转型深化，金融业作为数据应用“高地”，走在这一趋势的前沿。一方面，金融业企业的业绩水平与数字化能力是直接挂钩的，从今年数据来看，转型较快的金融机构业绩提速明显快于较慢的；另一方面，来自宏观经济发展压力，导致规模盈利减低，进而导致业务转型加速。在数字化转型加剧的大背景下，金融 企业对数据使用呈现多样化特点且针对特性能力提出更高要求。相应的也对数据底层基础设施之一的数据库提出要求。金融业 业务驱动如上面所谈，金融业在数字化转型中，面临业务转型问题。当前金融业整体处于信息化末期、移动化成熟期、开放化成长期、智能化探索期。其典型特点是，金融行业的数据急剧增长，对数据存储和管理提出了更高要求；在高并发业务和大用户量带来的系统压力的同时，也要求移动应用响应速度更快。国家 政策指导在政策层面，国家很早就将新型数据库作为重要基础设施来看待并给出指导性原则。在《金融科技（ FinTech）发展规划（2019-2021）》中明确指出：“加强分布式数据库的研发应用。做好分布式数据库金融应用的长期规划，加大研发与应用投入力度。有计划、分步骤稳妥推动分布式数据产品先行先试，形成可借鉴、能推广的典型案例和解决方案，为分布式数据库在金融领域的全面应用探明路径。建立健全产学结合、校企协同的人才培养机制，持续加强分布式数据库底层和前沿技术研究，制定分布式数据库金融应用标准规范，从技术架构、安全防护、灾难恢复等方面明确管理要求，确保分布式数据库在金融领域的稳妥应用。”2） 金融业对数据库转型诉求在上述大背景情况下，金融业对数据库支持能力呈现如下特点：实时性在数字化趋势下，数据会更多参与到企业决策、业务调整甚至驱动业务变化。数据的鲜活性，对企业价值意义完全不同。实时的交易处理、实时的反馈、实时的汇聚、实时的洞察成为全场景数字化的必备。例如在金融场景中，金融需求与生活场景相融合，实时风控的复杂度以及时效性要求随场景服务的发展不断增长，通常需要秒级完成业务流程。翻译成技术语言，即要求支持对数据高频实时多点写入、对多类信息实时汇聚分析处理。于是近些年来，在数据流式处理、 HTAP、高性能计算等领域的发展，正是为迎合这一诉求。敏捷性数字化转型下，各种业务形态不断涌现且单业务内变化也很大，这对底层基础设施提出了敏捷性要求。即具备快速响应能力，满足各类业务应用需求。作为传统的以静态、固定资源供给方式，过渡到以动态、可调节的资源供给方式。这其中以云、容器化、 Serverless、存算分离为代表的技术能力，正是为满足这类需求而诞生。即使是以较为传统架构的资源供给方式，也更为强调弹性、可定制能力，满足客户此方面需求。安全性数据安全，是近些年来的热门话题。从监管方的频频出台各项政策，可见一斑。作为承载数据的主体，数据库首当其冲需要将更为重视安全问题。从数据存储、数据访问、数据传输、数据应用等多角度解决数据安全问题。特别是过去一二十年开源数据库蓬勃发展，但开源数据库自身在安全方面是否能达到商用标准，值得关注。此外，考虑到复杂的国际产业环境，开源协议本身的合法合规性也值得关注。可用性可用性要求，一直是数据库提供的基本能力之一。随着数字化深入，越来越多的数据参与到企业经营管理之中，这些对于可用性要求提出了更高的要求。从数据库的角度来看，之前单机架构或集中式架构，一般是通过高可用硬件 +软件来解决；对于新兴的分布式架构来说，其组件更多也更为复杂，且对于硬件也无较多要求，这就要求软件本身提供更高要求。经济性随着数据存储规模越来越大，对数据计算要求越来越高，整体数据存储和计算的成本也整体提高。如何提供更具经济性的方案，对客户能否大规模使用意义很大。这其中云数据库、存算分离、数据分层等技术，正是为了应对这一诉求。云作为一种新的资源供给方式，可以带来更为切合需求的资源消耗。存算分离，则提供一种按计算和存储独立扩展能力，避免冗余浪费。数据分层，则可根据数据热度等因素提供不同的能力，满足个性化需求。智能化由上述变化可见，对于数据库而言，无论从使用规模、复杂程度都会带来很大调整。针对这一问题，一方面可以通过工具化、平台化的方式来满足管理问题；而更为优雅的方式是在数据库端提供内置的智能管理能力，例如智能调优、索引推荐、自我诊断、故障自愈等，可协助 DBA降低运维难度，大幅提升管理效率。海量并发这是两个需求，一个是数据规模问题，提供海量数据支撑能力；一个是数据计算问题，提供高并发访问支持。这些都是数字化会带来业务变化的必然。对应于技术而言，分布式数据库无疑是一种很好的方式，也是其主要面对解决的场景之一。统一管理随着数字化深入，对数据库的种类与数量、企业的 IT体系等都发生了不少变化。这些变化冲击了传统的数据库生态，第一数据库选型自身呈现多元化趋势；第二随着分布式、存算分离等新兴架构，对管理也带来了管理难题；第三随着对安全性、可靠性等方面的更高要求，也带来了不少难点。面对上述问题，为数据库提供统一管理和运维的平台型工具也逐渐走向台前，变得越来越重要。自主可控对基础软件来说，自主可控非常关键。作为数字化的载体，数据库的自主可控能力尤为重要。近些年国产化诉求日益高涨，也有着这方面的考虑。这其中值得关注的一点是关于开源的使用。根据近期的调研，开源数据库份额已经超越商业数据库；但对于开源数据库的把控能力，却有着较大差异。特别是某些商业数据库，底层也是基于开源产品的，尤其值得关注。开放生态数字化深入，带来的更多的场景、更多的方案、更多的产品。如何能做到产品之间的很好的融合，发挥最大的作用，开放生态非常重要。对于数据库而言，过去数十年来以国外商用数据库产品为主，已经培育自己的生态圈；而对于国内产品而言，还需要走过这一过程。比较可喜的是，开源软件的使用可大大加速这一过程。以 MySQL、PG为代表的开源软件，具有较为完备的生态，国内产品可通过兼容开源产品，复用其生态，大大加速这一进程。简化融合如之前所说，数字化深化带来的技术需求的多元化，与之对应的产品方案也呈现同样的态势。虽然可以通过统一管理角度去简化管理，但对于用户而言仍然不得不去面对复杂的管理和使用问题。如果能通过单一平台提供所需能力，无疑对用户非常有吸引力。这就是简化融合的诉求的来源。近些年来，包括混合事务与分析处理（ HTAP）、湖仓一体、流批一体等，都是代表着用户追求 “简化、融合”技术栈的需求。此外，云也是一种简化融合的体现，通过一站式的产品+方案，解决用户复杂管理和使用问题。消费创新数据在未来扮演着愈发重要的角色，人们对数据的消费使用习惯也发生了很多变化。从使用角度来看，普惠性得以强调。数据的使用消费者，从传统的分析师、 BI工程师向普通的数据消费者转移。越来越多的用户能够触达数据，享受数据结果。当然，这也得对数据提供方式带来新的挑战，自助式、对话式、自动化甚至智能化的数据计算展现方式得到更多的使用，进一步减低人们使用数据的门槛。这对于底层数据库带来包括适配能力、实时计算、多模计算、智能分析等诸多要求。3） 分布式数据库在金融业使用痛点如之前所说，金融业一方面面临诸多转型压力，对底层数据库提出了更多要求；另一方面原有数据库技术已不适应当前业务特点，继续升级换代。面对底层基础设施的转型问题，分布式数据库作为解决上述方案的唯一选型。但在这一选择过程中，往往存在较多的痛点和难点。这主要是因为金融行业的特殊性所造成的。基础功能待完善对标传统集中式数据库，现有的分布式数据库在功能上仍然有待完善。这一方面是因为分布式架构所造成的功能 tradeoff，另一方面是在产品化能力完整性上的欠缺。前者是我们在使用分布式数据库产品时，需要在架构、设计层面需要在关注的，在项目初期都需要解决掉的。而后者厂商产品经过多年发展在内核能力上已趋于完善，但在周边配套的管理、设计、优化工具上，仍需进一步完善。毕竟最终为用户呈现的，是一套完整的数据库解决方案。运行稳定待验证对于金融行业而言，稳定性是第一位的。虽然分布式数据库在设计之初，就将稳定性设计放在优先位置，其天然的分布式架构也有利于提供更高的可用性保证。但一方面分布式架构天然由多组件组成，其复杂程度较集中式更高；另一方面其对底层基础环境的要求也更高。此外，产品的稳定性是要在长期实践中不断打磨、持续改进的。分布式数据库作为后来者，也需要经历这一过程。迁移改造任务重选择使用分布式数据库产品，对应用侧来说，需要有大量的应用迁移工作。一方面是由于分布式数据库较集中式数据库功能上有所削弱，另一方面更换数据库天然所需要的移植工作。虽然目前各分布式数据库也推出 兼容能力，但从实际效果来看仅能减少部分移植工作，整体迁移任务量仍然很高。且迁移采用所谓的兼容模式，也不利于后期平滑更换，这点后面会讲到。风险巨大需并行对底层数据库的更换，是存在较大技术风险的。一是由于新产品、新架构所带来的风险；二是应用迁移改造带来的不确定性；三是产品本身的稳定性的潜在风险。为应对这种情况，最为稳妥的方式是采取应用双发并行的方式解决。这种方式可在最大程度上减少可能初期的风险，可做到数据冗余、无缝切换、灵活可控等，但其花费的代价也是非常高的。需要从应用端做大量双发改造，如果更换系统很多，这方面代价是比较大的。生态环境需培育虽然发展多年，但国产分布式数据库在整体市场上仍然属于小众选择。之前国外厂商产品占据市场领导地位，经过多年发展已形成了较为完善的生态。随着近些年来， MySQL、PG开源数据库在互联网行业得到大量应用，积累大量用户，建立其不错的生态。很多国产分布式数据库采用迂回策略，通过兼容上述数据库标准，来享受开源生态红利。此外，近期国产数据库如TiDB、OceanBase、PorlaDB、openGuass等，也纷纷开源建设自有生态。信创要求时间紧作为国家安全的重要举措之一，安全可控成为基础要求，信创因而诞生。为保证上述政策执行到位，国家也设定实施计划。作为基础软件的数据库，也是信创工作的重点。如何在规定的时间内完成，也为各企业带来的很大压力。场景多元难选择与互联网企业不同，金融行业对数据的使用场景更加多元化，这也对数据库提出了较高的要求。仅选择单一数据库满足全场景需求，几乎是不可能的。在传统集中式数据库上，这一问题还不明显，因为这些数据库往往是多面手，各方面功能较为均衡；而分布式数据库则不然，其往往有明确的适用场景范围。而作为企业用户，是需要对自己场景有个清晰的认识，然后按图索骥找到适合自己的产品。厂商绑定风险高选择某厂商产品，也就意味着选择某一技术路线，如果深度依赖厂商产品的特有能力，无疑存在绑定风险问题。这点对于分布式数据库来说，表现尤甚。各厂商产品实现差异很大，没有通用的使用标准。如何规避这一风险，带来最大的自由度选择？后文会展开说明。2. 分布式数据库技术发展趋势1） 数据库技术发展整体趋势数据库技术 ，最早源自上世纪70年代，从IBM著名的论文开始，后面诞生了Oracle、DB2为代表的优秀商业产品以及PostgreSQL、MySQL为代表的开源产品。这些产品很好的满足了对数据存储和计算的需求。随着21世纪初期，互联网浪潮的来临，数据规模呈爆炸式增长，单机数据库越来越难以满足用户需求。这也催生了分布式数据库的到来。到了2006年之后，出现以HBase/Cassadra/MongoDB为代表的NoSQL类产品。这些产品实现了分布式架构，可以实现容量的水平扩展，但也牺牲了诸如事务、SQL访问接口等能力。存储模型的简化为存储系统的开发带来了便利，但是降低了对业务的支撑。在这一阶段，很多企业为了解决大规模数据存储与访问的问题，也研发了很多中间件产品。其原理是通过将数据分片存储到单机库，上层对SQL解析实现对语句的路由。这种方式有一定的难点，例如对分布式事务的处理及规模扩大下的管理问题。到了2012年，Google的论文为关系模型的分布式架构，提供了新型分布式数据库理论基础。在此之后，诞生了一系列新型分布式数据库产品。其原理是通过分布式一致性算法协议完成底层数据多副本存储，上层则实现了标准SQL支持能力。数据库架构演进，从整体来看，走过了大致三个阶段。第一阶段，是以单节点为主要特征，通过单机能力来承载数据计算和存储的能力。这一架构的优势在于架构简单、维护成本低，随着单机能力的提升可满足大部分业务场景需求。缺点是数据库节点（包括内置存储）容易出现单点故障，且计算和存储能力受限于硬件性能，无法扩展。第二阶段，是以共享存储为主要特征，通过多台主机来承载数据计算能力，数据存储则集中于集中式共享存储之中。这一架构的优势在于解决了前一阶段数据计算部分的单点故障，结构仍较简单，易于实现事务一致性等问题。缺点在于数据计算部分扩展能力有限，底层数据存储部分依赖于高端共享存储且扩展能力也有限。第三阶段，是以分布式为主要特征，通过多台主机来承担数据计算与存储能力。这一架构优点在于良好地水平扩展能力，数据多副本存储，无需依赖共享存储。缺点在于，计算与存储能力需同步扩展，灵活度稍差，此外存在分布式查询、分布式事务的处理开销问题。2） 主流的分布式数据库技术分布式中间件这种架构是从之前谈到的中间件路线演进而来 ，是一种典型的“ Share Nothing”架构。通过上层无状态的计算节点提供弹性可扩展的计算能力，下层通过增强单机数据库提供基础存储能力及本地算力。这一架构通过硬件堆叠，可近似线性地提供计算性能和存储容量，具有可支持超大规模集群的能力。这种架构在分布式事务、全局MVCC等方面，往往存在一定难点，各厂商也有各自解决之道。这一架构产品优势在于功能丰富、可按业务做定制；稳定性较高，基于成熟稳定的单机引擎。在面对超大规模数据存储，通过灵活的分片配置策略，支持高灵活度数据打散技术，并可贴近场景需求定制分片。相对不足在于全局事务能力、全局 MVCC、副本控制、高可用等方面存在先天短板，需要有针对性增强。例如引入全局事务管理器组件，突破单机限制，实现分布式事务的实时一致性及全局MVCC能力，对应用透明的分布式事务处理，应用无需改造。通过一阶段提交+自动补偿机制，提升分布式事务处理性能。针对数据强一致性的要求，在单机库同步技术基础上，通过内核级的增强优化实现更高级别的复制保证数据不丢失。此外，由于需维护多节点一致性而带来的在跨分片DDL、分片节点扩容、跨节点复杂查询、全局一致的备份恢复等方面问题值得关注。这种架构产品较为适用于数据规模巨大、对延迟要求很高的在线交易场景。在数据库设计时，需要特别注意分区键和分区策略的选择，合理布局数据，尽量避免跨节点的分布式事务处理，以提高数据库的效率。分布式事务这 种架构正是受到Google论文影响演进而来 ，采用“ Share Nothing”架构。其采用存储与计算分离架构，底层多采用自研或裸存储引擎，数据按规则打散并存储多个副本，通过paoxs/raft等分布式协议保证多个副本间数据一致。上层实现数据库基础的优化器、执行器等组件，对分布式事务、全局MVCC等支持更为彻底。此外，由于其底层的存储引擎不是依赖某一产品，可根据需要组织数据，因此在适配场景上 更有优势，例如在某些分析类场景可选择列存。原生分布式实现，工程上不依赖其他产品，可控程度更高。面对很多新的需求，可从底层加以实现支持，不受限于第三方。在副本控制、数据一致性、容灾、弹性能力等方面更具有优势。此外，场景方面有更为灵活的选择及未来可扩展的空间。 但这一方式在产品成熟度，仍需较长时间沉淀。特别是使用在核心业务场景，仍然需要较长时间的锤炼。此外，其内置的分片规则，对于某些需贴合业务的架构设计不太友好。对于高并发、低延迟的极端场景仍然有一定局限。分布式存储在某种程度上讲，云原生数据库也是一种分布式，但与前两者区别是非 Share Nothing架构，而是Share Everything模式。其底层是与分布式云存储，本质上来说仍然是一种集中式架构。上层的计算部分，是无状态的一组结点组成。针对这种架构不足展开说明，原因是这种方式是需要对底座有比较重的依赖，无法在金融行业相对要求独立环境中部署，除非整个底层都更换。因此，使用选择上存在一定困难。3. 分布式数据库金融业实践1） 金融业数据库选型难点金融业在分布式数据库选型存在若干难点：复杂业务逻辑问题，包括数据库技术基因匹配性（如：数据库本身锁机制、隔离级别问题），包括技术兼任性（如存储过程、视图兼容性）；应用的适配度问题，银行应用大部分都是基于单机关系型数据库机制设计的，例如大部分场景都是串行机制，发挥不出来分布式数据库的强大并发处理技术，反而分布式数据库本身的二阶段提交机制，对简单事务的延时增加问题，造成串行事务执行性能低下；人员能力的匹配性，需要根据人员技术能力进行选型考虑，例如基于 Spanner体系，基于Aurora体系，基于国内互联网公司自研的产品等，要考虑现有人员对数据库技术的了解程度，更要关注数据库技术本身的开放度和社区热度，让人员可以很快的学习和提升数据库技术能力；数据库自身能力问题，包括在分布式事务、数据一致性、高可用容灾等，相较于传统集中式数据库还是存在一些不足；此外金融业在联机交易的低延迟要求、跑批类的高吞吐要求也对分布式数据库提出了很高的要求；数据库运营维护问题，包括是否具备足够能力维护分布式数据库？是否能够接受数据库转型期间的业务中断时间？是否具备迁移（甚至在线）迁移能力？是否具有应用级双发能力，规避可能出现的风险等。2） 金融业数据库选型策略通过数据库的技术标准化和轻量化工作，形成统一的数据库使用规范，解耦应用和底层数据库技术架构，在标准数据库协议及语义下，可以很轻松的更换数据库架构。通过构建异构间数据同步、流量接入控制（限流、灰度等）、全局数据服务（如事务、快照等），实现业务的无感切换和迁移回退，保证最大的灵活可控。针对上述诸多难点、痛点，作为金融行业如何选择分布式数据库呢？可遵从以下几个方面：尊重路线之争，无关技术领先如前面所述，分布式数据库的发展有着不同的技术路线。曾有种观点认为，“分布式数据库的发展方向代表着未来，分布式中间件方向没有前途”。针对这一问题，我的观点是采用不同技术路线的产品有自己的适用场景，与技术领先性无关。某种技术通过提出理论、工程化实现、产品能力输出，可解决某方面需求、甚至带来巨大产品能力的提升；但希望以此通过大一统的产品解决所有问题是不现实的，未来仍然是多种技术路线并存的情况。成熟度有待完善，但时不我待提前规划分布式数据库作为一种新兴技术产品，其成熟度尚需锤炼，但不能基于此就选择观望态度。产品成熟的提高，一方面来自厂商对产品的不断迭代优化；另一方面也来自使用者的不断打磨。企业内对数据库的落地使用，也需要较为长期的过程。此外，外部驱动也对这一选择起到加速推动作用。作为企业来讲，根据自身情况可以选择不同策略（引领、跟随）；但无论那种都需要提前规划，有明确方向和实施路径。国产数据库百花齐放，机会无限近些年来，国产数据库发展迅猛，呈现百花齐放态势。针对这一现状，一方面要持续关注这些产品，给予这些产品充分施展机会；另一方面制定准入标准严格把关，让真正有实力的厂商能够进入，得到充分锻炼、打磨的机会。慎重技术选型，不迷信宣传技术选型是个很严谨的过程，需要慎重对待。有很多第三方的评测和厂商宣传结论，但这些只能做参考，决策层面的依据还是需依靠自己。一方面宣传内容一般都会所选择有利于自己，这会带来一定误导性；另一方面对同一概念的理解是有偏差的，很难仅仅通过一段文字描述就能完全说清楚。这些问题只有在真实环境，叠加上自身需求，测试出的结果才具说服力。结合场景需求，没有最好只有最适合业务场景千差万别，其对数据库能力要求和侧重点也有所不同。很难选择一款通用型产品满足全场景，那就需要根据实际情况做有针对性的选择。此外，不同产品各有强点和局限之处，选择最适合你的产品就好。例如上文谈到的分布式中间件产品，在超大规模、自定义分片、超高性能、业务控制等方面往往更有优势；而分布式数据库产品，则在分布式事务、数据强一致、混合负载等方面有所擅长。不选产品选兼容性，保持最大自由度当前分布式数据库，仍然处于快速发展期，很难确定未来的主流选择。为了规避路线选择、厂商绑定的风险，比较现实的方法是选择一款兼容通用性协议的产品，并且在使用中仅使用标准数据库的用法。举个例子，选择一款兼容 MySQL的产品并且安装标准MySQL的用法使用；当出现风险时完全可选择另外一款同样兼容MySQL的产品来替代。目前MySQL生态在国内最为成熟，很多厂商产品也选择了兼容它，因此选择兼容性产品在未来的自由度最大。保持技术敏感度，紧跟时代发展步伐面对技术发展多变、应用特点多变、外部需求紧迫的现状，时刻关注分布式数据库发展，保持足够的技术敏感度，紧跟技术发展趋势。采取架构前置、谨慎选型、局部试点、多线布局、掌握主动、自建增强等策略，保持主动。3） 金融业数据库场景梳理金融企业对数据库使用场景众多，而对应分布式数据库产品功能各异且特点鲜明。如何为不同场景选择最为适合的分布式数据库产品，成为分布式数据库落地前提。下表结合金融行业特点，抽象出若干数据应用场景，形成以事务类、分析类、混合类为代表的三大类五种典型场景。从适用场景、技术架构特征、关键指标、功能维度等多方面对场景进行梳理。一句话总结：“没有最好的产品，只有最合适的产品！”。4） 金融业分布式数据库选型技术要素技术为业务服务的，不能为了使用技术而使用，需要综合考虑成本和收益的平衡。分布式数据库使用场景，应当在数据大规模、高并发、高可用性等场景下有其特有优势。一般的业务场景如果能用单机数据库支撑的尽量用单机库。选择一款分布式数据库，会带来一系列的成本，如应用适配成本、运维成本、硬件成本，这方面后面会赘述。此外，在做上述判断时，还需考虑业务的发展，最好是能判断三年的数据量和交易量的增长变化。在进行分布式选型时，可重点考察下列几个方面：分布式事务分布式架构，自然会带来分布式事务的问题。由于需要跨节点的网络交互，因此较单机事务会有很多损耗。随之带来的是事务处理时间较长、事务期间的锁持有时间也会增加，数据库的并发性和扩展性也会很差。针对单笔事务来说，分布式事务执行效率是肯定会有降低的，分布式带来的更多是整体处理能力的提升。但在设计之初，就应尽量做到业务单元化，将事务控制为本地事务，这可大大提升执行效率。性能由于二阶段提交和各节点之间的网络交互会有性能影响，分布式数据库优势不是单个简单 SQL的性能，但是大数据量的SQL查询，每个节点会将过滤之后的数据集进行反馈，会提升性能，并且分布式数据库的优势是并发，大量的SQL并发也会比单机数据库强大，应用需要做分布式架构的适配，将串行执行机制尽量都改造成并发处理。对于含有需要节点间数据流动的SQL语句的事务，OLTP类的分布式数据库处理效率一般较差，事务处理时间会较长，事务期间的锁持有时间也会增加，数据库的并发性和扩展性也会很差。建议尽量改造存在跨节点数据流动的SQL语句 （主要是多表关联）的事务。 分布式数据库性能是软硬整体架构的保障，不仅在软件、S QL 语句方面做优化，硬件方面也需要重视，包括处理器、内存、网络、磁盘等等，尤其在支撑交易类业务系统时重视对基础设施选型和优化。数据备份分布式数据库一致性保证通过内部时钟机制，所有节点都会遵循一致的时钟，所以备份恢复的增量也是基于时钟，相当于单机数据，但是分布式数据库的备份解决方案最重要标志是否支持物理级的备份，物理级的备份会比逻辑的备份性能吞吐会大很多，还有就是是否支持一些分布式备份方案，比如 S3协议接口，是否支持压缩等功能。分布式数据库基本都具备备份和恢复方案，通常从备节点进行连续备份（全量+日志），恢复的时候制定节点进行恢复到指定时间点，整个过程可配置自动任务自动执行。高可用分布式数据库大多都是基于多数派协议，同城双中心不适合多数派的要求，同城数据级多活建议采用三中心部署，如果同城主备可以采用集群级的异步复制。异地建议采用集群级的 binlog异步复制。建议实例的主备节点设置在同城两个双活数据中心，仲裁节点三机房部署；异地灾备单独启实例与本地实例进行数据库间同步，也可以将本地备份文件T+1恢复到异地灾备。数据一致性NewSQL分布式数据库基本都是通过获取全局时钟时间戳，采用二阶段提交实现一致性，可以实现一致性的保证，分库分表架构对于事务的一致性，需要应用层考虑，比如通过合理的分区键设计来规避。分布式数据库对于跨节点事务目前还是实现的最终一致，对于全局一致性读，一般通过引入类似全局时间戳的组件统一管理全局事务，在数据库选型时可以重点关注厂商对这一块的实现。如果目前暂时无法提供全局一致性读的分布式数据库，对于要依赖分布式事务“中间状态”的业务，优先进行业务改造进行规避，其次通过合理的数据分片设计让其在单节点内完成。其他因素金融行业在数据库选型中，除了需要考虑上述外，还有其他一些因素的考虑。如原有系统的承载能力、是否必须进行选择等。5） 金融业分布式数据库选型非技术要素金融业分布式数据库选型，除了上述技术要素外，还包含如下非技术要素，主要是在成本投入方面：硬件成本一般采用 x86服务器，存储多为本地存储，推荐使用SSD甚至是NVMe SSD，网络一般 采用 万兆网络。在这部分主要成本是取决于集群规模、数据量及数据库自身架构。此外，如果涉及到灾备方案，还需要考虑灾备环境的硬件投入及主备间的专线费用。 此外，考虑很多金融单位现在机房建设空间和能耗有限，可采用配置较高的硬件设备，如基于英特尔 ®至强® 金牌处理器内核的x 86 物理机、配置 英特尔®傲腾™固态盘 等，减少服务器数量、降低耗电量。软件成本主要来自分布式数据库本身的软件采购成本，成本取决于各厂商的内部商业策略。但这部分总体来讲，是较传统数据库产品还是有优势的。此外，这部分还涉及到维保费用，针对分布式数据库来说，相对较新，企业自有能力尚不具备，还是建议购买原厂服务或其他三方公司的服务，降低风险。开发测试成本这部分是指针对数据库更换后，应用需要需要完成的必要的开发测试成本。这部分成本差异很大，跟原有系统实现有较大关系。如果原有系统重度依赖数据库（大量功能是基于数据库自身功能实现的），那么存在的改造量较大。新型分布式数据库的功能，不能与传统数据库做一一对应，很多能力是需要在应用层重构完成。针对这种情况，是建议应用开发遵循数据库标准方式进行（如采用 MySQL作为标准）开发，这样如有改型也很简单。此外，还有一类隐形成本包含在这部分，如果业务比较重要，是需要考虑双发支持或灰度迁移的方式，这会带来一部分工作量。总体来说， 这部分成本是比较高的，可能占整体成本的大部分。运营维护成本这部分成本，包括了为满足更换数据库所带来的数据迁移成本和上线后的日常维护成本。针对前者，可以在应用侧解决或者外采商业软件解决；后者更多是人员管理成本。针对这部分成本，是有个相对较长的投入，且整体成本不少。6） 金融业分布式数据库运维要点分布式数据库，作为较为新兴的基础架构产品，在运维层面有其独有特点。下面结合之前的实践，将运维要点整理如下：软件规划和部署方案分布式数据库组件众多，而且每个组件都有高可用备份，所以在有限数量的服务器下进行组件的分配要尽量考虑达到各个服务器负载的均衡， GTM作为分布式数据库的瓶颈尽量和他们组件分开部署。监控方案监控一般可以采用开源的 zabbix进行定制化开发，当然也可以基grafana+prometheus的方案做监控。但一般大中型金融企业都有一套自己的监控系统，这里需要有个对接适配的过程。此外，由于分布式的多组件特点，在监控指标数量及指标间关联上，与传统数据库差异巨大，是需要监控摸索过程。语句调优因为不同厂商研发的数据库 SQL优化器及执行计划都有所不同，所以要根据不同产品进行学习。天然由于分布式架构带来的复杂度，也会影响到语句的执行效率。比较常见的如数据库访问链路长所带来的的问题、数据分布不均带来的问题及分布式优化器的问题等。备份方案分布式数据库如何做到多节点全局一致性备份也是难点，要做到真正意义上的基于时点恢复，就需要做到分布式环境下每个全局事务的可追溯操作。应急方案因为分布式数据库还处于发展阶段，还不成熟，技术比较复杂，所以生产环境下要制定详细的应急方案，让不了解分布式数据库的同事也能够在出现问题时按照手册操作。DDL变更在分布式架构下， DDL变更是个难点。如果做到全局一致，做到业务无感知，是核心点。不同厂商产品实现能力层次不齐，介于此安排在低峰期操作并做好必要的监控回退。水平扩容分布式架构下，都是支持水平扩容的。一般来说，非数据节点的扩容是相对容易的，对业务也是无感的，但涉及到数据节点的扩容，势必会遇到数据 reshard的问题。建议选择在低峰期，同时控制好扩容粒度。即便如此，仍然建议提前做好容量规划，避免扩容。跨片计算分布式架构下，数据是分布在多个节点中。如果数据计算是可以在本地计算完成，无疑是效率最高的，但完全避免跨片计算是不太现实的。如果发生跨片计算，则不可避免地对上层节点带来压力，要做好相应监控，并争取在根本上避免跨片类计算。5. 总结分布式数据库 ，作为 一种新型数据库 产品架构，正处于蓬勃发展阶段。其 具备 的 数据分片管理、分布式事务、读写分离等关键分布式能力， 能够很好地满足企业在 高性能、大数据量 等多种 业务 场景 。近年来，各国产厂商都在积极推进分布式数据库产品的研发，技术已经逐步成熟 。金融行业，作为数字化转型的先导性行业，对数据基础设施有着更高的要求。分布式数据库的出现，恰好可以满足金融企业迫切需求。随着近些年来，分布式数据库的成熟，并在 金融行业已有成功案例投入生产系统使用。 相信，两者的结合，必定在未来能擦出更多火花，促进金融行业在新时代转型发展。文章来源：https://www.talkwithtrend.com/Article/259665    纯属学习、分享，如有涉及版权，请联系处理。

随着业务的发展与数据量的增长，在存储、计算、安全等方面占据优势的分布式架构数据中心或将成为数据中心未来发展的趋势。与此同时，分布式数据中心带来的建设挑战也为数据中心可持续发展指明方向。分布式数据中心（Distributed Data Center），简称DDC，是利用网络把成千上万台存储服务器连接、组合而成的一台虚拟超级存储服务器，用以完成单台存储服务器无法完成的超大规模问题求解。目前，分布式数据中心在建设过程中面临一些挑战，主要包括网络、存储、计算和安全四个方面。1.在网络方面，多个分布式数据中心间的通信是首要问题。建设时需考虑多区域间如何实现灵活组网与入云连接，但目前各个网络设备供应商间的大二层网络和协议并未统一，故在设备的兼容性上可能存在一定问题。2.在存储方面，如何实现数据协同是一大难题。随着业务高覆盖，各地数据中心协同的重要性日益提高，但受困于距离与规模等难题，各地数据中心间网络宽带无法保证数据实时同步，这对数据的一致性与完整性、业务的连续性造成一定影响。3.在计算方面，对计算资源的管理是重大挑战。数据迁移和灾备建设等难题，要求数据中心日常进行计算资源管理时，不仅要做好常规故障排查，还要做好数据资源的迁移规划和安排工作。4.在安全方面，如何保证数据中心安全性是严峻考验。传统数据中心虽然缺乏灵活性，但它的安全网关足够保证传统数据中心数据存储、处理安全。分布式数据中心的灵活性更高，但目前仍未形成完整统一的安全产品解决方案。来源：今日头条