中奖结果公示感谢各位小伙伴参与本次活动，欢迎关注华为云DTSE Tech Talk 技术直播更多活动~本次活动获奖名单如下：请@Sakura、 于7月8日前在此问卷中反馈您的中奖邮寄信息~直播简介【直播主题】智能优化揭秘 - GaussDB数据库查询重写的自动挖掘与生成【直播时间】2024年6月26日 16:30-18:00【直播专家】王肇国 上海交通大学软件学院副院长Ethan 华为云数据库 DTSE技术布道师【直播简介】在数据库世界里，查询重写是提升性能的关键环节。现有系统依赖人工发现重写规则，过程缓慢且费时。而WeTune的诞生，彻底改变了这一现状！WeTune是一种革命性工具，能自动发现新重写规则，通过枚举和验证等效查询计划，大幅优化查询性能。加入我们的直播，共同探索数据库查询优化的前沿技术，见证性能提升的神奇瞬间！活动介绍【互动方式】直播前您可以在本帖留下您疑惑的问题，专家会在直播时为您解答。直播后您可以继续在本帖留言，与专家互动交流。我们会在全部活动结束后对参与互动的用户进行评选。【活动时间】即日起—2024年6月27日【奖励说明】评奖规则：活动1：直播期间在直播间提出与直播内容相关的问题，对专家评选为优质问题的开发者进行奖励。奖品：华为云定制T恤活动2：在本帖提出与直播内容相关的问题，由专家在所有互动贴中选出最优问题贴的开发者进行奖励。奖品：华为云定制Polo衫​更多直播活动直播互动有礼：官网直播间发口令“华为云 DTSE”抽华为云定制雨伞等好礼。​【注意事项】1、所有参与活动的问题，如发现为复用他人内容或直播间中重复内容，则取消获奖资格。2、为保证您顺利领取活动奖品，请您在活动公示奖项后2个工作日内私信提前填写奖品收货信息，如您没有填写，视为自动放弃奖励。3、活动奖项公示时间截止2024年6月29日，如未反馈邮寄信息视为弃奖。本次活动奖品将于奖项公示后30个工作日内统一发出，请您耐心等待。4、活动期间同类子活动每个ID（同一姓名/电话/收货地址）只能获奖一次，若重复则中奖资格顺延至下一位合格开发者，仅一次顺延。5、如活动奖品出现没有库存的情况，华为云工作人员将会替换等价值的奖品，获奖者不同意此规则视为放弃奖品。6、其他事宜请参考【华为云社区常规活动规则】。

数据库版块、炒香菇的书呆子、4月【分享交流】生成式AI大模型，开源还是闭源更有未来？cid:link_2原创PostgreSQL数据库高可用设计方案：构建坚若磐石的业务基石cid:link_0合集2024年5月份数据库热门问题合集cid:link_1

一、引言在当今信息化高度发展的时代，数据已成为企业运营和决策的核心资源。随着数据量的不断增长和复杂性的提高，如何有效地管理和利用这些数据成为了摆在我们面前的一大挑战。在这个过程中，数据库血缘关系（Data Lineage）的概念逐渐受到了广泛关注。本文将对数据库血缘关系进行深入解析，帮助读者更好地理解其含义、作用和应用。二、数据库血缘关系的概念数据库血缘关系，简而言之，就是数据在产生、处理、流转到消亡过程中，数据之间形成的一种类似于人类社会血缘关系的关系。在数据库管理系统中，这种关系体现在数据从源头到最终应用的全过程中，包括数据的来源、流向、转换和最终用途等各个环节。通过血缘关系，我们可以清晰地追踪数据的来源和流向，了解数据的生命周期和变化过程。三、数据库血缘关系的特征多源性：同一个数据可以有多个来源，即一个数据可能是由多个数据加工生成的。这种加工过程可以包括数据的抽取、转换、加载（ETL）等多个环节。归属性：数据通常归属于特定的组织或个人，这些组织或个人对数据拥有所有权和使用权。可追溯性：数据库血缘关系体现了数据的全生命周期，从数据的生成到废弃的整个过程都可以进行追溯。这有助于我们了解数据的来源、流转路径和变化过程，为数据质量问题的排查和解决提供有力支持。层次性：数据的血缘关系具有层级关系，如同一棵树的结构。在关系型数据库中，用户、数据库、表、字段等对象之间形成了清晰的层次关系。四、数据库血缘关系的作用数据治理：通过血缘关系，我们可以清晰地了解数据的来源和流向，为数据治理提供有力支持。例如，在数据质量管理中，我们可以根据血缘关系追踪到数据质量问题的源头，从而采取相应的措施进行解决。数据安全：血缘关系有助于我们了解数据的敏感性和重要性，为数据安全管理提供依据。例如，在数据泄露事件中，我们可以根据血缘关系迅速定位到泄露的数据源和流转路径，从而采取紧急措施防止数据进一步泄露。数据应用：血缘关系为数据应用提供了重要参考。通过了解数据的来源和流向，我们可以更好地理解数据的含义和价值，为数据分析和数据挖掘提供有力支持。五、总结数据库血缘关系作为数据管理和利用的重要工具，对于提高数据质量、保障数据安全、促进数据应用等方面具有重要意义。随着大数据技术的不断发展和应用，数据库血缘关系的概念和应用将会越来越广泛。因此，我们需要不断加深对数据库血缘关系的理解和应用，以更好地应对数据管理和利用的挑战。

GaussDB数据库SQL系列-复合查询https://bbs.huaweicloud.com/forum/thread-0226150345278816027-1-1.html《GaussDB数据类型介绍》https://bbs.huaweicloud.com/forum/thread-0249150602087448029-1-1.htmlGaussDB数据库事务介绍https://bbs.huaweicloud.com/forum/thread-0279150602334571031-1-1.html GaussDB的行存表与列存表的选择https://bbs.huaweicloud.com/forum/thread-02109151812652385008-1-1.htmlGaussDB数据库的备份与恢复https://bbs.huaweicloud.com/forum/thread-0299151831620291022-1-1.htmlGaussDB数据库基础函数介绍-上https://bbs.huaweicloud.com/forum/thread-0240150603546516035-1-1.htmlGaussDB数据库基础函数介绍-下https://bbs.huaweicloud.com/forum/thread-0249150603656637030-1-1.html【GaussTech第2期】GaussDB SQL查询语句执行过程解析https://bbs.huaweicloud.com/forum/thread-0282150694254856025-1-1.html项目要将oracle库迁移为高斯数据库oracle模式，请问数据源配置该如何配？url前缀是什么？驱动名称是什么？应该引入哪个驱动jar包？https://bbs.huaweicloud.com/forum/thread-02106150774321287001-1-1.htmlOpenGauss一主两备集群异常断电后不能正常启动的解决过程简记https://bbs.huaweicloud.com/forum/thread-02106151055971542009-1-1.htmlspringboot,Druid对接高斯数据库gaussdbhttps://bbs.huaweicloud.com/forum/thread-02109151249398574011-1-1.htmlJDBC连接GaussDB云数据库操作示例https://bbs.huaweicloud.com/forum/thread-02109151319847720018-1-1.html数据库模型设计案例分享（GaussDB版）https://bbs.huaweicloud.com/forum/thread-0299151575790377009-1-1.html

中奖结果公示感谢各位小伙伴参与本次活动，欢迎关注华为云DTSE Tech Talk 技术直播更多活动~本次活动获奖名单如下：请于6月6日前在此问卷中反馈您的中奖邮寄信息~直播简介【直播主题】从数据库设计到性能调优，全面掌握openGemini应用开发最佳实践【直播时间】2024年5月29日 16:30-18:00【直播专家】Shawn 华为云开源DTSE技术布道师，openGemini社区发起人【直播简介】数据库是一个复杂的系统，如何用好它，让它在实际应用中充分发挥其作用，这对我们每个开发者来说都至关重要。本期直播将围绕openGemini的应用开发流程，并结合具体案例，详细介绍数据库设计、数据写入、数据查询等场景下的最佳实践，共同探索数据库的奥秘！直播链接：cid:link_1活动介绍【互动方式】直播前您可以在本帖留下您疑惑的问题，专家会在直播时为您解答。直播后您可以继续在本帖留言，与专家互动交流。我们会在全部活动结束后对参与互动的用户进行评选。【活动时间】即日起—2024年5月29日【奖励说明】评奖规则：活动1：直播期间在直播间提出与直播内容相关的问题，对专家评选为优质问题的开发者进行奖励。奖品：华为云定制按摩颈枕活动2：在本帖提出与直播内容相关的问题，由专家在所有互动贴中选出最优问题贴的开发者进行奖励。奖品：华为云定制双肩包​更多直播活动直播互动有礼：官网直播间发口令“华为云 DTSE”抽华为云定制飞盘等好礼。​【注意事项】1、所有参与活动的问题，如发现为复用他人内容或直播间中重复内容，则取消获奖资格。2、为保证您顺利领取活动奖品，请您在活动公示奖项后2个工作日内私信提前填写奖品收货信息，如您没有填写，视为自动放弃奖励。3、活动奖项公示时间截止2024年5月31日，如未反馈邮寄信息视为弃奖。本次活动奖品将于奖项公示后30个工作日内统一发出，请您耐心等待。4、活动期间同类子活动每个ID（同一姓名/电话/收货地址）只能获奖一次，若重复则中奖资格顺延至下一位合格开发者，仅一次顺延。5、如活动奖品出现没有库存的情况，华为云工作人员将会替换等价值的奖品，获奖者不同意此规则视为放弃奖品。6、其他事宜请参考【华为云社区常规活动规则】。

我这边自己创建镜像，但是通过该镜像创建出的容器在运行几秒后就会自动关闭，其产生的错误日志如下：2024-04-25 21:11:52 [2024-04-25 13:11:52.569][176][][gs_ctl]: gs_ctl started,datadir is /var/lib/opengauss/data 2024-04-25 21:11:52 [2024-04-25 13:11:52.591][176][][gs_ctl]: waiting for server to start...2024-04-25 21:11:52 .0 LOG: [Alarm Module]can not read GAUSS_WARNING_TYPE env.2024-04-25 21:11:52 2024-04-25 21:11:52 0 LOG: [Alarm Module]Host Name: ffc7af174a53 2024-04-25 21:11:52 2024-04-25 21:11:52 0 LOG: [Alarm Module]Host IP: ffc7af174a53. Copy hostname directly in case of taking 10s to use 'gethostbyname' when /etc/hosts does not contain <HOST IP>2024-04-25 21:11:52 2024-04-25 21:11:52 0 LOG: [Alarm Module]Get ENV GS_CLUSTER_NAME failed!2024-04-25 21:11:52 2024-04-25 21:11:52 0 LOG: [Alarm Module]Invalid data in AlarmItem file! Read alarm English name failed! line: 572024-04-25 21:11:52 2024-04-25 21:11:52 0 WARNING: failed to open feature control file, please check whether it exists: FileName=gaussdb.version, Errno=2, Errmessage=No such file or directory.2024-04-25 21:11:52 0 WARNING: failed to parse feature control file: gaussdb.version.2024-04-25 21:11:52 0 WARNING: Failed to load the product control file, so gaussdb cannot distinguish product version.2024-04-25 21:11:52 The core dump path is an invalid directory2024-04-25 21:11:52 2024-04-25 13:11:52.644 [unknown] [unknown] localhost 140296755687744 0[0:0#0] 0 [BACKEND] LOG: when starting as multi_standby mode, we couldn't support data replicaton.2024-04-25 21:11:52 gaussdb.state does not exist, and skipt setting since it is optional.2024-04-25 13:11:52.649 [unknown] [unknown] localhost 140296755687744 0[0:0#0] 0 [BACKEND] LOG: [Alarm Module]can not read GAUSS_WARNING_TYPE env.2024-04-25 21:11:52 2024-04-25 21:11:52 2024-04-25 13:11:52.649 [unknown] [unknown] localhost 140296755687744 0[0:0#0] 0 [BACKEND] LOG: [Alarm Module]Host Name: ffc7af174a53 2024-04-25 21:11:52 2024-04-25 21:11:52 2024-04-25 13:11:52.649 [unknown] [unknown] localhost 140296755687744 0[0:0#0] 0 [BACKEND] LOG: [Alarm Module]Host IP: ffc7af174a53. Copy hostname directly in case of taking 10s to use 'gethostbyname' when /etc/hosts does not contain <HOST IP>2024-04-25 21:11:52 2024-04-25 21:11:52 2024-04-25 13:11:52.649 [unknown] [unknown] localhost 140296755687744 0[0:0#0] 0 [BACKEND] LOG: [Alarm Module]Get ENV GS_CLUSTER_NAME failed!2024-04-25 21:11:52 2024-04-25 21:11:52 2024-04-25 13:11:52.649 [unknown] [unknown] localhost 140296755687744 0[0:0#0] 0 [BACKEND] LOG: [Alarm Module]Invalid data in AlarmItem file! Read alarm English name failed! line: 572024-04-25 21:11:52 2024-04-25 21:11:52 2024-04-25 13:11:52.652 [unknown] [unknown] localhost 140296755687744 0[0:0#0] 0 [BACKEND] LOG: loaded library "security_plugin"2024-04-25 21:11:52 2024-04-25 13:11:52.652 [unknown] [unknown] localhost 140296755687744 0[0:0#0] 0 [BACKEND] WARNING: could not create any HA TCP/IP sockets2024-04-25 21:11:52 2024-04-25 13:11:52.652 [unknown] [unknown] localhost 140296755687744 0[0:0#0] 0 [BACKEND] WARNING: could not create any HA TCP/IP sockets2024-04-25 21:11:52 2024-04-25 13:11:52.658 [unknown] [unknown] localhost 140296755687744 0[0:0#0] 0 [BACKEND] LOG: InitNuma numaNodeNum: 1 numa_distribute_mode: none inheritThreadPool: 0.2024-04-25 21:11:52 2024-04-25 13:11:52.658 [unknown] [unknown] localhost 140296755687744 0[0:0#0] 0 [BACKEND] LOG: reserved memory for backend threads is: 220 MB2024-04-25 21:11:52 2024-04-25 13:11:52.658 [unknown] [unknown] localhost 140296755687744 0[0:0#0] 0 [BACKEND] LOG: reserved memory for WAL buffers is: 128 MB2024-04-25 21:11:52 2024-04-25 13:11:52.658 [unknown] [unknown] localhost 140296755687744 0[0:0#0] 0 [BACKEND] LOG: Set max backend reserve memory is: 348 MB, max dynamic memory is: 8142 MB2024-04-25 21:11:52 2024-04-25 13:11:52.658 [unknown] [unknown] localhost 140296755687744 0[0:0#0] 0 [BACKEND] LOG: shared memory 3285 Mbytes, memory context 8490 Mbytes, max process memory 12288 Mbytes2024-04-25 21:11:52 2024-04-25 13:11:52.690 [unknown] [unknown] localhost 140296755687744 0[0:0#0] 0 [CACHE] LOG: set data cache size(402653184)2024-04-25 21:11:52 2024-04-25 13:11:52.712 [unknown] [unknown] localhost 140296755687744 0[0:0#0] 0 [SEGMENT_PAGE] LOG: Segment-page constants: DF_MAP_SIZE: 8156, DF_MAP_BIT_CNT: 65248, DF_MAP_GROUP_EXTENTS: 4175872, IPBLOCK_SIZE: 8168, EXTENTS_PER_IPBLOCK: 1021, IPBLOCK_GROUP_SIZE: 4090, BMT_HEADER_LEVEL0_TOTAL_PAGES: 8323072, BktMapEntryNumberPerBlock: 2038, BktMapBlockNumber: 25, BktBitMaxMapCnt: 5122024-04-25 21:11:52 2024-04-25 13:11:52.726 [unknown] [unknown] localhost 140296755687744 0[0:0#0] 0 [BACKEND] LOG: gaussdb: fsync file "/var/lib/opengauss/data/gaussdb.state.temp" success2024-04-25 21:11:52 2024-04-25 13:11:52.726 [unknown] [unknown] localhost 140296755687744 0[0:0#0] 0 [BACKEND] LOG: create gaussdb state file success: db state(STARTING_STATE), server mode(Normal), connection index(1)2024-04-25 21:11:52 2024-04-25 13:11:52.884 [unknown] [unknown] localhost 140296755687744 0[0:0#0] 0 [BACKEND] LOG: max_safe_fds = 976, usable_fds = 1000, already_open = 142024-04-25 21:11:52 The core dump path is an invalid directory2024-04-25 21:11:52 2024-04-25 13:11:52.886 [unknown] [unknown] localhost 140296755687744 0[0:0#0] 0 [BACKEND] LOG: user configure file is not found, it will be created.2024-04-25 21:11:52 2024-04-25 13:11:52.893 [unknown] [unknown] localhost 140296755687744 0[0:0#0] 0 [BACKEND] LOG: the configure file /usr/local/opengauss/etc/gscgroup_omm.cfg doesn't exist or the size of configure file has changed. Please create it by root user!2024-04-25 21:11:52 2024-04-25 13:11:52.893 [unknown] [unknown] localhost 140296755687744 0[0:0#0] 0 [BACKEND] LOG: Failed to parse cgroup config file.2024-04-25 21:11:52 2024-04-25 13:11:52.906 [unknown] [unknown] localhost 140296755687744 0[0:0#0] 0 [EXECUTOR] WARNING: Failed to obtain environment value $GAUSSLOG!2024-04-25 21:11:52 2024-04-25 13:11:52.906 [unknown] [unknown] localhost 140296755687744 0[0:0#0] 0 [EXECUTOR] DETAIL: N/A2024-04-25 21:11:52 2024-04-25 13:11:52.906 [unknown] [unknown] localhost 140296755687744 0[0:0#0] 0 [EXECUTOR] CAUSE: Incorrect environment value.2024-04-25 21:11:52 2024-04-25 13:11:52.906 [unknown] [unknown] localhost 140296755687744 0[0:0#0] 0 [EXECUTOR] ACTION: Please refer to backend log for more details.2024-04-25 21:11:52 2024-04-25 13:11:52.906 [unknown] [unknown] localhost 140296755687744 0[0:0#0] 0 [BACKEND] FATAL: ERROR: could not create instr log directory "pg_perf": Permission denied2024-04-25 21:11:52 2024-04-25 21:11:52 2024-04-25 13:11:52.920 [unknown] [unknown] localhost 140296755687744 0[0:0#0] 0 [BACKEND] LOG: FiniNuma allocIndex: 0.2024-04-25 21:11:53 [2024-04-25 13:11:53.593][176][][gs_ctl]: waitpid 179 failed, exitstatus is 256, ret is 22024-04-25 21:11:53 2024-04-25 21:11:53 [2024-04-25 13:11:53.594][176][][gs_ctl]: stopped waiting2024-04-25 21:11:53 [2024-04-25 13:11:53.594][176][][gs_ctl]: could not start server但是我直接在CentOS内本地安装却不会产生任何问题，因此这里求助各位大神，这种情况我需要做些什么？

我们写了一些函数/存储过程用来展现报表数据，为了存储中间数据用了临时表，并且临时表在运行过程中insert的数据量有时候会很大（百万级），因此在后续对这些临时表引用的时候，需要对这些表做动态采样，否则会导致执行计划有问题。在Oralce中，我们在函数/存储过程中在对临时表做关联查询的时候，采用 SELECT /*+ opt_param('OPTIMIZER_DYNAMIC_SAMPLING',6) */ 这样的hint 来要求做动态采样。在Opengauss中，我们先是尝试在INSERT 临时表数据后，通过ANALYZE tablename;来更新该临时表的统计信息，但是ANALYZE无法在函数/存储过程中执行，否则会报”ANALYZE cannot run inside a transaction block”。请问是否有其它办法可以在函数/存储过程中对临时表做动态采样？

你踩过哪些sql查询时索引使用不合理的坑？欢迎畅所欲言

HTTP与HTTPS：应用与区别https://bbs.huaweicloud.com/forum/thread-0235148060922093001-1-1.html【GaussTech技术专栏】分布式数据库技术又会向什么方向发展https://bbs.huaweicloud.com/forum/thread-02120148013835594002-1-1.htmlMysql 的binlog日志的原理https://bbs.huaweicloud.com/forum/thread-0274147866480625030-1-1.html使用MyBatis操作GaussDB，使用的dbdriver & 操作方法，都跟pgsql完全一样吗？https://bbs.huaweicloud.com/forum/thread-0296147798019018031-1-1.htmlopenGauss数据库常用sql指令https://bbs.huaweicloud.com/forum/thread-0219147789440502037-1-1.html 探索openGauss：一款国产高性能、高安全关系型数据库https://bbs.huaweicloud.com/forum/thread-02104147789392322040-1-1.html分布式数据库与集中式数据库：架构、特性与优缺点解析https://bbs.huaweicloud.com/forum/thread-02109147783666284043-1-1.html数据仓库分层：理解DWD、DWB和DWS的含义https://bbs.huaweicloud.com/forum/thread-0296147779133564030-1-1.html 数据库中 BLOB、CLOB、NVARCHAR 的区别与应用场景https://bbs.huaweicloud.com/forum/thread-0277147276388776012-1-1.htmlsql查询中一个条件匹配用in和=的区别https://bbs.huaweicloud.com/forum/thread-02107148448396245003-1-1.htmljava线程池有哪些类型https://bbs.huaweicloud.com/forum/thread-02120148449121921003-1-1.htmlSimpleDateFormat类为何不是线程安全的？https://bbs.huaweicloud.com/forum/thread-0205148449279210003-1-1.htmljava中如何设计跨线程的数据同步问题https://bbs.huaweicloud.com/forum/thread-0208148448736910003-1-1.html索引的结构介绍https://bbs.huaweicloud.com/forum/thread-0229148450870412003-1-1.html索引最左前缀匹配原则https://bbs.huaweicloud.com/forum/thread-02106148451452838004-1-1.html

中奖结果公示感谢各位小伙伴参与本次活动，欢迎关注华为云DTSE Tech Talk 技术直播更多活动~本次活动获奖名单如下：请于4月17日下班前在此问卷中反馈您的中奖邮寄信息~直播简介【直播主题】GaussDB(DWS)基于Flink的实时数仓构建【直播时间】2024年4月11日 16:30-18:00【直播专家】Eric 华为云数仓DTSE技术布道师【直播简介】华为云数仓GaussDB(DWS)基于流处理框架Flink实现了高效实时数仓构建，数据分析时效从T+1时效趋向于T+0时效。GaussDB(DWS)+Flink如何增强湖仓增量数据在不同数据模型层之间的实时流动能力？如何为消息数据流提供高性能通用入库能力？本期直播将为您带来DWS-Flink的全新探索实践分享。【直播链接】cid:link_1活动介绍【互动方式】直播前您可以在本帖留下您疑惑的问题，专家会在直播时为您解答。直播后您可以继续在本帖留言，与专家互动交流。我们会在全部活动结束后对参与互动的用户进行评选。【活动时间】即日起—2024年4月12日【奖励说明】评奖规则：活动1：直播期间在直播间提出与直播内容相关的问题，对专家评选为优质问题的开发者进行奖励。奖品：华为云定制U型按摩枕活动2：在本帖提出与直播内容相关的问题，由专家在所有互动贴中选出最优问题贴的开发者进行奖励。奖品：华为云定制双肩包更多直播活动直播互动有礼：官网直播间发口令“华为云 DTSE”抽华为云定制雨伞、填写问卷抽华为云云宝手办盲盒等好礼。课后有奖实操 ：4月11日-4月12日，完成课后动手实验即送华为云定制T恤。点击开始实验【注意事项】1、活动期间同类子活动每个ID（同一姓名/电话/收货地址）提问数≤20个；所有参与活动的问题，如发现为复用他人内容或直播间中重复内容，则取消获奖资格。2、为保证您顺利领取活动奖品，请您在活动公示奖项后2个工作日内私信提前填写奖品收货信息，如您没有填写，视为自动放弃奖励。3、活动奖项公示时间截止2024年4月13日，如未反馈邮寄信息视为弃奖。本次活动奖品将于奖项公示后30个工作日内统一发出，请您耐心等待。4、活动期间同类子活动每个ID（同一姓名/电话/收货地址）只能获奖一次，若重复则中奖资格顺延至下一位合格开发者，仅一次顺延。5、如活动奖品出现没有库存的情况，华为云工作人员将会替换等价值的奖品，获奖者不同意此规则视为放弃奖品。6、其他事宜请参考【华为云社区常规活动规则】。

原文链接cid:link_0详情参考附件

原文链接：cid:link_0向量数据库也许你最近可能听过这样的新闻，某向量数据库的初创公司刚写好 PPT，就获得了几千万的投资，某公司的开源的向量数据库因其代码的简陋而登上了 Hackernews 等等。在过去几个月时间中， AI 应用的发展如火如荼，带动了 AI 应用技术栈上下游的火爆，而向量数据库就是其中最热门的之一。笔者最近因为开发 ChatFiles 和 VectorHub 两款开源项目的需要从而对向量数据库（Vector Database）进行了学习，在对主流的向量数据库和搜索算法有了大概的了解后，笔者决定将这些知识整理成一篇文章，希望能够帮助到大家。

注：原文URL:https://mp.weixin.qq.com/s/D8EtMUd4RZOStFaq3tIm2w详细的讨论会分享背景请见我们上一篇文章《AI如何颠覆软件：你能为AI打工吗？》。我们尽量每周都会组织不同领域的AI讨论会，覆盖软件行业的所有细分。为了保持一个活跃的讨论环境，对参与人群会有限制，请有意愿参与讨论会的直接私信后台“微信号，个人介绍，以及擅长讨论什么话题”，从业者/创业者优先。本期讨论会参与者：邰骋，墨奇科技创始人，向量数据库创业者，师从知名的应用数学领域科学家、中国科学院院士鄂维南。主要研究方向为大规模非结构化数据处理算法和系统，在SIAM、JMLR、ICML等国际期刊会议发表多篇论文，是国内人工智能、应用数学方面的领军学者。Haowei，Snowflake早期员工，多年数据库内核开发经验，专注容器化和虚拟化技术。Yujia，微软Copilot产品经理，正在尝试Copilot+各种场景。以及资深数据架构师，数据库/BI创业者，投资人，参与讨论作出的贡献。1 AI会如何改变数据库交互AI改变的交互对OLTP硬影响不大：使用到的Python、Java等，用这些代码建好应用后，很难想象会替换成自然语言和数据库进行交互AI会降低OLAP的交互门槛，促进数据仓库普及：在OLAP的场景下，需要BI和数据仓库交互。以及看到基于GPT将自然语言转成SQL的技术，然后进行数据查询的产品、Prototype等，会大大降低非技术人员和数据仓库交互的门槛以史为鉴，当对象的使用门槛降低的时候，普及性就会越来越高。例如当图形界面GUI问世的时候，个人电脑就普及了。同样，当LLM降低数据仓库的门槛时候，越来越多的公司（而不仅仅是科技公司），都会变成Data Driven导向，或者以数据来进行决策。公司中的每一个人都可以快速根据数据决策，做决策的效率和频率都会提高。自然语言仍很难替代所有SQL语言：SQL是非常古老的语言，产生于1980年代。SQL有一个问题，简单的东西非常简单，一旦复杂化后，就会变得反人类。故如果没有经过专门的训练，一般人只能拿SQL 做简单的事情。现在大语言模型把它翻译成 SQL，最长的SQL 大概存成文本文件的话大概有 20 个Megabyte，这个就完全不是人能够读的东西了。今天为什么大家都用SQL，因为说白了可能是一种习惯，但这种习惯有没有被挑战？就算没有大模型其实也正在被挑战，比如spark，现在就很多人就觉得不管是 Python还是Java，通过spark API 去写比写 SQL其实更顺利一点。所以在很多 ETL 的场景下面，现在很也不单纯用 SQL ，很多的 ETL 现在都是用 Spark ，其中原因之一就是SQL 这个语言不够直观。SQL也是更加精确的语言，在复杂的和机器场景下的准确性要高于自然语言。很难用自然语言去精准地表达一些复杂的接口、Query。虽然现在已经出现了自然语言转SQL的GPT工具，但因为自然语言的局限复杂度不够，复杂场景仍然做不了未来更多是简单的查询用自然语言接口，复杂的场景还是需要SQL，或者Spark、Python，SQL有很强的韧性，可以适应各种复杂场景。自然语言 vs SQL=易用 vs 效率/精准：当追求极致的简易性，在效率和准确上就会有牺牲，就需要自然语言。就类似于过去编程情况，如果追求便捷就会用Python，但可能会牺牲效率；如果追求效率，用C++这样更接近于机器的语言，学习曲线就会更高。自然语言不是针对数据库查询的最优选择，但会根据使用者的情况有Trade Off。2 AI是否能改变数据库底层AI很难改变底层：LLM很难对计算引擎、网络等产生影响，数据库内核的发展和LLM的演变也没什么关系。但数据库可能未来会承担更多的模型训练任务，不再是单纯的数据层的数据库，这相当于数据库从数据层往训练工具演变。现有数据库架构会不会因为AI而演化出类似HTAP的情况，同一份数据有两种形态：在为LLM训练的场景，可能不会很普遍，大模型需要的训练数据主要是知识，和平时公司商业用途需要查询的数据，还是两种数据。但对于中小规模的模型，会有这类的场景，很多公司都会有内部需求。比如简单的情况，数仓一般是Column Format，再做一个Compression，这种情况非常常见。但做AI训练的时候，一般需要Row Format。如果传了两份到storage engine之后，这两份相关性不大。存完之后是存在一个地方，是两个表还是一个表，没有什么关系。应用A（比如说一般数仓）永远不会探索为应用B（基于AI训练的结果）存的那一份。应用B也永远不会探索为应用A存的那一份。除非应用A需要用到一份，应用B需要用到同样的一份，这个时候把这张表作为一张表看待，有比较大价值。现在的实际情况是，两个应用永远不会碰到同一份。从某种程度上来说，这两个应用physically比较独立。如果硬要把这两份数据说是属于一样表，但就像很多OLTP的表，OLAP经过ETL之后形成OLAP的表。大家也知道这两张数据库表是同样一张表，但是基于数据库的应用就把它当作两张单独的表来看。因为做OLAP的时候，永远也不会访问OLTP的那个数据表。所以如果两个应用之间没有相互的mix和match的时候，把它当成两张不同的表，在两个不同引擎里面存储，还是当成一张表有两个format来看，实际没有本质的影响。而一定要把这两个当成一张表的两个不同引擎来看的时候，事实上增加了系统的难度。在目前的情况下，机器学习的 training 的 format 和做OLAP查询的这两种format，本身天然是不会相互碰到，也就导致了目前还没有需求非得要把这两份数据当做同一张表格的两种形态。目前可以把它当成两个单独的表格来处理，并不影响使用。不知道将来会不会有BI的应用导致现在这种假设不成立。这是有可能的，正如HTAP。往10年前看的时候，AP是AP，TP是TP。这两年HTAP出来了，因为有真实的需求，可能对于AI和AP在过个几年也会有这样需求，但是就目前为止还看不到。3 LLM可以直接作为数据库使用吗？很难替代数据库的使用场景：LLM很难解决ACID问题，LLM的初衷就不是为了精准查询设计的，LLM的查询结果很难保证准确的Number，也很难保证Snapshot isolation。长期来看，LLM也很难匹配数据库的性价比，数据库都有非常复杂的场景优化。更可能的演化，还是LLM改变了数据库的交互，但LLM本身不会成为数据库。4 数据仓库/数据湖在训练中的支持情况数仓/数据湖未来都会搭建训练平台：传统数仓/数据湖之前是提供数据源，但未来可以作为训练平台，例如替代一部分Sagemaker的场景。从客户角度，在数仓/数据湖中做训练，尤其是训练小模型场景，可以省去移到训练平台的数据迁移成本，省去中间Pipeline的维护，省去ETL的过程，也不需要把数据放在不同系统中减少了Replica。同样，从安全性和隐私性角度出发，未来会看到更多类似GDPR的规范，多个数据存储系统会导致数据泄露的风险加大，也需要雇专门的人去审计不同系统中的数据合规性要求。从产品完整性的角度，数仓本来做的就是做商业决策，成为ML/AI的训练平台后也可以完善商业决策，也属于本身的计划发展方向。训练也是多次的，对数仓/数据湖都会有带动作用：GPT或者大语言模型的技术革命，会让更多企业意识到AI的价值。在过去的很多年里，AI不是一个新技术，但用得好的都是很大的科技企业，在传统企业的渗透率仍然非常非常低。GPT更像是破圈的Trigger，迫使所有公司都去尝试ML/AI，不一定是直接接入LLM，还有很多垂直的企业场景。从具体的带动关系来看，AI训练不是只训练一次，需要不断地训练，有不断的新数据进来。每隔一段时间就要去更新模型，上线新模型。也就需要不断地向数仓/数据湖去要数据。5 AI对部分数据仓库/数据湖的影响数据仓库最本质的还是产品能力，AI不是决定性因素Databricks随着Dolly的推出，有机会帮助他们的一些客户更好更容易地训练大模型。但大多数企业还是负担不起大模型的训练。所以还是更加的倾向于训练小模型，或者训练一个 good enough 的模型，或者说是一些模型的 fine tuning。就fine tuning来说其实也有很多方法，然后有一种方法，我听说是可以先训练一个比较小的模型，然后和大模型在 merge 一下，调一下权重。Databricks和 Snowflake 其实更多的还是赋能企业，他们提供了一个平台，能帮企业更好地去训练。至于说他们开源了这个模型， Dalle2 它只是一个开源模型，还要看开源生态能不能搭建起来。Databricks选择开源这样一个模型，在对模型的支持上就可能有偏向性，不确定是否能保证对其他模型也有很好的支持。微软也有偏向性，包括选择OpenAI。亚马逊和Snowflake目前没有偏向性。6 Copilot能帮助分析型数据库实现什么样的新场景目前Copilot/其他大模型的目标还是降低普通/简单任务的门槛：不管是Copilot，还是其他的大模型，目前最擅长的东西肯定不在于非常高级和难的任务，而是在于能够降低一些普通和简单任务的门槛。不管是在 Office 的处理还是数据库，都是在拓展易用性，以及能够大规模的让一些企业去进行操作上的升级，或者是让更多的人可以做更多的事情。大模型能够解决的问题的复杂性还取决于成本：对于成本的问题，如果我们降低承载大模型使用的大模型相关的产品或相关的体验的使用的成本，这里其实是一个目的导向的事情，即如果我们希望它以一个什么样价格收费是市场能够接受的，或者说我们能提供的价值是否能够cover成本。这里面有很多工程加算法的问题，像刚才提到的我们到底什么样的情况下才需要大模型，不是所有的问题和所有的处理都必须要使用大模型。实际上各家的大模型在实际解决问题的时候，已经在考虑成本的问题了：那这里面前期需要做一个判断，从技术上其实在微软这方面做的背后的工程量和 OpenAI 做的都很多。虽然用户感知到好像都是GPT/LLM在回答，但这里面可能会有一些筛选，有一些情况其实传统的搜索或者更早期的AI就能有一个非常好的结果的时候，就不会再去用高级的模型。其实这上面会有，就包括数据库之后的应用，这方面也会有很多的方法可以降低这个成本。7 向量数据库的前世今生向量数据之前的应用：邰博士之前主要做向量的算法、图的算法，也在北大教授人工智能课程。最早做向量数据库的时候还不叫向量数据库，但会用到很多向量和图。在大模型之前主要是用作搜索/推荐，以前像Google做网页搜索的时候，有一些关键词特征，就是向量特征。除了搜索引擎外，还会用到例如微博中。后来在计算机视觉中也有了向量表示，图像可以变成一个向量的表示，这些都是为了做向量搜索的。语音也是同样的，可以做声纹比较。在Bio-informatics里，也可以基于基因相似的序列、蛋白质的结构比例等等。向量数据库正变得更加重要：向量数据，同传统数据库里面有整型、字符串，比较新的比如地理信息的一些坐标等，也是一种数据类型。LLM出现后，向量的这种数据类型将会变得更加重要。意味着不同的数据库往后都要需要支持向量。而专门为这种数据类型做一些Data Infrastructure的优化也变得更加必要。为了优化结构化数据的读写，产生了TP；为了优化海量数据的计算，产生了AP；为了优化非结构化数据，产生了文件数据库等。针对向量数据，怎么如何做存储，怎么如何做索引，怎么如何做高性能的查询、压缩等等进行专门的优化也是非常必要的，使之能够让其更好的面向 AI 应用。除了向量，在这个场景，以后可能还会有更多其他的类型的数据。图也是很重要的类型（并不是现在见到的大图，可能是一些小的图等等，可能就几百节点，但是数量会很多，就跟向量一样，可能是多个向量组成的这些图），也是以后可能的演化。8 向量数据库与其他Data Infra的关联跟分析型场景的结合度比较高：现在很多情况向量是作为一个数据类型在做的，Workflow 里面的很多环节它都有关系。比如原始数据，ETL进分析型数据库，再向量化进向量数据库。Huggingface 上很多这样的模型，可以把不同类型的语音文本、pdf等向量化。Metadata的结构化的特征，或者是模型预测的这种标签的特征，也会向量化。从学习框架上来讲：在训练模型和推理过程中，现在都可以用到一些向量，当然不是所有的都用。现在的Transformer架构，加一个外置的Memory ，可以在参数不大的情况下，达到和大参数模型一样的效果。其实就是外挂的向量数据库加上一个中小模型，可以得到一个很好的效果。然后在推理应用的层面上，如做搜索引擎，做行业应用等等。要把不同的类型整合在一起做一些分析，这更多是偏向于分析型的应用，如果最单纯的那种向量近似搜索的话，或者精确搜索的话，只是针对这种类型的分析。当然很多刚才讲的应用里面，像 flaw detection 推荐系统，要跟结构化的特征一起做联合的分析。先写一段SQL，用结构化的信息做一些过滤，做一个过滤，然后再用向量做一些查询找一些相似的例子等等。这反而是在应用中非常常见的，就是在这种实际应用中，都是要跟结构化的数据做结合的。单纯用向量这个我觉得可能看到的还少一点，可能只是作为召回这种情况或者更简单的使用，或者模型训练的使用。联合应用的情况会更多，比如墨奇做的MyScale数据库，针对Clickhouse进行了二次开发，在这个基础上开发了一个新的引擎，它可以对向量、对图做一些联合的查询。可以分析向量，也可以分析原来结构化的数据。这就是说从前到后，从数据源、数据的转化、包括跟机器去做大模型、到应用层等等，存在一个紧密的关系。把向量作为一个环节来看，让他跟其他的数据做一些紧密的结合，联合的分析会更有用。分析型数据库也有必要与向量数据结合：墨奇+Clickhouse已经在做这方面的工作了，Elastic和PG也有向量插件了。未来有必要专门为AI做一个新兴的数据库，支持AI Native应用，对数据的查询要求和过去可能会有差别。未来单一的向量数据库可能是一个比较薄的产品，更多是和现有的分析型数据库结合。例如一个很适合的向量数据库+Clickhouse场景就是大模型推理，比如 GPT 3，它context size是很有限的。现在GPT 到GPT3 token 的 size 从 8000 变成了这个 2 万多，提高3 倍的contact size, 需要的计算量~ 9 倍，是个平方的关系，所以 long-term memory 是大模型的问题。那现在有向量数据库，可以充当这个 long-term memory。很多人做一些算法上改善的尝试，目前都没有成功，包括用一些逼近的方法，包括用linear attention，但都失败了，那full attention 在一段时间内还是要长期要在的。这样的话，在一段时间内可能就需要有一个外置的memory，通过long-term memory 来解决大模型的问题，这就是大模型带起来的最大的一个需求。我觉得向量数据库充当这个long-term memory，就是非常合适。还有比如相似人的查询，或图的搜索任务。或者再加一些别的限制，可能这个在“我的品类”者“商品推荐”，在这个类型中，我们找一个跟竞品比较像的，或者怎么样。就所有这些任务，推荐等等，都是有结构化的描述在这里，也很适合和向量数据库结合。还有比如全文检索跟ES也可以结合，向量可以解决模糊搜索和语义搜索的需求。9 向量数据库的未来演进方向未来可能不只是大模型：例如Google的很多论文都在讲，中等规模模型+外界大数据库，那可以实现更大规模模型的效果。如果看OpenAI之前的论文的话，也将很多类似的。如果有很好的、精标的数据集，然后有很好的人工干预，那么不用大模型，几百亿级别的模型也可以做到和千亿级别模型一样的效果。向量数据库还有很大的优化空间：针对向量的压缩、索引、查询的优化都还有很多空间。从向量算法来看，现在开源的库很多，像Pinecone、Milvus等等，开发者可能用ivf、hsw这些，做深入优化工作，可以使得性能、Density等提高很多，例如墨奇的压缩就做得很好，可以比过去存10数十倍以上的数据。从AI应用的角度来看，向量数据库会成为LLM在性价比上的补充：高质量性能的外部数据库，对训练和推理上都会有很大的助力，也就需要一个向量+分析都能支持很好的数据库。未来会走向一个融合引擎的数据库，支持向量、图、全文检索、结构化数据等类型10 传统数据库在向量数据库的尝试已经有在做，但优化层面还很浅：分析性数据库（OLAP）做向量更加有意义，例如Elastic做得意义就大于MongoDB来做。Elastic已经尝试添加了子向量模块，包括向量检索的功能，但是跟完整的向量数据库相比，功能差距还很大。目前传统数据库厂家还没有根据向量这一特殊类型，去优化存储和计算引擎，更多是接入库和简单算法。想要做到向量数据库的能力，还要做到算法层面优化，不能只靠开源生态。MongoDB结合得不紧密，分析型场景对于MongoDB也不是主要的。Clickhouse非常适合做向量数据库，墨奇也给Clickhouse贡献了很多Feature。11 向量数据库还能怎么补充大模型LLM主要有三个普遍的缺陷，需要向量数据库来补充：第一，比较本质的，比如GPT 3，它使用到21年9月份的数据，那练完之后模型里面存的知识就是静态，不能被更新。然后它的 context size，需要实时的信息，比如说，这周华南地区的销售怎么样？可以问GPT，但它不能告诉你答案，即便给了答案也不是真实的。所以只能是跟数据库结合，有一个实时数据源，提供给它这种实时的信息。那么向量数据库它可以这种包括跟数据库的结合，这里不只是向量数据库，跟实时数据源的结合，可以解决这个实时性的问题。第二，精确性的问题。在搜索里面用的很多。知识存在大模型的参数里面，也是有记忆的，但是很难精确的去取回一些信息。问大模型两次问题答案会不一样。希望有很精确的信息的时候，在数据库里面是可以有非常精确的东西，有这种可靠性。所以要很精确的信息的时候，可以在这里做企业搜索，文档搜索，这种数据库的查询就会非常有用。第三，数据权限跟管理的问题。比如想问CTO薪酬是多少，类似这种信息不能够放在大模型里面，因为放进之后所有人都能 access 大模型，无意之间泄露重要信息。包括政府等客户的信息，不能把这些加入到训练语料当中去。这些信息还是要放到数据库里再来做，所以天然可能就形成一个模式：非实时的信息，不敏感的信息，但是又有系统性，规律性的东西，作为领域知识的、行业知识，或者更通用的一般的知识，放到大模型里面去，形成一个载体；另一个载体是承载实时的、精确的，有权限、隐私要求的信息，那么放到数据库。LLM厂商都有尝试去解决，但目前进展一般：OpenAI 有一些新的插件也是为了暂时的去解决这些问题，但在短期内不容易有很大优化。到 GPT 5/6，也不会有太大的改进，还是需要依靠外部memory的这种结合来提高它的 effective context size。12 大模型会如何影响数据处理以及ETL环节ETL本身也是一个工程问题，会有一定的复杂性，但是从目前来看用大模型已经可以去解决一些ETL需求：像大模型包括 GBT-4，做这类事情很多效果都远超预期。去年这个时候都不会觉得它有那么好。但特别从去年 10 月份之后到现在，performance好了很多。过去很难用规则表达的，或者一般小的模型难处理好的东西，就是或者不愿意去fine-tune一个小的模型的任务，现在变得很容易。过去做这个事情：以最复杂的PDF为例（PDF内可能包含文字、图，尤其是PPT 转的PDF，里面内容很多）。过去做法是训练一个 Bert 或 fine-tune Bert， fine -tune 很多模型去解决不同的数据转化。这都导致在于是要么很高的训练模型的门槛，或者要么在一个场景需要做有很多模型。然后现在的大模型，比如说让他去抽取简历，去抽取PDF格式的年报的信息，效果真的是都非常好。感觉实际效果跟人工标的那个准确率其实都差不多的，但是使用过程要快很多。这带来一个更大的一个好处：过去要维护很多的中小模型，现在通过一个大模型，然后再加上prompt 和 Meta prompt engineering，就可以做很多事情。维护成本变得很低，效果也不差。成本角度，如果都用大模型来做特征提取的工作的话，成本会很贵很高，因为chatgpt按 token来收费。但也有很多别的做法可以降低成本，比如Stanford，Databricks，还有国内的一些公司在做的事情。方法是用 GPT 4来产生很多的标签数据。比如说一天可以产生10 万个 GPT 4/100 万个 GPT 4 的样例，然后用它来 finetune 一个自己训练的百亿的模型，到时候就不用再调用 GPT 4 了。就直接用finetune好的这个模型，然后用来做ETL，会便宜一个数量级（vs 都调用GPT4）。目前成本对于企业内的一些智能文档等场景，是可以承受的，但是就是就是它蒸馏之后，或者是根据 instruction tuning 之后，这个成本对于哪些场景目前是可以接受的？如果是蒸馏之后，就是说 fine tune 之后，比方用一个百亿的模型再做一些整治，其实成本是比较低的。可能还有一些成本更低的，像大家开源的模型这块得也是挺大的一个力量。在很多ETL任务上已经到了一个很可用的程度了。墨奇MyScale数据库介绍MyScale 是墨奇科技研发的一款用于向量计算的高性能数据库。一方面，MyScale基于ClickHouse内核开发，兼顾了极强的向量数据处理能力和极好的OLAP型数据库的复杂数据分析能力，同时完整支持SQL语言，极大降低了数据迁移和开发者学习成本；另一方面，MyScale在精确检索、结构化数据和非结构化数据联合查询、高密度索引存储等任务上实现了自研算法的核心突破，主要指标显著优于同类产品，处于世界领先地位。随着大语言模型的技术突破，向量数据库+大语言模型这种新范式的重要价值也迅速凸显。通过对领域知识的海量数据进行向量化并存储在向量数据库中，可以很大程度上解决大语言模型的几个主要缺陷：无法有效覆盖时效性数据和领域数据；生成内容缺乏事实依据；输入/输出的内容长度显著。通过向量检索+大语言模型的结合，生成式AI的回复将更可控、可解释、可溯源。目前MyScale的Cloud版本已经进入内测阶段，只需通过简单的注册，即可免费享有数百万规模向量数据的处理能力，欢迎访问https://myscale.com/进行体验！

金融开放平台数据库转型白皮书版权声明 本报告版权属于北京金融科技产业联盟，并受法律保护。 转载、编摘或利用其他方式使用本白皮书文字或观点的，应注 明来源。违反上述声明者，将被追究相关法律责任。编制委员会 主任： 聂丽琴 刘承岩 编委会成员： 黄本涛 王 辉（工行） 编写组成员： 董勇明 史大鹏 李 林 庄乾锋 董 里 赵 耀 庞 毅 陈伟红 郭凤鸣 谢 军 白 阳 徐 旭 王 辉（华夏） 杨 勐 徐雅光 韩竺吾 李 倩 毛思平 王莉莉 郑皓广 王鹏冲 李中原 王嵩阳 李 斌 娄贺展 编审： 林承军 张 蕾 参编单位： 北京金融科技产业联盟 中国工商银行股份有限公司 华为技术有限公司 华夏银行股份有限公司 中国银行股份有限公司 中国农业银行股份有限公司 中国建设银行股份有限公司 兴业银行股份有限公司 中国光大银行股份有限公司 平安银行股份有限公司摘 要 “十四五”规划提出了“加快数字化发展”的总体布局，金 融服务是支撑数字经济发展的关键要素，同时自身也有数字化转 型的发展诉求。金融开放平台数据库作为金融信息系统的核心基 础软件，转型升级对于突破金融效率瓶颈、释放金融创新空间、 提升金融服务水平、支撑金融行业数字化转型和高质量发展具有 重要而深远的意义。 在开放平台数据库转型中，面临着技术选型难、系统迁移难， 综合风险提升等诸多挑战。本文通过调研金融行业开放平台数据 库技术应用现状、分析金融行业数据库架构转型中的重点和难点 应用场景、并结合开放平台业务系统关系型数据库的应用转型实 践，提出转型解决思路和建议。文中述及的方案以数据库的集中 式+分布式双栈架构，满足金融业不同的业务场景需求：对于稳 态业务，采用集中式部署，满足快速原地平替的转型需求，对于 敏态业务，采用分布式部署架构，满足系统快速弹性扩缩容的需 求。 数据库转型是一项复杂的系统性工程，本文对多个关键技术 领域，包括同城双集群容灾、对象迁移、数据迁移、数据校验、 测试验证、并行方案等都进行了深入的阐述和分析，给出了整体 技术方案建议和实践案例，可为金融同业及相关领域从业者提供 参考。

版权声明：来源：CCSA TC601 大数据技 术标准推进委员会2023年数据库发展研究报告，大数据技术标准推进委员会发布CCSA TC601 大数据技术标准推进委员会 2023年7月版权声明本报告版权属于 CCSA TC601 大数据技术标准推进委 员会，并受法律保护。转载、摘编或利用其它方式使用本报 告文字或者观点的，应注明“来源：CCSA TC601 大数据技 术标准推进委员会” 。违反上述声明者，本院将追究其相关 法律责任。详情请参考附件