大数据时代的到来，颠覆了传统业态的运作模式，激发出新的生产潜能。数据成为重要的生产要素，是信息的载体，数据间的流动也潜藏着更高阶维度的价值信息。对于数据控制者和数据处理者而言，如何最大化数据流动的价值，是数据挖掘的初衷和意义。然而，一系列信息泄露事件的曝光，使得数据安全越来越受到广泛的关注。各国各地区逐步建立健全和完善数据安全与隐私保护相关法律法规，提供用户隐私保护的法律保障。如何加强技术层面的数据安全和隐私保护，对数据仓库产品本身提出更多的功能要求，也是数据安全建设最行之有效的办法。数据脱敏，顾名思义，是屏蔽敏感数据，对某些敏感信息（比如，身份证号、手机号、卡号、客户姓名、客户地址、邮箱地址、薪资等等 ）通过脱敏规则进行数据的变形，实现隐私数据的可靠保护。业界常见的脱敏规则有，替换、重排、加密、截断、掩码，用户也可以根据期望的脱敏算法自定义脱敏规则。通常，良好的数据脱敏实施，需要遵循如下两个原则，第一，尽可能地为脱敏后的应用，保留脱敏前的有意义信息；第二，最大程度地防止黑客进行破解。数据脱敏分为静态数据脱敏和动态数据脱敏。静态数据脱敏，是数据的“搬移并仿真替换”，是将数据抽取进行脱敏处理后，下发给下游环节，随意取用和读写的，脱敏后数据与生产环境相隔离，满足业务需求的同时保障生产数据库的安全。动态数据脱敏，在访问敏感数据的同时实时进行脱敏处理，可以为不同角色、不同权限、不同数据类型执行不同的脱敏方案，从而确保返回的数据可用而安全。

执行安装集群报错：集群定义已保存，但创建集群未完成，请修改后重试。详细错误信息如下：Failed to verify nodes because Failed to verify oms nodes. because they are null or not avaliable.日志附件已经上传

线下8.1.1.5版本在使用用户空间时怎么快速定位单dn中的那个schema下的那些表倾斜引起空间超出？

线下8.1.1.5版本管理员用户的连接数也在max_active_statements的限制下吗？怎么设置不在max_active_statements连接数内？

create temp table xxxx ; 临时表数据存储在哪里，如果临时表数据量够大，是先内存后磁盘吗？如果是，是哪个参数控制先存入到内存的大小，超过该参数大小后，数据落盘？

一、背景客户现场执行一个sqldelete from aa.bb where data<’2024-07-11’;每一次都报错，报错为Lock wait timeout:thread xxx on node dn_600x_600x wating for shareLock on transaction xxAfter xx ms.其实这是一个很明显的报错，但当时我被另外一个报错误导了deadlock detected当时脑子都是死锁怎么这么样二、排查思路先查询同名活跃会话，并发更新了一条insert，记下该语句的pid后查询了锁视图pg_locks，但锁视图不太好看，同时视图没有当时delete的pid后查询死锁视图pgxc_deadlock,这个就非常明显，他很明显出现了delete原语句，同时出现了insert into aa.bb (a ,b …) values($1 ,$2…) on duplicate key update a=value(a),b=value()…可以确定为，并发insert和delete到这一张表，所以报了锁错误。但杀掉了这两条insert后，查看活跃会话和锁视图，依旧出现了insert语句。后delete语句执行还是失败了，报相同的sharelocak。询问业务后得知，因为insert为flink并发插入，随时可能进来，无法规避insert。        1、但当时客户问：insert 和delete有个前后关系，不是应该等delete执行完吗？为什么还是锁失败了。当时脑子里都是锁冲突，没转过来。后经过提醒，脑子就清醒了，原因为，锁超时。Insert等delete的锁，等到超时报错退出。后跟客户解释清楚了这个原理。2、客户表示理解，并提出新的疑问：为什么昨天成功，今天失败呢。原因为，delete和insert同时并发更新到同一条语句。因业务老师认为，上游写入数据只写入今天，但他删数据是昨天的数据，故不可能发生冲突。经过我们实际查询数据后，发现昨天的数据一直在增长，即上游一直对表进行昨天的数据插入，故删除一直在等锁。经过和客户沟通，客户表示理解，这个为上游业务的问题，他们和上游沟通。至此，结束。共勉：其实排查不难，但是由于对原理理解并未透彻，客户已提出疑问就卡住了。还得加强学习。

三、缓存服务、自动物化系统及优化效果在快手的湖仓一体架构中，缓存服务扮演着至关重要的角色。缓存服务分为元数据缓存和数据缓存两大部分，旨在提升数据访问的性能和稳定性。元数据缓存包括库、表、列、分区和文件等元信息，而数据缓存则以文件形式存储在缓存系统中，提供本地化的数据访问性能。快手自主研发的Meta Server作为统一的元数据服务，负责监听Hive Metastore中的Schema变化、Alluxio中的缓存变化等，并将这些信息持久化到后端的Meta Store中。Meta Server还会定期将元数据推送给Doris FE的Catalog中，并通过元数据校验服务保证数据的一致性。此外，快手还结合Alluxio的缓存能力，对分区信息缓存策略进行了改造，实现了查询引擎（Doris）、元数据服务（Hive Metastore）、数据缓存服务（Alluxio）三方的高效联动。数据缓存服务方面，快手采用了基于Alluxio的外置数据缓存服务，提供HDFS兼容的API，使得Doris能够方便地访问Alluxio文件系统中的文件。为了减少数据访问延迟，快手还开发了缓存预热功能，使得预热后的数据存储在Alluxio中，显著提高了查询响应速度。缓存服务的3个图： 图一图二图三除了缓存服务，快手还开发了自动物化服务，以实现消费驱动生产的数据加工模式。在这种模式下，数据工程师将数据直接交付至DWS层，而ADS层的物化视图生产逻辑则由计算引擎托管，从而降低了数据工程师的理解成本。自动物化服务通过物化视图的自动发现、生产和消费，显著提升了查询效率。物化视图的发现可以通过专家规则或分析历史查询来实现，而物化生产则由作业调度平台根据基表数据变化自动调度。物化消费阶段，Doris会从Meta Store同步物化视图信息，并在查询时进行透明改写，以实现查询加速。物化图：这些优化措施的实施，使得快手在处理海量数据时，能够实现更快的数据模型交付和查询响应。在实际测试中，物化处理后的数据行数压缩至少达到11倍，而查询性能相比物化前提升了至少6倍。这些成果不仅加快了数据模型的交付速度，还显著提升了查询效率，为快手的数据分析和业务决策提供了强有力的支持。快手的湖仓一体架构优化实践表明，通过技术创新和系统优化，可以显著提升大数据系统的处理能力和查询性能。这些经验对于其他企业在构建和优化自己的数据平台时，也具有重要的参考价值。未来，快手将继续探索Doris在湖仓一体架构下的应用实践，以进一步提升数据处理效率和查询性能。原文地址：快手：从 Clickhouse 到 Apache Doris，实现湖仓分离向湖仓一体架构升级cid:link_0

二、引入Apache Doris实现湖仓一体架构面对原有湖仓分离架构带来的挑战，快手决定引入Apache Doris，以实现湖仓一体的架构升级。Apache Doris作为一个实时数据仓库，不仅提供了极致的分析性能，还通过其物化视图改写能力和自动物化服务，为快手的数据查询和治理带来了显著的改进。Apache Doris的引入，使得快手能够直接在数据湖上进行数据分析，无需复杂的数据传输过程，从而避免了数据传输中可能出现的问题。Doris的分布式SQL查询引擎对Parquet、ORC等文件格式进行了深度适配，结合灵活的缓存策略和物化视图能力，提供了高吞吐和低延迟的数据分析能力。此外，Doris支持多源联邦分析，通过丰富的数据源连接器，可以对Hive、Iceberg、Hudi等异构数据源进行统一的元数据管理和映射，实现标准SQL语言的联邦分析。快手基于Apache Doris构建了新的湖仓一体分析平台，该平台从下至上主要分为数据加工层、数据缓存层和数据查询层。数据加工层负责将数据源数据同步到数据湖仓，并在湖仓系统中完成从ODS层到DWS层的加工处理。数据缓存层通过Alluxio提供高性能的数据缓存访问能力，同时元数据也缓存到元数据管理服务中，提供统一的、稳定的元数据访问服务。数据查询层则基于Apache Doris提供对ADS层数据的高性能查询服务。新架构：为了进一步提升分析平台的智能化和自动化水平，快手开发了查询路由服务和自动物化服务。查询路由服务能够根据查询的数据扫描量自动将超大查询路由到Spark引擎，避免大查询占用过多的Doris资源。自动物化服务则提供DWS层到ADS层的按需自动化加工，智能选择排序字段、哈希字段以及更合理的物化，实现对复杂查询或高优看板数据的智能查询加速。通过这些升级和优化，快手的OLAP系统在数据查询性能和数据治理方面取得了显著的提升。统一存储和简化的数据链路降低了数据维护和存储的成本，同时提升了数据时效性。Apache Doris的高性能计算引擎和物化视图透明改写能力，以及基于代价的查询优化器，满足了不同数据分析场景下的查询加速需求。此外，Doris的物化视图改写能力和自动物化服务也使得在ADS层进行视图建模更加方便，对业务层屏蔽了复杂的底层实现逻辑，提供了更灵活的数据治理方式。这些改进不仅提升了快手的数据服务能力，也为公司的业务发展提供了强有力的数据支持。

一、快手的OLAP系统及其挑战快手的OLAP系统是公司数据服务的核心，它为包括ToB系统和内部系统在内的多个业务场景提供数据支持。ToB系统包括商业化报表引擎、商业化DMP、商业化磁力金牛和电商选品等，而内部系统则涵盖了KwaiBI、春节/活动大屏、APP分析、数据同步、用户理解中心、APM、CDN监控和雷达监控系统等。这些系统每天需要处理近10亿的查询请求，对数据处理和查询性能提出了极高的要求。最初，快手的OLAP系统采用的是湖仓分离架构，其中离线数据湖使用Hive和Hudi作为核心引擎，而实时数仓则依赖ClickHouse。数据源非常丰富，包括结构化、半结构化和非结构化数据，这些数据经过ODS、DWD、DWS和ADS层的处理后，同步至实时数仓，再由数仓提供BI、报表和查询等服务。架构图：尽管这套架构在快手内部稳定运行了相当长的时间，但随着业务需求的变化和数据量的不断增长，湖仓分离架构的问题逐渐显现。首先，数据冗余存储问题突出，虽然将数据入仓到ClickHouse能够提高查询性能，但同时也导致了数据的冗余存储，这不仅影响了数据就绪时间，也降低了存储效率。其次，资源占用问题严重，数据同步到ClickHouse的过程占用了大量集群资源，包括数据同步系统的资源消耗和数据写入后的Compaction计算资源消耗。在高并发查询时，这种并行读写带来的资源抢占问题尤为显著，可能影响其他查询任务的执行效率和集群的整体性能。此外，数据治理变得复杂，数据工程师需要投入大量人力建立ADS层模型，以支持数据导入ClickHouse的工作，并需要额外的精力维护导入任务。当报表看板下线后，对应的ADS层和数据导入任务仍在运行，造成计算和存储资源的不必要浪费，这增加了运维管理的复杂度。最后，随着ClickHouse在业务中使用的深入，查询性能出现了瓶颈，排序字段、二级索引、物化视图以及哈希字段的选择和创建对ClickHouse查询性能有显著影响，但由于ClickHouse的语言和系统适配性限制，开发人员的学习及操作门槛较高，查询调优的难度增加。这些问题促使快手开始寻求新的解决方案，以期通过技术升级来解决这些挑战。原文地址：快手：从 Clickhouse 到 Apache Doris，实现湖仓分离向湖仓一体架构升级cid:link_0

问题现象ECF 安装Common MySQL 失败DWS_安装GaussDB 失败定位信息界面查看日志，有如下关键信息ERROR:check the etcd node xx.xx.xx.xx:22379 healthy is fail从hcc后台curl 对应ip端口网络不通xx.xx.xx.xx:22379解决方案联系ETCD检查etcd服务是否正常，修复后重试

在当今数据驱动的时代，高效的数据存储和处理解决方案至关重要。今天，我们将深入探讨 GaussDB (DWS)，一款功能强大的分布式数据仓库。GaussDB (DWS) 是华为推出的一款高性能、高可靠、高安全的分布式数据仓库产品。它旨在满足企业对大规模数据存储、分析和处理的需求，为企业提供强大的数据支持。一、强大的性能GaussDB (DWS) 具有卓越的性能表现。它采用了分布式架构，可以轻松处理大规模数据。通过并行计算和优化的查询处理算法，GaussDB (DWS) 能够快速响应复杂的查询请求，大大提高了数据处理的效率。同时，GaussDB (DWS) 还支持多种数据存储格式和压缩算法，可以有效地节省存储空间，提高数据存储的密度。这使得企业能够在有限的硬件资源下存储更多的数据，为数据分析提供更丰富的数据源。二、高可靠性在企业级应用中，数据的可靠性至关重要。GaussDB (DWS) 提供了多种高可靠性机制，确保数据的安全和稳定。它采用了多副本存储技术，将数据存储在多个节点上，即使某个节点出现故障，也不会影响数据的可用性。此外，GaussDB (DWS) 还支持数据备份和恢复功能，可以在数据丢失或损坏时快速恢复数据，保证业务的连续性。三、高安全性数据安全是企业关注的重点之一。GaussDB (DWS) 提供了全面的安全保障措施，包括用户认证、授权、数据加密等。它支持多种用户认证方式，如密码认证、证书认证等，确保只有合法的用户才能访问数据。同时，GaussDB (DWS) 还提供了细粒度的授权机制，可以对不同的用户和角色进行不同级别的授权，控制用户对数据的访问权限。此外，GaussDB (DWS) 还支持数据加密功能，可以对敏感数据进行加密存储，防止数据泄露。四、丰富的功能GaussDB (DWS) 提供了丰富的功能，满足企业对数据分析的各种需求。它支持 SQL 标准语法，方便用户进行数据查询和分析。同时，GaussDB (DWS) 还提供了多种数据分析工具，如数据挖掘、报表生成等，帮助用户更好地理解和利用数据。此外，GaussDB (DWS) 还支持与其他数据源的集成，可以方便地从各种数据源中抽取数据，进行统一的存储和分析。五、应用场景GaussDB (DWS) 广泛应用于各个行业，如金融、电信、电商等。在金融行业，GaussDB (DWS) 可以用于风险评估、反欺诈分析等场景，帮助金融机构更好地管理风险。在电信行业，GaussDB (DWS) 可以用于用户行为分析、网络优化等场景，提高电信运营商的服务质量。在电商行业，GaussDB (DWS) 可以用于销售数据分析、用户画像等场景，帮助电商企业更好地了解用户需求，提高销售业绩。

问题现象：语句从第3次开始执行性能慢：前两次执行快，第三次及以后执行慢（存储过程入参完全相同，中间数据未变化，未发生过重新analyze）前两次执行：500ms第三次及以后执行时间：13s定位过程：（1）打开存储过程子语句开关enable_track_record_subsql，记录子语句的执行计划（2）对比执行计划发现，执行计划出现变化，且第三次以后的执行计划中，入参被替换成了$1  $2（3）而前两次计划中入参为实际值：（4）因此初步判断执行计划和性能差异与此有关，该变化是custom plan和generic plan差异导致原理说明：对于同一个语句反复执行的场景，优化器会尝试生成generic plan，省去每次生成计划的开销，缺点是部分参数场景下执行计划非最优，可能性能较差。而custom plan是指在生成计划时，每次都会按照参数值生成具体的执行计划，缺点是每次执行前都需要重新生成计划，带来的优点是每个入参的执行性能都较好解决方法：语句级设置参数：set plan_cache_mode = 'force_custom_plan'，强制指定生成custom plan

咨询下GaussDB 200查看表膨胀率可以通过哪些方式，另外想知道GaussDB 200的收缩方式是vacuum嘛？gaussdb是所有的表都能收缩吗？

【问题描述】集群状态异常告警【问题影响】无（务必确认该集群已删除，再做操作）【问题版本】所有版本适用 【定位步骤】1、OC和console界面一直有已删除集群上报集群状态异常告警（后台删除集群，或者不清楚怎么删除的）；2、排查残留数据，先排查rms数据库rds_cluster和rds_instance表是否有残留，有即把状态改成400；3、再排查DMS数据库DMS_META_CLUSTER是否有残留，有即把状态改成DELETED；4、最后排查monitor数据库instance_monitor表，有即把monitor_switch从1改成0；5、清理残留数据前需要先清理告警，保证console界面不显示告警，可在event数据库删除该条告警信息；【规避措施】1、monitor残留数据处理（monitor）：1）登monitor数据库，查询该集群上报状态：select id,instance_orig_id,instance_name,cluster_id,monitor_id,monitored,monitor_switch,status,event_update_at,namespace from instance_monitor where instance_name like '%集群名或者ID%';（console界面找集群id或名称）2）修改为不上报状态：update instance_monitor set monitor_switch=0, monitored=0 where monitor_switch=1 and cluster_id='';（cluster_id为上面查询出来的cluster_id）2、删除console界面告警信息（event）：1）登event数据库查询console界面显示的一条告警事件：select * from alarm_record where resource_id='' order by occur_time desc limit 1;（resource_id在告警信息里找）2）删除console界面显示的告警条目：delete from alarm_record where resource_id='' and occur_time='';（occur_time为上一部查询出来的occur_time）

max_prepared_transactions这个参数的值小于max_connections这个参数的值有什么影响吗？备节点不会执行语句？还是会直接报错？可确保每个会话都有一个等待中的预备事务。什么是预备事务？