一、什么是推荐系统不知道大家有没有过这样的经历，当你前脚刚在某电商网站买了一个手机，过两天再打开该电商网站，首页推荐显示的必定有耳机、手机壳、蓝牙音箱等手机配件。如果你买的不是手机，而是一件衣服，那么下次打开电商网站显示的，必定是和衣服搭配的裤子和鞋子等。聪明的你不禁要问，为何电商网站如此强大，竟能提前预知你的偏好，并且给你推荐你可能喜欢的商品？其实在这背后，都离不开那强大的推荐系统。什么是推荐系统？首先我们来看看维基百科上的定义：推荐系统是一种信息过滤系统，可以根据用户历史行为预测用户对物品的“评分”或“偏好”。简单来说，如果你是一个电子发烧友，那么系统肯定会给你推荐各种新鲜出炉的3C产品，如果你是一个coder，那么你的页面肯定充满各种编程大全的书籍。推荐系统近年来非常流行，应用于各行各业，推荐的对象包括：电影、音乐、新闻、书籍、学术论文、搜索查询、分众分类、电商购物和游戏业务等。二、推荐系统的架构了解了什么是推荐系统之后，接下来我们继续介绍下推荐系统的架构，以游戏行业为例，一个典型的游戏业务的推荐系统架构设计如下： 推荐系统主要由3部分组成，分别是：行为日志收集、特征生产和特征消费。 01.行为日志大数据业务通过收集用户的行为日志，分析获得用户画像，并且将这些用户画像保存在分布式文件系统HDFS中。02.特征生产工程业务负责为大数据业务提供一套接口调用，主要是“灌库”，即定时或按一定逻辑把HDFS中的用户画像加工成特征，灌入工程业务负责的“KV存储”。 03.特征消费工程业务团队还负责将算法团队的推荐模型进行工程落地，他们开发线上推理组件，从KV存储中提取特征数据、分析计算，最终得出推荐结论，展示给用户。 三、推荐系统的存储痛点上一节中我们介绍了游戏行业中推荐系统的架构，这也是推荐系统的一个典型架构。从架构图可以看出，KV存储在整套链路中，承载着重要的承上启下作用。然而，推荐系统中的KV存储却存在着两个大的痛点，第一个是成本高，第二个是扩容慢。 01.成本高首先第一个是成本高的问题。通常我们搭建KV存储的首选是选择自建一个开源Redis集群作为KV存储系统。一方面，开源Redis的数据全部放在内存中，众所周知内存的存储成本非常昂贵，只适用于存储少量数据，如果数据量大，存储成本将成为企业的负担；另一方面，开源Redis在进行AOF文件重写的过程中存在fork机制，导致开源Redis在AOF文件重写时，其内存利用率只有50%，这就进一步使增加了开源Redis的内存使用成本。02.扩容慢除了成本比较高，开源Redis还存在扩容慢的问题，在自建的开源Redis集群中，随着业务增长，KV存储的容量不得不进行扩容。但由于原生Redis本身的架构特点，在扩容过程中难免要发生key的跨slot迁移，如下图所示，跨slot迁移需要耗时很久并且业务受影响时间长。 四、为什么推荐GaussDB(for Redis)知道了推荐系统的痛点所在，该如何解决呢？究其根本是降本增效，而GaussDB(for Redis)可以说是为解决这些问题而生。01.降本GaussDB(for Redis)从两个方面降低KV数据的存储成本： 第一个方面，GaussDB(for Redis)的所有数据全部落在存储，相比开源Redis数据存放在内存中，其成本降低了75%~90%，形成极大的价格优势。举个例子，一个512GB的开源Redis集群，其成本几乎要5w/月，而相同规格的实例，如果替换成GaussDB(for Redis)，其成本节约40%以上，几乎节省了一个人力成本在里面。下面这张表格是不同层级存储器之间的成本对比图。 另一方面，在推荐系统中，KV数据主要存储的是用户画像的信息，这些信息基本上都是经过Protobuf序列化后的信息，而GaussDB(for Redis)自带的数据压缩功能，可以对序列化后的信息进行高压缩比的压缩，实际占用空间仅为开源Redis的50%左右，这又进一步降低了KV数据的存储成本。 02.增效除了降本，另一方面就是增效了。众所周知，开源Redis的架构中，如下图所示，其存储和计算是不分离的，这就导致节点进行扩容的时候，会发生分片的迁移，从而导致业务会受到影响。GaussDB(for Redis)为了解决这个问题，采用了存算分离的架构，如下图所示：在存算分离的架构下，底层数据可以被任意上层计算节点访问，扩容过程不发生数据拷贝搬迁，速度极快；同时还做到分钟级节点扩容，业务秒级感知；存储扩容业务0感知。无论是扩节点还是扩存储容量，对业务的影响几乎为0。五、总结本文简单介绍了推荐系统是什么，并以游戏业务为例，阐明了推荐系统的架构和存在的存储痛点，同时GaussDB(for Redis)是如何解决这些存储痛点的。在大数据时代，推荐系统的应用场景将会越来越多，作为推荐系统的数据存储，GaussDB(for Redis)完美弥补了开源Redis的短板，能够为推荐系统提供强有力的技术支撑。

场景版本号基线发布时间文档地址软件地址(企业网)发布历史独立软件销售场景(线下物理机)8.2.12023.07.12企业网运营商8.2.1.3-8.1.3(推荐)2022.05.30企业网运营商8.1.3.32022.11.30更新到8.1.3.32022.07.20更新到8.1.3.22022.06.16更新到8.1.3.18.1.12021.06.30企业网运营商8.1.1.32022.05.30更新到8.1.1.32022.03.30更新到8.1.1.28.0.02020.03.15企业网运营商8.0.0.138.0.0其他补丁2022.07.08更新到8.0.0.132022.03.16更新到8.0.0.122021.07.09更新到8.0.0.96.5.1及之前--企业网运营商6.5.1.8--混合云场景8.1.3.331(最新)2024.04.30企业网运营商8.1.3.331配套混合云HCS 8.3.18.1.3.3232023.09.30企业网运营商8.1.3.323配套混合云HCS 8.3.08.1.3.3102023.03.30企业网运营商8.1.3.310配套混合云HCS 8.2.18.1.3.2002022.09.30企业网运营商8.1.3.200配套混合云HCS 8.2.08.1.1.500(推荐)2022.05.30企业网运营商8.1.1.5008.1.1.300配套混合云HCS 8.1.1：2022.05.30发布8.1.1.500租户镜像2022.03.30发布8.1.1.300租户镜像8.1.1.52021.10.30企业网运营商8.1.1.5配套混合云HCS 8.1.08.1.0.1012021.04.30企业网运营商8.1.0.101配套混合云HCS 8.0.3HCSO场景8.1.3.200(推荐)2022.11.07企业网运营商8.1.3.200配套HCSO 22.9.08.1.1.5002022.05.30企业网运营商8.1.1.500配套HCSO 22.3.08.1.1.2022022.03.03企业网运营商8.1.1.202配套HCSO 21.12.0公有云场景8.3.02024.4.17中国站国际站欧洲站产品首页-8.1.3(推荐版)2022.04.152023.03.09更新到8.1.3.3102022.12.19更新到8.1.3.3002022.10.31更新到8.1.3.2002022.08.23更新到8.1.3.1102022.06.20更新到8.1.3.1008.2.02022.11.282023.01.14更新到8.2.0.1008.1.12021.07.302022.06.20更新到8.1.1.5002022.04.15更新到8.1.1.3002022.03.30更新到8.1.1.205

如图，改造算子中的actual time的两个时间代表什么，网上有说是1、执行改算子返回第一行时间、所有行时间，如果是这样那就是说下面执行这个算子需要了24s？2、执行改算子的开始时间、结束时间，如果是这样那就是说下面执行这个算子只需要1~2s？

DWS版本：8.1.1MRS：3.0.2Flink：1.12.0Flink读取kafka数据，sink到dws里面。程序正常运行12小时左右就报错。但是超时的参数都配置的没问题。statement_timeout=0;session_timeout=0;这俩参数都没问题。但是不知道为什么就会中断了？

为何 DWS to_date(xxx,'yyyymmdd')关联比 cast(xxx as date) 关联效率慢 ？关联基表数据量 2亿+，使用 to_date 转换关联运行4小时未出结果，使用 cast 则很快出结果，能给解答一下为何？

【摘要】 GaussDB(for Redis)推出双活方案，助力全球化业务部署，为您的数据资产保驾护航！本文分享自华为云社区《华为云GaussDB(for Redis)揭秘第22期：拔掉电源会怎样？GaussDB(for Redis)双活让你有备无患》，作者： 高斯Redis官方博客。一、GaussDB(for Redis)双活方案介绍       数据库系统是业务稳定运行的基石，其重要性不言而喻。然而，现实世界存在着的如断电、火灾，甚至是更小概率的地震等突发灾害，这些不稳定因素都会威胁到公司核心业务的连续性。       华为云GaussDB(for Redis)是采用存算分离架构的企业级KV数据库，使用方式上完全兼容开源Redis，同时稳定性全面超越开源Redis，此外还提供数据高可靠存储、秒级在线扩容等企业级能力。       在上半年的故障演练中，作为需求方的某内部重要业务部门对华为云KV数据库GaussDB(for Redis)进行了一系列严苛的可靠性测试。其中就包括模拟实例级断电，评测GaussDB(for Redis)的双活容灾能力。在故障演练中，GaussDB(for Redis)顺利通过测试，满足了业务部门对RTO和RPO等指标的严格要求。GaussDB(for Redis)支持双活容灾，即在两个实例之间建立数据同步链路，其中主实例支持读写，备实例只读。适用于以下两类业务场景：       1.    灾备系统：核心业务生产环境可靠性要求高，例如金融服务等。       2.    实例级读写分离：有超高并发访问诉求，例如广告竞价、推荐系统等。       在后续规划中，GaussDB(for Redis)还将进一步支持双主实例模式，实现双主双写，敬请期待。下面让我们来深入了解GaussDB(for Redis)的双活能力。二、GaussDB(for Redis)双活原理及评估指标1) 架构解析       常见的容灾方案有以下2种：同城容灾：由于距离近，通信质量好，比较容易实现数据零丢失。一般用于防范火灾、供电故障等人为破坏引起的灾难。异地容灾：由于主备数据中心之间距离远，通常会有少量的数据丢失,而异地灾备可以防范火灾、水灾、建筑物破坏、地震、战争等可能遇到的风险隐患，保障业务的连续性。       GaussDB(for Redis)双活方案支持同城容灾和异地容灾，下图展示了其技术原理：       可以看出，与开源Redis那种简单的命令转发不同，GaussDB(for Redis)的双活方案是基于WAL日志的数据同步，原理上更类似于MySQL数据库。在双活架构中，RsyncServer进程负责数据的全量和增量同步。数据同步链路采用华为云内部高速网络，同Region内仅毫秒级延迟。       GaussDB(for Redis)的双活功能有以下企业级特性：全量同步：支持秒级快照，且不影响原有集群的正常读写，发送速度快增量同步：监听日志写入变更，实时同步最新数据，毫秒级延迟key保序：主备实例采用多线程异步并发模式发送数据，按Key保序可靠传输：利用wal日志序号的单调递增特性，实现滑窗机制确保可靠传输高效传输：日志迭代、网络发送、DB增删监听等任务采用Reactor事件管理，全流程pipeline异常重传：解决网络抖动导致的丢包或延迟现象断点续传：每个DB持久化保存其应答过的日志序号，如发生宕机、网络隔离、进程重启等情况，可从该序号位置进行续传防止回流：同步到对端流量做特殊标记，防止回流到源端2) 技术指标       从技术上看，业界衡量容灾系统有两个主要指标：RPO：最多可能丢失数据的时长。RTO：从灾难发生到整个系统恢复正常所需要的最大时长。       一般而言，容灾系统能够提供较好的RTO和RPO指标。国际通用的容灾系统的评审标准SHARE 78（7个层次、8个原则），可以作为广大用户衡量和选择容灾解决方案的指标。      目前，在大部分场景下，GaussDB(for Redis)灾备方案位于6级，即只有在极端场景下才会丢失少量数据。3) 优势总结       根据前期市场调研，有些客户的业务场景基于开源Redis搭建集群级的灾备系统，从技术原理上评估可靠性很低，违背了灾备的初衷。与之相比，GaussDB(for Redis)提供企业级可靠的双活方案，优势如下：三、GaussDB(for Redis)双活搭建步骤       登录GaussDB NoSQL控制台，您可以很方便地搭建GaussDB(for Redis)双活系统：       1.    点击“购买数据库实例”，创建2个GaussDB(for Redis)实例（主、备），建议规格保持相同。       2.    进行网络配置，详细指导：https://support.huaweicloud.com/redisug-nosql/nosql_10_0502.html       3.    选中期望的主实例，如图操作，开始搭建双活关系：       4.    在“搭建双活关系”页面，选中期望的备实例，点击确定，即开始双活系统搭建。              注意：一旦双活系统开始搭建，备实例数据将被清空，请谨慎操作。        双活关系搭建完成后，除了用于容灾之外，其备实例可提供读服务，可以有效分担主实例的读压力。四、GaussDB(for Redis)双活技术演进        当前双活方案中，备实例在运行期间仅提供读服务，如果两个数据中心能同时提供写服务，那么将极大地提高资源利用率。当灾难发生时，双活系统提供极致的RPO和RTO，从而最大程度保障业务连续性。它具有资源利用率高的特点，支持数据冲突解决等功能。目前，GaussDB(for Redis)的双活多写功能已经在开发阶段，不久之后即将上线，请大家拭目以待。五、附录本文作者：华为云数据库GaussDB(for Redis)团队杭州/西安/深圳简历投递：yuwenlong4@huawei.com更多产品信息，欢迎访问官方博客：bbs.huaweicloud.com/blogs/248875

【功能模块】DWS数据库【操作步骤&问题现象】1、需用Navicat等工具连接dws数据库2、内网：10.110.60.178      公网：112.46.84.66【截图信息】【日志信息】（可选，上传日志内容或者附件）王斌国/18629429514/wangbinguo@chinasoftinc.com

数字时代，海量的信息让人应接不暇。各行各业都在探索如何从庞杂的数据之中，提取深度价值，更好的为用户服务。金融行业也不例外，如何利用数字技术，为客户提供更智能便捷的金融服务，以及为用户提供更优质高效的服务体验，已成为了银行业当下热门的话题。在此背景下，招商银行携手华为，依托华为云数据仓库强大的存储、计算能力，通过对所有业务数据进行整合分析，实现精准的信息抽取、加工和分发，让金融服务“想你所想”，为用户筑起云端VIP通道。数据仓库踏上“筋斗云”伴随着客户数、交易量和业务种类的逐年增加，招商银行的数据仓库平台面临着容量、性能、安全性等方面的多重挑战，亟需一个安全高效的信息系统，来保障各业务环节的稳定运行，支撑银行整体业务的快速发展。 在此背景下，招商银行决定对原数据仓库进行云化升级，打造高性能、高可用、支持高扩展的分布式数据库，并通过全面选型，最终确定以华为云GaussDB(DWS)一站式全场景云数据仓库作为新一代平台，搭建全球首个基于华为云底座的超大规模金融核心数仓。 GaussDB(DWS)为招商银行数据仓库提供了GB-PB级的数据分析能力、多模分析和实时处理能力，有力支撑其超大数据量计算和超大并发查询场景，同时基于公有云部署形态的云数仓，支撑招商银行业务的持续升级和灵活拓展。具体来讲，招商银行云数仓构建于华为云底座之上，可以选择通过增加集群节点、增加计算节点、增加存储节点等灵活的方案实现容量和性能的快速提升，从而保障海量数据的快速、准确处理。 招商银行持续打造一朵“招行云”和两个中台（数据中台及技术中台）的开放基础架构，打破系统竖井与数据孤岛，持续沉淀企业级能力，最大化释放数据价值。踏上GaussDB(DWS)的“筋斗云”，招商银行数据应用全链路运行时长缩短15%以上，全行用数门槛进一步降低，有效支撑了“人人用数”大数据发展战略落地。此外，招商银行还与华为共同设立了联合创新实验室，不断深挖金融行业的应用场景，在备份恢复、细粒度容灾、集群间高速互联互通、快速温备等领域取得了技术突破。目前，云数仓备份速度已达150T/小时，实现了多集群的统一逻辑访问，极大提升了生产效率。金融业“云启”下一程招商银行运用金融科技对客户服务、经营模式和组织架构开展的数字化转型，除了华为云GaussDB(DWS)，华为云FusionInsight MRS数据湖等性能强劲的IT基础设施，其还在网络管理过程中采用了多项华为的智能化解决方案，实现了运维管理效率的提升。例如，招商银行基于华为 iMasterNCE 自动驾驶网络管理控制系统配合 ZTP 零配置上线功能，实现了整体网络零配置上线，以及 Overlay 配置自动化下发。不仅做到业务配置的分钟级下发，将基础网络的交付从过去的两周缩短至 3 天，同时极大减轻了在资源交付阶段的压力；招行云数据中心通过引入华为 iMaster NCEFabricInsight网络智能分析器，实现基于大数据和 AI 算法的故障自动识别、智能定位和潜在风险提前预测。在数字经济的浪潮下，越来越多像招商银行一样的金融机构紧跟时代步伐，加速开展金融科技布局，通过云化转型、IT架构升级等方式提升数字化经营能力，为高质量发展积蓄新动能。在这个过程中，数字化、智能化的应用与作用也日益得到普及和凸显。7月20日至22日，第十届华为智慧金融峰会将于新加坡举办，峰会以“全联接、全智能，共建绿色数智金融”为主题，汇集全球金融行业领军人物、意见领袖、学术大咖和创新践行者，共议未来金融行业发展趋势，探寻如何共建绿色数智金融，期待您的参与和关注！

问题有两个一、sql在执行Streaming(type: REDISTRIBUTE)（数据重分布）之前先进行HashAggregate是否能提升性能？根据网上的说法是重分布之前自己会先HashAggregate一次减少需要重分布的数据量，这样可以提升性能，但这边很多sql在执行Streaming(type: REDISTRIBUTE)之前都没有先HashAggregate导致重分布的数据量大导致性能查。二、如果sql在执行Streaming(type: REDISTRIBUTE)前自己不先HashAggregate，那如何手动调优使sql能在在执行Streaming(type: REDISTRIBUTE)之前先进行HashAggregate一次？执行计划如下

问题有两个一、sql在执行Streaming(type: REDISTRIBUTE)（数据重分布）之前先进行HashAggregate是否能提升性能？根据网上的说法是重分布之前自己会先HashAggregate一次减少需要重分布的数据量，这样可以提升性能，但这边很多sql在执行Streaming(type: REDISTRIBUTE)之前都没有先HashAggregate导致重分布的数据量大导致性能查。二、如果sql在执行Streaming(type: REDISTRIBUTE)前自己不先HashAggregate，那如何手动调优使sql能在在执行Streaming(type: REDISTRIBUTE)之前先进行HashAggregate一次？执行计划如下

【功能模块】【操作步骤&问题现象】1、2、【截图信息】【日志信息】（可选，上传日志内容或者附件）

【功能模块】Oracle的months_between函数迁移，在论坛下面连接找了一个自定义函数，效率非常慢。数据量很小，77万条记录。脚本没有加上这个函数，只需要3秒钟就能跑完，加上这个函数一直跑不出来，然后等待了一次，发下花了47分钟。后面反复验证，就是这个函数的问题。因为通过单一变量原则，只要一加上这个函数，就跑不动。一去掉就是3秒钟出结果。请问下有没有其他的方式，效率没问题有的。https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=122098&page=1#pid1500638CREATE OR REPLACE FUNCTION MONTHS_BETWEEN(date, date) RETURNS double precision    AS $$    SELECT   CASE    --WHEN EXTRACT(day from $1) = EXTRACT(day FROM $2) THEN   /* the two dates have the same day component */       -- EXTRACT(year FROM $1) * 12 + EXTRACT(month FROM $1) - EXTRACT(year FROM $2) * 12 - EXTRACT(month FROM $2)    WHEN (EXTRACT(day FROM $1) = EXTRACT(day FROM (date_trunc('MONTH', $1) + INTERVAL '1 MONTH - 1 day'))) and    (EXTRACT(day FROM $2) = EXTRACT(day FROM (date_trunc('MONTH', $2) + INTERVAL '1 MONTH - 1 day'))) THEN /* both the last day of the month */        EXTRACT(year FROM $1) * 12 + EXTRACT(month FROM $1) - EXTRACT(year FROM $2) * 12 - EXTRACT(month FROM $2)    when (EXTRACT(day FROM $1) = EXTRACT(day FROM (date_trunc('MONTH', $1) + INTERVAL '1 MONTH - 1 day'))) and    (EXTRACT(day FROM $2) <> EXTRACT(day FROM (date_trunc('MONTH', $2) + INTERVAL '1 MONTH - 1 day'))) then         (EXTRACT(year FROM $1)-EXTRACT(year FROM $2))*12+         EXTRACT(month FROM $1)-EXTRACT(month FROM $2)+1-EXTRACT(day FROM $2)/31    when (EXTRACT(day FROM $1) <> EXTRACT(day FROM (date_trunc('MONTH', $1) + INTERVAL '1 MONTH - 1 day'))) and    (EXTRACT(day FROM $2) = EXTRACT(day FROM (date_trunc('MONTH', $2) + INTERVAL '1 MONTH - 1 day'))) then         (EXTRACT(year FROM $1)-EXTRACT(year FROM $2))*12+         EXTRACT(month FROM $1)-EXTRACT(month FROM $2)-1+ EXTRACT(day FROM $1)/31         ELSE        (EXTRACT(year FROM $1)-EXTRACT(year FROM $2))*12+         EXTRACT(month FROM $1)-EXTRACT(month FROM $2)+         (EXTRACT(day FROM $1)-EXTRACT(day FROM $2))/31END

【DWS产品】存储选型，HDD硬盘与SSD硬盘应该怎么选？某客户打算使用DWS产品，对于选择HDD硬盘还是SSD硬盘比较犹豫？ 客户出于数据安全的考虑，担心SSD硬盘故障率高以及寿命短？专家怎么看？

【DWS产品】【建表功能】能否通过登录节点，直连DN，在单个DN上创建表？

【DWS产品】【性能】DWS处理数据时为什么不使用缓存提高性能？