数据库

欢送拜访 OceanBase 官网获取更多信息：https://www.oceanbase.com/ 国泰产险自 2018 年以来业务开始高速增长，现平峰日均保单量达数千万级，顶峰日均保单量达亿级。面对财产保险场景化、碎片化特色，国泰产险最终抉择分布式数据库 OceanBase 并已安稳运行近 5 年。在此期间，国泰产险积极探索，在运维翻新与数据库迁徙等方面积淀了大量可借鉴的行业教训。3 月 25 日，2023 OceanBase 开发者大会在京召开， 国泰产险资深数据库专家舒明分享了《国泰产险的 OceanBase 上云实际》的主题演讲， 以下为演讲实录。 国泰产险于 2008 年在上海成立，迄今已在西北沿海和中西部地区 9 个省市设立25家分支机构。过来的 2022 年，全年保单数量达 57.8 亿单，保费规模达 53.8 亿元，累计服务客户达 3 亿人， 并取得 2021 年中国金鼎奖“年度卓越财产保险公司”、2022 年“金理财”奖年度企业社会责任奖。 国泰产险互联网产品有两个比拟显著的特点： 一是场景化。 所谓场景化，就是在生存和工作中遇到的一些场景。例如以电商场景为代表的退货运费险，大家在淘宝、天猫等平台购买商品时商家赠送的退货运费险，很有可能就是咱们国泰产险的产品。这种产品特点体现在“小单”和“天量”，“小单”是指保费支出和保额较少，但绝对其余险种它的“天量”即数量十分大。像过来几年的“双 11”期间，国泰产险的退货运费险日保单量根本都在 1 亿以上。 二是碎片化。 国泰产险的产品笼罩生存场景中的很多碎片化需要，这类产品特点通常不能用一些通用的模型来解释，比拟偏定制化、个性化。例如大家给本人买的健康险、给宝宝买的“萌宝保”、给父母买的“孝顺保”等。国泰产险针对这些碎片化场景打造了 200+ 翻新产品，驱动业务高质量倒退。 面临多重挑战基于国泰产险产品场景化、碎片化的特点，咱们在理论生产过程中遇到了一些业务和技术上的挑战。 ▋ 挑战一：要求 7×24 小时全天候高可用降级为互联网科技保险公司后，咱们的零碎要求 7×24 小时全天候提供服务，因为即便是在深夜也会有用户在淘宝、天猫等线上平台下单，进而同步购买咱们的各种产险产品，假如进行服务五分钟，都会给咱们带来间接的经济损失。而作为底层服务的数据库须要放弃更高的可用性。 ▋ 挑战二：业务快速增长，分库分表逻辑简单近年来，国泰产险在互联网平台上的保单数快速增长，数据库的单表数据量急剧收缩。这种状况下，咱们已经思考分库分表加历史数据归档，还对一些分库分表计划进行了选型，如通过第三方中间件，如间接本人写框架在程序层进行逻辑管制。但无论哪种计划，整体逻辑都会比较复杂且后续保护不不便。 ▋ 挑战三：并发高，性能要求刻薄每逢节假日、大促日，尤其是“双 11”期间，高并发的特色非常明显。像在大促日 24 点时，很多用户都守在 APP 前筹备集中下单，短期内成千上万甚至上亿的保单量，刹时流量十分大，对咱们的利用来说压力十分大。再加上保险业务的一个申请要通过承保前置、承保、合约、风控等链路，并且对链路上每个节点的运行晦涩度要求都十分高。所以咱们对数据库性能的要求能够说是十分刻薄的。 分布式数据库选型及成绩为了晋升互联网化交付速度、麻利响应大规模业务需要，国泰产险信心全力打造保险中台，而保险中台的底层须要一款经验过海量数据考验的数据库做撑持。 一方面是基于打造保险中台的大背景，一方面是基于以上三点业务和技术上日益凸显的挑战，咱们开始进行大量的数据库调研工作，发现 OceanBase 有三个特点十分吸引咱们，也是咱们最终抉择握手 OceanBase 的次要起因。 ...

从中兴、华为等一系列高新科技企业被美国制裁，到俄乌抵触事件暴发后，东方各国相继发表制裁俄罗斯，以Oracle、IBM、微软、SAP为代表的科技巨头暂停在俄服务，这一系列动作给咱们敲响了减速国产化代替的警钟。数据库作为提供数据存储与解决能力的根底软件，是信息系统的根底、信息安全的基石，因而，数据库自主可控和国产化代替曾经迫不及待。 兼容性是国产化代替要害，自研数据库更具后劲 Oracle数据库倒退较早，在国内市场内霸占了肯定先机，企业通过信息化的长期积攒和变革，基于Oracle开发了大量的零碎业务。为了可能适配新的国产数据库产品，必须对利用代码进行大量批改，各数据表的数据类型、函数、语法规定须要进行零碎、全面的革新，这就要求新的国产数据库对原有数据库可能有很好的兼容性反对，升高迁徙的代码革新老本。 Oracle通过多年的倒退，在SQL语言、性能、实例状态、容灾计划等方面有很多积攒扩大。若要实现Oracle数据库的国产化代替，除了要可能提供在性能、容灾能力、平安能力等方面全方位提供对等的能力，首先要解决的就是如何兼容Oracle的大量SQL方言，尤其是Oracle的PL/SQL这一独特的广受欢迎的语法体系。 中国信通院《数据库倒退钻研报告》中示意，“国内关系型数据库产品中少数是基于MySQL和PostgreSQL二次开发的”。因而，这些产品对MySQL、PostgreSQL兼容性较好，但没有体系化的兼容Oracle，尤其是PL/SQL方面。 “高度的商业数据库兼容能力意味着大量的设计和研发工作，波及产品整体架构的多个方面，非常考验厂商对代码的了解和掌控能力”。国家工业信息安全倒退钻研核心 、中国电子学会和北京国家金融科技认证核心联结公布的《分布式数据库发展趋势钻研报告》中指出，“齐全自主研发的产品在这方面具备先天的劣势，将来无论在兼容性适配还是产品能力的研发上都更具后劲”。 KunDB是星环科技自主研发的国产分布式交易型数据库，提供残缺的关系型数据库的能力，高度兼容MySQL和Oracle，可低成本实现数据库国产化的代替和迁徙，具备可扩大、高并发、高可用、数据灾备等个性，满足企业要害业务解决、高并发查问、业务分布式革新、交易剖析混合的数据中台等简单场景，在金融、政务、能源、医疗、交通、教育等多个行业利用，为用户提供高性能、稳固牢靠、经济实用、自主可控的国产化数据库产品。 高度兼容Oracle，实现低成本国产化平滑代替 KunDB对Oracle语法各个方面高度兼容，成为业内当先的具备撑持Oracle业务迁徙能力的国产数据库。KunDB高度兼容Oracle语法与PL/SQL，反对VARCHAR2/NVARCHAR2、NUMBER等全副罕用数据类型，在PL/SQL语法上，反对管制语句、汇合、动静SQL、子程序、预约义包、错误处理等全副PL/SQL语法，并且通过自主原创的PL/SQL编译器，KunDB反对简单PL/SQL程序，执行性能比解释执行晋升一个数量级，解决了Oracle业务迁徙到国产化数据库的外围痛点，为其余兼容性欠缺提供了根底。 在Oracle数据库对象、DML、函数、零碎视图、内置包、驱动等方面，KunDB做到了罕用性能的兼容，满足大部分业务的迁徙需要，极大升高了企业业务迁徙老本。 例如在某省级社保零碎迁徙过程中，KunDB仅用了3天就实现了8万多行PL/SQL代码的迁徙工作，高效、低成本、平安地保障了原数据库迁徙，平滑实现了数据库系统的国产化代替。 翻新过程语言编译技术，残缺反对Oracle PL/SQL语法 KunDB自研翻新的过程语言编译技术及两头优化语言TIR，反对简单PL/SQL程序，执行性能比解释执行晋升一个数量级。 形象和实现了星环通用两头PL/SQL指令集TIR，为多种代码编译执行形式提供基础表达能力 联合LLVM代码生成技术，间接生成CPU指令，比Go等高级语言运行时生成代码的效率晋升一个数量级 内置LLVM优化器，应用最新的编译优化技术，做有效代码、公共表达式、死码、边界查看打消等优化，保障最终执行代码的最简化 自研表达式计算引擎，反对向量化和JIT执行，PL/SQL和SQL均可调用，比Go语言的通用表达式计算性能晋升5倍以上 KunDB为PL/SQL定义了极其精简、通用的TIR指令集，其中6类指令可用于PL的解释，8条指令可用PL/SQL中的游标、游标遍历、动态SQL、动静SQL的解释，这14条指令的组合，可笼罩PL/SQL语法范畴内所有语法组合的解释。PL/SQL被解析成形象语法树后，PL和SQL被TIR指令集解释成相应的指令汇合。 TIR指令反对LLVM编译器，可生成不同平台的Native code，即CPU指令集减速执行。在LLVM的编译过程中，还会主动同步实现局部代码的逻辑优化，比方有效代码的去除。编译生成的执行指令集KunDB会保留在元数据中，为雷同PL/SQL文本提供可复用的指令集（相似执行打算）。而对于LLVM指令集中还不反对的PL/SQL指令，会保留为高级语言（Golang）的指令最终交由高级语言编译器编译执行。 所以KunDB的PL/SQL执行，是将大部分指令映射成CPU指令执行的，而且不须要反复编译，相较于每次编译成其它高级语言的形式，有较大的性能劣势。以相似TPCC中NewOrder解决的PL/SQL实现为例，不思考SQL执行的状况下，纯PL的逻辑的执行，应用KunDB的动静编译执行是齐全由高级语言编译执行的3倍以上。 另外，PL/SQL以及惯例SQL语法中的表达式计算是影响性能的关键因素之一，也借鉴了动静编译执行的思维，KunDB设计和实现了基于列存数据和动静执行的表达式引擎，对于数值类型的聚合计算，应用动静编译执行比一般解释执行要快10倍以上。 查问优化和向量化执行引擎，高性能简单SQL查问 KunDB基于火山模型的优化器和向量化执行引擎反对了跨分片的查问，反对的SQL蕴含递归查问、嵌套子查问、别名等简单SQL场景。针对聚合计算类SQL中性能耗费较高的表达式计算做了特地优化的表达式模块，逻辑优化能够用该模块进行如常量折叠，公共表达式提取等优化，执行器调用该模块进行表达式的计算。以TPCH为例，KunDB可高效跑完100GB规模内的全副22个简单查问SQL。 适配Oracle利用生态，保障业务平滑迁徙 KunDB适配Oracle利用开发生态，反对基于Oracle的业务间接或者通过中间件框架连贯KunDB，包含Java、.NET、C/C++等语言开发的利用，尤其是针对C/C++利用提供兼容Oracle的OIC/OCCI驱动，来保障业务的平滑迁徙。KunDB还提供了凋谢的数据生态，通过全局事务日志可与异构零碎实时同步，可利用在实时数仓建设、Oracle和KunDB双数据库系统并轨运行回切等场景。 以某大型医疗HIS零碎适配为例，应用的.NET EFCore开发框架与星环科技KunDB连贯，通过高兼容性和迁徙服务保障了多个外围业务零碎的平滑迁徙， 业务全量功能测试中个别的外围数据库源零碎数据类型、语法兼容问题仅通过大量调整便能达成利用适配，在节俭大量人力老本的同时，保障了数据库无损切割，实现了疾速、平安地替换Oracle的指标。 星环科技分布式交易型数据库KunDB自主研发，并以优异的问题通过了工信部、央行、信通院等多项数据库权威测试认证，为用户提供高并发、高性能、高牢靠的国产数据库产品。同时，KunDB高度兼容Oracle PL/SQL和MySQL方言，可实现低成本数据库国产化代替，并且适配反对国产服务器、芯片、操作系统等软硬件生态，助力企业打造自主可控数据平台。

4 月 18 日 — 21 日，一年一度的云原生旗舰会议——由云原生计算基金会（CNCF）主办的 KubeCon + CloudNativeCon Europe 2023 在荷兰阿姆斯特丹胜利拉开帷幕，数千名云原生开源社区的技术专家和云原生爱好者、使用者汇聚在此，围绕 WebAssembly、机器学习和人工智能、云原生平安、eBPF 等技术热点，共享云原生开源资讯，独特探讨云原生的将来发展趋势。 值得一提的是，涛思数据作为 KubeCon + CloudNativeCon Europe 2023 的荣誉赞助商也参加了本次会议，在会议现场，涛思数据展位吸引了泛滥开发者的关注，TDengine 创始人 & 外围研发陶建辉和现场的开发者们一起探讨云原生技术对于数据库倒退的重要性。 近年来，在开源技术的推动下，云原生的倒退进入快车道阶段，国内外泛滥企业都开始投入力量深度钻研云原生技术，试图以云技术的有限后劲推动数字化时代的疾速倒退。在此过程中，为了突破信息孤岛、实现技术交换，各种云原生大会也逐步衰亡，其中 KubeCon能够说是云原生畛域最具影响力的会议之一。从 200 人的小会议倒退到近 4000 位云原生和开源畛域工程师齐聚一堂的大会，KubeCon 只用了四年工夫，作为云原生畛域的盛会，每一年的 KubeCon 都会将世界各地出名的云厂商汇聚于此，为参会者分享他们这一年来面向云原生的翻新技术和研究成果。 同样，借助云原生的力量，涛思数据旗下的 TDengine 3.0 也倒退成为了一款真正的云原生时序数据库（Time Series Database），解决了困扰时序数据库倒退的高基数难题，反对 10 亿个设施采集数据、100 个节点，反对存储与计算拆散。与此同时，基于 TDengine 打造的全托管的时序数据处理云服务平台 TDengine Cloud 也胜利推出，正式反对 Microsoft Azure、AWS、Google Cloud、阿里云四大私有云，将来还将接轨更多的云厂商。 涛思数据在云技术上的种种研究成果也成为关上 KubeCon + CloudNativeCon Europe 2023 大门的通行票，置信借助这一云原生盛会的力量，更多国外开发者可能理解到云原生时序数据库 TDengine，而 TDengine 的技术创新力量也可能借此契机更快走出国门、惠及世界各地的企业和开发者。 流动举荐时序数据处理有没有让你头疼？想不想找到一个优良的解决方案，让你轻松应答海量的时序数据？2023 年 4 月 25 日 19:00-20:00，TDengine 创始人&CEO 陶建辉 将为大家分享《时序数据处理的云端利器：TDengine Cloud 详解与演示》。 TDengine Cloud 是一个极简的全托管时序数据处理云服务平台，它是基于开源的时序数据库 TDengine 而开发的。它是一款极简的时序数据管理平台，提供便捷且平安的数据共享和安全可靠的企业级服务。 ...

为表彰应用大数据、人工智能等根底软件为企业、行业或世界做出杰出贡献和微小翻新的标杆我的项目，星环科技自2021年推出了“新科技 星力量” 星环科技科技实际案例评选活动，旨在为各行业提供更多的优良产品案例，彰显技术扭转世界的力量，目前已胜利举办两届，收到了来自各界的积极参与。 第二届星环科技科技实际案例评选活动新增了“年度信创先锋之星”，通过产业界、学术界专家联结评审，最终评比出了“年度信创先锋之星”、“年度科技向善之星”、年度价值奉献之星”、“年度科技前沿之星”、“年度技术革新之星”五大奖项，并特此进行案例巡展。 本期巡展案例为取得第二届“新科技 星力量” 星环科技科技实际案例评选活动“年度信创先锋之星”的江西金融倒退集团股份有限公司基于星环科技分布式数据库的互联网金融业务零碎实际。 企业与我的项目 江西金融倒退集团股份有限公司（以下简称“江西金发”）于2016年经江西省政府批准设立，是补位江西传统金融服务的产融联合综合型金融科技平台，公司逐渐构建担保增信为主导的多元化金融服务体系，聚焦以产融联合的模式助力中央建设。 江西金发充分发挥混合所有制劣势，强化数字化转型先天基因，以多元金融服务体系为根底，制订数字化框架顶层设计，通过更大投入、更实动作、更优机制推动数字化转型，助推江西省金融服务模式由“找钱”的传统模式向“钱找”的智慧模式转型，为江西省数字经济倒退做出踊跃奉献。 随同着公司业务体量的晋升，对数据库性能要求和自主可控的要求也越来越高，金发公司打算将所有业务零碎进行革新，对立采纳国产高性能分布式数据库来提供服务，同时为了进步数据的利用率，施展数据的价值，打算构建数据仓库与数据湖一体零碎来代替之前的开源大数据平台CDH，为业务部门提供数据撑持。 我的项目背景与需要 江西金发的互联金融业务采纳互联网开发的技术栈，应用开源的MySQL作为对立的数据库建设计划，蕴含200多个实例，构建了一套面向互联网用户的高并发信贷业务零碎，并通过大数据风控技术晋升业务的安全性。 随着业务的增长，业务互联网特色更加显著，对高并发、低提早以及稳定性有了更高的业务要求。同时，随同着交易的增多，对风控剖析、报表等实时查问剖析需要也进步了要求，反对基于历史数据的实时查问与批量解决等，超过了单机MySQL的解决下限。从金融业务的敏感性来讲，对业务开发过程中的技术安全性也迫切需要改良，采纳国产化软硬件是必由之路。 通过对分布式数据库成熟度、先进性和行业案例等维度评估，最终抉择了星环科技分布式交易型数据库KunDB和分布式剖析型数据库ArgoDB作为技术解决方案，保障了国产数据库替换的正确性和低迁徙老本的同时，实现了性能、可靠性、实时性等维度的晋升。 解决方案 为满足业务高速倒退和自主可控需要，江西金发联结星环科技制订了具体的国产化零碎革新降级计划和布局，制订了严格的业务革新开发、测试和上线流程，保障数据库变更前后的品质，并造成了分布式数据库革新开发标准。在整体业务方面，原业务零碎中前置业务（对接第三方互联网金融平台的流量）、中台、风控外围业务等跟对公业务强相干的模块，均对接了星环科技分布式数据库。 江西金发基于星环科技分布式数据库的互联网金融业务零碎 利用成果 金发业务零碎与数据平台别离联合星环分布式交易型数据库KunDB与星环分布式剖析型数据库ArgoDB进行了革新开发，低成本实现了原零碎的平滑迁徙，实现了从数据库到操作系统到硬件的全栈国产化革新，做到了自主可控，并且实现了性能、可靠性、实时性等维度的晋升。 平滑迁徙星环科技KunDB高度兼容MySQL，反对MySQL通信协议、方言和开发生态，配合星环科技自研的迁徙工具，实现了原开源MySQL零碎数据和业务的平滑迁徙，共实现了14个外围业务往分布式数据库的迁徙和业务革新，通过全量数据迁徙+增量数据迁徙的形式实现了在线不停服迁徙，累计迁徙了2TB的业务数据，满足将来2年业务增长的需要。 架构翻新原先MySQL+Hadoop降级为星环科技KunDB+ArgoDB湖仓一体架构，用户能够基于对立拜访接口最大水平上升高数据湖、数据仓库、数据集市业务过程中业务接口的调整，升高用户开发成本，进步数据处理效率。对立的元数据管理能够在精准的ACL管制下，实现按需展现湖仓集内的相干元数据的对立查问，进步数据管理效率。对立存储管理，对使用者屏蔽不同数据源的数据存储，升高业务数据管理难度。 此外，基于星环科技分布式AETP技术，零碎可同时撑持TP与AP的高性能业务需要。基于容器化技术的部署实现了资源隔离，易于治理和公布，并为零碎稳定性提供了保障。同时，测试环境与生产环境互相不影响，且可实现CI/CD，晋升了开发效率。 性能晋升业务零碎中前置业务（对接第三方互联网金融平台的流量）、中台、风控外围业务等跟跟对公业务强相干的模块，均对接了分布式数据库，对高并发和大数据量的表进行了分表，实现了存储上的扩大和性能上的扩大，实时信贷交易的并发量为原来的3倍，基于分布式剖析型数据库ArgoDB的剖析业务响应效率晋升为原来的5倍。 零碎容灾程度晋升业务零碎与分布式数据库均采纳冗余部署的容灾计划，通过Loadbalance组件实现动静负载平衡。故障时服务和数据库可主动选主，RTO<10s，RPO=0，提供7*24小时继续服务，且不影响负载平衡的有效性。 自主可控KunDB和ArgoDB均为星环科技自主研发，并且与国产软硬件生态实现兼容适配，助力金发实现了从数据库到操作系统到硬件的全栈革新，实现了技术大幅降级，提前进入新的支流技术生态。

欢送拜访 OceanBase 官网获取更多信息：https://www.oceanbase.com/ 3 月 25 日，第一届 OceanBase 开发者大会在北京举办，OceanBase 生态产品技术专家陈小伟为大家带来了 《数据库协同开发的现状和发展趋势》 的分享，从热门的 ChatGPT 谈到数据库的协同开发，与大家一起洞悉行业热点话题，畅想行业发展趋势。 以下为演讲实录： 随着数据快速增长，数据库稳定性问题导致的故障也越来越重大。咱们先看几个具体的例子，是 ChatGPT 帮我找的： 2016年，某社交网络应用的一名工程师在批改一条 SQL 查问时犯了一个谬误，导致了该公司的服务在寰球范畴内停机。该谬误导致了数据库中某些表的数据无法访问，最终导致了整个零碎的故障。 2017年，某电商企业曾因一次故障而导致其 S3 服务在美国东部地区停机。预先考察发现，该故障是由一个谬误的删除指令引起的，这个指令原本只想删除一小部分数据，但因为编写了烂 SQL，后果导致了整个数据中心的数据失落。 2018年，某云厂商的云存储服务呈现了一个故障，导致一些客户的数据无法访问。考察后发现，这是因为一个工程师在批改数据库的查问语句时犯了一个谬误，导致了整个服务呈现了故障。 我其实也问了中国大陆地区的状况， ChatGPT 的回复也是有很多例子，然而不可能通知我具体的公司名称，看来目前还是很爱护中国大陆厂商的体面的，这背地不晓得是否有团队在帮忙做一些工作。 这些例子，比方烂 SQL 导致的零碎不稳固，在数据规模不大的时候都不成为问题，然而目前的趋势就是数据规模越来越大，数据库作为保障信息系统稳定性的重要兜底安装，身上的担子就越来越重了。 由这个话题，开始我明天的分享的主题： 数据库协同开发曾经成为趋势。 本文次要蕴含四个局部，我会从四个方面来阐释此观点，也在文章的结尾给大家介绍了 OceanBase Developer Center（ODC）在这方面的致力和往年的 roadmap。 分享数据库行业现状，数据库的开发工具，要解决的还是应用数据库的问题。目前在数据库应用过程中有哪些挑战，以及我的用户，包含蚂蚁团体是如何去应答这些挑战的。基于对国内市场、海内市场常见工具的察看，所得出的论断。联合数据库行业的变动，对趋势做进一步洞察。数据增长带来一系列变动▋ 数据快速增长近些年在数据管理畛域的很多挑战，根本原因都能够归结到数据快速增长。信通院的报告显示，中国数据库市场规模近几年放弃 25% 左右的年增长率。 外表上咱们看到的是，数据存储规模在疾速减少，数据库市场规模在一直增长。咱们服务的用户场景，有一些具体的例子： 某电商零碎应用 60 个节点的数据库集群，每个节点数据规模 20TB 左右，总数据规模超过 1PB；某金融零碎应用的数据库表数量达到 20W，列数量达到 400W；某金融零碎应用的分区数量达到 100W；某制造业零碎应用的 PL 程序包数量达到 4K个。从数据库开发者的视角来看，或者说从数据库开发工具的视角来看，这背地数据库的实例数量、数据库实例内存储的对象的数量、应用数据库的业务零碎的数量、以及数据库厂商的数量、数据库从业人员数量，都在一直地增长。 随同着上述的诸多变动，给数据库的应用带来了很多问题，近些年在数据管理畛域的很多挑战，根本原因都能够归结到数据快速增长。 ▋ 更加严格的合规监管数据快速增长，利用数量也一直增长，集体、企业的敏感数据流通范畴更广了，数据带来的隐衷泄露问题也越来越重大。这几年咱们国家从顶层设计、法律法规、行业标准、企业自主意识方面都对敏感数据爱护越来越器重。 列举一些近些年咱们国家颁布的，一系列对于保障信息安全的法律法规和行业标准。 《中华人民共和国网络安全法》：2017年6月1日失效，包含对个人信息的收集、应用、存储和爱护等方面的规定，对违反规定的行为进行了明确的处罚。《中华人民共和国个人信息保护法》：2021年11月1日失效，是中国大陆地区首个专门针对个人信息爱护的法律。该法规明确了个人信息的定义、解决规定、权力爱护和责任查究等方面的内容。《中华人民共和国电子商务法》：2019年1月1日失效，包含对于个人信息的收集、应用、治理、平安保障等方面的规定，针对电子商务畛域的个人信息爱护进行了标准。JR/T 0223-2021《金融数据安全数据生命周期平安标准》。WS/T 78802021 《国家卫生信息资源应用治理标准》。在数据安全之中，数据库表演至关重要的角色，保证数据不泄露、失落。数据不失落是由 ACID 来保障的，不泄露则须要业务利用零碎来和管理工具一起保障。很多客户曾经开始器重这个问题，正在寻找解决方案，但解决方案并不遍及，目前行业计划还不成体系，配套的开发工具也不够成熟。 ...

欢送拜访 OceanBase 官网获取更多信息：https://www.oceanbase.com/ 近日，新兴游戏公司海南掌玩网络科技有限公司（以下简称“掌玩科技”）正式牵手原生分布式数据库 OceanBase，其投放零碎、用户剖析零碎、数据系统、经营剖析零碎等数套零碎均接入了 OceanBase。 通过 OceanBase 的 HTAP 能力，实现游戏平台用户行为数据实时剖析，存储老本升高 80%，性能晋升约 30%，DBA 运维效率大幅晋升。 掌玩科技于 2019 年成立，始终以来专一于游戏联运、游戏发行和游戏盒子等业务，旗下经营国战传奇、自在之刃、怒火一刀等热门游戏产品，累计注册用户超千万。 对于一款游戏来说，用户的可继续留存、可继续变现是外围竞争力，数据分析继而成为领导游戏经营的重要伎俩。通过数据分析能够将玩家行为数字化，并提供建设用户画像，剖析用户行为的根底，又能给游戏公司建设多纬度的数据报表领导经营决策。 随着掌玩科技的游戏业务疾速倒退，数据量越来越大，包含经营剖析，买量分析，用户剖析等在内的数据分析性能曾经远远不能满足业务需要。 基于“云原生数据库（TP）+数据仓库（AP）“建设汇聚库的模式造成数据多份冗余，还须要保护数据同步链路，导致数据存储老本和运维复杂度显著回升。 此外，用户的精细化经营需要，如举荐、用户散失归因等场景的一直减少，对数据分析的实时性要求越来越高。原数据库性能，特地是 AP 性能无奈撑持实时剖析需要，起初降级为云原生数据库后，掌玩科技尝试将数据同步至数据仓库，心愿能把精力投入到更有价值的业务上，而不是破费精力去保护多份数据和同步链路，但剖析性能仍未达到预期。 通过多家调研与测试，掌玩科技最终抉择牵手原生分布式数据库OceanBase。目前，掌玩科技的投放零碎、用户剖析零碎、数据系统、经营剖析零碎等数套零碎，通过OMS（OceanBase Migration Service，OceanBase 数据迁徙工具）在业务零批改的状况下，实现了向 OceanBase 分布式数据库的残缺、平滑迁徙。 迁徙至OceanBase后，掌玩科技借助 OceanBase 的 HTAP 能力，代替原有“云原生数据库（TP）+数据仓库（AP）”的计划，大大简化了数据库架构，数据只有一份且无需保护同步链路，剖析业务真正做到了实时没有链路提早，剖析解决的性能和实时性失去进一步提高，简单 SQL 性能均匀进步 30%。 在接入 OceanBase 后，掌玩科技降本增效显著，借助 OceanBase 的高级压缩技术，以及一份数据即可实现存储和剖析，助力公司数据存储老本整体降落了 80%。 纯熟利用 OceanBase 的大集群模式、在线 DDL、智能诊断等性能，在云控制台加持下，掌玩科技的 DBA 运维效率大幅度晋升，再无需为保护多份数据和同步链路而懊恼，能够将精力投入到更有价值的业务上。 据理解，OceanBase 私有云（OceanBase Cloud）是构建在阿里云、AWS 等寰球支流私有云基础设施上，基于齐全自主研发的原生分布式数据库，提供弹性扩大、卓越性能、支流兼容的高性价比的数据库云服务，为客户在云上提供服务、弹性、监控、诊断、开发、迁徙、备份、复原的端到端数据库服务化解决方案。2022年，OceanBase Cloud 正式面向寰球客户开服，开始为寰球不同规模、不同成长阶段的客户提供优质数据库服务。 凭借 LSM-Tree 高压缩引擎、原生多租户、真正的 HTAP 等硬核能力，OceanBase 深度助力中小企业降本提效。携程、海底捞、现实汽车、二维火、客如云、利楚商服、易仓科技、洋葱团体、致欧家居等搭载 OceanBase 全新登程后，均在数据库性能显著晋升的根底之上，播种多项老本升高与效率晋升。 欢送拜访 OceanBase 官网获取更多信息：https://www.oceanbase.com/ ...

如何疾速、即时、合乎直觉地去解决 Nebula Java Client 中的数据解析？读这一篇就够了。图数据库 NebulaGraph 的论坛和微信群里，有不少用户问及了 Java 客户端数据解析的问题。在本文教你一种简略的形式同返回后果交互，疾速、即时地拿到解析数据。 欢快、洁净的 Java 交互环境本文最为关键步骤之一，便是用几行代码，筹备一个洁净的交互式 NebulaGraph Java REPL 环境。 多亏了 Java-REPL，咱们能够很不便地（像 iPython 那样）去实时交互地调试、剖析 NebulaGraph Java 客户端。 上面，开始实操。 先用 Docker 镜像筹备环境： docker pull albertlatacz/java-repldocker run --rm -it \ --network=nebula-net \ -v ~:/root \ albertlatacz/java-repl \ bashapt update -y && apt install ca-certificates -ywget https://dlcdn.apache.org/maven/maven-3/3.8.6/binaries/apache-maven-3.8.6-bin.tar.gz --no-check-certificatetar xzvf apache-maven-3.8.6-bin.tar.gzwget https://github.com/vesoft-inc/nebula-java/archive/refs/tags/v3.0.0.tar.gztar xzvf v3.0.0.tar.gzcd nebula-java-3.0.0/../apache-maven-3.8.6/bin/mvn dependency:copy-dependencies../apache-maven-3.8.6/bin/mvn -B package -Dmaven.test.skip=truejava -jar ../javarepl/javarepl.jar在执行完下面的 java -jar ../javarepl/javarepl.jar 之后，咱们就进入了交互式的 Java Shell（REPL）。咱们不必再做编译、执行、print 这样的慢反馈来调试和钻研咱们的代码了，是不是很不便？ ...

继4月3日甲骨文发表推出收费开发者版 Oracle Database 23c后，墨天轮社区发动 “Oracle 23c 收费开发者版个性体验”有奖征文活动，邀请大家分享Oracle 23c装置部署、性能体验与新个性测评的实操文章。以后曾经收到了数十篇稿件，这里为大家展现局部优质文章 优质文章文章题目作者【ORACLE】极速通关Oracle23c开发者免费版连贯DarkAthena只需三步疾速体验 Oracle 23c 开发版JiekeXu数据库治理-第六十五期 Oracle 23c新个性（20230411）胖头鱼的鱼缸真！手把手让你简略两步领有Oracle 23c刘贵宾数据库治理-第六十六期 SQL Domain（20230413）胖头鱼的鱼缸Oracle 23c新性能一览及局部个性测试刘贵宾ORACLE23C新个性学习-新角色IT烧麦（博）数据库治理-第六十七期 SQL Domain 2（20230414）胖头鱼的鱼缸在openeuler下体验oracle 23c 的装置lqkitten流动处分本次为基于【墨力原创打算】之上的主题征文，一个天然月为流动月。对合格文章的断定规范与【墨力原创打算】统一，需满足原创首发，字数大于500且浏览量需大于50等要求，具体可点击此处查看具体规定。 除了参加【墨力原创打算】的评优以外，本专题征文中的合格文章（翻译文章除外）都能够额定取得100墨值的处分。（点击此处可理解墨值用处） 本次征文接管Oracle 23c相干的装置部署、性能体验与新个性测评等主题文章，也非常欢迎您从其余的角度登程创作。期待酷爱技术、酷爱创作的你参加！点击查看具体规定：https://www.modb.pro/db/525525。参考资料： 产品页面：https://www.oracle.com/database/free下载地址： Docker：https://container-registry.oracle.com/ VM：https://www.oracle.com/database/technologies/databaseappdev-vm.html Linux RPM：https://www.oracle.com/database/technologies/free-downloads.html在线文档：https://docs.oracle.com/en/database/oracle/oracle-database/23/index.html点击查看Oracle 23c 主题投稿作品合集欲了解更多可浏览墨天轮社区，围绕数据人的学习成长提供一站式的全面服务，打造集新闻资讯、在线问答、流动直播、在线课程、文档阅览、资源下载、常识分享及在线运维为一体的对立平台，继续促成数据畛域的常识流传和技术创新。

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。GreatSQL是MySQL的国产分支版本，应用上与MySQL统一。作者： 奥特曼爱小怪兽文章起源：GreatSQL社区原创往期回顾 MySQL8.0 优化器介绍（一） MySQL8.0 优化器介绍（二） 本篇将进一步深刻介绍优化器相干的join优化 为更好的了解本篇内容须要提前看一下以下内容： 单表拜访的办法，参考《MySQL 是怎么运行的：从根儿上了解 MySQL》第10章"单表拜访办法"更多select语句级别的优化细节 见（https://dev.mysql.com/doc/refman/8.0/en/select-optimization.html）为了让读者对join优化 有更深的理解，章节里的sql例子，留了一些思考和入手的问题。可能大家失去的答案会不同，但摸索未知的过程，形式应该是一样的。 join优化（Join Optimizations）MySQL能够应用Join Optimizations来改良上次分享过的join algorithms，或者决定如何执行局部查问。本次次要介绍三种常常用到的join Optimizations，更多的 join type 见上面的链接：（https://dev.mysql.com/doc/refman/8.0/en/explain-output.html#e...） index merge通常MySQL只会对每个表应用一个索引。然而，如果对同一表中的多个列在where后有条件限度，并且没有笼罩所有列的单个索引，无论选哪个索引都不是最佳的。对于这些状况，MySQL反对索引合并 (index merge)。select a,b,c from t where a=x1 and b=x2 and c=x3,这种状况下，建设一个多列的复合索引 index_abc 比应用 index merge +index_a+index_b+index_c 性能更好。 Index merge 反对三种算法 见下表 查问打算应用index merge 时，会在explain sql 的 access type 列 有"index_merge"，key 列会 蕴含所有参加merge的列， key_length 蕴含一个所用索引的最长要害局部的列表。举个Intersection例子： Intersection以下代码块正文中提到的知识点略多 ##无论optimizer 是否抉择 index merge 取决于index statistics. ## index statistics 是从哪个试图取得呢？mysql.innodb_index_stats 还是 information_schema.statistics ## 还是 information_schema.INNODB_SYS_TABLESTATS？ ## 能够参考 https://www.cnblogs.com/ClassicMan/articles/15871403.html## index_dive eq_range_index_dive_limit 这两个参数有什么作用？##意味着即便返回雷同STATEMENT_DIGEST_TEXT的sql查问语句, WHERE语句前面跟不同的值，失去的查问打算可能是不一样的 ##比方select * from people where name='惟一值'；##select * from people where name='超级多的反复值'## 同理index statistics 的扭转会让同一个查问走不同的执行打算，## 体现在 select a,b from t where a=1 and b=1 有时走了 index merges，有时没走。CREATE TABLE `payment` ( `payment_id` smallint unsigned NOT NULL, `customer_id` smallint unsigned NOT NULL, `staff_id` tinyint unsigned NOT NULL, `rental_id` int(DEFAULT NULL, `amount` decimal(5,2) NOT NULL, `payment_date` datetime NOT NULL, `last_update` timestamp NULL, PRIMARY KEY (`payment_id`), KEY `idx_fk_staff_id` (`staff_id`), KEY `idx_fk_customer_id` (`customer_id`), KEY `fk_payment_rental` (`rental_id`)) ENGINE=InnoDB;## case1 等值查问SELECT * FROM sakila.payment WHERE staff_id = 1 AND customer_id = 75; mysql> EXPLAIN SELECT * FROM sakila.payment WHERE staff_id = 1 AND customer_id = 75\G**************************** 1. row ***************************** id: 1 select_type: SIMPLE table: payment partitions: NULL type: index_merge possible_keys: idx_fk_staff_id,idx_fk_customer_id key: idx_fk_customer_id,idx_fk_staff_id key_len: 2,1 ref: NULL rows: 20 filtered: 100 Extra: Using intersect(idx_fk_customer_id,idx_fk_staff_id); Using where 1 row in set, 1 warning (0.0007 sec) mysql> EXPLAIN FORMAT=TREE SELECT * FROM sakila.payment WHERE staff_id = 1 AND customer_id = 75\G**************************** 1. row ****************************EXPLAIN: -> Filter: ((sakila.payment.customer_id = 75) and (sakila.payment.staff_id = 1)) (cost=14.48 rows=20) -> Index range scan on payment using intersect(idx_fk_customer_id,idx_fk_staff_id) (cost=14.48 rows=20)1 row in set (0.0004 sec)##留神"Index range scan on payment",两个等值查问条件，为啥触发了rang scan？## case2 上面的sql范畴查问也能用到index merge 吗？执行打算 本人上来测试验证SELECT * FROM sakila.payment WHERE payment_id > 10 AND customer_id = 318;Union Algorithm##case1 等值查问SELECT * FROM sakila.payment WHERE staff_id = 1 OR customer_id = 318; mysql> EXPLAIN SELECT * FROM sakila.payment WHERE staff_id = 1 OR customer_id = 318\G**************************** 1. row ***************************** id: 1 select_type: SIMPLE table: payment partitions: NULL type: index_merge possible_keys: idx_fk_staff_id,idx_fk_customer_id key: idx_fk_staff_id,idx_fk_customer_id key_len: 1,2 ref: NULL rows: 8069 filtered: 100 Extra: Using union(idx_fk_staff_id,idx_fk_customer_id); Using where1 row in set, 1 warning (0.0008 sec) mysql> EXPLAIN FORMAT=TREE SELECT * FROM sakila.payment WHERE staff_id = 1 OR customer_id = 318\G**************************** 1. row ****************************EXPLAIN: -> Filter: ((sakila.payment.staff_id = 1) or (sakila.payment.customer_id = 318)) (cost=2236.18 rows=8069) -> Index range scan on payment using union(idx_fk_staff_id,idx_fk_customer_id) (cost=2236.18 rows=8069)1 row in set (0.0010 sec) ## case2 范畴查问也能用到index merge 吗？执行打算 本人上来测试验证， ## 有主键参加后，和Intersection 章节的case2 执行打算中用到的索引个数有啥不同？SELECT * FROM sakila.payment WHERE payment_id > 15000 OR customer_id = 318;Sort-Union AlgorithmSELECT * FROM sakila.payment WHERE customer_id < 30 OR rental_id < 10; mysql> EXPLAIN SELECT * FROM sakila.payment WHERE customer_id < 30 OR rental_id < 10\G**************************** 1. row ***************************** id: 1 select_type: SIMPLE table: payment partitions: NULL type: index_mergepossible_keys: idx_fk_customer_id,fk_payment_rental key: idx_fk_customer_id,fk_payment_rental key_len: 2,5 ref: NULL rows: 826 filtered: 100 Extra: Using sort_union(idx_fk_customer_id,fk_payment_rental); Using where 1 row in set, 1 warning (0.0009 sec)mysql> EXPLAIN FORMAT=TREE SELECT * FROM sakila.payment WHERE customer_id < 30 OR rental_id < 10\G**************************** 1. row *****************************EXPLAIN: -> Filter: ((sakila.payment.customer_id < 30) or (sakila.payment.rental_id < 10)) (cost=1040.52 rows=826) -> Index range scan on payment using sort_union(idx_fk_customer_id,fk_payment_rental) (cost=1040.52 rows=826)1 row in set (0.0005 sec)Multi-Range Read (MRR)多范畴读取（MRR）优化旨在缩小对辅助索引进行范畴扫描所导致的随机I/O量。优化读取索引 ...

OceanBase 4.0（小鱼）的首次亮相是在 2022 年 8 月，作为业内首个单机分布式一体化架构的数据库，4.0 版本兼顾了分布式架构的扩展性和集中式架构的性能劣势，在等同硬件条件下实现单机性能赶超集中式数据库的同时，帮忙用户极大地升高了分布式数据库的应用门槛。 4.0 版本公布后，咱们收到了很多一线开发者的贵重倡议，而 4.1 版本也从开发者的角度登程，设计了许多晋升性能和效率的能力。 3 月 25 日，OceanBase 开发者大会·2023 在北京举办，大会上正式公布的 OceanBase 4.1 版本减少了旁路导入、租户级别物理备库、MySQL 8.0 兼容等多项面向开发者的能力。经测试，4.1 的小规格环境 TP 性能 sysnbench 综合读写能力相比 4.0 晋升 40%，TPC-H 100G 场景性能比 4.0 晋升 17%，TPC-DS 100G 场景性能比 4.0 晋升 15%。 “小鱼”的诞生与成长离不开宽广开发者的陪伴与反对，咱们十分兴奋能把 4.1 版本的这一系列新能力带给大家，“小鱼”会游得更快更远，也会陪伴更多数据库开发者一起成长。 即日起，OceanBase 启动第七期技术征文活动「小鱼快跑｜OceanBase 4.1 上手体验」，咱们欢送宽广数据库开发者畅谈 OceanBase 4.1。 无论你是数据工程师、DBA、利用开发者、架构师，还是其余数据库厂商的用户，又或是对数据库充斥趣味的爱好者，咱们都期待你的参加，期待“小鱼”能成为你的敌人。 除了稿酬、证书，咱们还特地为本次征文活动筹备了树莓派、静止手环等限定周边，快来参加吧～ 01 工夫安顿文章投稿： 4 月 18 日——5 月 22 日 评审阶段： 4 月 19 日——5 月 23 日 专家评优： 5 月 24 日——5 月 30 日 ...

在 3.0.3.0 公布一个月后，通过研发小伙伴加班加点地进行优化迭代，3.0.4.0 也在明天胜利出炉。从用户应用体验角度登程，这一版本进一步晋升了时序数据库（Time Series Database） TDengine 3.0 的稳定性，并优化了多个利用性能，产品性能加强的同时易用性也取得大幅晋升。 3.0.4.0 版本波及到的更新内容包含产品稳定性的晋升、查问性能晋升、参数应用优化、以及多正本状况下的健壮性晋升、Python UDF、集群负载再均衡、基于时间段进行数据重整等九大方面。具体更新信息如下： 1. 大幅晋升产品稳定性在大并发、高负载的写入和查问下的零碎稳定性有显著晋升：优化了对内存的应用，优化了有大量并发查问下对连接池的管制，修复了一些影响零碎稳定性的缺点。 2. 晋升了局部查问场景下的性能晋升了当与 interval() 一起应用时 mode() 函数的性能晋升了 percentile() 函数的性能晋升了 last()/last_row() 函数的性能3. 能够动静配置更多数据库参数新增两个能够动静配置的数据库参数：stt_trigger 和 minRows，其具体性能请参考官网文档。 4. 优化了 WAL 数据保留的行为WAL 中数据的保留仅受参数 WAL_RETENTION_PERIOD 和 WAL_RETENTION_SIZE 的管制，不再受数据订阅的影响。具体细节请参考官网文档。 5. Python UDF利用开发者能够用 Python 开发自定义函数并将其嵌入数据库，从而晋升数据处理和剖析能力。 6. 集群负载再均衡 （企业版性能）当集群中某个 dnode 宕机重启后会呈现负载不平衡景象，重新启动的 dnode 上没有 leader vnode，所以不承当任何写入和查问负载。通过 rebalance 命令，能够使集群中各个 dnode 之间的负载再次平衡。 7. 基于时间段进行数据重整 （企业版性能）为了缩小数据重整所破费的工夫，最小化对系统的影响，能够指定时间段进行数据重整，只针对确定有乱序数据的时间段或者查问所关注的时间段进行数据重整。 8. 可能将多种工业互联网中的传统数据源接入TDengine （企业版性能）OPC UAOPC DAPi9. 集中控制台 taosExplorer 治理数据源和数据接入工作 （企业版性能）同步加强了集中控制台 taosExplorer 以可能管理所反对的各种数据源和与它们所关联的数据接入工作。 详细信息能够参考公布阐明(https://github.com/taosdata/TDengine/releases/tag/ver-3.0.4.0)。欢送大家下载应用 TDengine，有任何问题，都能够增加小T vx：tdengine1 申请加入 TDengine 用户交换群，及时向咱们的解决方案专家寻求反对与帮忙。 ...

近日，由阿里云开发者社区、极客工夫、PolarDB开源社区联结出品的「阿里云巨匠课：PolarDB 高手课」课程正式上线。本系列巨匠课，阿里云开发者社区联结极客工夫团队，开创性地布局了技术点输入+访谈的模式，技术点输入2小时，访谈1小时，关上用户大厂技术视线，沉迷式承受高P专家心法。 数据库作为一类传统的、承前启后的根底软件，正被“云原生+开源”赋予了一种新的生命力。 近几年，云原生技术正从各个方面引领着数据库技术的倒退，数据库开源也逐步成为一种趋势。本期，咱们邀请了阿里云数据库技术架构部负责人，资深技术专家王远老师（花名：惊玄），分享了以阿里云自主研发的新一代云原生数据库 PolarDB 系列为例的数据库解读课程。 课程收费学习地址 课程背景PolarDB是阿里云自研的数据库产品家族，采纳存储计算拆散、软硬一体化设计，既领有分布式设计的低成本劣势，又具备集中式的易用性，可满足大规模利用场景需要。 PolarDB是业内独创反对跨机Serverless服务的云数据库，冲破了无感秒切和高性能全局一致性两大技术难点，与依照峰值负载配置容量的老本相比，最多可节俭95%的数据库老本。同时，PolarDB数据库的云原生HTAP性能，在列存索引IMCI技术加持之下，TPC-C、TPC-H性能实现行业大幅当先。2021年PolarDB发表开源，同时也是被阿里重点反对的开源我的项目之一。本系列课程将对PolarDB开源技术和实际、上云方法论进行一个整体的解读。 巨匠简介王远，花名惊玄，阿里云数据库技术架构部负责人，资深技术专家，开源PolarDB负责人，南京大学博士，先后在电力、能源、公安、军工等行业从事数据仓库及大数据平台的研发工作，屡次取得省部级科技进步奖及国家级荣誉称号，同时也负责云数据库整体架构、数据迁云计划及高校单干相干工作。 面向人群● 高校学生：理解数据库技术的钻研畛域及技术前沿；● 数据库开发者： 坚固数据库系统常识，并心愿对云原生数据库PolarDB有一个全局的意识，理解 PolarDB 的架构设计，进一步理解数据库上云的最佳实际方法论；● 数据库爱好者： 入门数据库，但不晓得从何学起，想理解数据库畛域都有哪些新机遇和新方向。 你将学到• 揭秘数据库技术发展趋势与时机• 读懂 PolarDB-X 与 PolarDB-PG 外围原理• 把握 PolarDB-X 与 PolarDB-PG 实际计划• 5个数据库疾速上云要点实操 课程目录 访谈目录• 介绍一下本人和团队？• 云原生数据库的历史倒退和将来趋势• PolarDB的诞生背景和布局• 带团队做数据库研发中印象粗浅的故事• PolarDB开源的初心和指标• 数据库开源社区建设要关注哪些因素• 如何解读数据库演进的推动力• 给数据库开发者的职业倒退倡议

为了验证 TDengine 3.0 的性能，咱们应用第三方基准性能测试平台 TSBS（Time Series Benchmark Suite） 中针对 DevOps 的 cpu-only 五个场景作为根底数据集，在雷同的 AWS 云环境下对 TDengine 3.0 和 InfluxDB 1.8（该版本是 InfluxDB 可能运行 TSBS 框架的最新版本） 进行了比照剖析。在本篇文章中，咱们将从写入、存储、查问、及资源开销等几大维度对测试后果进行汇总剖析，给到大家参考。 咱们采纳下方 TimescaleDB vs. InfluxDB 比照报告中举荐的形式配置 InfluxDB，将缓冲区配置为 80G，以便 1000W 设施写入时可能顺利进行，同时开启 Time Series Index（TSI）。配置零碎在零碎插入数据实现 30s 后开始数据压缩。 TimescaleDB vs. InfluxDB: Purpose Built Differently for Time-Series Data：https://www.timescale.com/blog/timescaledb-vs-influxdb-for-ti... 对于零碎的配置详情、如何一键复现测试后果及具体的测试数据介绍等内容，大家可参考《一键获取测试脚本，轻松验证“TSBS 时序数据库性能基准测试报告”》、《TSBS 是什么？为什么时序数据库 TDengine 会抉择它作为性能比照测试平台？》两篇文章，本文便不再赘述。 写入性能最高达到 InfluxDB 的 10.6 倍总体而言，在 TSBS 报告全副的 cpu-only 五个场景中，时序数据库（Time Series Database）TDengine 写入性能均优于 InfluxDB。相比 InfluxDB，TDengine 写入速度最当先的场景是其 10.6 倍（场景五），起码也是 3.0 倍（场景一)。此外，TDengine 在写入过程中耗费了起码 CPU 资源和磁盘 IO 开销。上面看一下具体分析： ...

4月22日，云数据库技术沙龙“MySQL x ClickHouse”专场“MySQL x ClickHouse” 技术沙龙，本次沙龙以“技术进化，让数据更智能”为主题，汇聚字节跳动、阿里云、玖章算术、华为云、腾讯云、百度等泛滥数据库厂商的技术大咖， 围绕MySQL x ClickHouse的实践经验，与宽广技术爱好者交换分享。参会报名：https://www.ninedata.cloud/cdb 流动简介MySQL 是毫无争议的最受欢迎的数据库，在事实世界中反对了有数大大小小的业务场景；ClickHouse则是最近几年增长最疾速的开源剖析型数据库，因为其对于性能的极致谋求，使其即便是单机的状况下，也有着十分优良的性能体现。而这也十分好的补救了MySQL在简单剖析查问上的性能短板。这次，咱们就一起来看看MySQL x ClickHouse会碰撞出怎么的火花。 议题一：ByteHouse云数仓版查问性能优化和MySQL生态欠缺 游致远｜火山引擎ByteHouse资深研发工程师 嘉宾简介：火山引擎资深研发工程师，负责ByteHouse云数仓版引擎计算模块。之前先后就任于网易、菜鸟团体、蚂蚁团体，有多年大数据计算引擎、分布式系统相干研发经验。 主题介绍：ByteHouse云数仓版是字节跳动数据平台团队在复用开源 ClickHouse runtime 的根底上，基于云原生架构重构设计，并新增和优化了大量性能。在字节外部，ByteHouse被宽泛用于各类实时剖析畛域，最大的一个集群规模大于2400节点，治理的总数据量超过700PB。本分享将介绍ByteHouse云原生版的整体架构，并重点介绍ByteHouse在查问上的优化（如优化器、MPP执行模式、调度优化等）和对MySQL生态的欠缺（基于社区MaterializedMySQL性能）。最初结合实际利用案例总结优化的成果。 议题二：HTAP for MySQL在腾讯云数据库的演进 陆洪勇｜腾讯TEG数据库产品部高级技术专家 嘉宾简介：曾在SAP做过多年HANA数据库内核的设计与研发，阿里云Polardb数据库内核的设计与研发。目前在腾讯云数据库做HTAP for MySQL相干产品的设计与开发。 主题介绍： MySQL在充分利用多核计算资源方面比拟欠缺，无奈同时满足在线业务和剖析型业务的客户需要，而独自部署一套专用的剖析型数据库意味着额定的老本和简单的数据链路。本次主题将介绍腾讯云数据库为满足此类场景而在HTAP for MySQL产品方面进行的尝试。 议题三：多云多源下的数据复制技术揭秘-NineData 陈长城（天羽）｜玖章算术技术副总裁 嘉宾简介：陈长城（天羽），玖章算术技术副总裁，前阿里云资深技术专家，在数据库畛域深耕15年，主导了阿里数据库基础架构演进（IOE到分布式、异地多活、容器化存计拆散）和云原生数据库工具体系建设。 主题介绍：随着数据智能时代的到来，多云多源架构下的数据管理是企业必备的基础设施，咱们认为数据存取、数据集成与散发、数据安全与数据品质是根底，也是走向多云多源架构的终点。本议题介绍云原生的多云多源数据管理NineData，重点介绍MySQL、ClickHouse相干的数据管理和复制技术。 议题四：阿里云数据库ClickHouse产品和技术演讲嘉宾： 刘扬宽｜阿里云数据库ClickHouse技术研发 嘉宾简介：刘扬宽，阿里花名留白，从事数据存储与数据处理系统研发十余年，先后在中科院计算所，中国移动苏州研发核心参加存储系统研发。2019年退出阿里云参加外部产品的存储计算拆散的架构降级。在云原生ClickHouse的研发中，承当存储模块的负责人，依据计算层拜访存储系统的特点，有针对地优化了存储系统，晋升了云原生ClickHouse的整体性能。 主题介绍：社区ClickHouse的单机引擎性能非常惊艳，然而部署运维ClickHouse集群，以及troubleshoot都不是很好上手。本次分享阿里云数据库ClickHouse产品能力和个性，蕴含同步MySQL库、ODPS库、本地盘及多盘性价比实例以及自建集群上云的迁徙工具。最初介绍阿里云在云原生ClickHouse的停顿状况。 议题五：GaussDB(for MySQL)云原生数据库技术演进和挑战 周家恩｜华为云数据库高级产品经理 嘉宾简介：10年以上数据库技术运维，产品治理教训，先后在多家TOP云厂商任职产品经理，相熟MySQL，SQL Server等多款数据库治理，保护以及商业经营工作，现任华为云数据库高级产品经理，负责原生数据库GaussDB(for MySQL)产品治理和设计，经营工作 主题介绍：GaussDB(for MySQL)是华为自研云原生数据库，具备高性能，高扩大，高牢靠的特点，齐全兼容MySQL协定，自研架构和敌对的生态兼容性，能够同时满足数据库管理员、利用开发者、CTO的运维、应用和业务倒退需要，本次次要介绍GaussDB(for MySQL)在云原生技术方向上遇到的挑战和将来的倒退演进门路。 议题六：百度云原生数据库GaiaDB的HTAP与多地多活技术实际 邱学达｜百度数据库资深技术专家 嘉宾简介：百度数据库资深技术专家，次要负责分布式架构设计与数据库内核个性设计和开发。多年数据库与分布式存储开发教训，专一于分布式高可用+高牢靠架构设计与云原生化革新。在分布式性能优化、端到端可用性晋升方面具备丰盛教训 演讲主题：云原生数据库在应用存算拆散技术后，能够在齐全兼容MYSQL协定和语法的状况下，极大晋升单实例所能承载的数据规模与吞吐能力下限。但除了对客户端兼容外，对整个数据生态（地区容灾，数据分析，备份复原）的适配同样须要大量的设计优化工作。本次分享GaiaDB在跨地区/异构数据同步场景下，吞吐/实时性/一致性方面能力打造与实践经验。

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。GreatSQL是MySQL的国产分支版本，应用上与MySQL统一。作者： KAiTO文章起源：GreatSQL社区原创因为交换群中涌入了越来越多的对GreatSQL感兴趣的开源爱好者，也有许多的初学者，初学者可能对Linux等平台较为生疏，为了能够让更多的人尝试和应用上GreatSQL，特此出一篇教程让GreatSQL能够在Windows上应用 开始装置因为GreatSQL源码不好编译到Windows平台上，所以咱们应用在Windows开启一个Docker容器，话不多说，跟着我一起入手操作吧！ 第一步查看Windows 相干配置1.启用虚拟化关上工作管理器点击性能点击CPU看看是否启用了虚拟化 2.启用Hyper-v关上控制面板（Win+R -> 输出control -> 回车） 记得点击右上角查看形式为“小图标”，点击程序和性能 启用或敞开Windows性能 勾选Hyper-v 开启Hyper-v 与 英特尔VT 虚拟化会造成抵触，可能会影响到大部分安卓模拟器和旧版的VMware虚拟机的应用，若要应用安卓模拟器请不要开启，或能够更换基于Hyper-v 的安卓模拟器/子系统和新版本的VMware这时候会弹出一个搜寻须要的文件急躁期待即可，而后点击重启计算机 第二步下载Docker一、下载Docker 进入以下连贯下载Docker桌面https://docs.docker.com/desktop/windows/install/ 二、装置Docker 双击关上装置即可装置实现后还须要重启一次 重启后可看到这个图标点击Accept 能够看到会让你降级WSL 点击连贯进入下载下载实现后装置后再次开启Docker Desktop 能够曾经实现了Docker Desktop的装置 能够来更换一下镜像地址： { "registry-mirrors": [ "https://registry.docker-cn.com", "http://hub-mirror.c.163.com", "https://docker.mirrors.ustc.edu.cn" ], "insecure-registries": [], "debug": false, "experimental": false, "features": { "buildkit": true }, "builder": { "gc": { "enabled": true, "defaultKeepStorage": "20GB" } }}在国内拜访 Docker 官网的镜像，速度都很慢。为了快速访问 Docker 官网镜像都会配置三方加速器，目前罕用三方加速器有：网易、USTC、DaoCloud、阿里云。接下来咱们来装置 GreatSQL 装置GreatSQL在Docker Desktop上方搜寻 GreatSQL ...

本文为大家整顿了墨天轮数据社区2023年3月公布的优质技术文章，主题涵盖Oracle、MySQL、PostgreSQL等数据库的根底装置配置操作、故障解决、性能优化等日常实际操作，以及概念梳理、罕用脚本等总结记录，分享给大家： Oracle优质技术文章概念梳理&根底配置 Oracle之数据文件和临时文件治理Oracle 19C 如何设置PDB备库 disable recovery 并疾速恢PDB复案例剖析干货！EBS 12.2克隆具体步骤过程Oracle创立表空间，数据库到底做了什么Oracle DG PDB数据同步学习以优雅的形式对oracle分区表进行分区拆分操作故障剖析与解决 Oracle X7一体机存储节点重启导致u01使用率一直增大Oracle 19c RAC 不同架构下压测性能比照剖析报告诡异的ORA-17503: ksfdopn: 2 DATA/jyc/PASSWORD/pwdjyc.263.1131705075利用rman备份库调优生产sql级联DG——常见问题Oracle 故障解决|V$ACTIVE_SESSION_HISTORY 视图没有数据Oracle解决错误代码ORA-04031一例一起由级联DG配置不标准引发的生产事变MySQL、PG及国产数据库相干技术文章MySQL相干技术文章 MySQL 8.0 MGR 日常运维命令MySQL8.0 用户表性能加强MySQL8.0 GA Encryption加密MySQL8.0查找长期事物MySQL优化实战之当语句自身无奈优化时，换个思考形式一文具体讲清楚 MySQL为什么是小表驱动大表？在麒麟桌面版操作系统（X86_64、ARM）装置MySQLPG相干技术文章 【合辑】PostgreSQL + 数据库可观测技术（eBPF）实操pg_lock_tracer实现数据库服务可观测PostgreSQL如何并行逻辑备份和复原如何查看 PostgreSQL 过程占用内存状况pg_basebackup 在 PostgreSQL 15 中的新个性自定义 Dockerfile 构建 PostgreSQL 15 编译版 Docker 镜像Greenplum执行打算剖析国产数据库相干技术文章 疾速搭建 GBase 8c 集群环境GBase 8c 分布式数据库 常用命令 & 常见问题 集锦OMS 4.0 实现 mysql 8.0 MGR 到 oceanbase 4.0 的迁徙基于阿里云数据库TiDB的性能压测初体验某公共零碎数据还原达到梦I系列一体机实战演示这些文章选题都是大家日常可能会遇到的状况，文章构造残缺、逻辑清晰，其中故障解决主题类文章均蕴含问题景象（具体报错等）、问题定位与剖析 、 问题解决、问题总结等几个方面，可参考价值很强，心愿对大家有所帮忙。 墨天轮数据社区是一个业余的数据技术内容分享社区，会集了来自各行业的专家大咖、一线技术人员，他们勤于记录、乐于分享，公布了泛滥国内外数据库技术相干的优质实操文章、文档。在这里，咱们定期将为大家整顿墨天轮网站上的优质内容，以月度进行公布展现。若您想每日获取最新技术干货，也可增加墨天轮小助手（VX：modb666）理解征询。 另外，墨天轮社区正在举办“墨力原创作者打算”，收集了不少对于Oracle、MySQL、PG以及国产数据库相干的实操文章投稿，欢送大家点击此处查阅全副文章。另外也欢送大家退出投稿，咱们筹备了合格奖、新人奖、勤更奖等的现金、礼品的处分，点击此处理解流动详情。

当企业须要建设独立的数据仓库零碎来撑持BI和剖析业务时，有了“数据湖+数据仓库”的混合架构。但混合架构带来了更高的建设老本、治理老本和业务开发成本。随着大数据技术的倒退，通过在数据湖层减少分布式事务、元数据管理、极致的SQL性能、SQL和数据API接口能力，企业能够基于对立的架构来同时反对数据湖和数据仓库的业务，这就是湖仓一体架构。本篇持续介绍星环科技Inceptor和Apache Delta Lake。 — 星环科技Inceptor— 星环科技 Inceptor是一个分布式的关系型剖析引擎，于2013年开始研发，次要用于ODS、数据湖以及其余结构化数据的剖析型业务场景。Inceptor反对绝大部分ANSI 92、99、2003 SQL规范，兼容传统关系型数据库方言，如Oracle、IBM DB2、Teradata等，并且反对存储过程。2014年起，国内一些银行客户开始尝试将一些本来在DB2上一些性能有余的数据加工业务，迁徙到Inceptor上，而这些本来构建在关系型数据库上的数据工作有大量的并发update、delete的需要，并且存在多个数据链路加工一个后果表的状况，因而有很强的并发事务性能要求。此外，因为用户不仅冀望实现数据批处理业务从关系数据库迁徙到Hadoop平台上，并且冀望性能上有数量级上的晋升，因而星环科技从2014年开始研发基于HDFS的分布式事务机制，以撑持局部数据仓库的业务场景，到2016年随着Inceptor 4.3版本正式公布了相干的技术，并后续几年在数百个金融行业用户落地生产，技术成熟度曾经金融级要求。 Inceptor的总体架构图如上，因为ORC是列式存储，有十分好的统计分析性能，咱们抉择基于ORC文件格式来二次开发分布式系统。因为HDFS也不反对文件的random access和文件内的事务操作，因而对数据的并发update和delete，咱们采纳了MVCC机制，每次提交的数据更新，不间接对数据文件进行改写，而是对数据文件减少一个相应的新版本，一个事务内的所有的数据操作都写入一个delta文件中。读取数据的时候再将所有文件数据读入内存，并且在内存中对多个文件中的同一个数据依照事务程序和可见性来做合并，也就是Merge on Read机制。 须要强调一点，数据仓库上都是数据批处理加工，批处理的数据业务每个SQL都可能操作的数据量比拟大，单个的SQL操作须要的延时可能是几十秒甚至是分钟级以上，它对分布式事务的性能要求是几十到几百TPS，而不是分布式数据库面向交易型业务须要的几万甚至更高的TPS。锁抵触是批处理状况下并发性能的一个次要瓶颈点。如果同时有多个ETL工作在加工一个数据表，那么这个表很有可能就会呈现锁抵触，从而导致数据工作之间呈现锁期待而拖慢最终加工节奏。为了解决性能问题，咱们开发了一个独立的Lock Manager来治理分布式事务的产生与可见性判断，同时锁的粒度包含Database、Table和Partition三个粒度，这样就缩小了很多的不必要的锁抵触问题。 此外，在数仓加工过程中，很多表既是上一个加工工作的后果表，也是其余数据工作的数据源头，因而也会存在读写抵触问题，局部状况下会导致并发受限。为了解决这个问题，咱们引入快照（snapshot）机制和Serializable Snapshot的隔离级别，数据表的读操作能够间接读取某个快照，这样就无需跟写操作产生事务抵触。在咱们的设计中，快照不须要长久化，无需减少大量的物理存储，而是一个轻量级的、全局统一的逻辑概念，在事务处理中能够疾速判断数据的某版本该当蕴含还是排除。 在事务的隔离性上，Inceptor反对Read uncommitted、Read committed、Repeatable reads、Serializable和Serializable Snapshot这5种隔离级别。在并发控制技术上，Inceptor 提供了乐观和乐观两类可序列化隔离级别：基于严格的两阶段锁的串行化隔离级别和基于快照的序列化隔离级别。用户能够依据业务场景抉择适宜的隔离级别类型。严格的两阶段锁的序列化隔离（S2PL Based Serializable Isolation）是一种乐观的并发控制技术，其次要特点是先取得锁，再解决读写，直到事务提交实现后才开释所有锁。它的实现比拟不便，次要难点是解决好死锁问题（通过环检测解决）。该技术的读写无奈并发，因而事务处理的并发性能较差。而可序列化快照隔离（Serializable Snapshot Isolation）可能进步事务处理的并发性能，采纳了基于乐观锁的可序列化快照隔离，该技术的劣势是不会产生两阶段锁技术中读写操作相互阻塞的状况，使得读写互不阻塞，进步了并发度。尽管快照隔离也不会呈现脏读、不可反复读、幻读景象，但它并不能保障可序列化，在解决并发的事务时，依然可能因为不满足束缚（Constraints）而产生异样，称之为写偏序问题（Write Skew）。为解决写偏序问题，Inceptor引入对可序列化快照抵触的查看，减少了对快照隔离级别下事务间的读写依赖关系中环的检测来发现相干的抵触问题并abort异样的事务。 如上文所述，Inceptor在分布式事务的并发能力、事务隔离性、SQL性能等方面的技术积攒比拟残缺，此外从2016年就开始被金融业大量采纳，在数据仓库的场景下Inceptor的成熟度比拟高。因为Inceptor设计上不是为了机器学习的场景，因而没有提供间接给机器学习框架应用的数据API层。另外，Inceptor也没有独自设计面向实时数据写入的架构，也不能无效的反对流批一体的架构，不过星环科技在分布式数据库ArgoDB中解决了流批一体的需要问题。 — Apache Delta Lake — 因为Databricks Cloud上大量用户运行机器学习工作，因而Databricks的次要设计指标包含： 优良的SQL性能数据分析的性能是BI和剖析类软件的外围要求，因而须要采纳列式文件格式（如Parquet等）等适宜统计分析的格局，以及向量式计算引擎、数据拜访缓存、层级化数据存储（如冷热数据拆散存储等技术）等技术，来晋升数据湖内SQL统计分析的性能，达到数据仓库的技术要求 提供分布式事务和schema反对数据湖的存储多以文件形式，采纳的schemaless形式，这位数据分析提供了灵活性，然而就无奈实现数据库的ACID治理能力。Delta Lake欠缺了文件存储，提供严格的数据库schema机制，之后研发了一套基于MVCC的多版本事务机制，这样就进一步提供数据库的ACID 语义，并且反对高并发的update和delete的SQL操作。此外，Delta Lake基于凋谢的数据格式（Parquet），这样既能够间接操作HDFS，也让其余计算引擎能够拜访相干的数据，进步了生态兼容性。 灵便对接机器学习工作和摸索式剖析的数据API机器学习和AI训练任务对Databricks的外围业务场景，因而Delta Lake在设计上十分重视保障的这类业务的撑持，其不仅提供DataFrame API，还反对Python、R等编程语言接口，还强化了对Spark MLlib、SparkR、Pandas等机器学习框架的整合。 基于以上能力，联合Spark的计算能力和Delta lake的存储能力，就能够实现齐全基于Databricks存算技术的数据架构，能够反对BI统计分析、实时剖析以及机器学习工作，另外Delta Lake基于凋谢的数据存储格局，也能够对接其余的计算引擎如Presto做交互式剖析。 在我的项目的初始设计指标上，Hudi侧重于高并发的update/delete性能，Iceberg侧重于大量数据状况下的查问性能，而Delta Lake设计的外围是为了更好的在一个存储上同时反对实时计算和离线计算。通过与Spark Structured Streaming的深刻整合，delta table不仅能够做Streaming的数据源，也能够间接作为Streaming的指标表，此外还能够保障Exactly-Once语义。Delta社区联合multi-hop数据架构设计了一套流批一体的参考架构设计，可能做到相似Kappa架构的一份数据存储响应流批两种场景需要。 因为Databricks对Delta Lake的开源绝对受限，局部性能须要依赖Databricks File System以及Engine能力比拟好，因而社区外面的关注度上不如Huid和Iceberg。此外，设计上Delta Lake并不提供主键，因而高并发的update/delete不如Hudi，也不提供相似Iceberg的元数据级别的查问优化，因而查问性能上可能不如Iceberg，然而Delta Lake强调的是联合Spark造成的流批一体的数据架构以及对机器学习类利用的原生API级别的反对，可实用的业务场景有很好的普遍性。 — 小结— 从工夫维度上看，星环科技Inceptor是最早开始摸索在数据湖上提供数据仓库能力的产品，并且在2016年即实现产品的规模化上生产，因而产品成熟度较高，尤其是在分布式事务实现的齐备性上更是有显著的劣势。 ...

2023年3月31日，IvorySQL开源我的项目的文档核心进行了一次更新，如果您对此感兴趣，请点击 https://docs.ivorysql.org/index.html对咱们簇新的文档核心进行拜访。 文档核心采纳「Antora」工具生成，文档格局采纳asciidoc格局。 倒退未有穷期，任重而道远。IvorySQL开源社区始终保持开源共享的理念并且欢送每一位违心恪守「社区行为准则」的小伙伴的退出。文档核心还在欠缺，社区的每一份力量都肯定会使得IvorySQL社区更加强健。 为了您能在发现错误时做出的「commit」更容易接受，您须要理解咱们文档的标准格局，以便您在批改时可能失去失当的后果。如果您平时习惯书写markdown语言，那么您仅须要在书写时依照下文做一些小小的调整；如果您没有接触过此类标记语言，那么下文同样能够帮忙您以最小的老本达成您提交批改的目标。 规格格局在书写adoc格式文件时，不要吝于应用换行和空格，多应用换行和空格可能会帮你更容易失去你想要的后果。 网址链接如果您批改的内容波及到网址链接，请您依照以下格局批改： https://docs.ivorysql.org[IvorySQL文档核心]如果这个链接前后呈现了注释内容，请切记增加一个空格隔开以使这个链接失效。相似如下： 文本 https://docs.ivorysql.org[IvorySQL文档核心] 文本代码块如果您想批改代码块的内容，或者新减少一个代码块内容，您能够参照上面的格局进行书写： [source,c/java/python/doc/SQL/...]----This is a code block.You can write code at here.----留神，以下格局同样是标准的： ----This is a block of text.You can write anything at here.----题目adoc格局的文件同样兼容md格局中采纳#来表明题目，不过在adoc文件中更加标准的格局为采纳=。例如，md格局文档中。 # 一级题目## 二级题目### 三级题目#### 四级题目##### 五级题目在adoc格局文档中。 = 一级题目== 二级题目=== 三级题目==== 四级题目===== 五级题目留神：adoc格式文件题目级别仅到第六级，请留神题目级别的书写。 有序列表和无序列表adoc格式文件应用.来生成有序列表。 . 一级列表1. 一级列表2.. 二级列表1... 三级列表1.. 二级列表2. 一级列表3adoc格式文件应用*,-来表明列表。 * 一级列表** 二级列表*** 三级列表或者* 一级列表- 二级列表** 三级列表如果以上这些仍不能满足您的批改需要，您能够参照 「asciidoc官网」 https://docs.asciidoctor.org/asciidoc/latest/  来持续学习如何书写标准的adoc格局的文档。 Antora环境筹备（Linux环境）//装置nodecurl -o https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.1/install.sh | bash //配置环境变量vi .bashrcexport NVM_DIR="$([ -z "${XDG_CONFIG_HOME-}" ] && printf %s "${HOME}/.nvm" || printf %s "${XDG_CONFIG_HOME}/nvm")"[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" # This loads nvmsource .bashrc//应用node版本nvm install 16//装置antoranpm i -g @antora/cli@2.3 @antora/site-generator-default@2.3antora -v以上为antora的linux装置步骤，仅供参考。 详情能够参考  https://consolelog.gitee.io/docs-antora/antora/2.3/install/in... 如果您更习惯于应用其余的操作系统环境，您能够参考「antora官网」，来装置antora。 Antora应用通过上述步骤，您的零碎中曾经装置好了antora工具。 playbook.yml 的筹备在运行antora工具来将您的adoc文件组织成html文件时，您须要提前准备一个playbook.yml文件，您须要在该文件中筹备以下内容: site:   title: #这里是您的网页题目  url: #这里是您网址的公网地址  start_page: #这里是点击您网址的公网地址时，用户最先看到的页面content:  source:  - url: #这里是您网页原内容的地址，个别是github等具备版本控制的我的项目托管平台，如果您有多个我的项目，您能够在新一行增加url。    branches: #这里能够填写您具体想从哪几个分支外面获得内容，如果下面的url指向的我的项目仅有一个分支，能够疏忽该值ui:  bundle:    url: #这里是您组织成网页所需框架的地址    snapshot: #个别写true，这样每次运行antora时都会从新获取一次ui框架，保障您对ui的任何更新都能够实时体现在您的网页上以上内容是一个playbook.yml的根本内容。上面是antora文档核心在建设过程中的一个测试用处的yml文件： site:  title: IvorySQL Document Site  url: https://docs.ivorysql.org  start_page: ivorysql-doc::welcome.adoccontent:  sources:  - url: https://github.com/DutMsn/ivory-docs.git    branches: [master,v1.0,v1.1,v1.2,v1.3,v1.4,v1.5,v2.1,v2.2]asciidoc:  attributes:    experimental: ''    idprefix: ''    idseparator: '-'    page-pagination: ''ui:  bundle:    url: https://raw.githubusercontent.com/IvorySQL/ivory-doc-builder/main/templates/ui-bundle.zip    snapshot: trueruntime:  fetch: true您同样能够在antora的官网上获取到一个用于入门antora的playbook.yml文件，以便您能够在您的电脑上疾速的胜利运行一次antora，这种正反馈对于您之后的学习十分有帮忙。 antora.yml的筹备在胜利运行过antora，并且胜利生成了与源文件绝对应的网页之后，您可能不满足于生成一些简略的demo，同样的，置信您也留神到通过antora工具生成的网页具备版本控制的特点，这对于治理那些通过迭代逐步成熟的我的项目的文档零碎以及具备多种生态工具的我的项目的文档零碎是十分便当的。 通过对上述操作的复现以及antora官网的学习，置信您对于modules曾经获得了初步的理解，要留神，每一个modules文件对应的同级目录下，应该筹备一个antora.yml文件以供antora工具在运行时，可能正确辨认您的文件内容并依照对应版本组织到适合的地位。以下为一个antora.yml文件的根本内容： name: #这里是您其中一个组件的名字，该值的缺失可能会导致antora无奈胜利运行title: #这里是该文件放在网页时，您心愿显示的名字，您能够自在编写，不会影响antora的编译version: #这里是该文件对应的版本号，您能够自在编写，不会影响antora的编译start_page: #这里是当用户点击对应版本号时，你心愿跳转呈现的页面nav:- #这里须要写明您文件的导航文件的门路以下为IvorySQL文档核心在建设过程中用于测试的antora.yml文件内容 name: ivorysql-doc-cntitle: IvorySQLversion: v2.2start_page: welcome.adocasciidoc:  attributes:    source-language: asciidoc@    table-caption: falsenav:- modules/ROOT/nav.adocnav.adoc的筹备nav.adoc是生成网页的导航栏内容文件，您能够在这里取得您对于nav.adoc的所有内容。 https://docs.antora.org/antora/latest/navigation/multiple-lis...  运行anotra筹备好上述文件以及您的源文件（留神是.adoc文件）之后，您就能够通过运行antora playbook.yml命令来生成您的网页了。 如果一切顺利，在您相熟antora的简略用法之后，您在运行时就能够增加参数来使得生成网页的工作更加效率。尝试以下命令； antora generate --to-dir ../demo playbook.yml --stacktrace✨以上，是IvorySQL文档核心建设过程中，对于antora工具应用的一些教训，心愿可能帮忙到你！ 最初，欢送退出到咱们的IvorySQL社区。 官网网址： https://www.ivorysql.org/zh-cn/ 社区仓库： https://github.com/IvorySQL/IvorySQL IvorySQL社区欢送并赞叹所有类型的奉献，期待您的退出！ 还有，别忘了在Github给咱们一个 ⭐奥~

天气转暖，一年一度的踏青季到来，微度假、周边游炽热，而户外露营则是其中尤受欢迎的一种。从市场规模来看，中国露营经济外围市场规模已从2014年的100亿增至2022年1134.7亿元，带动周边市场规模达5816.1亿元。 露营的“最佳拍档”一次沉迷式的户外露营体验须要各类电子设备加持，无论是电磁炉、电饭煲等烹饪电器，还是电脑、手机等数码产品，再到投影仪等娱乐设施都能为露营流动削减许多荣耀。而这些电子设备则须要一个弱小的电力能源在前面撑持。 依据CBNData数据，超六成用户偏向两天一夜的深度户外活动，个别用电时长在12-48小时左右，近九成的露营爱好者示意，可继续供电设施对户外活动来说尤为重要。 外放电性能完满符合户外用电需要在燃油车时代，露营的工具车只是被当成将露营道具从 A 点搬运到 B 点的搬运工具。进入新能源时代，许多车型都减少了外放电性能。这一配置，让新能源车成为了露营的新宠——只需一根藏身于后备厢盖板下的小小放电枪，就能使你体验到热腾腾的火锅，电烤盘的烧烤，制冰机为高兴水、冰美式带来陈腐的冰块，以及茶余饭饱后投影仪提供的露天电影。 新能源车市场欣欣向荣新能源车行业市场也在露营的加持下迎来新的倒退态势。依据中汽协最新公布的数据显示，往年前两个月，我国新能源汽车产销别离实现97.7万辆和93.3万辆，同比别离增长18.1%和20.8%。 而不少厂商为了投合生产需要，相继推出搭载VtoL模式的新车型，这些车型具备对外放电性能，且放电功率大多达到了 2~3kW，齐全能满足各类露营电器的应用需要。 谁钟意开着新能源车去露营？新能源车主与露营酷爱者“不约而同”从现有新能源车主年龄散布来看，20-40岁群体是新能源汽车生产主力人群，占比70%以上，并且新能源汽车的生产人群日趋年轻化，20-30岁青年群体占比减少，而这一年龄区间刚好与酷爱露营的用户年龄段相吻合。 “她经济”在新能源行业中体现显著从性别散布来看，与传统车一样，男性车主仍然是生产主力人群。但相较于燃油车女性车主只占比21.87%而言，新能源车主中女性用户的占比显著回升，达到26.62%。 这或者与新能源汽车品牌的设计与营销思维无关，一些车企不仅推出了更多车漆色彩以供选择，而且其操作系统更加简略、更易上手，还融入了智能模块以辅助平安驾驶和高效停泊，因而吸引了更多女性车主。 高支出、高学历的新能源女性车主65%以上新能源女性车主的学历在本科及以上，并且有50%以上的新能源女性车主的支出冲破万元。 “新女性”群体具备强劲的经济购买力，对陈腐事务接受程度更高，也更加认同新能源理念。她们重视颜值，重视驾驶体验，重视性能和安全感，是新能源汽车行业新的生产力量。 “她”们的购车动机除了用车成本低这一最次要的购车动机外。咱们能够发现，30岁及以上的车主更关注车内的静谧性，新能源车发动机的乐音相较于燃油车而言的确更低，这一改良能够给乘坐者带来更加舒服的乘坐体验。 并且相较于30岁以下的女性车主而言，她们抉择新能源车是因为其上手更简略，相比燃油车来说更易操作，尤其是一些新能源车企相继推出主动泊车等性能，更是为这些女性车主在驾驶上提供了不少便利性。 而30岁以下的年老车主在抉择新能源车时更多的是受到“节能环保，绿色出行”这一新理念的影响。 “她”们的购车估算独身女性车主的购车估算大多集中在10~20万之间，占比达到45%左右；而处于恋爱或结婚阶段的女性车主广泛将购车估算进步了一截，大多在20~25万之间。 总体来看，10万以下的低端车型对独身女性更有吸引力，而结婚生子后的女性车主更违心花更多估算来购买高端车型。 “她”们的购车关注点依据调研发现，有58.8%的新能源车女性消费者在择车时第一思考因素是续航问题，“能源焦虑”简直充斥在所有新能源车的用户中。这也和一些新能源车企虚标电量，夸张续航里程有很大关联。 而近几年新能源车自燃的新闻一直爆出，大部分女性车主更关注新能源车安全性的问题。超过五成（57.7%）的受访者放心新能源汽车安全性不高，放心如车辆自燃、制动故障、整机故障等问题。 彻底解放双手不是梦 新能源车所带来的舒适性和便利性吸引着越来越多的用户，而各大车企更是新陈代谢，以电动化为终点，争相倒退智能化，打造驾驶体验更佳的新车型。 主动驾驶新体验。主动驾驶技术是新能源汽车行业将来倒退最次要方向之一。它能够帮忙驾驶员更好地治理车辆，从而进步行车安全性和舒适度。目前，L3级及以下驾驶辅助零碎曾经量产，L4级在特定场景下的一些利用也在逐渐开发中，一边吃着火锅一边开着车仿佛不再边远。 语音管制新体验。语音控制技术是目前曾经落地实现的技术之一，它能够帮忙驾驶员通过语音指令管制车辆，例如管制音响、导航、空调等。这能够进步驾驶员的舒适度和便捷性，同时还能够缩小驾驶员在驾驶时的注意力扩散。 车联网驾驶新体验。车联网技术是汽车行业将来倒退的另一次要方向，它能够将车辆与互联网连接起来，从而实现更多的车辆管制和信息交换性能。它能够通过云端服务实现近程管制车辆、获取车辆数据等，同时还能够提供实时的交通信息和路况信息，帮忙驾驶员更好地布局行车路线来节约出行工夫，并且就此缩小交通拥堵和车祸发生率，为城市交通管理作出贡献。

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。GreatSQL是MySQL的国产分支版本，应用上与MySQL统一。作者： 奥特曼爱小怪兽文章起源：GreatSQL社区投稿上一篇 MySQL8.0 优化器介绍（一）介绍了老本优化模型的三要素：表关联程序，与每张表返回的行数（过滤效率），查问老本。而join算法又是影响表关联效率的首要因素。 join算法（Join Algorithms）join在MySQL 是一个如此重要的章节，毫不夸大的说，everything is a join。 截止到本文写作时，MySQL8.0.32 GA曾经发行，这里次要介绍三大join：NL（Nested Loop），BNL（Block Nested Loop）,HASH JOIN 嵌套循环（Nested Loop）MySQL5.7之前，都只有NL，它实现简略，适宜索引查找。 简直每个人都能够手动实现一个NL。 SELECT CountryCode, country.Name AS Country, city.Name AS City, city.District FROM world.country INNER JOIN world.city ON city.CountryCode = country.Code WHERE Continent = 'Asia'; ##执行打算相似如下： -> Nested loop inner join -> Filter: (country.Continent = 'Asia') -> Table scan on country -> Index lookup on city using CountryCode (CountryCode=country.`Code`) ##python 代码实现一个NL result = [] for country_row in country: if country_row.Continent == 'Asia': for city_row in city.CountryCode['country_row.Code']: result.append(join_rows(country_row, city_row))图示化一个NL ...

近期，数据库畛域的顶级学术会议 ICDE 2023 在迪斯尼主题公园的故土 - 美国的安纳海姆（Anaheim）举办。由 OpenMLDB 开源社区和新加坡科技设计大学（Singapore University of Technology and Design）联结实现的钻研工作在 ICDE 2023 上作为工业界的惯例论文发表。该项钻研工作加强了 OpenMLDB 的流式特色计算能力，对其中的要害操作 Interval Join 进行了深度优化，获得了比目前工业界广泛应用的算法高达数量级的吞吐和提早优化。基于该优化算法，克服了流式计算在实时机器学习畛域所遇到的性能瓶颈，能够反对在金融、风控、举荐等畛域的毫秒级实时流式特色计算的需要。其论文预印版可在此链接浏览：Scalable Online Interval Join on Modern Multicore Processors in OpenMLDB OpenMLDB 作为一个线上线下统一的实时特色计算平台，被广泛应用于如反欺诈、风控、实时举荐等场景。在本次的钻研工作中，单方单干对基于 OpenMLDB 进行流式特色的计算能力进行了深度优化。特地的，咱们关注其中的性能瓶颈，即 Interval Join 操作。下图为 Interval Join 的示意图。其基于数据流 S，定义一个往前两秒的工夫窗口，对数据流 R 上在对应工夫窗口内的数据进行 JOIN 或者聚合操作，实现须要的特色计算逻辑。该操作在 Flink 中即为 Interval Join，在 OpenMLDB 中是通过 WINDOW UNION 语法进行副表多行聚合特色的开发，或者也被称为 point-in-time join/aggregation。 Interval Join 在现有的工业界流式解决零碎中，个别应用 key-partitioned based join 算法，简称为 Key-OIJ。比方在工业界中广泛应用的流式计算框架 Flink，即应用了 Key-OIJ 的算法实现 Interval Join 的计算工作。此种算法对于一个 buffer 内的 R 和 S 做 partition，而后对于在雷同 partition 内的数据再进行 join 或者聚合操作。在此次钻研工作中，咱们发现 Key-OIJ 在很多真实世界的工作负载中存在重大的性能问题。次要总结为： ...

剖析型数据库的另外一个倒退方向就是以分布式技术来代替MPP的并行计算，一方面分布式技术比MPP有更好的可扩展性，对底层的异构软硬件反对度更好，能够解决MPP数据库的几个要害架构问题。本文介绍分布式剖析型数据库。 — 背景介绍—目前在分布式剖析型数据库畛域，学术界往年的钻研不多，次要是工业界在推动相干的技术倒退。分布式剖析型数据库的存储层个别采纳分布式存储或云存储，而计算引擎层采纳独立的分布式计算引擎，而MPP数据库的存储层和计算层都是由多个数据库实例来承当的，这是两者最大的架构区别。 在Hadoop开始衰亡的时候，分布式架构的可扩展性和弹性劣势就逐步显现出来，以HDFS为代表的大数据技术使大数据的解决在扩展性、弹性、容错性、老本等方面获得提高，然而却就义了传统SQL数据库例如事务、SQL语句、关系模型、平安管控等要害个性。SQL作为数据库畛域的事实标准语言，相比拟用API（如MapReduce API，Spark API等）来构建大数据分析的解决方案有着先天的劣势。从2013年开始大量的SQL on Hadoop引擎的呈现和疾速成熟，并且在国内外企业取得了大量生产落地，充分说明了SQL的重要性。 分布式剖析型数据库用于数据仓库的建设，就须要解决分布式事务以及高并发的批处理问题，因而须要从新构建分布式事务引擎和计算引擎。以后行业内不同的数据库采纳的技术计划不尽相同，分布式事务引擎大多须要从0到1的构建，而分布式计算引擎有采纳相似DAG的计算模型。 分布式数据库与MPP数据库的一个典型区别就是计算和存储的局部拆散，也就是存储服务和计算服务不再绑定在一个过程中，数量能够不统一，这样就实现了计算的弹性。在实在生产业务中，计算的弹性需要比拟大，而存储相当来说可预测性更强。一些厂商采纳自研存储的形式如星环科技的ArgoDB，而另外局部企业就间接基于云存储的形式来构建其数据库，将指标市场间接定位在私有云端，如AWS Redshift、Snowflake和Databricks SQL。不过公有云和私有云场景下的剖析型数据库的设计理念差别十分大，理论架构区别也非常明显，咱们将在后续章节开展。 — 总体架构 —因为分布式数据库起步较晚，设计者在做架构设计的时候就能充沛排汇MPP数据库和Hadoop等技术的劣势，避开MPP数据库的架构缺点，并且解决弹性化、多租户隔离等方面的各种问题。分布式剖析型数据图的逻辑架构如下图所示，次要蕴含了服务层、SQL引擎、分布式事务引擎、分布式计算引擎和存储引擎。与MPP数据库的逻辑架构最次要的区别在于计算引擎和存储引擎独立，而MPP数据库底层基于某一种关系数据库，蕴含了SQL、事务、计算和存储能力。因为几个引擎绝对独立，架构上的灵活性就保障了有多种形式能够解决原有MPP数据库的架构问题。 分布式存储引擎在分布式存储引擎这一层，目前行业内有比拟多的基于Paxos或Raft协定打造的高可用的分布式存储。因为用于剖析型场景，数据存储格局个别都采纳列式数据存储，典型的实现有ORC和Parquet文件格式。在剖析场景下仅读取须要的列数据而无需读取其余不相干列，节俭了IO从而有很高的数据读吞吐；另外一个列的数据采纳同样的编码方式（如RLE、Delta、字典编码等），因而数据有很高的数据压缩率，个别能够做到5~10x的压缩比。另外，因为不同的列曾经离开存储，个别会设计并行读数据的API，每个线程读取不同的列数据，从而进步并行读数据能力。基于列式存储的另外一个益处就是更好的反对各种结构化和非结构化数据，从而能够在一个平台内反对多样的数据类型的数据分析。 列式存储对读数据有很大的性能劣势，个别都会设计接口跟下层的计算层对接，提供读取、过滤下推、索引等读写接口。在反对数据写入的能力上，列式存储不如行式存储，个别须要通过在下层减少一个内存buffer的形式来减速，如MariaDB的Version Buffer。 另外分布式事务也是分布式存储的一个重要个性与要求，个别都采纳MVCC和Compaction机制来实现。在列式存储中去批改给定一行的数据是比较复杂的，因而在实际操作每个事务操作并不会间接批改对应的字段的值，而是在生成一个新的版本，并在对应字段的block生成一个只蕴含要批改的数据的新版本的数据块。每个新版本操作就生成一个新数据块，在读取数据的时候，会依据无效的事务号来读取相干的数据块并和根底数据合并生成最终的数据值。随着数据库的版本减少，数据读的速度会降落，因而须要启动Compaction机制来合并，将大量的多版本文件合并为大量的文件，从而实现读写能力的无效均衡。 在理论性能中，还须要思考对于分布式治理和运维方面的能力，包含对磁盘或节点的增删治理能力，数据迁徙能力等。 分布式计算引擎分布式计算引擎是另外一个重要的组成，一个优良的引擎包含计算框架、各种分布式计算的算子、优化器以及资源管理能力。在计算框架方面，个别抉择DAG或MPP模式，依据不同的设计需要来抉择。在计算算子方面，围绕着SQL的原语，能够设计大量的算子，譬如JOIN算法就能够有包含hash join、sort merge join、index scan join、skew scan join等多种不同的实现，并对接到CBO优化器来做自动化的抉择。这个方向的长期演进方向就是自治数据库，通过大量的优化规定和机器学习能力来产生针对用户场景的更多优化规定，从而让数据库能够主动的抉择最合适的执行打算，无需DBA的手工干涉。在资源管理方面，如果跟现有的资源管理框架无效联合也是分布式数据库的重要工作之一，包含YARN、Kubernetes以及各个私有云平台。无论是Spark、Flink等开源资源管理框架，还是各个商业的剖析型数据库，都在鼎力的推动资源管理模式的优化，从而更好的反对多租户以及与云计算的联合。 分布式事务引擎在分布式数据库畛域，分布式事务处理和优化是十分热门的关键技术，如何在简单的零碎架构和容错设计下保证数据的一致性，以及有多种事务隔离级别的反对（串行化、可反复度、Read committed等），可能拓展数据库去撑持更多的利用。两阶段提交（2PC）、MVCC、基于快照的事务隔离等都是重要的技术实现。因为剖析型数据库次要解决低并发度的事务操作，比拟多的都是批量的数据批改或插入，因而对事务的并发度要求不高。在实现中，甚至能够采纳一些低并发度然而实现简略的算法，如两阶段封闭（2PL）等算法。 SQL引擎SQL引擎为开发者提供SQL开发能力，是业务开发的外围接口，因而各个数据库都在致力提供欠缺的SQL反对，以及残缺的SQL优化能力。因为Oracle、Teradata等数据库的SQL性能十分欠缺，提供Oracle与Teradata的数据库兼容性是个十分有挑战的工作，也须要长期继续的投入。 — 星环剖析型数据库ArgoDB — 随着大数据技术在企业中利用得越来越深，国内的企业数据架构变得越来越简单，次要体现在离线业务与在线业务并存，剖析型业务与检索型业务并存，结构化数据与非结构化数据并存，对数据库性能、多租户服务能力的要求也越来越高。企业对性能要求超过弹性或者老本，因而亟需有极致性能的分布式剖析型数据库，这也是公有云畛域剖析型数据库的次要倒退方向。 软件的设计须要充分考虑硬件的个性，从SAS硬盘，到SATA SSD，到PCIE-SSD，再到Memory，性能都有着数量级的增长，也推动着数据库架构的从新设计。在利用需要和技术架构的双重推动下，星环科技从2014年即开始布局不依赖于Hadoop存储的剖析型数据库，重用已有的SQL、事务和分布式计算引擎的能力，自研新一代的基于闪存的分布式存储，到2018年正式推出了闪存数据库ArgoDB，指标可能作为数据仓库、数据湖和数据集市的对立解决方案。 ArgoDB的架构如上图所示，次要的外围组件次要包含分布式计算引擎Crux、SQL编译器、分布式存储管理层TDDMS以及存储引擎Holodesk。 SQL编译器继承了Inceptor产品的优良能力，实现了SQL 99的残缺兼容性，反对PL/SQL以及DB2 SQL PL存储过程标准，并且原创的反对了Oracle、DB2和Teradata的方言。为了满足企业的数仓需要，ArgoDB也反对分布式事务管理和四种隔离级别。 ArgoDB在数据库外部实现了本人的资源调度以更好的反对不同业务的并发SQL工作，并与平台自身的调度零碎联合，实现了两个层级的更加细化的资源管理和调度能力。首先ArgoDB有个常驻服务，数据库启动后就事后申请了CPU和内存资源，并将资源划分为多个资源池。除了基于FIFO或FAIR策略为每个SQL分配资源以外，ArgoDB还减少了一个Furion机制，基于一个树形的构造来资源管理，同一个树节点下的各个子节点容许资源互借资源，每个树节点容许不同的用户或者利用设定ACL或affinity，理论调度的时候，只有有一个CPU core资源闲暇，就调度某个task，最大水平的让资源无效利用。为了更好的反对多业务，ArgoDB容许依据用户名、IP、业务类型、提交工夫等个性来设定不同的优先级和调度策略，容许抢占式调度。另外每个资源池都保障最小的资源，从而防止饥饿调度问题。 ArgoDB将分布式存储引擎解构为通用分布式存储管理层TDDMS与底层存储引擎Holodesk两块。TDDMS将底层存储引擎形象为一组接口，包含存储的读写操作接口、事务操作接口、计算引擎的优化接口等，任何实现这些接口的存储引擎都能以插件的模式接入ArgoDB。TDDMS基于分布式一致性协定Raft实现的存储引擎，利用它能够实现存储引擎治理的高可用和备份灾备能力，并且提供运维治理能力。因为TDDMS在设计上的应用了数据存储的引擎化治理，它可能接入新的专用存储，从而解决了对Hadoop生态技术的依赖问题。TDDMS在设计上能够接入多模态的存储，既而与下层计算引擎配合，实现多模态的对立存储和对立剖析能力，在理论业务中是个重要的翻新，防止每个数据库都要垂直的实现存储管理的工作。 Holodesk通过基于闪存的行列混合存储，针对闪存SSD弱小的随机IO能力，以及优于一般HDD盘程序读写能力，做了数据读写的专项优化，实现了数据疾速的读写能力，进而能够是业务取得更优良的剖析能力。Holodesk也反对多种辅助索引技术，反对数据块级别的事后聚合，极大地加强了数据的检索性能，能更好地适配混合型的业务场景。但Holodesk并不仅仅只能应用SSD，也反对内存+闪存+磁盘的三级混合存储。多级存储使得用户能够更好的在性能和硬件估算间找到平衡点。 分布式计算引擎Crux是一个向量化的计算引擎，采纳的基于DAG模式的计算框架，外部由多个无状态的执行器组成，能够依据业务负载来调整计算弹性化。计算引擎既能够疾速读取批量存储文件，也能够高速地运行大量数据的简略查问和简单查问。内存数据格式的设计与列式存储适配，最大水平地缩小了数据在内存中转换的工夫。同时，可能动态分析SQL构造，基于向量化的思维选取高效的运行时行列对象模型，在晋升性能的同时显著节俭内存应用。 ArgoDB的整体的业务查问架构如下所示，用户的SQL业务通过SQL编译器生产执行打算和Runtime Context，而后发送给Crux Executor；Executor通过TDDMS来拜访存储层的数据，其中F1/F2/F3/F4等都代表一个数据块，Holodesk默认采纳3正本形式存储，而后通过TDDMS Tablet Server来拜访本地文件系统上的存储的理论数据块。 Crux Executor和TDDMS存储是独立分层的，它们各自能够依据负载状况来独立的弹性扩缩容，因而解决了可扩展性问题，尤其是计算的可扩大。将来，咱们打算将TDDMS Tablet Server与各个云平台对接，能够间接与云上的文件系统高速交互打造云上的数据分析能力，服务于私有云的企业客户。ArgoDB自身实现了数据库内的资源管理，底层基于容器技术和Kubernetes做零碎层的资源调度，通过两层资源调度机制实现了十分好的多租户能力。 基于先进的架构设计与布局，ArgoDB在2年内也落地了大量的金融级生产案例。此外，在国内基准组织TPC的数据分析决策测试TPC-DS的测试中，星环Inceptor是国内上首个通过测试的产品，而ArgoDB是寰球第四个，这也充分说明了整体架构的先进性。 — 小结—本文介绍了分布式剖析型数据库的架构原理，以及星环剖析型数据库ArgoDB的外围能力。分布式数据库相比于MPP数据库可能实现存算拆散，这样就能实现了计算的弹性。那么更进一步的，在传统的企业数据使用中，经常会呈现企业的零碎数据散落在各个数据存储中的情况，数据分析需要往往是跨库的，这类需要又该如何解决呢？下一篇将介绍数据联邦架构。

这是社区版回归与大家见面的第一个版本，在新版本 v1.5.0 中，CloudQuery 次要性能包含以下几个模块：对立数据库治理数据库纳管反对欠缺 SQL 编辑器数据源操作权限工夫权限设置受限资源权限设置数据导出权限减少流程模块查看审计日志系统监控性能01对立数据库治理 CloudQuery 作为一体化数据库操作管控平台，始终将数据库的对立高效治理视作外围性能和竞争力。这次回归进一步欠缺了该性能，具体包含：● 反对对立管控下，对数据库、表、函数、存储过程、DBLINK、包、包体、序列、触发器等十多种数据库对象的创立与编辑；● 编辑时，反对图形可视化操作。用户能够在图形化界面创立表、索引、触发器、对表构造进行变更、对表数据进行增删改查，操作形式与传统客户端保持一致，疾速上手；● 导入文件时，反对EXCEL、CSV、TXT等文件的数据导入，反对自定义分隔符。 02数据库纳管反对 v1.5.0 是不同于以往的全新社区版本，目前反对6种数据源，Oracle、OracleCDB、SQLServer、MySQL、PostgreSQL和MariaDB。 ● OracleCDB 与 Oracle 相比，减少了PDB层级 ● CloudQuery 社区版目前反对纳管的实例数下限为100个03欠缺SQL 编辑器 新版本欠缺了 SQL 编辑器的局部性能：● 反对SQL语句智能提醒、关键词高亮显示、执行打算、事务、SQL丑化（包含大小写转换、格式化、折叠/开展、放大/放大字体）● 反对全副执行或选中执行，并反对查看执行打算● 反对编辑器内容珍藏至文件或从文件加载04数据源操作权限 ● v1.5.0 加强了权限管控的细粒度，目前权限管控可准确到字段级别● 欠缺了对操作对象、操作类型、操作工夫、影响行数、操作次数等多因素的管控，限度越权操作和高危操作05工夫权限设置 与之前的版本相比，CloudQuery 社区版 v1.5.0 反对自定义执行 SQL 语句的操作工夫，实现更细粒度的管控。06受限资源权限设置 v1.5.0 反对自定义高危操作，高危提权复核形式反对同步复核。07数据导出权限 ●  v1.5.0 新增了数据导出权限，可设置导出权限的权限名称、权限形容，抉择对应数据库元素；可针对单条权限进行编辑、删除操作。08减少流程模块 v1.5.0 相比之前的版本，减少了流程申请和审批模块，次要性能包含： ● 当普通用户须要某些权限时，反对向管理员发动流程申请，权限管控更加灵便；● 反对查看申请详情，包含申请人、工夫、操作类型等；● 反对管理员设计流程，将审批自定义为一级/二级审批，也反对抉择审批人；● 反对管理员治理流程，如将审批进行转审。 09查看审计日志 最新版本更新了审计性能。CloudQuery 会记录应用过程中的语句明细和操作明细，在以下性能上进行了降级： ● 反对查看平台执行SQL次数、谬误数、数据库应用占比、以及沉闷用户数等●  反对查看SQL操作信息明细，包含操作语句、执行打算、关联权限等● 反对自定义查问后果字段展现、按条件筛选语句信息明细● 反对点击用户名或数据库对象进入相应的审计核界面● 反对查看平台用户操作明细，包含用户名、用户角色、客户端、操作类型等10系统监控性能● 主机监控CloudQuery v1.5.0 具备主机监控性能，可对本身平台所在服务器运行状态进行监控，查看CPU使用率与总体率、分区状态、流量状态等。 ● 容器监控新版本应用 docker 容器进行装置部署，每个服务领有独立容器环境，同时反对对容器运行状态进行监控，及时查看服务运行状态。 更丰盛的性能欢送大家点击文末浏览原文或搜寻 https://cloudquery.club/#/ 进入官网，下载应用！此外，为了更直观具体地为大家解说新版本的性能和理念，咱们行将于 4月19日 在墨天轮、微信视频号、bilibili 同步进行一场发版直播，搭档们能够扫描二维码预约观看！直播中还会不定时公布抽奖，欢送大家积极参与！墨天轮 bilibili  大家在应用过程中有任何疑难和倡议，欢送扫码增加 CloudQuery 官网小助手微信进入社区群，咱们期待收到您的反馈！

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。GreatSQL是MySQL的国产分支版本，应用上与MySQL统一。作者： Yejinrong/叶金荣文章起源：GreatSQL社区投稿启用coredump制作一个coredump场景实在故障场景剖析跟踪上一篇文档介绍了如何构建gdb跟踪调试环境，本文介绍如何依据谬误日志信息，跟踪定位问题可能的起因，以及如何利用coredump文件查找问题线索。 1. 启用coredump程序运行过程中可能会异样终止或解体，OS会把程序挂掉时的内存状态记录下来，写入core文件，这就叫 coredump，通过gdb联合core文件能够不便地进行调试。 利用core文件中保留的异样堆栈文件，可能帮忙研发同学更快定位问题。因而，如果某些故障断断续续会呈现，倡议阶段性开启coredump性能。 想要开启coredump，须要先批改OS层的几个设置： $ ulimit -c unlimited$ sysctl -w fs.suid_dumpable=2$ echo "core.%p.%e.%s" > /proc/sys/kernel/core_pattern同时，将这些批改长久化到相应文件中（假设MySQL/GreatSQL服务过程的属主用户是 mysql）： $ echo "mysql - core unlimited" >> /etc/security/limits.conf$ echo "fs.suid_dumpable=2" >> /etc/sysctl.conf$ echo "kernel.core_pattern=core.%e.%p.%t" >> /etc/sysctl.conf$ sysctl -p接下来，批改 my.cnf 配置文件，减少以下两行内容： core_fileinnodb_buffer_pool_in_core_file=OFF而后重启GreatSQL服务过程，即可失效，查问确认下： mysql> show global variables like '%core%';+---------------------------------+-------+| Variable_name | Value |+---------------------------------+-------+| core_file | ON || innodb_buffer_pool_in_core_file | OFF |+---------------------------------+-------+这样设置实现后，需要的话会在 datadir 目录下生成core文件。 2. 制作一个coredump场景咱们能够给mysqld过程发送 SIGSEGV(11) 信号，即可模拟出coredump的场景，例如： $ kill -s SIGSEGV `pidof mysqld`这时查看GreatSQL谬误日志文件，以及core文件，就会发现有coredump： ...

作者：卢文双 资深数据库内核研发 去年年底通过微信公众号【数据库内核】设定了一个指标——2023 年要写一系列 个性介绍+内核解析 的文章（现阶段还是以 MySQL 为主）。尽管关注者很少，但本着“说到就要做到”的准则，从这篇就开始了。序言： 以前对 MySQL 测试框架 MTR 的应用，次要集中于 SQL 正确性验证。近期因为工作须要，深刻理解了 MTR 的方方面面，发现 MTR 的能力不仅限于此，还反对单元测试、压力测试、代码覆盖率测试、内存谬误检测、线程竞争与死锁等性能，因而，本着分享的精力，将其总结成一个系列。 次要内容如下： 入门篇：工作机制、编译装置、参数、指令示例、举荐用法、增加 case、常见问题、异样调试进阶篇：高阶用法，包含单元测试、压力测试、代码覆盖率测试、内存谬误检测、线程竞争与死锁源码篇：剖析 MTR 的源码语法篇：单元测试、压力测试、mysqltest 语法、异样调试因为集体程度无限，所述不免有谬误之处，望雅正。 本文是第一篇入门篇。 本文首发于 2023-03-18 21:58:52本系列基于 MySQL 8.0.29 版本，且次要在 Ubuntu 22.04 X86_64 验证（局部指令也在 Ubuntu 20.04 X86_64、Ubuntu 22.04 ARM64、MacOS M1 做了验证），如有例外，会特地阐明。 简介在批改内核代码后，不仅须要测试新增性能，同时也要对原有性能做回归测试，以保障新加代码对原有性能没有影响，这就须要用到 MySQL 源码自带的测试框架 mtr。 MySQL 测试框架是一个以 MySQL 框架和外部引擎为测试对象的工具，次要执行脚本在装置门路（make install后的门路）下的mysql-test目录，根本笼罩了所有 MySQL 的个性和异常情况。 MySQL 测试框架 mtr 次要蕴含如下几个组件： mysql-test-run.pl ：perl 脚本，简称 mtr，是 MySQL 最罕用的测试工具，负责管制流程，包含启停、辨认执行哪些用例、创立文件夹、收集后果等等，次要作用是验证 SQL 语句在各种场景下是否返回正确的后果。mysqltest ：C++二进制程序，负责执行测试用例，包含读文件、解析特定语法、执行用例。 用例的非凡语法（比方，--source，--replace_column等）都在command_names和enum_commands两个枚举构造体中。mysql_client_test ：C++二进制程序，用于测试 MySQL 客户端 API（mysqltest 无奈用于测试 API）。 ...

大家好，我是冰河~~ 明天发现Mysql的主从数据库没有同步 先上Master库： mysql>show processlist;查看下过程是否Sleep太多。发现很失常。 show master status;也失常。 mysql> show master status;+-------------------+----------+--------------+-------------------------------+| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |+-------------------+----------+--------------+-------------------------------+| mysqld-bin.000001 | 3260 | | mysql,test,information_schema |+-------------------+----------+--------------+-------------------------------+1 row in set (0.00 sec)再到Slave上查看 mysql> show slave status\G Slave_IO_Running: YesSlave_SQL_Running: No可见是Slave不同步 解决方案上面介绍两种解决办法 办法一：疏忽谬误后，持续同步 该办法实用于主从库数据相差不大，或者要求数据能够不齐全对立的状况，数据要求不严格的状况 解决： stop slave; #示意跳过一步谬误，前面的数字可变set global sql_slave_skip_counter =1;start slave;之后再用mysql> show slave status\G 查看 mysql> show slave status\GSlave_IO_Running: YesSlave_SQL_Running: Yesok，当初主从同步状态失常了。。。 形式二：从新做主从，齐全同步 该办法实用于主从库数据相差较大，或者要求数据齐全对立的状况 解决步骤如下： 1.先进入主库，进行锁表，避免数据写入 应用命令： mysql> flush tables with read lock;留神：该处是锁定为只读状态，语句不辨别大小写 ...

欢送拜访 OceanBase 官网获取更多信息：https://www.oceanbase.com/ 对于作者 胡智娟OceanBase 产品经理次要负责 OceanBase 生态工具数据研发、迁徙评估方向的产品工作，在蚂蚁团体有多年数据库治理实战经验，对日常研发及运维痛点有较深感悟。心愿能帮忙开发者解决痛点，为大家带来好用、平安、全面的开发合作平台。 2023 年 Q1，OceanBase 开发者核心 (ODC) 陆续公布了 4.1.0、4.1.1、4.1.2 版本，从 ODC 4.0.x 到 ODC 4.1.x 有一系列新性能，也有十分多罕用性能优化，概括来说包含更加适宜 OceanBase 4.0/4.1 版本、晋升了规模用户协同的效率、反对 SQL 定时执行和 SQL 查看以及一系列小性能和易用性晋升，本文为大家具体解读 ODC 4.1.x 的重点新个性 。 面向 OceanBase 4.0/4.1 的 ODC♀️ 在数据源适配方面，ODC 4.1.0 开始反对连贯 OceanBase 4.0，ODC 4.1.2 开始反对连贯 OceanBase 4.1。 传输平安是数据安全的重要环节，数据库连贯怎么能少了 SSL 反对，安顿~ 基于 OceanBase 4.0 开始提供的 GV$OB_PROCESSLIST视图，ODC 的提交、回滚按钮会基于事务状态同步。 一个 DBA 轻松治理千人以上数据库权限 更弱小的数据库拜访权限治理，轻松反对 1000+ 用户协同场景。 用户能够通过公共连贯对立配置数据库连贯，通过角色受权给用户防止数据库帐密散发。 ...

欢送拜访 OceanBase 官网获取更多信息：https://www.oceanbase.com/ 3 月 25 日，第一届 OceanBase 开发者大会在北京举办，OceanBase 首席架构师杨志丰（花名：竹翁）带来了 《OceanBase 的单机分布式一体化》 的分享，为大家介绍了单机分布式一体化架构的概念及思考，以及对业务的价值。 以下为演讲实录： 明天我的演讲主题是《OceanBase 的单机分布式一体化》，次要来解释 OceanBase 为什么要做单机分布式一体化，我将从以下 3 个方面进行明天的分享： 首先，单机分布式一体化是什么？ 其次，单机部署时如何取得与单机数据库相当的性能？ 最初，分布式部署时如何实现高性能低时延？ 什么是单机分布式一体化？每个人听到“单机分布式一体化”可能都会有本人不同的了解，也会有很多疑难，事实上，单机分布式一体化不是 OceanBase 忽然冒出来的概念，而是基于三方面的起因。 第一，产品迭代。 OceanBase 从 2010 年开始自研，在走出蚂蚁团体开始服务金融行业，到当初走到云下来服务更多互联网行业客户的过程中，基于客户的反馈，咱们的产品一直在演变、欠缺。 第二，硬件趋势的一直倒退。 OceanBase 在 1.0 最后设计的时候，过后咱们在蚂蚁团体的外部集群，用的机器都是一般 16 核的机器，前面随着硬件技术的倒退，咱们的支流机器都在 96 核以上，服务器单机的性能有了极大的晋升。 第三，云技术的倒退。 近几年，云技术倒退突飞猛进，OceanBase 刚刚创建之初，云技术刚刚衰亡，而当初云基础设施触手可得。技术的倒退随同着 OceanBase 架构的倒退，OceanBase 的技术经验了三个大的版本迭代。 ▋ 从 0.1 到 4.0，OceanBase 的倒退历程 第一个版本是 0.5 版本，尽管是十几年前的版本，但其实它曾经齐全是分布式的架构，在过后，OceanBase 把 SQL 层和存储引擎做了拆散，下面是一组 SQL 无状态服务，上面是由 ChunkServer 和 UpdateServer 组成的存储集群，对外裸露的就是表的 API。过后因为咱们刚刚开始去做数据库的实现，所以咱们做了一些限度——没有多点写入，所以过后实际上是不反对分布式事务的。 当 OceanBase 从 0.5 往 1.0 演进的时候，咱们有一个粗浅的感触：传统单机数据库采纳紧耦合的设计，存储和计算放在一起，起初因为有了 NoSQL，很多人感觉是不是应该把存储层独自隔离开，OceanBase 在零点几版本的时候就遵循这样的设计思路，所以咱们做了拆散，但拆散当前带来十分大的问题。 ...

本期试验将领导您应用PolarDB-X分布式事务和数据分区 本期收费试验地址 本期教学视频地址 前置筹备假如曾经依据前一讲内容实现了PolarDB-X的搭建部署，能够胜利链接上PolarDB-X数据库。 体验PolarDB-X分布式事务本步骤将带您体验PolarDB-X分布式事务。首先开启一个分布式事务，通过命令察看事务信息。而后模仿一个转账行为，察看原子性和隔离性保障，最初通过Flashback Query查看历史版本。 1.筹备测试库、测试表和测试数据。a. 执行如下SQL语句，创立测试库transfer_test并应用。 CREATE DATABASE transfer_test MODE='AUTO'; USE transfer_test;b. 执行如下SQL语句，创立测试表account。 CREATE TABLE account ( pk bigint not null auto_increment, id varchar(64) not null, balance double not null, gmt_create timestamp default current_timestamp, gmt_modified timestamp default current_timestamp on update current_timestamp, PRIMARY KEY(pk), key(id));c. 执行如下SQL语句，创立测试表user 。 CREATE TABLE user ( pk bigint not null auto_increment, name varchar(64) not null, addr varchar(128) not null, gmt_create timestamp default current_timestamp, gmt_modified timestamp default current_timestamp on update current_timestamp, PRIMARY KEY(pk), key(name));d. 执行如下SQL语句，初始化数据。 ...

数据孤岛是始终以来的老大难问题，之前也有在寻找相干产品和解决方案，要么太重，要么不容易落地，直到偶然间看到 Tapdata。这是一个小而美的产品，专一实时数据开发畛域，其异构数据实时同步能力使咱们能够更专一在业务层面开发，而不必再关怀数据层问题。——中核武汉零碎技术部架构师 易继虎近年来，以信息化、智能化为典型特色的新一轮科技反动正在蓬勃发展，寰球经济正处在一个前所未有的变轨期，数字化技术继续涌现，数字经济未然成为经济增长的外围驱动力。 时代召唤传统企业的数字化降级。 而国有企业作为国民经济倒退的中坚力量，须要充分发挥国有经济主导作用，被动把握和引领新一代信息技术改革趋势，引领和带动我国经济在这轮转型改革中占据国际竞争制高点。国务院国资委更是于2020年正式印发《对于放慢推动国有企业数字化转型工作的告诉》，踊跃疏导国有企业在数字化转型路线上施展其示范引领作用。 在央企、国企全面实现数字化转型的路线上，存在着这么一个公认的拦路巨石——数据孤岛。而在与泛滥相干企业用户牵手，减速转型优化的过程中，Tapdata 也始终在致力为企业轻老本破局提供新思路，践行数据孤岛“终结者”的使命。 想晓得 Tapdata 具体解决了什么样的问题、能够如何应用，无妨一起来理解下中核武汉是怎么实际落地的。 一、中核武汉，科改示范“卡脖子”的数据孤岛，难拔除的数据烟囱 中核武汉，科改示范企业，由核动力运行研究所、秦山核电公司、武汉元一科技投资有限公司、上海核工程钻研设计院独特投资组建，融入了发动单位在核动力技术服务畛域的原有劣势资产、市场以及治理运作劣势，“以此为生，精于此道，致力于保障核设施平安、牢靠、经济地运行”，是目前国内规模最大、实力最强的核动力运行技术服务专业化公司。 中核武汉在为不同国企、央企提供信息化服务的同时，也发现了一个普遍存在的问题：数据孤岛。因为零碎的多样性——外采、内建构造各异，组织分化，业务场景多样……以致对接业务数据时频频碰壁，往往须要破费大量的人力资源去做非业务侧的开发工作。开发中更是须要和不同组织部门的人协调，申请取得对应的数据权限，并消耗工夫老本来了解数据字典的业务含意。 而常见的 ETL 工具没有复用性，每次有新需要或是需要有改变时，都须要重跑一遍同步流程，大量 ETL 开发也只能是“治标不治本”，没有方法从本源上突破数据壁垒。除此之外，中核武汉还在通过 Java代码来实现不同数据中心之间的数据查问，工作量也很大，依旧会带来背离外围工作的资源投入。 如此一来，其我的项目落地周期不可避免地被拉长，以至于无奈专一在业务的开发上。中核武汉迫切需要解放被数据层“绑架”的创造力，将开发重心收拢回业务侧，为此，中核武汉尝试将数据层技术对接工作交托给了专一于实时数据开发畛域的 Tapdata——各专其专，各长其长，独特为核工业高质量倒退添薪。 二、Tapdata：小而美的实时数据交换平台因为专一，所以更业余 面对日益低落的数据买通需要，和传统架构掣肘之间的矛盾，Tapdata 提供了新思路：“实时同步+实时处理+实时公布”的全链路实时数据服务平台，在保留原有零碎根底上，构建一个高度一致的数据镜像，并采纳主数据管理技术，造成一套残缺、精确、可信、可服务的主数据服务零碎。 为疾速满足中核武汉缩短我的项目周期，优化资源配置的需要，Tapdata 充分发挥平台低代码可视化配置操作，以及异构数据实时同步等性能个性，疾速买通中核武汉各数据中心，达成本地和云上数据联通——实现疾速开发、疾速查问，极大优化开发人力资源，胜利用开创性的“小而美”攻破了沉疴式的“大而难”。 同时思考到中核武汉的央企属性，Tapdata 还具备“纯国产自研”，领有自主知识产权的劣势，对国产数据库也更加敌对，从国际竞争久远角度来看，技术更加可控。 架构部署图解 从预生产实例同步全实例数据到公共数据中心实例公共数据中心实例通过特定逻辑和规定将批改的公共数据别离同步至不同的业务数据中心实例，同时记录同步的数据条数和是否胜利（有日志）公共数据中心研发域通过数据同步后处理造成宽表，将全局查问数据同步至公共数据中心研发域 ES为什么抉择 Tapdata？面对国有企业的精细化治理需要，以及科技攻关路线上的国产化过程，Tapdata 展现出如下劣势： 纯国产自研Tapdata 先天具备自主知识产权劣势，技术更加可控。开箱即用与低代码可视化操作 Tapdata 部署简略，且反对无代码和低代码可视操作，能够在利落拽中疾速创立工作，无需编码甚至 SQL 来编写转换规则。 内置 60+ 数据连接器，稳固的实时采集和传输能力 以实时的形式从各个数据起源，包含数据库、API、队列、物联网等数据提供者采集或同步最新的数据变动。反对多源异构数据双向同步，主动映射关系型到非关系型。基于自研的 CDC 日志解析技术，0入侵实时采集数据，对源库简直无影响，一键实现实时捕捉，毫秒内更新。已内置 60+连接器且一直拓展中，笼罩大部分支流的数据库和类型，并且反对自定义数据源，具备强可扩展性的 PDK 架构，4 小时疾速对接 SaaS API 零碎；16 小时疾速对接数据库系统。 秒级响应的数据实时计算能力 全链路实时，基于 Pipeline 流式数据处理，以应答基于单条数据记录的即时解决需要，如数据库 CDC、音讯、IoT 事件等。不同于传统 ETL，每一条新产生并进入到平台的数据，会在秒级范畴被响应，计算，解决并写入到指标表中。同时提供了基于工夫窗的统计分析能力，实用于实时剖析场景。 稳固易用的数据实时服务能力 反对低代码可视化形式开发和配置业务须要的 Data API，可能提供毫秒级提早、大并发的实时交互式数据拜访能力，做到真正意义上反对 TP 型业务。具备欠缺的、可配置的数据拜访权限，反对拜访监控和剖析能力，可为数据需要部门提供基于权限内的自助式主数据拜访服务和机制。 兼具高可用、可扩大的架构设计，足以应答大并发和大流量的拜访。 数据、工作分类，让数据跨部门流动起来 ...

导读最近的几年中，HTAP数据库成为了一个时尚词汇，言必称HTAP也成了很多数据库畛域从业者的风潮。如何打造一款HTAP数据库，从架构层面登程，去应答将来的变动，拥抱变动，也是很多数据库公司所始终在摸索的。 MatrixOne 是矩阵起源（MatrixOrigin）开源的一款超交融 HTAP 云原生数据库，与业内诸多数据库产品十分不同的点是，MatrixOne 的自研之路是从第一行代码开始的。MO 的指标是打造一款极简、高扩展性、高灵活性、高性价比的全新数据库。 在过来的两年里，MatrixOne经验了一次架构的演进，更具备试验性质的旧架构到面向未来的新架构，成为了诸多数据库开发工程师与运维工程师的关注点，他们经验怎么的架构演进，这两头又有哪些值得借鉴的内容，将在本文中为大家一一揭晓。 上面是本文目录概览：1.晚期架构的千层糕2.三座大山，推倒重来3.新生后的MatrixOne4.积跬步以至千里5.复盘播种6.总结 Part 1 晚期架构的千层糕MatrixOne作为一款开源分布式架构的数据库，已有靠近2年的生命历程。我置信有很多社区老用户，会对晚期架构时SSB测试的高性能留有印象。而到了0.5版本公布之后，性能忽然就大幅下滑。过后就有敌人问我，怎么还越做越回去了？我对他说，有个大动作，整个架构做了一个大规模的降级。 此时此刻，我觉得很有必要，对整个架构的演进降级，做一个残缺的论述。 如何界定MatrixOne的晚期架构？明确地说，是指MatrixOne从0.1到0.4版本的架构，也是在2022年上半年之前，在各类推送中呈现的那个架构。与其说这是一个架构，更不如说，这是一场试验，通过一个架构，去摸索出各种架构的有余，找到真正适宜于与原生的HTAP分布式架构。这个试验的旧架构，有两个显著的特色：NewSQL与MPP。前者是基于Google当年的几篇经典论文所衍生出的，也是明天很多数据库产品的总思路。后者MPP，顾名思义，大规模并行处理，并行计算是它们的显著特点。落地到MatrixOne的晚期架构，又有了更具体的含意。 NewSQL 分布式架构：多节点的分布式数据库服务器，每一台服务器既蕴含了计算资源，又有各自的存储节点，解决了传统单机数据库伸缩性和高可用问题。多引擎：数据库服务器中可能存在多个存储引擎，不同的引擎个性不同，负责不同的场景。MPP 并行计算：将工作并行地扩散到多个服务器和节点上，在每个节点上计算实现后，将各自局部的后果汇总在一起失去最终的后果。1.1 晚期架构详解进一步拆解，将视角拉到MatrixOne Server外部，它又有着多个模块，分工协同，实现整个分布式数据库的性能。一共分为5个局部，前端、计算层、分布式框架、存储层、元数据层。五个局部各自的性能与个性又各有不同。SQL Frontend 亦称SQL前端，是间接解决SQL语句的局部，它提供了如下性能： 提供MySQL兼容协定，确保MySQL的各类协定可能被MatrixOne接管；兼容MySQL的语法，对接管的SQL做合乎MySQL的语法判断。Query Parser是MatrixOne中对语法解析的功能模块，它提供了如下性能： SQL解析，对前端的SQL并转化形象语法树；方言反对，提供反对多种SQL方言根底。MPP SQL Execution是实现MPP的SQL执行器，它提供了如下性能： SQL减速，对SQL计算引擎的一些根底操作的向量化减速，局部操作采纳汇编改写做减速；Plan构建，应用独有的因子化减速能力做SQL的Plan构建。分布式框架晚期MatrixOne的分布式框架叫做MatrixCube，同样是一个开源我的项目，它具备了如下组件与性能： 提供高可用、多正本、强统一与主动负载平衡；提供分布式事务的反对能力（WIP）；提供基于Raft的正本调度机制，该调度器在代码中称为Prophet。存储层晚期的MatrixOne存储层是一个领有多个引擎的架构，多种存储引擎相互分工协作，共同完成HTAP数据库性能： AOE引擎，Append Only Engine，这是一个Append Only的列存引擎，不反对事务；TPE引擎，Transaction Processing Engine，用于保留元数据Catalog；TAE引擎，Transactional Analytical Engine，基于列存的HTAP引擎，会提供残缺ACID能力及弱小的OLAP能力。元数据层是一个在晚期MatrixOne架构中被每个其余模块都频繁调用的内容，保留在TPE引擎中，提供了全局的元数据的保留与读取，是一个频繁应用的模块。 1.2 晚期架构，何以有余？作为一个晚期的架构，更多的是承载了研发团队晚期的摸索和钻研，通过试验架构，逐渐摸索出一条面向未来的架构。随着开发进度的一直推动，毫无意外地，旧架构的问题开始凸显进去，并且随着性能与性能的晋升，愈发成为后续倒退的枷锁，集中在三个方面暴发： 拓展性 Share nothing架构，每扩大1单位节点，需同时扩大存算资源;每份数据至多要保留3正本，从扩大节点到实现，工夫更久.性能 Raft协定所蕴含的leader角色，容易造成热点；在性能较差的存储下，数据库整体性能降落会超过预期；多种引擎各自用处不同，性能各异，无奈有效应对HTAP场景。老本 数据保留3正本，随节点规模，老本一直攀升，云上版本更甚；只有高配存储能力施展数据库的预期性能。这三大难题不得不令MatrixOne团队去思考，到底什么样的架构能力满足将来HTAP的需要，让云用户与私有化客户，获得最佳产品体验与最佳实际。如同很多破而后立的故事的开始，此时此刻恰如彼时彼刻，由CTO田丰博士引领，MatrixOne团队开始了架构的降级之路。 Part 2 三座大山，推倒重来三大难题是旧的试验架构的表象，如果仅仅依据表象去解决问题，无疑只能做到知其然而不知其所以然。更深层次的起因，依然须要去被开掘与确认，通过MatirxOne研发团队的重复的假如与论证后，旧架构有余的根因，归结为三个大问题，这是压在MatrixOne之上的三座大山，如同幽灵个别，在每个MOer的头上回旋 2.1 分布式框架MatrixCube作为过后的分布式框架，提供了多正本存储模式，每一份数据都保留3正本并且以分片（shard）模式保留，使得存储的老本飙升。 而基于Raft选举的Leader节点，频繁成为了热点，各类操作都须要通过Leader节点进行散发，在极其业务场景下，Leader节点的负载会数倍于一般节点 2.2 引擎泛滥晚期的MatrixOne内置了三种存储引擎，三个引擎之间代码复用率较低，使得对性能的保护须要投入更多人力。 而基于因子化算法的Plan构建形式过于激进和形象，在计算组外部对其齐全了解的程序员数量无限，往往增加性能时仍旧须要主开一人实现，新性能增加迟缓。 2.3 资源分配旧架构采纳了存算不拆散的架构，这个架构导致了扩展性较差。每扩大一个单位的计算节点必须同步扩大存储资源。 因为存储采纳了shard分片，使得在shard较大时影响了OLTP的性能，在shard较小时，又会影响OLAP性能。在找到了三座大山之后，接下来要做的事件就是一一扳倒它们，田丰博士联合MatrixOne的产品愿景以及将来的技术趋势，对于试验架构进行了总结，并提出了MatrixOne独有的架构构想，从整个架构的现状来看，要分三步走： 第一步，将旧架构share nothing的框架破除，实现更灵便的解耦；第二步，将多种引擎合二归一，实现外部引擎的大一统；第三部，重构计算引擎，留有足够的空间给将来的产品倒退。Part 3 新生后的MatrixOne 新架构通过解耦，最终实现了三个各自独立的层级，每个层级有本人的对象单元与分工，不同类型的节点能够灵便伸缩，不再受到其余层的制约： 计算层 ，以计算节点Compute Node为单位，实现了计算和事务处理的Serverless化，又有本人的Cache，能够实现任意重启与扩缩容；事务层 ，以数据库节点Database Node为与日志节点Log Service为单位，提供残缺的日志服务以及元数据信息，内置Logtail用于保留最近数据；存储层 ，全量数据保留在以S3为代表的对象存储中，实现了低成本的无线伸缩存储形式，以File Service命名的对立文件操作服务，实现了不同节点对底层存储的无感知操作。 在确定了以TAE作为惟一存储引擎之后，对交融后的TAE引擎又做了诸多设计上的调整，才有了起初交融后的TAE存储引擎。实现了繁多引擎实现所有数据库存储行为的指标，并且具备了如下劣势： ...

本期试验将领导您应用Prometheus+Grafana搭建PolarDB-X监控体系 本期收费试验地址 本期教学视频地址 前置筹备假如曾经依据前一讲内容实现了PolarDB-X的搭建部署，能够胜利链接上PolarDB-X数据库。 启动模仿业务流量本步骤将领导您如何应用Sysbench Select场景模仿业务流量。 1.筹备压测数据。a.执行如下SQL语句，创立压测库。 create database sysbench_test;b.输出exit退出数据库。 c.执行如下命令，切换到账号galaxykube。 su galaxykubed.执行如下命令，进入到/home/galaxykube目录。 cde.执行如下命令，创立压测数据的配置文件sysbench-prepare.yaml。 vim sysbench-prepare.yamlf.按i键进入编辑模式，将如下代码复制到sysbench-prepare.yaml文件中，而后按ECS退出编辑模式，输出:wq后按下Enter键保留并退出。 apiVersion: batch/v1kind: Jobmetadata: name: sysbench-prepare-data-test namespace: defaultspec: backoffLimit: 0 template: spec: restartPolicy: Never containers: - name: sysbench-prepare image: severalnines/sysbench env: - name: POLARDB_X_USER value: polardbx_root - name: POLARDB_X_PASSWD valueFrom: secretKeyRef: name: polardb-x key: polardbx_root command: [ 'sysbench' ] args: - --db-driver=mysql - --mysql-host=$(POLARDB_X_SERVICE_HOST) - --mysql-port=$(POLARDB_X_SERVICE_PORT) - --mysql-user=$(POLARDB_X_USER) - --mysql_password=$(POLARDB_X_PASSWD) - --mysql-db=sysbench_test - --mysql-table-engine=innodb - --rand-init=on - --max-requests=1 - --oltp-tables-count=1 - --report-interval=5 - --oltp-table-size=160000 - --oltp_skip_trx=on - --oltp_auto_inc=off - --oltp_secondary - --oltp_range_size=5 - --mysql_table_options=dbpartition by hash(`id`) - --num-threads=1 - --time=3600 - /usr/share/sysbench/tests/include/oltp_legacy/parallel_prepare.lua - rung.执行如下命令，运行筹备压测数据的配置文件sysbench-prepare.yaml，初始化测试数据。 ...

2023年4月7日，由中国DBA联盟（ACDU）和墨天轮社区联结主办的第十二届『数据技术嘉年华』(DTC 2023) 在北京新云南皇冠假日酒店隆重开启。HashData资深解决方案架构师李俊在4月8号专题会场6-“交融利用：湖仓技术创新”上发表了《基于HashData的湖仓一体解决方案的摸索与实际》的专题演讲。本文依据演讲实录整顿而成，演讲注释如下（全文浏览须要20分钟以上）： 一、湖仓一体的演进数据仓库的概念是比尔·恩门（Bill Inmon）在1991年出版的《Building the Data Warehouse》一书正式提出后被宽泛承受。通过30年倒退，在金融、通信、航空等各行各业都是有广泛应用。数据仓库具备便于BI和报表零碎接入，数据管控能力强的劣势，然而随着大数据的衰亡，体现出不反对非结构化数据、专有零碎老本高，专有数据格式、灵便度低的劣势。数据湖的概念衰亡于大数据的呈现，是在2010年左右，它具备存储老本较低、反对非结构化数据。数据湖一度被认为会取代数据仓库，然而随着数据湖投入理论利用中，人们逐渐发现到它的一些劣势：对BI零碎的反对有余、查问性能低、数据交互不实时、可靠性差等问题。在数据湖与数据仓库之间学术界、工业界产生过强烈的辩论，最初根本达成共识：数据仓库与数据湖就像苹果与橙子，它们是齐全不同的货色，不会互相取代。数据仓库和数据湖不会互相取代，它们会共存，独特组成企业的数据平台。Gartner提出的逻辑数据仓库概念就包含了数据仓库和数据湖两个局部，这也是目前大多数企业的一个现状。然而创新者并不满足于现状，在2020年左右由Databrick公司率先提出了Lakehouse的概念，在国内翻译成湖仓一体或者湖仓。不难看出Lakehouse是前一半起源Data Lake，后一半是起源Data Warehouse。它的寓意是Lakehouse排汇数据湖和数据仓库的劣势，创立一个新的平台。湖仓一体（Lakehouse）别离在数据格式、数据类型、数据拜访、可靠性、治理与平安、性能、扩展性、用户场景反对提出新要求。为了满足上述的新要求，湖仓一体（Lakehouse）必须具备如下的要害能力。存算拆散数据湖须要晋升的要害能力：事务BI反对性能数据治理与平安数据仓库须要晋升的要害能力：多数据类型机器学习老本二、国外湖仓技术倒退简介提到国外的湖仓技术，人们探讨最多的Databrick、Hudi、Iceberg这三家开源解决方案。Databrick家解决方案是DeltaLake,我有幸加入过DeltaLake的产品培训和试用，的确具备了事务、BI反对、性能等方面的要害能力，体验很好。Apache Hudi是DeltaLake的竞争对手。Apache Iceberg是DeltaLake的另一个竞争对手。正是因为开源Hudi、Iceberg疾速的倒退，逼迫DeltaLake由商用改为开源。谈到Iceberg，咱们须要重点介绍一个概念：Table Format(数据表格格局)，Table Format是形象层，帮忙计算引擎解决底层的存储格局（ORC、Parquet等），而不是像以前那样须要间接操作底层存储。这个概念很重要，在前面的技术分享会用到。下面提到Apahce DeltaLake/Apache Hudi/Apache Icerberg三种开源解决方案都是数据湖向数据仓库交融的技术路线，HashData作为一个数据仓库解决方案将向大家开展一个数据仓库向数据湖交融的新视角。三、HashData翻新与摸索实际HashData最后的产品原型是基于Greenplum，它是一个典型的MPP架构，然而它是存算耦合的，即数据存储、数据计算都在一个数据节点。通过面向云原生的重复迭代设计后，HashData v3的架构是这样的。它是一个服务、计算、存储三者拆散的架构，无效解决了传统MPP的木桶效应问题，使得HashData数据仓库具备反对超大规模的集群能力。HashData目前曾经胜利利用于C行的超大规模数据仓库服务，截止2022年底，目前在生产中曾经有2万多个数据节点 在运行，数据存储约13PB左右。数据仓库向数据湖交融另一挑战是如何提供低成本解决方案？来自华为云官网的数据显示，对象存储的老本仅仅只有磁盘、SSD的价格的几十分之一。如果把所有的数据全副存储在对象存储中，整体解决方案将大幅升高。可怜的是对象存储的IO不太好，这样会就义性能。在价格和性能两头，咱们采纳多级存储技术：长久化数据存储在对象存储中，在计算层减少热点缓存技术，很好的解决了这个问题。采纳了对象存储的HashData数据湖解决方案整体老本能够升高到原来的1/10，但通过热点缓存技术保障了性能。相干Benchmark数据报告表明，性能十分靠近原来的程度。对于机器产生的数据比方IoT数据，HashData反对流式计算引擎准实时写入，从而进步数据分析的实效性。在A能源团体案例中，对立数据湖曾经存储油藏、地质、勘探、生产等数据1.7PB，当然也有下面提到的机器设备产生的流式数据。对于半结构化数据，当初基本上数据库都有很好的反对，这是不反复阐明了。重点在于非结构化数据，数据库其实能够以二进制形式存储图片等，但应用起来比拟麻烦，这不是一个好的解决办法。对于非结构化分析，目前咱们给出的解决方案是分两局部：原始文件存储在对象存储中。解析进去的结构化数据存储于数据库中，便于检索比对。上面以高速公路的卡口数据分析案例进一步阐明。摄像头抓拍车牌信息后，将原始照片存储到对象存储，以做原始证据。解析进去的车牌号、色彩、工夫寄存到HashData数据库，以反对流量统计监测、逃费稽核等利用。对于机器学习，HashData反对SQL形式调用函数在库内进行机器学习，当初新增反对更凋谢的Python的原生反对。综上，HashData湖仓一体解决方案是一个以服务、计算、存储三者拆散的技术架构为基石，面向多种场景，包含数据仓库、数据湖，也包含数据因素市场等场景的解决方案。四、湖仓交融的思考与瞻望湖仓交融后的会造成一个对立存储+多计算引擎的格局。对于数据格式的交融，HashData后续会引入Iceberg作为TableFormat。

简介TiDB 是一款由 PingCAP 开源的 分布式关系型 数据库，主打 HTAP 能力，具备 优良的伸缩性。其开源社区弱小，产品颇具风行度。 数据同步场景中，TiDB 官网提供如 TiCDC、TiDB Binlog 等工具，但为了满足用户将 TiDB 数据迁徙同步到更加宽泛数据库的需要，CloudCanal 近期推出了 TiDB 为源端的数据迁徙同步 性能，本文将简要介绍该能力的落地。 性能介绍指标数据库和能力指标端数据源构造迁徙数据初始化增量同步数据校验数据勘误MySQL反对反对反对反对反对TiDB反对反对反对反对反对指标数据源一直减少中TiDB 源端特色能力不依赖 TiCDCTiDB 为源端的增量数据同步实现有两种形式 作为 TiCDC 上游接管变更记录，实现数据同步与 TiKV/PD 间接通信，接管实时变更数据，实现数据同步CloudCanal 思考到部署的 轻量性、可控性，抉择了第二种计划，跳过 TiCDC、TiDB Server 组件，间接与 PD 建设 gRPC 通信，实时接管源端数据变更记录，通过算法解析字节流内容，主动同步到对端数据库中。 反对断点续传长周期数据同步，工作可能会因为参数调整、问题数据修复、性能优化等操作暂停或重启工作，断点续传能力不可或缺。 CloudCanal 为 TiDB 源端定时或定量保留对端生产后的位点，以实现断点续传能力。 全量迁徙中，对亿级别数据量的大表中断重启，断点续传能力可尽可能少的影响迁徙进度，增量同步中，断点续传能力确保工作重启后可持续，并不失落数据。 变更事件保序订阅 TiDB 增量变更事件，可能因为各种起因，个别变更数据达到工夫不统一(乱序)，导致数据失落或变更谬误。 CloudCanal 为此采纳自研算法处理事件，并依据事务 最终提交工夫 来保障事务的有序生产。 反对 DDL、DML 增量数据同步CloudCanal 反对以 TiDB 为源端，TiDB、MySQL 为对端 (反对的对端数据源还在一直减少) 的 DDL 和 DML 同步。 DDL 数据同步能力： ALTER TABLE ... ADD/DROP/MODIFY COLUMN ...ALTER TABLE ... ADD/ALTER/DROP INDEX ...RENAME TABLE ... TO ...DML 数据同步能力 ...

青山遮不住，毕竟东流去。 生机勃勃的春天送来了2023年4月的 墨天轮中国数据库风行度排行。 本月共有263个数据库参加排名，排行榜前30的数据库中，有13个数据库锋芒毕露，处于上行趋势，中国数据库行业整体风行度有所增加。细观本月榜单前十，能够用一句话概括为：OTO 组合崩溃，达梦厚积薄发夺探花；榜单第五至十名较上月未有变动。 图1：2023年4月排行榜TOP10得分详情表 一、群雄逐鹿榜单前十在本月排行榜前十中，间断四个月持重开局的 OTO 组合崩溃，OTD 组合开新局。本月榜单第五至十名仍维持着上月名次。值得注意的是，墨天轮榜首尽管仍是 OceanBase，然而其与第二名的分数差距有所拉大，这表明 OceanBase 风行度一劳永逸。接下来具体看看排行榜前十名的得分以及排名状况。 间断霸榜五个月的 OceanBase 本月以688.36分位居第一，始终致力于打造极致的开发者敌对数据库的成绩。 上月，首届 OceanBase 开发者大会在北京举办，OceanBase 从用户视角设计，诞生了一系列的成绩。OceanBase 4.1 版本公布、向导式的装置部署、场景化文档的公布，这一系列动作使 OceanBase 与用户之间的间隔日益拉近，因而风行度居高不下。TiDB 以609.16分排名第二，较上月名次没有变动。 其在线上社区发展各种培训流动、提供多样的学习文档。为了更密切地接触使用者，TiDB 也举办了各种线下沙龙。目前其已是中国风行度颇高的开源产品，然而宣发上比拟低调，本月风行度有所降落。较上月回升一位至榜单第三的达梦，以553.46分反超了 openGauss。 国产化代替正在减速推动，传统的数据库厂商具备先发劣势。达梦代码自研率100%，在政府端等畛域获得了重大成果。行将成为“国产数据库第一股”的达梦成为了泛滥公司进行数据库替换的首选。因而，达梦整体的热度有所上涨。openGauss 以521.20分位列榜单第四，较上月名次降落一位。 上月末，openGauss 5.0.0 里程碑版本公布。此版本是 openGauss 公布的第三个LTS版本，版本生命周期为3年。openGauss 5.0.0版本与之前的版本性能个性放弃兼容，在内核能力、工具链、兼容性方面全面加强。因为公布的工夫为月末，其相干的关键词所带来的热度于次月才会有显著的减少。人大金仓间断三个月位列排行榜第五。 其致力于为宽广学子提供产业视角，搭建更加宽阔的实际平台。目前人大金仓已与中国人民大学、北京交通大学、北京科技大学、重庆邮电大学等多所高校，就课程共建、科研单干、实习实训、研究生联培、业余赛事等不同方面达成单干。各类的数据库常识进校园的生态建设流动进步了人大金仓的热度。以0.47分的分数劣势位列第六的 PolarDB，本月维持着上月的名次。 上月，阿里云瑶池数据库峰会上，阿里云首次将云原生数据库 PolarDB 和云原生数据仓库 AnalyticDB 买通交融，造成“云原生一体化”的 HTAP 解决方案。这一降本增效的解决方案吸引了泛滥使用者关注。此外，云原生数据库 PolarDB PostgreSQL 版取得“开源数据库卓越贡献奖”。这一系列的动向都是围绕着用户登程。距第六名仅差2.28分的 GaussDB，本月名次较上月未变，以407.62分位列排行榜第七。 上月，华为云 GaussDB 数据库社区重磅上线，社区的建设更利于造成自在交换、常识分享的学术气氛，也能增强与使用者之间的分割。GaussDB 独立社区的建设，将来将会吸引更多的潜在用户。TDSQL 本月以278.88分位列榜单第八。 3月24日，腾讯云数据库 [TDSQL 顺利通过TPC-C 基准测试](https://www.modb.pro/db/621135?0414)，性能达到每分钟8.14亿笔交易（tpmC），突破世界纪录。这也标记着国产数据库 TDSQL 的分布式架构设计和资源调度能力，均达到了业界顶尖程度。腾讯云数据库 TDSQL 曾经进入规模化复制的第四个阶段，此次能力和性能的展现，将会失去泛滥金融行业等潜在用户青眼。历经近二十年的打磨，GBase 的产品体系、生态建设等进一步欠缺。本月其以252.22分位列排行榜第九。 上月，GBase 在人才培训、生态建设、市场拓展等方面有所停顿。GBase 8c 荣获第12届 PostgreSQL 中国技术大会评比的“数据库最佳利用奖”、第三期“GBase 8c多模多态分布式数据库认证培训班”预报名冲破500人，传统数据库厂商焕发出新生机。AnalyticDB 是阿里云自主研发的云原生数据仓库，本月以208.1分排名第十。 近日，阿里云立志要成为“云原生一站式”数据库的领导者。这一指标有助于推动整个中国数据库行业向云原生数据库方向后退。AnalyticDB 也将瞄准更准确的场景，不断完善优化。二、能者谋局怀才不遇本月排行榜十名之后，有一些数据库产品踊跃布局，动向频繁，本月排名较上月有显著晋升。限于篇幅，小编仅在此筛选了局部数据库的得分和排名，一起来看看它们的倒退动静。 ...

随着企业数据量的增多，为了配合企业的业务剖析、商业智能等利用场景，从而驱动数据化的商业决策，剖析型数据库诞生了。因为数据分析个别波及的数据量大，计算简单，剖析型数据库个别都是采纳大规模并行计算或者分布式计算来晋升它的数据处理能力。本篇文章将具体介绍 MPP 数据库的概念，解决的问题、典型的厂商以及它的技术架构和将来的倒退方向。 — MPP数据库简介— 剖析型数据库是数据库的一个分支，次要设计指标是存储、治理和剖析数据，个别存储的数据类型多，工夫维度长，次要配合企业的业务剖析、商业智能等利用场景，驱动数据化的商业决策。因为数据分析个别波及的数据量大，计算简单，剖析型数据库个别都是采纳大规模并行计算或者分布式计算来晋升它的数据处理能力。 行业内从1984年开始推出基于多个关系数据库（Postgres为主）组成的MPP数据库形式来晋升计算能力，代表性的产品有Teradata、Netezza、Vertica等。MPP全称为Massive Parallel Processing，是一种并行化的编程模型，其思维是通过治理来协调的，由多个处理单元并行处理一个程序中的不同局部，从而最终实现整个程序的计算模式。每个处理单元有本人独立的运行环境和资源。MPP数据库中每个处理单元就是一个关系数据库，通过大规模并行的关系数据库的协同来晋升数据库可能解决的数据的量级和性能。基本上每个支流的关系数据库厂商都有本人的MPP版本，另外也有一些次要开发MPP的数据库厂商和开源的MPP数据库，国内近几年也涌现了不少的MPP数据库。 — 总体架构 — MPP数据库个别会蕴含多个管制节点和多个计算节点，管制节点负责计算工作的编译、执行打算的生成和计算结果的聚合，而计算节点负责计算划分到具体数据库实例的计算工作。为了更好的可扩展性，MPP数据库个别采纳Shared-nothing架构，每个数据库节点之间没有数据共享。MPP数据库个别能够通过减少数据库计算能力，此外因为多个实例，数据库总体的数据加载性能相比拟单实例数据库也有很高的晋升。 数据分片是可能实现并行化计算的外围，MPP数据库有多种数据分片形式，次要包含3大类： Hash模式个别实用于事实表或大表，依据一条记录的某个字段或组合字段的hash值将数据扩散到某个节点上，hash函数能够有多种形式。通过依据对给定字段的hash值来做数据分布，一个大表能够平均的扩散到MPP数据库的多个节点上，当对这个表查问时，MPP数据库编译器能够依据SQL中相应的检索字段将查问疾速定位到某个或几个相干的数据库节点并将SQL下发，对应的数据库节点就能够疾速响应查问后果。Hash模式在实在生产中应用的比拟多，不过它也有几个较显著的问题：一是Hash取值个别是跟数据库节点数量密切相关，如果数据库增加或者缩小节点后，那么曾经存在的数据的Hash散布就不再正确，因而须要做数据库的数据重散布，带来较大的运维老本；二是在实际操作中须要依据业务特点来设计或抉择Hash字段，否则容易呈现性能热点等影响数据库整体性能的问题。均匀分布模式个别实用于一些过程中的长期表，在对表的数据的长久化过程中依照均匀分布的形式在每个数据库节点上平均写入数据。这个模式下数据库的IO吞吐能够失去最大化利用，无论是读取还是写入，仅适宜表只做一次读写的场景。全复制模式个别适宜记录数比拟少的表，个别状况下在各个数据库节点都残缺的存储一份数据。这类表个别状况下用于大量的剖析类场景，事务类操作比拟少，因而尽管存储上有显著的节约，然而在剖析性场景下不再须要将这个表在多个数据库节点上传输或复制，从而晋升剖析性能。 基于数据分片的形式实现了数据无共享架构，因而能够通过减少数据库实例的形式来晋升数据库的性能，因而与晚期的SMP共享架构数据库（典型代表Oracle RAC）相比，MPP数据库的剖析性能要远远超出。此外数据库的整体并发响应，以及数据库的读写吞吐量，MPP数据库都可能通过无效的业务优化达到一个很高的程度。 在MPP数据库的可扩展性方面，从中国信通院的相干测试来看，开源的MPP数据库可能反对一百节点左右的集群规模，而一些商业MPP数据库通过更好的软硬件联合曾经能够实现单集群达到五百个节点。— 开源MPP数据库Greenplum —Greenplum是以PostgreSQL为单实例的MPP数据库，于2003年诞生，在2012年之后演进成为Pivotal Greenplum Database。Greenplum用于存储、解决海量的数据，次要用于OLAP业务。Greenplum采纳MPP架构，底层的逻辑数据库采纳PostgreSQL，客户端反对psql和ODBC。 Greenplum集群中有三种角色组件，Master、Segment、Interconnect。数据的分片形式以及SQL计算的合成/聚合和通用的MPP数据库原理基本一致，在此不做赘述。 Master是Greenplum数据库系统的入口，承受客户端连贯及提交的SQL语句，将工作负载分发给其它数据库实例（segment实例），由它们存储和解决数据。Master也负责长久化和查问零碎级元数据，负责认证用户连贯，接管来自客户端的SQL解决申请，最终汇总Segments的后果并返回客户端。Master Server自身采纳主备形式来保障高可用。 Segment是独立的PostgreSQL数据库，负责数据存储和剖析的具体执行，集群中的数据分布在各个Segment上，用户不间接与Segment通信，而是通过Master交互。每个Segment的数据冗余寄存在另一个Segment上，数据实时同步，当Primary Segment生效时，Mirror Segment将主动提供服务。 Interconnect负责不同PostgreSQL实例之间的通信，它默认应用UDP协定以提供更好的网络性能，并通过对数据包的测验来保障可靠性。 从2019年中国信通院组织的剖析数据库基准测试后果来看，一共有14个产品通过测试，其中6个产品是基于Greenplum来二次开发的，这阐明了Greenplum是开源MPP数据库的最受欢迎我的项目。除了自身开源以外，Greenplum在以下几方面也比拟独特： SQL兼容度：因为Greenplum基于PostgreSQL内核，因而其自身放弃了关系数据库的个性以及SQL的兼容性，以及与PostgreSQL类似的平安和权限模型。此外，Greenplum反对残缺的分布式事务操作和MVCC，因而在事务相干操作上也兼容规范SQL语义。剖析性能：在SQL优化方面， GPORCA优化器是基于代价的优化器的一个杰出的开源我的项目，为各种简单的剖析SQL有个极佳的执行打算。并行数据加载：Greenplum提供了并行加载的技术，其自带的gpfdist工具可能间接和每个Segment交互做并行导入。开放式的架构：因为PostgreSQL可能反对插件化的形式来自定义数据类型、函数、存储过程等能力，Greenplum也天然继承了这一特点，因而社区的开发者先后奉献了包含天文时空数据处理、机器学习、图剖析、文本剖析等在内的多个扩大模块，以及反对了JSON、XML等半结构化数据类型。因为Greenplum数据库依然是基于典型的MPP架构，因而MPP数据库的规模问题（单个集群规模在200节点以内）、多租户资源隔离问题、落后者问题等依然存在，因而在撑持大型企业的多个业务场景时存在较大的技术挑战。因为其比拟良好的SQL兼容、分布式事务、优良的优化器等能力，Greenplum能够比拟好的反对一些中小型企业的结构化数据分析工作。Greenplum本身也在致力和云计算联合来解决多租户资源隔离问题，其曾经和多个私有云厂商单干推出云上的数据库服务。另外，Greenplum也在更加严密的与PostgreSQL社区单干，踊跃的跟进其最新的性能。 — MPP数据库的架构问题与将来倒退方向 — MPP数据库通过并行计算来解决了很多的数据分析的能力问题，不过也有它的架构缺点，次要包含以下几个问题： 数据的散布对业务的性能影响极大：在抉择数据分布算法以及对应的分片字段的时候，不仅要思考数据分布的平均问题，还须要思考到业务中对这个表的应用特点。如果多个业务的应用形式有显著差别，往往很难抉择一个十分好的表分片字段，因而会导致一些因为数据或业务不均匀分布或跨节点数据shuffle可能引起的性能问题。落后者问题（又称Straggler Node Problem）是MPP数据库的一个重要架构问题。工作负载节点（对GPDB而言是Segment节点）是齐全对称的，数据平均的存储在这些节点，处理过程中每个节点（即该节点上的Executor）应用本地的CPU、内存和磁盘等资源实现本地的数据加工。当某个节点呈现问题导致速度比其余节点慢时，该节点会成为Straggler。此时，无论集群规模多大，批处理的整体执行速度都由Straggler决定，其余节点上的工作执行结束后则进入闲暇状态期待Straggler，而无奈分担其工作，如下图所示Executor 7即为落后者并最终拖慢了整个集群。当集群规模达到肯定水平时，故障会频繁呈现使straggler成为一个惯例问题。 集群规模问题：因为MPP的“齐全对称性”，即当查问开始执行时，每个节点都在并行执行完全相同的工作，这意味着MPP反对的并发数和集群的节点数齐全无关。在大数据时代，对于联机查问的并发能力要求减少十分迅速，也极大的挑战了MPP架构自身。此外，MPP架构中的Master节点承当了肯定的工作负载，所有联机查问的数据流都要通过该节点，这样Master也存在肯定的性能瓶颈。因而很多MPP数据库在集群规模上是存在肯定限度的。 多租户资源隔离问题是MPP数据库一个十分难解决的一个架构问题。因为一个企业的MPP数据库个别撑持多个业务或多个租户，如果某个业务的局部SQL剖析在数据库节点Node 1上产生了热点并占用了该节点绝大部分的资源，从而拖慢了所有的可能应用Node 1的其余租户或业务，导致整体业务服务能力好转。从咱们对行业的一些大型企业客户的调研后果看，这个问题是十分致命的问题，只能通过运维的伎俩来检测并敞开相似的热点SQL来缓解。 更好的撑持AI程序处理半结构化或非结构化数据是MPP数据库的一个重要挑战，尤其是在人工智能相干的需要暴发后，NLP、智能辨认等技术都须要无效的半结构化或非结构化数据的存储、检索和计算需要，而这些都不是关系数据库善于的能力。 随着硬件技术的疾速倒退，尤其是SSD和网络性能的大幅度晋升，MPP数据库厂商都开始基于这些新硬件技术来解决以后的软件架构问题，如采纳更高速的网络来晋升总体的可扩展性，解决集群规模存在下限的问题。另外局部MPP数据库从新设计其执行模式，调整其计算架构同时反对MPP和DAG模式，通过更加的执行打算和Lazy Evaluation形式来解决常见的“落后者”问题。此外，近几年MPP数据库厂商都在推动存算拆散架构，让底层能够间接依赖云存储等形式，从而实现云化服务，并以此来实现多租户隔离等治理能力。 — 小结—本文介绍了剖析型数据库MPP数据库，它通过大规模并行的关系数据库的协同来晋升数据库可能解决的数据的量级和性能。那么，剖析型数据库的另外一个倒退方向是以分布式技术来代替MPP的并行计算，一方面比MPP有更好的可扩展性，另一方面能够解决MPP数据库的几个要害架构问题，下篇咱们将介绍分布式剖析型数据库。

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。GreatSQL是MySQL的国产分支版本，应用上与MySQL统一。作者： Yejinrong/叶金荣文章起源：GreatSQL社区投稿背景介绍编译环境编译前筹备工作编译GreatSQL初始化并启动GreatSQL数据库运行sysbench测试附录：编译sysbench1. 背景介绍为了能更好地反对更多操作系统及相干生态，咱们决定公布openEuler、龙蜥Anolis、统信UOS三个操作系统下的GreatSQL二进制包。相应的二进制包能够拜访gitee.com上的 GreatSQL我的项目 https://gitee.com/GreatSQL/GreatSQL/releases/tag/GreatSQL-8.0.25-17下载。 本文简要记录在这三个操作系统下编译GreatSQL二进制包的过程。 2. 编译环境本次编译都是采纳鲲鹏916这个型号的CPU（泰山2280服务器系列）： $ lscpu Architecture: aarch64 Byte Order: Little Endian CPU(s): 64 On-line CPU(s) list: 0-63 Thread(s) per core: 1 Core(s) per socket: 32 Socket(s): 2 NUMA node(s): 4 Model: 2 BogoMIPS: 100.00 L1d cache: 32K L1i cache: 48K L2 cache: 1024K L3 cache: 16384K NUMA node0 CPU(s): 0-15 NUMA node1 CPU(s): 16-31 NUMA node2 CPU(s): 32-47 NUMA node3 CPU(s): 48-63 Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid上述 lscpu 是在物理机上执行的，理论编译环境则是在这个物理机上运行的虚机中，调配了8个CPU、16G内存。 ...

导读： 随着叮咚买菜业务的倒退，不同的业务场景对数据分析提出了不同的需要，他们心愿引入一款实时 OLAP 数据库，构建一个灵便的多维实时查问和剖析的平台，对立数据的接入和查问计划，解决各业务线对数据高效实时查问和精细化经营的需要。通过调研选型，最终引入 Apache Doris 作为最终的 OLAP 剖析引擎，Doris 作为外围的 OLAP 引擎反对简单地剖析操作、提供多维的数据视图，在叮咚买菜数十个业务场景中广泛应用。 作者｜叮咚买菜资深数据工程师 韩青 叮咚买菜创建于 2017 年 5 月，是一家专一美妙食物的守业公司。叮咚买菜专一吃的事业，为满足更多人“想吃什么”而致力，通过美妙食材的供给、美妙味道的开发以及美食品牌的孵化，一直为人们提供美好生活的解决方案，致力让更多人吃得陈腐、吃得省心、吃得丰盛、吃得衰弱......以更美妙的舌尖体验，为古代家庭发明美味与幸福感。 业务需要随着叮咚买菜业务的倒退，不同的业务场景对数据分析提出了不同的需要，这些需要最终被数据看板、实时 Ad-Hoc、行为剖析、B/C 端业务平台和标签平台等零碎利用所承载，为实现这些零碎利用，叮咚大数据心愿引入一款实时 OLAP 数据库，旨在提供一个灵便的多维实时查问和剖析的平台，对立数据的接入和查问计划，解决各业务线对数据高效实时查问和精细化经营的需要。基于上述诉求，咱们心愿所引入的数据库具备以下能力： 能够实时高效地剖析和应用数据；能够反对明细数据、汇总数据两种不同的数据查问形式；能够对入库后的数据即席抉择维度和条件查问，实时/近实时返回后果选型和比照咱们次要比照了 Apache Doris 和 ClickHouse 两款市面上最常见的开源 OLAP 引擎，在选型过程中咱们次要思考以下几个方面： 反对规范 SQL，无需投入额定的工夫适应和学习新的 SQL 方言、间接用规范 SQL 即可间接查问，最大化升高应用门槛；反对 Join 操作，不便事实表与维度表进行关联查问，在应答维度更新时具备更高的灵活性、无需对解决后的宽表进行重刷；反对高并发查问，零碎面临多条业务线的同时应用，因而须要有比拟强的并行查问能力，以更好满足业务需要；反对离线和实时导入，可与已有技术栈轻松对接，反对多个数据源或大数据组件的离线和实时导入，以更好适配不同应用场景；反对大数据量的明细数据查问，以满足不同业务用户灵便多变的剖析需要；通过详尽的技术调研，Apache Doris 各项能力都比拟优异，在咱们的大多数业务场景中都须要明细数据级别的查问、高并发的点查和大数据量的 Join，而这几个方面 Apache Doris 相较于 ClickHouse 均更胜一筹，因而咱们决定应用 Apache Doris 来搭建新的架构体系。 架构体系在整体架构中，各个组件承载着特定的性能，Elasticsearch 次要负责存储标签零碎的数据，HBase 是实时数仓的维表层，MySQL 用于存储业务零碎的数据存储，Kafka 次要存储实时数据，Spark 次要提供 Ad-Hoc 查问的计算集群服务，而 Apache Doris 作为外围的 OLAP 引擎反对简单地剖析操作、提供多维的数据视图。 离线局部： 数据从业务库通过 DataX 导入到数据仓库 ODS 层，通过层层解决输入到 Doris 中，下层 BI 零碎链接到 Doris 进行报表展现。实时局部： 数据通过 Flink 生产 Kafka 中的数据，进行相应的逻辑解决后，输入到 Doris 或者 HDFS 中，供应用层应用。 ...

笔记类 App 都很强调个人化，因为咱们每个人会用不同的办法来做笔记、写日记。不过有一些框架能够帮忙咱们，比方子弹笔记（Bullet Journal）等。 Tana 和 Amplenote 都能够应用「标签」，只管它们解决的形式、体验都大不相同。 Amplenote 有一个涣散的组织框架，重大依赖标签来聚拢想法。与 Tana 相比，它的反向链接和援用能力十分弱。在Tana中，你能够通过许多不同的形式来建设构造，最弱小的是数据库（database），而后超级标签重叠在它们之上。但对某些人来说，Tana 最大的劣势也可能是它的毛病。Tana 是围绕着节点建设的，为了创立好的构造，你必须做一些批判性的思考，看看什么能最好地服务于你，这能够大大增加你工作流程的便利性。 Tana 中的“我的工作”节点 我是在2019-2021年左右应用了Amplenote ，在此期间它尽管是我次要的笔记软件，但同时我依然应用了其它相似软件。 我的 AmpleNote 工作区的照片 Amplenote 的「工夫块」性能给我留下了粗浅的印象。Amplenote 就像是一套应用程序，有 Daily Jots、Notes、Tasks 和 Calendar这些性能，他们都能够相互嵌入。我始终在应用Bear，除了没有每日打算性能外，它在结构上是类似的。Amplenote 扭转了我过来应用相似 app 的固定模式，因为在Amplenote里，工夫块和笔记是彼此的子集。只管我始终应用 Things3 来实现工作，但我应用了标签和反向链接。Amplenote 能够做很多事件，但在实践中，对我来说，它太横七竖八了，所以我只像 Bear 一样应用它。 图片来自amplenote.com 对我来说，Tana 是一个更有凝聚力的体验，它把所有都交融在一起。但将它用作更长格局的 wiki 成果不佳，因为没有块选项。而且其无奈与没有 Tana 帐户的人共享节点，因而合作很艰难。但我依然抉择 Tana 而不是有数其余选项作为我思考的次要场合，因为它们的组织是无缝的。一个例子是我之前用 Amplenote 写过我的教训，所以我在开始写这篇文章的节点中找到了能够援用它的节点。当我开始重写我新近的想法时，参考资料又失去了更新。 ‼️ 妙记多 Mojidoc 是兼具了 Amplenote, Tana 长处于一体的笔记工具：✅它领有和Amplenote相似的「块编辑器」，容许内容自由组合沉积，为你带来更加灵便的排版体验； ✅它也像 Amplenote 一样，能将待办工作放在日历表里，但它不止于此，而是实现了“待办清单+日程安排+文档内容“三合一，防止了多个应用程序来回切换的不便，真正实现了项目管理/工作治理的简略高效； ✅它具备和Tana, Amplenotes 标签性能相似的设计，妙记多可能在账号外部划分出多个空间，你能够依据本人的爱好来进行分类管理，比方喜好空间、工作空间、学习空间等等，在空间外部也能够将文档归属于不同「页面」下，真正打造有序的协同空间； ✅它具备和 Tana 相似的援用性能，妙记多反对「内联文档」， 你可在文档内援用其余文档，实现文档整顿上的关联性； 最要害的是，妙记多还具备 Tana, Amplenote 没有的「协同性能」，它反对多人实时协同编辑、反对利用“接力”性能来继续推动以文档为载体的我的项目流程治理、反对文档内间接开启语音通话、会后间接语音转文字等等； ...

小 T 导读：taosKeeper 是 TDengine 3.0 的运行状态指标监控工具，通过简略的几项配置即可获取 TDengine 的运行状态信息。其应用 TDengine RESTful 接口，所以不须要装置 TDengine 客户端即可应用。本文将具体解读 taosKeeper 的具体语法规定，不便有须要的用户发展利用。时序数据库 TDengine（ Time Series Database） 通过 taosKeeper 将服务器的 CPU、内存、硬盘空间、带宽、申请数、磁盘读写速度等信息定时写入指定数据库，也反对对重要的零碎操作（比方登录、创立、删除数据库等）以及各种谬误报警信息进行记录。系统管理员能够从命令行间接查看该数据库，也能够在 Web 端通过图形化界面查看这些监测信息。这些监测信息的采集缺省是关上的，也能够通过批改配置文件里的选项 monitor 来敞开。 taosKeeper 装置形式：独自编译 taosKeeper 并装置，详情请参考 taosKeeper 仓库（https://github.com/taosdata/taoskeeper）。 配置和运行形式taosKeeper 须要在操作系统终端中执行，该工具反对三种配置形式：命令行参数、环境变量和配置文件。优先级为：命令行参数、环境变量、配置文件参数。 须要留神的是，在运行 taosKeeper 之前要确保 TDengine 集群与 taosAdapter 曾经正确运行，并且 TDengine 曾经开启监控服务。监控配置可参考相干文档，具体的配置项包含 monitor、monitorFqdn、monitorPort、monitorInterval 和 telemetryReporting。 命令行参数启动能够间接执行 taosKeeper，也能够在执行命令时提供命令行参数。 $ taosKeeper环境变量启动通过设置环境变量达到管制启动参数的目标，通常在容器中运行时应用。 $ export TAOS_KEEPER_TDENGINE_HOST=192.168.64.3$ taoskeeper具体参数列表请参照 taoskeeper -h 输出后果。 配置文件启动执行以下命令即可疾速体验 taosKeeper。当不指定 taosKeeper 配置文件时，优先应用 /etc/taos/keeper.toml 配置，否则将应用默认配置。 $ taoskeeper -c <keeper config file>具体配置文件示例请参考：https://docs.taosdata.com/reference/taosKeeper/ ...

近期，StarRocks V3.0 RC 版本公布。自此，StarRocks 开启了从 OLAP 到 Lakehouse 演进的新篇章。 全新降级的 StarRocks 3.0： 通过存算拆散架构，帮忙用户升高存储老本、晋升计算弹性 通过数据湖剖析、物化视图等个性简化湖仓交融，实现极速对立湖仓剖析 通过新的 RBAC 权限框架，实现湖仓数据的对立治理4 月 19 日早晨 7 点，StarRocks Active Contributor 张友东将在线解说从 shared-nothing 到 shared-data 的湖仓剖析新范式如何帮忙用户实现“极速对立“的价值。 预约直播，流动邻近将为您发送开播信息，赶快预约吧！ 其余流动举荐 此外，StarRocks 社区推出有奖征文｜领先体验存算拆散新性能，“码”上拿大奖！流动，旨在帮忙大家分享教训和防止同样的谬误。本次流动不仅前三名有大奖，而且每位参与者都有机会取得奖品。心动不如口头，快来加入吧！更多流动细节，请点击浏览原文

利用场景及痛点介绍高质量数据已成为企业重要的资产与财产，能够无效助力金融机构打造数字时代的外围竞争力。金融机构进行业务翻新，须要对现有和新增的经营治理数据进行深度开掘与剖析，明确评估新产品和新服务的老本、危险及收益，推出具备竞争劣势的翻新金融业务，晋升客户体验和外围竞争力。而这所有的根底，是须要提供治理后的高质量的经营治理数据。因而，金融机构须要建设欠缺的数据治理机制，充沛保障数据品质，才可能为业务翻新和外围竞争力的晋升提供无力反对。 在长期的数据治理实际中，金融行业的数据治理面临着诸多挑战，这当中有技术、有业务、也有零碎难题，数据血统治理便是其中的一个技术、业务和零碎交错的挑战。 金融机构数据起源和处理过程不通明，数据扩散在多个零碎和应用程序中，难以对立治理和管制，使得存储、查问和剖析数据血缘关系变得艰难；技术架构简单，波及多种技术、脚本和工具，如数据库、数据仓库、ETL 工具等，使得数据血统解析更加艰难；开发团队更关注性能需要的实现，而对非性能需要的关注有余，导致数据模型品质不高，存在先净化后治理的景象。这些问题间接导致了难以通过全自动化的伎俩，全面构建具备高准确率的细颗粒度血统脉络。 目前少数血统治理计划仅仅解决了血统治理从无到有的问题，仅能实现表级的血统治理。然而只有字段级血统治理能力真正满足金融机构血统治理的业务要求，实现对数据的追根溯源，并高效保障数据品质。然而，字段级血缘关系通常远多于表级血统，字段血统的解析、存储、查问、剖析对数据治理平台能力提出了更高的要求。因而，咱们翻新地将图数据库、图剖析技术用于数据血统治理解决方案，不仅能够多层次展示字段级血统链路全貌，同时亦可对整体血缘关系进行实时高质量剖析，进而进步数据的合规性、数据可运维能力和数据品质，升高数据经营老本和数据危险，为企业数据资产平台的建设打好根底。 Fabarta 及产品介绍Fabarta （北京枫清科技有限公司）作为一家专一于图智能畛域的国际化公司，致力于解决在大规模增长的多源异构数据环境下的图智能难题，赋能企业客户和业务合作伙伴更加便捷地在图智能剖析平台之上积淀业务价值，梳理与治理数据资产，帮忙企业疾速高效地构建丰盛的图智能畛域利用，构建基于数据编织的下一代企业数据智能平台。 目前 Fabarta 的产品体系分为三层：根底层是 ArcGraph 图智能引擎，交融了图数据库和图计算能力，采纳齐全分布式的架构设计，为企业提供更高速的查问性能和一体化应用体验，曾经实现了中国信通院“可信数据库”评测；中间层是低代码化的图剖析平台，简化简单的图技术细节，让图技术疾速落地于业务场景中；最上层是围绕垂直畛域打造的改革型利用，目前已有图加强数据治理平台产品，利用图和 AI 技术切实解决数据治理难题，帮忙企业进步数据品质，无效领导业务倒退。 解决方案及亮点介绍Fabarta 图加强数据血统治理解决方案，充沛交融了 Fabarta 图智能产品矩阵及图智能引擎能力： 通过 ArcGraph 图智能引擎对元数据进行图化治理，进步数据完整性和可追溯性，进步了数据血缘关系的建模和存储效率，放慢了数据血缘关系的查问和剖析速度。通过 Fabarta 图加强数据治理平台的外围性能血统治理性能，联合基于大模型技术的 AI 算法，进行数据血统智能解析，提供清晰的数据链路；实现全面、精确的数据血缘关系追溯，不便疾速发现并排查数据链路中的问题以及可能带来的影响。优化了数据治理流程，进步了合规监管和风险管理能力。通过 Fabarta 低代码图剖析平台图剖析能力，联合内置的图算法，实现了对元数据进行血缘关系数据孤岛、要害数据和循环依赖的剖析。该计划基于金融行业数据现状和治理需要，借助 Fabarta 自有的图引擎能力和 AI 解析能力，能够解析各种脚本，主动构建血统链路，并依据数据变动被动剖析其上下游影响。甚至能够被动倡议数据脚本的编写形式，辨认血统链路中的孤岛、环路以及重要数据节点等。不仅能够帮忙企业疾速修复数据品质问题，还能够进行前瞻性的剖析，提醒潜在问题，帮忙企业进行脚本和数据模型的设计，无效保障数据品质。此外，零碎可能精准辨认相干影响，而不须要在群里播送告诉，从而进步工作效率。 该计划实现了全面、精确的数据血缘关系追溯，可能疾速定位数据问题，无效地进步了数据治理效率；可能更好地治理和爱护数据，进步数据的安全性和可靠性，晋升企业合规监管和风险管理能力，实现数据价值的最大化。该计划已被多个客户采纳，客户对计划的理论应用体验十分认可，对其成果给予了充分肯定。

欢送拜访 OceanBase 官网获取更多信息：https://www.oceanbase.com/ 本文来自社区分享，仅限交换探讨。原文作者：中国联通软件研究院济南分院 唐素珍、邱永刚。 原文转载自公众号：联通软件研究院（Chinaunicom-Software）精雕细琢方为器，千锤百炼始成钢。 联通软研院平台架构部数据库研发团队，历时13个月实现了对社区版OceanBase的优化改良，打造了ChinaUnicom Database for OceanBase（以下简称CUDB for OB）分布式HTAP数据库产品。保持边用边改、以改促用，使得该产品失去规模利用，获得良好的应用成果。 CUDB for OB齐全适配了PKS体系，完满补齐CUDB 分布式HTAP数据库的空白，为联通云产品体系再添新星。 CUDB for OB将产品的开明、应用、监控和运维全面接入联通云，实现产品资源的一点开明、一点交付、一点监控、一点运维和一点操作，为联通云租户提供易用而业余的一站式服务。 一、产品个性（一）高可用社区版OceanBase在可用性方面是三正本能力，但存在监控体系不欠缺、突发异样流量无应答策略、数据误删除复原繁冗及日常操作无治理等问题。数据库研发团队结合实际的生产场景，对全面监控、熔断拦挡、数据恢复、数据自治等能力进行研发实现及加强，用于晋升数据库高可用。 1.全面监控。 研发了涵盖集群级及利用实例级的监控指标体系，监控指标对接数字化监控平台，实现监控一点可视、告警实时推送。 2.熔断拦挡。 实际统计生产上数据库相干的故障80%是由不标准的SQL编码导致，弹性扩缩并不能从根本上解决问题，为此研发了SQL语句熔断优化，链接数拦挡性能，保障资源正当调配和业务可用性。 3.数据恢复。 研发了笼罩全场景的数据恢复核心能力，用于误操作时生产数据疾速复原，全库恢复模式可在10钟复原TB级数据到任意工夫点，精准恢复模式基于CLog解析性能，可按表主键、按表全字段疾速、精准复原DML语句的误操作。 4.数据自治。 对接在主研发的泛数据库自治服务平台CDAS，笼罩利用的研发态、生产态、日常运维态对数据库的应用场景，使人人都是DBA。 （二）省资源为了保障数据库高可用，个别依照流量顶峰进行资源配置，波峰波谷最高差距可达10倍，导致资源利用率不高。同时为了高可用又采纳一主两备形式，备机闲置加剧了资源利用率低的问题。因而，数据库团队优化资源应用形式，研发主动弹性扩缩能力，晋升资源利用率。 1.资源共享。 租户共享资源 ，采纳多租户共享资源池建设模式，租户间共享资源并互相隔离，进步资源利用率； 节点资源平衡利用 ，采纳表平衡散布在每个节点上模式，不再有备节点资源闲置问题，并且能够齐全横向扩容，资源利用率更高； 存储资源高效压缩 ，深度应用数据压缩性能，相比MySQL能够 无效节俭70-90%存储资源 。 2.弹性扩缩。 研发了数据库 租户在线秒级纵向扩缩，TB数量级小时级横向扩容 能力，实现 利用无感知扩缩容 ，利用无需为了应答顶峰拜访而冗余大量资源，从而进步资源利用率。 （三）迁徙快以后，生产上还有很多利用采纳MySQL 5.5、MySQL 5.6、MySQL 5.7等版本建设，生产问题时有发生，为了放慢对立技术栈收敛，研发高度兼容MySQL多个版本的离线迁徙工具，反对将数据迁徙至CUDB for OB， 实现10万条/s迁徙速度，已帮忙利用迁徙数据50TB+。 （四）信创适配全面适配海光、鲲鹏、飞腾等CPU，以及麒麟、统信等操作系统，反对全栈信创，保障信息安全，躲避软硬件技术“卡脖子”危险。 二、产品推广状况2022年3月份上线以来，数据库团队已将CUDB for OB产品推广至总部及各省分共100+利用，200+天无生产故障（主机宕机0影响）。 三、将来瞻望（一）对立技术栈，外围零碎稳中求进勇立技术前沿，丰盛开源生态，收敛数据库组件， 将来将施行代替600+套MySQL等高风险组件 ，实现新建零碎“能用尽用”，外围零碎稳中求进，逐步推广利用。 （二）能力晋升，试点多核心多活两地三核心五正本容灾能力解决方案落地实际，异地灾备/双活平台架构建设， 实现地区级、机房级无损容灾（RTO = 0） ，撑持 7x24 小时继续服务，满足利用业务能力双活须要。 （三）中心化建设，数据库运维智能化数据库产品能力建设体系化、中心化，围绕着产品部署、应用、监控、保护等场景，打造产品交付核心、操作核心、数据恢复核心、数据卸载核心、感知核心和运维核心，基于大数据和AI能力，实现数据库的自感知、 自修复、自优化、自运维、自平安。 （四）奉献开源，自研性能共享共建秉承拥抱开源、应用开源、奉献开源的准则，将联通自研OceanBase数据离线迁徙工具、基于CLog的精准记录复原工具等对外开源，独特做好产品生态工具的建设和保护。 ...

欢送拜访 OceanBase 官网获取更多信息：https://www.oceanbase.com/ 本文来自OceanBase社区分享，仅限交换探讨。作者介绍：刘强，就任于作业帮基础架构 DBA 团队，负责分布式数据库的摸索和应用，协同研发团队在公司外部推动分布式数据库在业务上的落地。 在作业帮刚上线OceanBase 4.0 时，我分享过作业帮的业务架构痛点。目前，作业帮是多云架构（阿里云、百度云、腾讯云），并同时应用 MySQL、Redis-Cluster、MongoDB、Elastisearch、TiDB 、OceanBase这几款数据库。出于高可用和降本需要，咱们决定将更多 MySQL业务场景用 OceanBase 代替，本文将和大家分享具体起因，以及OceanBase 4.0 与 MySQL5.7 的比照数据。 高可用双活架构计划降级需要因为作业帮业务的多样性和复杂性，咱们对于分布式数据库的应用需要次要基于以下几个方面。 第一，在海量数据的状况下心愿缩小分库分表的复杂度，并解决单机存储瓶颈。 第二，对 I/O 密集型的 SQL 及 CPU 密集型的 SQL 来说，咱们心愿可能进步响应速度，缩小它在 MySQL 中对线上业务的影响。 第三，每个业务外部都须要业务人员频繁查问、录取线上数据，并有相应的报表服务以供下级 Leader 查看，而且大数据部门也会有报表需要接入线上数据，这对于线上 MySQL 来说难以撑持，在数据归档及汇总的状况下，也不足良好计划。 第四，因为MySQL的个性限度，咱们须要基于一个内部的高可用组件来实现 MySQL 的高可用架构，在多云环境下，网络环境绝对简单，这对高可用的稳定性提出了更高要求。如果局部业务的申请链路长或简单，跨云拜访会使业务相应耗时减少，影响用户体验。 因而，咱们须要摸索良好的双活架构计划，初步计划是基于 MySQL ，并引入 DTS 来实现双活架构。这种架构的复杂性及引入过程中 DTS 的异样或中断，对于数据的一致性有很大的挑战。同时在应用私有云的状况下，也心愿可能最大水平升高硬件的应用老本。 出于高可用和降本需要，咱们决定将更多 MySQL 的业务场景替换为 OceanBase，并对OceanBase 和 MySQL5.7 进行了多方面的比照。 OceanBase 4.0 比照 MySQL5.71、性能比照咱们应用32C64GB的硬件规格别离对 OceanBase 和 MySQL 进行性能、CPU使用率、磁盘空间占用的测试。 首先，从图1可见，OceanBase性能显著超过 MySQL。 图1 OceanBase 和 MySQL 的性能比照 ...

4月8日下午，为期两天的第十二届数据技术嘉年华（DTC 2023）在北京新云南皇冠假日酒店圆满落下帷幕。大会失去了工业和信息化部电子五所的反对和领导，围绕“开源·交融·数字化——引领数据技术倒退，开释数据因素价值”这一主题，通过一场主论坛和十二场专题论坛，汇聚“产学研”各界数据技术领军人物、学术精英、技术专家、行业用户，从多角度、多维度带来68场主题演讲。群贤毕至、俊采星驰，从技术倒退到计划构建、从用户需要到行业实际，饱含技术干货和远见卓识的嘉年华大会吸引了上千人到场参加，上万人观看线上直播。 — 致辞 —“建设历史视角洞悉过来，锻炼远见眼光着眼将来”——中国DBA联盟理事长、墨天轮社区发起者、云和恩墨创始人兼总经理盖国强在主论坛的欢送致辞中，以数据库畛域的两位图灵奖获得者 Jim Gray 和 Michael Stonebraker 在SIGMOD 2002上对产业界、学术界的批评发言引出这样一个摸索倒退方向的思维宗旨。墨天轮社区打造了DTC这一会议品牌，为学术界的首领、工业界的前辈、产业界的掌门人构建了一个交换的平台，他们摸索着不同的技术方向，沿着不同的技术路线砥砺前行。“咱们的指标如此统一，那就是为了中国数据库的产业崛起而贡献力量。”盖国强谈到。 致辞中，盖国强还对“开源·交融·数智化——引领数据技术倒退，开释数据因素价值”这一主题的选定进行了解读：第一，开源正在成为中国数据库产业倒退的新潮流，凝聚宽广研发人员的智慧可能减速推动数据技术的倒退；第二，简化作为用户的根本诉求，正在推动数据库从性能拆散到一体化的交融倒退；第三，数智化作为数据库技术倒退的高级需要，AI和数据交融摸索数据，为数据库的倒退拓展了新的方向。这三个关键词囊括了数据技术在过来一年里出现的变动和倒退方向。盖国强在最初示意，“引领数据技术倒退，开释数据因素价值，咱们置信每一分致力都是推动中国数据库技术提高的重要力量。” ☞大会PPT下载合辑：https://www.modb.pro/topic/622616（可公开内容陆续上传中... ...）— 主论坛 —大会邀请到工业和信息化部电子五所信创负责人李冬在主会场发表演讲。数据库作为咱们的IT行业里最重要的外围的产品之一，它近年来正产生着重大的变动、微小的改革。这场改革次要体现在三个方面：寰球的数据库产业改革市场格局重组、基于开源数据库市占率超过闭源数据库市占率、行业数据抉择更加多样化。现如今国产数据库品类丰盛，根社区和根生态已初步造成。他在演讲中指出，将来能够数据库的倒退能够从摸索更加多元化倒退门路、激励企业翻新在细分赛道上做差异化的竞争、丰盛国产数据库利用场景、构建凋敝的开源的生态四个角度发力。在演讲的最初李冬示意：“我置信中国数据库产业在大家的群策群力下，肯定会迎来咱们的倒退高光时刻。” 随后，CCF数据库专委会副主任，openGauss社区技术委员会主席，清华大学计算机系副主任、长聘传授李国良发表了题为 《openGauss：聚焦数据库内核翻新，共建开源数据库根社区》 的演讲。他示意 openGauss 始终践行三个使命：核心技术的翻新和摸索，始终走在核心技术的冲破上；建设国产数据库的根生态和根社区，和合作伙伴一起构筑中国数据库；有引领性和创造性的思路，不是简略追随其余数据库倒退一些原有的技术。因而随着数据技术的倒退和利用需要的变动，openGauss始终在高性能、高可用、高智能、高平安这四个方面做继续的翻新和摸索，李国良对“四高”背地的核心技术进行了具体解读。在演讲的最初他呐喊：“心愿‘产学研用’各界可能群策群力，一起共建、共享、共治构建国产数据库根社区。” 阿里巴巴团体副总裁，阿里云数据库产品事业部负责人，ACM、CCF、IEEE会士(Fellow)李飞飞在大会主论坛发表了题为 《阿里云瑶池数据库：数据业务继续在线，数据价值一直放大》 的演讲。阿里云数据库率先提出了主导将来数据库倒退的外围“四化”趋势：云原生化、平台化、一体化和智能化。他说“围绕这四化趋势，将来的数据库可能就像明天拼乐高一样，每一个组件会从架构角度进行解耦、存储、内存、计算，在计算层面咱们会有多种类型的不同的计算节点，有TP、AP、AI，能够像拼乐高一样依照利用的需要将它疾速的组合起来，组成进去一个最满足客户需要、利用场景的数据库，这就是我认为云原生数据库的终极目标。”两周前，阿里巴巴瑶池数据库品牌正式公布，他说“咱们从户视角登程，定义了阿里巴巴瑶池数据库的外围价值：一是数据业务继续在线；二是数据价值一直放大。”围绕着两点外围价值，李飞飞深刻分析了全线产品的技术细节。 华为云数据库服务产品部副总经理庄乾锋以 《自主翻新，北坡攀登，GaussDB给世界一个更优抉择》 为主题在主论坛发表演讲。他在演讲中指出，分布式和云将主导数据库市场的将来，因而，华为在GaussDB分布式数据库和华为云云原生数据库这两大产品线继续布局，增强自主翻新，构建弱小的技术能力，并逐渐实现商业落地，欠缺生态建设。在演讲的最初他说道：“分布式是自主翻新数据库的将来，云原生是数字化的将来。华为的GaussDB将继续注入更多当先的技术和翻新，做企业外围利用的智能数据底座，和大家一起来共创国产数据库的新将来，给世界一个更优的抉择。” 腾讯云数据库总经理王义成带来 《腾讯云TDSQL助力金融政企外围零碎国产化》 主题演讲。他首先介绍到腾讯云TDSQL经验了服务于腾讯云外部业务的第一个阶段；第二阶段是TDSQL  Inside使数据库集成到蕴含能源、金融、政务的产业互联网；深刻攻坚金融行业外围的第三阶段；现如今TDSQL 行将进入第四阶段，在行业内进行规模化复制。王义成示意，要做好第四阶段，首先要做好产品层面平滑的替换，为提供一站式国产数据库解决方案，接下来腾讯云数据库将围绕实现外围零碎替换、晋升超交融HTAP能力、提供SaaS一体化一站式解决方案这三点作为产品技术的攻坚点。 OceanBase创始人兼首席科学家阳振坤围绕 《关系数据库发展趋势的思考》 进行主题分享，论述了他在构建OceanBase数据库技术能力方面的一些思考。数据库能力的构建都是出于满足市场和用户的需要，如数据系统伸缩的敏捷性、交易解决或实时剖析能力、海量数据下的老本问题，依据这些需要来逐渐思考，OceanBase构建了单机分布式的一体化、交易、剖析的一体化解决等能力，以及现在在做的云服务，私有云、公有云、混合云等。他示意：“将来云的倒退肯定是私有云+公有云的混合云服务。兴许有很多业务还用纯正的私有云，极少业务用纯正的公有云，但更多企业可能会应用私有云和公有云的混合。” 云和恩墨·本原数据技术合伙人张程伟和金毅围绕 《回归数据本原，企业级数据库的技术探索》 这一主题开展联结分享。张程伟示意，目前云和恩墨与本原数据打造了两款数据库：第一款是企业级数据库MogDB，在公布的两年多工夫里，围绕“安稳易用”四个字，继续构建高性能、高可用、高平安、高智能的“四高”能力，面向高并发、低时延的交易型利用场景有着极大劣势。第二款是针对工业物联网中海量数据管理场景打造的超交融时序数据库Uqbar。这两款产品都是以openGauss开源内核来打造的，对于抉择openGauss的理由他说道，“咱们认为openGauss社区是一个可能长期继续演进的国产数据库的根社区，可能促使社区合作伙伴踊跃的参加到社区的共建、共享、共治，集百家之长继续构建产品的卓越能力。”同时，张程伟也做了产品公布的预报，在往年的6月30日，MogDB将公布第三个LTS版本——MogDB 5.0，而Uqbar也将公布第一个LTS商业版本。 随后，金毅博士围绕数据库技术创新的驱动因素开展剖析，并进一步提炼和定义了下一代10xHTAP原生数据库的架构：硬件变革（众核、多级CPU cache、大容量内存、NVMe SSD）驱动软件算法与架构变革，以一个数量级晋升资源利用率；云化资源催生云原生架构满足弹性负载；实时剖析推动编译执行、向量化、SIMD减速交融。 清华大学穿插信息研究院(姚班)助理传授张焕晨最初从学术界的视角带来 《迈向老本智能的云数据仓库将来》 主题演讲。他指出，辨别传统数据库架构和云原生数据库架构最要害的点是老本，以后云原生数据库的基础架构曾经成型，那么下一代的增强版云原生数据库就应该实现智能的老本管制。他用空调来作比喻，当空调创造进去后，下一步应该竞争的就是在同样制冷的条件下谁更省电，谁实现了这一点，谁的市场占有率就会更好。张焕晨总结道：“云原生数据库须要可能时刻在性能和老本之间进行核算，满足客户要求，数据库应该通过它的智能能力帮忙用户承当老本管制的累赘，这也是数据库易用性能够进步的中央。” — 专题论坛 —01「引领倒退：中国数据库翻新」专题论坛 数据库倒退历经半个世纪，现如今，百花齐放的中国数据库已逐步造成成熟的体系结构和产品能力。近年来中国数据库在需要驱动和政策带动下更加重视自主翻新。在 「引领倒退：中国数据库翻新」 专题论坛，五位技术专家作为百家争鸣的中国数据库厂商代表，在不同细分方向上展示了各自的技术冲破和翻新引领。 人大金仓高级副总裁冷建全带来了题为 《与利用一起，打造更稳、更快、更丰盛、更智能的数据库产品》 的主题演讲，对人大金仓的全链路产品体系和弱小能力做了具体解读，并示意将来将向多模数据对立解决、多语法体系对立兼容、多场景对立解决（HTAP）等方向演进。 PingCAP副总裁刘松带来了题为 《以自主开源和凋谢架构构建新一代HTAP数据库》 的主题演讲。在演讲中，他以云计算和开源数据库从业界者的视角分享了对寰球数据库的产业趋势洞察，解读数据赛道和行业机会和沟壑，并解说了TiDB过来两年在HTAP、云原生、Serverless化的技术演进和寰球市场的拓展模式，为大家提供了国产数据翻新门路的一些思考。 ...

随着 5G 基站等通信工程的放慢建设，城市治理、城市平安治理成为热门话题，物联设施在咱们的社会中表演的角色也变得越来越重要，智慧燃气、智能电表、智能井盖、智能交通等我的项目在泛滥城市开始布局，随着一众智慧城市我的项目的深刻落地，海量时序数据的高效解决和老本管控也成为一个待解的难题。 为帮忙大家寻找解决上述问题的最优解，咱们汇总了四家比拟具备代表性的智慧城市降级我的项目的架构革新案例，一起来看看他们都是如何做的。 SENSORO x TDengine“咱们进行的数据库调研测试结果显示，TDengine 的空间占用只有 Druid 的 60%（没有计算 Druid 应用的 Deep Storage）。针对繁多设施的查问与聚和的响应工夫比 Druid 有倍数的晋升，尤其时间跨度较久时差距更显著（在十倍以上），同时 Druid 的响应工夫方差也较大。在理论业务环境中，咱们创立了多列的超级表，尽管会存在大量的空列，但得益于 TDengine 的优化，能达到恐怖的 0.01 的压缩率，简略计算下来大概须要 3.67GB 每亿条。”业务背景SENSORO 面向城市基础设施与外围因素提供全域数字化服务计划，建设城市级传感器网络所波及的传感器品种非常多样，由此产生的数据量也非常宏大。在零碎开发初期，SENSORO 先是抉择了 Apache Druid 作为存储传感数据的数据库，然而在应用过程中却遇到了各种各样的问题，这使得其将眼光转移到了 TDengine 上，但因为平台波及的非凡数据模型，单干便始终搁置了下来。随后 TDengine 通过了多个版本迭代，反对了 join 查问，而 SENSORO 的数据模型也产生了变动，迁徙到 TDengine 时不再须要做出很多的零碎模块改变，由此单方的单干也开始疾速开展。 架构图点击案例查看更多技术细节 北京智能建筑 x TDengine“TDengine 帮忙咱们在边缘侧解决了一个很大的问题，即边缘存储的问题。因为很多时候边缘是布署在资源比拟少的机器下面，甚至是 ARM 的工业盒子下面，在资源应用上十分的刻薄，而当初得益于 TDengine 超强的压缩算法，咱们应用十分小的存储空间就存储了几千万数据，压缩率远超 1/20，在单机下面布署一个 TDengine 服务器就能够轻轻松松地存储上亿的数据。此外它还领有超强的计算能力，占用的资源也十分小，在咱们的业务中千万级数据检索工夫达到了毫秒级，从用户角度来说产品体验十分好。”业务背景北京智能建筑是北京市在智能建筑和智慧城市畛域的翻新平台，同时也是冬奥科技平台公司、智慧冬奥国家重点项目设计单位和外围施行单位。在边缘侧采集数据存储计划中，其面临着在无限的计算资源下，如何实现最高效的数据存储、剖析和计算的问题。通过调研与测试，其最终抉择依据业务需要灵便搭配应用 TDengine 与 SQLite——由 TDengine 解决时序数据，SQLite 解决关系数据，以此更好地实现边缘侧的数据自治。 架构图点击案例查看更多技术细节 交通数据资源管理零碎 x TDengine“所有车辆最新地位信息的查问是交通运行监控中的重中之重，最后‘应用何种查问语句实现高效查问’是十分困扰咱们的一件事，前面在 TDengine 社区团队的帮忙下，咱们利用了暗藏字段名 tbname 和 group by 办法，高效地查问了车辆的最新定位信息。在频繁查问的状况下，靠近六万辆车的地位信息，只用了不到 1 秒的查问工夫，简略而又高效，完全符合咱们的业务需要；在数据统计分析上，一个 64 天数据量的表，进行每日数据条数的降维统计，所需工夫也不到 1 秒。”业务背景为了强化全市交通运输治理、兼顾综合交通倒退、晋升交通运行和管理效率，某市级治理单位建设了大交通数据资源管理零碎及相干利用 “一图一库”。其中“一库”局部次要内容包含：数据接入、数据存储、数据共享；“一图”局部次要内容包含：GIS 信息及其关联数据信息在二维、三维地图上的形象表白。在数据中台的建设中，存在大量的时序数据利用场景，其中最为要害的就是车辆运行产生的时序数据的存储与应用。为了实现高效的业务解决， 研发人员决定从 InfluxDB、ClickHouse 和 TDengine 三款时序数据库（Time Series Database）中进行选型调研，最终凭借弱小的产品力，TDengine 怀才不遇。 ...

最近，杭州的天气转暖，气温慢慢回升，各位小伙伴的城市天气怎么呢？在这生机盎然的春天，CloudQuery 整装待发，准备赴一场与大家的约。 盼望着，盼望着，距此次 CloudQuery 社区版 1.5.0 正式公布仅剩五天。发版前，让咱们通过这篇文章重温 CloudQuery 社区版的初心，参加最新社区活动。 不忘初心，继往开来 CloudQuery 中文名为 询盾，“询”是对数据的查问、操作、使用，“盾”是对数据安全的防护。咱们想做的是一款一站式安全可靠的数据操作平台。 咱们打算中的 CloudQuery 社区，是一个围绕“CloudQuery ”和“数据操作与治理”的技术社区，在这里大家能够意识开发、数据和运维畛域的大佬，能够学习别人的教训和短处，能够分享产品应用过程中的爽点和槽点，能够相互交换、防止本人造轮子和反复踩坑。 在这里，产品和人能够共同进步。 过来几年与社区搭档们并肩作战的场景还历历在目。技术人员在后盾研发设计，大家在社区给予咱们最实在的应用反馈，共创了凋谢共享的社区环境。依据官网后盾数据统计，到目前为止，CQ 社区版安装包下载量近万次；CQ 社群成员也快达到300人，其中90%是普通用户；BinTools社区公众号累计公布 45 篇内容，共 387 人关注，关注人数还在一直攀升。CSDN 总站访问量共计 47，182次，其中，社区访问量达到17，080次。 过来的问题是大家独特参加的后果，这次重启也离不开每位社区用户和关注者的反对。咱们心愿大家在社区意识一些气味相投的敌人，共同进步。同时期待与大家一起玩点乏味的、有意义的、不一样的事件。 社区重启直播预报 为了更间接地与大家互动，解说新版本性能，咱们将于 4月19日 早晨七点 进行社区重启的主题直播。本次直播平台包含墨天轮、微信视频号和B站，直播过程中将会通过「墨天轮」平台抽奖赠送 CloudQuery 精美周边和相干礼品，包含华为手环和小米充电宝若干。下方是直播预约链接，大家能够依据本人的习惯和爱好抉择平台，与咱们云见面！ 墨天轮 视频号关注视频号BinTools图尔兹进行直播预约 bilibili： 网盘投票后果 几天前公布的 下载 CloudQuery 安装包的网盘抉择 投票曾经有了后果，百度网盘和阿里云盘（其余自填项）并列第一，天翼网盘和坚果云并列第二。 因为阿里云盘无奈分享安装包，CQ 将抉择百度网盘、天翼网盘、迅雷云盘作为次要下载安装渠道。 雄关漫道真如铁，而今迈步从头越。回顾过往，咱们更领有前行的底气和勇气；展望未来，咱们对 CloudQuery 社区建设充满信心。 CloudQuery 最新1.5 版本将于 4月14日正式上线 ，诚邀各位小伙伴届时下载应用！如果你也想退出 CQ 小家庭，参加社区活动，欢送扫描下方二维码增加小助手进入官网社群，关注社区最新资讯！

我是一个独立开发者，想要做一个理财记账的利用。不便中国基金、股票和虚构资产的收益汇总，并提供 AI 倡议。能帮我设计好相干的表构造嘛，应用 Prisma 语法，不容许应用自增 id。当设计表构造时，应该思考如何组织和存储不同类型的资产信息，并且应该使其易于查问和更新。上面是一个简略的表结构设计，能够作为参考： datasource db { provider = "postgresql" url = "postgresql://user:password@localhost:5432/mydatabase"}model User { id String @id @default(cuid()) name String email String @unique password String accounts Account[]}model Account { id String @id @default(cuid()) name String accountType AccountType balance Float currency Currency transactions Transaction[] user User @relation(fields: [userId], references: [id]) userId String}model Transaction { id String @id @default(cuid()) amount Float date DateTime description String category Category subcategory Subcategory? assetType AssetType assetCode String assetName String assetSymbol String? assetIssuer String? assetUnit Float? exchange Exchange? account Account @relation(fields: [accountId], references: [id]) accountId String}enum AccountType { BANK CREDIT_CARD INVESTMENT}enum Currency { USD RMB EUR}enum Category { INCOME EXPENSE INVESTMENT}enum Subcategory { STOCK FUND CRYPTO BOND}enum AssetType { FUND // 基金 STOCK // 股票 CRYPTO // 虚构资产 OTHER // 其余资产}enum Exchange { SHSE // 上海证券交易所 SZSE // 深圳证券交易所 HKEX // 香港证券交易所 NASDAQ // 纳斯达克证券交易所 NYSE // 纽约证券交易所 OTHER // 其余交易所}这个表构造蕴含三个实体：User、Account 和 Transaction。User 表保留用户的根本信息；Account 表保留用户的账户信息，包含账户类型、余额等；Transaction 表保留用户的交易记录，包含交易金额、日期、形容、类别等。 ...

近日，深圳大普微电子科技有限公司（以下简称大普微）与阿里云PolarDB 开源数据库社区开展产品集成认证。测试结果表明，大普微旗下DapuStor PCle4.0 嵘神系列 企业级SSD与阿里云以下产品：阿里云PolarDB数据库管理软件、阿里云PolarDB-X云原生分布式数据库管理软件，齐全满足产品兼容认证要求，兼容性良好，零碎运行稳固。 对于PolarDBPolarDB是阿里云自主研发的新一代云原生数据库，既领有分布式设计的低成本劣势，又具备集中式的易用性。数年来，阿里云针对 PolarDB 进行了诸多翻新，通过采纳存储计算拆散、软硬一体化设计，PolarDB 实现老本仅为传统商业数据库的十分之一。所实现的计算、内存与存储资源的“三层解耦”架构、多主多写、基于IMCI（内存列存索引）的 HTAP、Serverless 等性能已是寰球独创或业内当先的技术。从 PolarDB 公布以来，它在技术和商业化上都取得了迅猛发展，现在曾经成为阿里云数据库产品家族中最闪耀的产品。2021年，阿里云正式开源PolarDB，将PolarDB PostgreSQL 版（简称 PolarDB-PG ）和 PolarDB分布式版（简称 PolarDB-X ）进行了全内核开源，与社区一起共建云原生分布式数据库生态。 DapuStor企业级PCIe 4.0嵘神系列嵘神5 R5100 、 R5300 、 R5101 及 R5301 是DapuStor推出的新一代NVMe PCIe4.0企业级SSD系列产品，基于DapuStor自研控制器DP600和固件，搭载KIOXIA 112层3D Enterprise TLC NAND， 且反对Flash Raid 2.0技术，可容忍更多flash die生效并不影响业务及性能。比照Gen3性能翻倍且向下兼容，笼罩2T、4T、8T、16T多种容量，反对固件在线降级业务不中断。嵘神5系列产品还领有增强型掉电爱护技术、端到端数据保护、Multi namespace 、VSS、NVMe MI、9级可调功耗等高级企业级个性，凭借高牢靠、高性能、低延时等劣势，产品实用于不同的业务场景对新一代闪存存储产品的严格要求。 通过严格测试，单方产品齐全兼容，整体运行稳固，在性能、性能及兼容性方面体现良好。 实现兼容性认证后，通过单方的交换单干和资源共享，大普微将充分发挥在企业级SSD存储方面从主控芯片、固件、算法等关键技术研发方面的翻新劣势，与阿里云PolarDB开源社区一起共建数据库生态，独特推动企业级数据中心存储技术的提高，不断创新产品和服务，为千行百业数字化转型提供更加高效和智能化的解决方案。

近日，焱融科技中标中国移动研究院网络设备及分布式软件洽购我的项目。本我的项目将通过业界当先的焱融高性能分布式文件存储系统 YRCloudFile 为中国移动智算及相干我的项目提供高性能存储计划，推动 AI 及大规模算力的技术成熟和利用倒退。 算力已成为以后数字经济的外围倒退能源，撑持社会数智化转型，中国移动充分发挥运营商网络当先劣势，大力发展算力网络的全新理念，建设新型信息基础设施。焱融高性能存储解决方案对实时、大规模、多样化数据进行高效的存储管理，向计算层提供高吞吐，低时延的存储服务。焱融高性能文件存储 YRCloudFile 基于可灵便扩大的分布式文件并行架构能以高吞吐量、低时延和大规模并发形式传输数据，是大规模 GPU 集群利用场景的现实存储。焱融高性能文件存储 YRCloudFile 率先反对 400Gbps InfiniBand 网络，也是国内首家反对 GPUDirect Storage® 分布式文件存储产品，助力计算效率晋升和单位算力能耗升高，构筑 AI 算力时代数据中心的低碳建设。 在此之前，焱融科技就与多家出名云厂商开展单干并实现产品互认证，让存储可能在多个场景深度交融，晋升业务端的产品适配性。目前，焱融存储已在 AGI（通用人工智能）、智能汽车、智能制作、智能医疗、教科研等行业畛域广泛应用，为行业用户打造高性能、低成本且兼具稳定性与扩展性等特点的卓越解决方案，优化资源配置，赋能智慧计算。

量化业务背景 量化金融指依靠金融大数据、金融科技和智能金融的技术停顿，通过数量化形式及计算机程序收回交易指令，以获取稳固收益为目标的金融投资形式，在海内的倒退已有几十年的历史，其投资业绩稳固，市场规模和份额不断扩大、失去了越来越多投资者认可。量化投资技术简直笼罩了投资的全过程，包含量化选股、量化择时、股指期货套利、商品期货套利、统计套利、算法交易，资产配置，危险管制等。 量化的钻研方向和劣势 “AI+”量化投资模式将成为人工智能利用于量化投资中的次要倒退方向。国内量化在 2018 年之前，还是以量价数据+人工开掘的形式为主。在 2018 年之后，市场逐步进入 AI 算法的时代，不论从因子开掘、组合治理，还是危险优化等方面，进一步晋升了整个量化投资的收益。到 2019 年之后，整个量化行业的规模快速增长，这是推动整个行业倒退十分重要的能源。到 2020 年，量化行业曾经到了大数据+AI 算法的阶段。整体来看，在量化行业冲破 8000 亿的市场规模，大数据+AI 算法在将来的发展趋势势不可挡，不论是从数据的规模还是对于神经网络的利用，随着 AI+大数据的倒退，亦是将来量化行业的次要增长起源。 量化数据特点 在理解量化数据特点之前，咱们先看下量化数据都有哪些类别，一是市场的量价数据：交易所量价数据、交易量、成交量、价格、日内订单等；二是基本面数据：上市公司公告几千万条记录、公司财报数据数千万份、各大券商剖析报告等；三是另类数据：个股新闻、商品数据、宏观数据、产业数据、个股指标、物流数据、供应链数据、电商数据等。这些数据具备以下特点： 根底量化数据量规模大数据类型多，CSV，TXT，EXCEL，HDF file，DataBase信噪比低，烦扰数据多衍生数据简单，提取艰难量化的业务流程第一步：数据筹备，划分训练集、测试集首先咱们应明确咱们构建何种 AI 量化策略，如 A股、港股还是期货等，确定数据后，接着咱们把历史数据按工夫程序切分为两局部。第一局部的数据用来训练模型，第二局部的数据用来验证模型成果。 第二步：选定指标：数据标注其次咱们要明确咱们模型的训练指标，是预测股票收益率高下还是稳定率高下。 AI 量化策略的指标(Label)：人为定义的模型预测指标，例如将来 N 日收益率、将来 N 日稳定率、将来 N 日的收益率排序等统计量,平台 AI 量化策略默认应用股票收益率作为指标。 AI 量化策略的标注：计算训练集数据所在工夫阶段的每日目标值，比方按每日的将来 N 日收益率高下来定义股票的走势好坏等级，计算出每只股票将来N日收益率的好坏等级并标记在每只股票上。 第三步：特色数据、找因子抉择构建可能影响指标的特色（量化策略中可称为因子），如模板策略中的 return_5 (5日收益)、return_10 (10日收益)等。 AI 量化策略的特色(features)：反映事物在某方面的体现或性质的事项，在 AI 量化策略中，特色能够是换手率、市盈率、KDJ 技术指标等。 第四步：数据连贯 + 缺失数据处理将上述每只股票的标注数据与特色数据链接，以便下一步模型的学习与应用。 第五步：模型训练 + 股票预测咱们通过“好坏等级”对股票进行标注，贴上标签，连同其所对应的特征值一起来构建训练模型，通过演绎总结找到属性之间的关联，总结分类教训； 用验证集数据来测验训练后面构建好的模型，即测验模型依据验证集的特色数据预测出的目标值（股票走势好坏等级）是否精确。 第六步：回测验证将验证集的预测后果放入历史实在数据中检测，应用历史数据验证后面模型训练和策略的验证的好坏和后果。量化总体阶段业务特点 量化交易依靠“AI + 机器学习”成为行业支流 机器学习作为人工智能的外围，其传统算法在解决很多问题上都体现出了高效性。随着近些年数据处理技术上的提高和计算能力的晋升，深度学习在很多问题上利用十分深，在量化投资畛域，机器学习尤其是由统计学延长的各种算法始终以来都被尝试利用在选股、择时等策略的开发上，随着深度学习在其余畛域上的冲破，其在自动化交易甚至投资策略的自开发自学习方面的利用成为了各大私募机构和金融寡头摸索的焦点。 通过机器学习和深度学习算法，帮忙疾速、精确地剖析海量数据，并发现其中的法则和趋势。目前，深度学习最胜利的场景利用是在模式识别上，即利用已知数据，对具备肯定空间、工夫散布信息的数据与类别标号之间的映射做一个较好的预计。深度学习能够体现得比传统机器学习算法更好，次要有以下 3 点起因： 深度学习的主动提取特色比传统机器学习的人为提取特色过程更加高效。特定的利用场景中，只须要微调构造，如神经元的激活函数，就能够失去较好的成果。深度学习能够通过简单的构造和多重非线性解决层更好地捕获各类非线性关系。深度学习随着数据量的减少模型成果会一直地改善，这也是以后深度学习有逐步取代传统机器学习模型趋势的最大起因。AI+机器学习算法在量化的利用场景基于上述量化场景剖析 得出如下存储要求 通过剖析量化业务流程特点以及基于以 AI 和机器学习为根底的量化训练业务，每个步骤都会以不同形式给存储系统带来挑战。模型训练环节中，面临海量训练数据集的解决以及疾速 I/O 响应的挑战；推理环节中，存储系统须要具备以最小提早实时处理数据。深度学习算法的性质意味着它们会应用大量矩阵数学，这非常适合在 GPU 上执行，大量的 GPU 并行运算工作负载的复杂性加上深度学习训练所需的数据量，这带来极具挑战性的性能环境，深度学习存储系统设计必须在各种数据类型和深度学习模型中提供平衡的性能能力满足量化中模型训练的场景，具体为以下几点： ...

欢送拜访 OceanBase 官网获取更多信息：https://www.oceanbase.com/ 1951 年 12 月 25 日，四川省农村信用社联合社（以下简称“四川农信”）诞生于泸州黄舣乡。 经几代四川农信人接续奋斗，七十余年餐风露宿，四川农信曾经成长为全省业务规模最大、服务网络最广、员工数量最多、历史底蕴最厚的银行业金融机构，为反对“三农”以及全省经济社会倒退施展着重要作用。 截至 2022 年 12 月底，四川农信曾经有 5022 个营业网点，近 4 万名从业人员，资产规模近 2 万亿元，各项贷款近 1.7 万亿元，各项贷款 9892 亿元，资产规模、贷款规模位居全省同业第一位。 据四川农信联社信息科技核心副总经理陈晓东介绍： “四川农信有 5000 多个网点，有 10 万台终端机电设备，和 7000 多万的客户数，还有 1.4 亿的账户数”。这意味着，按四川的总人口来说，8000 万人里有 7000 多万是四川农信的客户。”其中，四川农信最大的外围业务零碎和手机银行零碎，每一天的交易笔数加起来就是 3 亿笔，也就相当于四川的总人口，每天都在四川农信办理一笔业务。下面流动的资金是 1000 亿，这些数字能够看出四川农信整个业务规模和体量十分大。 作为四川省业务规模最大的银行业金融机构、全国农信零碎“排头兵”，四川农信率先于 2018 年 9 月实现智慧银行 IT 架构蓝图，确定由集中式向分布式全面转型的 IT 策略方向，并翻新构建分布式架构转型的要害根底平台——“蜀信云”。 原生分布式数据库 OceanBase 作为“蜀信云”的数据底座，撑持了四川农信普惠金融、智能营销、智能柜面、汽车银行等近 50 个要害业务零碎的平安稳固运行。 办一张卡：从半小时，到5分钟从传统线下柜面进化到线上的“分布式”柜面，四川省农信联社信息科技核心副总经理陈晓东讲述了在这前后的变动。 过来，传统柜面的交易量，如线下 ATM 机、POS 机渠道，占银行的绝大头，70% 以上都是传统供应链的业务。通过电子化、数字化转型后，咱们大量的业务都迁徙到了线上渠道，包含手机银行、四川农信的惠领取扫码业务等。当初，四川农信手机银行业务的交易量，是传统柜面业务的 5-6 倍。同时，通过测算，咱们线上业务的老本也远低于线下传统柜面。 分布式革新之后，咱们有更高效的闭环应答这种撑持，反对更多的线上业务。当初基于 OceanBase，咱们构建的利用能够稳固撑持一些在交易比拟忙碌的时点金融服务。 比方“双 11”、除夕、春节，农民工返程的时候，四川农信交易量可能会达到平时的 2-3 倍，构建了分布式的数据库之后，能够更加从容地应答高并发高性能下的压力。 ...

StarRocks 3.0 版本介绍StarRocks 3.0 版本是 StarRocks 倒退历程中的一个重要里程碑，通过两年多的倒退，StarRocks 公布了超过 80 个版本，回顾过去： 在 1.x 版本中，StarRocks 的倒退主线是性能优化，通过向量化执行引擎、CBO、全局低基数字典等个性，在行业中建立了性能标杆。 在 2.x 版本中，StarRocks 针对实时和数据湖剖析场景做了深刻的打磨，Primary Key 模型解决实时场景下宽表的更新和查问性能问题；StarRocks 反对了Apache Iceberg/ Apache Hudi/Delta Lake 等数据湖表面查问；此外，基于Pipeline引擎的资源组性能能够帮忙用户进行细粒度的资源管控，隔离不同类型负载的资源应用，帮忙用户实现 OLAP 层的极速对立。 在 3.x 版本中，StarRocks 将开启从 OLAP 到 Lakehouse 演进的新篇章。通过全新的存算拆散架构，帮忙用户升高存储老本，晋升计算弹性，通过物化视图来实现湖仓交融、流批一体的 ELT 流程，最终实现在凋谢的湖仓架构下比数仓更好的性能和时效性。 新增外围性能介绍1 存算拆散StarRocks 3.0 版本最重要的变动是架构上反对了存算拆散模式。在该模式下数据将会长久存储在近程对象存储或 HDFS 上，而将本地磁盘作为缓存应用。存算拆散架构下用户能够动静增加或删除计算节点，实现秒级的扩缩容能力，并反对表级别的缓存生命周期治理；在本地缓存命中的状况下，能够取得与存算一体架构雷同的性能。 2 全新 RBAC 权限框架新版本提供了残缺的 RBAC(Role-based Access Control) 权限治理反对，在兼容之前的 IBAC(Identity-based Access Control) 模型根底上，RBAC 模型能够通过角色来治理一组对象权限，而后把权限赋给对应的用户，这样极大升高受权的治理老本，也能够更灵便不便的批改/回收权限。 您能够通过 StarRocks的预制角色db_admin, cluster_admin, user_admin, public 给系统管理员配置根底的权限模版。也能够自定义角色，并通过角色的继承来满足不同组织构造的需要。同时，StarRocks 反对了默认激活角色(Default Role)，在用户领有多个角色时，举荐默认激活最小角色，如遇非凡场景，手动激活高级角色，从而实现最小权限准则，避免误用。 3.0 版本新增了 40+ 种权限项，笼罩了物化视图，资源组，UDF 等多种对象，也反对了对 External catalog 进行对立的权限治理，能够像治理外部表一样治理表面的各类权限。 ...

自从 NineData 企业级性能公布以来，深受开发者认可，而库级别的权限是近期被点名屡次的性能，在上个月的公布终于上线，当初曾经十分稳固，欢送应用。 哪些团队能够拜访哪些生产数据库？在企业数据安全性要求十分高的当下，又不能太影响开发人员的效率，这大略是让 DBA 或者系统管理员最为头疼的问题之一。NineData 提供的库级别权限、自助式申请、基于角色的权限治理、主动权限过期等性能，能够让开发人员，在高效开发同时，仍旧保障数据安全。申请数据库权限权限申请与审批（数据源、数据库）该入口新增了自助式的库级别权限申请，用于组织内协同合作开发，晋升数据资产的安全性。 我的权限展现以后账号领有的所有权限。能够配合我的权限应用权限申请与审批性能，先确认本身所领有的权限，而后依据需要申请新的权限 更加残缺的审计日志性能本次公布还向用户提供了更加残缺的审计日志性能。审计日志性能反对跟踪控制台中产生过的操作历史记录，次要记录了谁在何时对哪个对象进行了什么操作，以便管理员能够对用户做出的更改和安全事件的产生进行剖析。该性能用于平安审计（剖析违规操作）、法规合规（保留操作和事件记录用于合规性校验）、故障排查（理解哪些操作导致了故障）等用处。 NineData 将通过继续的技术创新，以客户需要以及市场为导向，为开发者提供智能、高效、平安的数据管理体验，让每个人用好数据和云。如果各位有趣味，能够间接登录 NineData 官网(https://www.ninedata.cloud/)，申请收费测试数据源，开始你的探秘之旅。

欢送拜访 OceanBase 官网获取更多信息：https://www.oceanbase.com/ 3 月 25 日，第一届 OceanBase 开发者大会在北京举办，OceanBase 开源生态资深研发总监封仲淹为大家带来了《 OceanBase 开源技术生态全景解析》的分享。 以下为演讲实录： OceanBase 自 2021 年开源后，继续吸引开发者参加共建，拉近和开发者的间隔，同时，也在一直对接新的生态搭档。明天我想和大家聊聊 OceanBase 开源生态的全景图，以及咱们刚刚公布的 OceanBase 4.1 版本的新性能和产品将来布局。 开源凋谢，与生态搭档共赢任何一个零碎都不是孤立存在的，而是与上下游协同倒退；任何一个数据库都不能独立服务用户，而是须要为用户提供一整套解决方案，比方利用集成、数据治理、数据迁徙及运维管控等，帮忙用户更流畅地实现数据生命周期中的每一个阶段。 第一，利用集成就是让数据更轻松地生产进去。 明天 OceanBase 在企业版和社区版曾经对接 300+ 套偏利用的零碎。涵盖业务零碎、根底软件、连接池、中间件、ORM、数据驱动、BI 报表、大数据平台，比方 Flink、Spark、MyCat 等。咱们期待更多搭档的退出。 第二，数据治理是帮忙用户更平安地治理数据，包含根底客户端、数据加工、智能诊断、线上运维、平安管控等。 在咱们对接的零碎中，有 OceanBase 开发者核心（OceanBase Developer Center，ODC），有开源的 DBeaver，还有许多商业系统。 第三，数据迁徙是让数据自在地流动起来。 目前对接的零碎中，可能让 MySQL、Oracle、DB2、Elasticsearch、PostgreSQL、Hive、TiDB的数据流入 OceanBase，也能从 OceanBase 将数据同步到其余数据库中。在这些迁徙的工具中，有 OceanBase 迁徙服务（OceanBase Migration Service，OMS），也有开源的 Flink CDC、Canal、ChunJun 等，还有商业的 Data Pipeline 以及数控工厂等。 而我最想分享的一点是，现在数据迁徙这个市场孕育了大量的商业机会，在 OceanBase 的整个生态中，无论是社区版、企业版还是云上，咱们都违心将商业机会分享给合作伙伴。 第四，运维管控，让用户更轻松地运维OceanBase。 咱们对接的零碎有 Kubernetes、Grafana、Data Foundatian 等，并期待 OceanBase 被更多的平台集成，2021 年，咱们开源了 ODC，使 OceanBase 被更多大客户如携程、快手等集成，在他们的平台上运维 OceanBase，2023 年咱们打算开源 OCP Express。 ...

Hi~社区的小伙伴们大家好呀！ CloudQuery 最新 1.5.0 社区版本行将于 4月14日 公布，正式上线前，咱们急不可待与大家分享与 v1.4 相比，v1.5.0 在性能和性能上有哪些更新和降级。 01全新架构更稳固 这几年， CloudQuery 交付了50多个企业级客户。在满足企业用户需要的过程中，产品的稳定性和可靠性一直晋升。此次将要公布的 v1.5.0 与企业版同源，通过了公司外部的全面测试，也禁受了市场客户的应用测验，有牢靠的性能保障。 从底层架构的层面来说，CloudQuery 社区版 v1.5.0 去掉了之前的 LDAP，引入 pipeline，进步了稳定性和可扩展性。 02新增性能更欠缺 除了版本性能更加稳固，与之前的社区版相比，这次公布的 v1.5.0 减少了许多新性能。上面将具体介绍新老版本之间的性能差别。 丰盛了审计性能 新增操作权限起源关联CloudQuery 社区版 v1.5.0 可能监控并记录 CloudQuery 账户的操作流动，包含使用者在 CloudQuery 零碎的操作行为、以及对数据源的拜访/执行行为；可能提供丰盛多维的审计统计查问界面，供审计管理员对账号进行行为剖析、平安剖析、数据源操作行为追踪。 同时，新版本还提供追溯用户执行数据源所须要的权限起源，是用户申请提权的（关联到申请工单号包含审批人），还是管理员受权记录（关联管理员的受权操作记录）。 反对更全面，笼罩更广的 SQL 解析 CloudQuery 平安管控的外围在于 SQL 解析，对 SQL 解析前方能确定对哪些资源（表、函数、字段等）进行哪些操作（拜访、变更等）。数据库管控的精确度有赖于解析的准确性。CloudQuery 社区版 v1.5.0 修复了很多 CloudQuery 之前版本的解析 bug，使得解析更欠缺，也能反对更多 SQL 写法，大大提高了数据库管控的精确度。 操作权限管控更欠缺 v1.5.0 新增/拆分了权限粒度（例如ALTER细化为 ALTER INDEX、ALTER FUNCTION 等）， 每个语句都反对独立受权，使得治理粒度更细。 减少流程模块 v1.5.0 相比之前的版本，减少了流程申请和审批模块，次要性能包含：  当普通用户须要某些权限时，反对向管理员发动流程申请，权限管控更加灵便； 反对查看申请详情，包含申请人、工夫、操作类型等 反对管理员设计流程，将审批自定义为一级/二级审批，也反对抉择审批人； 反对管理员治理流程，如将审批进行转审。数据导出权限v1.5.0 欠缺了数据导出权限，遵循查导拆散准则，即查问到的数据不肯定能导出，有利于增强对数据的管控，避免数据泄露。同时为了导出性能，新版本应用流式导出。高危资源自定义 v1.5.0 反对自定义高危操作，高危提权复核形式反对同步复核。执行工夫限度与之前的版本相比，CloudQuery 社区版 v1.5.0 反对自定义执行 SQL 语句的操作工夫，实现更细粒度的管控。 03更多体验等你尝试 这些都只是新版本的冰山一角，CloudQuery 社区版 v1.5.0 将于 4月14日 正式公布。点击文末浏览原文，预约 4月19日 墨天轮发版直播！如果您想第一工夫体验，欢送扫描下方二维码增加小助手进入官网社群，关注最新资讯！

1. 筹备工作须要的环境 Oralce、MySQL、PG等支流数据库HHDBCS7.6及以上版本测试步骤 建设两张表带有主外键关系应用模板窗口生成数据，主键表生成100条，外键表生成10000条校验数据生成状况2. 建设两张表带有主外键关系--主键表create table dept( d_id NUMBER(5) primary key, d_name VARCHAR2(20));--外键表create table emp( e_id NUMBER(10), e_name VARCHAR2(20), salary NUMBER(6), dept_id NUMBER(5), FOREIGN KEY (dept_id) REFERENCES dept(d_id));3. 应用模板窗口生成数据3.1. 首先关上模板窗口 3.2. 查看编辑器快捷键以及脚本的模板点击下方的“应用帮忙”便可查看以下提醒 3.3. 抉择模板并编写SQL脚本在模板编辑器窗口输出“foreach ”便可弹出以下脚本，可依据理论状况抉择并进行SQL调整优化模板如下编写脚本 --dept表#foreach( $i in [1..100] ) insert into dept(d_id,d_name) values($i,'部门$i');#end--emp表#foreach( $i in [1..100] ) #foreach( $j in [1..100] ) insert into emp(e_id,e_name,salary,dept_id) values($j,'姓名$j',10000,$i'); #end#end别离将两个SQL脚本抉择“执行到文件”点击执行，输出文件名，保留即可弹出对话框，点击确定 3.4. 写入数据关上工作治理，工作类型抉择“增加SQL文件”点击增加弹出窗口，抉择上一步保留的SQL文件，依据集体状况可编辑工作名称点击确定，主动开始执行可点击日志查看运行进度 3.5. 校验数据生成状况应用select count() from dept union all select count() from emp; 查看dept表和emp表共有多少条测试数据查问后果别离为100、10000条数据，至此事务实现。 ...

欢送拜访 OceanBase 官网获取更多信息：https://www.oceanbase.com/ 4月7日至8日，由中国DBA联盟（ACDU）和墨天轮社区联结主办的第十二届『数据技术嘉年华』（DTC 2023）将在北京举办。本届大会以“开源 · 交融 · 数智化 —— 引领数据技术倒退，开释数据因素价值”为主题，为参会听众带来 60 场主题分享。OceanBase 首席科学家阳振坤、资深研发总监易鸿伟、架构师周跃跃受邀缺席并将发表演讲。 以下为 DTC 2023 中 OceanBase 三位受邀嘉宾的分享内容领先预览，欢送大家珍藏查看！ ✅ 主论坛 4月7日 11:05-11:35，OceanBase 首席科学家阳振坤将在主论坛发表题为《关系数据库发展趋势的思考》的演讲，率领大家回顾关系数据库的倒退历史，探讨关系数据库在新技术背景下的倒退方向。 ✅ “开源自研 - 分布式数据库”专题论坛 4月8日 14:00-14:40，OceanBase 资深研发总监易鸿伟将在“开源自研 - 分布式数据库”专题论坛发表题为《OceanBase Cloud 4.0技术外围能力解读》的演讲，深刻解读 OceanBase Cloud 的高性价比、高弹性、HTAP、跨境架构对立等外围能力，让更多的企业更加理解在云上 OceanBase Cloud 如何更优地提供端到端数据库服务化解决方案。 ✅ “交融翻新 - HTAP数据库技术”专题论坛 4月8日 16:00-16:40，OceanBase 架构师周跃跃将在 “交融翻新 - HTAP数据库技术”专题论坛发表题为《OceanBase 社区版 4.1 摸索与实际》的演讲，对 OceanBase 4.1 凋谢的外围个性进行技术解读，帮忙有需要的企业用户应用和用好 OceanBase 社区版。 除了多场精彩的演讲分享外，咱们还在 DTC 2023 现场设置了 OceanBase 展位，欢送各位开发者和行业用户来到现场交换。 欢送拜访 OceanBase 官网获取更多信息：https://www.oceanbase.com/ ...

欢送拜访 OceanBase 官网获取更多信息：https://www.oceanbase.com/ 3 月 25 日，第一届 OceanBase 开发者大会在北京举办，《明说三人行》访谈栏目创始人兼主持人卢东明、沃趣科技创始人兼 CEO 陈栋、DBAplus 社群联结创始人杨建荣、PostgreSQL 中文社区主席 张文升、OceanBase CTO 杨传辉在主论坛进行了 《数据库畛域，有哪些最值得开发者和用户关注的翻新与技术》 的圆桌探讨，独特探讨了单机分布式一体化、HTAP、多云原生等泛滥对于分布式数据库的热门话题。 以下为圆桌实录： 单机分布式一体化是将来趋势卢东明：请用一句话、三个标签来介绍一下本人和所做的事件？ 杨传辉： 工程师/开发者；单机散布一体化；性价比。 陈栋： DBA；守业；一体化。咱们从数据库、软件、硬件，即整个零碎一体化的形式给客户提供开箱即用的解决方案。 杨建荣： DBA；技术社区；技术分享。 张文升： PostgreSQL；开源社区；布道师。我最重要的标签就是 PostgreSQL，我认为哪里有 PostgreSQL，哪里就有我。 从左到右顺次为科技访谈栏目《明说三人行》创始人兼主持人卢东明，OceanBase CTO杨传辉，沃趣科技CEO陈栋，dbaplus社群联结创始人杨建荣，PostgreSQL中文社区主席张文升 卢东明：针对 OceanBase 最新提到的“单机分布式一体化”一词，在公众印象里“单机”与“分布式”是割裂离开，为什么 OceanBase 会将他们组合起来？ 杨传辉： 我很喜爱“单机分布式一体化”这个词。其实最早在 2021 年年底，它叫集中式分布式一体化。但前面咱们感觉不是特地直观，所以改成了“单机分布式一体化”。 的确，很多人脑海里感觉“单机就是单机，分布式就是分布式；支流就是单机，大规模就是分布式。 ”而单机分布式把两类零碎的产品个性以及技术劣势融入到一个零碎外面，对用户来讲很不便，用户不须要做抉择。正如主持人所说，咱们是成年人的数据库，这个比喻我很喜爱。 但这里有一个难点，有什么样的技术手段可能达到这样的成果。第一，当从单机到多机之后，性能不能损失，对用户来讲，它根本看起来没区别，然而仅仅性能不损失也没有用，如果性能一下子降下来的话，意味着一体化不成立。后面我在分享外面也讲了很多 NewSQL 的案例，一到分布式单机性能掉到原来的 1/5、1/10，这个没有方法既要也要。 OceanBase 可能做到性能也不损失，并且保障性能和扩展性外围的起因，在于咱们做到了分布式数据库外面的每台机器没有分布式相干的 overhead，动静的单日志流技术，是动静绑定的模式。一开始每台机器只有一个日志流，数据动静绑定到这台机器的单日志流，能够做到单机性能不损失，这是咱们讲的外围概念，同时我又能做到性能齐全无缝兼容，性能没有损失，这就是“成年人的数据库”。 张文升： 依据过往的教训，如果把分布式系统当作单机零碎去用，比方部署到一个机器上，它的性能会有大幅度的升高。这个问题如何解决？或者怎么冲破这个瓶颈？ 杨传辉： 晚期的支付宝，有很多 Oracle 的 DBA，他们示意：当 Oracle 关上强同步时，性能升高 35%，这个数据是以前支付宝的 Oracle 的 DBA 测试进去的。而为什么分布式应用到单机会呈现性能损失？因为分布式要做高可用、强同步的容灾开销。分布式做可扩大，因为扩展性带来的开销、强同步带来的开销，采取异步写 Redo Log 的模式，使得 OceanBase 强同步的计划性能损失管制在 8% 以内，其它中央做一些优化，同时具备强同步，并且不损失性能，这在以前的单机数据库根本做不到，因为底层的架构产生了变动。 ...

在“量化投资剖析”场景中，零碎须要从数据接口、网络上等各个中央获取证券的信息，其中往往以“实时的价格变动信息”为次要数据，而后再对这些数据进行实时的剖析与存储，供盘中和盘后应用。某企业遇到的问题如下：“咱们要对 500 个证券种类进行监控，在收盘时，每 5 秒会更新一次价格数据。这样算下来的话，每个证券种类一天就会产生 2880 条记录，如果是 500 个的话，就会有 144 万条数据。而这，还仅仅是一天中产生的数据。如果应用 MySQL 数据库，咱们该如何设计数据库和表，来承载这样的数据量呢？”援用从上述场景及问题登程，咱们邀请到 TDengine 解决方案架构师进行回复，并产出本篇文章。144 万条的数据量对于关系型数据库来说，的确是个有肯定规模的日增量。但从场景上看，上述问题场景还算不上「量化剖析投资」的外围，只能称之为数据抓取的场景。其中抓取对象为「证券」，规模 N = 500， 抓取工夫距离 T = 5s。咱们能够假如每次抓取的数据有： {scrawlTime: '2023-01-01 00:00:00'stock_code: 12345,price: 12.00,volumn: 134,bid_price_1: 12.01,bid_pridce_2: 12.02}如果要与常见的场景进行类比，能够应用 IT 服务器的运维监控比照。数据如下： {timestamp: '2023-01-01 00:00:00'ip: '172.16.8.1',cpu_usage: 0.81,memory_usage: 0.23}通过上述比照咱们能够看到，两种场景很类似。因而，从概念上讲，上述问题场景下的监控数据能够演绎为 metric —— 测量值，并且是随工夫变动的。这是很典型的时序数据，问题场景就是一种经典的时序数据存储场景。 基于 MySQL 的建模如果企业要用 MySQL 的话，其实外围要思考的问题应该是： 如何保障可能及时写入：500 rows/5s = 100 rows/s（但这个根本不是问题）。如何保障可能疾速查出？从 IT 运维看，常见的查问包含： 查问单个证券： 基于工夫范畴查问：ts in [startTs, endTs)基于监控值的过滤：WHERE bid_price_1 >= 10.00;最新值查问：ORDER BY ts DESC LIMIT 1查问多个证券：在单个证券雷同的状况下，只须要更快地返回，能在 1 个查问里返回更好。基于工夫的计算： ...

导读： 斗鱼是一家弹幕式直播分享网站，为用户提供视频直播和赛事直播服务。随着斗鱼直播、视频等业务的高速倒退，用户增长和营收两大主营业务线对精细化经营的需要越发地迫切，各个细分业务场景对用户的差异化剖析诉求也越发的强烈。为更好满足业务需要，斗鱼在 2022 年引入了 Apache Doris 构建了一套比拟绝对残缺的实时数仓架构，并在该根底上胜利构建了标签平台以及多维分析平台，在此期间积攒了一些建设及实践经验通过本文分享给大家。 作者｜斗鱼资深大数据工程师、OLAP 平台负责人 韩同阳 斗鱼是一家弹幕式直播分享网站，为用户提供视频直播和赛事直播服务。斗鱼以游戏直播为主，也涵盖了娱乐、综艺、体育、户外等多种直播内容。随着斗鱼直播、视频等业务的高速倒退，用户增长和营收两大主营业务线对精细化经营的需要越发地迫切，各个细分业务场景对用户的差异化剖析诉求也越发的强烈，例如增长业务线须要在各个流动（赛事、专题、拉新、招募等）中针对不同人群进行差异化投放，营收业务线须要依据差异化投放的成果及时调整投放策略。 依据业务场景的诉求和精细化经营的要求，咱们从金字塔自下而上来看，需要大抵能够分为以下几点： 剖析需要更加简单、精细化，不再满足简略的聚合剖析；数据时效性要求更高，不满足于 T+1 的剖析效率，冀望实现近实时、实时的剖析效率。业务场景多，细分业务场景既存在独立性、又存在交叉性，例如：针对某款游戏进行专题流动投放（主播、用户），进行人群圈选、AB 试验等，须要标签/用户画像平台反对。多维数据分析的诉求强烈，须要精细化经营的数据产品反对。为更好解决上述需要，咱们的初步指标是： 构建离线/实时数仓，斗鱼的离线数仓体系已成熟，心愿此基础上构建一套实时数仓体系；基于离线/实时数仓构建通用的标签中台（用户画像平台），为业务场景提供人群圈选、AB试验等服务；在标签平台的根底上构建实用于特定业务场景的多维分析和精细化经营的数据产品。在指标驱动下，斗鱼在原有架构的根底上进行降级革新、引入 Apache Doris 构建了实时数仓体系，并在该根底上胜利构建了标签平台以及多维分析平台，在此期间积攒了一些建设及实践经验通过本文分享给大家。 原有实时数仓架构斗鱼从 2018 年开始摸索实时数仓的建设，并尝试在某些垂直业务畛域利用，但受制于人力的配置及流计算组件倒退的成熟度，直到 2020 年第一版实时数据架构才构建实现，架构图如下图所示： 原有实时数仓架构是一个典型的 Lambda 架构，上方链路为离线数仓架构，下方链路为实时数据仓架构。鉴于过后离线数仓体系曾经十分成熟，应用 Lambda 架构足够撑持实时剖析需要，但随着业务的高速倒退和数据需要的一直晋升，原有架构凸显出几个问题： 在理论的流式作业开发中，不足对实时数据源的治理，在极其状况下靠近于烟囱式接入实时数据流，无奈关注数据是否有反复接入，也无奈分别数据是否能够复用。离线、实时数仓齐全割裂，实时数仓没有进行数仓分层，无奈像离线数仓按层复用，只能面向业务定制化开发。数据仓库数据服务于业务平台须要屡次直达，且波及到多个技术组件，ToB 利用亟需引入 OLAP 引擎缓解压力。计算引擎和存储引擎波及技术栈多，学习老本和运维难度也很大，无奈进行正当无效治理。新实时数仓架构技术选型带着以上的问题，咱们心愿引入一款成熟的、在业内有大规模落地教训的 OLAP 引擎来帮忙咱们解决原有架构的痛点。咱们心愿该 OLAP 引擎不仅要具备传统 OLAP 的劣势（即 Data Analytics），还能更好地反对数据服务（Data Serving）场景，比方标签数据须要明细级的查问、实时业务数据须要反对点更新、高并发以及大数据量的简单 Join 。除此之外，咱们心愿该 OLAP 引擎能够便捷、低成本的的集成到 Lambda 架构下的离线/实时数仓架构中。立足于此，咱们在技术选型时比照了市面上的几款 OLAP 引擎，如下图所示： 依据对选型的要求，咱们发现 Apache Doris 能够很好地满足以后业务场景及诉求，同时也兼顾了低成本的要求，因而决定引入 Doris 进行降级尝试。 架构设计咱们在 2022 年引入了 Apache Doris ，并基于 Apache Doris 构建了一套比拟绝对残缺的实时数仓架构，如下图所示。 ...

Smartbi是一款轻量级的剖析平台，从投入产出比看，尤其适宜中小企业；Smartbi简略易用，免培训的个性十分合乎让IT人员疾速开发报表，大幅晋升开发效率；另一方面，Smartbi能够反对多个数据源，无论是有ERP、MES、协同零碎的接入等，还是内部Excel数据的导入，Smartbi都能很好地反对。 ——广东申菱环境零碎股份有限公司CIO 吴斌 PART 01客户介绍 广东申菱环境零碎股份有限公司（以下简称“申菱环境”）位于珠江三角洲的中心地带顺德，注册资金24001万元人民币。公司成立于2000年，是一家集研发设计、生产制作、营销服务、集成施行、经营保护于一体的现代化企业，为寰球客户提供环境调控的整体垂直解决方案，是数据服务产业环境、工业工艺产研环境、业余特种应用环境、高端公建室内环境四大畛域的专家。 面对数字化转型趋势，申菱环境凭借前瞻性的思维，实地借鉴国内外各先进企业智能利用场景与优良案例，为进步生产效率、一直优化工业配备、工艺和资料、资源配置，发明差异化产品和实现服务增值，全力打造“智慧园区、智能产品、智能制作”的“三智标杆”产业基地。 PART 02-我的项目背景-随着企业信息化水平的晋升，数字化路线的深刻，申菱环境在企业数字化降级上遇到了一些问题：申菱环境在数字化过程中引入了很多零碎，比方CRM、ERP、HR等，此外，还有各种生产设施上的数字化工具一直的产生各种类型的数据。 这些零碎撑持着申菱环境研产销供财一体化业务的运作，但各个系统之间是绝对割裂的，数据孤岛，没方法集中展现和剖析。制作生产过程、品质、老本治理、人员考勤都通过手工注销的模式实现，所以很难与生产零碎、管理系统的最新数据进行同步，也就无奈生成实时性数据洞察。 而且，生产治理用传统的电子看板和保留大量数据的报表来进行数据分析，无奈实时、直观的出现以后的业务状态。没有一个对立的平台做经营治理，基层、中层、高层管理者通过碎片化的报表来查看数据，效率低下，无奈造成对立的经营剖析思路，也无奈麻利决策。 在这些背景下，申菱环境与思迈特软件携手，基于智能BI平台Smartbi，搭建生产指挥调度核心，通过对生产过程实时数据收集、治理、跟踪、统计分析，实现生产制作执行过程的精细化治理，满足申菱环境数字化降级需要。 集、治理、跟踪、统计分析，实现生产制作执行过程的精细化治理，满足申菱环境数字化降级需要。 PART 03-解决方案- 1、突破数据孤岛，对立整合数据 基于申菱环境多数据源、数据量宏大、数据类型丰盛的现状，Smartbi通过弱小一体化的数据接入、数据采集、数据整合、数据处理和数据建模能力，恰好能够满足申菱环境对大数据平台数据这块的高要求，无效对接申菱环境的各类数据源，突破数据孤岛，对立整合数据。 2、搭建对立看板，实时动静治理 通过Smartbi，申菱环境搭建了生产指挥调度核心看板。该系统集成了申菱环境生产全链条的过程信息，全面整合了人、机、料、 法、环等生产调度资源，实现从订单下达到机组发货的生产全过程实时动静治理， 以及整体经营指标监控与剖析，为制作零碎实时高效运作提供了强有力的工具。 目前，整个看板基于业务板块划分为首页、总装、部品一车间和部品二车间四大板块。  首页 该板块展现了整个制作核心的三维动静模型以及整体经营状况，包含环境、设施运行状况、能源监控、人均能效等数据，板块核心的三维动静模型通过色彩与布局，可实时出现每台设施、生产产品及场地环境等状态信息。 同时通过组件下钻，还能看到某个产品的合同名称、工序、机型、状态等具体信息。便于车间管理人员进行异样治理及实时调度，从而进步车间生产管理水平。 注 | 该图信息仅为示意图  总装板块 次要出现总装车间的整体经营状况，从人员、交付、效率、异样治理、品质、配套服务评估等维度进行综合评估。 左侧次要展现人员缺勤与平安、产出与工单达成状况以及异常情况的治理剖析（显示以后所有异样的解决状态，对超时未解决的异样单进行预警）；右侧次要展现的是当日总装车间上线、下线率，产品周期达成率，并细化至各班组的经营排名。另外，可通过异样数量、解决时效、异样类别、责任部门的变化趋势，寻找异样改善点，将异样损失降至最低。  部品车间 该页面大部分治理内容和总装板块相似，蕴含了考勤剖析、进度剖析、异样剖析等模块。 不同之处在于，该车间自动化率比拟高，所以引入了设施效益治理模块，它反映了数控冲床、激光切割机等钣金加工设施开关机率和稼动率剖析，便于车间管理人员实时理解设施应用状况，为生产打算调度治理提供根据。 注 | 该图信息仅为示意图 PART 04-我的项目亮点- Smartbi的引入使得申菱环境的数字化转型往前迈了一大步。凭着思迈特软件搭建的可视化生产经营治理平台我的项目，助力申菱环境的整个经营过程实现可视化、可预警、可监控、可改革与翻新，促使局部订单产品研发周期缩短了42%，生产效率晋升28%，为公司经济效益的进一步晋升打下了松软的根底，同时让申菱环境在2022年拿到了标杆工厂的荣誉称号，还取得了1500w的省级工业信息专项资金贴补。 1、被动变被动，申菱环境实现降本增效 通过Smartbi，申菱环境配置了生产指挥调度核心。该核心通过3D动静展现生产车间的情况，模仿车间现场作业，将设施、资源、环境等进行了无效集成与模仿，使管理人员不再须要去现场勘查问题和线下记录剖析问题，线上便可能实时的理解到工单生产、设施运行、品质解决、异样问题管控状况，并且借助于现场设施，能够进行近程指挥与调度，用被动治理代替被动式治理，进步与现场互动的能力和效率，极大升高了客户公司的整体经营老本。 2、间接变间接，申菱环境实现高效经营 给不同岗位的人员提供了与之匹配的工作视角，直观形象理解经营状况。比方：通过Smartbi基层管理者能够间接看到本小组的工作进展情况，中高层管理者也依据权限不同，查看更加具体的经营治理剖析报表。 尤其是当某一台设施或者某个业务环节呈现问题时，管理者能够十分形象、间接地看到问题的起源、解决的停顿过程等，让管理者更具备广阔的视角。 3线下变线上，申菱环境实现麻利决策 之前生产主任和部长等每日、周、月例会都须要在线下做文件去阐明状况，而通过Smartbi搭建的生产治理看板，造成了从基层、中层、高层视角所需的经营治理剖析报表。 目前车间主任每日例会间接关上零碎进行状况阐明，让管理者可能实时理解到经营的动静，便于及时调整经营策略。通过十余年的教训积攒，思迈特软件曾经与泛滥制作企业独特打磨和制订标准化解决方案。 将来，思迈特软件将深刻更多制作企业，把解决方案利用到理论的业务场景当中，利用大数据分析技术帮忙制作企业实现迷信的经营决策，为推动我国制造业数字化、智能化转型贡献力量。

近期，广州金域医学测验集团股份有限公司（以下简称“金域医学”）与思迈特软件达成签约单干，单方将携手打造对立数据经营平台，对立各集成利用的入口，营造自主的数据利用气氛和文化，推广数据利用的价值，为金域医学“大平台、大网络、大服务、大样本和大数据”的资源优势添砖加瓦。 广州金域医学测验集团股份有限公司（以下简称“金域医学”）是一家以第三方医学测验及病理诊断业务为外围的高科技服务企业，致力于为全国各级医疗机构提供当先的医学诊断信息整合服务，创始了国内第三方医学测验行业的先河，通过多年的倒退，现已成为国内第三方医学测验行业的市场当先企业。 近年来，在疫情的大环境下，医学诊断的需要日益增多，第三方医学测验机构因其规模化、专业化服务在行业中占据了越来越重要的位置。 为满足业务的拓展和企业的倒退，金域医学携手Smartbi共建对立数据经营平台，实现数据驱动业务增长。 构建一套可继续“让数据用起来”体系基于金域医学数据管理现状，Smartbi将联合服务泛滥客户所积攒的一整套集成教训，提出了以下的建设思路： 1)建设对立数据门户平台:对立入口服务，提供全面、便捷、高效、平安、智能的数据服务，晋升数据服务效率和用户满意度和使用率。 2)建设共享互动平台:在数据安全前提下，团体外部灵便分享与推广数据利用，通过“去中心化”的组织模式，实现业务能力的复用和翻新。 3)建设自助剖析平台:使数据系统自主疾速响应业务需要变动，助力业务决策。 4)建设经营治理平台:剖析统计数据资产，进步数据服务效率、品质和利用范畴，进步利用成果。 此次单干，金域医学充沛认可了Smartbi搭建对立数据经营平台的技术实力，接下来，Smartbi将继续推动我的项目的深刻施行，从金域医学的理论需要登程，助力金域医学数字化转型踏上新台阶。

更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【1】进入官网交换群数据治理随同着数据全生命周期的过程，波及事先标准查看、事中监控治理、预先优化复盘等过程，要害重点畛域包含数据品质的可用性、一致性，数据安全及合规性、资产老本度量及治理，以及在整个治理过程中所需的流程、标准和技术等。 2023 年 4 月 8 日，DataFun 联结字节跳动数据平台举办 DataFunSummit2023：数据治理论坛，由火山引擎 DataLeap 产品专家负责出品人，邀请来自字节跳动、小米、翼领取的讲师，分享联合本身业务特点在数据治理方向的前沿摸索及实际，心愿通过本次的深度交换，大家对数据治理能有更全面的了解，在确保数据作为资产进行治理并转化为有意义的信息上能更前进一步。 直播工夫：4 月 8 日 09:00-12:00直播平台：DataFunTalk 视频号、字节跳动数据平台视频号 内容介绍1.出品人：李晓菲 火山引擎 DataLeap 产品专家 2.周方圆 火山引擎 DataLeap 资深研发工程师演讲题目：智能化、自动化，揭秘字节跳动数据品质前沿摸索演讲提纲：从利用场景视角来对待数据品质问题，通过自动化、智能化技术让数据品质能够被“观测”。把数据品质融入在研发、合作的流程中。听众收益：1.理解如何通过智能化的工具晋升数据品质2.交换数据可观测性的前沿停顿 3.韩谋让 火山引擎 数据治理专家演讲题目：火山引擎 DataLeap 计算治理自动化实际和思考演讲提纲：1.数据治理的重要性：调优的挑战及自动化需要2.遇到的问题与挑战：手动调优局限性、多参数相互影响的复杂性、实时监控和反馈的需要3.计算治理自动化解决方案：如何实现自动化参数搜寻技术、实时监控与自适应调整4.实际案例与成绩展现5.论断与瞻望 听众收益：1.理解手动调优的局限性以及多参数相互影响的复杂性，意识到实时监控和反馈在调优过程中的重要性。2.通过理论案例，理解自动化解决方案在 Spark 工作调优中的利用和施行过程，以及所获得的成绩和成果。3.思考计算治理自动化解决方案的劣势与局限性，并对将来发展趋势和挑战有所理解。 点击跳转 火山引擎大数据研发治理DataLeap 理解更多

随着企业数字化水平的逐步提高，数字化业务对数据管理的需要也继续深入。依据企业自身所处的数字化水平不同，咱们将企业的数据平台的建设总结为五个阶段，本篇咱们对对立的数据存储与算力做介绍。 — 整体介绍 —企业倒退的战略目标就是为了更好地为企业和社会发明价值，而从数据中发明价值也是发明价值的重要一个环节。数据平台的建设须要可能撑持起这个总体目标，同时联合企业本身状况实现一个可继续演进的技术架构。 互联网企业引领着数据时代，以Google、Facebook、Amazon为代表的企业曾经实现了从IT巨头到DT巨头的转变。这些公司借助其在大数据、云计算、人工智能的技术倒退劣势，疾速实现业务数据化、数据资产化和企业经营数据化，减速商业价值的转化，在引领技术风向的同时取得了微小的商业胜利。 具体到落地上，随着企业数字化水平的逐步提高，数字化业务对数据管理的需要也继续深入。此外，随着近年来数据因素市场的疾速倒退，局部有大量高价值数据资源的企业还能够将其数据产品化，并买通到其余企业的通道，从而通过数据流通发明价值。依据企业自身所处的数字化水平不同，咱们将企业的数据平台的建设总结为如下的五个阶段，如下图所示： 除了无形的零碎建设外，配套的数据组织和能力建设也是数据平台建设的十分要害的体系建设，包含分布式系统运维能力、数据整合、数据治理、数据迷信建模、数据产品开发与公布等能力，随着数据安全相干的法律法规的落地，企业甚至要求技术管理者有足够体系的法律常识并将其使用于数据产品的价值化发明过程中。 — 对立的数据存储与算力根底概述 —企业启动业务数字化的策略后，首先须要解决的问题是如何标准、高效地收集各类业务过程依赖及产生的数据，其次是如何在迷信的框架内，由浅至深地逐渐加以开发和利用。这个时候企业外部很容易达成统一，须要布局一个对立的数据根底平台，可能将企业内散落在各地的数据会集起来，并提供对这些数据做进一步摸索的能力。在物理上，企业须要借助平台来撑持海量且持续增长的数据存储，并且提供数据分析和计算能力，打下这些根底后，数据团队就能够将企业内的数据继续地会集进来，为后续的数据化工作提供生产资料和生产工具。 随着大数据技术的疾速倒退以及企业摸索教训的积攒，在构建对立的数据存算根底能力的过程中，行业里逐步造成了一套欠缺的方法论体系，次要分为平台体系建设和技术能力体系建设。 在平台体系建设方面，个别采纳基于Hadoop体系的大数据平台或分布式数据库，来构建一个企业级数据湖，可能撑持企业外部的结构化、半结构化、非结构化数据的存储与剖析，此外为了可能撑持更多的实时性数字业务，个别在数据湖的建设过程中就会同步建设计算能力层，来反对实时计算、离线数据批处理计算以及高并发的在线剖析与查问类业务。 在这个阶段，企业的技术团队须要建设的技术能力次要包含数据整合能力、数据开发能力、平台运维与平安治理能力。数据整合指的是将企业外部的数据通过自动化的伎俩会集到数据湖中，并且会做一些技术上的数据开发工作（如不同数据库的类型转换，必要的数据补全等），让数据湖中能够积攒出可用的数据。数据整合的形式能够包含离线（如T+1）、准实时（分钟级）与实时（秒级），相应的技术难度、可接入的数据库类型等也会不同，要求的撑持工具和技能也会有较大差别。平台运维和平安治理能力是为了保证数据湖的业务连续性和安全性，因为个别数据湖都采纳分布式架构的根底软件，与传统集中式数据库有较大的运维治理差别，因而企业相干团队须要建设起分布式系统的运维治理能力，包含高可用、集群扩缩容、监控告警、权限治理、全局审计等相干的运维畛域。   — 数据存储与算力性能要求 — 数据存算根底层是整个数据平台层的根底，因而企业在设计上要充分考虑对可能的业务状态的性能撑持能力，以及架构上的可继续演进能力。在性能的设计上，因为企业的业务会有各种类型数据生成，如经营治理类的文档数据、票据、合同数据，制作畛域的时序数据、影响数据，地位类的天文数据等，因而存储平台须要反对结构化数据和多种非构造数据的解决能力。在可解决的数据量级上，企业要充沛预估将来可能接入的数据量级，尤其是对一线业务单位可能生成的大量制作流程数据、监控治理数据等做好容量布局，因而根底平台对存储和计算的数据容量，须要有很强的扩展性，能够最高反对PB级数据存储。在数据整合层面，根底平台层须要反对对数据的高并发写入、搜寻、查问等，并且反对规范的SQL语言做开发，这样就能够很好地应用企业外部已有的数据工具。此外，根底平台须要反对对数据的高并发的事务操作，保证数据ACID，从而具备撑持重要业务的技术根底，2019年后多个开源我的项目开始反对分布式事务，也推动了新一次大数据技术的疾速倒退周期。在计算能力层面，须要可能对数据做批处理的碰撞剖析，以及实时的写入或计算。 除了根底平台能力层以外，配套的工具可能晋升数据团队的工作效率，减速他们的技术能力建设过程。因而，根底平台层须要提供比拟便捷的数据整合工具，可能将业务数据库对的底层数据库中的数据整合到数据平台中来，最好可能反对离线与实时的混合形式。随着国内信创产业的继续倒退，对国产数据库和平台的撑持也是必要条件之一。而对运维和平安治理团队来说，图形化的运维管理工具和平安管理工具也是必须的，前者能够让运维者不便做基于图形化页面来做平台内服务的配置管理、服务启停、存储扩缩容、计算弹性调整等运维操作，而后者能够让平安运维人员来设置正当的零碎拜访控制策略，配置数据库表的权限，以及对数据操作的审计操作等。 — 数据存储与算力架构要求 —根底平台层的架构对将来平台可能撑持的业务能力至关重要，过来十多年来大数据技术疾速倒退，涌现了多种不同的技术架构和一些明星产品和技术，如最早的Hadoop技术体系，到前面流批一体、存算拆散、湖仓一体架构，以及最近涌现的云原生架构、多模型数据库架构等。这些技术社区的倒退都是从某些方面推动了根底平台架构的倒退，不过因为技术复杂度问题和普遍存在的技术宣传超过技术自身的问题，入门者比拟难有充沛的、主观感性的全面意识。为了解决这个问题，咱们对相干的技术架构须要做了一个形象和总结，并在第二章对不同的技术社区针对性的合成和阐述。 业务撑持层业务撑持层次要负责对数据平台下层数据利用的撑持，个别基于SQL或衍生API来提供开发能力，通过利用编排等形式提供数据利用的资源管理能力，同时配套提供平安治理和运维相干的性能撑持，因而业务撑持层次要的架构要求包含如下几点： 高并发、高吞吐数据利用广泛具备一些高并发或高吞吐的个性，如面向消费者的数据产品广泛有高并发的设计要求，而实时计算类利用的数据流转与读写，在设计上个别都会保障吞吐量高，因而业务撑持层就须要保障对外服务的高并发和高吞吐。落实到技术上，个别数据平台都有SQL编译器、连贯管理器等相干的模块，为利用提供并发的JDBC/ODBC连贯和数据拜访能力，这也就要求SQL编译器等模块有较高的性能。高可用因为数据利用大多是计算密集或者IO密集的，对资源耗费较大，为了保障平台和利用的高可用，在架构上咱们须要保障整体软件栈的高可用性，即便在物理硬件呈现问题的状况下，服务可能失常运行。咱们能够通过分布式软件的高可用设计来保障平台软件层的高可用，再通过提供给应用层基于容器技术的利用编排技术来保障应用层的高可用。链路平安管控数据链路平安是企业软件的根底要求，包含惯例的认证、受权和审计，还可能包含为了利用的功能性平安而采取的细粒度的安全策略管控，如数据利用依照白名单或黑名单来管制接入、提供数据拜访限流等措施。这要求所有的数据拜访接口和利用都能提供比较完善的数据安全架构设计。存储与计算层存储与计算层是根底平台的外围局部，也是最要害的能力因素，晚期企业在选型根底平台的时候会偏重这方面的性能与架构。随着计算与存储层技术的疾速倒退，各种新型架构的分布式存储和计算技术不断涌现，都在尝试去解决不同场景下的利用技术需要，不过往上形象起来，次要包含这几点：分布式分布式技术是整个大数据技术的外围，也是新的计算规范范式。分布式存储、分布式计算等技术是撑持行业数字化的根底能力。可扩展性因为企业数据平台是为了将来数十年的企业数据业务倒退而设计的根底层，因而平台肯定是随着业务继续演进的，平台无论是在横向、纵向的可扩展性方面，还是架构自身的可扩展性上，都须要可能做到较高的线性能力。横向的可扩展性指的是能够通过减少服务器数量来晋升解决能力，无论是存储平台还是计算引擎，都须要反对从GB到PB级别的数据能力。纵向的可扩展性指的是能够通过单台服务器的资源晋升来带动性能晋升。架构的可扩展性指的是将来有更强的新型计算和存储能力，平台上能够继续的减少新类型的存储与计算引擎，从而满足不停呈现的新业务的须要。多数据模型反对企业外部的数据业务自身具备丰盛的多样性，撑持业务的数据类型也就具备多样性。譬如经营治理类的数据个别以结构化的数据为主，而财务类数据利用就波及大量的合同、票据等半结构化数据，生产制作类业务须要大量的时序数据类的能力撑持。因而企业级数据平台就须要对多模型数据有很好的撑持能力，包含存储、计算、查问和生命周期治理等能力。实时计算与批处理混合晚期的数据业务次要是数据仓库和数据湖的建设，次要波及数据的离线计算。近几年实时类数据业务蓬勃发展，如工业制作类的故障检测、银行业的在线风控、智能营销等外围业务场景，因而对平台的实时计算也有很高的要求。因而，数据平台根底层须要反对离线计算和实时计算模式，为新业务场景做好技术根底。资源管理层资源管理层是保证数据平台内的所有软件、服务和下层的数据利用如何部署装置、运行、如何调度和生命周期如何治理，以及对不同的业务部门如何保障所有软件的稳定性、隔离性和安全性。晚期的数据平台在资源管理上，都采纳硬件服务器间接部署的形式，依赖架构师的布局来落实资源管理，因而无奈保障实时变动的业务的无效资源管理。到2017年行业内开始呈现基于云技术来解决，目前比拟风行的形式有两种，一种是基于容器云和Kubernetes技术来提供分布式数据库或数据平台的资源管理，另外一种形式就是基于私有云的基础设施来交付，次要取决于企业的业务交付的模式和面向的业务客户状况。无论采纳哪种交付形式，数据平台根底层的资源管理架构要求能够简略形象为上面这几个要害因素：多租户能力多租户指的是一个平台内能够依照不同的业务部门或组织单位划分独立的资源单位，每个资源单位内部署和运行的软件应用不同的CPU、内存、磁盘等资源，互相隔离，因而不会相互争抢硬件资源，从而保障不同部门利用的稳定性。此外因为各个部门的数据敏感性要求不一，数据长久化在不同的磁盘空间上，数据也有物理隔离性，因而能够为不同业务敏感度的数据提供不同的平安服务等级。异构软硬件治理资源管理层的外围工作就是治理数据中心底层的软硬件资源，随着AI技术的倒退，大量新型减速设施如GPU成为数据中心的标配，此外摩尔定律继续推动半导体行业的倒退，一个数据中心会呈现多种资源配置的硬件资源，譬如局部服务器存储密度高，局部服务器的内存密度低等。因而，资源管理层须要可能对立无效的治理起这些异构的软硬件环境，可能依照业务的特点将利用下发到适合的服务器上运行，进步根底平台层的运行效率。多种生命周期的数据工作治理从资源管理层的视角来看，数据工作分为短生命周期和长生命周期两种。短生命周期工作包含相似机器学习模型训练程序、数据ETL程序等，他们都是一次启动实现计算后就完结，个别生命周期都是几个小时以内甚至是秒级。长生命周期指的是7x24小时运行的数据利用，如对外服务的AI推理利用、挪动APP的数据后盾服务等。晚期的数据资源框架如Apache YARN都是针对短生命周期的工作的治理而设计的，不能反对长生命周期的工作。国产软硬件生态反对国内企业须要可能基于国产信创相干技术来构建整体的生态，平台本身也须要满足国产化的相干要求，以后这是一个强架构要求，尤其是国计民生相干的行业，如金融、能源、交通、政府等。— 小结—本篇介绍了企业级数据平台建设的最根底层—数据存储与算力根底层，从性能要求和架构要求两方面分析了建设思路。那么实现了数据存储和算力根底平台建设和数据资源归集后，如何将有业务语义和业务价值的数据资源梳理出，并与业务衔接起来？下一篇数据资产化为你解读。

企业实现建设数据存储和算力根底平台后，再将数据资源归集，下一步就须要将数据资源转化为数据资产。那么什么样的数据资源是数据资产？企业数据管理者须要晋升数据品质、打消数据孤岛，并逐渐积攒数据价值？本篇将从数据平台建设和团队建设两个角度来介绍如何实现数据资产化。 — 数据资产化的挑战 —企业实现建设数据存储和算力根底平台后，再将数据资源归集，下一步就须要将数据资源转化为数据资产。有业务语义和业务价值的数据资源才是数据资产，因而企业数据管理者须要将数据与业务衔接起来，梳理出哪些数据能够服务哪些业务，同时建设好数据连接通道并做好数据安全治理。这个阶段的次要指标是提供给业务方能够间接应用的数据资产。 企业在数据资产化的阶段会遇到各种各样的挑战，尤其是在起步阶段，常常会遇以下几个问题： 如何能辨认出企业的全量数据资产如何能精确且疾速的晋升以后的数据品质如何能跨业务跨畛域的买通企业数据，打消“数据孤岛”以后数据的流转过程是否符合国家相干的法律法规的要求企业怎样才能逐渐的挖掘出数据资产的价值并量化它相干人才的造就，管理手段的降级，思维模式的翻新对于大多数企业，这一系列挑战在很长一段时间里，都深深困扰着数据管理人员，尤其是引领企业数字化转型的管理层。然而办法总是比艰难多，相干问题的解决并非欲速不达，须要一套残缺的技术平台和管理体系，并落实到具体的业务单位，有打算、分步骤、可量化的继续推动各项服务流动的发展与落地。在这个阶段，企业数据管理者须要实现两个方面的工作，一个是平台性能的建设，一个是团队能力的建设。 — 平台性能建设 —平台建设的重点次要包含能帮忙企业做数据资源的治理和业务化转换的数据开发与治理平台，以及随着数据安全类三法（《网络安全法》《数据安全法》《个人信息保护法》）强制推广后要落地的数据安全治理平台。 上图是一个整体的，从数据开发到资产价值的总体流程的概要示意图，不同企业的布局和落地，按照企业的理论状况会存在肯定的差别，不过总体过程大同小异，在资产化阶段，对于平台工具的性能要求，咱们将其总结为以下几点： 元数据管理与数据资源注销可能对立治理来自不同数据源的数据资源是数据资源化的第一步，次要包含数据源治理、元数据管理、数据资源盘点等性能。数据源治理要可能反对不同的数据库或平台，平台工具须要可能配置数据源、定义数据资源等。元数据管理要可能反对不同源数据的自动化采集，依照一些对立的规范做元数据定版治理，甚至笼罩数据血统的对立收集和治理。数据资源盘点须要包含一个资源门户和资源管理标准，能够将不同数据库的差异化数据格式采纳对立的数据格式进行盘点和规范化形容，再挂载到对立的资源目录上，便于数据管理和用户发现数据。数据模型与标准设计数据模型是数据平台内归集的多样化数据，是对立品质晋升和业务化晋升的要害。数据模型包含逻辑模型与物理模型，其中逻辑模型次要负责映射业务需要和数据表构造关系，物理模型负责将业务层的数据表构造转换为数据平台底层数据库的理论DDL等。数据规范是数据平台内元数据和数据品质的对立定义，是后续数据资产化过程的参考根据。平台工具须要可能提供逻辑模型注销和物理模型设计的性能，要可能设计数据规范、保护规范映射和执行落标查看，从而能够建设企业外部对立的数据标准和建设规范数据。自动化的数据品质晋升数据品质晋升是一个工程量十分庞杂的工作，平台工具须要可能进步这个工作的自动化水平从而晋升效率。平台工具须要提供的能力包含梳理品质模板、编写品质规定、查看品质报告、解决品质问题等。一些自动化和智能化的性能是十分要害的增值技术能力，通过一些基于数据类似度的举荐算法，让机器主动的给数据表关联品质规定和落实数据规范工作，能够将人力从反复的工作中解放出来，从而减速欠缺数据品质的过程。数据资产治理与服务能力通过企业内大量数据管理人员的工作积攒，外部将逐渐积攒起大量的可被各个业务应用的数据资产，此时企业就须要将这些潜在价值很大的数据资产治理起来，并提供多样化的服务形式能够让不同业务部门应用起来。企业个别要建设一个企业的数据资产目录或门户，反对数据管理者来挂载数据资产；而业务用户可能基于资产目录来做检索，更好的发现数据，理解数据分布以及数据信息溯源。除了功能性要求以外，数据治理类软件自身也是要害的根底软件，企业对其天然也有体系化的架构要求，次要包含如下几点： 稳定性与可靠性 ：相干软件会产生大量的无人驻守的计算工作，因而在架构上须要保障相干数据计算工作的稳定性和可靠性。用户自服务能力 ：数据治理软件和资产门户等相干软件是须要凋谢给所有数据管理人员、平安管理人员以及各个业务部门外部的数据人员来应用的，因而须要提供比拟强的自服务能力，这包含独立的工作空间、体系化的权限隔离机制，以及较低的开发启动老本。譬如企业数据管理部门对立制订数据规范，能够分发给各个业务组织或部门，由各个部门再联合本身的业务数据做进一步的欠缺，而无需从0开始，两头过程能够通过一些要害的数据管理流程来管制。非结构化数据的资产化：数据资产平台须要对非结构化数据提供治理能力，或者提供插件化的形式，让各个业务团队能够基于肯定的形式来做定制化的开发，最终可能无效的治理起业务积攒的这部分数据资产。数据安全：数据的凋谢在数据流通过程中，也带来了平安危险，依照法律法规的要求企业必须欠缺数据内容平安和流通平安，而不仅仅是软件层面的认证、权限和审计。数据安全治理平台须要可能提供基于数据内容的分类分级，生成细粒度的安全策略，反对动静脱敏、动态脱敏、数据水印等能力，能够让平安管理人员灵便的配置，从而落实相干合规性要求。国产软硬件生态反对：数据资产平台软件须要可能开发和治理国产数据库内的资产，此外平台本身也须要满足国产化的相干要求。 — 团队能力建设 —团队能力建设绝对比较复杂，在技术层面上团队须要把握数据资产盘点技术、数据品质治理能力、数据安全分类分级与细粒度平安治理等技术，还须要拓宽视线，从整体的角度考量如何从数据推动业务效率的晋升。这部分内容比拟形象，咱们将其形象为全局、求实、平安、资产四个关键点： 全局观：以通过数据来扩充企业业务视线和治理视线为指标，以盘点和拉通企业各畛域数据为度量，促成企业全面的辨认和展现出所领有的数据资源量，数据资产量。求实观：以晋升数据品质、满足数据需要为指标，从组织、技术、治理、人员等多方面多角度、多因素动手深挖数据品质问题根因，长效晋升数据品质。安全观：以在满足日益完善的法律法规要求为前提，保证数据资产平安，爱护隐衷信息不泄露。资产观：以做好资源配置，管制好老本和收益为指标，对数据收集、存储、整合、利用、共享、凋谢，再到价值的评估量化全链路建设体系化的资产治理保障。具体到细分的技术能力上，咱们将这部分能力分为四个域，包含开发能力、管控能力、服务能力和经营能力，咱们一一对其开展论述： 数据资产开发能力域企业针对数据资产的开发不仅包含数据的采集、存储、加工，也包含剖析、建模、数字产品；而数据资产开发的治理指标则是蕴含了对这些方面的接入、协同、管控的全流程治理。数据开发团队须要把握对多模数据源的对接，脚本开发、测试执行、作业调度、ETL配置等根底能力，可联合业务语义剖析提供罕用语法、罕用关联等智能举荐，联合标签画像、指标体系等能力，疾速买通数据开发畛域的各种问题。数据资产管控能力域咱们晓得将生产资料转化为产品时，最重要的就是品质保障，而数据管控就是对数据产品的各个治理畛域的性能组合，须要为数据订立架构与标准，建设数据品质的管理机制继续监管及解决品质问题，同时建立起数据共享与爱护的意识。企业数据管理团队须要构建数据规范模块以定义标准，通过落标查看来监督标准的执行；通过数据品质模块来定义质量检查规定并执行，统计和剖析品质后果，提出问题并处理解决；通过数据安全的分类分级对数据进行安全级别定义，构筑数据保护的根底；通过数据模型将规范落实到数据产品的设计工艺上；以元数据模块进行技术元数据的采集、数据加工血统门路的采集，实现差异性剖析、血统剖析、特征分析等；通过数据模型管理软件来对立治理企业外部的各种业务数据模型定义和落实模型校验，欠缺外部的数据管理要求。数据资产服务能力域产品生产进去了，并且成为了品质过硬的好产品，这时最须要的是将产品销售进来，投入到替换、应用的环节中，而数据资产服务能力域就是对数据的替换、共享、利用输入等服务能力的综合治理，须要将标签画像、指标体系、自助剖析、建模预测等业务模式，通过人-机的联机查问拜访、机-机的零碎调用接口、平台外部实验区数据验证等不同接口模式注册为服务，以对立治理的形式对服务进行注册、公布、监控、停用的治理，同时，可利用常识图谱等模式对应用状况、业务模型进行常识演绎和共享，并将安全等级定义落实到数据的共享治理中，确保权限的正确调配、实现确权和审计要求。平台须要提供数据商城模块实现数据集的注册、公布，并实现API拜访、下载等接口的凋谢。数据的共享流转流程成熟后，再对服务层进一步优化常识共享、平台衍化、数据重组等。数据资产经营能力域既然企业已将数据因素定位为重要资产之一，那数据资产经营将会像企业经营一样重要。数据资产经营以数据资产治理为主线将数据资产开发、管控、服务三大能力域串联起来，形象出最根本的引入、上架、经营、下架四个阶段对数据资产进行治理。平台须要提供基于元数据的数据集类资产引入、逻辑资产编目模组、对其余类型数据资产的治理和注册等能力。数据管理人员可通过资产导览的形式或全局搜寻的形式查找心愿援用的资产，买通资产到数据商城的关联，将来将通过数据需要，能够连通数据的开发、管控、服务的各治理接入点，通过智能化的资产打标、评估算法等性能以晋升管理效率。通过四个能力域的性能模组的不断完善，帮忙企业造就起从个别职员到决策者都能基于数字化能力实现企业日常经营的思维模式，只有数据的应用便当、数据的内容详实，数据的论断精确、数据的利用全面，能力将改革成为习惯，这才是企业数字化转型胜利的外围必要条件。 — 小结—本篇从数据平台建设和团队能力建设两方面，分析了数据资产化建设所需的根底功能性能力和数据团队应具备的技术能力、思维模式等软实力。实现了数据资产化治理，曾经实现了数字化转型的根底布局，那么如何实现数据共享与剖析？如何实现数据产品对内的业务经营和对外的价值发明？下一篇为你揭秘。

OpenMLDB 提供了一个线上线下一致性的实时特色计算平台。对于如何在理论业务零碎中整合 OpenMLDB，构建残缺的机器学习平台，OpenMLDB 提供了灵便的反对。本文关注基于 OpenMLDB，在企业级业务零碎中应用的常见架构。咱们次要关注存储和计算两个方面： 离在线数据存储架构：如何正当的进行离线和在线数据的存储，并维持离在线数据的一致性。实时决策利用架构：如何基于 OpenMLDB 的实时申请计算模式构建线上利用，蕴含常见的事中决策和实时查问利用架构。离在线数据的存储架构因为不同的性能和数据量的需要，在个别状况下，OpenMLDB 的离线和在线数据在物理上是离开存储： 在线数据存储：OpenMLDB 提供了一个高效的实时数据库（基于内存或者磁盘），次要目标为存储在线数据用于实时特色计算，而非全量数据。其次要特点为： 针对时序数据的毫秒级拜访，默认基于内存具备数据过期主动淘汰的能力（TTL），TTL 能够依据表格粒度进行设置，用于线数据库仅寄存必须的工夫窗口内的数据默认基于内存的存储引擎尽管性能较高，然而可能存在内存消耗量较大的问题，能够在满足性能要求的前提下应用基于磁盘的存储引擎离线数仓：OpenMLDB 自身并不提供独立的离线存储引擎，能够灵便反对不同的离线数仓和架构模式。以下探讨常见的离线和在线数据的存储架构。 全量数据存储于实时数据库（不举荐） 用户能够抉择把全量数据存储于 OpenMLDB 的实时数据库，此种应用形式带来的劣势是应用简略，并且物理上仅有一份数据，也节俭了治理保护老本。但此种形式在理论应用中较少应用，次要有以下潜在问题： 全量数据个别较大，而 OpenMLDB 为了保障线上性能，默认应用了基于内存的存储引擎，基于内存存储全量数据会带来较大的硬件老本累赘。OpenMLDB 尽管也提供了基于磁盘的存储引擎，然而磁盘存储会带来 3-7x 左右的性能降落，可能无奈满足某些在线业务场景需要。离线和在线数据存储于同一个物理介质，可能会对线上实时计算的性能和稳定性带来较大的负面影响。因而在理论中，为了充分发挥 OpenMLDB 的实时计算能力，咱们并不举荐存储全量数据在 OpenMLDB，而是和离线数仓配合应用。 离在线数据存储拆散治理架构 目前在理论应用场景中，大部分用户基于此种离在线存储拆散治理的架构。基于此种架构，数据会同时写入到离线数仓和实时数据库。OpenMLDB 的实时数据库会设置表格级别的数据过期（TTL）。此种设置会对应于所须要的特色脚本内的工夫窗口的大小，即实时数据库只存储用于实时特色计算的必要的数据，而非全量数据。相干留神点： 理论企业架构中，数据源个别基于 Kafka 等音讯队列的订阅机制。不同的利用会去别离生产数据。在此种架构下，写入到 OpenMLDB 的实时数据库的通路，以及存储到离线数仓的通路，能够认为是两个独立的消费者。如果并非基于音讯队列的订阅机制，也能够认为在 OpenMLDB 上游有一个或者多个数据接管程序，用于实现和治理 OpenMLDB 的在线存储以及离线存储。OpenMLDB 实时数据库的过期工夫须要正确的被设置，使得实时数据库内存储的数据能够被用于正确的实时特色计算。此种架构的次要毛病是治理稍简单，从用户视角看到了离线和在线两份数据须要本独自治理。离在线数据存储对立视图架构（预期 v0.7.4 反对） 在此种离在线数据对立视图的架构下，简化了用户视角对于离在线数据的同步和治理。咱们预期会在 0.7.4 版本推出一个自动化的从实时数据库到离线数仓的同步机制。在此种架构下，尽管在物理上咱们仍然有实时数据库和离线数仓两个存储引擎，然而在用户视角上，能够仅关注一个写入通路。用户只须要将新的数据写入 OpenMLDB 实时数据库，设置好实时到离线的同步机制，OpenMLDB 即能够自动化地将数据实时或者定时地同步到一个或者多个离线数仓。OpenMLDB 的实时数据库仍然依附数据过期机制仅保留用于线上特色计算的数据，而离线数仓会保留所有全量数据。该性能预期在 2023 年 4 月上旬的 0.7.4 版本会退出。 实时决策利用架构实时申请计算模式在理解实时决策利用架构前，须要先理解 OpenMLDB 线上实时计算引擎提供的基于申请的实时计算模式，其次要蕴含三个步骤： 客户端通过 REST APIs 或者 OpenMLDB SDKs 发送计算申请（request），该申请可选带有以后事件的状态信息数据，比方以后刷卡事件的刷卡金额、商铺 ID 等。OpenMLDB 实时引擎承受该申请，依据曾经部署上线的特色计算逻辑，进行按需（on-demand）的实时特色计算OpenMLDB 将实时计算结果返回给发动申请的客户端，实现本次实时计算申请本文将从理论利用场景登程，论述基于 OpenMLDB 的实时申请计算模式的常见利用搭建架构。咱们会介绍两种常见的利用架构。 ...

建设企业级数据平台，首先须要理解企业数据，确认治理需要，并抉择一个数据管理架构。那么面对纷繁复杂的数据起源，多元化的数据结构，以及他们的治理应用需要，企业数据平台建设该从何处动手呢？哪个数据管理架构适宜本人的企业呢？本篇将介绍数据仓库、数据集市、数据湖。 — 数据仓库（Data Warehouse）—数据仓库是Bill Inmon在1991年出版的“Building the Data Warehouse”一书中所提出的定义被宽泛承受：数据仓库（Data Warehouse）是一个面向主题的（Subject Oriented）、集成的（Integrated）、绝对稳固的（Non-Volatile）、反映历史变动（Time Variant）的数据汇合，用于反对管理决策（Decision Making Support）。 数据仓库是企业的对立的数据管理形式，将不同利用中的数据汇聚，而后对这些数据加工和多维度剖析，并最终展示给用户。它帮忙企业将纷纷浩杂的数据整合加工，并最终转换为要害流程上的KPI，从而为决策/治理等提供最精确的反对，并帮忙预测发展趋势。因而，数据仓库是企业IT中十分外围的零碎。 依据企业构建数据仓库的次要利用场景不同，咱们能够将数据仓库分为以下两种类型，每一种类型的数据仓库零碎都有不同的技术指标与要求。 企业数据仓库企业会把数据分成外部数据和内部数据，外部数据通常分为两类，OLTP交易系统以及OLAP剖析零碎数据，他们会把这些数据全副集中起来，通过转换放到数据库当中，这些数据库通常是Teradata、Oracle、DB2数据库等。而后在这下面进行数据的加工，建设各种主题模型，再提供报表剖析业务。一般来说，数据的解决和加工是通过离线的批处理来实现的，通过各种利用模型实现具体的报表加工。  * 实时数据仓库 随着业务的倒退，一些企业客户须要对一些实时的数据做一些商业剖析，譬如批发行业须要依据实时的销售数据来调整库存和生产打算，风电企业须要解决实时的传感器数据来排查故障以保障电力的生产等。这类行业用户对数据的实时性要求很高，传统的离线批处理的形式不能满足需要，因而他们须要构建实时处理的数据仓库。数据能够通过各种形式实现采集，而后数据仓库能够在指定的工夫窗口内对数据进行解决，事件触发和统计分析等工作，再将数据存入数据仓库以满足其余一些其余业务的需要。因而，实时数据仓库加强了对实时性数据的解决能力要求，外围的计算引擎须要基于实时计算平台，如开源的Flink或星环科技自研的Slipstream，通过实时引擎来对接机器学习、可视化剖析和实时调度类利用。  —数据集市（Data Mart）—数据集市是一个有针对性的数据仓库版本，它蕴含一个较小的数据子集，这些数据对组织内的单个团队或选定用户组很重要且是必须的。因为数据集市蕴含较小的数据子集，因而在应用更宽泛的数据仓库数据集时，数据集市使部门或业务线可能更快地发现更有针对性的洞察。最后创立数据集市的目标是应答组织在20世纪90年代建设数据仓库的艰难。过后集成来自整个组织的数据须要进行大量手动编码，而且十分耗时。与集中式数据仓库相比，数据集市的范畴更无限，使其实现起来更容易且更疾速。到了大数据时代，尽管企业数据仓库和数据湖在各个企业都曾经遍及，然而每个部门本身也有对业务数据进行解决剖析统计的需要，而且不波及到和其余数据交互，因而特定的部门不心愿在数据量大的数据仓库进行操作（因为操作慢，而且可能影响到其他人解决数据），所以建设一个新的存储系统，把数据仓库里关联本人的数据存储到这个零碎，实质上算是数据仓库的一个子集。这个零碎叫做数据集市。 相比拟数据仓库，因为数据集市波及的数据源集中于某个部门或者业务线的主体，因而其解决的数据会小很多，业务构建比拟麻利，对用户需要的响应也会更加迅速。对集市的用户来说，因为仅凋谢给某个部门或业务主体，其对多租户隔离的需要也不是很强，用户能够更加简略不便的获取数据，能够简略的通过数据报表工具或Excel等工具来做数据分析，因而对基础设施的依赖就绝对比拟低，建设老本也绝对更低。此外，对集市的施行人员来说，波及到要加工解决的数据比拟少，数据加工工夫会短很多，平安治理的要求也比拟低，因而建设和运维绝对更低。总体上说，因为数据集市都是集中在某个繁多的业务畛域，对施行人员和业务用户来说都比拟麻利和灵便。 依照集市和数据仓库或数据库的关系，数据集市也能够分为三种类型： 独立数据集市 ： 独立的数据集市零碎，不依赖数据仓库或数据湖，个别间接从数据源零碎加载必要的数据做加工后依照业务主体提供业务剖析后果；  关联数据集市： 是数据仓库或数据湖的一个局部，个别对应数据仓库的数据集市层，相干的数据加工解决由数据仓库的批处理工作实现； 混合数据集市： 主题数据的起源包含了数据仓库、数据湖，也包含了其余的数据库。这种集市的益处是既能蕴含企业自顶而下设计的从数据仓库中加工而来的业务主题数据，又能满足自下而上的一线分析师的灵便提出的业务需要。 数据集市的底层个别是一个独立的数据库，并且个别提供高并发的统计分析和检索服务，因而对数据库的并发计算性能要求比拟高。为了保证数据集市的并发性能，关键技术包含这两种：一是数据库层采纳反对高并发拜访的分布式数据库来撑持，二是采纳OLAP Cube技术。分布式数据库因为其可扩展性能的劣势，可能撑持更高并发的连贯拜访，并且分布式计算引擎的统计分析SQL的性能更强，还能够通过减少硬件资源来扩大性能，因而针对一些用户规模较大、或者BI报表波及的报表计算非常复杂的部门或业务线，能够采纳分布式数据库。 OLAP Cube技术是将一些数据建模后果事后计算出来，这样剖析人员应用数据的时候就能够灵便的做各种深入分析，如数据下钻、切片等，就能够通过预计算的数据来拜访，而无需去查问底层数据库或从新计算数据，因而如果拜访数据可能命中Cube，业务的并发拜访性能将失去极大的晋升。OLAP Cube自身是采纳空间换工夫的优化策略，它须要用户来指定预计算的schema，此外Cube建模工具会有优化办法来缩小须要长久化的Cube数据，从而缩小预计算须要的解决工夫和存储空间。OLAP Cube技术依据其长久化数据的形式又分为ROLAP和MOLAP，简略了解ROLAP是将建模的Cube数据长久化在数据库中，而MOLAP个别是将Cube数据长久化在报表工具或建模工具中。 — 数据湖（Data Lake）—数据湖是一种企业数据架构的实现形式，在物理实现上是一个存储库，容许用户以任意规模存储所有结构化和非结构化数据，并反对对数据进行疾速加工和剖析。用户能够按原样存储数据（无需先对数据进行结构化解决），并运行不同类型的剖析（从控制面板和可视化到大数据处理、实时剖析和机器学习，以领导做出更好的决策。最后创立数据湖的目标是应答数据仓库无奈解决数量、速度和品种一直减少的大数据的状况。尽管数据湖比数据仓库慢，但它们的价格也更低廉，因为在采集之前简直不须要数据筹备。与数据仓库或数据集市不同的是，数据湖上存储原始数据，通常为PB级别，个别没有简单的业务建模，次要做一些根底的数据治理或者基础性的模型建设工作，更多的为企业外部提供一个公共的数据存储和摸索能力，并为上游的集市、仓库或者中台提供数据与计算能力。很多企业会同时建设数据湖和数据仓库，从而保障更好的数据架构与用户体验。 数据湖反对宽泛的用例，因为在收集数据时不须要定义数据的业务指标。数据湖能够存储结构化和非结构化数据，这种灵便的存储需要对于数据科学家、数据工程师和开发人员尤其有用，让他们可能拜访数据进行数据发现练习和机器学习我的项目。数据科学家能够应用数据湖进行概念验证。机器学习应用程序能够从可能在同一个中央存储结构化和非结构化数据中受害，这是应用关系数据库系统无奈实现的。数据湖也能够用于测试和开发大数据分析我的项目。当利用程序开发实现并辨认出有用数据后，能够将数据导出到数据仓库以供操作应用，并且能够利用自动化来实现应用程序扩大。数据湖还能够用于数据备份和复原，因为它们可能以低成本进行扩大。数据湖非常适合存储尚未定义业务需要的“以备不时之需”数据，当初存储这些数据意味着能够在当前呈现新打算时应用。 从实现形式上看，目前Hadoop是最罕用的部署数据湖的技术，也有采纳MPP+Hadoop的混合架构，近年也有一些基于私有云存储的数据湖计划呈现和落地。 为了满足多样化的数据存储与剖析的需要，在数据湖的建设中，咱们须要设计确保落地后的数据湖具备以下4个要害能力： 数据整合能力数据湖须要提供相干的工具或能力，能够整合包含各种关系数据库存储的结构化数据，以及从各个其余渠道（包含互联网、外部文档、传感器）等收集和存储非结构化数据，并且具备多样化的数据整合策略，包含实时、准实时、离线整合等，容许整合过程中的数据转换等能力。数据计算能力因为数据湖中积攒了企业外部的多样化的数据，因为使用者能够买通外部各种数据，从而剖析其中的数据法则，从而进一步领导和预测剖析。因而，数据湖须要给使用者提供弱小的数据计算能力，可能疾速地从海量数据中检索到要害信息，或是可能做大量数据的碰撞找到关联关系，或是对非结构化数据进行深度的辨认剖析等，这些都须要数据湖的平台提供欠缺的数据计算能力。数据治理能力因为数据湖中会集了原始数据，未做简单的数据模型加工，因而可能存在湖内的数据自身有较多品质问题的状况，或者各个数据源头的规范不对立，因而不能很好地用于领导数据分析业务。因而，数据湖的建设者须要提供工具或计算能力给使用者，能够在数据湖内做进一步的数据治理，从而进步数据品质和价值。数据服务能力数据湖在设计的时候，须要充分考虑如何提供给更多的数据需求者来自助服务，用户能够在数据湖上发现数据、剖析数据、改良数据以及最终奉献数据，从而造成一个从数据到价值链路的闭环。在这个过程中，无效的数据资产目录能够无效地帮忙用户来买通数据链路，而多租户服务能力是外围的技术要求。除了以上4个外围的功能性需要以外，还须要关注一些重要的非功能性需要，包含： 互操作性数据湖自身须要跟企业外部的各个数据系统有很好的互操作性，因而数据整合的工具或零碎须要有良好的连贯互通性，能够与关系数据库、NoSQL、实时数据系统、企业级对象存储等各个系统建设高效的数据交互通道。无效的老本管制因为数据湖自身的特点，存储的数据量个别比拟大，数据价值密度低，因而须要十分关注自身的老本管制，总体方案上须要较低的硬件老本和运维老本，以及较好的资源应用效率，有较好的弹性伸缩，可能反对计量计费等。多租户数据湖个别会凋谢给企业内多个部门或组织共用，而每个使用者自身运行的业务各自有特殊性，譬如机器学习的工作计算复杂度高，CPU耗费大，而检索类工作磁盘IO密集应用，面向多个用户同时提供服务，如果要保障用户体验，数据湖底层须要提供良好的资源共享与隔离能力。业务连续性此外，高可用与灾备能力也是数据湖的一个要害因素，在技术的设计上须要充分考虑相干的技术要求，从而实现极其故障下的业务疾速恢复能力。 — 小结—本篇介绍了数据仓库、数据集市、数据库等数据管理架构。那么对于平台建设落地，该如何依据企业数字化水平，建设一个可继续演进技术架构呢？在接下来的几篇中，咱们将依据企业数字化水平，分五个阶段来介绍。下一篇：存储与算力根底建设

因为企业的业务零碎信息化的分阶段建设、以各自业务为导向等起因，每个业务都积攒本身的数据，造成肯定的数据孤岛。而数字化转型的一个外围就是以数据为抓手来买通各个不同的业务，以数据驱动辅助教训主导的流程来辅助业务，因而须要企业建成一个对立的、可共享的数据平台，推动建设外部业务的对立数据化，为企业治理和决策提供数据根底与剖析能力保障 ，帮忙企业落地数字化策略。建设企业对立的数据平台须要思考哪些问题？本文进行介绍。 — 企业级对立数据平台整体建设思路—企业级数据平台指的是撑持企业的数字化业务翻新和经营的技术根底平台，提供数据驱动、精准决策的全方位技术撑持。 整体要求从公司整体的数字化策略的视角来看，数据平台通过对立的数据整合、存储、计算和服务能力，能够突破企业外部壁垒，服务于企业内的不同业务部门和组织部门，将有形的业务流程自动化和数据化。为了达到既定的策略要求，企业数据平台须要实现几个必要的对立，次要包含： 对立整合企业内、内部各类业务零碎数据，尽量做到“应存尽存、能收则收、层级化治理”；对立治理企业内外部数据资产，造成企业对立数据治理规范及标准，落实数据安全管控，将数据资产化和业务化，实现“数据既能管得住，也能立刻用”；对立撑持企业以及各个组织部门、子公司等创新型利用和业务，提供包含实时计算、离线计算、机器学习等在内的多样化的计算能力，辅助按需提供的算力和数据资产，从而发现数据的业务价值，通过数据驱动来推动经营优化、翻新业务摸索、危险管制等新业务，推动企业数字化转型。* 数据架构的设计 数据架构形容如何治理从收集到转换、散发和应用的数据。它为数据及其在数据存储系统中流动的形式设定了蓝图。它是数据处理操作和人工智能 (AI) 应用程序的根底。 数据架构的设计应该由业务需要驱动，数据架构师和数据工程师应用这些需要来定义相应的数据模型以及反对它的底层数据结构。这些设计通常有助于满足业务需要，例如报告或数据迷信打算。 随着物联网 (IoT) 等新兴技术的呈现，新的数据源不断涌现，良好的数据架构能够确保数据易于治理且具备利用价值，从而反对数据生命周期治理。更具体地说，它能够防止冗余数据存储，通过清理和反复数据删除来进步数据品质，并反对新的应用程序。古代数据架构还提供了跨域（例如部门或天文区域之间）集成数据的机制，突破了数据孤岛，因此打消了将所有数据存储在同一中央所带来的微小复杂性。 古代数据架构常常利用云平台来治理和解决数据。尽管它的老本更高，但它的计算可扩展性使重要数据处理工作可能疾速实现。存储可扩展性还有助于应答一直增长的数据量，并确保所有相干数据都可用，以进步训练 AI 应用程序的品质。 古代数据架构的七大特色： 云原生和反对云，让数据架构可能从云技术的弹性扩大和高可用性中受害。弱小、可扩大且可移植的数据管道，将智能工作流、认知剖析和实时集成联合在一个框架中。无缝数据集成，应用规范 API 接口连贯到原有应用程序。实时数据反对，包含验证、分类、治理和治理。解耦且可扩大，因而服务之间没有依赖关系，而且凋谢规范反对互操作性。多租户反对能力通过优化，在老本和简略性之间获得均衡。— 企业级对立数据平台的五大能力要求—起初，数据平台技术（国内约是2010年后）的定位是贮存原始格局数据的大数据平台，可包容结构化、半结构化、非结构化及二进制的数据。随着大数据技术的交融倒退，数据平台的边界一直扩大，外延也产生了变动，逐步形成了5大能力要求，如下图所示： 企业数据平台的5大外围能力要求次要包含： 数据多源异构：数据平台可能整合和集成多源异构的海量数据，反对结构化、半结构化、非结构化等各种数据模型，这样就可能保障即便前期业务有了新的需要，数据平台也可能即时的实现数据接入、整合和最终的服务，在技术上也可能撑持企业落地“应存尽存、能收则收”的数据策略。数据对立的存储与治理：随着分布式存储技术的疾速倒退，提供对立的数据存储服务曾经成为业内的共识，在实现形式上能够是物理上的对立（所有数据通过物理复制到企业数据平台上）或逻辑上的对立（局部数据依然在其余数据存储中，但能够通过元数据管理、数据联邦等形式实现逻辑的存储管理）。基于对立的数据存储和治理能力，企业能力基本上解决了“数据孤岛”的买通，并且往上对接各种计算引擎和数据管理工具，从而为后续的数据资产化和服务化打好根底。多范式计算：数据资源本身可能提供的价值无限，而海量数据通过多维度的碰撞、关联剖析或智能化学习后，暗藏在数据外面的离散价值就能够被发现和开掘进去，从而将数据变成有价值的资产。因为撑持业务的多样性，企业级数据平台须要反对多种计算引擎，满足不同数据计算剖析需要，反对离线计算、施行计算、图计算、机器学习等多种计算范式，让不同的开发者和分析师能够依照他们的技能畛域和业务领域来抉择适合的计算工具或引擎，让数据被真正的开发和利用起来。数据服务多样化：后面提到的数据整合、存储和计算都属于根底的数据平台技术能力，而数据服务就是连接数据平台和业务之间的要害因素，或者说是数据平台为业务和组织生产的要害产品。企业的产品是企业实现经营性指标的外围交付形式，也是与用户建设黏性的要害介质；同样的类比也适宜于数据平台，因而作为数据平台产品的各种数据服务也是保证数据平台胜利的要害因素，要做到品质高、品类丰盛、平安合规和服务形式多样化，可撑持各种业务畛域。目前企业内次要的数据服务模式包含SQL、API、数据指标、数据标签和数据模型等。利用宽泛：目前各个行业的企业数据利用倒退热火朝天，如面向企业经营剖析的各类数据分析产品，面向政府治理的数据大屏、“衰弱码”等利用，以及面向消费者业务的数据决策类产品等，利用的翻新速度超过数据平台自身。掂量一个数据平台的胜利与否，其最次要的KPI指标应该也是“该数据平台撑持的胜利的数据利用的数量和业务成果”。数据平台和数据利用平台能够离开建设，也能够对立建设。在对立建设的模式下，企业数据平台除了给业务利用提供数据资源或数据资产外，还能够为数据利用提供资源调度和生命周期治理能力，这样不仅能够晋升利用的性能，还能够提供弹性伸缩、资源隔离等利用所需的根底撑持，从而能够让数据利用更加强壮和高效。— 企业级对立数据平台的设计考量—为了可能帮忙企业疾速的撑持业务的需要，更好的满足数字利用的开发和经营，企业数据平台应该是以PaaS平台来对内对外提供服务能力，而不再应该是面向运维和治理的IaaS形式。而在PaaS构建的过程中，为了可能适应将来企业的灵便、疾速变动的业务需要，企业数据平台须要听从如下的几个次要设计考量： 以数据为核心，业务导向在总体的设计思路上，咱们应该从传统的以资源为核心，以运维便利性作为首要考量因素，转变为以数据为核心，以业务作为导向，将能够减速业务翻新速度的技术作为更优先的指标。数据、利用和智能是数字化的三大外围原料，咱们须要在一个PaaS平台上提供包含数据分析、利用开发和智能建模等在内的残缺的工具链，并凋谢给尽可能多的使用者来尝试翻新。 云原生传统的虚拟化技术因为有很大的技术开销，启动和敞开速度慢，扩缩容能力弱，因而并不适宜包含微服务、分布式系统在内的新一代工作负载。容器技术无效解决了相干问题，能够进步数据中心的资源使用率的同时，可能给微服务提供更好的弹性和扩大能力。而通过技术创新，容器技术同样能够反对包含分布式数据库在内的简单业务零碎，同时还能够提供多租户、主动扩大、自动化冗余等能力，这对业务开发者来说进一步升高了运维的难度。因而，容器化技术是将来。 交融互通约瑟夫.熊彼特已经指出，翻新是生产因素的重组。重组可能次要做加法，做交融或者通用化；也可能是做减法，做拆散和专用化。交融带来通用和低成本，然而会有一些冗余；拆散的劣势是高性能和特定场景的能力，然而利用场景少、老本高。交融谋求公众普适，拆散面向业余群体。数字化基础设施的用户是面向企业或组织内宽泛的利用开发者、数据建模人员、以及业务人员，所有处在业务一线的人员都是数据生态的重要人员。因而在设计数字化基础设施的时候，咱们须要充分考虑通用性和低成本，这样能力更好的服务于指标对象。从技术的角度来剖析，利用可能会运行在私有云、公有云、边缘端等任何可能有计算能力的中央，而数据也会随着业务而积淀，因而咱们在设计的时候就须要思考利用的跨云能力、数据的互通互联、云端和边缘端协同等，从而回绝技术烟囱，缩小各种可能的孤岛问题。 层次化设计在架构设计上，须要从传统的以利用驱动开发的形式造成的烟囱式技术栈，转变为谋求服务共享复用思路的层次化设计。下图是企业数据平台的设计思路，做的一个概要的设计参考架构，它不仅蕴含了技术底层，还有数据业务核心层和业务服务层。最上层是间接服务于业务的服务层，提供App、web等的之间拜访和交互能力；中间层是企业的数据业务核心，也是最外围的局部，它蕴含企业积淀的各种无效的业务服务和数据服务，业务依照DDD的准则进行服务划分，数据都做了无效的建模造成数据资产，这可能蕴含数据仓库、数据湖或者数据中台的建设；而最底层应该是云根底平台，提供包含大数据、AI、Kubernetes、容器、数据库、计算、网络、平安等在内的技术能力。 — 小结—本文介绍了企业数字化转型的三层业务模式，给出了平台建设的整体思路，以及一些根底能力要求和建设上的考量。置信大家通过浏览本文，对企业数字化建设曾经有了根底概念。那么面对纷繁复杂的数据起源，多元化的数据结构，企业数据平台建设该从何处动手呢？哪个数据管理架构适宜本人的企业呢？下一篇将介绍数据仓库、数据集市、数据湖。

传统企业正在面临IT新技术的挑战，“云大物移”曾经成了高频呈现的热词，传统企业们愈发清晰地感触到IT的重要性与挑战。传统企业有着数十年积攒的贵重资产，包含客户关系、数据、品牌形象、供应链、渠道等等，要在互联网时代的竞争环境中占得一席之地，靠的不是冲破最高精尖的技术畛域，而是以数字化的模式激活本人多年累积的外围资产，将外围资产转变为能够在互联网上应用的服务，使其焕发新的价值。在这个数字化时代，实现企业数字化转型势在必行。 — 数字化业务倒退的历史回顾— 数据库技术诞生的10年间，技术的改革都来自业务的利用需要，提供交易的能力，这个时代的数据分析能力十分无限。Bill Inmon在1992年提出了数据仓库实践，带动了商业智能疾速倒退，也推动了MPP数据库技术的倒退，由此咱们进入企业数据仓库时代。2010年后，互联网业务需要推动了大数据技术的倒退，大量新型数据如IoT数据、利用埋点、内部数据、非结构化数据等存储需要日益增多，推动了基于大数据的数据仓库、数据湖、数据集市的建设，而AI的衰亡带动了数据迷信平台的倒退。企业开始着手解决数据孤岛的问题，并开始建设除了剖析业务零碎外的在线数据业务零碎。然而数据、利用和AI平台之间互相独立，只能通过接口层做无限的交互。在这个阶段，很多企业都在尝试新利用的拓展，在此过程中摸索新的治理形式。2013年之前，互联网和企业的业务都采纳的是单体利用的开发模式。然而到了数字化时代，业务利用的开发思路须要转变，要从以产品为核心转向以用户和体验为核心。单体利用的开发的毛病大家可能都比拟相熟，很多人参加同一个我的项目，往往耦合重、开发效率低、常常反复造轮子、开发周期长，而且往往是‘牵一发而动全身’；而微服务是一种将单个利用以许多渺小服务所组成的服务套件模式来构建软件的办法，每个微服务领有本人的轻量级数据处理模块和通信机制，能够独立进行开发和部署。因而它能更快交付，更灵便的运维，并防止掉反复造轮子。而当微服务量级进步，可积淀为利用核心，为全公司乃至全行业赋能。单体利用开发模式转变为微服务开发模式，外围是外包的开发模式转为自研模式，要么通过新的治理形式来标准研发，要么是自建研发团队。而随着火线人员对数据的需要越来越多，企业须要开发出大量新的数据利用来继续的迭代业务，改良用户体验，包含实时类、AI类、在线数据类业务的大量翻新和尝试，因而就须要分层设计和更好的数据建模，提供多种不同的数据计算能力，并能够依据业务负载进行弹性的伸缩，因而最终须要云计算技术来反对弹性、灵便的数据服务和利用。 — 什么是数字化转型— 数据是指任何以电子或者其余形式对信息的记录，比方声音、图像、符号、文字等。数据资源是指可能参加社会生产经营流动、能够为使用者或所有者带来经济或社会效益、以电子形式记录的数据。甄别数据与数据资源的根据次要在于其是否具备应用价值。数据因素是参加到社会生产经营流动、为使用者或所有者带来经济或社会效益、以电子形式记录的数据资源。甄别其与数据资源的根据次要在于其是否产生了经济或社会效益。数据价值是指在数据的生命周期中，使用者通过剖析伎俩将数据的属性或内容转换成了具备业务目标的信息，再经剖析造成可执行的决策信息，最终由口头产生价值，进而实现的降本增效数量。在宏观层面上，数据价值次要体现在企业如何利用数据进行生产与经营流动，体现为对使用者效用的进步。从规模角度，高质量的数据因素具备规模报酬递增特色与正反馈效应，而低质量的数据投入规模越大，对企业的烦扰也越大。数据通过解决及整合后，再经剖析造成可执行的决策信息，最终由口头产生价值。数字化转型是指通过利用古代技术和通信伎俩，扭转企业为客户发明价值的形式。现在，数字技术正被融入到产品，服务与流程当中，用以转变客户的业务成绩及商业与公共服务的交付形式。这通常须要客户的参加，但也波及外围业务流程、员工，以及与供应商及合作伙伴的交换形式的改革。 — 数字化转型的必要性— 寰球出名调研机构IDC此前曾对2000位跨国企业CEO做过一项考察，结果显示到2018年，寰球1000强企业中的67%、中国1000强企业中的50%都将把数字化转型作为企业的策略外围。数字化时代是个赢家通吃的时代，产品的推广速度远超以往。在工业时代，收音机花了38年取得了5000万用户，到了信息化时代，iPod用了4年工夫获取5000万用户，而在数字化时代，抖音在2018年春节假期就获取了3000多万的新增沉闷用户。翻新速度是数字化时代的次要竞争资源，因而企业做数字化转型势在必行。 — 数字化转型的三层业务模式— 企业要实现数字化转型，首先须要构建一个全新的数字化策略，从观点和思维上进行转变来适应新时代的要求，包含组织构造的降级、企业文化的建设等工作，只有在企业整体在意识上造成对立，数字化的转型落地才能够执行。在自上而下实现思维和意识上的转变后，企业各级部门须要投入实现两个重要的工作，即建设合乎数字化转型所需的业务状态和构建数字化基础设施。传统的企业业务模式，是一个单向、关闭的过程，它基本上是由企业外部的资源如业务部门、产品经理等，依据外部已有的教训或者常识来布局、设计和建设的。一旦建设实现，业务的迭代个别会比拟少，次要还是通过设计人员的常识更新，亦或是内部竞争状态的变动来驱动的，间接用户很少参加其中，因而这个模式不太适宜数字化时代的经营要求。数字化的企业业务，在信息状态上是双向，业务部门给用户提供产品和内容，用户会反馈行为轨迹、爱好、倡议等数据，而利用可能在线或者离线的依据用户反馈进行内容迭代或者产品更新。数字利用的外围是数据在每个环节都能够产生价值，设计的思维是用户至上，次要是让数据来驱动业务状态，而不再是产品设计人员的教训和常识。此外因为用户的不同需要反馈，数字利用的迭代速度要远快于传统利用，个别是每月甚至是每周就须要优化和迭代。在技术实现上，因为面对着长尾的用户，产品的设计须要互联网化，可能面对高并发的用户拜访，可能自动化的进行产品保护，并智能化的依据用户来做内容更迭。企业的数字化的业务演进，在技术上能够合成为三个层面：数据模式：数据的无效应用是数字化的基本前提。企业须要首先解决数据的存、通、用的外围问题，从没有数据、依附人的教训的模式转变为以数据驱动的模式，并须要将数据能够赋能的对象，从技术开发人员扩充到所有的一线工作人员，甚至是其生态。因而须要全新的大数据视角来推动数据应用。利用模式：须要从传统的单体利用转变为云原生模式，从而能够更好更快的依据用户的需要迭代，并可能无效的用人工智能技术来驱动利用。在落地过程中，企业须要找一些要害的业务（如AI利用）来进行先期摸索。IT模式：须要从运维的视角（治理机器资源）转变为驱动业务为核心，须要提供云原生的平台，反对数据平台和数字业务的运行和撑持。除了IaaS平台以外，个别须要构建PaaS云平台来满足数据和利用开发的需要。 — 小结— 本文介绍了数字化倒退历史，以及数据模式、利用模式、IT模式的三层业务模式的数字化建设策略。数字化时代的明天，翻新速度是次要竞争资源，企业的数字化转型势在必行。那么企业级数据平台，须要有哪些根底能力呢？下一篇将介绍企业级对立数据平台建设思路。

近日，KaiwuDB 携旗下系列产品及数字能源一站式解决方案，亮相中国石油石化企业信息技术交换大会。大会由中国石油学会、中国石油、中国石化、国家管网、国家能源等单位独特主办，是我国石油石化企业数字转型、智能化倒退畛域备受瞩目的、权威的、大型的科技交流平台。 KaiwuDB 大会展台 本次大会特邀某部委、公安部、国资委等无关部门领导，来自石油石化企业、高等院校、科研院所等单位领导、专家和代表共计 2000 余人加入会议，独特探讨数字化技术推动科技翻新、能源转型和零碳倒退的办法路径。 大会现场客户答疑交换 继续构建拓展数字技术生态圈，致力创始油气行业高质量翻新倒退新格局是时代所需。本次亮相石油大会， KaiwuDB 重点展现了其面向数字能源行业打造的一站式解决方案： KaiwuDB 数字能源解决方案推出了能源企业数据实时剖析、多维数据模型摸索、数据可视化展现等多样性性能，帮忙企业实现对能耗、设施、人员的智能化集中化管控；通过实时数据监测、预测、剖析与调度，服务于能源数据从采集、存储、治理、计算剖析与利用的全流程，为能源企业提供了智能化的全新解决方案。 KaiwuDB 联合分布式计算、多模数据库架构、实时就地运算等核心技术，构筑更高效、更平安的能源管理平台，具备反对能源企业大量设施数据实时采集、百万级测点的数据汇入、高压缩比算法大幅升高数据存储压力等要害个性。 数字能源解决方案架构图 通过上述计划可助力客户企业实现千万级以上数据记录毫秒级查问响应，领有批量高速简单查问、多维聚合等实时数据处理能力，海量数据计算和剖析能力帮忙企业实时监控预测能耗信息，削峰填谷升高损耗，智能化调度剖析为企业降本增效。 基于上述计划的设计思路，KaiwuDB 已携手河工大，围绕分布式计算、云边端协同等技术在新能源场景中的交融利用开展单干，顺利推动了新能源发电零碎数字化与智能化验证平台建设。 将来，以新技术、新资料、新能源为次要驱动力的能源反动正推动社会进入全新能源时代，KaiwuDB 将专一打造更多能源畛域标杆落地实际，攻坚数据库利用技术难题，赋能能源行业高质量倒退。

HDFS 作为 Hadoop 提供存储组件，曾经成为大数据生态外面数据存储最罕用的抉择，通常在机房环境部署。 JuiceFS 是一个基于对象存储的分布式文件系统，用户能够在云上疾速地搭建按需扩容的弹性文件系统。 如果企业正在思考在云上构建大数据平台，理解这两种产品的差别和优缺点，能够为企业迁徙或切换存储产品提供参考。这篇文章将从技术架构、性能个性、应用场景等多个方面来解析 HDFS 和 JuiceFS 的异同。 1. 架构1.1 HDFS 架构HDFS（Hadoop Distributed File System）是 Hadoop 生态系统中的分布式文件系统。在 HDFS 的架构中，有两种类型的节点：NameNode 和 DataNode。一个最简略的 HDFS 集群就是由一个 NameNode 和一组 DataNode 组成。 NameNode 是 HDFS 的元数据管理节点，负责管理文件系统的命名空间和响应客户端对文件元数据的申请（比方 create，open，rename，delete 等申请），同时， NameNode 也负责管理 DataNode 和数据块的映射关系，保护所有文件和目录的层次结构，记录文件的名称、文件大小、文件块的地位等信息。在生产环境应用时，HDFS 须要部署多个 NameNode 并联合 ZooKeeper 和 JournalNode 来实现高可用。 DataNode 是 HDFS 的数据存储节点，负责存储理论的数据。一个文件会被宰割成一个或多个文件块，每个 DataNode 节点存储一部分数据块，并向 NameNode 汇报存储的块的列表和状态信息。DataNode 节点解决客户端的读写申请，向客户端提供文件块的数据。 1.2 JuiceFS 架构与 HDFS 不同，JuiceFS 社区版采纳的是插件化架构，JuiceFS 的文件数据是被切分后并保留在对象存储（如 Amazon S3、MinIO）中，元数据则存储在用户抉择的数据库中，例如 Redis、TiKV、MySQL等。这种架构的设计使得 JuiceFS 能够通过共享同一个数据库和对象存储实现强一致性保障的分布式文件系统。 ...

欢送拜访 OceanBase 官网获取更多信息：https://www.oceanbase.com/ 近日，金融信创生态实验室在京举办金融信创解决方案研讨会，正式公布第二期金融信创优良解决方案，OceanBase 基于数据库的金融外围业务解决方案胜利入选该名单。 金融信创生态实验室成立于 2020 年 11 月，由中国人民银行领导的中国金融电子化公司牵头组建，是专一金融信息技术翻新的重要基础设施和专业化试验平台。 2022 年 10 月 24 日起，金融信创生态实验室组织金融机构、高校、科研院所和产业机构等领域专家发展多轮计划评审工作，最终评比出 21 个《金融信创优良解决方案（第二期）-产品工具类-产业机构》解决方案，OceanBase 的解决方案被收录其中。 金融行业对数据库有着最为严苛的要求，金融级数据库也一贯被用户视为平安、稳固、牢靠的代名词。OceanBase 已服务全副政策性银行、2/3 国有大行，浦发银行、民生银行、安全银行、渤海银行等股份制商业银行，以及北京银行、宁波银行、西安银行、中原银行、天津银行、香港银行、云南红塔、苏州银行、富滇银行、常熟农商、顺德农商、广东农信、四川农信、湖南农信、河南农信等近百家银行。 除近百家银行客户外，OceanBase 在保险、证券、基金、期货等金融子畛域捷报频传，一直博得中国人寿、中国安全、中华保险、中国人保、泰康保险、太平洋保险等第一梯队保险公司，以及招商、中信、广发、易方达、国泰君安、华泰等第一梯队资管公司的信赖。目前，全国已有 1/4 的头部金融客户将 OceanBase 作为外围系统升级首选。 欢送拜访 OceanBase 官网获取更多信息：https://www.oceanbase.com/

为什么须要窗口函数？ Window是一个罕用且重要的性能，PolarDB-X作为一款分布式数据库，天然也反对了窗口函数。对于业务开发来讲，其能够大大简化业务SQL的设计，比方分组排序功能，如果反对窗口函数，则只需应用排序函数即可，例子如下。 例：我当初有一张表，蕴含学生姓名，学生班级，学生问题，当初请你帮我写一条SQL，实现对每个班级内的同学进行排名的需要？ 有窗口函数时： SELECT student_name, class_name, score, DENSE_RANK() OVER (PARTITION BY class_name ORDER BY score DESC) AS rankFROM student_scoresORDER BY class_name, rank ASC;无窗口函数时：就须要写比较复杂的SQL，感兴趣的同学能够自行尝试或者网上搜寻一下如何写这样的SQL（或者这也可能在面试中被问到:)）。 窗口函数是什么？实质上window是一种aggregation，然而不同于agg的是，agg要进行聚合的是该分组内的所有记录，每个分组也只会输入一行记录，而window则能够管制对于每一行来讲，想要聚合的记录到底是哪些，当然这种管制也是通过规定进行束缚的，输入的记录行数等于输出的记录行数，上面贴了一张图，应该还比较清楚:)。 上图中的partitioin by与大家常写的SQL中的group by根本等价，比拟容易了解，不再赘述。咱们来开展介绍一下frame是个什么样的货色，如前所述，frame管制的是进行partition分区后，在该partition分区内，该行应该抉择哪些行进行聚合运算。 具体来讲，咱们是通过between和and来指定咱们心愿框定向前和向后的哪些行进行聚合运算的，而指定形式也无非是行数，以后行以及不做限度，据此咱们能够将frame分为四类，如下图所示。 实际上，将frame划分为不同的类型，能够领导咱们依据不同的frame类型进行不同的优化，其次要目标是为了防止反复计算。比方对于unbounded preceding and unbounded following类型，显然咱们只需对该分组进行一次计算即可，该分组的后续记录可间接应用该后果。而对于sliding frame则不能这样解决，其解决要简单一些，对于每一行，咱们都须要找出该行所对应的框定行，而后对这些行进行聚合运算。 进一步的，frame能够分为两类，row模式和range模式，row模式寻找边界的根据是行数，而range模式的根据则是值。咱们拿一个例子进去，看下row模式和range模式的区别吧。如下图所示，其frame定义均为between current row and current row，然而在row模式和range模式下，其选中的行并不相同。 在上述的介绍中，咱们没有介绍每个分区内的order by字段，其实一个残缺的window的定义蕴含partition by, order by和frame specification。但order by了解起来也比较简单，顾名思义，order by即指定对于每个分区内的行，该当依照什么程序进行排序，frame中的向前向后多少行也是基于该排序后的汇合。 Q：抛一个问题，有趣味的敌人能够思考一下，向前向后的行肯定是间断的，这是为什么呢？比方range模式下如何保障这一点？ 窗口函数的设计与实现窗口函数可能不是那么容易了解，所以咱们在后面进行了比拟多的介绍，当初咱们终于来到了设计与实现局部。 如何执行窗口函数？咱们以一条SQL为例吧，如下所示，partition字段为c1，排序字段为c2，frame定义为rows between 1 preceding and 1 following。 select c1, c2, avg(c2) over ( partition by c1 order by c2 rows between 1 preceding and 1 following )from t;首先，关键点1，c1字段雷同的记录该当被搁置在一起（shuffle）；其次，关键点2，当咱们对c1 + c2进行排序时，即可辨认每行属于哪个分区以及该行的相干行是哪些。据此咱们来开展介绍一下优化器和执行器的设计。 ...

NineData 联结创始人周振兴（苏普）受邀加入2023年 ACMUG 第一站西安站，发表了《云数据库架构与选型》主题演讲。 ACMUG，全称为中国MySQL用户组 (All China MySQL User Group) ，是 MySQL 和 MariaDB 在中国最大的技术社区，是失去了 Oracle User Group Community、MairaDB Foundation、中国计算机行业协会开源数据库业余委员会等官网认可的社区组织，ACMUG 会邀请国内外顶尖互联网公司和大型企业技术专家，分享其在数据库、大数据、云原生、AIOps 等技术方向上的教训以及最新进展。 以下内容，依据周振兴在【2023年 ACMUG 第一站西安站 】线下演讲内容整顿而成。 AWS 在 2009 年公布第一款云数据库产品 RDS MySQL，阿里云于2011年 也公布了本人的 RDS MySQL，到当初，云数据库技术曾经通过了 14 年的倒退。云数据库的架构曾经变得非常复杂，上周则借着 ACMUG（中国 MySQL 用户组）的分享则总结了 AWS 和阿里云 RDS 的次要架构特点，并通过一张架构图汇总，帮忙开发者依据须要在适合的场景抉择适合的架构与规格。 一、AWS：抉择适合的 RDS 架构与规格1.1 架构与规格大图 该架构图蕴含了高可用架构、CPU 架构抉择、存储类型抉择等内容。该架构图不包含性能、准确的对应关系（如 SQL Server 反对的存储空间大小与 MySQL 有什么差异）等内容，临时不包含 Aurora 架构（后续思考补充）、Custom、Outpost 类型等。 1.2 高可用架构AWS RDS 的高可用架构包含了单可用区（Single-AZ / Single DB instance）、多可用区（Multi-AZ DB instance）这两种常见类型，RDS MySQL/PostgreSQL 还提供了多可用区集群版（Multi-AZ DB Cluster）。 ...

3月29日，中国通信标准化协会大数据技术标准推动委员会在杭州召开本年度第一次整体工作会议。 KaiwuDB 自成为中国通信标准化协会大数据技术标准推动委员会成员单位并退出大数据技术与产品工作组（WG1）、数据库与存储工作组（WG4）后，始终积极开展各项工作，陆续参加了包含大数据数据库一体机技术要求、数据库稳定性测试要求、数据库迁徙工具能力要求等在内的各项行业标准制订。 整体工作会议上同时举办了数据库利用翻新实验室汽车行业工作组成立典礼，KaiwuDB 作为汽车行业工作组副组长单位发表了演讲。 为进一步标准汽车行业数据库标准化建设工作，中国信通院数据库利用翻新实验室筹备建设了汽车行业工作组，旨在围绕汽车行业数据库规范编制、行业报告、沙龙流动等发展相干工作。目前，泛滥支流数据库厂商、头部汽车企业等参加共建。 KaiwuDB 重点面向物联网、车联网、数字能源等要害畛域发力，先后助力包含工联院、山东重工等在内 100+ 要害客户胜利实现落地实际。近日，KaiwuDB 又联手河工大开展产学研单干，推动新能源发电零碎数字化与智能化验证平台建设。 将来，KaiwuDB 将面向车联网数据管理、人车路协同治理、车联网智能驾驶、智能汽车综合治理等多纬度场景，打造高性能多模架构数据库解决方案，助力智能车企充分调动数据生机，开释数据价值，为汽车产业绿色低碳倒退开翻新场面。 此外，咱们也将踊跃投身于大数据技术标准推动委员会相干工作，与委员会成员单位携手输入更多规范，独特实现行业跨越式倒退。

一、技术背景在面向数字能源畛域，KaiwuDB 就元数据同步存在以下利用场景：源端执行元数据操作语句，同时对应源端元数据变动；这些元数据须要在指标的一端进行同步，而实现这一指标的办法是通过数据复制同步模块来实现。 元数据复制同步能够分为两个局部： 元数据回放表的复制模块；元数据回放模块。本文次要介绍整个元数据同步模块中的后半局部，即元数据回放（metadata backfill）模块的技术实现。 二、技术根底1. 元数据回放表此表用于记录源端元数据操作 SQL 语句： 表 1：元数据回放表 2. 表级别的复制表级别的复制是元数据回放的根底。通过复制语法能够将源端的元数据回放记录表复制到指标端，在源端通过 DDL 对元数据进行操作的语句，将会由表级别的复制发送到指标端，实现对元数据记录表的复制操作。元数据回放模块在此表的同步根底上，进行两端的元数据回放并达到元数据同步的目标。 元数据模块由表级别的复制调用触发。在表级别的复制过程中，存在将数据写入元数据表的操作。抉择在数据写入到指标端的回放表时，触发回放模块，进行检索并实现元数据回放。 三、实现流程图 1：回放流程 1. 记录元数据操作语句咱们在执行元数据操作的 SQL 语句时，在执行流程中调用回放表写入接口，将 SQL 语句等其余参数记录在元数据回放表中。 写入此表的数据中，生成的主键为以后的 portal_id（portal_id 和源端绑定，每个端的 portal_id 是不同的）和生成的 rowid 联结主键。因而，纵使多个源端的语句也能够在同一指标端聚合在同一张回放表中，不会产生主键抵触问题。默认记录的 SQL 语句的回放状态为未回放状态。 2. 回放模块的启动回放模块的启动是基于启动服务时拉起一个协程。通过启动一个回放协程，协程中会检测信号 signal 作为回放模块的触发机制。 若 signal 接管到信号，就触发回放模块的执行。启动后的回放模块，期待复制模块的触发信号，进而触发回放。 3. 回放模块的触发复制模块通过复制表将源端记录表复制到指标端。随着一直的 SQL 记录写入回放表，表级别的复制能够将后续的 SQL 语句记录发送到指标端。 在指标端上，写入回放表时通过向 signal 赋值，即向回放协程模块发送触发信号，就能够在回放模块中触发回放模块。触发回放模块后，就能够进行到下一步回放模块的执行。 4. 回放模块的执行图 2：回放执行模块 1）获取回放语句 通过对复制过去的源端的回放表的查问，通过筛选查出回放表的未回放语句，查找对应 SQL 记录的回放状态，从而拿到须要回放的待回放语句。 从回放表拿到的语句解析为待执行的字符串语句，这些语句就是待同步在指标端执行的语句，将其传入回放模块的下一阶段，执行回放语句。 2）执行回放语句 将获取的待回放语句传入执行回访模块，利用执行模块对获取到的语句进行执行，实现元数据在指标端的同步执行。 执行完语句后，须要批改此条语句的回放状态，进入更新语句的回放状态模块。 3）更新回放状态 回放胜利的语句，须要进入更新回放状态模块，将记录的语句执行胜利的更新状态为 true 已执行，下次从新获取的语句就会跳过曾经被回放过的语句。 回放模块的执行中，抉择将执行回放语句模块放入同一个事务执行，若语句回放失败，则不进行更新状态；若更新回放状态失败，则回退回放语句的执行。放在同一个事务中，保障回放状态和是否胜利执行回放语句保持一致。 四、总结优化基于复制的技术根底，回放模块启动后，触发和执行回放模块，在源端执行的元数据操作 SQL 语句，同步到指标端进行回放，从而达到元数据的同步。本文讲述的是一个根底的实现思路，将来仍将有很大的优化空间。

面试官：一千万的数据，你是怎么查问的？1 先给论断对于1千万的数据查问，次要关注分页查问过程中的性能 针对偏移量大导致查问速度慢：先对查问的字段创立惟一索引依据业务需要，先定位查问范畴（对应主键id的范畴，比方大于多少、小于多少、IN）查问时，将第2步确定的范畴作为查问条件针对查问数据量大的导致查问速度慢：查问时，缩小不须要的列，查问效率也能够失去显著晋升一次尽可能按需查问较少的数据条数借助nosql缓存数据等来加重mysql数据库的压力2 筹备数据2.1 创立表CREATE TABLE `user_operation_log` ( `id` int(11) NOT NULL AUTO_INCREMENT, `user_id` varchar(64) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL, `ip` varchar(20) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL, `op_data` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL, `attr1` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL, `attr2` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL, `attr3` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL, `attr4` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL, `attr5` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL, `attr6` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL, `attr7` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL, `attr8` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL, `attr9` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL, `attr10` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL, `attr11` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL, `attr12` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL, PRIMARY KEY (`id`) USING BTREE) ENGINE = InnoDB AUTO_INCREMENT = 1 CHARACTER SET = utf8mb4 COLLATE = utf8mb4_general_ci ROW_FORMAT = Dynamic;2.2 造数据脚本采纳批量插入，效率会快很多，而且每1000条数就commit，数据量太大，也会导致批量插入效率慢 ...

腾讯云存储团队正式公布数据加速器 GooseFS 1.4 版本（含 GooseFS 1.4.0 和 GooseFS 1.4.1 版本），该版本针对 AI、大数据场景提供了文件解压缩等便捷易用的工具，同时针对海量文件读写下的集群性能和稳定性问题进行了针对性优化，晋升了产品竞争力。 重点更新点一：提供文件解压缩能力AI 场景下，业务团队可能会将大量用于训练或者学习的文件打包成一个压缩包并上传到对象存储中；在执行训练或者学习工作时，再将压缩包文件下载到本地并解压。这一流程会对底层对象存储服务产生较大的读带宽，每次启动工作时，无论须要读取多少文件，都须要将文件所处的压缩包整包下载才能够执行。 GooseFS 在本次更新中联结 COS 服务提供了服务端的解压缩能力，反对通过解压缩工具向 COS 服务端发动解压缩申请，晋升文件拜访性能。GooseFS 反对文件解压缩能力的根本框架如下： 整体流程上：1. 首先通过 GooseFS 解压缩指令goosefs fs decompress向 COS 服务发动指定文件的解压缩申请。 2. COS 服务收到解压缩申请后，会向解压缩服务模块提交解压缩工作，由文件加压缩模块治理工作进度。3. 解压缩过程中，用户能够通过goosefs fs queryDecompress指令查问解压缩工作的状态。4. 解压缩工作实现后，实现解压后的文件会输入至用户指定的文件目录中。5. 反对通过goosefs fs listDecompressJobs <namespace>指令查阅指定命名空间的解压缩工作停顿。 GooseFS 提供的解压缩能力目前依然在公测阶段，公测阶段有地区和可用区限度，但暂不进行免费，如需应用能够提交工单申请。 应用 GooseFS 文件解压缩能力的劣势如下：1. 防止文件读放大问题，缩小底层对象存储服务的读带宽。用户在服务端侧实现解压缩后，只需按需读取须要用到的文件，无需读取整个压缩包。  缩小客户端侧的 CPU 压力。用户无需在客户端侧执行解压缩操作，能够让贵重的计算资源聚焦在 AI 计算工作上。重点更新点二：反对长期密钥被动热更新GooseFS通过托管在集群中的密钥拜访远端的对象存储服务。腾讯云的永恒密钥具备永恒的有效期，长期密钥的有效期则能够由用户自行指定，最长不超过 2 小时。在 GooseFS 集群中托管永恒密钥存在肯定的平安危险，比方当永恒密钥泄露时，对象存储服务中的文件将继续存在泄露的危险。因而在本次更新中，GooseFS 团队提供了长期密钥托管的模式。 通过长期密钥托管服务，用户能够只在 Worker 节点上缓存从 Master 节点拉取的长期密钥信息，并通过长期密钥拜访远端对象存储服务，获取业务所需数据。GooseFS 反对长期秘钥托管服务的整体框架如下所示： 整体流程上：1. 在 Worker 节点中，能够周期性地通过以下指令，变更节点上的长期密钥信息。goosefs ns update <namespace> [--secret <key=value>] [--attribute fs.cosn.userinfo.sessionToken=xxx]2. 客户端读取文件时，如果文件未缓存在 Worker 节点上，Worker 节点能够通过长期密钥拜访远端对象存储服务拉取文件。 ...

欢送拜访 OceanBase 官网获取更多信息：https://www.oceanbase.com/ 在咱们 3 月 25 日的 OceanBase 开发者大会现场，有一面非凡的墙，很多用户在这面墙上留下了对咱们的祝愿、对咱们的鞭策、倡议、对咱们的告白、以及一些碎碎念。 在大会完结的早晨，工作人员撤场的时候，咱们将大家的留言带了回来进行了整顿，如下。 ❤️灵魂画手 画得真难看！下次也要持续画哦~ ❤️@产研同学 有小伙伴说心愿咱们的生态及周边工具、OMS 性能、全量校验、反向同步能力更加欠缺，咱们曾经将这张便当贴转交产品同学了哦~ 有同学心愿咱们的版本更加成熟稳固，版本升级能够更加无感平滑，这也是咱们始终以来的谋求！心愿下次您在体验 4.2、4.3......5.x 时，能够感触越来越好。 也有同学说心愿 OceanBase 能够更加轻量化，能够适配更多的业务场景，咱们想说，小型化是咱们去年、往年乃至当前始终致力谋求的指标，也是咱们 4.0 版本的重要特点之一。 去年咱们公布的 4.0 小鱼通过一直的技术创新，弥合了传统的集中式架构和分布式架构的鸿沟，突破了分布式数据库只能用于大型场景的局限，在走向千行百业的路线上迈进了一大步。 ...... 谢谢大家对咱们产品技术的倡议，下次遇见，肯定会更好！ ❤️@开发者大会和社区 “受益匪浅”、“品质十分好”、“深入浅出”、“充满希望”......看到大家对咱们的开发者大会示意认可，咱们的 OceanBase 的每一位同学真的十分十分十分快慰~ 咱们深知，OceanBase 产品的迭代和降级离不开宽广关注咱们的开发者。2021 年 OceanBase 开源以来，在很多小伙伴的默默反对下，咱们的社区从无到有，初具雏形。通过两届数据库大赛、N 场线下 Meetup、N 场线上直播，咱们意识了很多开发者、好敌人、新用户，并进行了深刻的交换。 话不多说，明年大会，咱们以更好的风貌相见！ ❤️@OceanBase 数据库 越来越好、加油、走向世界、腾飞......在大家的奢侈祝愿里，咱们读到了真挚。 这个板块的留言也是最多的。感恩！ ❤️@得心应手许诺区 在这片区域，也不乏有大局观的同学，科技自主自强，OceanBase 也会致力奉献本人的绵薄之力！ 愿许诺找到新工作的小伙伴梦想成真！ 一起致力，放弃酷爱和激情，奔赴星辰大海！ 除了咱们的聆听墙区域，咱们现场的问卷也收到了很多很好的倡议，非常感谢大家的反馈和小欲望~咱们都记下啦！ 你留下的所有对产品技术的倡议，咱们都会反馈给产研团队。 你对 OceanBase 的每一条祝愿，咱们都会当作能源好好收藏！ 欢送拜访 OceanBase 官网获取更多信息：https://www.oceanbase.com/

作者：徐嘉 StarRocks Active ContributorStarRocks 函数就像预设于数据库中的公式，容许用户调用现有的函数以实现特定性能。函数能够很不便地实现业务逻辑的重用，因而正确应用函数会让读者在编写 SQL 语句时起到事倍功半的成果。StarRocks 提供了多种内置函数，包含标量函数、聚合函数、窗口函数、Table 函数和 Lambda 函数等，可帮忙用户更加便捷地处理表中的数据。此外，StarRocks 还容许用户自定义函数以适应理论的业务操作。本文将以标量函数和聚合函数为例，介绍 StarRocks 常见的两种函数实现原理，心愿读者可能借鉴其设计思路，并按需实现所需的函数。同时，咱们也欢送社区小伙伴一起贡献力量，独特欠缺 StarRocks 的性能，具体的函数工作认领形式请见文末。 如何为 StarRocks 增加标量函数标量函数介绍标量函数用于解决单行数据，承受一个或多个参数作为输出，并返回一个值作为后果。StarRocks 常见的标量函数有 abs、floor、ceil 等。 标量函数的实现原理首先，咱们来理解函数签名，函数签名用来惟一标识函数，形容函数的 ID、名字、返回类型、输出参数的类型等根本信息。标量函数的函数签名定义在gensrc/script/functions.py，在编译阶段咱们会依据 Python 文件中的内容生成对应的 Java 和 C++ 代码，供 FE 和 BE 应用。每个函数签名在 Python 文件中通过一个特定的数组来形容，数组的内容有如下两种格局： [<function_id>, <function_name>, <return_type>, [<arg_type>...], <be_scalar_function>]or[<function_id>, <function_name>, <return_type>, [<arg_type>...], <be_scalar_function>, <be_prepare_function>, <be_close_function>]其中根本信息如下： function_id：函数惟一标识，是惟一一串数字，function_id 遵循如下约定，前两位示意 function_type，两头两位示意 function_group，余下的示意具体的 sub_function，前面咱们会举例说明function_name：函数名称return_type：返回值类型arg_type：入参类型，如果有多个入参，须要在数组中形容每个入参的类型be_scalar_function：BE 中负责实现该函数计算逻辑的函数be_prepare_function/be_close_function：可选参数，有些函数在执行的过程中可能会传递一些状态，be_prepare_function 和 be_close_function 就是 BE 中负责实现创立状态和回收状态的函数为了反对多种数据类型作为输出，须要为每种类型独自创立函数签名。以下以 abs 函数为例，该函数用于计算绝对值，须要形容以下五个信息： function_id：10代表它们都属于 math function，04代表它们都属于 abs 这个 function group，余下的数字用来辨别具体的 sub-functionfunction_name：函数名称都是 absreturn_type：返回值类型，同入参类型统一arg_type：该函数只承受一个入参，所以第四项的数组中只有一个元素。be_eval_function：BE 中实现计算逻辑的函数，StarRocks 针对每种数据类型做了非凡解决，所以每个签名中的函数名也不一样对于 abs 函数而言，因为不须要传递状态，因而不须要 be_prepare_function 和 be_close_function 这两个选项。请留神，这两个选项在某些状况下可能会用到，具体用法将在前面的示例中介绍。 [10040, "abs", "DOUBLE", ["DOUBLE"], "MathFunctions::abs_double"], [10041, "abs", "FLOAT", ["FLOAT"], "MathFunctions::abs_float"], [10042, "abs", "LARGEINT", ["LARGEINT"], "MathFunctions::abs_largeint"], [10043, "abs", "LARGEINT", ["BIGINT"], "MathFunctions::abs_bigint"], [10044, "abs", "BIGINT", ["INT"], "MathFunctions::abs_int"], [10045, "abs", "INT", ["SMALLINT"], "MathFunctions::abs_smallint"], [10046, "abs", "SMALLINT", ["TINYINT"], "MathFunctions::abs_tinyint"], [10047, "abs", "DECIMALV2", ["DECIMALV2"], "MathFunctions::abs_decimalv2val"], [100470, "abs", "DECIMAL32", ["DECIMAL32"], "MathFunctions::abs_decimal32"], [100471, "abs", "DECIMAL64", ["DECIMAL64"], "MathFunctions::abs_decimal64"], [100472, "abs", "DECIMAL128", ["DECIMAL128"], "MathFunctions::abs_decimal128"],在 StarRocks 的编译和执行阶段，都会应用函数签名来确定函数的输入输出和执行逻辑。具体流程如下： ...

什么是 StarRocks 源码实验室？援用浏览源码是开发者深刻理解一个我的项目的好办法，不仅能够更好地了解程序的逻辑和实现形式，对于调试和批改代码也十分有帮忙。对于想要退出 StarRocks 社区奉献的小伙伴来说，这是必要的学习之一，因为理解 StarRocks 外部运作机制有助于疾速上手并参加到开发工作中。为此，StarRocks 社区推出了 StarRocks 源码实验室，联合实践和实际，帮忙大家将所学常识利用到理论工作中。大家在实现学习后，能够间接到 GitHub 认领工作，不出 30 分钟的工夫，你也能够成为 StarRocks Contributor！函数作为实现某些性能运算和实现各种特定操作的重要伎俩之一，丰盛的函数能够帮忙用户缩小反复编写程序的工作量和进步程序编译和运行效率。函数奉献不仅十分的老手敌对 （因为不须要花大量的工夫学习 StarRocks 简单的内核机制），又能够造福宽广的社区用户，让大家都能更简略地应用 StarRocks！4 月 6 号（星期四）早晨 19:00-20:00，StarRocks 源码实验室第一期咱们将为大家揭秘 StarRocks 内置函数的工作原理。快来报名直播和认领工作，StarRocks 函数 Master 的头衔等你来拿！在观看直播前你也能够提前浏览技术底细｜StarRocks 标量函数与聚合函数，理解 StarRocks 两类常见函数的实现原理。 开始入手试验在你入手开始试验前请谨守实验室规定，否则可能有操作不通过的危险！ 第一步：到https://github.com/StarRocks/starrocks/issues/13300选取工作。 第二步：请在 issue #13300评论区 @kateshaowanjou 预订问题，评论能够参考上面 ： Hi @kateshaowanjou, Could you please assign xxx to me? thx!第三步：上一步实现后你须要再到你选中的函数 issue 里留下任意评论，这样咱们才能够把此 issue assign 给你。 第四步：当你被 assign 了工作之后，在理论开发之前，务必与社区探讨设计、输出/输入、参数、函数名称等，这样能够确保你的函数合乎社区标准。 退出探讨的形式：你能够在 GitHub issue 下评论区做探讨或是退出函数开发的微信群 （入群形式见下方） 第五步：提交 PR （奉献流程注意事项请见：https://docs.starrocks.io/en-us/main/developers/How_to_Contri...） 第六步：持续挑战 or 填写问卷兑换奖品 ： https://tl-tx.dustess.com/Um5wF7XKdX 特地留神： 在 PR 提交前一个人只能被 assign 一个工作，PR 提交实现后（不须要合并通过）能够再预约新的函数工作如果在开发过程中遇到了问题，请随时向社区寻求帮忙。欢送扫码加小助手后回复“函数”，咱们会拉你进函数开发群一个函数工作的期限是一个月。如果您很忙无奈实现认领的工作请通知咱们，咱们能够把工作重新分配给其他人。否则咱们将主动在 1 个月后重新分配工作给其余小伙伴。积分会每两周颁布在 StarRocks 论坛，最终积分将在 6/7 前颁布，大家定期关注本人的排名噢！（链接：https://forum.mirrorship.cn/t/topic/6235）积分规定 & 奖品兑换 ...

欢送拜访 OceanBase 官网获取更多信息：https://www.oceanbase.com/ 3 月 25 日，第一届 OceanBase 开发者大会在北京举办，OceanBase CTO 杨传辉在主论坛进行了《打造开发者敌对的分布式数据库》的分享。 以下为演讲实录： 各位 OceanBase 的开发者，大家上午好！OceanBase 在去年 10 月份公布了最新的 OceanBase 4.0 版本，4.0 版本作为单机分布式一体化架构，我认为它给开发者带来最外围的价值在于极大地升高了分布式数据库的应用门槛。 明天也是第一次开发者大会，非常高兴能在这里与咱们 OceanBase 的开发者谈谈我本人对于怎么去构建一个对开发者敌对的分布式数据库的思考。 OceanBase整体架构演进首先，OceanBase 宏观上三次架构的演进，有很多人可能晓得晚期的 OceanBase 是一个单写多读的架构，存在 OceanBase 的 0.1 版本直到 0.5 版本。OceanBase 在 1.0 版本公布了过后的全分布式架构版本 1.0，这个 1.0 架构也利用在 1.x 版本、 2.x 版本、3.x 版本，直到 2022 年公布了最新的单机分布式一体化架构 4.x 版本，它对于用户最外围的价值方才曾经提到了—— 在于把单机的劣势也就是单机的高性能、低成本与分布式的劣势可扩大的能力、高可用的能力齐全融入到一套零碎外面。 这样的一个系统对开发者是十分敌对的，咱们也选在这样一个工夫点跟大家来谈开发敌对的话题。 稳固牢靠，很多个0后面那个1首先，数据库有很多对开发者比拟有用的个性，十分弱小的性能、很好的性能，或者可能有一些十分乏味的个性。比方可能反对 Severless、多云原生，甚至能够跟 ChatGPT 联合。我认为对于开发者而言，对于数据库来讲，开发者最看中的个性永远是稳固、牢靠。我置信在座的很多开发者应该都或多或少有过早晨 12 点解决故障的经验，我用 “稳固牢靠” 作为明天分享的收场。 阿里巴巴的 DBA 团队有一句话，稳固牢靠是数据库这样的根底软件很多个 0 后面那个 1。 没有稳固牢靠，数据库有再多的性能性能都是没有任何意义的。OceanBase 在 2014 年把过后支付宝的交易业务由 Oracle 迁徙到 OceanBase，这是 OceanBase 第一个撑持的外围业务场景。我记得很长一段时间，其实咱们睡不着觉，放心呈现重大的生产事变。 ...

【前言】作为中国的 “Fivetran/Airbyte”, Tapdata 是一个以低提早数据挪动为外围劣势构建的古代数据平台，内置 60+ 数据连接器，领有稳固的实时采集和传输能力、秒级响应的数据实时计算能力、稳固易用的数据实时服务能力，以及低代码可视化操作等。典型用例包含数据库到数据库的复制、将数据引入数据仓库或数据湖，以及通用 ETL 解决等。 随着 Tapdata Connector 的一直增长，咱们最新推出《Tapdata Connector 实用指南》系列内容，以文字解析辅以视频演示，还原技术实现细节，模仿理论技术及利用场景需要，提供能够“珍藏跟练”的实用专栏。本期实用指南将以 Tapdata 新增数据源 Salesforce → MongoDB 为例，演示 Tapdata 可能为 SaaS 类数据源的数据同步需要提供怎么的反对。 CRM（Customer Relationship Management，客户关系治理）类软件的衰亡，源于企业对于客户关系治理的了解与需要。起初是市场竞争加剧，让企业开始意识到客户满意度和忠诚度对企业胜利至关重要。企业须要充沛理解客户偏好，并由此提供更好的产品和服务。而后随着销售流程的复杂化和业务数据的增长，为了进一步优化销售流程，进步销售效率和生产力，实现更好的客户沟通和合作，企业也开始更加依赖 CRM 软件作为企业治理的重要工具。 作为 CRM 软件的经典代表之一，Salesforce 通过将营销、销售、服务和 IT 团队整合到一个平台，胜利扭转了企业的运作形式。然而，在明天一直变动的数据环境中，想要仅凭 Salesforce “一己之力”来为企业取得最大价值未然远远不够。往往须要将其与一个表现出色的数据库或数仓联合起来，能力激发更弱小的剖析洞察力，促成企业效益持续增长。 同样亲密关注数据价值与 SaaS 产品的 Tapdata，作为自带 ETL 的实时数据平台，也透过社区看到了大量相干的数据迁徙需要，已于近日在产品层面实现了对 Salesforce 作为“源”的反对。 一、为什须要从 Salesforce 单兵作战走向组合牌诚然，Salesforce CRM 曾经为企业提供了一套相当全面的解决方案，包含销售自动化、客户服务、营销自动化和合作平台等，并由此帮忙企业优化客户关系治理、进步销售效率、增强合作与沟通，以及提供数据分析等性能，从而晋升企业的竞争力和业务水平。但并不能实用于所有企业的数据存储和解决需要，因此在独自应用时常会在以下几个方面受到掣肘： 数据量大时性能降落：当数据量达到肯定规模时，Salesforce 的性能可能会降落，导致响应工夫变慢，用户体验不佳；数据分析性能无限：Salesforce 的数据分析性能绝对较弱，不反对大规模数据分析和数据挖掘，对于须要进行深入分析的企业而言，会是个不小的麻烦；限度开发自定义利用：Salesforce 的自定义利用开发受限，须要应用特定的开发语言和框架，不够灵便，开发周期可能较长；访问量受定价模式限度：Salesforce 是按用户免费的，须要购买年度许可证能力开始应用。这样的定价模型可能会对拜访和应用数据产生限度，从而影响企业在数据分析和治理方面的能力。企业可能须要在管制老本和进步数据拜访灵活性之间进行衡量。因而，为了充分利用企业数据，能够思考将 Salesforce 和其余数据库或数据仓库联结应用，像是 MongoDB、BigQuery 等等，不仅能够无效解决上述问题，进步数据处理的效率和精度，通过将 Salesforce 中的数据整合到企业的数据生态系统中，还能实现更全面的数据分析、决策和利用，达到组合劣势。 以 MongoDB 为例大多数状况下，企业须要解决不同品种的数据，例如销售、客户关系、产品、员工和财务数据等。而 Salesforce 则次要用于治理客户关系和销售过程，因而并不能很好地满足企业在其余方面的数据处理需要。而 MongoDB 作为一个面向文档的 NoSQL 数据库，实用于解决半结构化和非结构化数据，且领有更好的扩展性和灵活性。二者联合能够为企业用户发明价值如下： ...

简述Db2 是一款具备悠久历史的关系型数据库，由 IBM 公司开发和保护，广泛应用于金融级业务场景。 CloudCanal 近期提供了 Db2 为源端的数据迁徙同步 性能，用户能够便当地将 Db2 中数据实时同步到其余数据库，实现数据更宽泛、更实时的利用。 性能介绍指标数据库和能力指标端数据源构造迁徙数据初始化增量同步数据校验数据勘误MySQL反对反对反对反对反对TiDB反对反对反对反对反对Kafka-反对反对--StarRocks反对反对反对反对反对Db2 源端特色能力基于 CDC 技术的数据同步Db2 源端同步能力是基于 SQL 复制的 ASN 捕捉代理，CloudCanal 通过捕捉 Db2 CDC 表中的增量数据来实现数据同步。 Db2 源端进行增量数据同步时，CDC 元信息表的保护过程会被自动化治理，无需用户手动操作。 同时，CloudCanal 会周期性地清理曾经同步到指标端的 CDC 记录，以防止 CDC 表的有限增长，从而保障同步数据的准确性和零碎的稳定性。 构造迁徙类型主动解决不同数据库对于数据类型反对存在差别，CloudCanal 构造迁徙时会进行类型主动转换。 Db2 为源端的构造迁徙也存在相似转换(5+，并一直细化)，如对端为 MySQL 或 TiDB，CloudCanal 将主动转换 VARCHAR FOR BIT DATA 为 VARBINARY。 数据初始化反对断点续传Db2 为源端的数据初始化，反对字符或数字类型主键表的断点续传性能。 对于亿级别数据量的大表，此能力不可或缺，数据初始化断点续传性能让此种暂停尽可能少的影响进度。 数据同步反对断点续传长周期的数据同步工作，暂停工作调整参数、修复问题数据、优化性能等状况很难防止，断点续传让这些保护操作变成可能。 CloudCanal 定时或定量保留提交后的位点(LSN，log sequence number)，确保增量同步工作重启后可持续，并且不失落数据。 配套数据校验与勘误能力在数据同步过程中，因为数据的内部关联性、构造束缚差别、数据库运维操作、软件bug等状况，两端数据可能会不统一，此时数据校验和勘误性能十分必要。 CloudCanal 为 Db2 为源端的数据同步能力额定提供了数据校验和数据勘误性能，疾速确定不统一数据范畴，并针对差别数据进行修复。 产品化能力撑持可视化创立CloudCanal 创立 Db2 数据迁徙同步工作是齐全可视化的，通过获取数据库元数据，让用户在 web 页面上决定哪些库、表、列进行迁徙同步，或者设定过滤条件、自定义数据处理逻辑等。 自动化流程Db2 数据迁徙同步工作创立后，CloudCanal 将主动流转各个阶段的工作，用户无需干预，中转数据实时同步状态。 ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。GreatSQL是MySQL的国产分支版本，应用上与MySQL统一。作者： JennyYu文章起源：GreatSQL社区投稿背景接到客户诉求说一条SQL长时间运行不出后果，让给看看怎么回事，SQL不简单，优化措施也不简单，然而要想SQL达到最优状态，也是须要通过一番考量并做出抉择的。上面借试验还原一下此SQL优化过程。 试验：数据库环境：MySQL5.7.39 测试表构造如下： mysql> show create table t_1\G*************************** 1. row *************************** Table: t_1Create Table: CREATE TABLE `t_1` ( `w_id` int(11) DEFAULT NULL, `w_name` varchar(10) DEFAULT NULL) ENGINE=InnoDB DEFAULT CHARSET=utf8mb41 row in set (0.00 sec)mysql> show create table t_2\G*************************** 1. row *************************** Table: t_2Create Table: CREATE TABLE `t_2` ( `i_id` int(11) NOT NULL, `i_name` varchar(24) DEFAULT NULL, `i_price` decimal(5,2) DEFAULT NULL, `i_data` varchar(50) DEFAULT NULL, `i_im_id` int(11) NOT NULL, PRIMARY KEY (`i_im_id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb41 row in set (0.00 sec)mysql> show create table t_3\G*************************** 1. row *************************** Table: t_3Create Table: CREATE TABLE `t_3` ( `s_w_id` int(11) NOT NULL, `s_i_id` int(11) NOT NULL, `s_quantity` int(11) DEFAULT NULL, `s_ytd` int(11) DEFAULT NULL, `s_order_cnt` int(11) DEFAULT NULL, `s_remote_cnt` int(11) DEFAULT NULL, `s_data` varchar(50) DEFAULT NULL, `s_dist_01` char(24) DEFAULT NULL, `s_dist_02` char(24) DEFAULT NULL, `s_dist_03` char(24) DEFAULT NULL, `s_dist_04` char(24) DEFAULT NULL, `s_dist_05` char(24) DEFAULT NULL, `s_dist_06` char(24) DEFAULT NULL, `s_dist_07` char(24) DEFAULT NULL, `s_dist_08` char(24) DEFAULT NULL, `s_dist_09` char(24) DEFAULT NULL, `s_dist_10` char(24) DEFAULT NULL, `t_2_id` int(11) DEFAULT NULL, `t_1_id` int(11) DEFAULT NULL, PRIMARY KEY (`s_w_id`,`s_i_id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb41 row in set (0.00 sec)Create Table: CREATE TABLE `t_4` ( `w_name` varchar(10) DEFAULT NULL, `s_i_id` int(11) NOT NULL, `s_quantity` int(11) DEFAULT NULL, `s_ytd` int(11) DEFAULT NULL, `s_order_cnt` int(11) DEFAULT NULL, `s_remote_cnt` int(11) DEFAULT NULL, `s_data` varchar(50) DEFAULT NULL, `t_2_id` int(11) DEFAULT NULL, `i_name` varchar(24) DEFAULT NULL, `i_price` decimal(5,2) DEFAULT NULL) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4其中t_1表25条记录，t_2表100条记录，t_3表500万条数据。我这里试验数据量少些，客户理论业务表数据量别离是（30，150，2700万）。t_4表为一个历史数据归档表，用于插入数据。 ...

MySQL创立表的时候能够不设置主键吗？MySQL创立表的时候是能够不被动设置主键的，然而表是肯定须要一个主键的，MySQL会被动将第一个不为null的惟一索引设置为主键 为什么MySQL举荐应用自增id作为主键？MySQL官网举荐不要应用uuid或者不间断不反复的雪花作为主键，而是应用间断自增的主键id应用自增id的内部结构自增id的值是程序的，所以innodb在索引B+树的叶子节点层面能够间接把每一条记录都存储在上一条记录的前面，当达到页面的最大填充因子的时候（页面容量曾经满了）下一条记录就会写入新的页中，数据依照这种程序的形式进行填充，主键页就会以近乎于程序的记录填满，晋升了页面的最大填充率，不会有页的节约新插入的行肯定会在原有的最大数据的下一行，这样MySQL定位和寻址十分快，不会因为计算而做出额定的耗费，并且可能缩小页决裂和碎片的产生页决裂：保障后一个数据页的所有行主键值比前一个数据页的主键值大，所以当ID不为自增的主键的时候，就会导致后一个页的所有行并不一定比前一个数据页的行的id大。这时就会触发页决裂的逻辑，对两个页之间的数据进行调整，底层就是树结构的调整，这个耗费是很大的，甚至会波及到多个数据页，导致性能升高应用自增id的毛病 他人一旦爬取你的数据库，就能够依据数据库的自增id获取到你业务的增长信息，从而剖析出经营状况对于高并发的负载，innodb在依照主键进行插入的时候会造成显著的锁争用，auto_increment锁机制会造成自增锁的抢夺，有肯定的性能损失为什么分布式系统不必自增id，而是要用雪花算法生成id分布式id创立的业务需要全局惟一趋势递增 innodb引擎的叶子结点是有序的双向链表，趋势递增能够减少性能，不会打乱树的构造信息安全最好蕴含工夫戳为什么自增id不适宜分布式系统？当数据宏大的时候，在数据库分库分表之后，数据库自增id不能满足惟一id来示意数据；因为每个表都依照本人的节奏自增，会造成id抵触，从而无奈满足需要应用auto_increment实现便宜的分布式惟一主键flickr有相似的计划，构建是一个专用的数据库服务器，下面只有一个数据库，在数据库外面有用于32位id和64位id的id表，id是auto自增的，所有数据库生成id都会向这个服务器发申请，而后服务器散发id上来，也能达到一种分布式惟一主键的成果相似于session-redis的思维，把所有的sessionid都存在redis外面，所有的服务器实例在比拟cookie的时候就先去redis外面比拟，这样就能防止因为负载平衡导致的cookie生效问题当然这个便宜的做法显然是有很大问题的并发量很小，因为只有一台服务器减少开销，并且整个申请流程变慢，因为须要向服务器发申请，并且是在硬盘层面进行操作的flickr服务器成了整个零碎的瓶颈和隐患，如果服务器宕机整个零碎间接崩掉了雪花算法是twitter开源的分布式id生成算法，后果是一个64位的longint类型，核心思想是用41位来作为工夫戳，10位来作为机器的id，12位作为毫秒内的流水号（意味着每个节点能够在每毫秒生成4096个id），最初还有一个符号为永远为0 长处● 齐全在内存生成，高性能高可用● 容量大，每秒能够生成几百万id● 趋势递增，插入数据库索引树的时候，性能比拟高毛病● 依赖零碎时钟的一致性，如果某台机器的零碎时钟回拨，有可能造成id抵触● 多台机器的ID只能保障趋势减少，即每一台机器都能保障这台机器生成的ID是在减少的，然而多台机器并不一定相对递增● 41位工夫戳只能保障69年无反复ID● 因为是64位的ID，在传递给前端的时候须要用字符串的类型进行传递，因为js的number类型最大只反对53位其余分布式ID计划● UUID:JAVA自带的API，生成一个唯一性的字符串，不能保障有序递增● UidGenerator:百度开源的分布式ID生成器，基于雪花算法● Leaf:美团开源的分布式ID生成器，能保障全局惟一，趋势递增，然而须要依赖关系数据库、Zookeeper等中间件本文由mdnice多平台公布

欢送拜访 OceanBase 官网获取更多信息：https://www.oceanbase.com/ 作者简介： 孙宏鑫，OceanBase技术专家，次要负责oceanbase开源生态，运维监控相干工作。 OceanBase 自开源以来随着用户的一直减少及应用场景的不断丰富，其部署状态逐步多元化，为了帮忙用户更流畅地在不同环境部署，本文将从体验场景和生产环境两方面别离介绍在主机、容器环境中如何部署OceanBase。 环境筹备家喻户晓，OceanBase 作为分布式数据库，以多正本的形式保证数据的可用性，在生产环境中至多要筹备3台机器，如果仅学习体验 OceanBase 的性能，应用1台机器部署单节点集群即可。 操作系统 OceanBase 反对部署在支流的Linux操作系统上，上面列出了罕用的操作系统： Redhat / CentOS 7.x/8.xSUSE / OpenSUSE 15.xAnlios 7.x/8.xDebian 9.xUbuntu 20.x主机资源 下表列出了部署OceanBase所需的单台主机的资源，如果须要集群部署，举荐应用雷同规格的主机。 我的项目资源大小阐明cpu2c生产环境举荐4c以上内存8G生产环境举荐16G以上磁盘内存的6倍以上举荐应用 SSD, 生产环境要配置多块磁盘，将日志盘和数据盘离开文件系统EXT4 戓 XFS当数据超过 16T 时，应用 XFS用户配置 OceanBase 能够应用任意有目录读写权限的用户进行部署，如果应用了多台主机，则要求这些主机应用雷同的用户和明码登录，或者配置同一个用户的免密登录，如果思考之后应用 OCP 接管部署的 OceanBase 集群，倡议应用 admin 用户进行部署。 时钟同步设置 分布式数据库产品是集群软件，对各个节点之间的工夫同步性有要求。OceanBase 要求所有节点之间的时间误差管制在 50ms 以内。理论生产环境为了稳定性和性能思考，倡议时间误差管制在 10ms 以内。通常只有节点配置工夫同步服务器跟公网工夫放弃同步即可。实际上在企业机房里，企业会有对立的工夫服务器跟机房提供的工夫服务器或公网工夫服务器同步，OceanBase 节点只须要跟机房对立的工夫服务器进行同步即可。 CentOS 或 RedHat 7.x 版本举荐应用 chrony 服务做工夫源。Chrony 是 NTP（Network Time Protocol，网络工夫协定，服务器工夫同步的一种协定）的另一种实现，与 ntpd 不同，它能够更快且更精确地同步零碎时钟，最大水平缩小工夫和频率误差。无关工夫同步技术请参考工夫同步产品官网介绍。 敞开防火墙 查看防火墙状态 systemctl status firewalld如果输入后果非 inactive, 能够通过如下命令进行敞开 ...

欢送拜访 OceanBase 官网获取更多信息：https://www.oceanbase.com/ 本文来自OceanBase社区分享，仅限交换探讨。原作者陈小伟。 我是陈小伟， 2019 年退出 OceanBase，目前负责 OceanBase 开发者核心的研发。 OceanBase ODC 这几年从一个数据库图形化客户端工具逐步变成一个面向协同开发场景的管控平台。我也看到这几年数据库行业内配套的开发工具也正好是有一些相似的变动，于是造成一个察看，数据库协同开发曾经成为趋势。 OceanBase ODC 这几年从一个数据库图形化客户端工具逐步变成一个面向协同开发场景的管控平台。咱们也看到这几年数据库行业内配套的开发工具也正好是有一些相似的变动，于是造成一个察看，数据库协同开发曾经成为趋势。 为什么？上面我会从三方面进行叙述。 另外在注释开始前，阐明一下本文我想跟大家聊四个局部：第一局部是数据库行业现状，毕竟作为数据库的开发工具，要解决的还是应用数据库的问题。在第二局部咱们从现状去看目前在数据库应用过程中有哪些挑战，以及说咱们的用户是如何去应答这些挑战的，这里也会蕴含蚂蚁团体是如何应答这些挑战的。第三局部咱们基于对国内市场、海内市场常见工具的察看得出结论。第四个局部会联合数据库行业的变动对趋势做进一步洞察。 数据增长带来一系列变动能够认为，近些年在数据管理畛域的很多挑战根本原因都能够归结到数据快速增长。 数据快速增长国内调研机构 IDC 公布的《数据时代2025》预测，寰球数据总量将从 2018 年的 33ZB 增至 2025 年的 175ZB，增长超过 5 倍，这里结构化数据大略占 10%。信通院的报告显示，中国数据库市场规模近几年放弃 25% 左右的年增长率。 外表上咱们看到的是数据存储规模在疾速减少，数据库市场规模在一直增长。 咱们服务的的用户场景有一些具体的例子： 某电商零碎应用 60 个节点的数据库集群，每个节点数据规模 20TB 左右，总数据规模超过 1PB；某金融零碎应用的数据库表数量达到 20W，列数量达到 400W；某金融零碎应用的分区数量达到 100W；某制造业零碎应用的 PL 程序包数量达到 4K个；从数据库开发者的视角来看，或者说从数据库开发工具的视角来看，咱们其实看到的是这背地数据库的实例数量，数据库实例内存储的对象的数量，应用数据库的业务零碎的数量，以及说数据库厂商的数量，数据库从业人员数量 都是在一直的增长。那咱们晓得变动这个事件啊，质变逐步逐步的是会产生量变的。数据库这个应用过程当中啊随同着上述的诸多变动，而其实就带来了诸多的一些问题，实际上能够认为， 近些年在数据管理畛域的很多挑战根本原因都能够归结到数据快速增长。 数据库是稳定性基石数据快速增长，数据库稳定性问题导致的故障也越来越重大。 这里咱们看几个具体的例子： 1、2016年，某社交网络应用的一名工程师在批改一条 SQL 查问时犯了一个谬误，导致了该公司的服务在寰球范畴内停机。该谬误导致了数据库中某些表的数据无法访问，最终导致了整个零碎的故障。 2、2017年，某电商企业曾因一次故障而导致其 S3 服务在美国东部地区停机。预先考察发现，该故障是由一个谬误的删除指令引起的，这个指令原本只想删除一小部分数据，但因为编写了烂 SQL，后果导致了整个数据中心的数据失落。 3、2018年，某云厂商的云存储服务呈现了一个故障，导致一些客户的数据无法访问。考察后发现，这是因为一个工程师在批改数据库的查问语句时犯了一个谬误，导致了整个服务呈现了故障 这几个例子是 ChatGPT帮我找的，我其实也问了中国大陆地区的状况，然而 ChatGPT的回复是也有很多例子，然而不可能通知我具体的公司名称，看来目前还是很爱护中国大陆厂商的体面的，这背地不晓得是否有团队在帮忙做一些工作。 实际上这些例子咱们去看，比方 烂 SQL 导致的零碎不稳固，在数据规模不大的时候都不成为问题。然而目前的趋势就是数据规模越来越大，这个时候数据库作为保障信息系统稳定性的重要兜底安装，身上的担子就越来越重了。 ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。GreatSQL是MySQL的国产分支版本，应用上与MySQL统一。作者： 杨延昭文章起源：GreatSQL社区投稿在进行数据库备份的时候次要分为了逻辑备份和物理备份这两种形式。在数据迁徙和备份复原中应用mysqldump将数据生成sql进行保留是最罕用的形式之一。 本文将围绕着mysqldump的应用，工作原理，以及对于InnoDB和MyISAM两种不同引擎如何实现数据一致性这三个方面进行介绍。 一.mysqldump 简介mysqldump是MySQL自带的逻辑备份工具。它的备份原理是通过协定连贯到 MySQL数据库，将须要备份的数据查问进去，将查问出的数据转换成对应的insert语句，当咱们须要还原这些数据时，只有执行这些insert语句，即可将对应的数据还原。二.备份的命令2.1命令的格局1.mysqldump [选项] 数据库名 [表名] > 脚本名2.mysqldump [选项] --数据库名 [选项 表名] > 脚本名3.mysqldump [选项] --all-databases [选项] > 脚本名2.2选项阐明参数名缩写含意--host-h服务器IP地址--port-P服务器端口号--user-uMySQL 用户名--pasword-pMySQL 明码--databases 指定要备份的数据库--all-databases 备份mysql服务器上的所有数据库--compact 压缩模式，产生更少的输入--comments 增加正文信息--complete-insert 输入实现的插入语句--lock-tables 备份前，锁定所有数据库表--no-create-db/--no-create-info 禁止生成创立数据库语句--force 当呈现谬误时依然持续备份操作--default-character-set 指定默认字符集--add-locks 备份数据库表时锁定数据库表三.还原的命令3.1零碎行命令mysqladmin -uroot -p create db_name mysql -uroot -p db_name < /backup/mysqldump/db_name.db注：在导入备份数据库前，db_name如果没有，是须要创立的； 而且与db_name.db中数据库名是一样的才能够导入。3.2source形式mysql > use db_name;mysql > source /backup/mysqldump/db_name.db;四.mysqldump实现的原理4.1备份流程如下1.调用FWRL（flush tables with read lock）,全局禁止读写2.开启快照读，获取此期间的快照（仅仅对innodb起作用）3.备份非innodb表数据（*.frm,*.myi,*.myd等）4.非innodb表备份结束之后，开释FTWRL5.逐个备份innodb表数据6.备份实现 4.2执行mysqldump，剖析备份日志# 执行语句[root@localhost backup]# mysqldump -uroot -proot -h127.0.0.1 --all-databases --single-transaction --routines --events --triggers --master-data=2 --hex-blob --default-character-set=utf8mb4 --flush-logs --quick > all.sqlmysqldump: [Warning] Using a password on the command line interface can be insecure.[root@localhost ~]# tail -f /var/lib/mysql/localhost.log第一步： FLUSH /*!40101 LOCAL */ TABLES# 这里是刷新表第二步： FLUSH TABLES WITH READ LOCK# 因为开启了--master-data=2，这时就须要flush tables with read lock锁住全库， 记录过后的master_log_file和master_log_pos点 这里有一个疑难？ 执行flush tables操作，并加一个全局读锁，那么以上两个命令貌似是反复的， 为什么不在第一次执行flush tables操作的时候加上锁呢？ 简而言之，是为了防止较长的事务操作造成FLUSH TABLES WITH READ LOCK操作迟迟得不到 锁，但同时又阻塞了其它客户端操作。 第三步： SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ# --single-transaction参数的作用，设置事务的隔离级别为可反复读， 即REPEATABLE READ，这样能保障在一个事务中所有雷同的查问读取到同样的数据， 也就大略保障了在dump期间，如果其余innodb引擎的线程批改了表的数据并提交， 对该dump线程的数据并无影响，然而这个还不够，还须要看下一条第四步： START TRANSACTION /*!40100 WITH CONSISTENT SNAPSHOT */# 获取以后数据库的快照，这个是由mysqldump中--single-transaction决定的。# WITH CONSISTENT SNAPSHOT可能保障在事务开启的时候，第一次查问的后果就是 事务开始时的数据A，即便这时其余线程将其数据批改为B，查的后果仍然是A。简而言之，就是开启事务并对所有表执行了一次SELECT操作，这样可保障备份时， 在任意工夫点执行select * from table失去的数据和 执行START TRANSACTION WITH CONSISTENT SNAPSHOT时的数据统一。 【留神】，WITH CONSISTENT SNAPSHOT只在RR隔离级别下无效。第五步： SHOW MASTER STATUS# 这个是由--master-data决定的，记录了开始备份时，binlog的状态信息， 包含MASTER_LOG_FILE和MASTER_LOG_POS这里须要特地辨别一下master-data和dump-slavemaster-data:--master-data=2示意在dump过程中记录主库的binlog和pos点，并在dump文件中正文掉这一行；--master-data=1示意在dump过程中记录主库的binlog和pos点，并在dump文件中不正文掉这一行，即复原时会执行；dump-slave--dump-slave=2示意在dump过程中，在从库dump，mysqldump过程也要在从库执行， 记录过后主库的binlog和pos点，并在dump文件中正文掉这一行；--dump-slave=1示意在dump过程中，在从库dump，mysqldump过程也要在从库执行， 记录过后主库的binlog和pos点，并在dump文件中不正文掉这一行； 第六步： UNLOCK TABLES# 开释锁。五.mysqldump对InnoDB和MyISAM两种存储引擎进行备份的差别。5.1对于反对事务的引擎如InnoDB，参数上是在备份的时候加上 –single-transaction 保证数据一致性–single-transaction 实际上通过做了上面两个操作 ：① 在开始的时候把该 session 的事务隔离级别设置成 repeatable read ；② 而后启动一个事务（执行 begin ），备份完结的时候完结该事务（执行 commit ）有了这两个操作，在备份过程中，该 session 读到的数据都是启动备份时的数据（同一个点）。能够了解为对于 InnoDB 引擎来说加了该参数，备份开始时就曾经把要备份的数据定下来了，备份过程中的提交的事务时是看不到的，也不会备份进去。5.2对于不反对事务的引擎如MyISAM，只能通过锁表来保证数据一致性，这里分两种状况：1）导出全库：加 –lock-all-tables 参数，这会在备份开始的时候启动一个全局读锁 （执行 flush tables with read lock），其余 session 能够读取但不能更新数据， 备份过程中数据没有变动，所以最终失去的数据必定是完全一致的；2）导出单个库：加 –lock-tables 参数，这会在备份开始的时候锁该库的所有表， 其余 session 能够读但不能更新该库的所有表，该库的数据统一；Enjoy GreatSQL :) ...

欢送拜访 OceanBase 官网获取更多信息：https://www.oceanbase.com/ 近日，北京奥星贝斯科技有限公司（OceanBase 数据库）在取得 ISO9001、ISO14001、ISO45001 及 ISO27001 等认证后，又于技术服务方面通过了 ISO20000 认证和 ITSS 认证。 这标记着 OceanBase 数据库建设的信息技术服务管理体系合乎以下规范： 《ISO/IEC 20000-1:2018 规范》、《信息技术服务 运行保护 第1局部通用》（GB/T 28827.1-2012）、《信息技术服务 运维保护服务能力成熟度模型》（ITSS.1-2015）。 再获认可的“服务管理体系”作为第一部针对信息技术服务治理畛域的国际标准，ISO20000 为 IT 管理者定义了一套全面的、与企业严密相干的 IT 服务管理体系的参考模型，该规范更加着重于基于服务生命周期办法进行合乎性评估，更加强调高质量服务的治理，充分说明了在信息技术时代信息安全、危险和机会治理及服务生命周期更加要求翻新多变、与时俱进、一直迭代改良。 OceanBase 作为自研原生分布式数据库，其产品的运维及售后服务笼罩每一个我的项目的全生命周期，从调研、设计、交付、上线验收到最初的售后服务，都有技术专家及时提供响应反对、全方位保障客户无忧。 全我的项目周期服务保障，及时响应客户需要ITSS 是我国第一套成体系和综合配套的信息技术服务规范库，全面标准了 IT 服务产品及其组成因素，用于领导施行标准化和可信赖的 IT 服务。此次 OceanBase 取得的是运维服务能力等级三级证书。 始终以来，OceanBase 提供一套欠缺的服务体系。包含交付服务、运维服务、测试服务、迁徙服务、架构咨询服务、客户胜利服务以及培训认证服务等，为客户提供超 7 大类 31小类的 全方位笼罩、全生命周期保障 的专家服务。同时提供笼罩寰球 7*24 小时及时响应的近程技术支持服务，遍布全国的分级疾速到场服务和蕴含三方凋谢生态搭档在内的全面交付运维等服务。 在规范服务能力根底上，OceanBase 为客户提供金钥匙服务，联合客户技术团队和理论业务零碎运行状况，以被动服务的模式手把手传递分享数据库应用运维教训和最佳实际，以共创模式帮忙客户落地 OceanBase SRE 体系，在体验 OceanBase 弱小能力的同时，真正做到安稳顺滑和安心可控。 OceanBase 潜心打磨 13 载，将来 OceanBase 也将保持长期主义，继续加强技术服务能力，标准服务流程，为客户提供高水平、高质量、高牢靠和可信赖的优质化的服务体验，助力客户业务倒退稳固牢靠，成为用户可信赖的数据底座。 欢送拜访 OceanBase 官网获取更多信息：https://www.oceanbase.com/

作者：京东批发 梁强1、背景这篇次要形容了B端令牌零碎利用数据分表解决业务数据量增大，且存在的数据歪斜问题，次要面向的场景是一对多数据歪斜问题 1）B令牌的业务背景先简述一下B令牌的业务背景，B令牌零碎是用于营销场景中，将许多用户绑定在一个令牌上，再将令牌绑定在促销上，从而实现差别和精准营销，个别状况下一个令牌的生命周期等同于这个促销。 2）B端令牌的构造现状令牌和令牌用户关系是一个一对多的关系，晚期的令牌零碎应用jed分库，2个分片，两头进行了一次扩容达到了8个分片，存储的数据行数达到了1.2亿 3）数据和业务现状 1.2亿数据，散布在8个分库中，每个分库均匀1500万，但因为分库字段应用的是令牌ID(token_uuid)，有得令牌用户少，只有几千到一万，有的令牌用户多，有100万到150万，令牌总数量并不多，只有2万左右，所以导致数据存在歪斜，有的分库有3000多万数据，有的分库可能只有几百万，这曾经开始导致数据库读写性能降落。而又因为令牌用户关系表数据结构很简略，尽管数据行数很多，但占用的空间却不大。8个分库总占用量还有余20G。同时令牌的生命周期根本和促销雷同，一个令牌服务于一个或几个促销后，就会缓缓过期被弃之不必，后续会持续创立新的令牌。所以这些过期令牌是能够进行归档的。 同时因为B端业务的倒退，业务诉求也更多，和业务沟通中理解到，将来会上线主动选人零碎，由零碎主动创立令牌，并抉择适宜促销的人群，将来每个月数据增量在3000万左右，如果运行一年就会减少3.6亿，届时单表数据量均匀会达到6000万，以后的设计架构曾经齐全不能满足业务需要。 同时目前也存在依据令牌ID分页查问令牌下用户的性能，但仅限于给治理端经营应用，应用也不频繁。 2、解决方案的思考1) 怎么解决这个问题面对日益降落的数据库读写性能，以及业务增长的需要，当下面临以下几个问题： 如何解决单表数据行数过多的问题以后分库计划存在比较严重的数据歪斜如果应答将来数据的增长2) 技术计划调研和比照a.数据库分表个别状况应答第一个问题，通常都是分库分表，而当下咱们曾经是8个分库，而且8个分库才占用了有余20G空间，单库资源节约重大，所以齐全不会思考持续减少分库的形式，所以分表才是解决办法。 数据分表通常有两种形式：垂直分表和程度分表。 垂直分表指的是将数据的列进行拆分，而后利用主键或其余业务字段进行关联，从而升高单表数据占用空间，或缩小冗余存储，B令牌的场景数据结构简略，数据占用空间小，所以不会应用该分表形式。 程度分表指的是将数据的行以一种路由算法拆分到多张表中，读取时候也基于这种路由算法来读取数据，这种分表策略个别用来应答数据结构不简单，但数据行特地多的场景。这也是咱们行将应用的形式。应用这种形式须要思考的就是如何设计路由算法，这里也是应用这种形式来分表。 b.路由算法数据分表路由算法的应用在业内也有多种，一种是利用一致性hash，抉择适合的分表字段，对字段值hash后值是固定的，应用该值通过取模或者按位运算的形式失去一个固定的序号，从而确定数据存储在哪张表中。 比拟常见的利用如分库大多就是应用一致性hash的形式，通过即时计算分库字段的值判断数据属于哪个分库从而决定将数据存入哪个分库或者从哪个分库读取数据。而如果查问时没有指定分库字段则须要同时向所有分库收回查问申请，最初在汇总后果。 另外像java代码的HashMap数据结构其实也是一种一致性hash算法的分表策略，通过对key进行hash后决定将数据存入数组的哪个序号，HashMap外面用的不是取模的形式获取序号，而是应用按位运算的形式，应用这种形式也决定了HashMap的扩容都是依照2的x次方的大小进行扩容，当前有机会能够介绍这个原理。 下面就是HashMap中的一个简化的数据Hash存储过程，当然我省略了一些细节，比方HashMap中每一个节点都是一个链表（抵触过多还会变成红黑树）。利用在咱们的场景中就能够将每个序号当成是一张数据表即可。 以上这种路由算法的长处的路由策略简略，实时计算也不必减少额定存储空间，但也存在一个问题就是如果要扩容则须要将历史数据从新hash一遍进行迁徙，比方数据库分库如果减少分库则须要将所有数据从新计算分库，HashMap扩容也会执行rehash从新计算key在数组的序号。如果数据量太大，这种计算过程耗时将会很长。同时，如果数据表太少，或者抉择分片的字段离散水平低都会导致数据歪斜。 还有一种分表算法优化了这种rehash过程，这便是一致性hash环，这种形式是在实体节点之间形象出很多虚构节点，而后再利用一致性hash算法将数据打在这些虚构节点上，而每个实体节点其实是负责的该实体节点逆时针方向上和另一个实体节点相邻的虚构节点的数据。这种形式的益处是如果须要扩容减少节点，减少的节点放在环上任意地位，也只会影响到该节点顺时针方向上相邻节点的数据，只须要将该节点中的局部数据迁徙到这个新节点上即可，大大降低rehash的过程。同时因为虚构节点多，也能够减少让数据更平均的散布在这个环上，只有将实体节点搁置在适合的地位，就能最大水平保障的解决数据歪斜问题。 比方图上就是一个一致性Hash环的hash过程，在整个环上有从0到2^32-1个节点，其中实线的就是实在节点，其余都是虚构节点，张三通过hash后落到环上的虚构节点，而后从虚构节点的地位顺时针寻找实在节点，最终数据就存储在实在节点上，所以疯驴子和李四就存储在节点2上，王五在节点3上，郑六在节点4上。 扩容了一个节点5号后，则须要将节点1和节点5之间的数据迁徙到节点5上，其余节点数据则不必变更。但如图上看到的，只加这一个节点，也容易导致每个节点负责的数据不平均，比方节点2和节点5，相比于其余节点负责的数据就少了很多，所以扩容时最好是成倍扩容，这样数据能够持续放弃平均。 3) 思考我的计划再回到B令牌的业务场景上来，须要能达成以下诉求 首先必须应用程度分表来解决单表数据量过大的问题须要能反对依据令牌分页查问用户因为以后业务数据增量在3000万，但不排除将来业务持续增长的可能，分表数量须要能反对将来扩大数据行数过高，将来在扩大时必须保障无需数据迁徙或者数据迁徙成本低须要解决数据歪斜问题，确保不因为单表数据量过大而导致整体性能升高基于以上诉求，首先看问题b，如果要反对依据令牌分页查问用户，就须要保障令牌下的所有用户都在同一张表上，能力简略的反对分页查问，否则用一些汇总归并算法则复杂程度过高了，而且表太多也会升高查问性能。尽管也能够通过将数据异构es提供查问性能，但仅仅是为了大量治理端的查问诉求再进行数据异构，老本有些高收益并不显著，也有些浪费资源。所以分表字段就只能确定应用令牌ID。 而下面也提到令牌ID数量并不多，而且令牌下的用户也从1万到100万不等，单纯应用一致性hash的形式用令牌ID作为分表策略则会导致数据歪斜重大，而且将来扩容时数据迁徙老本也很高。 但应用一致性hash环又会导致将来在扩容时最好是按2的倍数扩容，不然就会存在有的节点负责的虚构节点多，有的节点负责虚构节点少，导致数据不平均。然而在和数据库共事进行沟通，一个数据库下的数据表数量不宜太多，否则会对数据库带来较大压力，而一致性hash环这种形式可能扩两三次容就会导致分表数达到一个很高的数值。 基于以上问题，在确定应用令牌id作为分表的前提下，就须要着重思考如何反对动静扩容和解决数据歪斜的问题。 3、计划落地1) 计划概述a.如何反对动静扩容分表的字段曾经确定应用令牌ID，而后面也提到咱们的数据结构是令牌和用户是一对多的关系数据，那么在创立令牌时hash出的分表序号存储下来，后续基于存储的分表序号进行路由，就能够保障将来扩容时也不会影响存量数据的路由，无需进行数据迁徙。 b.如何解决数据歪斜因为选用了令牌ID作为分表字段，而各令牌数据量大小不一，数据歪斜就会是一个大问题。所以这里就想方法引入了一个分表水位的概念。 在用户申请保留或删除关系用户数的时候，基于分表序号对以后分表数量进行一个增减的计数，当某个分表中的数据量处于高水位时，就将该分表从分表算法中剔除，从而让该分表不会持续产生新的数据。 比方当设置阈值1000万为高水位，因为以上5张表都没有达到高水位，则创立令牌时依据令牌ID进行Hash后取模失去3，按程序获取表，则以后令牌的分表号为b2b\_token\_user_3。后续关系数据都从该表中获取。 运行一段时间后，表b2b\_token\_user\_1数据量曾经增长到了1200万，超过了1000万的水位，这时候在创立令牌则将该表移除，在此进行Hash后取模失去1，则以后分到的表就是b2b\_token\_user\_2。而如果b2b\_token\_user_1的水位如果始终不能降下来，则该表后续都不会再参加分表，表中的数据量也不会再减少。 当然有一种可能就是所有表都进入了高水位，为了兜底，这时水位性能就生效，所有表都退出到分表中来。 c.定期数据归档，升高分表水位如果表中的数据量只会一直减少，而不会缩小的话，那么早晚所有的表都会达到高水位，这就不能达到动静的成果。下面背景中有提到，令牌创立后是为某一批促销服务，促销终止后，令牌也会失去作用，同时令牌上也有有效期，超过有效期的令牌也会失去作用。所以定期对数据进行归档就能够让那些处于高水位的表把水位缓缓降下来，重新加入到分表中。 而且以后令牌曾经存在了一张b2b\_token\_user的表，外面的数据曾经有1.2亿，能够将该表作为图上的0号表，这样在第一次上线时只有将历史令牌都的分表序号都记为0即可，存量数据就不须要再进行迁徙，而该表数据量水位高，也不会参加分表。再搭配定期的数据归档，该表的水位也会缓缓将下来。 d.监控机制尽管能够通过定期进行数据归档，能够让表的水位降下来，但随着业务倒退，可能会存在大多数表都进入了高水位，并且都是无效数据的状况。这时候零碎就会像HashMap判断容量达到75%就主动扩容一样，咱们不可能主动创立表，但当75%的表都进入高水位能够告警进去，开发人员监听到告警人工染指，察看是须要调高水位，还是进行表的扩容。 3) 有余• 水位阈值和扩容监控 目前水位的阈值还是依附人工手动设置，应该设置多大还是比拟理性的，只能设置一个，在告警当前适当调整。不过其实能够在零碎中主动监控接口读写性能的稳定，发现大多数表白到高水位时，接口读写性能都没有显著变动，能够零碎主动调高阈值，从而造成智能阈值。 而接口性能读写呈现显著变动时发现大多数表都达到了阈值，则能够告警提醒该当思考扩容。 4、总结解决问题素来没有银弹，咱们须要利用手里的技术手段和工具，进行组合、适配，使之适宜咱们当下的业务和场景，没有好或不好，只有适不适宜。

欢送拜访 OceanBase 官网获取更多信息：https://www.oceanbase.com/ 作者简介： 谢志刚，OceanBase 管控平台（OCP）技术负责人，主持 OCP 的整体研发工作。在云计算及数据库畛域深耕多年，对数据库管控、数据库自动化运维、数据库多云部署等方向具备粗浅的了解和丰盛的实践经验。 在 OceanBase 开源后，为了帮助用户更加高效地治理 OceanBase 集群，升高用户对 OceanBase 的学习老本及企业的 IT 运维老本，咱们推出了社区版 OCP（OceanBase Cloud Platform），为用户提供了 OceanBase 集群的图形化治理能力，包含数据库组件及相干资源（主机、软件包等）的全生命周期治理、备份复原、监控告警等。这样一来，用户可能实时把握 OceanBase 的运行动静，并将 DBA 从繁冗的运维工作中解放出来。 然而，随着业务摸索的不断深入和最佳实际的一直积攒，OCP 也遇到了更多场景的挑战。 社区版 OCP 定位于数据库集群的治理平台，面向规模化治理场景，对于单集群、小规模集群以及集体开发者不太敌对。对于集体开发者来说，如果要体验 OCP 的治理能力，须要付出肯定老本。因为 OCP 是中心化部署的，因而须要独自的机器进行装置，且部署和运维都有肯定门槛。并且为了实现平台级性能，OCP 对资源占用的要求也较高。因而，对于单集群、小规模集群、集体开发者来说，社区版 OCP 在可获得性、易用性上较难满足要求。 为了解决在社区场景下用户对 OceanBase 图形化治理的可获得性和易用性问题，咱们 在保留并继承了 OCP 原有体验和根底能力的前提下，推出了 OCP Express ，能够帮忙用户更好的治理 OceanBase 数据库。在满足数据库根底治理和数据库可观测性的同时， 大幅升高了 OceanBase 数据库图形化治理的应用门槛和总领有老本 。本文将和大家分享 OCP Express 的架构特点、要害能力、装置部署、利用场景，以及一些常见问题。 一、以极小资源耗费部署于任一节点的OCP ExpressOCP Express 是一个基于 Web 的 OceanBase 4.x 轻量化管理工具，作为 OceanBase 数据库的工具组件，它集成在 OceanBase 数据库集群中，反对数据库集群要害性能指标查看及根本数据库根底治理性能。OCP Express 源自于 OceanBase 云平台（OceanBase Cloud Platform，OCP）， 在保留外围能力的根底上，调整了整体的性能布局，给予用户全新的应用体验。 同时，OCP Express 的性能配置也进一步调整，可能以极小的资源耗费部署在任意一台数据库节点上。从而使 OCP Express 用户 以最小的老本，获取全新的 OceanBase 4.x 管控体验。 通过 OCP Express，用户能够执行根底的 OceanBase 数据库治理工作，例如创立或变更租户、治理数据库及用户等，还能够查看无关 OceanBase 数据库的监控、性能、诊断、日志等信息。OCP Express 的特点参考图1。 ...

导读： 传统行业面对数字化转型往往会遇到很多艰难，比方不足数据管理体系、数据需要开发流程简短、烟囱式开发、过于依赖纸质化办公等，美联物业也有遇到相似的问题。本文次要介绍美联物业基于 Apache Doris 在数据体系方面的建设，以及对数据仓库搭建教训进行的分享和介绍，旨在为数据量不大的传统企业提供一些数仓思路，实现数据驱动业务，低成本、高效的进行数仓革新。 作者｜美联物业数仓负责人 谢帮桂 美联物业属于香港美联团体成员，于 1973 年成立，并于 1995 年在香港联结交易所挂牌上市(香港联交所编号:1200)，2008 年美联工商铺于主板上市（香港联交所编号:459）， 成为领有两家上市公司的地产代理企业。领有 40 余载房地产销售行业教训，业务涵盖中、小型住宅、豪宅及工商铺，提供移民参谋、金融、测量、按揭转介等服务，业务遍布中国香港地区、中国澳门地区和中国边疆等多个重要城市。 本文次要介绍对于美联物业在数据体系方面的建设，以及对数据仓库搭建教训进行的分享和介绍，旨在为数据量不大的传统企业提供一些数仓思路，实现数据驱动业务，低成本、高效的进行数仓革新。 思考隐衷政策，本文不波及公司任何具体业务数据。 业务背景美联物业早在十多年前就已深刻各城市发展房地产中介业务，数据体系的建设和倒退与大多数传统服务型公司相似，经验过几个阶段期间，如下图所示。 咱们的数据来源于大大小小的子业务零碎和部门手工报表数据等，存在历史存量数据宏大，数据结构多样简单，数据品质差等普遍性问题。此外，晚期业务逻辑解决少数是应用关系型数据库 SQL Server 的存储过程来实现，当业务流程稍作变更，就须要投入大量精力排查存储过程并进行批改，应用及保护老本都比拟高。 基于此背景，咱们面临的挑战能够大抵演绎为以下几点： 不足数据管理体系，统计口径对立，已有数据无奈降本复用。多部门、多零碎、多字段，命名随便、表违反范式构造凌乱；对同一业务起源数据无奈做到多份报表复用，重复在不同报表编写同一套计算逻辑。海量数据下性能有余，查问响应慢。历史大多数业务数据存储在关系型数据库中，分表分库已无奈做到上亿数据秒级剖析查问。数据需要开发流程简短、烟囱式开发。每当业务部门提出一个数据需要，数据开发就须要在多个零碎之间进行数据兼容编写存储过程，从而导致存储过程的可移植性和可读性都十分差。部门之间重大依赖文本文档解决工作，效率低下。因为长期的手工统计，用户已造成习惯，导致对信息系统的信赖水平也比拟低。晚期架构针对上述的⼏个需要，咱们在平台建设的初期选⽤了 Hadoop、Hive、Spark 构建最后的离线数仓架构，也是比拟广泛、常见的架构，运作原理不进行过多赘述。 咱们数据体系次要服务对象以外部员工为主，如房产经纪人、后勤人员、行政人事、计算机部门，房产经纪在全国范畴内散布宽泛，也是咱们的次要服务对象。以后数据体系还无需面向 C 端用户，因而在数据计算和资源方面的压力并不大，晚期基于 Hadoop 的架构能够满足一部分根本的需要。然而随着业务的一直倒退、内部人员对于数据分析的复杂性、剖析的效率也越来越高，该架构的弊病日益越发的显著，次要体现为以下几点： 过于轻便：传统公司的计算量和数据量并不大，应用 Hadoop 过于节约。效率低下：T+1 的调度时效和脚本，动辄须要破费 1 小时的计算工夫导入导出，效率低、影响数据的开发工作。保护老本高：组件过多，排查故障链路过长，运维老本也很高，且部门共事之间相熟各个组件须要大量学习和沟通老本。新数仓架构基于上述业务需要及痛点，咱们开始了架构降级，并心愿在这次降级中实现几个指标： 初步建设数据管理体系，搭建数据仓库。搭建报表平台和报表疾速开发流程体系。实现数据需要可能快速反应和交付（1小时内），查问提早不超过 10s。最小老本准则构建架构，反对滚动扩容。技术选型通过调研理解以及敌人举荐，咱们理解到了 Apache Doris ，并很快与社区获得了分割，Apache Doris 的几大劣势吸引了咱们： 足够简略 美联物业及大部分传统公司的数据人员除了须要实现数据开发工作之外，还须要兼顾运维和架构布局的工作。因而咱们抉择数仓组件的第一准则就是"简略"，简略次要包含两个方面： 应用简略：Apache Doris 兼容 MySQL 协定，反对规范 SQL，有利于开发效率和共识对立，此外，Doris 的 ETL 编写脚本次要应用 SQL进行开发，应用 MySQL 协定登陆应用，兼容少数 MySQL 语法，提供丰盛的数据分析函数，省去了 UDF 开发工作。架构简略：Doris 的组件架构由 FE+BE 两类过程组成，不依赖其余零碎，降级扩容十分不便，故障排查链路十分清晰，有利于运维老本的升高。极速性能 Doris 依靠于列式存储引擎、主动分辨别桶、向量计算、多方面 Join 优化和物化视图等性能的实现，能够笼罩泛滥场景的查问优化，海量数据也能能够保障低提早查问，实现分钟级或秒级响应。 ...

为了帮忙大家及时理解中国数据库行业倒退现状、梳理以后数据库市场环境和产品生态等状况，从2022年4月起，墨天轮社区行业剖析钻研团队出品将继续每月为大家推出最新《中国数据库行业剖析报告》，继续流传数据技术常识、致力促成技术创新与行业生态倒退，目前已更至第十一期，并公布了共计122页的2022年度剖析报告。3月《中国数据库行业剖析报告》已正式公布（点击即可跳转，欢送大家下载查阅），本期报盘点了墨天轮“中国数据库风行度排行”、产品投融资等业内资讯以及相干政策讲话，以此出现以后数据库行业前沿动静与政策引领现状。 本月报告详尽展现SQL技术的起源演进、技术要点与发展趋势，重点解析NL2SQL实现原理、利用场景及挑战趋势。最初，精选几款国内外典型的NL2SQL利用产品与模型作为案例，介绍其工作原理、性能等个性。望为大家摸索NL2SQL如何充当智能接口、实现人与数据库的多元交互带来倡议和启发。 一、数据库排行榜及前沿动静 本章节目录 3月中国数据库风行度排名剖析2023年3月的墨天轮中国数据库风行度排行榜共260个数据库参加排名，榜单前十用一句话能够概括为：榜单前八较上月岿然不动，GBase奋勇向前重返第九。在本月排行榜前三中，OTO组合曾经间断四月持重开局，TOP3顺次是OceanBase、TiDB和openGauss，且前三甲均为开源数据库，这表明开源给数据库产品带来更多的生机，风行度也随之水涨船高。此外，GBase凭借多年积淀反超AnalyticDB以第九名亮相。 本月排行榜十名之后，有一些数据库产品在排名上较上月有了显著的晋升，诸如亚信科技旗下企业级数据库产品AntDB本月排名回升一位至第12名；火山引擎的剖析型数据库产品ByteHouse排名较上月回升55个位次至第27名；Kyligence本月排名较上月晋升47个位次至第32名等。 数据库行业倒退动静为帮忙大家对以后数据库行业最新政策有更深刻的理解，本次报告特梳理了2022年至今习主席对于信创倒退的相干重要讲话，并对3月7日颁布的组建国家数据局相干事宜进行了具体整顿。此外，展现了国内市场要闻资讯，诸如数仓巨头Teradata退出中国市场、中国软件终止对易鲸捷3.89亿增资认购、InfluxDB厂商实现5100万美元E轮融资等，此处因篇幅所限仅截选局部内容，具体内容可查阅报告。 二、SQL技术倒退历程回顾 本章节目录 SQL的历史能够追溯到1970年，IBM公司的Edgar Codd发表了将数据组成表格的利用准则（Codd’s Relational Algebra）。20世纪70年代末，Codd零碎的雏形建成，并且诞生了结构化查询语言SQL，1979年ORACLE公司首先提供商用SQL，IBM公司在DB2和SQL/DS数据库系统中也实现了SQL，从此大家开始宽泛应用SQL与数据库进行交互。 以后，SQL曾经在数据库中失去了宽泛的利用，并获得了重大进展。本章节具体介绍了SQL技术的起源演进、根本概述、执行原理与技术要点，同时也梳理了其所面临的挑战与自动化、智能化与安全性等将来发展趋势。受篇幅所限此处仅展现局部内容。 以后，SQL技术面临的挑战包含众厂商SQL不兼容、无奈辨认简单的句子和推理、当解决大规模数据时SQL查问性能降落、须要反对多种数据类型以及面临着歹意攻打和黑客攻击的威逼等等。为了应答这些挑战同时升高用户的应用老本，进步工作效率，SQL在将来将出现自动化、智能化发展趋势，同时将更加晋升在安全性方面的反对。报告对挑战与将来发展趋势均进行了详细分析，欢送大家查阅报告。 三、NL2SQL交互技术解析 本章节目录 以后，大量信息存储在结构化和半结构化知识库中，对于这类数据的剖析和获取须要通过SQL等编程语言与数据库进行交互操作，但SQL的应用难度限度了非技术用户，给数据分析和应用带来了较高的门槛。人们迫切需要技术或工具实现自然语言与数据库的交互，因而诞生了NL2SQL工作。早在20世纪中后期，人们就曾经开始尝试通过自然语言间接拜访数据库中存储数据，但受技术水平限度发展缓慢。直到2015年AI的倒退和自然语言解决的翻新，人们又从新关注这一畛域。 本章节次要整顿了NL2SQL技术的实现原理、利用场景及挑战、发展趋势等，并对以后支流的NL2SQL训练数据集进行了介绍，这里为大家摘选了局部内容。首先为大家介绍NL2SQL的定义与简述。NL2SQL(Natural Language to SQL）是语义解析畛域的一个子工作，顾名思义是将自然语言转为SQL语句。它能够充当数据库的智能接口，让不相熟数据库的用户可能疾速地找到本人想要的数据，改善用户与数据库的交互方式。 训练数据集层面。目前支流NL-to-SQL数据集次要有 WikiSQL（Salesforce）、 Spider（耶鲁大学&Salesforce）、 SParC（耶鲁大学& alesforce）。截至2023年3月， 在三大公开数据集榜单前三名中，国内模型占比绝大部分席位。以后Text-to-SQL数据集大部分是英文数据集， 代表性中文SQL解析数据集有NL2SQL（追一科技）、Cspider（西湖大学）、DuSQL（百度）。 利用场景与倒退挑战层面。以后应用NL2SQL最广的是BI报表等OLAP零碎，用户能够十分不便的通过文字统计分析数据并生成报表，另外还用于智能搜寻、智能问答、商业智能等畛域。但同时也面临着中文数据集不足、查问用意转换SQL不足背景常识撑持、模型成熟度、私有化部署难等方面的挑战。本章节均进行了具体分析，大家可查阅报告理解。 四、国内外产品利用案例报告最初一章则选取了几款国内外典型的NL2SQL利用产品与模型作为案例，首先是BI利用，蕴含Power BI Q&A 自然语言发问工具、Tableau的Ask Data自然语言交互工具、Amazon的云反对业务剖析服务Quicksight以及Apache Doris与思必驰推出的自助对话式BI等，别离能够帮忙用户查问数据并从中获取所需的后果，具备智能问答、智能剖析、可视化等性能。 其次，重点展现了OpenAI的Codex模型及其利用解读，另外，官网最新消息示意Codex模型在3月22日将进行反对，OpenAI倡议所有用户从Codex切换到ChatGPT背地的GPT-3.5 Turbo模型，这也表明了OpenAI对通用大模型的信念。 最初，整顿了以后国内几款专用模型的工作原理与技术价值，蕴含蚂蚁团体SeaD、人民大学RESDSQL-3B、上海交大 RASAT、北京大学RAT-SQL-TC与达摩院Graphix-T5。此处仅展现本章节中局部内容，大家能够下载报告获取更多内容。 本文仅对3月《中国数据库行业剖析报告》的局部内容进行了摘录、整顿，更多残缺、具体内容大家能够下载报告全文理解，也欢送各位数据行业同道交换、探讨、建言献策，咱们一起见证、独特助力中国数据库产业的发展壮大！ 报告全文下载地址：https://www.modb.pro/doc/100166往期报告下载2022年4月-2023年3月中国数据库行业剖析报告合辑2022年中国数据库行业年度剖析报告更多精彩内容尽在墨天轮数据社区，围绕数据人的学习成长提供一站式的全面服务，继续促成数据畛域的常识流传和技术创新。增加社区墨天轮小助手（VX：modb666）可获取更多技术干货。

3 月 25 日，第十届向阳国内人才守业大会（ITEC）翻新峰会在京举办。本届大会由向阳海内人才守业大会（OTEC）全新降级为向阳国内人才守业大会（ITEC），服务范畴从海内人才拓展至国内人才，性能从反对我的项目落地晋升至打造全因素翻新守业生态。其中，寰球守业赛作为本届大会的重头戏，共设置了成长组、初创组两大组别，凭借着凋谢开源的技术创新力量，涛思数据荣获 ITEC 2022 寰球守业赛成长组二等奖。 从 1000 余个参赛我的项目中怀才不遇据理解，往年是朝阳区间断第十年举办守业大会，十年来共吸引来自寰球 39 个国家和地区的 40000 余名创业者、8000 余个我的项目、数百家出名创投机构参加。与此同时，在翻新大会寰球守业赛的舞台上，十年间也涌现出了泛滥优良的守业团队和我的项目，这些团队立足科技前沿，以国际化的视线、开拓创新的精力，成为驱动区域经济社会倒退的新锐力量。 本届 ITEC 寰球守业赛在成长组、初创组两大组别下设置了特等奖、一等奖、二等奖、三等奖、优胜奖五个奖项，共吸引来自 39 个国家和地区的 1000 余个我的项目参赛。历经 5 个月的强烈角逐，其中 73 个我的项目入围寰球总决赛。最终，决出特等奖 1 名、一等奖 2 名、二等奖 4 名、三等奖 8 名、优胜奖 30 名，其重磅水平可见一斑。立足产品翻新实力，涛思数据冲破重围，胜利斩获 ITEC 2022 寰球守业赛成长组二等奖的重磅荣誉。 本届寰球守业赛获奖我的项目整体出现三大特点。一是国际化水平高，海内及具备海内背景的我的项目 23 个，占比 51%；二是成长后劲大，已取得融资的优质我的项目 39 个，占比 86.7%；三是守业团队强，我的项目创始人 93% 以上来自国内外出名高校，博士占比 44%，汇聚了一批在行业畛域锋芒毕露，具备较强创新能力和发展潜力的优秀青年人才。 此外，本届寰球守业赛将为获奖我的项目提供“后赛会”阶段的“全链条”服务保障，包含取得大赛三等奖及以上我的项目的次要创始人入选朝阳区“凤凰打算”高层次人才，并纳入服务反对体系；设立人才孵化基地，反对优质创业项目入驻，提供孵化场地、产业赋能、综合服务等全周期孵化服务；依靠向阳国内青年创投联盟，联动出名创投机构，对优良我的项目进行重点跟投；开明政务服务“绿色通道”，汇集区域内各类资源因素，为初创企业提供政策、场地、投资、人力、征询、社群等服务，帮忙企业实现疾速落地成长等等。 用数字技术创新助力数字经济倒退数字经济曾经成为撑持以后和将来世界经济倒退的重要能源。从党的二十大到去年 12 月召开的地方经济工作会议，再到刚刚完结的全国“两会”，都为倒退数字经济、建设数字中国指明了方向和重点。以后，朝阳区正全力打造数字经济核心区，减速推动数字产业化和产业数字化联动倒退，逐渐建设多元化、立体化的数字经济生态环境。 本届 ITEC 严密围绕数字经济主题打造系列流动。寰球守业赛依照数字经济产业倒退需要和特色设置“4+X”赛道（新一代信息技术、人工智能、数字平安、数字文化四大主赛道，以及元宇宙、光电子、天文信息技术、医药衰弱等特色主题赛道），以数字经济翻新人才和我的项目引进造就为抓手，联结区域内出名头部企业，在落地反对、产业翻新、守业赋能、品牌打造、产业集群建设等方面独特发力，助力数字经济新产业、新业态、新模式放慢培养。 多年来，涛思数据也始终在紧抓数字技术的翻新倒退，旗下自主研发的时序数据库 TDengine，其 3.0 版本正式降级成为了一款真正的云原生时序数据库（Time Series Database），破解了困扰时序数据库倒退的高基数难题，反对 10 亿个设施采集数据、100 个节点，反对存储与计算拆散。同时这一全新版本还针对存储引擎、计算引擎进行了降级优化，并打造了全新的流式计算引擎，无需再集成 Kafka、Redis、Spark、Flink 等软件，大幅升高了零碎架构的复杂度。此外，不久前上线的全托管时序数据云平台 TDengine Cloud，已反对包含阿里云、Microsoft Azure、AWS、Google Cloud 在内的四朵私有云。 ...

公司文化涛思数据团队直率、真挚、专一、重视细节、自我驱动而且指标导向。团队对世界始终保持好奇心，喜爱尝试、折腾，从不进行从失败中学习。拥抱开源，置信单干的力量。 咱们的吸引力：待遇超过华为、阿里和腾讯，更有丰富期权等你拿；获GGV和红杉中国等近 7000 万美元投资；弹性工作，重视沟通，反对近程办公；你将与业内顶尖技术大牛，最有激情的共事合作共事。如果你喜爱团队的价值观，置信技术扭转世界，欢送退出！请将简历发至hr@taosdata.com 社招岗位流式计算资深研发工程师工作职责：设计、实现并优化新一代时序数据流式计算引擎；负责管理、协调流式计算小组的工作；与付费客户以及开发者社区进行交换，剖析需要。根本条件：相熟流式计算的罕用算法与基本原理，具备2年以上流式计算内核的开发教训；相熟并钻研过一种或多种开源的流式计算引擎（包含但不限于Spark, Flink, Storm等)；相熟并钻研过一种以上开源的大数据处理软件（包含但不限于Kafka, HBase, Redis等)；优良的C/C++编码能力，对编写高性能程序有丰盛的教训，酷爱技术挑战；良好的英文浏览能力，理解把握数据库技术畛域的前沿趋势和动向。数据库内核资深研发工程师工作职责：设计、实现并优化新一代分布式时序数据处理引擎；负责管理、协调研发小组的工作；与付费客户以及开发者社区进行交换，剖析需要。根本条件：相熟数据库系统罕用算法与基本原理，具备3年以上数据库内核或大数据处理系统开发教训；对数据库事务处理、查询处理及优化、索引零碎、文件存储等一个或多个方面有肯定的钻研；相熟并钻研过一种或多种开源数据库、大数据系统（包含但不限于LevelDB, RocksDB, MySQL, HBase等）；相熟分布式系统中 Paxos、Raft等数据复制机制及一致性共识算法；优良的C/C++编码能力，对编写高性能程序有丰盛的教训，酷爱技术挑战；良好的英文浏览能力，理解把握数据库技术畛域的前沿趋势和动向。资深/高级/中级DBA工作职责：负责客户技术支持，包含配置管理、降级、扩容、备份、数据迁徙等工作；负责用户 集群监控、故障响应、问题跟踪及性能剖析解决。任职要求：3 年以上 DBA，或者大数据工程师的相干工作教训（MySQL、Oracle、Hadoop等），2 年以上的企业服务工作教训；精通一种数据库的（如 MySQL ）配置、备份、优化、监控、治理；相熟 Linux 操作系统，如常用命令、文件系统、系统配置等，具备较强的故障定位和问题解决能力，有丰盛解决重大故障的经验。事业部总经理工作职责：组建、并治理团队，包含销售、售前、售后技术支持；率领团队在给定的估算和工夫内，达到销售指标。根本条件：最近五年从事 toB 软件或云服务销售；有丰盛的行业资源，过来一年率领团队实现千万级的销售额；有短缺的二线品牌产品市场拓展教训。C/C++资深研发工程师工作职责：负责数据库引擎的设计、开发、测试和优化；与其余负责人一起相互review架构设计、代码；与客户进行需要沟通、技术培训，介绍 TDengine的原理、应用形式、实际等；根本条件：优良的C/C++编码能力；相熟数据库内核的根本算法；对数据库开源我的项目(Cassandra, Redis, Mongo DB, MySQL等)有钻研；有2年以上零碎开发教训，相熟分布式、高牢靠零碎的设计、研发和测试；能疾速搜寻并浏览英文技术材料，爱写程序，爱技术挑战；能独立做需要剖析，并设计、开发、测试软件，全栈软件工程师一个；能组建并率领团队，也能挽起袖子本人干；点击查看更多岗位信息 分割咱们简历发送至：hr@taosdata.com工作地点：北京市朝阳区望京保利·国内广场 T2 702室

欢送拜访 OceanBase 官网获取更多信息：https://www.oceanbase.com/ 3 月 25 日，由中国计算机学会（CCF）数据库业余委员会领导，国产分布式数据库 OceanBase 与蚂蚁技术研究院联结举办的第二届 OceanBase 数据库大赛在北京落下帷幕。 在通过三轮强烈角逐后，来自浙江大学的 K-ON! 队荣摘桂冠，西北工业大学的 426白给突击队与电子科技大学的 0xc0 队取得亚军，季军团队别离是 824445721（北京大学）、Don’t panic（浙江大学、北京理工大学）、DaSE997（华东师范大学）。 第二届OceanBase数据库大赛获奖名单 实践与实际联合，零碎提醒工程化能力OceanBase 数据库大赛发动于 2021 年，本届大赛于 2022 年 10 月启动，历时 6 个月，经验三轮角逐。 大赛集结了国内顶尖的数据库专家团评委，吸引了来自国内外 1180 支队伍的 1988 名选手参赛。 大赛由中国人民大学明理书院院长杜小勇、西北工业大学计算机学院副院长李战怀、武汉大学计算机学院副院长彭智勇、华东师范大学数据迷信与工程学院院长钱卫宁、东北大学计算机学院于戈传授等多位国内数据库畛域顶尖专家组成评审团，吸引了包含加州大学圣地亚哥分校、悉尼大学、南洋理工大学、清华大学、北京大学、浙江大学、香港中文大学、西北工业大学、华东师范大学、电子科技大学等国内外 219 所高校选手报名。此外，来自华为、快手、美团、北京银行、百度等企业界的开发者也参加其中。 第二届OceanBase数据库大赛颁奖现场 相比去年，第二届 OceanBase 数据库大赛的规格、参赛选手队伍与人数、赛事热度均有所晋升。赛前，OceanBase 举办了 7 期《从 0 到 1 数据库内核实战训练营教程》线上直播，从 MiniOB 入门级教学实战到 OceanBase 企业级工程实战 ，吸引了近 2 万人在线学习，帮忙选手更快上手数据库。 为了将实践与实际联合，让参赛选手真正领会数据库生产环境须要的技术实力，往年的赛题设置上更重视造就选手的工程实战能力。如果说去年的赛题革新一个简略的数据库系统较为根底，那么往年的赛题就是挑战更上一层，基于数据库利用场景和批量的数据，让选手将数据更快地加载进去，工作起来。 进一步深刻实际，把握数据库内核常识在“夺冠之夜”，来自全国各地的 12 支队伍针对决赛题目——旁路导入，开展性能测试过程的叙述、优化思路的剖析及参赛播种的分享。 由西北工业大学计算机学院副院长李战怀、武汉大学计算机学院副院长彭智勇、华东师范大学数据迷信与工程学院院长钱卫宁、OceanBase 创始人兼首席科学家阳振坤等八位专家组成的评审团精彩点评一直。比方对于 SSTable 排序优化、异步 I/O 优化、Macro Block Writer 优化等思路的疏导，以及对性能瓶颈、数据压缩办法的探讨。 ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。GreatSQL是MySQL的国产分支版本，应用上与MySQL统一。作者： 奥特曼爱小怪兽文章起源：GreatSQL社区原创前言线上，遇到一些sql性能问题，须要手术刀级别的调优。optimizer_trace是一个极好的工具，曾经有很多材料介绍optimizer_trace怎么应用与浏览。有必要再介绍一下咱们平时不太能留神到，然而又对sql性能起着相对作用的优化器。 优化器是啥？在sql整个生命周期里处于什么样的地位，起到什么样的作用，cmu15445 课程(https://15445.courses.cs.cmu.edu/fall2022/notes/14-optimizati...)中对此有一些直观的形容。 以上图片有6大模块，每一个模块都是一个独自的畛域。以优化器为例，从1979年到当初，曾经倒退进去9个细分的钻研畛域： Planner frameworkTransformationJoin Order OptimizationFunctional Dependency and Physical PropertiesCost ModelStatisticsQuery feedback loopMPP optimizationBENCHMARK接下来会选几个畛域做一些更底层的介绍，基于篇幅的限度，某些知识点，点到为止，能够作为当前工作再深刻的一个入口。 要让优化器可能失去足够好的plan，有几个必要条件： 数据库中的表设置了适合的数据类型。数据库中设置了适合的索引。并且索引上有正确的统计信息。正当的数据分布。查问优化器的作用：当咱们将查问提交给MySQL执行时，大多数的查问都不像 select * from single_table;那样简略，从单个表读取所有数据就行了，不须要用到高级的检索形式来返回数据。大多数查问都比较复杂，有些更简单并且齐全依照编写的形式执行查问绝不是取得后果的最无效形式。咱们能够有很多的可能性来优化查问：增加索引、联接程序、用于执行联接的算法、各种联接优化以及更多。这就是优化器发挥作用的中央。 优化器的次要工作是筹备查问以执行和确定最佳查问打算。第一阶段波及对查问进行转换，目标是重写的查问能够以比原始查问更低的老本执行查问。第二阶段包含计算查问能够执行的各种形式的老本，确定并执行老本最低的打算。 这里有一个留神的点：优化器所做的工作并不准确迷信，因为数据及其散布的变动，优化器所做的工作并不准确。转换优化器的抉择和计算的老本都是基于某种程度的预计。通常这些估计值足以失去一个好的查问打算，但偶然你须要提供提醒（hint）。如何配置优化器是另外一个话题。 查问改写（Transformations）优化器有几种更改查问的改写，在依然返回雷同后果的同时，让查问变为更适宜MySQL。 当然，优化的前提是返回的后果合乎冀望，同时响应工夫变短：缩小了IO或者cpu工夫。改写的前提是原始查问与重写查问逻辑统一，返回雷同的查问后果是至关重要的。为什么不同的写法，能够返回雷同的后果，又是一门学识：关系数据库基于数学集实践的钻研。 举个查问改写简略的例子： SELECT * FROM world.country INNER JOIN world.city ON city.CountryCode = country.Code WHERE city.CountryCode = 'AUS'这个查问有两个条件：city.CountryCode = 'AUS'，city.CountryCode=country.Code。从这两个条件能够得出country.Code='AUS'。优化器应用这些常识来间接过滤country。因为code列是country表的主键，这意味着优化器晓得最多只有一行符合条件，并且优化器能够将country表视为常数( constant)。实际上，查问最终是应用country表中的列值作为抉择列表中的常量（constant)执行扫描CountryCode='AUS'的city表中的行。 改写如下： SELECT 'AUS' AS `Code`, 'Australia' AS `Name`, 'Oceania' AS `Continent`, 'Australia and New Zealand' AS `Region`, 7741220.00 AS `SurfaceArea`, 1901 AS `IndepYear`, 18886000 AS `Population`, 79.8 AS `LifeExpectancy`, 351182.00 AS `GNP`, 392911.00 AS `GNPOld`, 'Australia' AS `LocalName`, 'Constitutional Monarchy, Federation' AS `GovernmentForm`, 'Elisabeth II' AS `HeadOfState`, 135 AS `Capital`, 'AU' AS `Code2`, city.* FROM world.city WHERE CountryCode = 'AUS';从性能的角度来看，这是一个平安的转变，且是优化器能够主动实现的，并且对外提供了一个开关。 ...

作者：京东批发 董方酉引言利用衰弱度是反馈利用衰弱水平的指标，它将零碎指标分类为根底资源、容器、利用、报警配置、链路这几项，收集了一系列零碎利用的指标，并对指标进行打分。 利用衰弱度的每一项指标显示着零碎在某一方面可能存在的隐患和平安问题；因而进步利用衰弱度对于系统监控具备重要意义。知其然需知其所以然，理解利用衰弱度中的指标背地的隐患，对于咱们理解和晋升零碎安全性很有帮忙。 笔者作为后端研发工程师，同时在推动组内利用衰弱度提高的同时，基于遇到的问题景象，联合利用衰弱度进行分析，将逐个总结一系列利用衰弱度隐患分析； 第一篇，咱们来分析下容易被人漠视的数据库时区设置项可能导致的隐患。 一、利用衰弱度查看项数据库连接池配置中，通过解析源代码获取，反对DBCP1.X，DBCP2.X，Ali Durid，HikariCP四种连接池；配置监测有以下几项 危险示例如下图所示： connectTimeout 、SocketTimeout 和 时区 三个指标是连接池数据源的 url 中解析失去, 如：mysql://xxx.jd.com:3358/jdddddb_0?autoReconnect=true&useUnicode=true&characterEncoding=UTF-8&connectTimeout=1000&socketTimeout=3000&serverTimezone=Asia/Shanghai 其中，时区设置容易被人漠视；疏忽设置会带来什么样的隐患呢？ 二、遇到的问题1、景象在2023年3月12日（3月的第二个周日），零碎UMP监控报警，提醒如下 2、问题起因Mysql 驱动：mysql-connector-java 降级到8版本后。将数据库工夫解析到java工夫，须要获取数据库的时区。如果数据库连贯中指定时区，则会用该时区，否则可能会应用零碎时区 可通过select @@time\_zone语句查问，如果返回SYSTEM，则阐明数据库没有设置时区，应用select @@system\_time_zone 语句可查问得出零碎默认时区，为CST。 CST时区为美国中部工夫，因为美国有夏令时和非夏令时 CST非夏令时对应 UTC-06:00，夏令时对应 UTC-05:00 。 美国的夏令时，从每年3月第2个星期天凌晨开始，到每年11月第1个星期天凌晨完结。 以2023年为例: 夏令时开始工夫调整前：2023年03月12日星期日 02:00:00，工夫向前拨一小时. 调整后：2023年03月12日星期日 03:00:00 夏令时完结工夫调整前：2023年11月05日星期日 02:00:00，工夫往回拨一小时. 调整后：2023年11月05日星期日 01:00:00 这象征这:CST没有2023-03-12 02:00:00~2023-03-12 03:00:00 这个区间的工夫。会有两个 2023-11-05 01:00:00~2023-11-05 02:00:00区间的工夫。 因而，在获取信息时会抛出“SQLException: HOUR\_OF\_DAY: 2 -＞ 3”异样。 3、批改计划数据库连贯地址中设置数据时区：serverTimezone=Asia/Shanghai 三、工夫相干的其余隐患1、据钻研试验反馈，设置时区为默认时可能有性能问题，往往须要指定时区。 2、应用timestamp类型时需注意工夫偏差： timestamp类型的工夫范畴between '1970-01-01 00:00:01' and '2038-01-19 03:14:07'，超出这个范畴则值记录为'0000-00-00 00:00:00'，该类型的一个重要特点就是保留的工夫与时区密切相关，UTC(Universal Time Coordinated)规范，指的是经度0度上的规范工夫，我国日常生活中时区以首都北京所处的东半球第8区为基准，对立应用东8区工夫(俗称北京工夫)，比UTC要早8个小时，时区设置也遵循此规范，因而对应过去timestamp的工夫范畴则应校准为'1970-01-01 08:00:01' and '2038-01-19 11:14:07'，也就是说东八区的1970-1-1 08:00:01等同于UTC1970-1-1 00:00:01。 ...