最近有童鞋在我之前发布的《聊聊中台》一文中提问:技术中台是什么?和业务中台又有什么区别?考虑到在工作中,也有部分同事问过这个问题,我这里总结一下形成此文进行答复。 所谓平台,即中台的主要形式,它通过对于更细粒度能力的识别与平台化沉淀,实现企业能力的柔性复用。 在之前我的《聊聊中台》一文中,重点强调和介绍了业务中台,这是大部分谈论中台的人谈到的中台类型,因为不论什么中台,最终都是为业务服务,赋能前台,提高企业的用户响应力的。 [一个常见的电商业务中台示例图] 2、技术中台又讲了什么 虽然我比较认可网易云的观点“所有的中台都是业务中台”,而其他的中台其实都是一种广义上的业务中台,被称之为中台,就需要具备一定的业务属性,最终都要为业务服务 (均来自于波波老师的《Spring Boot与K8s云原生应用开发》课程PPT) [eBay中台体系示意图] [拍拍贷中台体系示意图] 3、我司的业务中台与技术中台 分享一个我司目前的总体技术体系图,这是我在
幸运的是,这一年个人的主旋律仍然还是围绕着中台这个既火热又充满争议的主题,只不过关注点逐渐从Why和What逐渐过渡到How,也就是对于如何构建中台的通用方法论思考、研究与应用上。 在各种讲中台落地规划,尤其是业务中台的共性能力识别和微服务划分的时候,总是能看到这两位的身影。不过相信好多朋友对于这两个相对陌生的面孔还是感觉云里雾里,搞不清楚到底是什么,以及与中台的关系。 ---- DDD、EventStorming与业务中台 我之前的文章曾提到过业务中台与微服务的关系,而当时我的观点很简单,就是:没有直接关系。 ,这套领域分析方法,则可以指导我们探究与分析业务中台规划过程中的一个最困难的问题,既:识别不同的业务线,到底有哪些业务是可以复用的? 而这种通过领域分析和抽象,找寻不同业务线背后面对的相同的问题域,并从中提取共性的业务模型、提取共性的业务功能、提取共性的业务流程、甚至是提取共性的业务模式,加工并予以复用的过程,也正是业务中台的规划与建设过程的关键所在
但在日常开发里,各个因素都可能极大提高问题的复杂度,所以除了清晰地理解业务诉求之外,更加需要我们通过建模的方式对这种复杂度进行简化与精炼。 作为一种建模方法,虽不是那么出色,然而却能够在如何引领需求发掘,如何建立沟通反馈,如何与业务方共建模型等问题上,提供到一套出色的框架。 最后我会介绍四种建模方法,分别是:催化剂法、角色 - 目标 - 实体法、事件风暴与四色法,以弥补领域设计在建模能力上的缺陷。 二、新约:“云时代”的业务建模 如今,云时代彻底改变了我们构造软件的方式,微服务、中台、软件的 SaaS 化都是这一影响的体现。 其次,我会介绍一种由我发明的业务建模方法 8X Flow 法,用于解决微服务、分布式事务为主导的架构风格中的业务建模问题。这个方法同样可以用于构建中台系统,也是我司目前用于中台建模的主要方法。
2015年左右底,“中台”这个词 迅速在互联网走红,众多互联网大厂纷纷投入到“中台”的战略布局中,转眼间,到了2024年,曾经风靡一时的中台迎来了退潮时刻。 本文将阐述我对于中台建设的一些思考和浅见,希望可以引发技术人的思考。 本文作者将在下周三晚做客腾讯云开发者视频号「鹅厂程序员面对面」直播间,分享中台、建模、领域驱动等干货内容,提前预约抢占前排座位! 如果是中台围绕着业务发展,这个关系就从 “中台提供能力 变成了 中台接受需求” 业务同学会把一些定制化需求抛给中台,这好像又违背了中台围绕复用能力建设的初衷,如果有100个业务同时提需求,中台可以抗的住吗 4.2 变与不变 唯一不变的是变化,面对市场的变化,技术架构应该如何快速的应对,有几点想法可以谈谈: 中台建设更适用于有稳定基本盘的业务,稳定就意味着变化少,变化少,才更方便的去抽象出可复用的能力。 中台的建设需要有对业务领域有认知极强的专家团队,并且需要有极强的建模能力,以及可以找到业务的本质以及 get 到业务和技术的衔接点。
而数据中台的概念显然更加抽象一些,比如用友把数据中台作为其云平台的一部分,同时提供业务中台和技术中台;咨询机构罗兰贝格认为数据中台的本质是数据共享、整合和深度分析;奇点云强调数据中台的能力是“计算平台+ 所以关于主数据与数据中台有什么区别,不同的人基于实践可能会有不同的见解,下面收集了几个对于二者概念、内涵的精彩回答,供大家参考。如果还有更多真知灼见,欢迎扫描文末二维码添加好友入群探讨。 业务中台重点是业务数据化,而数据中台重点是数据业务化,数据来源于业务又反哺业务。 在数据分析平台中,通过对数据的加工和整合,通过与基础数据平台进行修整和清洗的黄金数据进行关联,通过产品的内置图形化组件将数据进行可视化展现等手段,可以大大地提高企业领导层的决策能力和企业数据的分析能力。 在企业系统架构中的位置与传统架构中的ORM层相当,只不过,数据中台功能上要同时处理结构化,非结构化,文档类型,影音类型,空间类型......等各种数据,性能上要能支持海量数据,高可用,高可靠等等。
前言 今天要分享的主题是:对中台的探索与思考。 中台概念如今已经不是什么新的名词了,相信大家对中台都有所耳闻,目前各大企业已经先后开始建设自己的中台。 那中台到底是什么?为什么大家要建设中台? 平台:平台是建设中台的基座,建设中台之前一般都是先建设平台 说到这,正好可以引出一个话题,中台与平台有什么区别。 我们来看一下平台的概念。 平台对比与中台更偏向底层。 中台的类型 关于中台的类型,主流的分类就是业务和数据双中台架构了。 技术中台可以认为是更加底层的技术基座,与业务关联可能不大,技术中台有点类似于平台的概念。 技术中台是建设中台的第一步,前台业务团队接入技术中台,阻力比较小. 某数据中台 在数据中台中,首先要实现数据资产化,三大体系保证了数据资产化顺利进行: (1)One Model:简单的理解就是数据模型的统一,我们不用重新建模,只要调用数据中台中已有的模型即可,一个模型可以被多个业务部门共享
(DWD,Data Warehouse Detail) 原始数据层(ODS,Operation Data Store) 数仓为什么分层 隔离原始数据:不论是数据异常还是数据的敏感性,使真实数据与统计数据解耦开 操作数据层(ODS) 数据与原业务数据保持一致,可以通过增加字段方式对数据整理 业务系统对历史数据完成修改后,在字段中进行标识,而不覆盖元数据。 实现方式一 使用日期分期表,全量数据记录,每天的分区存储昨天全量数据与当天的增量数据合并的结果 数据量大会导致全量表膨胀,存储大量永远不更新的冷数据,降低性能 使用于数据量少的情况 实现方式二 MOLAP 系统建模 MOLAP 将数据进行预结算,并将数据结构存储到 CUBE 模型中。MOLAP 产品:Kylin、Druid CUBE 模型以多维数组的形式,物化到存储系统中,加快后续的查询。 [外链图片转存中…(img-uQis5F2c-1645262440294)] 范式 第一范式:属性不可分割 第二范式:消除不分函数依赖 第三范式:消除传递依赖 关系建模与维度建模 关系建模:将复杂的数据抽象为两个概念
hello大家好我是人月聊IT,我今天接着跟大家介绍我们整个云原生技术中台里面关于低代码平台它整体的总体架构的一个情况。 但是一直没讲过我们整个低代码平台的总体架构;最近几天我又刚好梳理了一下我们的低代码平台,重新把原来我们的整体的架构图做了一下规整,在整个低代码总体平台的架构里面我们可以看到,它底层仍然是依托我们的云原生的技术中台 数据字典、权限菜单、最外层的门户界面,这些功能全部都已经具备;在这些功能已经具备的情况下,后面开发完的每一个低代码应用或者说开发完的每一个微服务,他都可以通过我的持续集成快速的交付到我的整个低代码运行环境中。 在开发态我们基于对象建模驱动,包括了对象建模、数据建模、表单建模、规则建模、流程建模、报表建模;对象建模完成了以后,它朝下可以生成相应的数据对象开放相应的a b c接口能力,朝上又去衔接我们的表单建模和报表建模 这些就是我讲的整个低代码平台从开发态到运行态它本质的一个转移,通过开发态和运行态的解偶,低代码平台开发出来的应用它也是一个标准的可扩展的微服应用,同时它是可以完全脱离我的低代码开发框架和环境运行的应用在整个低代码平台开发完成以后,最上层也是我们常说的统一的与服务中心
在现代数据库系统中,数据建模与性能优化是确保系统稳定、高效运行的关键环节。面对海量数据和多样业务场景,数据库需在数据结构设计、查询执行效率及存储管理等多方面实施优化。 建模时,应根据业务需求合理设置PCT FREE参数,预留足够页面空闲空间以降低行迁移和链接,优化插入与更新性能。BTREE索引:组织成平衡有序的B树结构,支持唯一性约束和高速索引查找。 数据库安全与访问控制优化安全设计在数据建模中扮演重要角色,YashanDB多维度保障数据库安全:用户与角色管理:通过权限最小化原则,基于角色的访问控制实现权限粒度细化,配合三权分立管理减少内聚风险。 结论本文基于YashanDB的体系架构和核心技术特点,全面分析了数据库的数据建模和性能优化实践。 通过合理的数据存储结构选择、有效的分区方案设计、事务与并发控制优化、SQL执行效率提升、存储空间管理优化、高可用架构规划及安全体系完善,能够大幅提升YashanDB在复杂业务场景中的性能与稳定性。
从管理视角看——为什么是数据中台而不是数据XX 从技术视角看——数据中台与数仓、数据湖到底有没有本质区别 从业务视角看——企业需要什么样子的数据中台 1、从管理视角看——为什么是数据中台而不是数据XX 数据中台,在这个角度,正好与企业的需要不谋而合。 数据中台是为前台业务而生,它提供了一种数据与业务之间协作发生化学反应的最佳模式。 数据中台形成可共享复用的数据资产,并且拥有与业务更近的关系(一般情况下的数据中台是要扛业务KPI的),让企业首次有了数据驱动业务的能力,以及随之带来的对组织和人才结构的优化,这些才是数据中台真正的竞争力 而数据中台首先在体系架构上与数仓就有很大的不同,数据中台是由多系统组成的,其计算和存储平台是建立在分布式系统之上,以满足不同业务需求和高并发高扩展性需求。 除了计算和存储平台外,一般数据中台还应包含数据集成、数据开发、数据建模、数据资产管理、数据治理以及数据服务等多个组件,通过多个维度组件形成一整套方案。
到处都在喊中台,到处都是中台,中台这个词在好多地方已经被滥用了。 在有些人眼里:中台就是技术平台,像微服务开发框架、Devops平台、PaaS平台,容器云之类的,人们都叫它“技术中台”。 在有些人眼里:中台应该是组织的事情,类似于企业内部资源调度中心和内部创新孵化组织,人们都叫它“组织中台”。 中台,从字面意思上理解,是位于前台和后台之间。 那么,中台到底是什么呢? 谈到中台,首先会想到阿里巴巴,今天就从阿里中台开始,一起认识下中台到底是什么?到底如何发展而来的呢? 阿里中台的发展历程 ? 到此,共享事业部的发展与大多数人的期望有很大偏差。 看看接下来又发生了什么故事,如下图: ? 2010年聚划算出现了。 正是有了这“点睛之笔”,共享事业部便有了一个极强的抓手,将原本与三大电商平台对话权不平等的情况拉平,这使得“共享事业部”成为了阿里巴巴集团的核心业务平台。
我很赞同这位同学的观点,中台本身就是一个比较抽象的概念,很多时候我们被那个“中”字困住了,整天在前与中、中与后的具体差别和评判标准上纠结不已。 中台与前台的划分原则是什么? 中台化与平台化的区别是什么? 中台化和服务化的区别是什么? 中台该怎么建设? 同时企业级也是区分企业中台化与应用系统服务化的关键点,简而言之中台化是企业级、是全局视角,服务化更多是系统级、是局部视角。 提到中台,最常听到的一个词就是「能力」。可能是因为能力这个词足够简单,又有着足够的包容度与宽度。 ,区分开了单系统的服务化与微服务; 「能力」定义了中台的主要承载对象,能力的抽象解释了各种各样中台的存在; 「复用」定义了中台的核心价值,传统的平台化对于易复用性并没有给予足够的关注,中台的提出和兴起,
产品与产品之间的技术出入会导致应用的出错,最终影响用户对产品的信任。由此,集成式的建设方式给技术部门形成巨大的维护成本和治理成本,并没有达到数据中台建设的真正目的。 数据中台帮助业务部门建立工作台,通过工作台可以快速获取到数据相关服务,包括数据提取、数据分析、数据推送、数据回流等服务;数据中台可以将脏乱差的数据进行加工、治理、切分、建模、打标签等。 产品与产品之间的技术出入会导致应用的出错,最终影响用户对产品的信任。由此,集成式的建设方式给技术部门形成巨大的维护成本和治理成本,并没有达到数据中台建设的真正目的。 数据中台帮助业务部门建立工作台,通过工作台可以快速获取到数据相关服务,包括数据提取、数据分析、数据推送、数据回流等服务;数据中台可以将脏乱差的数据进行加工、治理、切分、建模、打标签等。 数据中台具有资产沉淀能力。用户在使用数据的过程中会自动地沉淀出高价值的数据,通过数据中台的融通能力,将这些有价值的数据进行良性的循环与回流。企业因此对自身的用户数据、会员数据、人力数据等认识加深。
Pace Layer 里提到,可以按照事物变化的速度来分层,这样可以逐层分析并设计合理的边界与服务。 2018 年,史凯在与不同企业沟通过程中经常听到的一句话就是,“我们现在还没有到利用数据这一步,因为(应用系统中的)数据质量太差”。 其次,数据中台应该从小数据、小场景做起。 数据中台是面向场景而非面向技术的,这种与客户的业务、企业的结构和信息化发展阶段有着紧密的相关性的业务基础架构,是很难买一个大而全的产品来一劳永逸解决的。 数据中台团队和技术选型 数据中台团队通常需要包含以下角色: 业务专家团队:了解业务、梳理业务场景,确定数据资产与业务场景的一一对应关系,确定业务场景的优先级,为数据中台的建设提供依据。 从这个角度来讲,数据中台将会变成物理世界的业务在数字化世界的一个还原。 数据中台设计的初衷是将计算与存储分离,从狭义上来说,真正最核心的数据中台可以是没有存储的。
建模方法论 今天我们主要介绍常见的建模方法,这也就是我们今天文章的名称——建模方法论 20年前兴起的数据仓库简单的可分为两大流派,Inmon方法和Kimball方法,分别由 Ralph Kimbal和Bill 区别的关键在于如何在数据仓库中建模、加载和存储数据的方式。而由此出发的不同架构影响到了数据仓库的建设成本和到适应用户不断变化的ETL逻辑的能力。 建模的目的 数仓的建模或者分层,其实都是为了更好的去组织、管理、维护数据,所以当你站在更高的维度去看的话,所有的划分都是为了更好的管理。 小到JVM 内存区域的划分,JVM 中堆空间的划分(年轻代、老年代、方法区等),大到国家的省市区的划分,无一例外的都是为了更好的组织管理 访问性能:能够快速查询所需的数据,减少数据I/O。 数据成本:减少不必要的数据冗余,实现计算结果数据复用,降低大数据系统中的存储成本和计算成本。 使用效率:改善用户应用体验,提高使用数据的效率。
我曾经推过一篇《中台战略与气象业务系统建设之经验分享》,简单聊了聊中台战略在气象部门的落地困境。 最近看了《企业IT架构转型之道》一书的作者钟华的一段关于中台的对话访谈,其中谈到决定中台成败的四要素,对我思考中台在气象业务建设过程中遇到的问题有了一些启发,也有了一些新的理解,所以今天跟大家再次聊聊中台战略与气象业务建设 新冠疫情发生后,很多企事业单位都受到不同程度的损失,中台战略也受到打击,我发现中台的热度骤减,再也没有2019年各种创新大会上的中台热,并且越来越多关于中台的吐槽文章,简直让人开始怀疑中台是不是就只是一个概念 在《中台战略与气象业务系统建设之经验分享》一文中我说过,中台是个“一把手”工程,是自上而下的组织实施过程。 中台的落地实施是个全局层面的战略方向,绝不是信息网络部门一家之事。中台的建设相当于一个地基的搭建过程,领导层要认同中台战略,同时要有足够的耐心去支持中台的搭建。
数据资产管理所处地位 数据资产管理在数据中台架构中的位置,介于数据开发和数据应用之间,处于承上启下的重要地位。 ? 4. 数据治理与数据资产管理的关系 数据资产管理就是传统的数据治理的升级版,可认为是数据治理2.0,数据资产管理包含数据治理。 ?
整理| 技术领导力(ID:jishulingdaoli) 源 / 技术领导力 文 / 朱剑锋 说明:本资料来自首届全国中台战略大会暨第三届互联网架构峰会 后台回复关键词回复“Java中台” 获得大厂中台架构和微服务文章锦集合集 END
数据中台的起源与疑惑 “中台”某种意义上是一个正宗的中国概念,早在2015年,马老师访问过北欧的Supercell游戏公司之后,便提出了这个概念。随之而来的,是阿里带动的“大中台、小前台”运动。 其实这就是今天大家对中台有意见的原因,因为技术上能够整合,但业务上却难以体现其价值。 中台应有的价值如何体现 让我们回到Supercell,对于一家游戏开发公司而言,怎样才算是好的中台? 但如果中台能够支撑一定的基础开发工作,比如模拟物理环境、碰撞检测、动画建模等通用出来,我搭建一个游戏就不需要从头开始,而是设计好游戏内容和形式后,直接上手开发就可以了。 数据中台如何体现价值 假设我们所在的公司有能力搭建数据中台,那么怎样的数据中台是合格的呢? 其实数据中台更多的要走到业务中,为业务贡献价值,才能真的称之为“中台”。
数据处理层:这一层负责数据的清洗、整合、转化和预处理,以使其适合分析和建模。这可能涉及到使用Spark、Pig、Hive等工具进行批处理,或者使用Flink、Kafka等进行实时流处理。 媒体与出版业:媒体和出版机构可以利用内容中台整合新闻、文章、图片等资源,快速发布到不同的平台和渠道。 数据中台可以帮助金融机构实现内部部门连接和与终端客户的连接,实现跨部门、多业务系统数据的统一管理,以应对政策、规则、需求的变化。 数据中台可以帮助政府部门优化服务流程、提高服务效率和质量,为公众提供更加便捷、高效、精准的政务服务。数据共享与交换:在企业内部或跨企业间实现数据的共享和交换,促进数据资源的有效利用和协作。 业务分析与决策支持:通过数据中台进行大数据分析,为企业决策者提供实时或近实时的业务洞察,帮助他们做出更明智的决策。例如,销售分析、客户行为分析、市场趋势预测等。