精华内容
下载资源
问答
  • 大数据中台

    千次阅读 2020-08-28 11:17:11
    数据中台最早是阿里提出的,但真正火起来是2018 年,我们能感受到行业文章谈论数据中台的越来越多。大量的互联网、非互联网公司都开始建设数据中台。为什么很多公司开始建设数据中台?尽管数据中台的文章很多,但是...

     

    数据中台的由来

    数据中台最早是阿里提出的,但真正火起来是2018 年,我们能感受到行业文章谈论数据中台的越来越多。大量的互联网、非互联网公司都开始建设数据中台。为什么很多公司开始建设数据中台?尽管数据中台的文章很多,但是一千人眼里有一千个数据中台,到底什么是数据中台?数据中台包含什么?

    当企业需要数据化转型、精细化运营,进而产生大规模数据应用需求的时候,就需要建设数据中台。数据中台是高质量、高效赋能数据前台的一系列数据系统和数据服务的组合。数据中台包含数仓体系、数据服务集和BI 平台。

    1、是阿里拜访芬兰的一家公司—SupperCell,只有不到10个人,每个员工创造估值3.74亿
    ​
    2、淘宝遇到的问题:淘宝和天猫是两套完全独立的两套系统,但是却都包含了商品、交易、评价、支付、物流
    ​
    3、中台之前类似的思想
    SOA(方法):面向服务的架构(SOA)是一个组件模型,它将应用程序的不同功能单元(称为服务)进行拆分,并通过这些服务之间定义良好的接口和协议联系起来。接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构件在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。

     

     

    电商系统的四个发展阶段

    1、单一系统
    2、分布式系统
    3、平台化(服务业务,支撑作用)
    4、中台化(驱动业务,中枢作用)
    第一阶段:数据库节点:单一业务系统阶段
    第二阶段:数据仓库节点:处理分析报表的需求
    第三阶段:数据平台阶段:解决报表和BI的需求
    第四阶段:数据中台阶段:系统对接OLTP和OLAP

     

    中台长什么样?

    阿里的大中台,小前台

    沉淀共享服务,打破系统壁垒,业务快速创新

     

    滴滴的中台

     

    大数据中台解决的问题

    1. 到底什么是数据中台?

    2. 如何来建设数据中台?

    3. 数据中台有哪些应用价值?

     

    建设数据中台的背景

    1. 指标口径不一致造成数据不可信;

    2. 数据经常无法按时产出,影响工作效率;

    3. 敏感数据泄露,引发安全危机。

    最终的结果就是数据不好用,无法发挥应有的价值

     

    建设数据中台的复杂度

    • 客观上讲,数据中台的建设是一项系统性工程,从组织架构、支撑技术到流程规范,既要有宏观的顶层设计,又要有强有力的落地执行,所以对整个团队的要求会比较高;

    • 从主观上讲,这些企业本身数据建设经验不足,或者还处于比较初级的阶段,不知道数据建设中有哪些痛点,更不知道用什么样的技术手段和管理机制去解决这些问题。

     

    中台起源

    关键词:数据库,数据仓库,数据湖,大数据平台,数据中台

     

    数据存储起源:数据库

    1979年:Oracle 1.0 商用数据库发布 1996年:MySQL 1.0 发布,到2000年以后开始火起来。

    特点:数据库主要面向事务的增删改场景,一个数据库支撑多个简单单体应用,少量分析需求,借助数据库直接完成。但当数据增长较快,复杂的大量的分析需求,借助数据库做分析开始吃力。

     

    分析计算起源:传统数仓

    在 1991 年出版的《Building the Data Warehouse》中,数据仓库之父比尔·恩门(Bill Inmon)首次给出了数据仓库的完整定义,他认为:数据仓库是在企业管理和决策中面向主题的、集成的、与时间相关的,不可修改的数据集合。

    数据仓库,聚合多个业务系统的数据,同时保存历史数据,进行大数据量的范围查询。

    Kimball 和 Inmon 是两种主流的数据仓库方法论,分别由 Ralph KimballBill Inmon 提出,在实际数据仓库建设中,业界往往会相互借鉴使用两种开发模式。

    Inmon 提出的建模方法自顶向下(顶是指数据的来源,在传统数据仓库中,就是各个业务数据库),基于业务中各个实体以及实体之间的关系,构建数据仓库。缺点是:构建成本高,适用于业务场景固定的业务(实体 和 关系)

    Kimball 建模与恩门正好相反,是一种自底向上的模型设计方法,从数据分析的需求出发,拆分维度和事实。优点是:适用于变化速度比较快的业务。(事实 和 维度)

    传统数据仓库,第一次明确了数据分析的应用场景应该用单独的解决方案去实现,不再依赖于业务的数据库。在模型设计上,提出了数据仓库模型设计的方法论,为后来数据分析的大规模应用奠定了基础。

     

    技术革命:大数据平台

    进入互联网,数据量开始暴涨,主要有以下两个变化:

    • 一个是数据规模前所未有。一个成功的互联网产品日活可以过亿,就像你熟知的微信,支付宝,头条,抖音等,每天产生几千亿的用户行为。传统数据仓库难于扩展,根本无法承载如此规模的海量数据。

    • 一个是数据类型变得异构化。互联网时代的数据除了来自业务数据库的结构化数据,还有来自 App、Web 的前端埋点数据,或者业务服务器的后端埋点日志,这些数据一般都是半结构化,甚至无结构的。传统数据仓库对数据模型有严格的要求,在数据导入到数据仓库前,数据模型就必须事先定义好,数据必须按照模型设计存储。

    所以:传统数仓应对这种场景吃力,开始涌现一些针对大规模海量数据进行分析处理的技术。

    2003年起,谷歌发表了 3 篇论文: 《The Google File System》 《MapReduce:Simplified Data Processing on Large Clusters》 《Bigtable:A Distributed Storage System for Structed Data》

    这三篇论文,提出了一种新的,面向海量数据分析的海量异构数据的统一计算和存储的方法,奠定了现代大数据,大规模并行计算的技术基础。Yahoo对此做了开源实现,就是现在的Hadoop。两个优势:

    • 完全分布式,易于扩展,可以使用价格低廉的机器堆出一个计算、存储能力很强的集群,满足海量数据的处理要求;

    • 弱化数据格式,数据被集成到 Hadoop 之后,可以不保留任何数据格式,数据模型与数据存储分离,数据在被使用的时候,可以按照不同的模型读取,满足异构数据灵活分析的需求。

    随着 Hadoop 技术日趋成熟,2010 年,Pentaho 创始人兼 CTO James Dixon 在纽约 Hadoop World 大会上提出了数据湖的概念,他提到:数据湖(Data Lake)是一个以原始格式存储数据的存储库或系统。数据湖是按存储原始数据格式的数据存储,旨在任何数据可以以最原始的形态储存,可是结构化或者非结构化数据,以确保数据在使用时可以不丢失任何细节,一般以Hadoop系统存储为比较典型的解决方案,所有的实时数据和批量数据,都汇总到数据湖当中,然后从湖中取相关数据用于机器学习或者数据分析。

    易观在2018年,提出数据河的概念,避免“数据湖”成为“数据沼泽”,流动的“数据河”是关键。因为大部分使用数据湖的企业在数据真的需要使用的时候,往往因为数据湖中的数据质量太差而无法最终使用。数据只有流动起来,才可以不成为数据沼泽,湖泊只是暂存数据河流的基地。数据流动就意味着所有的数据产生,最终要有它的耕种者和使用者。要让数据有效流动起来,就要建立有效的“数据河”(Data River)。数据河(Data River)就是在由源头产生清晰干净的有效数据(去ETL化,数据源头业务就像生态水源一样,不让污水流下去),通过各个河流网,流向各个数据消费端的架构。

     

    数据工厂时代:大数据平台

    大数据平台是面向数据研发场景的,覆盖数据研发的完整链路的数据工作台。就是为了提高数据研发的效率,降低数据研发的门槛,让数据能够在一个设备流水线上快速地完成加工。

    大数据平台按照使用场景,分为数据集成、数据开发、数据测试……任务运维,大数据平台的使用对象是数据开发。大数据平台的底层是以 Hadoop 为代表的基础设施,分为计算、资源调度和存储等。

    数据存储:HDFS,HBase,Kudu等
    数据计算:MapReduce, Spark, Flink
    交互式查询:Impala, Presto
    在线实时分析:ClickHouse,Kylin,Doris,Druid,Kudu等
    资源调度:YARN,Mesos,Kubernetes
    任务调度:Oozie,Azakaban,AirFlow等
    ....
    数据收集,数据迁移,服务协调,安装部署,数据治理等

    大数据平台像一条设备流水线,经过大数据平台的加工,原始数据变成了指标,出现在各个报表或者数据产品中。

     

    数据价值时代:数据中台

    在应用大数据平台架构的时候,你可能遇到这么个问题:因为烟囱式的开发,不同数据应用可能存在相同应用指标,但是运营可能发现这些数据指标的结果不一致,因为不知道该用谁信任谁而导致运营对数据的信任下降。

    数据割裂的另外一个问题,就是大量的重复计算、开发,导致的研发效率的浪费,计算、存储资源的浪费,大数据的应用成本越来越高。

    • 如果你是运营,当你想要一个数据的时候,开发告诉你至少需要一周,你肯定想是不是太慢了,能不能再快一点儿?

    • 如果你是数据开发,当面对大量的需求的时候,你肯定是在抱怨,需求太多,人太少,活干不完。

    • 如果你是一个企业的老板,当你看到每个月的账单成指数级增长的时候,你肯定觉得这也太贵了,能不能再省一点,要不吃不消了。

    这些问题的根源在于,数据无法共享。

    2016 年,阿里巴巴率先提出了“大中台,小前台”战略,推出了数据中台。数据中台的核心,是避免数据的重复计算,通过数据服务化,提高数据的共享能力,赋能数据应用。之前,数据是要啥没啥,中间数据难于共享,无法积累。现在建设数据中台之后,要啥有啥,数据应用的研发速度不再受限于数据开发的速度,然后我们就可以根据需求场景,快速孵化出很多数据应用,这些应用让数据产生价值。

    总的来说,数据中台吸收了传统数据仓库、数据湖、大数据平台的优势,同时又解决了数据共享的难题,通过数据应用,实现数据价值的落地。

     

    数据中台适合企业

    大数据平台型企业的问题

    大量数据产品的出现,在不断提高企业运营效率的同时,也暴露出很多尖锐的问题,在我看来,主要有五点。

    • 指标口径不一致:主要原因:业务口径不一致、计算逻辑不一致、数据来源不一致。要实现一致,就务必确保对同一个指标,只有一个业务口径,只加工一次,数据来源必须相同。

    • 数据重复建设,需求响应时间长:解决数据复用的问题,要确保相同数据只加工一次,实现数据的共享。

    • 取数效率低:构建一个全局的企业数据资产目录,实现数据地图的功能,快速找到数据

    • 数据质量差:存储数据链路,及时发现数据质量问题,并恢复数据。

    • 数据成本线性增长:大企业烟囱式开发,导致一个企业拥有很多小数仓,不同数仓可能开发相同任务,导致资源浪费,而且也做不到淘汰低价值数据任务。所以解决方案的核心:解决数据重复建设,打通数据孤岛。

    因此:数据中台是企业构建的标准的、安全的、统一的、共享的数据组织,通过数据服务化的方式支撑前端数据应用。

     

    那么数据中台如何解决呢?

    • 由一个团队,负责所有指标的管控,明确每个指标的业务口径,数据来源和计算逻辑,消除指标二义性

    • 数据服务化,提高了数据应用接入和管理的效率

    • 对于非技术人员,数据中台提供了可视化的取数平台。你只需要选取指标、通过获取指标系统中每个指标的可分析维度,然后勾选,添加筛选过滤条件,点击查询,就可以获取数据。

    • 构建了企业数据地图,你可以很方便地检索有哪些数据,它们在哪些表中,又关联了哪些指标和维度

    • 数据只能加工一次,强调数据的复用性

    • 成本控制,研发了一个数据成本治理系统,从应用维度、表维度、任务的维度、文件的维度进行全面的治理

     

    什么样的企业适合建数据中台?

    数据中台的构建需要非常大的投入:一方面数据中台的建设离不开系统支撑,研发系统需要投入大量的人力,而这些系统是否能够匹配中台建设的需求,还需要持续打磨。另外一方面,面对大量的数据需求,要花费额外的人力去做数据模型的重构,也需要下定决心。

    所以数据中台的建设,需要结合企业的现状,根据需要进行选择。我认为企业在选择数据中台的时候,应该考虑这样几个因素。

    • 企业是否有大量的数据应用场景: 数据中台本身并不能直接产生业务价值,数据中台的本质是支撑快速地孵化数据应用。所以当你的企业有较多数据应用的场景时(一般有 3 个以上就可以考虑),就像我在课程开始时提到电商中有各种各样的数据应用场景,此时你要考虑构建一个数据中台。

    • 经过了快速的信息化建设,企业存在较多的业务数据的孤岛,需要整合各个业务系统的数据,进行关联的分析,此时,你需要构建一个数据中台。比如在我们做电商的初期,仓储、供应链、市场运营都是独立的数据仓库,当时数据分析的时候,往往跨了很多数据系统,为了消除这些数据孤岛,就必须要构建一个数据中台。

    • 当你的团队正在面临效率、质量和成本的苦恼时,面对大量的开发,却不知道如何提高效能,数据经常出问题而束手无策,老板还要求你控制数据的成本,这个时候,数据中台可以帮助你。

    • 当你所在的企业面临经营困难,需要通过数据实现精益运营,提高企业的运营效率的时候,你需要构建一个数据中台,同时结合可视化的 BI 数据产品,实现数据从应用到中台的完整构建,在我的接触中,这种类型往往出现在传统企业中。

    • 企业规模也是必须要考虑的一个因素,数据中台因为投入大,收益偏长线,所以更适合业务相对稳定的大公司,并不适合初创型的小公司。

    建设数据中台不能盲目跟风,因为它不一定适合你。

     

    如何建设数据中台

    方法论

    在 2016 年,阿里巴巴就提出了数据中台建设的核心方法论:OneData 和 OneService

     

    OneData

    OneData 就是所有数据只加工一次。

    数据中台就是要在整个企业中形成一个公共数据层,消灭这些跨部门的小数仓,实现数据的复用,所以强调数据只加工一次,不会因为不同的应用场景,不同的部门数据重复加工。

    如何实现:

    • 数据划分主题进行管理:表的命名,字段的命名等规范统一,做到见名知义

    • 数据格式和字段命名和定义规范化

    • 指标一致,不存在二义性:提供全局数据字典确保意义一致。

    • 数据模型复用

    • 数据完善

    OneData 体系的目标是构建统一的数据规范标准,让数据成为一种资产,而不是成本。资产和成本的差别在于资产是可以沉淀的,是可以被复用的。成本是消耗性质的、是临时的、无法被复用的。

     

    OneService

    OneService,数据即服务,强调数据中台中的数据应该是通过 API 接口的方式被访问。

    现阶段企业数据应用现状:

    • 数据量小的使用 MySQL:Hive数仓,Spark计算引擎的计算结果导出到MySQL

    • 数据量大的使用HBase + ElasticSearch:解决海量数据中的低延迟高效查询

    • 需要多维分析的可能需要 ClickHouse,Kylin,Greenplum:提供现在分析能力

    • 实时性要求高的需要用到 Redis

    因此,从不同的系统取数据,应用开发需要定制不同的访问接口。而且如果数据发生异常,还不能查出影响到下游应用的那些应用或者报表。所以当你想下线一张表的时候,就无法实施,造成了上线容易,下线难的囧状。

    而 API 接口一方面对应用开发屏蔽了底层数据存储,使用统一标准的 API 接口查询数据,提高了数据接入的速度。另一方面,对于数据开发,提高了数据应用的管理效率,建立了表到应用的链路关系。

    如何实现:

    • 屏蔽底层数据来源的不同:不同的数据来源,统一的数据出口

    • 实现包括权限,日志,监控等管控能力的数据网关:权限控制,统计分析,流量控制,成本控制等

    • 给用户屏蔽底层的物理数据模型,提供数据逻辑模型:动态拼接多张相同粒度的数据结构,简化接入复杂度

    • 提供无状态的,高性能和稳定可靠的数据服务

    OneService 体系的目标是提高数据的共享能力,让数据可以被用得好,用得爽。

     

    技术

    以网易数据中台为例:

     

    这个图完整地描述了数据中台支撑技术体系

    • 1、大数据计算、存储基础设施

      数据中台的底层是以 Hadoop 为代表的大数据计算、存储基础设施,提供了大数据运行所必须的计算、存储资源。

    • 2、工具产品

      在 Hadoop 之上,浅绿色的部分是原有大数据平台范畴内的工具产品,覆盖了从数据集成、数据开发、数据测试到任务运维的整套工具链产品。同时还包括基础的监控运维系统、权限访问控制系统和项目用户的管理系统。由于涉及多人协作,所以还有一个流程协作与通知中心。

    • 3、数据治理模块

      灰色的部分,是数据中台的核心组成部分:数据治理模块。它对应的方法论就是 OneData 体系。以元数据中心为基础,在统一了企业所有数据源的元数据基础上,提供了包括数据地图、数仓设计、数据质量、成本优化以及指标管理在内的 5 个产品,分别对应的就是数据发现、模型、质量、成本和指标的治理。

    • 4、数据服务

      深绿色的部分是数据服务,它是数据中台的门户,对外提供了统一的数据服务,对应的方法论就是 OneService。数据服务向下提供了应用和表的访问关系,使数据血缘可以延申到数据应用,向上支撑了各种数据应用和服务,所有的系统通过统一的 API 接口获取数据。

    • 5、数据产品和应用

      在数据服务之上,是面向不同场景的数据产品和应用,包括面向非技术人员的自助取数系统;面向数据开发、分析师的自助分析系统;面向敏捷数据分析场景的 BI 产品;活动直播场景下的大屏系统;以及用户画像相关的标签工厂

     

    组织

    数据中台提供的是一个跨业务部门共享的公共数据能力,所以,承担数据中台建设职责的部门一定是一个独立于业务线的部门。

    独立部门的最大风险是与业务脱节,所以我们对数据中台的组织定位是:懂业务,能够深入业务,扎根业务。数据中台要管理所有的指标,而每个业务线之间的指标既有差异,也有交叉,要理解指标的口径定义,就必须要了解业务的过程。同时,当我们要制定一些新的指标时,必须要了解各个业务线新的业务目标,指标的本质还是为业务目标服务的。

    综合来讲:

     

    • 数据产品部门:负责数据中台、数据产品的体系规划、产品设计、规范制定、应用效果跟进,指标口径的定义和维护(有的部门是由分析师管理)。

    • 数据平台部门:负责研发支撑数据中台构建的产品,例如指标系统、元数据中心、数据地图等。

    • 数据开发团队:负责维护数据中台的公共数据层,满足数据产品制定的数据需求。

    • 应用开发团队:负责开发数据应用产品,比如报表系统、电商中的供应链系统、高层看板、经营分析。

    数据中台的组织架构改革涉及原有各个部门的利益,所以这个是数据中台构建最难又不得不做的地方,必须要取得高层领导的支持和重视。所以需要:

    • 一把手牵头,全员共识;

    • 总体规划,分步实施;

    • 找准切入点,解决具体业务问题

     

    中台实现:元数据中心

    元数据

    数据中台的构建,需要确保全局指标的业务口径一致,要把原先口径不一致的、重复的指标进行梳理,整合成一个统一的指标字典。而这项工作的前提,是要搞清楚这些指标的业务口径、数据来源和计算逻辑。而这些数据呢都是元数据。

    元数据中心应该包括哪些元数据呢? 什么样的数据是元数据?

    元数据划为三类:数据字典、数据血缘和数据特征。

    数据字典描述的是数据的结构信息:表结构信息

    数据血缘是指一个表是直接通过哪些表加工而来。数据血缘一般会帮我们做影响分析和故障溯源。比如说有一天,你的老板看到某个指标的数据违反常识,让你去排查这个指标计算是否正确,你首先需要找到这个指标所在的表,然后顺着这个表的上游表逐个去排查校验数据,才能找到异常数据的根源。

    数据特征主要是指数据的属性信息:存储空间大小,数仓分层,访问热度,主题分类,关联指标等

     

    元数据技术

    根据我的经历和了解,业界比较流行的元数据产品技术主要有:

    • 开源的有 Netflix 的 Metacat、Apache 的 Atlas;

    • 商业化的产品有 Cloudera Navigator。

    关于开源的这两款产品,Metacat 擅长管理数据字典,Atlas 擅长管理数据血缘。

    Metacat 介绍:https://github.com/Netflix/metacat

     

    从上面 Metacat 的架构图中,你可以看到,Metacat 的设计非常巧妙,它并没有单独再保存一份元数据,而是采取直连数据源拉的方式,一方面它不存在保存两份元数据一致性的问题,另一方面,这种架构设计很轻量化,每个数据源只要实现一个连接实现类即可。

    Apache Atlas 介绍:http://atlas.apache.org/

    血缘采集,一般可以通过三种方式:

    • 通过静态解析 SQL,获得输入表和输出表;

    • 通过实时抓取正在执行的 SQL,解析执行计划,获取输入表和输出表;

    • 通过任务日志解析的方式,获取执行后的 SQL 输入表和输出表。

    第一种方式,面临准确性的问题,因为任务没有执行,这个 SQL 对不对都是一个问题。第三种方式,血缘虽然是执行后产生的,可以确保是准确的,但是时效性比较差,通常要分析大量的任务日志数据。所以第二种方式,我认为是比较理想的实现方式,而 Atlas 就是这种实现。

     

    对于 Hive 计算引擎,Atlas 通过 Hook 方式,实时地捕捉任务执行计划,获取输入表和输出表,推送给 Kafka,由一个 Ingest 模块负责将血缘写入 JanusGraph 图数据库中。然后通过 API 的方式,基于图查询引擎,获取血缘关系。对于 Spark,Atlas 提供了 Listener 的实现方式。

     

    网易元数据中心实现

    下图按照功能模块分为数据血缘数据字典数据特征

     

    元数据中心统一对外提供了 API 访问接口,数据传输、数据地图、数据服务等其他的子系统都可以通过 API 接口获取元数据。另外 Ranger 可以基于元数据中心提供的 API 接口,获取标签对应的表,然后根据标签更新表对应的权限,实现基于标签的权限控制。

     

    关键点

    元数据中心是数据中台的基石,它提供了我们做数据治理的必须的数据支撑,数据的指标、模型、质量、成本、安全等的治理,这些都离不开元数据中心的支撑。

    • 元数据中心设计上必须注意扩展性,能够支持多个数据源,所以宜采用集成型的设计方式。

    • 数据血缘需要支持字段级别的血缘,否则会影响溯源的范围和准确性。

    • 数据地图提供了一站式的数据发现服务,解决了检索数据,理解数据的“找数据的需求”。

     

    中台实现:指标管理

    指标是一种特定类型的元数据,公司的运营会围绕它进行工作,可以说,它是业务和数据的交汇点。指标数据能不能用,会影响他们的日常工作。而且元数据在指标管理、模型设计、数据质量和成本治理四个领域也都发挥着作用,而这些领域构成了数据中台 OneData 数据体系。

     

    为什么需要指标管理

    举两个例子:

    第一个:新用户

    • 市场部门认定新用户是首次下单并完成支付的用户;

    • 会员中心认定新用户是当日新注册用户。

    第二个:7日UV

    • 过去7日UV的平均值

    • 过去7日所有Vistor的去重数量

    定义不一致,口径不一致,计算逻辑就不一致。所以构建数据中台,需要提供全局一致的指标口径,输出完备统一的指标字典。

     

    常见指标问题

    一般进行烟囱式开发的企业都多多少少存在以下的指标问题:

    • 相同指标名称,口径不一致:比如"新用户销售额,7日UV"

    • 相同口径,指标名称不一样:比如"优惠券抵扣金额"和"优惠券消费金额"

    • 不同限定词,描述相同事实过程的俩个指标,相同事实部分口径不一致

    • 指标口径描述不清晰:比如"关单金额"

    • 指标命名难于理解:比如"转化率" 和 "ROI"

    • 指标数据来源和计算逻辑不清晰

     

    如何定义指标

    • 面向主题:为了提高指标管理的效率,你需要按照业务线、主题域和业务过程三级目录方式管理指标

    • 拆分原子指标和派生指标:统计周期、统计粒度、业务限定、原子指标,组成派生指标,所以原子指标可以定义为不能够按照上述规则进一步拆分的指标。比如:30 天内某商品的非会员购买用户数

    • 命名规范:规范统一化,通俗易懂化。

    • 关联的应用和可分析的维度

    • 分等级管理

     

    如何构建指标系统

    • 提供一个易于维护的规范标准化指标管理系统,具备查询,增删等功能。

    • 数据中台团队必须要有一个专门负责指标管理的人或者小组(一般不超过 3 个人),最好是数据产品经理来负责,如果你的公司没有这个职位,也可以让分析师承担。

    • 提供一个完备的指标创建流程:提交指标需求,需求评审,模型设计和数据开发,验证,上线,应用接入

     

    指标管理总结

    • 数据中台直接产出的核心指标必须实施强管理,由数据中台团队的专人或者小组负责,最好是数据产品经理的角色。

    • 指标的管理必须结合系统 + 规范的治理方法,明确每个角色的职责,通过系统化的方法实现。

    • 不同的两个指标描述的相同业务过程中的相同事实部分口径不一致,是指标梳理过程中最常见的问题,需要通过拆分原子指标和派生指标的方式解决。

     

    中台实现:模型设计

    大多数公司的分析师会结合业务做一些数据分析(需要用到大量的数据),通过报表的方式服务于业务部门的运营。但是在数据中台构建之前,分析师经常发现自己没有可以复用的数据,不得不使用原始数据进行清洗、加工、计算指标。

    烟囱式数据开发:数据模型无法复用,每次遇到新的需求,都从原始数据重新计算

     

    如何构建可复用模型

     

    大数据中台的数据模型:

     

    构建可复用模型的标准:数据模型可复用,完善且规范

    • 统计明细层完善度:统计DWD层表被跨层引用次数即可,次数越多,证明完善度越好

    • DWS/ADS/DM 层完善度:能满足多少查询需求。

     

    中台实现:数据质量

    现有的大数据平台,或者数仓项目,很难做到任务追踪和数据追踪。举一个例子。

    运营每天上班的第一件事,都是打开响应的数据运营系统,如果某天突然发现这个数据反常,需要数据开发部门核对,或者经过他们自己核对,发现数据的确算错已经投诉了。

    这样的例子中,可以得出几个结论:

    • 数据部门晚于业务方发现数据异常,被投诉后才发现问题。

    • 出现问题后,数据部门无法快速定位到数据异常的根源,排查用了较长的时间。

    • 故障出现在数据加工链路的上游顶端,出现问题没有第一时间报警处理,导致问题修复时,所有下游链路上的任务都要运行,修复时间成本非常高。

    这些问题最终导致了数据长时间不可用。这就是数据质量的问题

     

    数据质量问题的根源

    对于一个做数据开发的人来讲,遇见数据质量的问题(也就是算错了数据的问题)是经常性的。而,通常进行排查和数据恢复,都需要较长的时间,和较大的代价。在多次问题的复盘中,总结出以下规律:

    • 业务系统变更,包括表结构变更,源系统环境变更,源数据格式异常

    • 数据开发bug + 数据开发任务变更:忘了修改数据源,写死数据分区,数据格式异常

    • 物理资源不足:YARN上多租户争抢资源导致数据延迟产出

    • 基础设施不稳定:NameNode高可用失效导致数据读写功能异常

     

    如何提高数据质量

    想提升数据质量,最重要的就是“早发现,早恢复”:

    • 早发现,是要能够先于数据使用方发现数据的问题,尽可能在出现问题的源头发现问题,这样就为“早恢复”争取到了大量的时间。

    • 早恢复,就是要缩短故障恢复的时间,降低故障对数据产出的影响。

    具体实施:

    • 添加稽核校验任务:确保数据的完整性、一致性和准确性

    • 建立全链路监控:可以基于血缘关系建立全链路数据质量监控。

    • 通过智能预警,确保任务按时产出:延迟产出,异常任务等立即报警

    • 通过应用的重要性区分数据等级,加快恢复速度

     

    如何衡量数据质量

    对于数据治理做到什么程度,很难衡量,最好的办法就是量化。

    • 某个时间点以前核心任务的产出完成比,超过规定时间,没有完成产出则稽核校验失效

    • 基于稽核规则,计算表级别的质量分数。对于低于质量分数的表,分发到响应责任人进行改进。

    • 需要立即介入的报警次数。超过规定次数的需要立即介入

    • 数据产品 SLA。数据应用中的所有指标在规定时间内产出。如果没有,则计算不可用时间,不可用时间越短,证明SLA越好

     

    中台实现:成本控制

    企业数据中台追求的是:高效,质量和成本。简单来说就是:快,准,省。所以能不能合理控制成本,也是决定数据中台项目成功与否的关键。

    如果老板问你:

    • 今年大数据中台预算 5000W,都用来支撑什么业务了?

    • 你们都做了哪些优化成本的举措呢?效果怎样?

    正常来说,数据中台的成本,是按照人力,物力,按照机器数量和电费来算的,又不是按照数据应用来算的,来自老板的这种灵魂拷问,还真是不好回答。但是一个公司的资源都是有限的,不可能无限增加,所以这些资源肯定都需要确保应用在公司的核心战略上产生价值。所以数据中台刚好又是一个高消耗支撑部门,所以如果想展现自己的价值,至少要做到两方面:

    • 支撑好业务,获得业务部门的认可

    • 精简架构,控制成本,为公司省钱

     

    成本陷阱

    根据经验,可以总结优化的地方还是挺多,如果都做到位,可以节省一半资源。相信很多小伙伴已经基本中招。

    • 数据上线容易,下线难,什么没有下线机制。

    • 低价值的数据应用消耗了大量的机器资源。

    • 烟囱式的开发模式导致数据加工重复。

    • 数据倾斜导致资源分配利用不均衡

    • 未设置数据生命周期,导致过期数据长期占用磁盘资源。

    • 调度周期设置不合理,未形成闲忙搭配得当。

    • 任务指定资源参数配置不当

    • 数据为压缩存储

    甚至还可以再列举一些。

     

    精细化成本管理

    • 全局资产盘点

    1、精细化成本管理的第一步,就是要对数据中台中,所有的数据进行一次全面盘点,基于元数据中心提供的数据血缘,建立全链路的数据资产视图。
    ​
    2、数据成本计算:一张表的成本 = 每个加工任务的计算资源成本 * m + 上有依赖表的存储资源成本 * n
    ​
    3、数据价值计算:给使用人数,使用频率,数据应用数,老板等因素加权计算
    • 发现问题

    1、持续产生成本,但是已经没有使用的末端数据(“没有使用”一般指 30 天内没有访问):没有使用,却消耗了资源
    ​
    2、数据应用价值很低,成本却很高,这些数据应用上游链路上的所有相关数据:低价值产出
    ​
    3、高峰期高消耗的数据:高成本的数据
    • 治理优化

    1、对于第一类问题,应该对表进行下线
    ​
    2、对于第二类问题,我们需要按照应用粒度评估应用是否还有存在的必要,如果没有,则删除。
    ​
    3、第三类问题,主要是针对高消耗的数据,又具体分为产出数据的任务高消耗和数据存储高消耗,分配到非高峰期运行即可。
    • 治理效果评估

    1、最简单粗暴的标准:省了多少钱
    ​
    2、下线了多少任务和数据;这些任务每日消耗了多少资源;数据占用了多少存储空间。
    ​
    3、将上述节省资源换算成钱,这就是你为公司省的钱。

     

    中台实现:数据服务化

    数据服务解决的问题

    数据接入效率低

    为了保障数据的查询速度,需要引入中间存储

    • 数据量小:MySQL

    • 低延时:Redis

    • 数据两大:HBase

    • 多维分析,数据量大:GreenPlum

    不同中间存储提供的 API 接口不一致,导致使用复杂度提高。维护困难。

    解决方案:提供统一的 API 接口,为开发者和应用者屏蔽不同的中间存储和底层数据源

     

    数据服务解决的问题

    • 中间存储中的数据无法复用

    • API接口根据应用高度定制化,也无法复用

    • 数据服务暴露的不是数据,而是接口

    • 数据服务具备限流功能,使得不同应用共享数据成为可能

     

    不确定数据应用在哪里

    • 数据和应用的链路关系是断的

    • 数据出现问题,不知道影响了哪个应用,无法优先恢复

    • 下线数据,不知道下游还有没有应用访问

    • L数据服务维护了数据应用和数据中台表的链路关系,建立全链路血缘

     

    数据部门的字段更变导致数据应用变更

    • 汇总层模型根据需求不断优化是最频繁出现的事情

    • 对应用开发来说,底层表变更简直就是噩梦

    • 数据服务解耦了数据应用和数据,修改

    • 数据服务的映射关系即可实现字段变更

     

    数据服务解决方案

    为所有的数据应用提供统一的 API 接口服务

    表现在:

    • 接口规范化定义

    • 数据网关

    • 链路关系的维护

    • 数据交付

    • 提供多样中间存储

    • 逻辑模型

    • API 接口

    • API 测试

    数据服务实现了数据中台模型和数据应用的全链路打通,解决了任务异常影响分析和数据下线不知道影响哪些应用的难题;

    基于相同主键的物理模型,可以构建逻辑模型,逻辑模型解决了数据复用的难题,提高了接口模型的发布效率;

    展开全文
  • 全渠道零售中台与数字化转型(1)-中台的前世今身

    千次阅读 多人点赞 2019-06-25 15:37:59
    本系列博客的目标是计划使用近半年时间创造: ... 全渠道零售中台与数字化转型(2)-中台给企业业务带来什么实际的价值 全渠道零售中台与数字化转型(3)-中台给企业技术带来什么实际的价值? 全渠...

    本系列博客的目标是计划使用近半年时间创造:

    • 国内唯一一部从业务场景到技术设计,从企业战略考虑到技术细节落地的大全;
    • 全文贯穿了企业架构、SOA、微服务,纵横业务与技术之间説透“全渠道”中台;
    • 全渠道零售中台与数字化转型(1)-中台的前世今身
    • 全渠道零售中台与数字化转型(2)-中台给企业业务带来什么实际的价值
    • 全渠道零售中台与数字化转型(3)-中台给企业技术带来什么实际的价值?
    • 全渠道零售中台与数字化转型(4)-作为甲方如何选择中台-产品还是开发?数据中台还是业务中台的多重考虑
    • 全渠道零售中台与数字化转型(5)-中台的架构设计
    • 全渠道零售中台与数字化转型(6)-基于微服务的组件设计
    • 全渠道零售中台与数字化转型(7)-中台核心框架代码实现
    • 全渠道零售中台与数字化转型(8)-中台的延伸

    楔子

    零售战鼓隆,各家齐斗法

    云溪论剑后,江湖出宝典

    古有葵花经,现有“大中台”

    没有“两个亿”,别想做中台

    技术道业务道,自求条正道

    各家纷説自己好

    谁曾想,旧日零售江湖间现己变成了血海滔滔

    你也説中台,我也説中台,到底什么是中台?

    现如今随着“新零售”这三个字一再被提及,整个零售界都在提一个“神密的东西”,那就是中台。甚至中台被上升到了“推进企业数字化变形”的乃至直接促成企业数字化转型能否成功的地位了。

    那么中台它到底是个什么样的东西呢?在人们眼中中台似乎犹如月球的背面一般神密。

    在人们眼中的中台无外乎于上述类似的组件图,类似的图一再被各大零售商或者是不少知名软件商一再的提及。

    它似乎有着“华丽的外表,沉渔落雁的面容,婀娜多姿的身段”。。。but。。。

    它只是利用了2009年TOGAF设计规范从顶向下的设计方法论把业务模块进行了LEVEL3级别的一个分解的功能图而己,它只要业务架构师手绘一些功能甚至公司的一个BA用Excel做一个功能列表然后让稍微资深点的UI做一下布局在一天内即可以得出的一个picture而己

    多少甲方为了这么一张外面报价800-1,000块钱制作费的首图化了近千万、甚至上亿的代价了?甚至笔者在几个展会听到不少的开发商豪言“你要做中台?你公司干什么的?每年至少2个亿销售额有吧。。。。。。没有?那您也别做中台了”。

     

    中台的诞生

    中台这个东西我明确告诉大家:它一点不神密,它也不是近3年的什么高科技的产物,早在2012年这个东西就已经有了。同时我本人在13年也已经用“中台”的理念制作了一套类似的东西我们在当时把它称为“SMART PLATFORM”,这套东西的代码我会在后面的章节涉及到设计和实现的时候公开它的核心源码、数据库表结构与设计思路,这个是属于我个人的也是没有问题的,各位也可以放心使用。

    这种一体化全渠道平台的出现最早是在银行、金融界,在那个时候银行、金融、保险界的一些大公司面对着繁杂的legacy systems需要开始迈入“手机端、无线办公”端的时代,于是当时的人们想到把这么多的legacy systems是不是可以做成一个“大后台”。

    在这个大后台中,把所有的业务功能进行整合,所有的数据使用一个或者是一套数据库以此来打通各个业务、解决掉数据孤岛问题、提高性能、降低不同系统间交互、接口转换、以及支持不同系统间数据交互的事务一致性时带来的昂贵的开发、网络延时与开销以及不必要的开发工作量。

    但是,业界在根据这个指导思想进行开发时发觉问题来了!

    如果仅仅是把所有的东西打包在一个“大后台”并不能真正解决IT的痛点,因为必竟它是一个IT系统。IT系统要考虑的东西除了业务功能,更重要和更有价值的地方在于:

    • 性能
    • 安全
    • 可以快速响应业务的创新或者説甚至可以“加速业务创新”并以此来为业务赋能

    以上説的神乎几神,我们中国人现在讲究的是“效率、实干”,要“落地”,要“接地气”,因此下面我们就用接地气的话来把上面这一段中台出现的背景、历史上经历的痛点来着重的讲一下吧。

     

    直接使用零售场景来描述中台的诞生与过程

    一个顾客在传统的零售场所的消费体验可以用下图描述出主要的“零售体验核心环节”

    以上这个图,它出现在20-25年前的零售大卖场内,支持它的系统也是20甚至25年前的“作品”。这边需要着重説一句的是:截止作者写此稿时,现有大部分的大型商超竟然用的还是20-25年前的IT系统。这也正是近来各大厂商、业界宣了沸沸扬扬的“新零售”,“数字化转型”的原动力与由来(改造需要money, money,没有money没有利益何来原动力)。

    因为。。。这么土的东西,直到现在终于有机会推翻它了。

    言归正传,解读上图!

    当一个顾客来到了大超市内,我们知道传统的大超市还会分不同的品牌,把化妆品还放到不同的位置甚至独立的橱柜,这就导致了客户要买什么东西,他会记得去问各个“导购”或者去服务台询问。

    “哎呀,请问会员怎么办?”,导购人员会告诉他!

    “哎呀,请问会员积分哪里积怎么积?”,导购人员会告诉他!

    “哎呀,请问印花是怎么得到?”,导购人员还是会告诉他!

    客户问错了人,比如説他去问“收银员”这把刀不是説买一把送一块肥皂吗?收银员通过话务机于是叫来了导购,但是导购也不知道,就又通过商场广播叫来了“促销人员”,促销人员当然知道买什么可以送什么或者打几折这些事喽。

    于是,靠着不同的、严格的岗位、职责的区分,我们的商场尚且还可以运作。并且要知道那是20年前,国人的消费能力有小部分已经开始起色而市场上商品的供应还不如现在的“百花齐放”。因此一些国外的大型商超明显在当时是属于“朝南坐”、“躺着挣钱的”

    因此,大型商超在当时对于IT系统的定位是次要中的次要的(很悲哀),而货物、商品甚至不乏国外进口商超内的商品在那时才是真正深深吸引国人的主要因素。

    于是过了大约10年,这也是零售业黄金的10年,随着国人消费能力的越来越高,随着IPHONE4、微信、淘宝的兴起,零商开始迈向了电商时代。

    于是这些大型商超、大型零售超市想当然的认为其实电商就是把原来站在各个服务前的一个个人肉导购啦、促销啦、专柜啦的这些个人取代成一个个的手机应用APP,于是,在当时的大型零售商眼里的电商也是类似下面这样的一个图

    先有了想法

    通过“想法”有了下面的系统“架构”

    零售电商1.0模式

    转型1.0模式

    不要笑,当时一堆一堆的零售(在当时还算是比较有钱)设计出来的系统就是这样的。

    “喏,要数字化,我把人变成了一个个的APP了,这不就是数字化!”

    所以大家直到现在也能看到类似的案例:一些传统的快销、零售商用微信、用APP、用微信小程序哪怕只是做出了一个会员登记系统也会把它当成“公司内部巨大的创新”,也是基于这样的想法。因为IT不重要吗,哈哈!

    可是,它依旧没有从根本上解决客户的问题。为什么呢?中国客户的电商使用习惯是什么?
     

    中国人的电商使用习惯

    中国,人多的很、市场大的很,我们説我们是世界第2电商大国,这个世界上没人敢説它是世界第1。

    那么多APP、那么多小程序、那么多微信公众号,而你只有一个企业实体却要做成“为了一个服务就放一个APP”的模式,比如説:我为了来一次“某干发”大超市、“某得福”网上超市购物你要我去下不止一个APP才能完成“会员、认证、购物、积分”本就应该集中在一个APP中的“功能”,甚至客户做一些兑换还要让我打开一个不知道什么地方的网页去登录一个网址才能完成兑换?你是不是觉得我们客户的时间太“无用了”?

    张小龙説过:哪个APP可以每天占用客户30分钟,这个APP就是巨大的成功

    在百花齐放、百家争鸣的数字化时代况且在当时淘宝连续使用4次双11打折活动打造了中国客户的使用电商APP的习惯后,你这边突然来了一个,有几个功能就要有几个网址、几个APP或者就算你是APP混合微信好来,你觉得中国的顾客会买你的帐?

    下载APP的时间是很宝贵的!

    在当时,APP与微信间还没做到数据共享,因为背后的legacy systems还是孤立的那么客户一些登记、购买行为、数据、历史消费记录都要我们的中国客户重复的操作2遍、操作3遍。。。。。。

    对不起,中国顾客对于这种重复操作2次以上而做的事是在完成同一件事的APP的使用不会超过1次,1次就删掉你!甚至拉黑你!并且还会去朋友圈把你数落一顿。这就是中国人的电商使用习惯。

    中国人喜欢 “一键式”,喜欢 “快速定位”,喜欢“3步操作内就完成一件事”。

    所以,大型零售商们错失了第一次电商黄金发展阶段即培养顾客消费习惯的这个阶段,那么这些大型零售商也意识到了问题:

    哦,这个问题出在后面的系统本来在打造的时候就是CS架构、本来就是一个个孤立的而导致的。

    在此时,大型零售商还是没有意识到自己的危机因为这时阿里淘宝还没有完全起势,大家都认为阿里脑子有水了,连续4次的双11。再説了,他们卖的东西不如我们的有“品牌”,对吧?

    那么现在大量的客户反馈説,你们的几个APP要变成一个APP才好用,所以大家就不约而同的想到了把后面的系统集成在一起,使得每一个系统不是孤立的对外服务了。

    同时,业内不乏I.O.E体系等造势宣称SOA,于是乎在“SOA可能是未来20年仅有的发财机会”这句口号的带领下,零售系统的改造进入了“集成1.5时代”。

     

    零售电商1.5模式-集成模式

    2007~2012年是“集成模式”概念被抛出率最高的年代,它有一个名字叫“SOA”,SOA就是那个时代的“全渠道中台”。

    以I.O.E为首尤其是IBM对SOA进行了系统化、理论化甚至到了产品化的密集布局与宣传,人们提起SOA一定会想到IBM或者是Oracle。

    嘿嘿!

    笔者突然想起2000年初时,有关于互联网的一个笑话:説人人都説这座山上有金子,于是所有人上山挖金子。结果挖金子的人没有发财,倒是山下那个“卖铲子的人”发了财

    系统集成就由如上图一样,复杂无比。

    一堆的Legacy,几十个Legacy,每个接口不同,要把它们集成光开发人员的付出就需要花费大量的时间与精力,很多企业为了不必要的自己去养开发团队为了图快于是使用了各种商业级别的、恶狠狠的集成工具(SOA开发环境)乃至付出了小型机的代价来集成一堆的Legacy。

    这些恶狠狠的工具的使用、错综复杂的系统间如蜘蛛网的连线的一切目的就是为了一个“one app can integrate all function”,一个APP所有功能。

    看似是这么一回事,可是,这次一些“巨头甲方”们却付出了惨重的代价!!!

    上面説了,集成这些Legacy本身是一件很复杂的事,因此需要使用不少在当时被称为“RAD-快速应用开发工具”来做这样的集成,这样的工具基本出自I.O.E体系,动辄几千万RMB一套,甚至还要用上百万的小型机去部署。

    钱花了,如果东西出来了倒也成了,关键是SOA还有一整套完整的“系统集成”体系化的概念。所以经历过SOA集成的都领教过所谓的“流程”。

    大家知道,所谓流程是一套best practice,它是用来帮助我们更好的更有条理的在一个如此宠大繁杂的、多达十几个几十个legacy系统集成中遵循的一条最佳途径,它并不是条条框框的死板的理论。

    至于流程是否我们真的学到了、消化了同时是否运用得当这是后话不会在本章展开,后面的章节我们会来讨论,我们就先説用SOA没有用好拿它集成完了的东西带来了什么样的噩梦吧。

    好,下面是一个运行SOA系统集成理念集成好的东西,当年国内很多大公司就是这么干的!

    这是后台用SOA理念集成好的东西,但是它在面临中国市场时又被打得体无完肤了。为什么呢?

    因为在I.O.E准备恶狠狠的、用昂贵的SOA的RAD套件进行密集推销时,我们国内的电商已经开始面临百万、千万甚至亿万级的流量了。什么东西到了中国一来,都会使用到各种高技术,国外对这点非常想不通!为什么呢?其实事情很简单,因为中国的人多,人多那么数字化流量也一定大么!中国人已经在开始思考解决大并发大流量的时候而国外还在考虑如何把“昂贵的铲子”去卖给大型零售商。于是,差距开始造成了!

    一个欧州国家的人口甚至整个欧州人口加在一起都不一定有我们的一个门户级网站的流量的人口多,势必这些国外的“高大上”会遇到水土不服,于是。。。买完了铲子,更可怕的噩梦发生了。

    频繁的CR带来的系统开发维扩成本急剧上升

    大家都知道,一个系统、一段代码它一定会经历“分析、设计、编码、测试、部署”几个阶段。如果这段代码有任何修改,它要再进行bug fix后再需要走一遍“分析、设计、编码、测试、部署”这几个阶段。

    大家知道吧,很多供应商有时为了进入一家企业做项目,它们在一开始可以跳水价、可以大甩买甚至可以0元进入,那么它挣的是什么钱呢?CR!

    对,有任何一个CR,如果再加上它是一个高大上的国外的所谓著名品牌,那么它的man day的费用会很高。比如説国内的人天单价在2,000~3,000,国外可能起板要收你4,000~6,000元的人天单价,其实人天单价6,000也已经算便宜的啦 ,你们真的没尝过8,000~1万、4万的人天单价呢!!!

    那么对于这样的公司来説,它最开心的就是甲方给他做CR,最好你依赖它,改个接口都要靠它。接口一个收8万,爽啊!!!

    好,一个复杂的系统集成完了,稍稍有任何改动,它牵连的可不只是它自己这一块代码,它会牵连到其它相关的代码,这种问题我们把它称为regression bug,为了做好regression bug的控制我们就要做regression test来保证我的这次改动不会影响到其它无关的功能。

    要知道,系统集成和"系统融和”是完全不一样的。系统集成的内部就是一团“乱麻”,业务层代码咬合在了一起,改一个功能就会引发一系列连锁反映。

    我举个例子来説,国外的系统集成或者説是很多国内软件供应商并未真正把SOA的理念吃透、甚至在瞎用,它们的手法就有点像“把一个人放在病床上,然后为了给这个病人安装一根假手指而需要把这个病人的整条手臂先卸下来,装上手指后再把这个手给病人安上”。

    它就由如下图哪怕是新增一个功能它要动到的也是一系列的“翻原代码”的行为,加上国内IT从12年后发展越来越快、整体行业较浮燥,导致国内程序员水平普遍很低。缺乏整体数据流、业务串联的能力,那么这样的改动引起的连锁反应会更大。

    拿我司曾发生过的一个案例来説,要在原有系统上做一个大闸蟹打折活动,这种设计的做法就是:

    • 设计数据库底层
    • 制作DAO
    • 制作SERVICE
    • 制作Controller
    • 制作页面

    然后有任何bug,bug的修复会把整个软件开发生命周期从头到尾再来一遍,这样的事不断的again, again, again。

    于是,一个活动做个80多人天,花掉10几万20万很正常。如果碰到“高大上”的外企来给你集成,那么把80人天剩4,000,6,000...那么做一个活动用掉个50万,80万,很合理呀。这就是我们很多国内的一 些大型零售企业在系统集成时碰到过的大血坑。

    钱,花了很多,效率又低,质量又差。

    这次的赫兹花了2亿做电商做砸了正是碰到这样的一个血坑。

    如果只是钱的问题还可以容忍,关键在这样的系统集成来到了国内碰上的最坑爹的是“系统并发”问题。

    前面説了,国内的人多,数字化流量高,这样的一种其本身后台legacy system还未经过改造只是遵照着SOA理念去做的系统集成出来的东西是根本挡不了大规模的“并发”的,国内动不动就来个十万级、百万级并发。。。。。。

    这种后台实际上充满着“单体”应用的电商应用APP,实际上是一个连千级并发都撑不住的东西,于是花了钱又做不好事,好了。。。很多企业没有死在“业务领域的竞争”中而是死在了“在国内上了电商系统”后死这个原因上了。

    成就了一上电商就死,电商领域成了一个“95%的电商项目都失败”这么一个“炼狱”了。

    于是基于“系统集成1.5”后又诞生了“系统集成2.0”模式,这次,卖铲子的又没有错过挣钱的好机会于是它提出了SOA2.0模式。

    SOA2.0模式

    这是I.O.E相关的体系们提出的SOA2.0模式,它很理论。但是它在2012~2014年间在其理论框架的指导下诞生了不少衍生技术。

    比如説它的“松耦合,高内聚,组件间无状态,外部模块间需要使用引用,强调系统整体监控、性能上的governance”,等衍生出了轻量级的Nginx、JSON API,ELK,NOSQL等一系列概念和组件甚至优化改造过了一系列之前的时代没有出现过的组件。

    可是当I.O.E体系还只停留在提出这些理念和这些组件的时侯,而我们国内的电商正在发生着巨变。历尽4次双11消费习惯培养后阿里完成了40亿到百亿规模的转变,此时它开始做一件事,那就叫去I.O.E。不要你那些动不动几百、几千万的软硬件了,我们国人一切靠自己来还比你们做了好!

    阿里去I.O.E引起了一股mySQL浪潮。而此时的I.O.E体系也已经日落西山了,IBM在惨败苏宁案例后退出了中国,很多SOA的精华其实从未被真正落地过,同时它被很多国内的开发商错误的理解和使用了,使用的目的也只是为了炒概念、卖高价。在当时,国内有超过90%的开发商认为:NGINX去代Apache,轻TOMCAT,JSON API,ELK,mySQL的组合就可以做电商了。

    OH...MY...GOD!

    首先理念错误、理解不透彻加上整体IT环境浮燥、只求实现不求精的风貌导致了又出现了一个API时代的怪胎,我们説API是一个好东西,可是它造出的怪胎更诡异!

    先从开发团队来错误的理解SOA2.0理念开始分析,下面是一个标准的在当时直到现在还有很多开发团队是这么认为的一种项目分工上的划分模式。

    我们拿JAVA项目来説,把系统划分成这么多子模块,再分别开发和打包以及分布式部署,这就是SOA!

    一切看似那么的自然。。。。。。那么的应该。。。。。。那么的。。。最后在面临国内十万、百万、千万级并发时死得那么的惨

    • 淘宝惨烈过
    • JD也惨烈过

    要不然怎么会出现“JD老刘的两把菜刀”的故事呢?以前去深圳学习JD618保卫战时还听説这个“两把菜刀”是真事呢!!!

    我们来看看工程项目上折的细又小、看似专业实际没有深入理解SOA2.0时代的精髓而只学到了表面的东西导致在当年产出的是一种什么样的怪胎吧。让我们直接从系统层面入手分析

    两个架构,先説一下其实都是“怪胎”;

    尚且不説第二个“看似专业设计架构”很多国内的供应商、软件开发团队还未达到只达到了前一种“通用设计架构”的水平,第二种架构再怎么説也比第一种要好一点,我们把它称为怪胎1.0和怪胎2.0版吧。

    怪在哪呢?下面来分析怪胎2.0版。

    场景发生在某大促的当天,在平时怪胎架构一点问题都不会发生,一切看似相当的正常和完美。而当大促这天一到,抢券、秒杀、折上折一开始:

    1. Web层汹涌压力扑面而来,这时的反映就是用户手机APP端卡死、白屏、卡顿、没反映;
    2. 于是运维一看Zabbix,哇~所有Web服务器标红,业务老板在屁股后面催的紧“快点搞定”,于是乎运维紧急增加Web服务器;
    3. 好,Web流量进来了,tomcat层吃不消了,zabbix频频告警,老板在屁股后面又开始催了“怎么还没搞定?”。于是我们增加tomcat服务器;
    4. tomcat扩了N个自以为没事了,加完后整个DB挂了,CPU飙升到100%以上,内存使用率高达95%以上,一堆的死锁,APP还是卡、白屏,这时已经距离活动开始过去了1小时了,业务老板破口大骂:“你们有没有做过电商呀,你们到底懂不懂,搞不定,滚”
    5. 这时运维傻了。。。介个问题。。。需要研发来帮忙了
    6. 好吧,活动第一天,失败。老板组织了研发、运维浩浩荡荡一大批开了个总结大会来研究第二天的方案,研发终于提出了靠谱的方案。很多内容可以走缓存,我们不该走DB的。于是大家开始了不要命的熬夜改造DAO层代码,把一些通用的都移到缓存;
    7. 此时,离第二天还剩4个半小时左右了,抓紧睡一觉吧,很多开发睡觉时还在做美梦,梦到第二天因为开发团队的给力付出我们终于顶下了流量,老板重点表扬开发;
    8. 第二天活动开始了,哇~一开始30秒时整个流量似乎比昨天大了2-3倍,这个很正常呀因为系统放开了吃流量肯定这个量超过昨天的量,然后30秒过了没多久,整个APP卡死、白屏。哈哈哈,再一看,缓存爆了,缓存爆了后流量落到DB,DB又来了一个CPU飙升到100%以上,内存使用率高达95%以上。。。。。。
    9. 再加DB,DB加完后发觉第三天量更大了,再加Web,Web加完后Tomcat中间群被压跨了,再回到以上第3点

    多少企业经历了上述的过程?我告诉大家一个值,超过90%的企业都有过上述的大血坑。

    这个大血坑会造成不少创业型公司秒死、见光死,也造成很多大企业一整批IT被干掉,也造就了那传説中的“两把菜刀”。

    这样的系统和设计它其实是由如下面的这样的一个怪胎的长相:

    脑袋小,脖子细的要命,肚子大,下盘小。吃饭吃多了他就呕,走路一快他就摔!这么样的一个怪胎!

    那么我们説系统性能没有做好?业务功能就一定做好了吗?

    嘿嘿嘿,我们回看I.O.E体系们在SOA2.0时代提出的一个概念图,再来看一遍这个图

    然后我们结合以下的一个场景再来考虑一下:

    小龙虾节活动,从数据库设计->存取层->服务层->控制层。从头到尾做了一遍,用掉了80多人天的价格。

    来了一个阳澄湖大闸蟹打折活动,从数据库设计->存取层->服务层->控制层。从头到尾做了一遍,又用掉了80多人天的价格。

    嘿嘿嘿,我们把以上深奥的理论,抽像成以下一个这样的业务场景大家看一下,是不是就可以理解为什么上述两个都同样是打折活动的业务场景分别都要用80多人天呢?

    上图已经可以很好的说明我们的程序员是如何沦落到程序猿、码农的了。

    性能达不到、加速业务、快速响应多变的由其是中国大陆市场几乎每天都在变动的业务也做不到,这是2005~2015年这10年国人特别是国内很多知名500强在电商领域经历的痛苦的10年,各种抱怨IT不给力。

    IT各种想办法找I.O.E相关体系来做企业整体解决方案,钱出了一大波,然并卵,各种继续不给力、抱怨。。。。。。again,again and again!!!

    而这10年,阿里和一些走在比较前沿或者説曾经在那10年内没有“死”的一些民营体制、特别接中国地气的企业他们已经开始深刻得总结、反省、并且依靠着自身之前学习到那些外资高大上的一些理论、知识、方法论后把它们再“本土化”并结合了中国自身特色,继而打造出来了一个新的产物,这个新的产物就是“全渠道零售中台”。

     

    回过头来看中台,什么是中台

    也有画成下面这样风格的图

    其实第2张图和第1张无非就是第一张的level3级别功能扩充了比较丰富点,第二张呢颜色鲜明一些。

    That's it,仅次而己!

    然后很多外资包括国内的一些甲方型企业拿着这样的图説“这就是中台”。。。。。。现在知道错在哪了吧。

    我上面列举的1.0,1.5,2.0时代的任何一种架构,其实都可以做成这样的“业务功能图”。

    这只是业务功能图而己,它不是代表"我“做出来的就一定是中台。

    我们看事务不能光看“外表”,我们需要看事物的“本质”,遵循着本质的那些公司都成功了,如阿里、苏宁、保洁、立白、海尔、华为。。。。。。有很多不再多叙。

    那么中台的本质到底在什么?而且是一个全渠道中台,也有人管它叫云中台它必须具备以下几样东西

    从业务功能上来分

    1. 全渠道订单中心,它必须是一个全渠道的订单中心,订单属性拥有线上、线下、O+2、第三方等各种渠道的特性;
    2. 全渠道商品管理中心,可以管理线上、线下甚至是虚拟商品;
    3. 全渠道会员中心,这个会员中心一分为2,一个合格的中台需要具备其中的CRM Foundation即会员中心基础功能,另一个叫“营销中心”,对,整个会员中心由“基础功能+营销中心”两部分构成,而很多好的中台不一定包括这个“营销中心”,因为营销中心可以诞生出另一个全渠道的产品,叫SCRM。我们不要求一个全渠道的零售中台内必须包括全渠道营销中心,必竟术业要有专精;
    4. 全渠道的促销中心,促销和营销很多人会搞起来,促销中心和营销中心在功能上是有相近的,有人把促销归为营销也有人把促销和营销进行分离,分离的条件就是“以会员为中心”和根据一个企业内的业务组织架构来决定的。这一定一定是一个全渠道的促销中心,它可以对线上线下同时促销,説白了就是你在手机APP商城内使用的券同时也可以使用在自助机、扫码购、微信小程序甚至在同一个零售企业门店POS结帐时使用,让客户无论是在线上还是在线下消费时“无缝/无差别”体验,这就叫全渠道。不管你什么活动、打折、促销,它还都是可以支持图形化界面可配置的;
    5. 内容中心,它又被称为CMS即Content Management System。它可以把手机、微信小程序、Web网站通过图形化类似于Photoshop或者説它比较接近于以前的DreamWeaver或者是FrontPage的一种“傻瓜”界面把这些活动给配置出来,它在配置的时候是可以通过结合前面的促销中心去做“协同工作”的;
    6. 财务共享中心-支付渠道啦、支付中心啦,支持各种支付,接入支付渠道时它也是可配置或者説是“半可配置”来完成一个支付渠道的接入的;
    7. 物流库存中心,支持全渠道的物流和库存,不管是自营、O+O、第三方还是自提,全部支持;
    8. 多租户管理中心,咦。。。。。。这是什么东西?唉呀,很简单!都上全渠道中台了,你这个电商不可能只是面向垂直单一名牌吧?一定是类似于“天猫店”那种多商户玩法吧?也有人管它叫B2B2C或者干脆简称成BBC功能;

    从技术上来分(月球的背面到底是什么)

    我们前面説了,业务功能它的表现出给到大众的一面很美丽、很灿烂。可是它不是本质,它不代表全渠道中台,我们需要了解月球的背后到底是什么?是不是真的有ET?喂。。。老婆,出来看上帝啊!

    从技术上来説一个全渠道必须具备如下几大功能,缺一不可,对。。。缺一不可!

    1. 微服务总线,这是必须要有的,真正的微服务讲究的是什么哈?我们先不説微服务所有的细节功能单説涉及到我们性能的那么几个功能吧:1)平峰削谷 2)服务自发现 3)服务升级降级 4)可弹性扩充,只説这4个点,有这4个点绝大多数的零售电商网站够用了,除非你能达到淘宝的量,我们后面章节会把微服务功能逐个剖析、亲自动手设计、乃至实现
    2. 各业务模块可纵向扩展,横向扩展是很简单的事,什么叫业务模块纵向扩展?比如説订单的写入和读都可以作分开的部署
    3. 可弹性的分布式的并且是多样化的缓存群
    4. 异步消息队列-MQ,必不可少
    5. 规则引擎,你当促销中心是怎么实现的?嘿
    6. HTTP请求级别缓存,这个缓存可和后台的那个分布式缓存群是不一样的东西哦,它缓存的是用户请求,相当于一个CDN功能但是和CDN又不一样,因为CDN只能缓存绝对静态的内容
    7. 分布式批处理任务-类似于网络计算,它比网格计算更轻、小
    8. 标准的安全认证登录接口,支持最常用的如:JWT,OAUTH2等协议
    9. 支持分步式数据库,此处可不只是一个数据库,你要有钱可以去烧Oracle RAC,阿里在20~40亿时为什么它要去I.O.E?那么用开源的数据库你需要怎么去实现原来的Oracle RAC的功能呢?当然你雇了一堆的架构师自己也是可以去打造这样的分布式数据库的结构应用的,只是一个产品如果它的原生就支持分布式数据库、分布式事务、可折表折库(此处指的可是纵向折哦),横向谁不会无非就是加slavers:)
    10. 成熟的性能监控
    11. 成熟的CI(持续集成)组件
    12. 配置中心,一个全渠道中台,组件少的有10多个模块,每个模块至少2-3个服务器,多的几十个模块,oh my god,全部写在properties文件里?Are you kidding me?

    所以,月球的背面长的是个什么样的呢?即什么是真正的全渠道零售中台?

    全渠道零售中台的“真容”

    我用下面的这张图来解析全渠道零售中台的技术的面长成个什么样!

    把我这篇文章的第1张图配合着全文最后一张图来看,那么你看的才是一个真正的全渠道中台!

    这两张图:

    1. 只看第1张,你会被人忽悠的体无完肤,出了钱买不到好东西;
    2. 只看第2张而不看第1张的结果是,你可能买到的不是一个产品级的解决方案而只是一个技术框架,一切业务功能需要从头开发,这是巨大的工作量和成本的付出;

    但是,不代表你把上述2张图结合起来看了就一定可以找中你“命中的中台”,还有很多、很多其它因素需要考虑。

     

    最后説一下为什么叫中台这个“中”字呢

    从业务层面解析为什么叫“中”台

    中台,我们的国人为了解决“TO C端业务的快速多变”,使用的是诸多非功能性需求如CMS+规则引擎+图形化编程,其实説白了就是把TO C端的前端的逻辑“下沉”,下沉到了这个中台系统中而不是停留在APP端 ,把APP端的功能做成了可以通过后台配出来,我之前的博客説过,所谓IT上口头説的“业务业务”,指的就是用户端功能,而不是让你去考上岗证。

    中国人做的这种高度一体化方案是基于可以彻底抛弃ERP的思想来做的,做什么legacy system的改造呢?这些功能在中台里已经有了,把你原来企业那10几个legacy system的数据做一次性的迁移,然后系统一刀切掉就好了,这是中国人的思路!但是中台在推出不久后它又要兼顾着中国人自古的“包容”精神,即我又要可以支撑原有legacy system和我的集成。那么,把原有后台legacy system的功能也放到这个中台系统中,因此它是后台业务功能的“上浮”。

    一个TO C端业务的下沉;

    一个后台业务功能的上浮;

    而中台它处于当中这一块地位,因此它就叫“中”台!

    而不是很多人认为,它处于后台和APP手机端应用的当中因此才叫中台的,不是的。这个理解太表面了没有真正理解中台的中到底为什么要叫中的背后的原理,中台的“中”是我上述这一段总结,这是业界真正公认的“中”。

    因此我这一系列文章才不仅仅只是写业务(解决方案)或者写技术,还要写数字化变形、写管理、写策略。。。。。。后面我们还会有更多精彩!

    先预告一些下一章内容吧:

    下一章我会对全渠道零售中台中的业务功能、技术组件一个个折开来、揉碎了和大家讲解!

    展开全文
  • 2、解读中台 -- 中台的作用

    千次阅读 2019-10-06 19:43:41
    中台的作用 中台应该包含哪些内容呢?什么应该包括在中里?什么不应该放在中台里?中台与企业现有的ERP,CRM是什么关系? 如果建设了中台,中台应当如何发挥作用,而不是又让企业陷入建设另一套IT系统的老路? 1、中台...

    中台的作用

    中台应该包含哪些内容呢?什么应该包括在中台里?什么不应该放在中台里?中台与企业现有的ERP,CRM是什么关系?

    如果建设了中台,中台应当如何发挥作用,而不是又让企业陷入建设另一套IT系统的老路?

    1、中台的分类

    中台是从多个相似的前台业务应用共享的需求中产生的,因此最先提出的中台是业务中台;

    数据是从业务系统产生的,而业务系统也需要数据分析的结果,那么是否可以把业务系统的数据存储和计算能力抽离,由单独的数据处理平台提供存储和计算能力?

    这样不仅可以简化业务系统的复杂性,还可以让各个系统采用更合适的技术,专注做本身擅长的事,这个专用的数据处理平台即数据中台。

    2、业务中台定义及建设内容

    业务中台是阿里巴巴首先提出的企业IT架构的转型之道,站在阿里巴巴集团全局的角度看,业务中台是从整体战略、业务支撑、连接消费者和业务创新等方面进行统筹规划的;因此业务中台内含了阿里巴巴电商交易的主营业务。业务中台更多关注的是如何支撑在线业务。阿里巴巴一开始将淘宝作为平台方连接商家和消费者,进行电商交易活动,随之发展出淘宝商城,即后来的天猫;天猫本质上还是电商交易平台,既然都是电商交易平台,就都涉及售前、售中和售后的业务流程。

    业务中台围绕以交易为核心关联的领域组成,交易的对象是商品,商品通过店铺售卖给会员,交易的凭证是订单,在线交易需要支付,成单后需要货品出库和物流派送等,售前需要营销促销活动吸引流量并加强转化,售后用户会对店铺、商品进行评价等。由此可见,典型的业务中台由多个业务服务中心组成,如下图所示:

    (上图是由服务中心组成的业务中台)

    会员中心:服务于用户的消费全生命周期,为用户提供特定的权益和服务,企业可以通过会员中心与用户进行互动,培养用户

    忠诚度。其主要能力包括:

    1)会员运营管理:  包括会员注册、个人信息维护、会员注销、会员卡办理等相关能力;

    2)会员体系管理:  包括会员体系的创建、积分规则、成长值规则、等级、权益等相关能力;

    3)客户服务管理:  包括客户的新增、导人、查询等相关能力;

    4)积分交易管理:  包括积分获取、核销、清零、冻结、兑换等相关能力。

    商品中心:提供管理商品核心数据的能力,围绕商品构建商品关联数据,诸如商品版本信息、商品品牌、商品属性、商品类目等。其主要能力有:

    1)品牌、类目、属性管理:  包括对商品品牌的维护、查询,前后端类目的维护,属性及属性组管理等相关能力;

    2)产品数据管理:  包括对产品模板的创建、编辑、查询、禁用等相关能力;

    3)商品数据管理:  包括商品创建、修改、查询等相关能力;

    4)商品发布管理:包括商品发布、上下架(即时+定时)等相关能力。

    交易中心:负责企业业务交易订单的整体生命周期管理,包括加入购物车一订单生成一合并分拆一流转一支付一发货一退换货-完成。所有电商业务的核心系统都是围绕交易订单进行构建的。其主要能力包括:

    1)购物车管理:  包括购物车商品添加、编辑、查询、校验等相关能力;

    2)正向交易管理:  包括交易订单生成、发起支付交易订单、商品发货管理、上门自提及核销等相关能力;

    3)逆向交易管理:  包括换货、退货、退款等相关能力;

    4)订单数据管理:  包括交易订单、支付记录、发货记录、换货记录、退款记录等数据管理能力;

    5)交易流程编排:  支持交易流程节点的配置化,便于根据业务场景的不同设置与之匹配的流程。

    评价中心:提供对评价主体对象、评价规则/等级、评价内容、评价操作的管理能力,从而满足不同角色的评价用户对评价内容的发布、追加、平台审核、平台申诉等需求。主要能力包括:

    1)评价内容管理:  包括管理评价的主体对象、评价规则配置、评价等级、评价标签配置等相关能力;

    2)评价操作能力:  包括评价的发布、修改、追加、回复、申诉等相关能力;

    3)评价监管能力:  包括评价发布审核、申诉审核、评价屏蔽等监管相关能力。

    店铺中心:提供企业店铺主体管理、店铺管理、类型管理、经营对象管理等能力以支持企业为商户提供线上门店,同时也支持商户管理、店铺会员、店铺会员等级管理、店铺装修等。其主要能力包括:

    1)商户管理:  包括商户单个、批量开通,商户审核,商户基本信息维护等相关能力;

    2)店铺管理:  包括店铺开通、店铺基本信息维护、店铺审核、店铺会员等相关能力。

    支付中心:给下游商户输出标准的支付服务,提供代付代收、财务对账等服务。通过对接多个主流渠道,稳定输出微信、支付宝、银联等支付能力。其主要能力包括:

    1)支付能力:  包括创建支付订单、接收渠道通知、查询渠道订单等基本支付能力;

    2)支付路由:  包括支付渠道管理、支付方式管理、支付商户和应用开通管理等相关能;

    3)资金账户:  包括资金账户管理、充值维护、提现等相关能力。

    营销中心:提供商家的活动计划、申报、审批、执行、核销的全链路管理,也提供基本的促销能力,如优惠券活动、满减买赠

    等。其主要能力包括:

    1)活动模板管理:  包括提供营销活动的策略模板、规则配置、条件、动作模板等相关能力;

    2)活动管理:  包括提供具体活动的基本信息配置、人群圈选、商品管理、触发条件等相关能力;

    3)优惠券管理:  包括优惠券的发放、领取、查询、使用核销等相关能力;

    4)赠品管理:  对于满赠、买赠活动,提供赠品维护、查询、启用、禁用等相关能力。

    库存中心:提供仓库、库存、货品、单据(入库单/出库单/盘点单/盘点盈亏单)、审核(调拨/盘点)、包裹、货品运费、物流运输、接入第三方物流公司的服务能力。其主要能力包括:

    1)仓库管理:  包括服务区、仓库、仓位及其关联管理等相关能力;

    2)货品管理:  包括货品进货入库、销售出库、调拨入库、调拨出库、调拨审核等相关能力;

    3)货品盘点:  包括盘点单生成、审核、查询等相关能力;

    4)履约管理:  包括库存检查、发货单创建及查询、包裹物流查询、运费管理、物流状态跟踪等相关能力。

    建设一套中台系统,可同时运用在多个电商平台的开发设计和服务中;因此中台可以为同时建设、运营多套电商平台的互联网企业节省系统建设和运营成本。因为中台既可以避免功能重复建设,又可以通过全渠道打通会员系统来增加流量、互相促进,还可以减少运营成本和人员。有了中台,再发展电商相关应用就会变得更加容易,比如,阿里巴巴发展出的聚划算。

    如果使用传统的系统思维来设计业务中台,很有可能只是将原先隔离的各业务系统通过微服务的方式,强行集成在一起,如下图所示:【传统思维下所建设的“业务中台”】

    这种方式构建的微服务不是纯粹基于领域进行建设,而是从一个系统的粒度层次进行建设。比如PMS会涉及用户和订单, OMS也需要关注会员和订单, CRM同样涉及会员。因此,按此方式建设的所谓中台,它的各组成部分还是互相交叉重叠的,并不能体现中台是能力共享平台的核心理念。所以,只对企业业务系统做一个大一统的集成,并不是中台。

    3、数据中台定义及建设内容

    数据中台是什么?

    数据中台与数据仓库有什么区别?

    数据中台到底怎么与业务中台融合?

    这三个问题一直以来是人们问得最多的问题,本节将试着对这三大问题进行解读。

    在回答数据中台是什么这个问题之前,先了解一下数据仓库。在以BAT为首的互联网公司蓬勃发展起来之前,国内三大电信运营商对于数据仓库的建设走在其他行业的前面。早在2011年的时候,中国移动集团公司就组织编写了指导各省公司建设数据仓库的纲领性文件《中国移动NG2-BASS3.0建设规范》,在文件中明确将中国移动的业务分成了7大业务板块,按照功能将数据资产划分为三层:数据层、功能层、应用层。这是很典型的数据仓库建设的分层模式,如今的数据中台数据分层建设模式也延续了数据仓库的分层建设规范。【下图为某电信运营商数据仓库分层模型】

    上图所示是某电信运营商数据仓库的应用层规划内容,详细规划了每个应用领域的数据应用,但是仔细研究可以发现,这些数据应用几乎全是“分析”,也就是解决了事后"看数据”的问题。【下图为阿里巴巴数据中台总体架构图】

    再来看看上图所示的阿里巴巴的数据中台支撑的数据应用层,除了通用的数据分析以外,还包含“个性化推荐” “风险评估"“预警监控”等与业务紧密结合的数据赋能业务的应用,而这些丰富的赋能业务的数据应用必须依赖数据中台提供的强大的数据服务来支撑

    通过上面的对比不难看出,数据中台与数据仓库最大的区别就是数据中台更加贴近业务,不只提供分析功能,更重要的是为业务提供服务,与业务中台或者业务系统(老旧系统)连接更加紧密了。

    就拿“千人千面”案例来说,除了要整合业务系统产生的用户基础属性、订单、评价、加入购物车等行为数据,还要通过埋点的方式实时获取用户偏好浏览、搜索、分享商品等行为数据,经过数据中台对一系列的数据进行加工处理(见下图),最终以微服务的形式提供支持。

    在业务系统中,每个需要呈现商品给目标用户的数据服务,已不是简单地、一成不变地去商品库查询数据,而是调用数据中台提供的商品推荐接口,以此来根据不同的人群偏好、浏览历史、商品相似度等数据来为每个人推荐他最感兴趣的商品。试问这种业务、数据紧密联动的场景在数据仓库时代又如何能做到呢?【下图为数据中台与外部系统交互】

    数据中台到底是什么?首先说说数据中台不是什么。

    第一、数据中台不等于大数据。近些年, “大数据”这个名词可能是被提及最多的词汇之一,大数据甚至成为国家战略。同时, “数据中台”也正是在大数据概念兴起之后应运而生的。因此相当一部分人把数据中台和大数据划等号,一提到数据中台,就想起Hadoop, Spark等大数据处理技术,这样的想法是不对的,这些大数据处理技术只是数据中台的基础设施提供者。大数据技术大行其道,加速了数据中台战略成熟。

    第二、数据中台也不是一个研发工具。最近一段时间,在市面上流行着一种说法,说某某公司有一个数据中台产品,可以直接卖给某某客户。这种说法是在忽悠客户,实际提供给客户的仅仅是一个可视化的研发工具而已。数据中台一定是整合了企业自身数据并经过加工、治理后形成企业自身的数据资产的平台。试问,根本还没了解客户到底有什么数据的情况下,如何能说自己有一个数据中台产品呢?

    那么如何定义数据中台呢?

    数据中台是一个用技术连接大数据计算存储能力,用业务连接数据应用场最能力的平台。

    “连接能力”是数据中台的精髓,作为一个处在中间层的能力平台, “连接”是其根本任务。在业务层面需要尽可能连接各种数据源作为其生产资料;同时,由于生产数据的场景越来越多,覆盖了线上、线下等多渠道,各数据生产资料之间也需要进行连接,才能形成全域的数据;数据在数据中台这个平台上按照标准的模型进行规范加工处理后需要服务于多种场景,同样需要我们提供标准的数据服务接口将数据与应用场景连接起来。因此,连接是数据中台的根本能力,也是数据中台的价值所在。

    4、业务中台和数据中台的关系

    无论是业务中台还是数据中台,都是在企业IT系统架构演进过程中形成的,并从企业自身IT系统规划、建设、运营、运维等多年的经验中提炼出来的共性能力。业务中台和数据中台作为两个轮子并肩构建了数字中台,支撑前台对会员提供从营销推广、转化交易到智能服务业务的闭环服务,促进企业业务的提升和发展,如下图所示。数字中台对内连接企业的后台系统,诸如ERP、人力资源、协同办公、财务管理等。【下图为业务中台与数据中台双轮驱动的数字中台支撑前台业务】

    业务中台抽象、包装和整合后台资源,转化为便于前台使用的可重用、可共享的核心能力,实现了后端业务资源到前台易用能力的转化,为前台应用提供了强大的“炮火支援”能力,且随叫随到。业务中台的共享服务中心提供了统一、标准的数据,减少了系统间的交互和团队间的协作成本。

    数据中台接入业务中台、后台和其他第三方数据,完成海量数据的存储、清洗、计算、汇总等,构成企业的核心数据能力.为前台基于数据的定制化创新和业务中台基于数据反馈的持续演进提供了强大支撑。可以认为,数据中台为前台战场提供了强大的“雷达监测”能力,实时掌控战场情况,料敌先机。不过数据中台所提供的数据处理能力和在之上建设的数据分析产品,也不局限于服务业务中台。数据中台的能力可以开放给所有业务方使用。

    从前台应用的角度看,业务中台所提供的“炮火支援”能力和数据中台所提供的“雷达监测”能力是一体的,并不是相互独立的;

    业务中台与数据中台相辅相成,互相支撑,对于业务方来说, 自己产生数据,并同时消费自己的数据,在消费自己的数据时又在继续产生数据,从而形成数据闭环;

    打个比方,业务沉淀数据是产矿,将数据导入数据中台是探矿和挖矿,数据中台对数据进行建模等加工处理是对矿物的加工提纯,通过数据服务指导业务的开展是矿产再生的过程;

    业务中台和数据中台只是技术实现方式不同,它们一起组成了支撑业务创新的两个“轮子”,缺一不可。

    内容来源 --- 《中台战略:中台建设与数字商业》

    展开全文
  • 中台打破了应用系统的壁垒,从企业全局梳理和规划业务程,重构了组织架构、业务架构与IT 架构。 在梳理了企业的IT 现状并回顾了SOA 的历史之后,我们需要对中台架构进行一番详细的介绍,阿里巴巴的Aliware 团队曾经...

    中台打破了应用系统的壁垒,从企业全局梳理和规划业务程,重构了组织架构、业务架构与IT 架构。

    在梳理了企业的IT 现状并回顾了SOA 的历史之后,我们需要对中台架构进行一番详细的介绍,阿里巴巴的Aliware 团队曾经给中台下过这样的定义:

    将企业的核心能力随着业务不断发展以数字化形式沉淀到平台,形成以服务为中心,由业务中台和数据中台构建起数据闭环运转的运营体系,供企业更高效地进行业务探索和创新,实现以数字化资产的形态构建企业核心差异化竞争力。

    现在中台战略常被简单地概括为“大中台,小前台”,意思是说将企业的核心业务能力沉淀和聚集到由业务中心组成的中台层上,前台应用以中台为支撑,向轻量化、敏捷化转变。本文核心观点援引自作者所著的《大数据平台架构与原型实现:数据中台建设实战》一书,全书对数据中台的理念、架构和具体实现做了详细论述。 (注:本文已由CSDN云计算公众号首发)
    在这里插入图片描述

    图1 战场中的中台阵型

    图1 是《企业IT 架构转型之道:阿里巴巴中台战略思想与架构实战》一书中给出的关于中台战略非常形象的描述。这张图描述的是Mei军现行的作战模式,在一线战场,Mei军通常以班为单位组织军事行动,这种极小型团队行动敏捷,容易捕获战机,一旦发现敌情就通过指挥系统呼叫强大的炮火和空中支援给敌军以重创。美军的这种战场组织阵型与中台架构的思想是一致的,战斗小组就是“小前台”,强大的炮火群和空中力量是“大中台”。在强大中台的有力支撑下,前端在进行业务运营和创新时会变得非常高效且灵活,企业可以根据最新的市场动态展开各种尝试和调整,一旦发现并验证了新的市场机遇,就可以调集中台的强大能力迅速跟进,抢占市场。

    中台作为面向互联网时代的企业新一代IT 架构最大的威力不在于解决眼前的问题,而是系统性、结构性地重组企业的IT 生态系统、业务架构及组织架构,它能帮助企业从本质上提升竞争力,降低成本。它将带给企业如下的能力与收益:

    • 应对未来所需的更快的业务创新和成本更低的业务探索;
    • 给企业带来核心竞争力的提升,提质转型、降本增效;
    • 给业务快速响应和创新带来的业务价值;
    • 给信息中心带来组织职能转变的机会;
    • 共享服务架构能提升企业整体效能。

    1 中台架构概述

    以中台的视角看待企业的整个IT 生态,可以将其分成前台、中台及后台三大组成部分,三者的定位如下:

    • 前台:由直接面向市场和终端用户的业务应用组成,负责支撑企业的前端业务;
    • 中台:由按业务领域细分的服务中心组成,负责支撑企业的共享业务;
    • 后台:由企业内部业务系统组成,如生产、库存、物流等管理系统。

    前台与中台的关系是:业务中台负责提供企业范围内共享的基础业务服务,前台应用会对这些基础业务服务进行组织编排,快速地在前端以产品形式将业务能力展开,以适应日新月异的市场变化。

    中台与后台的关系并不像前台与中台的关系那样紧密,中台架构是为了让企业拥有开放、创新和灵活的市场应变能力而提出的,这对于生产、库存、物流等后端系统的影响并不大,并且这些系统需要严谨和规范的组织与管理,因而会保持相对传统的组织架构与生态。

    由此可见,中台在企业的整体业务体系中起着核心作用,而建设中台的最大挑战也来自对中台层各服务中心业务能力的提炼和萃取。

    以零售和消费品行业的企业为例,往往会有如下一些面向市场和终端消费者的服务中心:

    • 用户中心:负责用户信息的全面管理,建设和维护会员体系,制定并推行会员运营策略;
    • 商品中心:负责商品的全面管理,包括SKU、品类及商品相关的各种属性、标签的管理;
    • 交易中心:负责统一管理线上和线下所有的购物车、订单及交易数据,并提供交易相关的各种服务;
    • 营销中心:负责全渠道的营销,对营销活动的全过程进行管理。

    以上四个是比较有代表性的业务中心,每一家企业还可能会基于自己的业务模式组织其他诸如支付、门店、内容、促销等中心。从服务中心的职责和定位我们也可以发现中台的一个重要特征,那就是应用系统的边界被彻底地打破了,不会再有CRM 和OMS 这样的孤立业务系统了,而是将它们所承载的共享业务能力分拆并重组到了各个业务中心,每个业务中心对接和服务的是来自企业全渠道的需求,如何能支撑这些复杂多变的前端需求是建设中台的挑战之一。针对每个业务中心,在业务和技术上都必须要有专业的架构师带领团队来统一梳理这些需求,识别哪些需求应该由中台实现,哪些需求应该由前台实现,这是确保中台架构能够合理存在并稳定发挥作用的重要前提,这个过程不会一蹴而就,而需要在不断的迭代和试错中逐渐明了。不难想象,如果这种切分不够合理就会出现如下两种结果:

    • 如果本应属于共享的服务与逻辑切分到前台,就会导致前台应用过“重”,且不可避免地会出现重复建设问题,因为前台应用无法从中台获得相关支持;
    • 如果过多的非共享服务与逻辑切分到中台,就会导致中台服务的复用性变差,前台应用无法直接调用,因此会产生很多“副作用”和“连带后果”。

    以上两种情形在现实里时有发生,这是企业打磨中台的一个必经阶段,也是团队磨炼对业务认知和对技术把控能力的一场“修行”。

    就“服务”这个概念而言,中台对外提供的“服务”与SOA 中倡导的“服务”并没有本质上的差别。在某种程度上,中台的定位会更加有助于实现真正可重用的“服务”,因为中台不再局限于某一个应用上,而是超脱于应用之上,宏观地看待一个“服务”如何能支持不同场景下的共性需求。因此,那些在SOA 中对服务粒度进行界定和组织的方法依然是值得借鉴的,特别是对基础服务、复合服务及业务流程服务这三个服务层次的划分是非常实用的。

    作为一个呼应,我们来看一下中台架构下“会员管理”是如何进行的:原有的CRM 系统将不复存在,取而代之的是“用户中心”,用户中心沉淀了与用户相关的共享服务,会员注册就是其中之一,前台应用系统进行会员注册时会调用用户中心上的会员注册API 来实现,当然,前台应用可能需要对用户数据进行一定的处理、转换以适配统一的API 规范,这样前台各个应用不再维护自己的“用户模块”,因此也不再需要同步会员数据。

    前面我们讨论的“中台”更具体地说是指业务中台,对于中台的另一个组成部分“数据中台”来说,它更侧重于企业数据的统一收集和处理。相对于应用系统而言,数据的平台化要相对容易一些,这也是很多企业早期就能建立数仓这种中心化、平台化的系统,而在应用系统上却陷入烟囱式的生态的原因之一。不过数据中台并不是传统数仓升级换代那么简单,从技术上讲,数据中台完全构建在大数据平台上,数仓是数据中台的重要组成部分,但远远不是全部。数据中台通常还要具备实时的数据处理能力和高级的算法分析能力,当数据处理完成后,数据中台还要提供强大的“数据服务”,能将结果数据通过各种协议以实时或批量的方式提供给业务中台或应用前台。

    此外,业务中台的建立也会对数据中台的建设起到很大的促进作用。一方面由于业务的梳理和中心化,使采集业务数据变得相对简单,业务中心的后台数据库将是数据中台主要的外围数据源;另一方面,业务中台对业务的切分和领域建模将对构建数据中台上的数仓和数据服务有很大的指导意义,例如,每个业务中心天然就是一个大的数据主题,相应地,也有会有一个独立的API 的namespace 等。

    下面我们把业务中台和数据中台放在一起,结合前面举例的零售和消费品行业来看看一个完整的中台架构,如图2 所示。
    在这里插入图片描述

    图2 中台逻辑架构示意图

    这是一张混合了技术和业务的中台逻辑架构示意图,前台应用部分我们将零售和消费品行业需要对接消费者的若干应用系统一一列举了出来,但是在中台架构下它们已经和传统的“应用系统”有了很大的差别,变得非常“轻量”。过去很多自行实现的业务功能都通过调用业务中台的各个业务中心完成了,如前面列举的会员注册功能,在中台架构下都是调用会员中心上的统一接口完成的。与此同时,各业务中心的数据都将通过数据中台上的数据采集组件采集到大数据平台上,然后通过批处理和实时处理机制构建出企业的数仓体系和高级数据分析能力,最后通过构建数据API (Web 服务)、OLAP 及专有的报表数据库等手段,将结果数据以Restful API、JDBC/ODBC 或FTP 等形式提供给外部使用。

    2 中台的技术体系

    中台由阿里巴巴提出并在业界获得广泛认可之后,阿里巴巴就一直希望通过阿里云平台向企业用户推广一整套的中台技术解决方案,这套方案就是Aliware——面向企业级互联网架构的PaaS 服务。Aliware 包含了企业级分布式应用服务(EDAS)、消息队列(MQ)、全局事务服务(GTS)等,这些服务涵盖了企业应用开发涉及的各个方面。但是中台并非必须构建在阿里云的这些PaaS 服务上,实际上,Aliware 是将当前企业级应用开发的主流技术和框架封装成PaaS 服务供开发者直接使用,所以本质上Aliware 与中台架构并没有必然的关系。

    中台作为一种生态系统级的架构,不会受底层技术的制约,反而倚重和遵循业界主流的技术体系,特别是开源的技术平台与框架。简单地说:

    • 业务中台的主要技术体系是:微服务;
    • 数据中台的主要技术体系是:大数据。

    与技术相配套的是设计思想和方法论,现在微服务的主流设计思想是领域驱动设计,大数据的主要设计思想是数据仓库理论。我们来分别介绍一下这两种技术与它们使用的设计理论。

    2.1 业务中台技术体系

    1. 微服务

    微服务架构最大的特征是解构了过去的单体应用,按照业务功能对系统进行了更细粒度的切分,每一个微服务都是一个可独立部署的单元,微服务内部高内聚,微服务之间低耦合。系统被微服务化之后会在很多方面得到提升和改善,过去在单一应用服务器和数据库服务器上部署的系统将转变为纯正的分布式系统,部署于多台服务器上,这相当于赋予了系统水平伸缩能力,同时局部节点的失效也不会再导致整个系统宕机,而是可以被限制在有限影响范围之内。

    微服务的这些优势使其在最近几年几乎成了企业级应用的架构标准,与之相配套的是一系列基础设施服务和支撑技术。

    • 服务注册与发现;
    • 服务配置管理;
    • 服务网关(API Gateway);
    • 事件/消息总线;
    • 负载均衡;
    • 容错与熔断;
    • 监控与报警;
    • 安全和访问控制;
    • 日志收集与处理。

    经过多年的沉淀和积累,业界在上述领域有很多成熟工具和框架,其中最主流的一站式方案非Spring Cloud 莫属。

    在微服务架构逐渐形成规模之后,就会对硬件资源虚拟化和自动化部署提出要求,与此同时,伴随着Docker 的崛起,人们发现容器化与微服务是一组绝佳搭档,再配合DevOps 技术的推动,最终在业界形成了“微服务 + 容器技术(Dockers + Kubernetes)+ DevOps”三位一体的微服务生态体系,这些技术汇集在一起为微服务的落地和持续演进铺平了道路。

    2.领域驱动设计

    恰到好处的微服务设计是一项很有挑战性的工作,识别、界定与设计微服务考验的是开发人员对业务的理解和设计能力,这需要对业务反复梳理和提炼,再经过仔细地斟酌和拿捏才能有一个比较好的方案。这与技术框架没有太大的关系,考验的是设计人员的“内功心法”,也就是设计能力和对业务理解的透彻程度。以往诸多项目的经验表明,糟糕的设计会极大地削弱微服务的作用,让其变得粗糙、难以被复用。过去,开发人员一直使用一些常规的方法论来设计微服务,如面向对象(OOD)的设计思想,但是取得的效果并不理想,直到后来领域驱动设计(Domain-Driven Design,也被简称为DDD)被社区发掘出来,逐渐成了微服务事实上的设计理论。

    领域驱动设计最早起源于Eric Evans 在2003 年撰写的一本名为Domain-Driven Design: Tackling Complexity in the Heart of Software 的著作,这本书全面系统地阐述了领域驱动设计的思想和方法论。早年间DDD 还较为小众,没有在业界得到推广,但是伴随着微服务的崛起,人们意识到领域驱动设计的诸多思想对于设计微服务有莫大的帮助,一个特别典型的例子就是根据限界上下文(Bounded Context)来划定微服务边界。

    简单总结一下,在技术上微服务是实现业务中台的最佳技术方案,再借助领域驱动设计,中台的业务中心可以构建得足够灵活和强大。

    2.2 数据中台技术体系

    在数据中台上,目前的技术选型也是非常统一的,基于Hadoop、Spark 的大数据技术是当前构建数据中台的主流方案,本系列也是以大数据技术为基础来讨论如何建设数据中台的。

    大数据涉及的技术非常多,在数据采集、存储、消息队列、批处理、实时处理、作业调度等诸多环节上都有对应的技术和工具来完成相关工作,在后续的章节里我们会逐一讨论它们,但通常人们会用Hadoop、Spark 来指代大数据技术,因为两者不单单是技术,更代表着一个技术生态圈,在它们背后有一组相关的配套工具。

    对于建设数据中台的方法论(确切地说是数据中台的批处理部分),传统的数据仓库理论依然是主要的方法论。数据中台的使命是将企业的全域数据收集起来,然后规范地处理它们,最后给到前端应用。对于如何规范地处理数据,目前业界最为成熟的理论是数据仓库(数仓)。在经过数仓体系的治理之后,最终会在数仓的最上层得到高质量的数据集,然后通过Web Service、ODBC、JDBC 等多种数据服务对外发布出去。

    简单总结一下,在技术上Hadoop、Spark 是实现数据中台的主要技术方案,遵循数据仓库理论对数据进行组织和处理,在最上层封装为数据服务的形式去支持前台和业务中台对数据的需求。


    关于作者:耿立超,架构师,14年IT系统开发和架构经验,对大数据、企业级应用架构、SaaS、分布式存储和领域驱动设计有丰富的实践经验,热衷函数式编程。目前负责企业数据中台的架构设计和开发工作,对Hadoop/Spark 生态系统有深入和广泛的了解,参与过Hadoop商业发行版的开发,曾带领团队建设过数个完备的企业数据平台,个人技术博客:https://laurence.blog.csdn.net/ 作者著有《大数据平台架构与原型实现:数据中台建设实战》一书,该书已在京东和当当上线:

    京东购书链接:https://item.jd.com/12677623.html
    当当购书链接:http://product.dangdang.com/28974965.html

    扫描图中二维码了解详情↓↓

    在这里插入图片描述

    展开全文
  • 与战略重组几乎同步,阿里、腾讯、百度、京东、美团等一众互联网巨头正纷纷加入“中台战事”。“中台”热度陡增的背后,是管理团队对企业未来深层次的忧虑。中台是应对大公司病的一剂良药吗? 2018年年底到...
  • 数据中台最早是阿里提出的,但真正火起来是 2018 年,我们能感受到行业文章谈论数据中台的越来越多。大量的互联网、非互联网公司都开始建设数据中台。 为什么很多公司开始建设数据中台?尽管数据中台的文章很多,...
  • 企业大中策略剖析

    千次阅读 多人点赞 2018-10-24 12:02:45
    随着数字化和互联网时代的来临,云计算、大数据、...由于公司的发展要求,笔者经常接触大中这一理念,结合公司主打SOA集成平台、数据治理等产品和方案,在学习过程有自己一些的理解,本文主要与大家分享笔者的...
  • 中台概念着实火了一把,继去年购买了“数据中台”的百度搜索指数后,昨天我又购买了“业务中台”的百度指数,可能是由于刚刚购买,全量数据还没有统计汇总出来,所以当我们在百度指数,搜索业务中台的时候,目前...
  • 八问数据中台:关于数据中台你想知道的都在这里! 原创: 筱愚她爸 凯哥讲故事系列 1周前 数据中台最近特别火,各个企业都在关注如何构建自己的数据中台,利用数据中台打造数据驱动的经营能力。数据中台的概念漫天...
  • 数据台和业务中台的思考

    千次阅读 2019-07-13 18:52:46
    这波由互联网巨头们带起来中台热潮,看似偶然,其实必然。它让我们真正意识到数据形成资产化之后带来的巨大价值,以及企业与机构在未来的竞争构建起数据资产体系和组织架构调整的重要性。 当数据中台成为...
  • 前台、后台我知道,中台是什么呢? 今天一早起来,整个互联网圈都被腾讯的组织架构调整刷屏了,甚至有些人对腾讯新的6大事业群如数家珍,侃侃而谈,搞得比对自家公司的组织架构还清楚一样。 腾讯进行组织架构调整...
  • 数据中台最早是阿里提出的,但真正火起来是 2018 年,我们能感受到行业文章谈论数据中台的越来越多。大量的互联网、非互联网公司都开始建设数据中台。为什么很多公司开始建设数据中台?尽管数据中台的文章很多,但是...
  • SpringCloud和Kubernetes,是目前互联网企业构建微服务技术中台所采用的主流技术栈,波波也分析和比对这两个方案。Kubernetes平台封装了构建微服务技术中台所需的关键基础服务,它是波波推荐的,构建微服务...
  • 当然,不排除有些边界很难界定,比如基于数据中台出指标体系,统计访问业务的 PV、UV 这种关键指标,不同部门统计的口径不一样,定义中台之后,类似的有成千上万的指标需要重新进行边界划分,确定哪些指标体系由...
  • 阿里“小前台、大中”的解读

    千次阅读 2018-10-17 11:21:35
    审核去年底阿里巴巴集团CEO发出内部信,宣布组织结构全面升级,建设整合阿里产品技术和数据能力的强大中台,进而形成“小前台,大中”的组织和业务体制,使前线业务更加灵动、敏捷,迎接未来新商业环境带来的机遇...
  • 单讲这两个问题你可能疑惑——为什么出现这样的问题?   所以下面来讲讲两个实际的例子来细讲一下这两个问题: 第一部分——两个实际的场景例子引入 1.以航空公司的场景为例:   航空公司的市场部计划推出...
  • Photo @David Emrich文|焦先编者按:阿里巴巴业务中台系列文章第一篇--《阿里巴巴架构师:十问业务台和我的答案》自 2019 年 11 月 28 日发布至今日,仅...
  • 安装11Gr2单机asm后,完11.2.0.3.7的psu后,发现启动不起来数据库,alert日志内容如下:Errors in file /u01/app/oracle/diag/rdbms/bdspoc/bdspoc/trace/bdspoc_rbal_11187.trc: ORA-15183: ASMLIB ...
  • 1无线双机互连配置(无路由或无AP,只通过无线网卡) 首先在一机子的网上邻居,右键点击选择“属性” 1)选中要来设置的无线网卡的连接“网络连接”窗口,右击打算用来共享的无线网卡并且选择“属性”,弹出新的...
  • 嗷,五年了,我终于换了人生的第一MacBookPro

    万次阅读 多人点赞 2020-07-18 16:15:37
    本文已经收录于个人GitHub仓库:https://github.com/mmdapl/JavaScriptCollection ,请勿随便转载或商用 B站搜:Rong姐姐好可爱 开局闲扯 ​ 或许,看到这个标题的时候,你就知道我已经拥有一MacBook Pro了。是...
  • 一个微服务业务系统的中台构建之路 中台是近两年软件开发领域的热点话题,相关的文章也成为了各个技术社区和媒体争相报道的网红内容。作为企业支撑业务开发的核心系统,中台的重要性不言而喻,很多企业也开始尝试...
  • 给大家介绍 2 本还不错的书,相信热爱学习的你一定感兴趣的 ~
  • 最近在得到APP听了吴伯凡老师的《每周商业评论》 1 《字节跳动为什么能持续出爆品》这两讲课程,我感觉对字节跳动这家公司多了一些了解,所以希望写一篇笔记来总结听课的内容。
  • 导读:《终于有人把数据中台讲明白了》一文讲到数据中台的定义和价值,本文将介绍数据中台到底包括什么内容。企业建设数据中台的过程哪些能力是必选项,哪些是可选的,将在本文一一揭晓。作者:陈新...
  • 业务开发和中台开发到底是否执行架构委员制定的流程和规范,需要有一定的工具链的配合,因而就需要技术底座组,包括云,大数据,容器,微服务,已经相应的流程管理,规范管理,绩效看板等,可以让架构委员通过...
  • 已经是2013年6月的一篇文章了,作者在文中对证券公司前后台的各个部门的业务与职能,未来发展前景等方面进行了分析,笔者读完觉得其中大部分内容放到现在还依然适用。 文中对各大部门的分析都是从作者多年经历...
  • 在成千上万的计算机,为什么一计算机能够准确着寻找到另外一计算机,并且把数据发送给它呢? 可能很多人都听说过网络通信的 5 层模型,但是可能并不是很清楚为什么需要五层模型,五层模型负责的任务也有可能...
  • 项目前端jsp页面有复选框,需要使用到ajax把这些值传递到java后台的操作。因为还需要返回数据到前端页面,所以无法使用form表单提交。 (对了,我在一群里问了这个问题,然后两个热心群友应持有不同的意见...
  • 会上,每日互动(个推)董事长方毅和CTO叶新江重磅发布了新一代数据中台产品——“数盘”。方毅表示,数盘的发布,其意义不止于中台。数盘更关注数据在行业场景的应用落地,将致力于对数据价值进行最大化挖掘,...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 280,108
精华内容 112,043
关键字:

中台会打起来吗