(https://open-leaderboard.x-lab.info/)。网站数据监控如果你想了解自己运营的网站的数据，则可使用一些数据监测工具。比如需要付费的

飙高问题的方法：1.登录上CPU不定时飙高的机器；2.排查占用CPU的进程；3.找出实际占用最高CPU的线程；4.用jstack获取对应线程的堆栈信息，找出耗CPU的代码位置对应修复。不足之处：

S3里也你也可以创建多桶。但是在这一个桶里，它是不分上下左右层次的，所有的文件或者数据都是对象，都往桶里扔，它们在桶里是没有层次结构的管理。但是为了方便自己的记忆，每一个对象有一个key，相当于一个

近年来，全球开源生态迈向高速发展的崭新阶段，很多企业、社区和个人都将关注点聚焦在开源之上。其中，有些企业、社区和个人更是为开源成立专门的组织机构，抑或是给开源设定KPI指标，意在推动开源项目或开源社区的可持续发展。当开源与KPI挂钩，结果有时会出人意料。一方面，某些开源社区或者技术大牛通过在开源项目中设定KPI，获得了广泛的关注和支持；另一方面，某些公司主管为了个人的职位晋升，盲目追求KPI指标，而开发了一个毫无使用价值的开源项目，显然有违开源精神。图片来源于：互联网坊间八卦KPI既可以促进开源的飞速发展，又可以让开源停滞不前，陷入缓慢的沉寂期。自此，人们开始思考：使用KPI的方式来运营开源项目或社区，能否带来可持续发展？一个好的开源项目的KPI指标是什么？用户和开发者对于开源项目设置KPI有何看法？企业或组织如何推动开源项目的持续发展，并避免KPI开源的变味走向？显然，开源项目和社区的成功不仅取决于技术实力，还取决于诸多因素，比如可持续发展。为了实现开源项目的可持续发展，需要确保项目对于个人、企业乃至市场具有一定的使用价值，并且可以留存用户和开发者。KPI指标应该能够衡量项目的质量、用户满意度、社区贡献度、以及用户和开发者参与度等方面，而不是单纯追求数量上的增长。对于企业或组织而言，推动开源项目的持续发展需要注意规避“KPI开源”的变味走向。他们应该注重开源项目的使用价值和社区贡献，鼓励开发者和用户参与其中，以确保项目的可持续发展。归根结底，开源项目的成功需要开发者、用户、企业和组织等各方的共同努力，方能实现真正的可持续发展。业界如何看待KPI开源？在开源生态持续繁荣的今天，很多公司和组织为了鼓励员工为开源做贡献，会将开源项目相关的指标列入到KPI考核中。二者相互关联，形成了一种考核形式，甚至演变成了一种模式——KPI开源。它坚持“要什么考什么”，具有计划性、系统性，是推动公司开源项目价值创造的驱动因素，其核心思想在于不断提升组织和员工绩效。KPI开源是一种现象而不是原因，它具有一定的必然性，并且备受争议。对于KPI开源，不同人可能有不同的看法。支持者认为，通过采用KPI开源的方法，可以更好地了解和评估开源项目及社区的表现和可持续性，有助于促进项目或社区的成功和发展。SphereEx联合创始人&CTO潘娟表示，“从开源项目角度出发，KPI开源主要围绕项目质量进行目标制定和衡量；从开源社区角度来看，可以将KPI开源解释成一种运营管理策略，来构建活跃或健康的社区。”“指标是有价值的。”开源社理事兼执行长、前华为开源能力中心开源专家庄表伟指出，“我们应该研究指标，开发指标，推广指标，并希望能够在行业内，形成对于一些关键指标的共识。对于特别容易‘买到’的短期指标，我们需要通过塑造影响力，让大家降低对这些指标的看重。”白鲸开源联合创始人代立冬也并不反对为开源项目设定KPI，他认为，“很多个人开源作者都是为爱发电，很难坚持

maven-shade-plugin采用maven-shade-plugin来达到类隔离的手段简单和粗暴，只要梳理出潜在的冲突类修改包路径后打进shade包中即可，困难在于梳理出完整的冲突类。1.2

等国际顶级开源基金会的治理模式运作。近九年来，链接了数万名开源人，集聚了上千名社区成员及志愿者、海内外数百位讲师，合作了数百家赞助、媒体、社区伙伴。👇感兴趣的朋友，可点击公众号浏览更多内容👇

开源项目，到凭借业务需求独自开发个人开源项目；从项目开源出来无人问津到至今200+star，多个企业级用户，在开源过程中，我也从走过低谷，一度想过放弃，但仍然选择坚持至今日。作者

随着数字化技术的大量应用和普及，作为核心资产的数据，其价值不断提升，数据安全已成为数字经济时代最紧迫和最基础的安全问题。数据安全是一种主动的数据防护手段，微盟主要从两大方面进行实操：一是数据处理的安全，二是数据存储的安全。分享提纲：1、数据库账号权限治理2、数据分类分级、数据加密及脱敏3、数据库平台：平台账号权限、数据查询、数据执行审计4、数据库安全运维据不完全统计，2017年6月～2021年7月，关于信息安全相关法律法规，共计有14次法规的发布及修正，足以可见国家对数据安全的重视程度。上图是监管矩阵图，监管最强的机构如网信办、工信部等。数据库相关审查的主要点是信息安全和存储安全的保护合规。关于个人信息保护合规的解读，我理解为三个方面：信息收集规则、信息使用规则，信息存储规则。在数据存储方面，主要是账号安全，数据的分类分级，数据访问安全和数据库及服务器等方面的一些安全工作。数据库账号权限治理首先，对账号进行了归类。按角色分为研发账号，运维（DBA）账号。按使用方分为业务、数据中心、运维平台、DBA运维。在业务方，建立实例与应用关系，账号无DDL权限。在数据中心方，遵循小权限账号的使用场景，具备只读权限、Binlog复制权限，对业务方实例无DDL权限。在运维平台方和DBA运维方，我们定义了不同的权限场景。按权限去划分账号，可以分为只读账号、读写账号、复制账号、管理账号以及临时账号。只读、读写、复制这三种权限类型主要被业务代码所使用，这类账号其实是最简单的一些权限划分，它相对来讲安全最好把控。管理账号这一类型稍微复杂一点，也是我们需要关注的账号类型，分为平台级和DBA运维级。简单来讲，平台账号是高于DBA运维账号的权限，因为大部分运维管理的工作都被我们的平台或者工具所取代，由这些工具或平台来完成一些功能需求。我们希望，工具能做到极致的代码质量，代码零bug。最后，我们也抽象出了一种带有有效期的临时账号类型，这类账号具备只读权限，并且只能用在临时的脚本代码中，它的服务下线不对线上业务有任何影响，仅仅作为修数据或者临时使用，具有有效期。怎么去做安全使用的管理？微盟账密安全使用管理从1.0到3.0，共经历了明文配置，一代加密（AES）、二代免密（账密替换）三个阶段。1.0明文配置阶段是下发明文账密，研发自主配置。2.0一代加密（AES）阶段是根据实例与应用关系，生成AES私钥文件，并保存至特定目录。应用通过Apollo配置数据库连接信息（密文密码）。启动应用时，通过私钥文件解密，应用启动成功。3.0二代免密（账密替换）阶段是根据实例与应用关系、业务数据库与应用关系，生成应用维度的数据库账号。账号注册至woauth账号中心，woauth对外暴露账密。Apollo配置业务数据库占位符，应用启动时上报信息至woauth服务，鉴权并推送账密，由应用端agent替换占位符，应用启动成功。在使用过程中，微盟也加入了常态化的治理运维工作项。比如，账号治理，主要梳理是否乱用，无用账号的梳理和清理，高危账号权限巡检，账号使用风险评估等工作。账号过期和密码更换是账号安全的重要保护手段。我们在实际工作中落地了一整套解决方案，将账号过期和密码更换的动作工具化、流程化，从而保障账号在更换过程中业务的无损，将这种风险降到最低。上图是从创建到下架，整个账号生命周期管理的平台化功能性支撑。从账号创建开始，有审计记录到账号使用过程中的鉴权，权限变更的历史记录。到最后，账号下架的整个流程，整个历史记录都在平台化里有审计日志。数据分类分级、数据加密及脱敏关于分类分级，工信部的166号文件里有明确的管理办法。我们在此基础上，定义了微盟4级标准：仅在数据归属部门内使用的信息，不允许开放共享的数据；法律法规等要求不允许泄露的信息；数据未经授权披露、丢失、滥用、篡改或销毁后对国家安全、企业利益或公民权益会造成严重危害。在分类上，主要是对个人信息做安全规范的定义，比如手机、身份证、地址、银行卡等。在数据分类的具体实现上，主要是通过正则表达式对数据库的表结构，数据库里面的数据去做定期的扫描，通过正则匹配来为这些表及字段打上分级的标签，完成数据的分级工作。最终，我们会输出数据分级的监管报表。通过报表可以很清楚的发现我们有多少种四级账号。数据加密与脱敏比较容易实现，加密需要业务方根据产品及监管的要求，在前后端做一些敏感信息的字符串替换来完成脱敏，其实是需要分业务场景和按监管的需求来进行的一类操作。我们的基础架构团队输出SDK或者API的工具给业务方使用。这些工具主要基于RSA的非对称加密算法，可以细化到商户维度的数据进行加密。在数据加密的前期，我们历史存量的数据与实时数据是共存的，加密数据临时放在中间态字段中。当存量的数据全部完成加密以后，将双写改为单写，将中间态数据字段变更为正式字段，非加密的原始数据字段是可以根据需求来选择删除。上图是我们加解密的架构模型。业务方需要先从组件中心申请业务K的只读权限，然后代码引入SDK，根据每一个应用的名称从内部的鉴权服务获取公钥，再通过公钥加上申请的业务K，请求微盟秘钥管理系统（WKMS）。请求相关的接口来获取数据加密的密钥，也叫做DEK，最后获取的DEK来完成数据的加解密。我们使用腾讯云的物理加密机来保护跟秘钥的绝对安全。关于微盟秘钥管理系统（WKMS），我们做了很多的功能扩展，比如高可用的存储、备份、缓存、审计等相关的功能，支持加密字段的模糊搜索。数据库平台：平台账号权限、数据查询、数据执行审计数据库平台安全管控的目标是最小权限分配原则。拆解下来，主要是授权范围、隔离策略、信息互通、可审计。资源只给对应的租户（业务团队）使用；租户（业务团队）间信息相互隔离；业务团队（租户）内所有信息共享，包括工单、资源监控、告警/慢日志推送等。数据库DML审计日志和平台操作审计日志。数据库平台权限体系分为租户（业务组）和用户操作权限两部分，用户操作权限包括是否可备份、可重启、可Kill、可资源管理、可成员管理等。对租户（业务组）进行管控，划分为用户与租户（业务组）、租户IM（业务组）、资源与租户（业务组）等。通过这些关系权限，就可以实现对资源进行操作。数据审计主要解析BinLog日志，引入实例的相关信息，做一些分析加工，变成结构化的数据，写入到对象存储当中。与此同时，我们引入Databend数仓实时查询功能，支持在线查询的数据库服务。数据审计相关工作可以对高危命令做治理/审计，比如，delete、drop；也可以给业务提供操作数据的变更审计；具备数据快照的能力，很清楚的知道数据变更前后的样子；还可以做在线事务、长事务分析；数据操作地图，可以定位哪些频繁被修改的表。关于平台权限体系的功能实现，用户细粒度的操作权限，不同的实例在每个人身上有不同的操作位权限，比如只允许备份、可以重启、不可以Kill等等。租户（业务组）对资源的管理，能够控制租户操作的资源范围。在租户（业务组）下，所有的成员操作记录共享、信息共享，实现团队内部的互相审计。数据库安全运维首先，定义规范防未然。我们抽象常用的运维操作类型，尽可能地将运维操作类型拆到最小，原子力度的操作类型抽象化，比如新建实例、资源扩缩容、重启集群，重启节点、主从切换等等。其次，对每一种操作类型定义高、中、低风险等级。同时，定义发布的窗口期，不同的风险等级在不同的发布窗口期走不同的审批流。低风险的应用允许在发布窗口，经过两道审批就可以完成运维变更的操作。从而实现规范化的运维操作，来降低人为批量操作的风险，也可以起到严控发布及变更的质量，也能够降低操作的影响面。在规范流程方面，我们整理了最常用的操作SOP、应急预案，同时会定期进行报告总结和权限收敛等工作。在团队管理方面，我们进行了运维安全风控。比如制度风控，关注员工的动态，引导员工积极向上的进行运维安全的工作。在系统风控层面，有权限风控、操作风控和应急预案等。｜嘉宾介绍｜余成真微盟集团数据库负责人微盟数据库高级技术专家，有多年的数据库产品管理和技术规划经验，目前负责微盟数据库团队管理及建设、数据库相关的业务保障、数据库技术决策；专业技能上：专注于数据库的高性能和高可用技术保障，负责数据库架构设计、数据库运维平台的自动化建设、数据库运维体系规范建设。在微盟工作经历中主导海量实例跨IDC迁移、自建集群到云数据库迁移等迁移工作；组建并带领团队完成数据库产品从0到1，从1到N的跨越；深度参与同城双活/异地多活数据库整体架构及数据同步方案的设计及实施。具备危机处理能力、具备多人组织动员能力、具有很强的判断与决策、计划和执行能力。如果您想投稿或想要讨论更多，欢迎在后台输入关键词“投稿”，联系我们。

数据作为数字经济时代核心的生产要素，已经成为经济增长的动力引擎。近几年，随着国家相关数据安全法规的陆续出台，数据安全被提升到了一个新的高度，甚至上升到国家战略层面。大数据作为企业数据资产的主要载体，是数据安全能力落地的关键，同时伴随着使用场景复杂和技术多样性等众多挑战。本文分享以货拉拉大数据平台的实际落地经验为基础，结合真实案例，系统的阐述大数据场景下的数据安全体系建设实践和方法论思考，包含了覆盖数据全生命周期的安全规范建设、安全能力建设和系统治理三方面内容，重点讲解数据使用场景、技术挑战难度下的数据（数据库表、数据报表、数据指标等）分类分级、数据的分级使用和加密存储、数据灾备等实践思路，最后全面的建设落地数据安全体系，提升数据安全能力成熟度，保障公司数据安全。分享大纲：1、背景和挑战2、大数据安全体系3、总结与思考背景和挑战货拉拉是一家互联网物流商城，提供同城/跨城货运服务，涵盖从面包车到17.5米货车多种车型，用户一键呼叫，司机实时抢单；企业版提供月结账期、定制配送等服务；零担物流，提供直达全国、门到门的长途物流运输服务；汽车租售，满足司机和企业租车购车需求。目前，货拉拉拥有6个以上的业务线，包含跨城、零单、物流以及搬家等。在大数据层面，货拉拉包含了3个IDC，是一个跨云、混合云的架构，包含阿里云、华为云以及一些自建的机房。机器数包括存储量和日均任务数，在业界属于中等的位置，在快速发展中。大数据的使命是驱动业务数智化，助力公司业务持续增长。而大量的数据存储会对我们的数据管控和数据安全带来一定的挑战。上图是货拉拉的大数据体系，自底向上，分别是基础层、接入层、平台层&数仓、服务层、应用层。基础层和接入层提供最基础的存储和接入的能力。在平台层&数仓层，包含数据研发平台、数据治理平台、数据资产。在服务层，面向服务场景开发的大数据应用，包含数据应用支撑服务工具、数据服务工具、数据智能支撑工具。在应用层，有辅助决策类应用和赋能业务类应用。整个大数据体系是相互依赖、相互支撑的体系。数据架构自左向右分成数据采集、数据存储和计算、数据应用三个层面。通过数据采集将日志数据、埋点数据、交易类数据集成到大数据平台，先做好数据存储，然后通过实时和离线链路进行数据加工处理，针对实时和离线，我们分别建立了一个数仓体系，最后将加工好的数据会推送到数据应用里面。货拉拉为什么要做大数据安全？一是因为数据资产保护的要求，二是因为个人信息保护法、网络安全法、数据安全法、数据安全管理办法等法律法规的要求。大数据安全面临着众多难点和挑战，货拉拉的数据资产类型多,

本文根据杨小飞在【第十五届中国系统架构师大会（SACC2022）】线上演讲内容整理而成。历经两年，中通快递已经实现了内部与生态绝大多数应用容器化的目标，期间经历了从单集群到多集群的部署，从单集群独立管理到统一多集群管理能力的发展旅程。中通云平台持续推出了基于真实负载的调度器和节点均衡job、应用画像、容器现场保留、应用迁徙、固定IP、跨集群HPA等多种功能或者产品，既提高了极端情况下单一集群的容灾能力，也提升了各个集群的资源利用率。单一网络多集群治理探索，以及不断推进容器化，提升各个集群资源利用率并部分提供容灾能力。本文就国产分布式数据库在引入后如何结合银行业务场景选型，如何配合开发兼容性改造、如何完成数据迁移等技术问题，如何搭建运维体系建设、如何规范流程管理进行内容分享。分享大纲：1、中通云发展背景与挑战2、从单集群到多集群3、多集群治理4、成功与总结5、未来规划中通云发展背景与挑战截止2019年前，独立的devops平台，中通云绝大部分流量都跑在虚拟机。从2019年开始，中通云开始容器化进程，自一开始便使用了bgp打通了各集群间的网络，支持虚机容器混部。截至2022年中旬，中通云现有业务绝大部分跑在容器上，大的生产集群有6个，总共pods数量18000多个，node节点700多，持续推进集群治理以保障环境的稳定和资源充分利用。未来，中通云会推动南北流量治理，全域容器化；提升可观测能力，有状态应用的支持。2019年前，中通云的状况是预研K8s、上线wayne、提供k8s资源管理微服务、上线ZKE、开发、测试上容器。自2020年开始，中通云开始生产上容器，并且不断推进容器化、多集群、cilium。未来，中通云将统一网关、离线混部等。容器化前，中通云主要是跑在虚拟机，部分有状态服务运行在物理机。其应用生命周期管理迟缓，南北流量全部依赖于静态配置，伸缩缓慢，大量僵尸应用缺乏治理，资源利用率低。容器化后，中通云的资源利用率从15%提升到百分之40%，应用全生命周期管理更快便捷、快速，弹性伸缩能力加强。在容器化过程中，中通云遇到了很多挑战。包括：安全要求，所有的外网访问都需要走申请；单集群部署存在风险，单集群的故障影响面太大；对接devops平台，有独立的devops平台，需要从传统的虚机发布添加对于容器和混部的支持；固定ip的需求，少量应用对于固定ip存在需求，比如“雪花算法”的应用。资源吃紧，由于容器化不断推进，而资源回收滞后，集群资源禁止持续了很长时间；原生调度器不足，基于request和limit的调度无法完全体现各个节点的资源情况；容器内故障现场难以保留，运行在容器的应用故障，重启或者回滚就丢失了现场；节点均衡，集群各个节点调度不均衡，为了平衡需要根据实际负载二次均衡。从单集群到多集群单集群支持内容基于真实负载的调度器拓展，中通云自研了基于原生的拓展调度器，基于采集到节点注解的负载信息进行调度。固定ip支持，采用ipam固定ip方法建立专用固定ip集群。容器现场保留，有别于官方的临时容器方案，通过宿主机cri能力切断故障现场的容器网络，然后踢出工作负载管理，再用钩子dump堆栈等。节点二次均衡，即使使用了自研的拓展调度器，个别情况下还是会出现负载不均匀的情况。因此，自研了二次均衡的job，来确保集群各个节点负载均匀。自研的拓展调度器的改造内容包括由采集器将节点真实负载写入到节点注解上，然后调度器从中获取信息之后调节节点的score。这期间踩过一些坑，由于node-exporter偶尔出现采集不到信息的情况，导致上报的负载为0，使得该节点被大量调度pod上去，最终打垮了该节点。热点调度，目前的工作负载都会设置反亲和性。关于容器的现场保留，其需求背景是生产环境上个别应用出现java进程假死情况或者出现应用层的保持。出于快速止血的需要，一般都会进行重启或者回退版本，这使得故障现场第一时间丢失。手动dump内存等周期长、慢，且不完整。基于选型的考虑，官方由提供临时容器的方式，可以复刻一个现场。但是，由于我们存在低K8s版本，无法全部满足需要，另外现场可能还会继续工作，如果既要他不工作又要现场保留，就会存在困难。最终采用是自研方案，由于我们内部都是无状态工作负载，所以最终采用了自带的特性：修改已经存在的label，然后k8s会自动拉起一个新pod来替代它；同时，调用容器内的dump堆栈指令保存即时的现场，再调用cri指令，切断容器的网络。二次节点均衡的背景是单集群内长期存在各个节点负载不均匀的情况，即使上了自研的基于真实负载的拓展调度器也未解决问题。高负载的节点会使得大量的运行上的应用高延迟，影响很大。等待触发k8s的驱逐机制非常危险且不确定。长期的解决方式是由运维手动删除一些负载较高的节点上的pod。解决方案是在内部，我们调研了descheduler，并且基于它改造了部分内容，根据真实的负载水平驱逐pod。但是，内部我们并未采用它，我们只需要其中更简洁、确定的功能。最终，我们自研了二次均衡的job。那么，哪些pod适合被驱逐？单实例多副本中的其中一个。非网关等核心应用，支持namespace、app、node节点白名单机制。cpu在2C~4C之间，低CPU驱逐没有意义，高CPU驱逐对于应用影响比较大。多集群的基本能力包括：跨集群之间的资源管理、Devops支持多集群发布和多集群管理、单集群管理控制台适配多集群管理工作负载的能力、多集群管理控制台——云看板。多集群支持的内容分为四个方面，应用发布支持多集群，由于集群间网络打通，所以只需要在多集群确保工作负载一致。多集群ingress与统一网关对接，应用路由以及各集群ingress网关上报给统一网关。多集群与日志平台的对接，从工作负载页面，支持快捷跳转日志平台和应用监控平台页面。多集群与监控中心的配合，以应用为纬度，统一上报到prometheus，再由监控中心配置告警阈值。多集群治理我们所做的治理内容包括应用迁徙、跨集群应用均衡、应用打分三方面。在应用迁徙方面，支持按照集群权重迁徙副本数，当新加入一个集群，需要对于资源进行迁徙，可根据配置，划分设置比重的副本到新集群。支持整体迁徙，拷贝所以资源到新集群，然后停用旧集群相关资源。在应用打分方面，支持根据部门和产品纬度整体打分，输出具体打分标准和低分整改要求。目的是为了应用的健壮运行提供了数据支撑，保障集群的稳定性，各产品良性竞争。支持依据cpu、memory等的使用情况和设置规则的差值比例；大副本；内存使用等多标准，依据不同情况对于应用提供治理项和依据。在跨集群应用均衡方面，对于历史应用，支持基于副本数和HPA对于工作负载在多集群之间进行均分，或者按照集群剩余request等多种方式分布或者伸缩。且支持cronHpa，未来还将支持基于消息积压的HPA。对于新发布应用，我们都会默认开启后，逐渐模糊单集群的概念，应用只需要关于自己的运行状态。成功与总结在单一网络多集群实践中，成功的方向有四个。我们解决了长期的基础设施历史包袱，推进容器化进程，应用大部分都跑在容器中，回收虚拟机与物理机都已经达到预期。拥有一个应用全生命周期管理，具备了比虚机更便捷的应用运行、发布、回滚等能力。关于多集群控制能力层次设计，避免鸡蛋都放在一个篮子，多个生产集群，避免单集群的故障对于整体的影响。多集群管理，目前可以非常友好的支持增加集群或者减少集群，中间周期可以大大缩短。由于各个集群之间细微的差异，比如版本，K8s核心组件和组件部署方式差异。我们在节点预留资源踩一些坑。此外，我们与统一网关的结合需要更加友好。比如，自动上报网关地址和端口以及域名和产品信息。由于长久的历史原因，提供东西流量的治理存在很大的未知性。由于安全的特殊要求，网络策略在多集群的管理下支持的不够好。未来规划目前是将各个集群的ingress网关地址配置在外部网关上，由此导致上层无法拿到pod

Bigtable上的Cookie匹配表用于这个目的。第二，移动设备端，提供设备的广告ID（例如IDFA和AID），但隐私设置允许用户阻止公司收集他们的广告信息。如何维护实时用户？Cloud

年初，成为当年首个毕业的顶级项目。在此过程中，我体会到了快乐、也收获了满满的成就。相比较而言，纯个人的项目风险会更大一些，因为它更取决于创始人自身的想法和状态。ShardingSphere

支持低延时的数据摄取，灵活的数据探索分析，高性能的数据聚合。简便的水平扩展。适用于数据量大，可扩展能力要求高的分析型查询系统。支持实时数据摄入。其机制将热点和实时数据存储在实时节点（Realtime

分钟一个checkpoint。另外一条链路是天级或者小时级，落入到Iceberg表。Iceberg表无论在ODS、DWS、DWD的哪一层，都可以根据用户需求对外直接提供服务，目前最多的业务场景是使用

开源机器学习数据库OpenMLDB网易严选基于“服务画像”的建设实践创新是国产数据库的唯一出路

聚合层，在实时数仓的建设中，DWS层聚合的成本非常高。实时计算大部分只会做一些很轻量级聚合，比如分钟级、小时级别的聚合，按需建设，有需求时会将这一层的数据落到现在比较流行的OLAP引擎当中，比如

云原生时代，数据库该何去何从20000节点数仓集群在大型商业银行的落地新一代云原生数据库关键技术解析与最佳实践TDSQL敏态引擎TDStore新技术引进

随着数字经济的蓬勃发展，产业数字化进程持续推进，数据技术拥有了广泛的端到端应用场景，而借助数据技术可以实现从数据到信息、从信息到知识、从知识到决策的转换，助力实体经济的创新发展。IDC预计，到2026年，全球大数据市场的IT总投资规模将增至4491.1亿美元，实现约15.6%的复合增长率。具体到技术层面，《IDC聚焦报告：2022年云上产品演进趋势》中指出，实体经济发展离不开数据支持，而与云原生技术相结合的大数据、数据治理、数智融合与隐私计算，在解决大数据技术门槛、运维部署等问题方面的突出作用持续受到关注，企业真正需要的是一套“开箱即用”的云原生产品服务。腾讯云大数据恰好提供了这样一套产品，它是基于腾讯海量业务打造的世界领先级大数据产品生态体系。截至目前，腾讯云大数据的算力规模已经突破千万核，日实时计算量达百万亿级、日运行容器数超亿级，日计算数据量数百PB，服务的企业客户数超2万家，开源社区代码贡献量超800万行。前不久，由ITPUB、IT168联合主办的《技术改变世界

都实现了很好的隔离，最小化不同负载之间的干扰，获得更好的性能。如，其分布式事务采用了乐观事务与快照隔离，快照隔离级别比常见的Read

新一代云原生数据库关键技术解析与最佳实践站在腾讯云数据库的2022年看中国数据库的现状和未来TDSQL敏态引擎TDStore新技术引进具备混合负载能力的分布式KV存储-KeeWiDB

本文根据刘迪在【第十三届中国数据库技术大会（DTCC2022）】线上演讲内容整理而成。在云计算时代，由于对弹性、高可用性、可扩展性的需求以及来自不同业务领域的应用程序对按需使用的需求增长，云原生数据库变得越来越重要。云应用程序的这些需求为云原生数据库提供了新的机会，而传统的企业内部数据库系统无法完全满足这些需求。腾讯云原生数据库经过多年的研发和打磨，所实现的计算、内存与存储资源的解耦的“日志即数据库”架构、HTAP、Serverless等特性，已是全球首创或业内领先的技术，同时其性能对比传统云数据库达到数倍的大幅度提升。

目前，中国数据库市场热闹非凡，百花齐放，据称有300多家数据库厂商，而据不完全统计，过去两年内，就有数十家新的数据库创业公司成立。数据库成为资本追逐的宠儿，新闻的热点。在这一片热闹之中，上云是比较确定的发展趋势，云数据库早已成为推动中国数据库创新发展的重要力量，尤其是一些云大厂，有相对完善的数据库产品线。在Gartner发布的2022年Gartner云数据库管理系统魔力象限中，腾讯云数据库的执行力遥遥领先于Niche

敏态引擎之存储层——TDStoreTDStore作为分布式存储层，不但负责保存用户的数据，其设计中还是两阶段事务协调者的这一层，不同的数据是根据Raft协议分布在不同的节点，都是由Raft

Table，传输的数据量远比下推一个场景计划小很多。通过这种方式，可以大大减轻高并发情况下的网络带宽的压力，很好地在同一套系统又支持复杂场景的PLAN

Nothing有一个问题，我们要做分布式事务只能在Proxy上来做，兼容性很难做得非常完美，而且对开发量也非常大，稍不留神就会跟不上。若100%做到，需要投入很大精力，并非易事。我认为未来Share

的生成，然后某些节点会从其他节点上拿数据。下图为在线引擎提供基于内存、外存两种存储引擎的选择：基于内存：低延迟、高并发；较高使用成本提供毫秒级延迟响应。基于外存：对性能较不敏感；低成本使用落地基于

DTCC2022金融级系统海量流量下高可用架构的道与术光大银行实时流数据平台架构实践小红书近线服务统一调度平台建设实践

2022年12月14日~16日，由IT168联合旗下ITPUB、ChinaUnix两大技术社区主办的第13届中国数据库技术大会（DTCC2022）在线上隆重召开。大会以“数据智能

康杨京东科技备战架构师委员会负责人京东支付架构师团队负责人【嘉宾介绍】京东集团认证讲师、京东集团PAAS化架构师委员会成员。整体负责京东支付PaaS化改造、京东支付上云

库的方式来实现真正的数据的管理，而不是消息的管理。从而也能实现平台真正变成数据属主，因为在原有的模式下，它更多的像是一个通路，或者说当上游有些变更、有些问题之时，没有很强的控制力

随着公司的发展，技术架构逐步演进为在线、近线、离线三位一体架构。近线服务介于在线和离线之间，一般采用异步计算的方式，并不要求立即返回结果，但是计算的执行却和在线服务类似。容器架构团队设计了一套基于容器的近线服务统一调度平台，支持数十万核近线服务接近0计算成本运行。

随着B站业务的高速发展，公司内部业务、基础架构和运维对于通用运维性数据的多样性、实时性和集成性需求越来越多，对数据质量的要求越来越高。而伴随着大数据技术的不断发展和成熟，B站也对公司内部基础数据的治理和管控进行了大量尝试和实践，最终建设了一体化运维数仓，来支撑满足内部业务/基础架构/工程效率/SRE团队对于数据的强烈需求。

随着个人信息和隐私数据对于保密要求越来越高，各行各业对安全的要求也越来越高。而支撑各行各业的信息系统在设计和开发时，面临着安全方面的新挑战。数据库作为信息系统中数据存储和数据管理一个重要模块，其安全和设计显得尤为重要。近年来，分布式数据库在金融业加速落地，金融机构对分布式数据库安全有哪些需求？金融机构分布式数据库要如何进行安全设计？

2022年12月14日~16日，由IT168联合旗下ITPUB、ChinaUnix两大技术社区主办的第13届中国数据库技术大会（DTCC2022）将以线上直播形式召开。PS:文末有免费送门票活动，先到先得！！大会以“数据智能

服务网格是微服务间通讯治理的基础设施层，近年来一直是服务治理方向的热点话题。随着微服务拆分的不断深入与精细化，微服务治理在微服务架构中的地位与作用逐渐凸显。服务网格在改进微服务架构稳定性和成熟度、统一精简微服务框架、提升服务治理能力方面，具备天然的技术优势。

金融核心系统，尤其是银行核心交易系统对数据库的要求极为严苛，一直都是国产数据库想要攻克的难关，是检验国产数据库能否挑起大梁的标志。近两年好消息不断，就在10月初，某银行基于易鲸捷分布式数据库打造的国产软硬件支撑的核心交易系统进入试运行阶段，目前运行稳定，各项指标均满足预期。可以说这是国产分布式数据库的一个突破，也是银行打造全栈国产软硬件核心交易系统的突破。IT168&ITPUB一直都在关注国产数据库在金融核心系统的发展动态，去年，该银行核心交易系统正在建设中，我们采访了易鲸捷解决方案架构师王燮元，讨论国产数据库在支持金融核心系统的发展情况，他告诉IT168&ITPUB：“全栈核心系统的主要难点在于软硬件之间的适配和磨合，相比国外产品数十年的发展，我们(国内)无论是芯片、操作系统还是数据库，实际上都缺乏在核心重要系统的应用和演练，虽然线下我们在积极推动生态的建设，各个厂商之间的适配工作也都在进行，但不拉到真实的战场试一下，总归是不行的。”日前，IT168&ITPUB再次找到王燮元，本次我们重点讨论了分布式数据库的发展，以及分布式数据库在银行核心系统的落地情况。分布式数据库从1.0走到2.0随着海量数据爆发，移动互联网带来高并发需求，传统的集中式数据库出现瓶颈，分布式数据库技术自2010年以来呈现蓬勃发展的趋势，目前正处于增长期，被认为是未来支撑核心、关键业务系统的主流数据库技术，也是国产数据库实现换道超车的希望。根据IDC的调研，目前约26.8%的企业级市场用户部署了分布式数据库，超过90%的企业认可分布式数据库部署后的效果，其中，大多数被访企业看到数据库系统性能的明显改善，切实解决数据库企业级应用痛难点。在分布式数据库如此火热之下，很多厂商针对不同业务场景打造了多个分布式数据库产品。比如，易鲸捷目前有QianBase

俗话说：“民以食为天，食以稻为先”。水稻在中国种植已经有7000多年的历史了，是人类重要的粮食作物之一。金秋是收获的季节，稻浪起伏，稻谷飘香。从一颗稻谷到另一颗稻谷，它代表着丰收，也代表着轮回。在这样一个循环往复的过程中，创新科技为秋粮丰收提供了全面、高效的支撑。要知道，在水稻成长过程中，从育种到栽培再到丰收，凝聚了无数科研人员的心血，科技正在为每一粒米护航，端牢中国饭碗注入力量。其中，“水稻适度加工技术”正在为水稻提质增收发挥着重要作用。工程北米斩获全国金奖近日，鲲鹏应用创新大赛2022全国总决赛在杭州闭幕。哈尔滨工程北米科技有限公司“数智识米——基于鲲鹏服务器的水稻适度加工解决方案”从全国21个赛区2000多支队伍中脱颖而出，获得全国总决赛企业数字化赛题金奖。据了解，哈尔滨工程北米科技有限公司，是由哈尔滨工程大学、黑龙江省政府和黑龙江新产业投资集团持股孵化的国家高新技术企业。公司是黑龙江省技术创新示范企业，并拥有省级技术创新中心“水稻适度加工智能技术创新中心”。本次斩获金奖的是工程北米公司的数智识米团队，该团队组建于2021年9月。团队成员涵盖软件、算法、测试、运维等方面。团队使命是助力鲲鹏生态的基础技术全栈发展和产业落地，共推稻米加工数字化转型。“水稻适度加工”痛点多水稻适度加工，是采用特殊技术在加工过程中保留传统加工工艺无法保留的胚芽和糊粉层，实现了在加工过程的节粮减损。由于胚芽占整个大米的3%-5%的重量，如果能够得到保留，相当于粮食增产3%-5%。该项技术涉及水稻加工、检测、包装、储运等多个行业，是高端装备制造、信息技术和农业等多个学科相互交叉而产生的新兴领域。如今，我国约有一万余家稻米加工企业，年加工量达到2.1亿吨。从国家粮食和物资储备局获悉，据测算，我国粮食在加工环节损失量每年在150亿斤以上，其中我国每年在水稻加工环节就损失了59亿斤。据数智识米团队负责人表示，水稻适度加工存在诸多痛点：一人对多机，检测数据不准确在加工过程中产生，绝大部分加工企业凭借人工巡检实现碾米工艺、设备性能和操作管理水平等指标。普遍出现工艺不合理、设备不合适、流量不平衡、砻碾设备技术参数不当、高温（湿）差、撞击以及操作不当等现象，从而造成加工浪费。一切等数据，工艺调整不及时当前，最严谨的检测，仅2小时检测一次，每次检测时间不少于10分钟，而稻米加工以每小时5-25吨的流速推进，检测速度远跟不上加工生产速度。同时，检测样本量小，数据具有很大的随机性，检测结果无法在加工过程中作为评价依据使用.一眼定乾坤，碾磨精度靠经验加工精度依赖技术工人的经验。在加工不同大小稻米时未进行分离处理，特别是特小或特大稻谷，包括砻谷机、谷糙分离机、碾米机、抛光机等设备加工精度达不到要求，摩擦碾白时压力大小不系统，产生极大的浪费。针对上述痛点，最终，数智识米团队决定采用鲲鹏服务器为核心计算设备，创新地提出了基于鲲鹏服务器的水稻适度加工解决方案。该方案的整体架构由设备端、边缘端及云端三部分组成。通过使用靠近数据源头的边缘计算来提供强实时、高效率的数据处理服务。边云协同进一步实现编排调度、资源管理从而为无所不在的计算提供高效、稳定、安全的算力支撑。据数智识米团队负责人表示，该方案有两大创新点：其一，该方案是首次将鲲鹏服务器应用于农业加工领域。基于昇腾AI完成云端训练和边缘侧推理，将推理得到的数据上传到鲲鹏服务器，服务器进行大数据分析形成加工工艺参数，下发到产线进行执行，进一步提高粮食产量。其二，团队通过在鲲鹏服务器上搭建稻米加工大数据平台，利用大数据分析将采集的水稻加工的设备运行数据转化为我们需要的各类匹配信息。通过匹配数据的挖掘，使用聚类算法，将不同水稻品种的加工策略分为不同的类簇，再对类簇中的加工策略进行对比研究，发现其潜在的模式规律，实现加工策略与加工对象的精准匹配。多品种稻米加工的通用模型的构建，能够使得生产环境摆脱必须依赖技术工人的经验的问题，实现端云协同，加速产业升级与复制落地。在实际价值方面，据数智识米团队负责人透露，团队以前用的是x86平台。在x86平台上，大数据分析算法耗费时间较长，影响稻米的加工生产效率。而鲲鹏平台采用ARM架构，多核，非常适合大数据、高性能计算以及数据库等应用场景。数智识米团队负责人表示，鲲鹏平台在水稻加工大数据分析时的性能非常突出。尤其是在运行机器学习算法时，性能平均提高了10倍左右，提高了加工生产效率，在数据库存取方面，性能也得到了3倍左右的提升。鲲鹏应用创新大赛打造创新人才聚集高地鲲鹏应用创新大赛作为鲲鹏计算产业面向全栈开发者的年度高端赛事，已经连续举办三届，今年这场大赛依旧火热。人才是鲲鹏计算产业的“星星之火”，本届大赛共吸引2000多个团队，产生了1000多份高质量初赛作品，引领了5000多个开发者加入鲲鹏生态建设，为计算产业的发展和数字经济发展创新提供了强大的新动能。据笔者观察，今年大赛有7个赛道，比赛队伍有企业，有运营商，还增加了不少科研团队和高校团队，大赛推动把大量的应用从原有的传统计算体制，迁移到当前规模部署的鲲鹏+openEuler系统上，提升了使用率，大部分参赛作品使用了鲲鹏生态软硬件工具。如今，鲲鹏生态已经覆盖到了政府、金融、电信等各大行业，正在向着更加广阔的应用领域发展，为行业数字化提供更加强大的根基。数智识米团队负责人表示，这几个月来，团队一直在积极筹备比赛，包括软件的开发、移植、调优以及系统的整体联调，项目解决方案的设计、修改等。鲲鹏生态创新中心给了我们资源上的支持，而在调试过程中，鲲鹏的技术人员给了我们技术上的支持，帮我们解决了很多问题。作为鲲鹏展翅合作伙伴，工程北米获得了鲲鹏生态创新中心的算力支持、技术支持等，为工程北米在农业加工领域注入了源源不断的动能。可能有人要问了，为什么鲲鹏要连续3年举办鲲鹏应用创新大赛？除了加速推动应用创新之外，我想，鲲鹏更看重的是人才的培养。国之重器离不开大国工匠，鲲鹏应用创新大赛让更多的产业人才和企业认识并使用鲲鹏生态基础软硬件设施，汇聚人才，凝心聚力，笔者感觉到鲲鹏生态从技术到产品，从应用到生态取得了快速的发展，给产业更多的信心，为数字中国建设添砖加瓦。近期文章精选

天下武功，唯快不破。HTAP之所以有一大批“忠粉”，甚至被称为是满足实时数仓业务需求的有效手段，那是因为它可以把两类工作负载放在一个系统上运行，让数据生产后立刻进入分析场景，而不是让数据在数据库和数据仓库之间传来传去，进行事后分析。那么，HTAP与实时数仓之间，到底是怎样一种关系？从架构以及技术理念来看，二者有着异曲同工之妙，都具备了业务需要的实时计算、实时存储等关键特性。但从定义来看，HTAP和数仓，又有着明显区别。HTAP，是从数据库的角度思考问题，但如何真正让OLTP和OLAP在系统运行过程中做到互不干扰，是设计的一大挑战；而实时数据仓库需要复杂的ETL和建模，最终才能产生信息，辅助业务决策。之后，随着云计算、流计算、大数据以及AI-Native技术的发展，不管是HTAP，还是数仓，都在努力跨越自身瓶颈，向新的技术方向演进，并有了逐步融合的趋势，导致很多新兴数据库以及实时数据仓库解决方案如雨后春笋般快速生长，天云数据Hubble就是在此种背景下诞生。问题与主义之争在了解Hubble如何以HTAP的形态满足实时数仓业务场景之前，我们先来分析下关于实时数仓的各种技术流派纷争。除了传统数仓的优化升级，云数仓、湖仓一体也被称为实时数仓。问题是，到底什么是实时数仓？从技术背后的构成要素去分析，可能才会抓住问题的关键点！▲天云数据CEO雷涛正如天云数据CEO雷涛所言，从大的数据业务场景来看，无非包括数据库、数据仓库和大数据平台三块内容。而针对实时数仓这个“窄场景”，也分两个不同角度。一个是，基于之前BI实现的数据仓库的优化，让数据库和数据仓库实现

近年来数据库领域最火热的两个细分赛道非图数据库与时序数据库莫属，根据DB-Engines的数据（如下图），近几年时序数据库的流行度一直稳居第二。近些年，一些新的时序数据库创业公司出现，获得资本的青睐，在万物智联时代争相竞逐，尤其是中国的初创公司，在时序数据库领域与全球基本处于同一起跑线，业界普遍认为前景可期。但也有人认为，专有的时序数据库是走了NoSQL的老路，没有未来，在万物智联时代，数据库的尽头是超融合。数据库的尽头是超融合？时序数据库是时间序列数据库的简称，也是NoSQL数据库的一种。简单来说，时序数据库(TSDB)是针对时间戳或时间序列数据优化的数据库。与其它数据不同，时间序列数据总是会和时间绑定在一起。比如服务器的指标、网络数据、传感器数据、街道上的监控数据等等，主要应用于分析预测和监控告警方面。随着物联网、5G等不断发展，时序数据海量爆发，传统的关系数据库无法满足要求，出现了像InfluxDB这样的专有时序数据库，近年来海内外巨头也开始针对时序场景布局推出相关产品，如Amazon

这两年，企业IT领域掀起实时数仓热潮。然而，只要稍做梳理就会发现，实时数仓格局未定，各种流派群雄逐鹿，还有很多需要进一步探讨的话题方向。比如：实时数仓是什么？如何从概念上去定义？有人认为，传统数据仓库做了实时化，就是实时数仓；有人认为，云数仓、湖仓一体是实时数仓；还有人认为，HTAP是解决实时数仓需求的一个重要手段！再比如：实时数仓是一款产品，还是一个解决方案？99%的企业都会认为是一个解决方案，1%的企业会认为是一款产品，这1%就是阿里云！▲阿里云自研大数据平台产品负责人刘一鸣（合一）为了弄清事实真相，帮助用户找到应用选型“快速通道”，本期实时数仓系列访谈，特邀请到阿里云自研大数据产品产品负责人刘一鸣（合一），请他从实时数仓的技术演进、应用场景、架构以及Hologres自身实践角度，一层一层揭开实时数仓的“谜团”！实时数仓进化如果，非要给实时数仓下一个定义，一定要符合从1.0到3.0时代的进化特征。首先，得是一个数仓，具备规模数据的交互式分析能力。实时数仓不只是“实时”，很多系统不支持标准SQL，不能算数仓。所以，属于1.0时代的实时数仓，有一个重要前提，就是支持较为完善的SQL以及优秀的大规模分析能力，因此很多系统采用了分布式、列存、索引、压缩等数仓加速的技术。其次，面向实时场景做了针对性优化，包括实时写入、实时分析、实时取数等。如果和普通数据库相同，没有针对实时场景做优化，很难达到实时数仓对吞吐和分析的时效性要求。实时数仓需要具备高吞吐写入和更新能力，数据写入即可用，支持灵活的数据更新。比如：很多普通数据库，虽然能写也能查，但当数据规模放大到一定程度，要么牺牲了写入性能保查询，要么牺牲了查询性能优化写入，无法针对实时数据多场景进行优化，这不能算好的实时数仓。进入2.0时代，实时数仓就要尽可能快地支持在线业务。企业之所以做实时数仓，是希望数据进来之后能够被足够新鲜地消费，能实时写入、实时分析，还要支撑在线服务。在线服务场景需要更高的性能、低抖动、稳定性、并发能力，对在线服务场景进行支持，是实时数仓关键一环。而3.0时代的实时数仓，可以定义为一站式实时数仓。这个时候的实时数仓，不仅具有高吞吐写入与更新、端到端的全链路实时加工以及低延迟高并发在线服务能力，在保证数据一致的前提下，需要支持多种负载之间完备的隔离和弹性能力，以确保各个业务互不干扰，各自按需使用资源。同时实时数仓的使用通常离不开离线数仓的组合关系，通过离线平台对历史数据的周期性汇聚、抽象和加工，并将结果数据导入实时数仓进行丰富和修正，需要更有效地打通实时与离线两套系统，实现元数据和数据的无缝交换，这也是实时数仓落地时需要具备的能力。这种一站式体现在存储状态的一致性，减少了不同负载之间的数据同步和存储开销，避免了数据服务层的数据孤岛难题。所以，实时数仓既不是传统数据库的旧瓶装新酒，也不是湖仓一体的多产品组合，它和离线数仓的本质区别是，通过对易变数据结构（包括内存结构、文件存储）和计算资源的细粒度灵活管控，更好地支撑数据的实时写入、实时更新、实时查询。至于，很多公司之所以把实时数仓定义为是一个解决方案，是因为技术相对更加复杂，既要考虑写入和加工能力，又要支持查询和在线分析场景，不得不针对不同技术需求将多种技术栈堆砌在一起，包括采用流式计算、消息中间件来达到端到端的实时加工，采用列式数据库应对分析需求，采用行存系统支撑在线服务系统，并依赖复杂的调度配置，实现数据在中间件、存储系统之间的最终一致性。而将复杂技术落地成为一款易于使用的成熟数仓产品，仍然是少数技术创新者在努力的方向。阿里云Hologres，整体技术水平领先业界1-2年，是基于在阿里巴巴内部数据技术的广泛应用与沉淀，一步一步走过来的。阿里有海量数据的复杂应用场景，有历年双11等大促的深度压力测试，有在存储和计算领域深扎多年的技术专家，有上万名数据小二支持业务的灵活需求与快速迭代，这些都是其他公司不具备的得天独厚的条件，推动着阿里在数据技术领域的持续创新。Hologres支撑的业务的规模、复杂性和对效率的极致追求，实现了通过有些开源技术组合无法达成的数据价值目标。行业内不少企业采用部分开源技术栈，如：用Kafka做中间件，用Hudi做离线存储，用Presto做离线查询加速，用ClickHouse做OLAP查询，用Flink做流式数据加工，用MySQL做缓存，用HBase做在线服务引擎。这些架构也是阿里采用过的第一代实时数仓架构，但当开发效率遇到瓶颈时，当数据链路复杂到成为运维负担时，当数据不一致不得不80%时间在对数排查时，工程师们开始思考是否还有更好的解决方案，是否有一个更加集中化、一体化、能力更全面的数仓选择。而Hologres的出现也就重新定义了实时数仓的形态。基于此，OLAP查询和在线服务使用Hologres，满足分析的灵活和效率，离线数仓使用MaxCompute，支撑规模性和Serverless扩展性，实时流式计算用Flink，凸显端到端全实时加工，三者的结合让实时和离线计算，分析和服务都能达到一个非常好的平衡，满足业务的多种需求。阿里云Flink版的出处与Hologres的渊源有人可能会说，阿里云Hologres+Flink这套组合也用了Flink，和其他解决方案相比，有什么不同呢？没错，Hologres要想发挥最佳水平，与Flink结合，一定是首选。实时计算需要后台有一套强大的大数据计算能力，而Apache

90%+的流量，通常可以在十分钟内解析完毕，剩下长尾就不确定了。第二，传统DNS应答数据易被劫持篡改，有些用户访问会被路由到一些钓鱼网站。第三，用户所在区域的LocalDNS

生活中充满了各种trade-off（权衡），编程开发中也是如此。本文将通过实战的角度，分享在开发微服务框架的过程中，针对不同的组件做的一些抉择，包括，协议支持的多少？数据传输采用TCP还是UDP？网络处理是普通处理模型还是定制的epoll？序列化框架那么多，该用哪种？注册中心选哪家？路由方式哪种好，如何限流等等。

后台有小伙伴反映说，有时想要看特定主题的技术文章，公众号搜索却又很不方便，针对这点，小编也深有同感。今天特地给大家汇总了一份近四个月的数据库系列干货文章合集，共53篇精华内容，希望数据库爱好者可以从中获益。强烈建议收藏本文哦！（点击下方的图片，即可跳转到文章！）数据库系列-

在高性能的服务架构设计中，缓存是一个不可或缺的环节。在实际的项目中，我们通常会将一些热点数据存储到Redis或MemCache这类缓存中间件中，只有当缓存的访问没有命中时再查询数据库。在提升访问速度的同时，也能降低数据库的压力。随着不断的发展，这一架构也产生了改进，在一些场景下可能单纯使用Redis类的远程缓存已经不够了，还需要进一步配合本地缓存使用，例如Guava

容易理解可由二维表结构来逻辑表达，相对网状、层次等其他模型更加容易被理解。严格遵循数据格式与长度规范，数据以行为单位，一行数据表示一个实体信息，每一行数据的属性都是相同的。2

是基于内存的数据库，所以当服务器出现故障的时候，我们的数据就得不到安全保障。这个时候就需要将内存中的数据存储到磁盘中，当我们服务器重启时，便可以通过磁盘来恢复数据，这个过程就叫做

业务需求是这样：获取最2021年的A类型账户数据，上报到大数据平台。一般思路的实现方式很多伙伴接到这么一个需求，会直接这么实现了：//查询上报总数量Integer

设计表时，我们需要选择合适的字段类型，比如：尽可能选择存储空间小的字段类型，就好像数字类型的，从tinyint、smallint、int、bigint从左往右开始选择小数类型如金额，则选择

Martin，是英国剑桥大学的一名分布式系统研究员。在此之前他曾是软件工程师和企业家，从事大规模数据基础设施相关的工作。它还经常在大会做演讲，写博客，写书，也是开源贡献者。他马上写了篇文章，质疑这个

不知从何时开始，实时数仓这个赛道变得越来越“卷”，湖仓一体、云数仓、传统数仓都在向满足业务的实时性需求演进，那么到底什么是实时数仓？未来，是否会有一个主流发展方向能统领全部技术路线？引领数据走向智能化新阶段“湖仓一体，或者云数仓，都更偏技术层面的基础能力，而从具体的数据应用场景看，其实是几大方向的融合。”滴普科技杨磊，在接受ITPUB实时数仓系列访谈时认为，不管是湖仓一体，还是云数仓，最终解决的问题都是实时的数据分析应用。尤其是湖仓一体，解决的是数据+AI问题，可以从根本上满足数据基础能力和应用创新需求，是实时数仓发展的重要方向。▲滴普科技杨磊回望过去，数据仓库并不是一个新事物，从Oracle到Teradata，到后来的MPP数据库，以及在整个过程中产生出来的包括Hadoop在内的大数据平台，再从Snowflake到云数仓，还有由Databricks定义的湖仓，其实都是关键发展阶段的代表。很多人提到的Hive、Spark，再到Flink，其实是整个大数据的“入口端”技术。Hive代表的是第一代的Hadoop架构，Spark代表的是第二代的Hadoop架构，Flink代表的是整个实时的大数据的架构。简单理解，实时数仓大概可以分为几个重要阶段，即数仓阶段、大数据阶段以及大数据和MPP数据库并存的阶段，最终出现了以Snowflake为代表的云数仓，近似于实时数仓这样一个概念。到最后，Databricks重新定义了湖仓一体的概念，即围绕数仓的能力，打造出全新的实时数仓的状态。其中，湖仓一体之所以能给用户带来更卓越体验，是因为在整个架构上实现了存算分离、流批一体，包括支持全量数据、数据存储，包括结构化、非结构化、半结构化的数据存储，在数据的事务处理能力上得到了进一步加强。因为像Hive这种技术，原来没有事务处理能力。另外，从整个引擎上来说，湖仓一体架构可以做进一步简化，易用性更好，而不像采用Hadoop开源架构那样，组件很多，需要多种不同能力模型的人，才能把Hadoop平台用起来。有句话说得好，“客户可以为技术鼓掌，而为业务买单”，湖仓一体让所有业务都具备AI能力，即让所有数据具备可以被分析、决策、预测的状态，让技术辅助业务，围绕最终目标不断演进，获得持续生命力。统一底层架构，拥有全链路能力而从用户实际落地案例来看，传统使用Hadoop以及MPP数据库的企业正在向湖仓一体化转型。以某时尚产业集团为例，该企业有很多传统数仓，有老的Oracle的数仓，还有OLAP、DB2、Teradata