【问题来源】深圳容大【问题简要】呼入座席接起通话，然后座席转接到外线，tcurrentbilllog表没有转外线的记录【问题类别】CC-DIS【AICC解决方案版本】22.100[问题描述]   您好！手机A呼入，座席20457接起，然后座席转接外线到手机B，手机B接通挂机。tcurrentbilllog表没有座席呼叫/转接手机B的信息。调用了"/voicecall/agentId/transfer"接口，话单记录见附件。

我这边自己创建镜像，但是通过该镜像创建出的容器在运行几秒后就会自动关闭，其产生的错误日志如下：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

【问题来源】深圳容大【问题简要】一通通话，经过座席的转换/咨询/会议后，产生的几个记录有没有字段可以关联起来【问题类别】CC-DIS【AICC解决方案版本】22.100[问题描述]   您好。客户打一通电话，座席接通之后，需要转接/咨询/会议，tcurrentbilllog表产生多条数据记录。这几条数据有没有字段关联起来，可以显示这个通话的轨迹？

中奖结果公示感谢各位小伙伴参与本次活动，欢迎关注华为云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 大数据技 术标准推进委员会” 。违反上述声明者，本院将追究其相关 法律责任。详情请参考附件

引言在信息化社会中，数据库作为数据存储、管理和检索的核心组件，其设计和选择直接影响到系统的性能、可扩展性、可靠性和安全性。其中，分布式数据库与集中式数据库作为两种主流的数据库架构模式，各具特色，适应于不同的应用场景。本文旨在深入剖析分布式数据库与集中式数据库的基本概念、核心特性以及各自的优缺点，以帮助读者在实际项目中做出更为明智的选择。一、分布式数据库：分布式的力量1. 定义与架构分布式数据库是一个由多个物理位置上的数据库节点组成，这些节点通过网络相互连接，共同构成一个逻辑上统一的数据库系统。数据被分割并分散存储在各个节点上，同时，数据库管理系统（DBMS）负责协调节点间的操作，确保数据的一致性和完整性。2. 主要特性高可用性与容错性：由于数据分散存储，即使个别节点出现故障，其他节点仍能提供服务，确保整体系统的持续运行。高性能与可扩展性：通过并行处理和负载均衡技术，分布式数据库能够利用多节点的计算资源加速查询和更新操作。随着业务增长，只需增加节点即可实现水平扩展。灵活的数据分布：可根据业务需求和数据访问模式，动态调整数据在节点间的分布，实现最优的资源利用。3. 缺点与挑战系统复杂性：跨节点的数据同步、一致性控制、故障恢复等机制增加了系统的复杂性，对管理和运维能力提出了更高要求。数据安全与隐私：分布式环境中数据传输与共享的风险增大，需要部署严格的安全策略和加密技术来保障数据安全。一致性保证：保持数据全局一致性的难度增加，尤其是面对并发操作和网络延迟时，需要采用如两阶段提交（2PC）、分布式事务等复杂技术。二、集中式数据库：单一源头的稳健1. 定义与架构集中式数据库是指所有数据存储、管理和访问均集中在单一物理位置（如一台服务器或数据中心）的数据库系统。用户通过网络连接到中心节点进行数据操作。2. 主要特性简单性与易管理：单一数据源简化了数据访问路径，便于数据的协调与管理，降低了运维复杂度。数据冗余低：数据集中存放减少了数据副本，有利于数据一致性维护，同时也节省了存储空间。经济性：相较于分布式架构，初期建设和运维成本通常较低，尤其适合规模适中、数据量稳定且对实时性要求较高的场景。3. 缺点与局限单点风险：集中式架构下，一旦中心节点发生故障，可能导致整个系统不可用，影响服务连续性。扩展性受限：随着数据量和访问量的增长，垂直扩展（提升单台服务器性能）存在物理极限，且成本高昂。水平扩展则需借助分库分表等技术，但会引入额外复杂性。数据访问压力：所有用户请求均指向同一节点，可能导致数据流量过大，影响响应速度。三、应用场景与选择考量分布式数据库在以下场景中表现出色：大数据处理：大规模数据集、高并发访问、实时分析等需要高吞吐量和快速响应的业务。互联网服务：社交网络、电商平台、在线游戏等用户基数大、数据增长迅速的行业。地理分布：跨国公司、云服务提供商，需要在全球范围内就近提供服务，降低延迟。集中式数据库适用于：中小型企业：初期数据规模较小，对成本敏感，且业务稳定性要求较高的情况。内部管理系统：如企业资源规划（ERP）、客户关系管理（CRM）等，数据量相对固定，访问模式较为明确。

在数据仓库领域，我们常常会遇到一些缩写，比如DWD、DWB和DWS。这些缩写代表着数据仓库的不同层次，对于理解和构建数据仓库体系具有重要意义。下面，我们就来详细解释一下这些缩写的含义。DWD（Data Warehouse Discover） DWD，即Data Warehouse Discover，代表着数据仓库的探索层。在这个阶段，主要的目标是进行数据探查和数据清洗。DWD的数据源可能包括多个系统，如ERP、CRM、OA等。这些系统中的数据格式、数据类型、数据关系等都可能不同，因此需要进行数据清洗和整合，以便于后续的数据分析和决策支持。DWB（Data Warehouse Build） DWB，即Data Warehouse Build，代表着数据仓库的构建层。在这个阶段，主要的目标是将DWD中的数据进行整合和清洗，构建出符合业务需求的数据模型。这个模型通常是一个多维度的数据立方体，可以支持多种数据分析算法和决策支持应用。DWB的数据源可以是多个数据仓库的整合，也可以是多个数据源的整合。DWS（Data Warehouse Services） DWS，即Data Warehouse Services，代表着数据仓库的服务层。在这个阶段，主要的目标是将DWB中的数据进行加工和处理，以支持决策支持和数据分析应用。DWS的数据源可以是多个数据仓库的整合，也可以是多个数据源的整合。DWS的数据模型应该与具体的业务需求相结合，支持多种决策支持和数据分析应用。总结一下，DWD、DWB和DWS是数据仓库的三个重要层次，分别代表着数据仓库的探索、构建和服务三个阶段。在构建数据仓库时，我们需要明确每个阶段的目标和任务，以及每个阶段所需要的数据源和数据模型。只有理解了这些缩写背后的含义和任务，我们才能更好地理解和应用数据仓库的知识和技术。在实际的数据仓库项目中，这些缩写都有着重要的应用价值。比如在构建一个新的人力资源管理系统的数据仓库时，我们可以首先使用DWD进行数据探查和清洗，然后使用DWB构建出符合人力资源管理业务需求的数据模型，最后使用DWS进行数据的分析和决策支持。除了这些缩写，数据仓库中还涉及到许多其他的概念和技术，比如ETL（Extract-Transform-Load，指数据的抽取、转换和加载）、ELT（Extract-Load-Transform，指数据的抽取、加载和转换）、数据模型设计、元数据管理、数据质量等等。理解了这些概念和技术的含义和应用方法，我们才能更好地构建和应用数据仓库。

在数据库设计中，选择合适的数据类型对于保证数据的完整性和效率至关重要。BLOB、CLOB 和 NVARCHAR 是数据库中常见的三种数据类型，它们各自有不同的用途和特点。本文将详细介绍这三种数据类型的区别，以及它们各自的应用场景。BLOB（Binary Large Object）BLOB 是一种用于存储大量二进制数据的数据类型，如图片、音频、视频文件等。它通常用于存储非文本数据，最大大小可以达到数GB。特点存储二进制数据：BLOB 可以存储任何类型的二进制数据。大容量：BLOB 适合存储大文件，其容量通常远大于其他数据类型。应用场景多媒体内容管理：如存储图片、视频、音频等多媒体文件。文档管理：如存储 Word、PDF、Excel 等文档。CLOB（Character Large Object）CLOB 是一种用于存储大量文本数据的数据类型，如大型文档、XML 文件等。它通常用于存储字符数据，最大大小也可以达到数GB。特点存储文本数据：CLOB 用于存储大量的文本内容。支持字符集：CLOB 可以指定字符集，以支持不同的语言和编码。应用场景内容管理系统：如存储文章、新闻、博客等文本内容。数据仓库：存储日志文件、报告等大量文本数据。NVARCHARNVARCHAR 是一种可变长度的字符串数据类型，它可以存储 Unicode 字符。NVARCHAR 通常用于存储少量的文本数据，如用户名、地址等。特点Unicode 支持：NVARCHAR 可以存储任何语言的字符，包括中文字符、日文字符等。可变长度：NVARCHAR 的长度可以根据实际存储的数据动态变化，节省空间。应用场景国际化应用：当应用程序需要支持多语言时，NVARCHAR 是理想的选择。常规文本字段：如存储用户输入的评论、描述等信息。结语BLOB、CLOB 和 NVARCHAR 是数据库中用于存储不同类型数据的三大数据类型。BLOB 和 CLOB 适用于存储大型的二进制和文本数据，而 NVARCHAR 则适用于存储少量的、需要支持多语言的文本数据。了解它们之间的区别和各自的应用场景，可以帮助数据库设计者做出更合理的数据类型选择，从而优化数据库的性能和可扩展性。希望本文能帮助您更好地理解这三种数据类型的使用。