【ArchSummit架构师峰会】探讨数据与人工智能相互驱动的关系>>> 了解详情
写点什么

车企数字化转型:数据,不仅是技术

  • 2019-09-05
  • 本文字数:8159 字

    阅读完需:约 27 分钟

车企数字化转型:数据,不仅是技术

数据不仅仅是个技术问题,更是关乎企业数字化转型生死攸关的关键因素,数字化转型的首要问题就是数据战略问题,那么数据战略问题具体如何解决?

数字化转型的本质是信息技术驱动商业变革

什么是数字化转型?


数字化转型应该如何定义?


对于以上问题,一千个人或许就有一千个回答。目光所及,这些回答覆盖了战略、管理、技术、业务、用户中心等等企业经营的不同领域,从工业 4.0、消费互联网到产业互联网,各自有各自的描述和解释。


那么,经过这么多年的转型实践,我们回头来看,最重要的驱动因素到底是什么?


让我们回到工业时代的最初。


尽管有着蒸汽机的帮助,人类的体力和脑力仍然是工业生产中必不可少的因素。经过这么多年的发展,机器越来越多地替代了人类的体力,但是脑力仍然是上个世纪最重要的驱动力量,哪怕是最初的计算机,也只是在增强人类的脑力而不是取而代之。


直到最近十年,情况发生了改变。


过去 10 年中,云计算、大数据和人工智能技术的发展,不断驱动机器智能替代体力和脑力,那些高频的重复的体力和脑力工作,越来越多地被机器智能所取代;而脑力赖以生存的经验公式(方法论、思维工具等等),也越来越多地被算法所代替。从这个意义上,算力才是这个时代真正的驱动力量,算力对于体力和脑力的替代,是过去十年来,人类面临的最大挑战之一,既往的运营和商业模式不断被颠覆。


所以,站在今天的角度,我们或许可以清晰地定义数字化转型,本质上就是以算力、算法和数据为代表的信息技术,以数字化的方式驱动社会整体的改变和变革。数字化转型的未来清楚指向人工智能的发展,从而让人做人该做的事情,让机器做机器该做的事情,人类和机器脑力算力协同发展。



人类所面临的挑战并不止于此。


曾经有一本名为《富足》的书指出,当人类社会从物资材料的供不应求到供过于求的富足状态之后,社会的组织模式和商业模式都发生了巨大的改变。吃不饱穿不暖,曾经是过去几千年来人类社会的主题,但是今天,当这些不再是问题的时候,人们迷茫了,我们到底需要追求什么?


用同样的视角去观照数据,我们会发现什么?


下图来自于互联网女皇的报告,从图上我们可以看到,进入 2010 年以来,人类社会的数据量有了巨大的增长。原图没有告诉我们的一点是,2015 年是人类社会数据增长的一个关键节点,因为在 2015 年,其一年产生的数据量是人类过去历史上产生的数据量的总和。换句话说,人类的数据量自此进入了指数级增长,2015 年之后,数据量每年增长 40%-50%,这也被称为「新摩尔定律」:人类有史以来的数据总量,每过 18 个月就会翻一番。


如果你还记得那个阿拉伯童话中国王和算师关于在棋盘上放满米的故事,那么,你就会知道,这种指数级增长的数据增量有多么巨大。人类社会或许即将从数据的供不应求到数据的供过于求的状态。从这里我们或许可以理解,为什么马老师说未来所有的公司都将是「数据公司」。



阿里巴巴曾经就是经历过这种数据增长的公司,在很长一段时间内,日益增长的数据存储费用和仍然稀缺的数据应用之间的矛盾一直都是阿里巴巴的主要矛盾。阿里巴巴为什么要「去 IOE」?传说王坚给马老师算了一笔账,如果仍然使用 IOE 架构来存储数据,那么,十年后,阿里巴巴的数据存储费用将 10 倍于其收入,届时,阿里巴巴必将破产。


目前,大部分的公司仍然处于数据的加法阶段,但是,在车企身上,我们已经看到了数据跨越式增长的苗头。这个苗头叫做「车联网」。


随着车企的电动化、智能化、网联化,车企也收集到了相当庞大的数据,一天 4G、一年 2.5 亿行、3 年后至少超过 200T……类似这样的描述,在大部分的车企都能听到。或许,车企的数据量增长还不能称为指数级增长,但是,相比之前,至少已经是乘数级的增长了。


那么,怎么办?


作为一家已经跨越了数据指数级增长的公司,阿里巴巴的经历或许可以给我们启示。

阿里巴巴如何跨越数据指数级增长奇点

2007 年,阿里巴巴在战略会议上决定阿里未来要成为一家数据公司。但真正在数据上有所建树,却要把这个时间延后到 2009 年,阿里云也诞生在这一年。大体上可以把阿里的整个跨越过程分成三个阶段:



第一个阶段:2009-2012 年,主题是「看见」。


从 2003 年成立以来,淘宝收集了大量的数据,其中 90%是非结构化的日志数据,当有了这些数据之后,所有人都想看见数据背后的真相:我的用户从哪里来,他们买了什么,为什么购买,转化率如何……这些问题我们大体都可以归结为两个基本问题:发生了什么?怎么发生的?


和「去 IOE」同步发生的,是阿里加大了对于 BI(商业智能)的需求,用数据「看见」答案的 BI,在这个阶段是阿里存储和计算资源消耗的主力军。阿里巴巴也是第一个设立 CDO(Chief Data Officer,首席数据官)的公司,第一任 CDO 是后来的阿里巴巴 CEO 陆兆禧,有意思的是,后来成立的数据平台部因此也习惯性被内部称为 CDO。


第二个阶段:2012-2015 年,主题是「使用」。


一个标志性的事件是 2012 年数据平台部的成立,这个被称为 CDO 的部门,源于七公组建的数据平台团队,在这个团队手上,诞生了一系列数据分析和挖掘工具,包括在云端、数据魔方、淘宝时光机、淘宝指数、TCIF 等等。这里特别要提一下 TCIF(淘宝消费者数据工厂),拉通了阿里巴巴所有的消费者数据,并且完成了 3000+标签体系的建设,这些标签每个用阿里妈妈做精准营销的同学应该都见过,就是达摩盘里面那些勾选的选项。


2012 年的标志性事件,就是 TCIF 的存储和计算消耗量超过了 BI,以 TCIF 为代表的人群定向成为了计算资源的消耗大户;另一个标志性的指标是,阿里巴巴有 50%的服务器不再处理任何事务,而仅仅用于处理数据。


这个阶段,阿里巴巴开始真正实现了用数据预测未来的问题,更好地帮助业务去回答:为什么发生?未来将发生什么?


第三个阶段:2015 年至今,主题是「赋能」。


同样,2015 年也有两个标志性事件:一是阿里云数加平台的成立(行在创立),这代表阿里巴巴开始把内部形成的大数据能力外化,赋能社会去建立大数据能力;二是推出千人千面算法,推荐算法一跃成为了存储和计算资源的头号消耗大户。


推荐算法不仅仅是我们看到的淘宝界面那么简单,在某种程度上,推荐算法让阿里巴巴跨越了「从人指挥机器到机器指挥人的奇点」,今天阿里巴巴 75%以上的 GMV 都由机器来运营,流量由机器来精准分配,相比之下,天猫淘宝等等全部合在一起也只有几千个运营小二,人效高得可怕。


经过这三个阶段,我们可以认为,阿里巴巴已经围绕数据完成了数据工业化生产链条的搭建,并且围绕着数据链条建立了丰富的数据生态。相比之下,太多的公司还处于数据的手工劳作阶段,而这给企业的数字化转型带来了非常不好的影响。


包括最初的连接买家和卖家的阶段在内,连接——看见——使用——赋能四个阶段,让阿里巴巴成功跨越数据指数级增长的奇点。

积极进取的车企数字化转型

除了互联网公司之外,汽车行业是最积极拥抱互联网的行业之一。特别是随着车联网、电动车和新能源车在近些年的突飞猛进,车企也投入了大量的资金和精力在 IT 基础建设和先进技术研发上。


大体上,这些尝试除了生产制造端(这是另外一个大话题,更偏向工业 4.0),可以分为

以车和服务为中心的技术重构

比如,以电动化、网联化、智能化为导向的未来汽车战略,以及围绕数字化出行打造全方位的服务能力等等。根据普华永道思略特的估计,到 2030 年,供应商业务、车辆销售和售后市场等传统行业的利润份额将从 71%降至 41%,车企需要向出行服务商方向转型。


从以车为中心转向以人为中心

车企传统上都围绕车的价值链来构建其组织结构,也就是图中右边那个半圆,而把人的价值链指定给销售或者市场营销来负责。但今天,越来越多的车企发现,人的价值链应当和车的价值链处于相同的地位,像蔚来这样的造车新势力,甚至其组织架构完全围绕用户来构建。从核心场景上看,车企都需要打通人车数据,构建人和车的全生命周期管理能力,通过数据资产化和业务智能化来突破业绩瓶颈。


消费者海量个性化需求倒逼车企推动四化

2010 年以来,随着电子商务、社交网络和移动互联网的发展,个性化、多样化的消费需求海量涌现。比如,有的消费者希望像淘宝购物一样,能看到买车的全部物流过程;有的消费者希望能定制个性化的颜色……但是,这些需求,仅仅依靠主机厂传统的信息管理系统和架构,无法得到满足。车什么时候能到店?什么时候能提货?这些简单的信息都尚未实现在线可查询,就更不要说提供复杂的个性化服务了。车企很早就意识到这一点,并且开启了云化、服务化的进程,来实现大规模精细化的人车匹配,只是结果难称满意,原因会在稍后表述。


人工智能驱动的组织进化已经悄然开始

越来越多的车企认识到,那些重复性的机械劳动,未来一定会被人工智能所取代,其中不仅有事务性和劳务性的工作,甚至有很多知识性的工作,也有极大可能被机器所取代。那么,接下来,车企就将面临严峻的挑战,需要重塑人工智能赋能的员工和团队,以及,车企未来的核心竞争力和吸引力也将来自于企业通过人工智能为员工提供支持、预测新型需求和推动工作职能的能力。


被忽略的数据,或将成为车企数字化转型的阿喀琉斯之踵

尽量已经在技术上和业务上做了众多的尝试,乃至找了传统的咨询公司来为数字化转型出谋划策,但是车企遇到的数字化问题却越来越多了。


新技术的广泛使用,在部分解决老问题的同时,又带来了更多的新问题:为什么我采集的数据,一半是空值?我有了那么多数据,要如何变现?如何对业务产生价值?就算用了新的系统,为什么还是黑箱决策?


在做咨询的时候,我第一时间都会观察,或者直接提问,这家公司的数字化转型是否有核心项目?(也就是通常所说的「一号工程」)是否是公司或部门最高领导直接出任负责人?以及,技术规划是否有效解决了现有问题?



通常情况下,所得到的答案在数字化转型的重要性上,表述相对清晰;但是落地到整体的项目规划,以及项目对业务的贡献,就会变得面目模糊。以及,常见一种表述,「数字化转型是公司一号工程」,然而,再往下,「数字化转型」的实际定义千差万别,有建数据库的,有建平台的,有开展创新项目的……唯一的共性大概是「先试试水」。


试水的好处在于,暴露了问题;坏处在于,试水所总结的经验常常并无助于解决问题。


总结下来,目前车企试水暴露的问题主要有三个:


1.数字化转型缺乏顶层规划和设计,各个部门各自为阵,基于各自的数字化转型理解,开展转型工作;


2 业务问题背后常常体现为数据问题,比如数据质量不行,数据统计口径不一致,数据不通等等;


3.IT 和业务的配合问题,业务所表达的需求,通常不是真正的业务诉求和痛点,而更多体现为「别人有的功能我也要有」。


先说第一个问题:顶层设计。


首先需要明确一点,所有的技术、所有的项目都为实现公司战略目标服务,但是公司的战略资源有限,需要在合理规划前提下,最大化利用现有资源和技术,然后才是项目管理的问题,这是顶层设计的初衷。


因此,所有的顶层设计问题,都需要回到本源「为什么样的客户提供什么样的价值」上来,从业务价值的角度倒推到项目优先级上,然后再考虑项目管理的问题;


其次,通常认为,项目的质量由 money、time、scope 三个因素决定,这也构成了一个项目管理的不可能三角:要想少花钱、短时间覆盖大量业务需求,那么项目质量就不会好。要么多花钱,要么多花时间,要么就明确少量的业务需求,只有这样,数字化转型项目才能比较高质量地转化成业务成果。



再说第二个问题:数据问题。


这是一个经常被管理者和员工挂在嘴上,但是并没有被企业提升到战略高度来正视的问题。


SKOTT 评估法认为,企业数字化转型需要关注战略、KPI、组织、数字技术和数字人才五个维度,才能减少和避免转型风险。我们非常认可并且对此进行了量化(量化方法容后描述),以及根据信息技术的特点,把数字技术拆分成了算力、数据和算法三个维度,来对企业的数字化转型现状进行评估。


评估结果,一句话描述就是:缺乏清晰的数据战略拖了车企数字化转型的后腿。或者说,到目前阶段,车企数字化转型首先要解决数据战略问题。


通常车企在战略部署和算力部署上都走得相对靠前,但是,很遗憾,如果把所有的 7 个维度拉成进度条,那么,数据的进度是最慢的。不仅如此,通常车企在 KPI、组织和人才也都相对表现不佳,而这些也都多多少和数据进度有关系。


比如说,因为缺乏数据战略,所以公司在数据相关的组织设立上,通常也行动缓慢,在数据和算法需要的相关人才招募和培养上,也缺乏相应的薪酬体系和激励机制,更不清楚目前缺什么人才和角色。顺带一提,根据我们的咨询经验,目前企业普遍最缺的角色是业务架构师、产品经理和数据分析师。


因为数据不通和数据质量问题,企业也很难从指标上对于数字化转型进行 KPI 定义,比如说,数字化业务利润占比,那么,哪些业务算数字化业务利润,哪些又不算呢?占比多少合理呢?这也导致缺乏有效的 KPI 来指引公司的转型事务,只能各个部门各自来定义。


以阿里为标杆,我们从数据的「存通用」角度也对车企的数字化转型现状进行了评估,从下图可以看到,数据尚未中心化,是现在车企普遍的现象。数据不通和数据质量问题也进一步导致了车企有算法但没有成果,有数据采集但没有质量,有算力部署但没有数据变现。



从这个评估来说,车企就像看着已经被 IT 武装到牙齿的希腊英雄阿喀琉斯,但是却因为对数据这个脚踵不够重视,一旦被业务的流箭射中就常常寸步难行。


所以我们常说,你不琢磨数据,数据就会琢磨你。


最后再说下第三个问题:业务配合问题。


这其实是一个很大的命题。


首先,这是一个组织问题。传统定义上,业务作为前台部门,要如何和 IT 这个后台部门分工合作,有一套传统的流程,但是今天,这种分工合作流程越来越不能适应企业数字化转型的需求,需要打破体制,包括项目预算、方案设计、KPI 等等都需要重新设计。


其次,这也是一个业务问题。传统前台业务通常把 IT 视为系统和工具的提供者,IT 不需要懂前台业务,IT 在业务分工里只是一个保障角色。当企业说业务价值的时候,通常说的是前台工作,而较少提及 IT 的价值。但是,当今天越来越多的技术创意引领公司业务,当业务落地需要技术交付的时候,IT 就不只要解决技术问题,还需要理解业务,能够和前台一起解决业务问题。这不仅需要跨界人才,也需要制度设计。


最后,这当然是一个技术问题。让 IT 做业务,让业务做技术,这都是不现实的解决方案。那么,IT 就需要能够面向未来,为业务提供技术保障。麻烦在于,今天的技术保障,不仅仅是系统建设和 IT 部署这么简单,还包括数据和算法的解决方案规划、线下数据的收集能力建设、数据应用能力的建设等等一系列超出传统 IT 定义的建设部分。这里面,还有一些类似标签化这样,需要业务一起参与和沉淀的项目,以及拉通前后端供应链数据这样的跨业务领域项目,这些项目甚至需要 IT 从技术角度先进行规划,由 IT 来拉动整个项目合作。

数据,不仅是技术问题

2015 年,MIT 斯隆管理评论和德勤一起,做了全球数字化企业高管调研,研究结论也成为了后来报告的标题,《战略,而不是技术,在推动数字化转型》。其研究表明:「数字化架构企业这个能力很大一部分程度上依赖于一个清晰的数字化战略,一个是被领导人所培育的能够改变和创新的文化支持的战略。」


只是就研究本身而言,只停留在数字技术的运用上,而并没有任何提及数据的地方,或许,其研究对象都把数据视为数字技术的一部分,或者把数据视为面向客户分析的材料而已。


对数据的忽视也是今天谈大数据常常陷入困局的原因。


对于大多数企业而言,并没有十分迫切的海量数据处理需求,在增量时代生意很好做,也并不需要通过数据挖掘来辅助精细化运营、数据化决策等等。但是当市场进入了存量拼杀时代,每个公司都需要在保有自身份额同时,从竞争对手手上抢夺存量市场,业务对数据质量和数据挖掘的需求突然就爆发出来。每个人都想知道,经营问题到底出在哪里?如何推动业绩继续增长?


另外,人工智能在近几年的发展,也引发了有识之士的关注。我们经常听到的问题包括:如果所有高频的重复的机械作业,都将被机器所取代;如果所有事务性和劳务型的工作,都将被人工智能所取代,那么,企业将会是一个什么形态?在人工智能主导的社会里,企业最重要的战略资产是什么?


进一步拆分算力、数据和算法的获取方式,可以发现,算力和算法都可以通过公共供给来获得,比如说上云,或者开源算法,唯独数据很难从市场上获得。而且,随着国家和民众对于个人隐私和个人信息的重视,在没有成熟的数据交换市场之前,数据将越来越难以通过购买方式获取。


简单来说,数据是唯一一个需要通过企业自身积累而来的要素,然而,和汽油类似,一旦没有炼油厂去处理石油原油把数据变成可用的汽油,没有加油站去给汽车加油,那么,数据就是躺在数据仓库里的原油而已,看得用不得。


这点,车企应该深有体会,特别是随着车联网和电动车的推进,车企沉淀了大量的相关数据,每天至少几个 G 的增长量,却没有产生任何业务价值。「我能用这些数据干什么?」这是调研过程中最常被问到的问题。


以及,正如上文所描述的三个问题,数据如何处理和消费,从来就不只是一个技术问题,而是涉及到业务价值、技术规划和组织保障三个领域的综合战略问题。要想解决技术问题,也需要从这三个维度入手。

如何从数据资产管理的角度推动企业数据战略

根据我的研究结果,目前有三种推进企业数据战略的主要方式:


整体评估,组织先行

这是及其少见的一种推进方式,目前也仅仅在阿里和华为等少数公司身上有所体现。在这些公司,随着公司战略调整,首先就会先进行组织调整,比如阿里巴巴在马老师提出「新零售」之后,就会迅速在人力资源层面增加「HR-新零售线」,来统一进行人力资源的规划和安排。这件事情有多可怕呢?借用一位老师的观点。他说传统理论都认为「船大难掉头」。但是,现状却是,像阿里巴巴这样的巨型企业,因为拥有了优秀的基础设施,面对市场变化,可以迅速地掉头;而小企业反而因为缺乏数据缺乏有效规划「船小难掉头」。这就颠覆了传统的管理理论。

业务先行,小步快跑

经验数据,90%-95%的公司都会选择这种方式来推进企业数字化转型。简单来说,IT 部门会先从业务最迫切的需求、或者最能够出成果的需求入手,使用数字技术手段来推动业务「试水」。如果有成果,那么就可以把该项目变成明星项目,说服企业高管和其他业务部门继续采用数字技术;如果失败,那么就继续寻找下一个明星需求。主要就是通过小步快跑试水累积数据、累积技术能力,以及来为下一步的技术规划提供判断。

技术先行,大步前进

这类企业通常都有比较明确的数据中台(平台)建设和数据资产管理体系的建设需求,尽管可能并没有明确数据在企业内的重要地位,以及如何去规划和建设数据中台和数据资产管理体系,但是都经过了前期研究和讨论,明确了建设需求。从我的理解来看,这些企业都希望用数据中台(尽管词义模糊不清)实现企业数字化转型的跨越式发展。这类企业,对于数字化转型咨询的需求也最为迫切。


不管是哪种方式,我们认为,其内在的发展逻辑都会类似于阿里巴巴的经历,先通过低成本的业务在线化「连接」企业和客户,再通过数据在线化「看见」业绩和顾客,然后建立数据「使用」能力来预测未来,最后用数据智能「赋能」业务转型成服务公司或者平台公司。


相对而言,我们更推荐「技术先行」的方式,因为不管选择哪种方式,都会需要数据中台以及数据资产管理体系,像经营人力资产一样经营企业的数据资产。


当然,也可以寻求以数据资产管理为核心的大数据咨询。



从上图可以看到,传统的咨询通常是针对某一二个领域进行战略咨询和规划,比如管理咨询、财务咨询、品牌咨询和人资咨询等等,其方法论基于经验总结而来,通过跨层级跨部门的调研,为企业提供第三方的中立数据以及规划建议,便于企业高层决策。但是这些经验里面,并不包括数据资产管理经验,因此,需要有相应经验的公司来提供咨询服务。这也是提出大数据咨询的初衷。


另一方面,大数据咨询的特殊之处在于,除了商业因素和组织因素,还需要把 IT 和数据考量在内,并且从能力建设的角度提供解决方案的建议,也就是不仅要面向需求端解决问题,更需要面向解决端提供能力,这也意味着大数据咨询需要有端(需求)到端(解决)的解决能力。这也是大数据咨询和其他咨询方式的不同。


公众号推荐:

跳进 AI 的奇妙世界,一起探索未来工作的新风貌!想要深入了解 AI 如何成为产业创新的新引擎?好奇哪些城市正成为 AI 人才的新磁场?《中国生成式 AI 开发者洞察 2024》由 InfoQ 研究中心精心打造,为你深度解锁生成式 AI 领域的最新开发者动态。无论你是资深研发者,还是对生成式 AI 充满好奇的新手,这份报告都是你不可错过的知识宝典。欢迎大家扫码关注「AI前线」公众号,回复「开发者洞察」领取。

2019-09-05 23:444033

评论

发布
暂无评论
发现更多内容

迁移prometheus数据

TiDB 社区干货传送门

迁移 实践案例 集群管理

WordPress 使用 TiDB Cloud 替换 MySQL

TiDB 社区干货传送门

迁移 实践案例 版本测评 应用适配

PCB阻焊桥存在的DFM(可制造性)问题,华秋一文告诉你

华秋电子

用数据分析的方法去做dba,维护好tidb数据库。

TiDB 社区干货传送门

6.x 实践

AIGC的阿克琉斯之踵

华为云开发者联盟

人工智能 AI 华为云 华为云开发者联盟 企业号 4 月 PK 榜

Mysql 连接查询

新特性解析丨TiDB 资源管控的设计思路与场景解析

TiDB 社区干货传送门

版本测评

python正则 | python小知识

AIWeker

Python python小知识 三周年连更

微服务 - 注册中心和配置中心(Consul)

做梦都在改BUG

Java 微服务 注册中心 配置中心

Karmada 多云容器编排引擎支持多调度组,助力成本优化

华为云开发者联盟

云原生 后端 华为云 华为云开发者联盟 企业号 4 月 PK 榜

免费领取 | ONES 联合中国信通院发布《中国企业软件研发管理白皮书》

万事ONES

苹果电脑臻选4K壁纸app:Dynamic Wallpaper

魔仙苹果mac堡

动态壁纸 Dynamic Wallpaper下载 苹果壁纸下载 mac壁纸一软件 高清壁纸下载

国内外主流的8款 IT 项目管理平台

PingCode

项目管理工具 PingCode 项目研发管理软件

【Linux】之创建普通用户并禁止root用户远程登陆

A-刘晨阳

Linux 三周年连更 用户名

即时通讯技术文集(第13期):Web端即时通讯技术精华合集 [共15篇]

JackJiang

网络编程 即时通讯 IM

从零到跑通TPC-H:如何快速实现查询计划

MatrixOrigin

分布式数据库 MatrixOrigin MatrixOne TPC-H

GitHub星标48k!蚂蚁金服开源的这份SpringBoot笔记

做梦都在改BUG

Java spring Spring Boot 框架

迁移PD坑-cdc任务全部stop

TiDB 社区干货传送门

实践案例 集群管理 故障排查/诊断

Parallels Desktop PD 18虚拟机关闭、停止、中止和暂停操作的区别

魔仙苹果mac堡

pd虚拟机 Parallels Desktop PD18虚拟机操作

maya软件在建模上有什么优势?

Finovy Cloud

maya 3D软件

谷歌 Chrome 正式发布 WebGPU!Orillusion开源倒计时!

Orillusion

开源 WebGL 元宇宙 web3d #WebGPU

面试官:Redis有什么持久化策略?

做梦都在改BUG

Java redis 缓存 面试 持久化

超强版干货投递!Milvus 的部署心得、运维秘籍都在这里了!

Zilliz

Milvus Zilliz ChatGPT LLM zillizcloud

阿里P8推荐学习的44个微服务架构设计模式,真的太香了!

做梦都在改BUG

Java 架构 微服务 设计模式

tidb-loadbalance 客户端方式软负载均衡配置实践

TiDB 社区干货传送门

数据库架构设计 数据库连接

AutoCAD 2024 Mac版如何设置自动保存文件为低版本?

魔仙苹果mac堡

CAD制图软件 AutoCAD 2024 Mac版 AutoCAD使用技巧 保存文件为低版本

Mac人工智能图像降噪 Topaz Photo AI 安装激活教程

魔仙苹果mac堡

Topaz Photo AI下载 图像降噪 苹果mac软件下载 Topaz Photo AI mac Topaz Photo AI破解

Neuron 2.4.0发布:体验下一代工业物联网连接和管理

EMQ映云科技

UI 物联网 IoT neuron 企业号 4 月 PK 榜

4 月 25 日直播预告 | 深入解读 Flink 1.17

Apache Flink

大数据 flink 实时计算

OneNote 2019 for Mac 中文版附激活工具

真大的脸盆

Mac Mac 软件 笔记应用

TiDB迁移、升级与案例分享(TiDB v4.0.11 → v6.5.1)

TiDB 社区干货传送门

迁移 版本升级 安装 & 部署 扩/缩容 6.x 实践

车企数字化转型:数据,不仅是技术_AI&大模型_何夕@奇点云_InfoQ精选文章