精华内容
下载资源
问答
  • 多个中台技术
    千次阅读
    2019-09-09 22:06:54

    定义

    在有些人眼里:中台就是技术平台,像微服务开发框架、Devops平台、PaaS平台,容器云之类的,人们都叫它“技术中台”。
    在有些人眼里:中台就是微服务业务平台,像最常见的什么用户中心,订单中心,各种微服务集散地,人们都叫它“业务中台”。
    在有些人眼里:中台应该是组织的事情,在释放潜能:类似于企业内部资源调度中心和内部创新孵化组织,人们叫它“组织中台”。

    中台更多是因为公司业务在发展到某一阶段时,遇到瓶颈与障碍后,为解决实际问题而提出的解决方案。

    1. 为什么需要中台?

    中台的产生,并非完全是自顶向下的战略设计,也非是为了追求某种行业风口,而是随着公司业务的高速发展、组织不断膨胀的过程中暴露的种种问题需要被解决。而这时,中台的概念恰好对应了这个问题,所以大家接受了中台。

    1. 例:
      公司刚开始只有淘宝,后来意识到B2C模式的业务也会是电商领域重要的组成部门,所以出现了天猫,随着天猫的不断发展,逐渐独立成一个部门,但是这两套都包含订单、商品、库存、价格、仓储、物流等基本业务系统。这两个系统互相独立,各自运行。

    等到10年左右,阿里开始上线1688、聚划算等业务的时候发现,这些业务针对的领域虽然各不相同,但是他需要用到的系统功能也高度类似,主要也是订单、商品、库存、价格、仓储、物流等系统。如果这些新业务的系统也都要全部重新开发一遍,这无疑是很大的资源浪费。明明既有的系统调整一下就可以满足新业务的需求,为什么还要继续开发新系统呐?

    在这个大的背景之下,阿里内部将共享服务部的职权不断提升,统一将各个业务业务部门重复使用,反复建设的功能和系统统一规划和管理。
    阿里供应链中台/图源网络

    例2: 滴滴在15年末开始启动自己的中台战略,这与滴滴当时的业务发展阶段也是相关的。

    2015 年末,滴滴在短时间内形成了包括快车、出租车、专车、顺风车、代驾等多业务的垂直化架构。

    这些业务虽然会有一些差别,但是核心系统和流程都是类似的。如果各自独立开发,也会出现各种各样的问题。

    比如说,开发成本过高,滴滴旗下的每个业务,其实都是可以单独支撑起一家公司的,如果每个业务都独立做到极致,那么开发成本和人力成本就会非常巨大,而如果为了控制成本,就把系统的建设放缓,则意味着,无论是核心系统本身的质量,还是对外的用户体验都不太好。

    在这样的背景下,滴滴也开始考虑将诸多业务,以及各个城市的系统统一规划,统一建设,提升服务前台的能力。

    其实,刚刚我们提到的,以及许多正在实践中台业务的公司,都有类似的问题,这些问题,大约会是两类——

    一类是,许多业务需求或功能需求高度类似、通用化程度很高,但是由于没有专门的团队负责规划和开发,大量的系统重复开发、重复建设,导致复用性低、效率低、产研资源浪费、用户体验不统一。

    另一类是,早期业务发展过程中,为了解决一些当下的业务问题,垂直的、个性化的业务逻辑与基础系统耦合太深,由于没有平台性质的规划,横向系统之间、上下游系统之间的交叉逻辑也非常多,这样导致在新业务、新市场的拓展过程中,系统没法直接复用,甚至没法快速迭代。

    这两类问题,在软件开发领域,有专门的名称,叫做“重复造轮子”和“烟囱式架构”。这两类问题本质上是企业在发展过程当中,为了解决当下的业务问题,快速上线了很多功能,而欠下了许多技术债,当企业进入成熟期之后,发现这些问题的存在,严重影响了企业的运行效率和运营成本。
    如何能够机制化,产品化地解决这些问题,能够更好地通过产品的形式,将企业内部具有很强的通用性的数据、功能、产品甚至经验进行统一规划和开发,进而更好地帮助前台业务部门更多地关注业务,提高业务运营效率,进而提升企业竞争力,是企业开发中台的基本出发点。

    现阶段,大多数提出中台战略或是建设大中台的公司,大多都有类似的困境。业务高速发展多年,许多问题积重难返或者大量在解决“重复造轮子”的问题,中台这个概念,很多情况下是因为契合了大公司业务的发展的情况,而被大家广泛认可。

    2. 中台能解决什么问题?

    很多公司的中台业务,实际业务发展到一定阶段,进入一个瓶颈之后,为了能够应对接下来的问题,才一点一点从内部开始推动解决之前的问题。
    但这其实只是中台建设的一个层面。

    中台作为一种产品设计思路,或者系统架构思路,并不受限于公司的规模,理论上讲,任何一家即将或者正在面临业务高速增长的状态时,都很值得利用和借鉴中台的思路,将目前业务当中大量可复用的功能和场景进行梳理,为业务的高速增长做好准备。

    这在中小公司当中,是有现实意义的。

    对于很多中小公司,当他们走出生存困境,进入到高速发展阶段时,会遇到很多的问题,但大概率会遇到的一个问题是,过往的业务模型,产品能力很有可能没法完全承接住大规模用户增长带来的压力。

    而当你具体到每个用户的时候,你又能发现,他们遇到的问题你之前都遇到过,只不过,因为一下来的太多,你没法像过去一样提供达预期,甚至超预期的服务时,对方就会产生不满。

    这也是为什么许多公司会生于拉新,死于留存的一个原因。

    很多公司在这个阶段的选择都是为了临时解决一个问题,快速上线一个功能,也不是不可以,只不过,很有可能你的解决方案会不断带来新的问题,最后陷入到功能太过复杂,以至于积重难返的地步。

    所以,在有可能的情况下,公司将一些大概率长期有价值的功能,专门模块化,进行开发和优化,确保即使业务规模进一步扩大,也能够满足业务需求。甚至,随着能力或方法论的不断优化,甚至有可能某一天成为整个行业的方法论。

    这个过程,就很像是在高速飞行过程中修飞机一样。一方面,机翼已经千疮百孔,摇摇欲坠,另一方面,发动机还在运转,你还能往前飞,但你知道,如果再进入到下一场战斗,你不见得还能确保飞机不会坠落,所以,必须抢在下一次战斗前把飞机修好。

    随着业务的发展,你对飞机的要求,也不仅仅是修好,可能会希望,能够提前预防一些问题。或者,知道你的飞机哪里战斗力最强,就把哪里做到最好。或许,就能够回避之后的一些问题。

    这或许是中台这个概念,对于中小公司内部产品规划的一个启发。

    当然,需要提示的一点是,对于中小公司而言,中台的理念不见得是单独拉几十人搭建一个中台产研团队,可以将一些关键流程先行标准化,把一些反复出现的场景当中的解决方案进行沉淀,部分需要产品化的功能先行产品化,可能对于一家业务刚刚开始起步的公司来说,就已经很重要了。

    3.中台产品经理的挑战

    一方面,是思维的差异。

    很多产品经理并不是从一开始就从事中台相关的事宜,也不是一开始就有中台这样的定位。更多情况下,他们是从前台业务部门,或者以业务为导向的产研部门转型到中台产研部门。

    这时,其实要面临很大的思维方式、做事方法的转变。

    在业务部门或者以业务为导向的产研部门,最核心的目的就是达成业务目标,要求你速度足够快、功能高效地解决当下的业务问题,当前业务发展的效率是最关键的。

    至于说,这个功能将来有没有可能适用于别的场景,有没有可能解决别的问题,这个问题实在是没那么重要。

    但是,对于中台不能如此。
    对于中台产品经理来说,必须思考的问题是,这个功能在现在或者将来能满足多少业务场景?如果将来有新的业务出现,是不是能够复用?或者说,需要做多大的调整才可以复用?甚至于,这个功能有没有可能对外输出,提供SaaS化的服务。

    另一方面,是环境的变化。

    当你在业务部门的时候,响应业务是相对轻松的。但是,在中台部门,响应多个业务,就没有那么轻松了。

    就拿需求调研为例。在业务部门或以业务为导向的产研部门的时候,你只要和对接的业务人员沟通清楚需求就OK了,毕竟,你只要了解这一个或对应的多个部门的业务需求即可,业务目标相对比较明确。

    但是,当你需要响应多个业务部门的时候,就没有那么容易了。

    你会发现,同样一个需求,A部门的流程和B部门流程完全不同,或者,流程是相似的,但到具体细节的时候,却有很大差异。

    更可怕的是,同样一个问题,由于业务的发展阶段不同,对于问题的态度也全然不同:有的部门业务已经非常成熟,自己流程也很清晰,所以不太希望你来调整他们现有的流程;但是,有的部门还处于探索期,还没有遇到你提出的问题,可能压根就不理你。这时,对于中台产品经理的挑战就非常大。
    他们可能会将大量的精力耗散于不同部门之间的沟通协调,反复对同一个需求进行确认,很长时间没有明显突破。这个时候,就要求中台产品经理有很强的沟通、协调和协作能力。
    并且,因为他们接下来要做的解决方案,是要服务于多个业务。这个时候,需要中台产品经理有很强的逻辑思考能力,看到不同需求之间的共性需求,并提炼出一个产品化的解决方案。
    甚至于,对于一些尚未遇到这个问题的业务部门,可能还要帮他们前置地思考解决方案。

    这又很要求产品经理的逻辑思考和抽象思考能力。

    既需要沟通协作的软技能,又需要逻辑抽象的硬思考,这可能才是中台产品经理最有挑战的地方。

    虽然有挑战,但是也不见得没有方法。对于中台产品经理来说,刚刚我们提到的内容,也只是帮助中台产品经理,对于中台产品这个岗位所要面临的挑战和工作,能够有一些初步框架性的理解。
    对于中台产品而言,他们的能力要求其实跨越非常大。一方面,需要极强的逻辑思维和战略分析能力,能够看到业务当中的关键流程,理解业务接下来的发展方向,并将其转化为产品功能,与研发一起实现。另一方面,又需要极强的沟通和交流能力,能够在与多个业务线,需求、背景、想法各不相同的相关方一起,推动完成相关功能的实现。

    更多相关内容
  • 技术中台的作用是什么? 技术前台 技术中台 在什么情况下,才有必要做技术中台? | 前提1:技术组织结构垂直化 | 前提2:业务线又又复杂 有了技术中台,是不是就能上天? 总结 就在刚过去的半年里,「...

    目录

    技术中台的作用是什么?

    技术前台

    技术中台

    在什么情况下,才有必要做技术中台?

    | 前提1:技术组织结构垂直化

    | 前提2:业务线又多又复杂

    有了技术中台,是不是就能上天?

    总结


     

    就在刚过去的半年里,「中台」成了技术圈内讨论的热门词汇,就连一些名不见经传的小公司,也都纷纷喊出了「要向中台转型!」的口号,甚至有人说「不做中台,那就等着死吧!」

    如果我没有记错,「中台」思想源自于2015年,马云参观一个著名的游戏公司Supercell之后提出了,简言之就是“小前台、大中台”,随即阿里就成立中台事业群,并取得了很好的成效。

    随后,美团点评也开始走中台策略,腾讯在去年的组织架构调整中,也提出建设具有 “腾讯特色的技术中台”。

    技术中台的作用是什么?

    要搞明白这点,你需要先搞清楚「技术前台」、「技术中台」与 「技术后台」 之间的关系,以及他们各自扮演的角色与作用。

    先来说说我们的「技术前台」。

    技术前台

    「技术前台」,说白了就是为业务部门开发功能的技术团队。

    如果是ToC的业务,交付物必须贴近终端用户,如果是ToB的业务,交付物需要满足商家的需求。

    脑海中必须时刻牢记 “小步快跑,快速试错” 的理念,业务说啥,就是啥,业务要怎么做,你就怎么做。

    另外,研发资源的投入基本和业务对等,业务需求多,人数增加,业务需求少,人数相应减少,而且团队组织也基本按功能线来划分。

    运用的技术栈也相对单一,以Java语言为例,通常 “1个NG + 1个War/N个Jar + 1个数据库” 就搞定了,而其余的技术服务都将由「技术中台」提供。

    「技术前台」的核心价值体现在对业务逻辑的理解与实现上,是技术向业务传递价值的阶梯。

    我觉得在这点上,与线下销售团队的前台营销有一些类似。

    技术中台

    再来说说我们的「技术中台」。

    「技术中台」,说白了就是强调资源整合、能力沉淀的平台体系,当「技术前台」实现业务功能时,为他们提供底层的技术、数据等资源和能力的支持。

    这怎么理解?

    从这张图中可以看到,「技术中台」有点像编程时的适配层,起到承上启下的作用,将整个公司的技术能力与业务能力分离,并以产品化方式向前台提供技术赋能,形成强力支撑。

    在什么情况下,才有必要做技术中台?

    俗话说 “知己知彼,百战不殆”,在我看来,面对技术问题时,“知己” 比 “知彼” 更为重要。

    在实施「技术中台」之前,我们是否要静下心来对自己进行 “灵魂拷问”?比如说,当前的时机是否已经成熟?或者怎么才叫成熟?

    在我看来,要想做「技术中台」,客观环境需先满足两个前提:技术组织结构垂直化业务线又多又复杂

    否则,「技术中台」的结果只会是两种:一场闹剧 或者 一笔赔钱的买卖。

    | 前提1:技术组织结构垂直化

    曾经有朋友说过,每家公司的组织结构演进都是一部心酸血泪史。我很费解,问为什么?

    他说,因为这中间掺杂着太多的主观判断与情感纠葛。

    比如,某员工认为公司管理混乱,组织架构来回调整,今天拆这个团队,明天合那个团队,纯属病急乱投医,高管都是些横行霸道,滥用资源的傻逼货,借机搞人,这公司,没救了。

    但高管们大呼冤枉,觉得组织架构调整的目的是为了提高产出和人效,如果你干得不爽可以离开,这种事情,本来就不可能让每个人都满意,既得利益者肯定大加赞赏,而失去利益者肯定狂喷不止,不用理会。

    的确,这种 “自我革命式” 的调整,基本不可能一步到位,需要一个过程慢慢演化,而在这个过程里,自然会遭遇很多的阻力或质疑。

    瞧瞧这结构,经典的职能分工模式,有什么问题吗?

    我不但说不出问题,甚至能找出一万个理由说明这种模式的好处。开发按业务线分开,测试与运维形成上下层关系,谁也不想管对方,两边的老大也是评级的,相安无事

    那什么情况下才会觉得这种模式有问题呢?

    客观的说,职能分工模式更适合瀑布式开发模式。先谈需求,再谈工期,随后按部就班地往下做

    但当用户的需求开始变的多种多样,业务方时不时的就要上一个新功能,做一个新系统的时候,你会发现开发出来的系统很难变更,至少很难快速变更。

    于是,你把开发按系统功能进行重组,每个团队都围绕 “交付速度” 开展工作,但这样又遇到了两个新的问题:

    • 多种多样的中间件,每个团队独立选型中间件,没有统一的维护,没有统一的知识积累,无法统一保障SLA。

    • 开发与测试、运维之间目标不一致(比如测试A君,开发要求你只做功能测试,快上线,但测试老大却要求你做非功能测试,保障质量,避免背锅……到底听谁的?),陷入永无休止的扯皮与争吵。

    面对这两个新的问题,我们做出了调整:

    • 成立平台架构组,负责中间件、自动化测试/运维、数据库等技术工具或服务的开发、维护。

    • 把质量管理部中的测试团队,与系统运维部中的应用运维团队,按照系统功能拆分至各开发团队,由原开发经理负责,形成各自独立的Feature Team。

    到这个时候,虽然整个组织结构还未完全实现垂直化分工,但已基本能够达到 “快速试错,小步快跑” 的目标。

    另外,这更像平台化的另一种雏形,就是逐渐把一些公共、底层的技术能力抽象出来,与业务逻辑分离,并形成各种接入式基础服务,同时可以为多个业务线提供服务。

    也就是说,打造「技术中台」的前提是平台化,而平台化的先决条件是「组织结构垂直化,技术工具公共化」

    如果没有这样的前提,就失去了打造「技术中台」的立身之基。

    | 前提2:业务线又多又复杂

    曾经有朋友问我,技术的核心价值是什么?我的答案是 “改变世界”。

    他说,别扯淡,好好说话。

    他说,对业务驱动型的公司来说,技术的核心价值是 “降低成本,提升效率”,而单从架构设计的角度来看,想达成这项目标的两个手段是「通用性」与「复用性」

    现在想想,这句话可以完美的衔接到「技术中台」上去。

    回顾几年前,我们的业务逻辑也曾非常单一,要么用你的银行卡买卖基金,要么用你的电子钱包买卖基金,方便,快捷。

    渐渐地,随着业务创新业务增多,需要前后台系统定制开发,逻辑兼容难度增加。

    在这样的局势下,为满足企业规模扩大和多样化经营对组织机构的要求,公司开始转向事业部制,按产品、地区或市场(顾客) 划分经营单位。

    为了应对业务方的这次调整,我们开始将业务开发中的一些共享服务分离出来,成立了业务中台组(由于本文以技术中台为主,业务中台的内容将不进行展开说明)

    将可以复用的服务和代码,交由这几个组开发出服务来,给业务组使用,这样数据模型会统一,业务开发的时候,首先先看看有哪些现成的服务可以使用,不用全部从零开发,也会提高开发效率。

    与「业务中台」相呼应,「技术中台」就像一个工具大仓库,里面放满了各式各样的技术工具,无论是哪个团队,哪个人,快速找到自己的工具,拿来就用就行了。

    而维护工具的这群人,不用贴近业务开发,每天的任务就是研究如何使用这些工具,如何调优,遇到问题如何Debug,形成知识积累。

    有了这么一群专职的人,就可以根据自身的情况,选择有限几个技术栈集中研究,限定业务组只使用这些工具,可保证选型的一致性。

    如果你只有一条业务线,那就别搞「技术中台」了,把人凑在一堆,又省钱,又省力。

    有了技术中台,是不是就能上天?

    理论上讲,当业务线变多且越来越复杂,前台与后台之间的“技术债”会随之变多,重复造轮子与沟通成本太高的现象会增多,通过技术中台可以一定程度上来解决这个问题。

    这种理论看似完美,但在实际执行上却困难重重。

    设想下,如果「技术中台」做得太多,资源投入就会很大,无法形成正向的利益传导;

    如果「技术中台」做得太少,又无法深入理解业务,导致适配方案落地性变差,渐渐失去价值。

    这句话怎么理解?

    十年前,我在某金融软件公司工作,随着客户数的增多,成本与效率/质量的矛盾日益凸显。

    设想下,从一波人维护一套代码,渐渐变成一波人维护几套代码,这样一来,Bug增多,效率下降,抱怨也随之变多,再加上甲方挖人,最后人员离职,团队土崩瓦解,Game Over……

    在这种情况下,一般公司会采取三种应对措施:

    1. 一对一服务 - 项目制:多个团队,多套代码,多套标准,服务多家客户,但这样一来成本又难以承受,时间一长,肯定资不抵债。

    2. 一对多服务 - 标准化:一个团队,一套代码,一套标准,服务多家客户,但客户不买账,客户说我的需求都是个性化的,你别来某某标准来引导我,叫你咋做,你就咋做,不愿意?那您走,我找别人家做。

    3. 一对多服务 - 产品化:一个团队,一套代码,多套标准,服务多家客户,通过技术与配置化的手段,利用SOA思想,打造自己的产品化平台,但对技术投入要求较高,尤其是核心人才的依赖较大,中小型企业一般都很难留住这些人,只要他们一走,公司基本完蛋。

    回想下,当年那些叱诧风云的软件公司,又有几家活下来了?以金融业为例,恒生算是在第二条路上走的比较成功的,而我们当年却死在了第三条路上。

    在我看来,我们的「技术中台」就是一家 “乙方服务公司”,而我们的「技术前台」更像是一家 “甲方电商公司”。

    不可否认,有了这家 “乙方服务公司” 之后,在面对大型项目及快速多变的业务时,技术的投入与主动权更强了,但由于理念、职责、节奏与使命不同,外加 “屁股决定脑袋” 的立场,前台与中台之间很容易引发矛盾。

    从职责角度来说,前台是 “快速应对业务变化”,中台是 “稳定高效提供服务”。

    一个追求效率,一个追求质量,这矛盾是天然存在的。

    怎么理解?我来举个小例子说明下。

    前台部门的A团队和B团队,由于业务需要同时向「技术中台」提出要接入缓存服务的需求

    「技术中台」的中间件产品线中有一套基于Proxy的自研分布式缓存系统,已在其他业务线运行多年,但由于A团队与B团队的技术债都各不相同,必须通过增加适配器才能完成接入

    而此时人手又不够,按重要程度排序,只能先接A团队,但B团队也有需求,又等不及,怎么办呢?就先给他来个Redis接着玩玩吧,等A团队接好了再来接你的。

    一个月后,等A团队接完了,找到B团队,这时痛点已不存在,团队的激情自然不高,毕竟没有收益,就不了了之了。

    几个月后,安全团队提出要对Redis集群进行改密,由于A团队接入的是「技术中台」的缓存中间件产品,采用代理模式,并通过控制台操作,既方便,又快捷,找个晚上,5分钟内,全部搞定。

    但B团队用的是直连Redis的模式,密码嵌入在SDK中,不仅在改密过程中需要前台与中台联动,而且还需要在改密后重启应用服务,这样一来,只有配合应用发布的周期才能干这件事。

    最终,原本五分钟可以搞定的事,整整搞了三周才搞定,「技术中台」的运维同学更是陪熬了多次通宵,还因为人为疏忽引发了一次事故。

    就在这件事过去的一年时间里,由于B团队系统的业务规模逐渐增大,Redis数量也逐渐增多,「技术中台」的运维成本与风险也随之上涨。

    这期间,中台曾多次与前台交涉,希望能够通过适配的方式将A团队接入缓存中间件,但始终未能达成。

    在「技术中台」看来,“你们只顾自己,不管别人,功劳你们拿,黑锅我们背?”

    在「技术前台」看来,“你TM懂个屁!我们都快被业务逼疯了,你们不就多费点人工吗?多加点班会死吗?总扯一些理念干嘛?对你没收益的事,你干嘛?”

    因为这样的分工模式,导致这种矛盾在工作中很多,而且似乎并没有更好的方法彻底解决。

    有人说,要解决很简单,要么强压,要么加大投入,下下狠心就得了。

    先来说说强压,似乎能够在短时间内达到目的,但纯属 “杀敌一千自损八百” 的招数,难道要业务研发团队停下手上的活,倾巢而出一起搞技术改造吗?更何况,前台承受的压力,是中后台团队无法想象的。

    退一步说,抛开 “互相理解” 这个话题,强压的套路等同于 “攻城为上,攻心为下”,对今后的管理与团队氛围都会带来诸多的麻烦。

    再来说说加大投入,看看我上面提到的 “死在路上的软件公司们”,还想加大中后台的投入吗?

    如果你不是大厂,还是算了吧。

    那句话怎么说来着?最悲惨的结局是,你的技术中后台越发强大,但你的业务规模却在逐渐萎缩。

    可悲,可叹。

    总结

    在互联网时代,技术圈似乎从来不缺少热议话题,但有质量,有深度,且能解决实际问题的却少之又少。

    现在人人都在讨论「中台」,今天「产品中台」,明天「数据中台」,这个说能提高效率,那个说能排除万难,聊得不亦乐乎。

    对于企业来说,话题热不热并不重点,方案牛不牛逼也不重要,关键是能帮助用户找到效率、质量与成本的平衡点,或许才算是一个合格的「技术中台」。

    展开全文
  • 业务中、数据中技术中台到底是什么?

    千次阅读 多人点赞 2021-03-16 13:48:38
    业务中、数据中技术中台到底是什么?00 中能力总体框架01 业务中02 数据中数据应用技术发展迅猛数据架构更加灵活数据来源更加多元化,数据格式更加多样化数据智能化应用将会越来越广泛03 技术中台1. API...

    作者:大数据DT
    来源:大数据DT

    导读:2015年 阿里巴巴提出“大中台,小前台”的中台战略,通过实施中台战略找到能够快速应对外界变化,整合阿里各种基础能力,高效支撑业务创新的机制。

    阿里巴巴中台战略最早从业务中台数据中台建设开始,采用了双中台的建设模式,

    到后来发展出了移动中台技术中台研发中台等,这些中台的能力综合在一起就构成了阿里巴巴企业级数字化能力。

    传统企业在技术能力、组织架构和商业模式等方面与阿里巴巴存在非常大的差异,在实施中台战略时是否可以照搬阿里巴巴中台建设模式?传统企业中台数字化转型需要提升哪些方面的基本能力呢?

    00 中台能力总体框架

    中台建设过程从根本上讲是企业自身综合能力持续优化和提升的过程,最终目标是实现企业级业务能力复用和不同业务板块能力的联通和融合。

    企业级的综合能力,一般包含以下四种:业务能力数据能力技术能力组织能力,如图2-1所示。
    在这里插入图片描述
    ▲图2-1 企业中台数字化转型基本能力框架


    • 业务能力:主要体现为对中台领域模型的构建能力,对领域模型的持续演进能力,企业级业务能力的复用、融合和产品化运营能力,以及快速响应市场的商业模式创新能力。

    • 数据能力:主要体现为企业级的数据融合能力、数据服务能力以及对商业模式创新和企业数字化运营的支撑能力。

    • 技术能力:主要体现为对设备、网络等基础资源的自动化运维和管理能力,对微服务等分布式技术架构体系化的设计、开发和架构演进能力。

    • 组织能力:主要体现为一体化的研发运营能力和敏捷的中台产品化运营能力,还体现为快速建设自适应的组织架构和中台建设方法体系等方面的能力。

    这些能力相辅相成,融合在一起为企业中台数字化转型发挥最大效能。接下来,我们一起来看看在不同的领域应该如何实现这些能力。

    01 业务中台

    企业所有能力建设都是服务于前台一线业务的。从这个角度来讲,所有中台应该都可以称为业务中台。但我们所说的业务中台一般是指支持企业线上核心业务的中台

    业务中台承载了企业核心关键业务,是企业的核心业务能力,也是企业数字化转型的重点。

    业务中台的建设目标是:“将可复用的业务能力沉淀到业务中台,实现企业级业务能力复用和各业务板块之间的联通和协同,确保关键业务链路的稳定高效,提升业务创新效能。

    业务中台的主要目标是实现企业级业务能力的复用,所以业务中台建设需优先解决业务能力重复建设和复用的问题。通过重构业务模型,将分散在不同渠道和业务场景(例如:互联网应用和传统核心应用)重复建设的业务能力,沉淀到企业级中台业务模型,面向企业所有业务场景和领域,实现能力复用和流程融合。

    图2-2是一个业务中台示例。在业务中台设计时,我们可以将用户管理、订单管理、商品管理和支付等这些通用的能力,通过业务领域边界划分和领域建模,沉淀到用户中心、订单中心、商品中心和支付中心等业务中台,然后基于分布式微服务技术体系完成微服务建设,形成企业级解决方案,面向前台应用提供可复用的业务能力。
    在这里插入图片描述
    ▲图2-2 业务中台示例


    在技术实现上,中台的系统落地可以采用微服务架构。微服务是目前公认的业务中台技术最佳实现,可以有效提升业务扩展能力,实现业务能力复用。

    在业务建模上,中台领域建模可以采用领域驱动设计(DDD)方法,通过划分业务限界上下文边界,构建中台领域模型,根据领域模型完成微服务拆分和设计。

    业务中台可以面向前台应用提供基于API接口级的业务服务能力,也可以将领域模型所在的微服务和微前端组合为业务单元,以组件的形式面向前台应用,提供基于微前端的页面级服务能力。

    业务中台建设完成后,前台应用就可以联通和组装各个不同中台业务板块,既提供企业级一体化业务能力支撑,又可以提供灵活的场景化销售能力支撑。

    02 数据中台

    数据中台与业务中台相辅相成,共同支持前台一线业务。

    数据中台除了拥有传统数据平台的统计分析和决策支持功能外,会更多聚焦于为前台一线交易类业务提供智能化的数据服务,支持企业流程智能化、运营智能化、商业模式创新,实现“业务数据化和数据业务化”。

    最近几年,数据应用领域出现了很多新的趋势。数据中台建设模式也随着这些趋势在发生变化,主要体现在以下几点。

    数据应用技术发展迅猛

    第一,数据应用技术发展迅猛。近几年涌现出了大量新的数据应用技术,如NoSQL、NewSQL和分布式数据库等,以及与数据采集、数据存储、数据建模和数据挖掘等大数据相关的技术。这些技术解决业务问题的能力越来越强,但同时也增加了技术实现的复杂度。

    数据架构更加灵活

    第二,数据架构更加灵活。在从单体向微服务架构转型后,企业业务和数据形态也发生了很大的变化,数据架构已经从集中式架构向分布式架构转变。

    数据来源更加多元化,数据格式更加多样化

    第三,数据来源更加多元化,数据格式更加多样化。随着车联网、物联网、LBS和社交媒体等数据的引入,数据来源已从单一的业务数据向复杂的多源数据转变,数据格式也已经从以结构化为主向结构化与非结构化多种模式混合的方向转变。

    数据智能化应用将会越来越广泛

    第四,数据智能化应用将会越来越广泛。在数字新基建的大背景下,未来企业将汇集多种模式下的数据,借助深度学习和人工智能等智能技术,优化业务流程,实现业务流程的智能化,通过用户行为分析提升用户体验,实现精准营销、反欺诈和风险管控,实现数字化和智能化的产品运营以及AIOps等,提升企业数字智能化水平。



    面对复杂的数据领域,如何建设数据中台管理并利用好这些数据?

    这对企业来说是一个非常重要的课题。

    数据中台的大部分数据来源于业务中台,经过数据建模和数据分析等操作后,将加工后的数据,返回业务中台为前台应用提供数据服务,或直接以数据类应用的方式面向前台应用提供API数据服务。

    数据中台一般包括数据采集、数据集成、数据治理、数据应用和数据资产管理,另外还有诸如数据标准和指标建设,以及数据仓库或大数据等技术应用。

    图2-3是2017年阿里云栖大会上的一个数据中台示例。
    在这里插入图片描述
    ▲图2-3 数据中台示例(图参考:2017年阿里云栖大会)


    综上所述,数据中台建设需要做好以下三方面的工作。

    • 一是建立统一的企业级数据标准指标体系,解决数据来源多元化和标准不统一的问题
      企业在统一的数据标准下,规范有序地完成数据采集、数据建模、数据分析、数据集成、数据应用和数据资产管理。

    • 二是建立与企业能力相适应的数据研发、分析、应用和资产管理技术体系
      结合企业自身技术能力和数据应用场景,选择合适的技术体系构建数据中台。

    • 三是构建支持前台一线业务的数据中台
      业务中台微服务化后,虽然提升了应用的高可用能力,但是随着数据和应用的拆分,会形成更多的数据孤岛,会增加应用和数据集成的难度。在业务中台建设的同时,需要同步启动数据中台建设,整合业务中台数据,消除不同业务板块核心业务链条之间的数据孤岛,对外提供统一的一致的数据服务。用“业务+数据”双中台模式,支持业务、数据和流程的融合。

    数据中台投入相对较大,收益周期较长,但会给企业带来巨大的潜在商业价值,也是企业未来数字化运营的重要基础。企业可以根据业务发展需求,制定好阶段性目标,分步骤、有计划地整合好现有数据平台,演进式推进数据中台建设。

    03 技术中台

    业务中台落地时需要有很多的技术组件支撑,这些不同技术领域的技术组件就组成了技术中台。

    业务中台大多采用微服务架构,以保障系统高可用性,有效应对高频海量业务访问场景,所以技术中台会有比较多的微服务相关的技术组件

    一般来说,技术中台会有以下几类关键技术领域的组件,如API网关、前端开发框架、微服务开发框架、微服务治理组件、分布式数据库以及分布式架构下诸如复制、同步等数据处理相关的关键技术组件,如图2-4所示。

    1. API网关

    微服务架构一般采用前后端分离设计,前端页面逻辑和后端微服务业务逻辑独立开发、独立部署,通过网关实现前后端集成。

    前台应用接入中台微服务的技术组件一般是API网关。

    API网关主要包括:鉴权、降级限流、流量分析、负载均衡、服务路由和访问日志等功能

    API网关可以帮助用户,方便地管理微服务API接口,实现安全的前后端分离,实现高效的系统集成和精细的服务监控。

    2. 开发框架

    开发框架主要包括前端开发框架和后端微服务开发框架。基于前、后端开发框架,分别完成前端页面逻辑和后端业务逻辑的开发。

    前端开发框架主要是面向PC端或者移动端应用,用于构建系统表示层,规范前后端交互,降低前端开发成本。
    在这里插入图片描述
    ▲图2-4 技术中台关键技术领域


    微服务开发框架用于构建企业级微服务应用。

    一般具备自动化配置、快速开发、方便调试及部署等特性,提供微服务注册、发现、通信、容错和监控等服务治理基础类库,帮助开发人员快速构建产品级的微服务应用。

    开发框架一般都支持代码自动生成、本地调试和依赖管理等功能

    3. 微服务治理

    微服务治理是在微服务的运行过程中,针对微服务的运行状况采取的动态治理策略,如服务注册、发现、限流、熔断和降级等,以保障微服务能够持续稳定运行

    微服务治理主要应用于微服务运行中的状态监控、微服务运行异常时的治理策略配置等场景,保障微服务在常见异常场景下的自恢复能力。

    微服务治理技术组件一般包括服务注册、服务发现、服务通信、配置中心、服务熔断、容错和微服务监控等组件。

    常见的微服务治理有Dubbo、Spring Cloud和Service Mesh等技术体系

    4. 分布式数据库

    分布式数据库一般都具有较强的数据线性扩展能力,它们大多采用数据多副本机制实现数据库高可用,具有可扩展和低成本等技术优势。

    分布式数据库一般包括三类:交易型分布式数据库分析型分布式数据库交易分析混合型分布式数据库

    • 交易型分布式数据库:用于解决交易型业务的数据库计算能力,它支持数据分库、分片、数据多副本,具有高可用的特性,提供统一的运维界面,具备高性能的交易型业务数据处理能力。主要应用于具有跨区域部署和高可用需求,需支持高并发和高频访问的核心交易类业务场景。

    • 分析型分布式数据库:通过横向扩展能力和并行计算能力,提升数据整体计算能力和吞吐量,支持海量数据的分析。主要应用于大规模结构化数据的统计分析、高性能交互式分析等场景,如数据仓库、数据集市等。

    • 交易分析混合型分布式数据库:通过资源隔离、分时和数据多副本等技术手段,基于不同的数据存储、访问性能和量等需求,使用不同的存储介质和分布式计算引擎,同时满足业务交易和分析需求。主要应用于数据规模大和访问并发量大,需要解决交易型数据同步到分析型数据库时成本高的问题,需要解决数据库入口统一的问题,需要支持高可用和高扩展性等数据处理业务场景。

    5. 数据处理组件

    为了提高应用性能和业务承载能力,降低微服务的耦合度,实现分布式架构下的分布式事务等要求,技术中台还有很多数据处理相关的基础技术组件

    如:分布式缓存、搜索引擎、数据复制、消息中间件和分布式事务等技术组件。

    • 分布式缓存是将高频热点数据集分布于多个内存集群节点,以复制、分发、分区和失效相结合的方式进行维护,解决高并发热点数据访问性能问题,降低后台数据库访问压力,提升系统吞吐能力。
      典型的开源分布式缓存技术组件有Redis。

    • 搜索引擎主要解决大数据量的快速搜索和分析等需求。

      将业务、日志类等不同类型的数据,加载到搜索引擎,提供可扩展和近实时的搜索能力。

    • 数据复制主要解决数据同步需求,实现同构、异构数据库间以及跨数据中心的数据复制,满足数据多级存储、交换和整合需求。

      主要应用于基于表或库的业务数据迁移、业务数据向数据仓库复制等数据迁移场景。

      数据复制技术组件大多采用数据库日志捕获和解析技术,在技术选型时需考虑数据复制技术组件与源端数据库的适配能力。

    • 消息中间件主要适用于数据最终一致性的业务场景,它采用异步化的设计,实现数据同步转异步操作,支持海量异步数据调用,并通过削峰填谷设计提高业务吞吐量和承载能力。

      它被广泛用于微服务之间的数据异步传输、大数据日志采集和流计算等场景。另外,在领域驱动设计的领域事件驱动模型中,消息中间件是实现领域事件数据最终一致性的非常关键的技术组件,可以实现微服务之间的解耦,满足“高内聚,松耦合”设计原则。典型的开源消息中间件有Kafka等。

    分布式事务主要是解决分布式架构下事务一致性的问题。单体应用被拆分成微服务后,原来单体应用大量的内部调用会变成跨微服务访问,业务调用链路中任意一个节点出现问题,都可能造成数据不一致。分布式事务是基于分布式事务模型,保证跨数据库或跨微服务调用场景下的数据一致性。

    分布式事务虽然可以实时保证数据的一致性,但过多的分布式事务设计会导致系统性能下降。

    因此微服务设计时应优先采用基于消息中间件的最终数据一致性机制,尽量避免使用分布式事务。

    技术中台是业务中台建设的关键技术基础。在中台建设过程中,可以根据业务需要不断更新和吸纳新的技术组件,也可以考虑将一些不具有明显业务含义的通用组件(如认证等),通过抽象和标准化设计后纳入技术中台统一管理。

    为了保证业务中台的高性能和稳定性,在技术组件选型时一定要记住:尽可能选用成熟的技术组件。

    展开全文
  • 引言——首先来聊聊现代企业数据架构及痛点: 数据孤岛:低效率和利用困难的根源 应用瓶颈:传统方案数据仓库、数据湖的不足   单讲这两问题你可能会...所以下面来讲讲两实际的例子来细讲一下这两问题:......

    引言——首先来聊聊现代企业数据架构及痛点:

    1. 数据孤岛:低效率和利用困难的根源
    2. 应用瓶颈:传统方案数据仓库、数据湖的不足

      单讲这两个问题你可能会疑惑——为什么会出现这样的问题?

    所以下面来讲讲两个实际的例子来细讲一下这两个问题:

    第一部分——两个实际的场景例子引入

    1.以航空公司的场景为例:

      航空公司的市场部计划推出一个新产品或者是一个客户活动,会希望了解哪一种渠道是某类客户最常用的?当想到这个问题的时候,发现航空公司的客户触点太多了。

      PSDP行程订单,投诉、行李系统,常旅客系统,手机App系统等等。这些系统都是航空公司在不同阶段,不同的业务部门建立的应用。这些应用在部署时只会以本业务为目标,而不会考虑到企业其他业务能够很好的对接。如果这些应用中的数据没有做到统一的话,那要花费数天或者数周才能得到结果,甚至都不知道哪里能够拿到数据。有时就算知道,还要协调其他业务部门来正确地给到。

    在这里插入图片描述

    2.以保单贷小程序的场景为例:

      当客户通过这个保单贷小程序申请现金贷的时候,如果客户在保险公司中已购买过重疾险、人寿险或财产险,系统可以根据客户的保单额,在一分钟内判断出提供给客户适合类型的现金贷。

      在上线的时候发现,这个保单贷小程序很快开发好了,但是数据在人寿、重疾、财险等不同的系统里面,有些还需要推荐系统和标签系统。所以要花很多的时间来做数据的对接,这个时间是数周、甚至数月。因为其中不只是数据问题,还涉及到权限等问题。

    在这里插入图片描述

    以上的情形都是企业中常见的数据孤岛的问题,而且随时 IT 建设的发展,这个问题会原来越常见。

    在这里插入图片描述

    综合分析:

    1. 有关于第一个问题——数据孤岛:
      数据孤岛成因:
        是由于事业部门在建设 IT 服务的时候,分别以各自业务建设为核心,而不是以数据建设为目标而形成的。

    2. 有关于第二个问题——应用瓶颈:
        其次,常用的数据库如Oracle, SQLServer, DB2, Sybase,这些关系型数据库一直以来存在性能扩展的瓶颈。导致在上大的系统,或者客户量增加时,需要采用分库分表的方式。因为单个库没有办法支撑到太多的业务量。这也形成了大量数据孤岛。

    3. 上述两个问题形成大量的数据孤岛,所带来的的对应的问题主要有(数据孤岛带来的影响严重阻碍了新业务对已有数据的重复利用):
      ①需要大量时间对接和同步;
      ②用户体验下降,数据不完整不实时;
      ③重复建设,复用率低等。

    第二部分——各种解决方案的分析

    在这里插入图片描述

    为了解决数据孤岛的问题, 目前的解决方案:

      有应用层面 ESB 企业总线、MQ等;从存储角度来说,有数仓Teradata,Greenplum,以及数据湖。这些方案都可以在一定层面上解决问题,但是存在局限性:

      首先,这些方案都是面向分析场景,对于数据抽取不及时,多数是 T+1 方式,也就是说业务获取的数据,是系统昨天生产出来的。这些数据在数仓及数据湖中处理形成了大量报表及结果数据,通过下载、导出等方式进行交付,形式粗放。所有目前市面上的大数据平台,大部分的场景是偏重于分析,主要用于做BI,做报表、Dashboard,来对企业的运营和客户有所洞察。

    在这里插入图片描述

      而对于企业运营来说,关键的、核心的能力不是后端的分析,而是在前端与客户交互,与业务交互,与流程交互。

    基于上述情况,数据中台应运而生。

    第三部分——优胜劣汰留下唯一解决方案->数据中台

    以打通部门或数据孤岛的统一数据平台为基础,构建统一数据资产体系,并以API服务方式为全渠道业务(分析 + 应用)提供即时交付能力的企业级数据架构。

    在这里插入图片描述

    • 首先,统一数据平台。
      数据中台也是一个数据统一的平台,它不会取代原来的系统,而是把原来组织中分散在各系统中的数据实时地汇聚到统一平台之中。

    • 其次,数据资产体系建立。
      与数仓及其它大数据平台不同的是,汇聚统一之后,做数据资产体系规划。对数据打标签,组织目录和结构,便于发现和使用。

    • 最后,提供数据服务。
      以API的标准接口方式向前端的业务场景,或分析场景提供服务。而不是通过传统的SQL,或者是dump的方式来导出数据。我们称之为DaaS(Data as a Service),数据即服务。

      构建企业数据中台,所支撑的场景不仅仅是分析(如可视化分析,数据发现,数据报表等等),也包括满足各种前端业务应用对数据的需求,如CRM、BPM、SCM、MES等。所以这里提供的数据服务是全渠道业务,而不是传统数仓做的BI类似的工作。更多前端业务应用如掌上商城、手机银行、保单管理、客户360、统一订单、销售大屏等。汇聚在中台的数据可以直接推到手机、App等各类前端,并且是实时的,交互的数据。

    这些都是传统数仓这样的平台所无法比拟的。

    以下是金融企业的数据中台架构参考(银行业):

    • 最低下蓝色是EDW、Hadoop、DB2、Oracle等是已有的各类系统的数据源。

    • 通过CDC、批量导入、API集成等方式把数据汇聚到中台。

    • 在中台里面进行资料的建模和分类,比如按照客户、账户、交易等纬度。

    • 然后以API方式交付到他们的各个业务中心。

    • 最后做成各种业务开发,如金融商城,手机App,社交系统等。

    在这里插入图片描述

    在没有数据中台的时候。实现这些前端场景需要各个业务中心找每一个需要用到的数据中心去协商,前端业务直接连到后台的核心系统。因此而产生两个问题:

    1. 当数据量上来时,如做促销活动,核心系统DB2,Oracle等跟不上。

    2. 当有业务中心有新的需求产生,对数据模型要改变的时候,核心系统很难支撑。

    当企业有了可以灵活组织新的业务模型的数据中台,才可能真正快速地响应前端的业务需要。

    在上图的右上角,可以看到数据中台依旧可以支持一些分析的场景。

    当然,这样的数据中台必须具备数据的治理能力,如质量,编目,建模等等。

    所以数据中台的主要价值在于,数据的协同效率、复用效率和交付速度。原各个系统中的数据不再各自为政,而协同到一起效率提高很多。同样,一份数据可以给多个业务场景使用,而不再需要 ETL 到不同的系统,还要去维护它们的一致性,去掉重复,或防止遗失。最大的价值更在于,加快数据的交付速度。

    (1)技术需求:

    我们讲完了这个中台的一个架构和它的逻辑模型,如果我们要来考虑实施数据中台有哪些技术模块要考量。还回到刚才那张图,首先中台必须是基于一个数据统一平台的,那数据统一的时候,其实刚才没有讲到的,还需要把数据同步和汇聚过来。所以有一部分的工作你是少不了的,如果你没有做过这种中台甚至统一平台的话,你必须有一个ETL平台来把你的来自各个来源的数据抽取过来,抽到你的数据统一平台上。

    数据统一平台你用什么样的解决方案?那是另外一个问题,回头我们会讨论。那进到里面了以后,我们在上面才构建我们的资产体系,这个是需要用到中台相应的一些比如数据治理的模块能力来做这个事情。那最上面层就是一套服务化能力,要把它做成API server 的方式,把这个数据快速的可以交付出去。

    基于上述对于数据中台的理解和定义,我们列出了数据中台所应该具备的技术需求。主要是分为:数据存储系统、数据同步汇聚工具、数据治理和开发、数据交换和发布、数据管理能力五大模块。

    如下表:
    在这里插入图片描述
    在这里插入图片描述

    • 我按照各每个系统大概列了一些数据中台比较核心需要的能力,当大家在采用某一种系统的时候,某一种方案的时候,可以对照一下。也不是每一个你们都会关注,但是这是从我们经验中经常用得到的。比如作为数据平台存储系统的话,你第一个肯定是要横向扩展。为什么?你做的是一个企业级的数据平台,你要把所有的原系统有可能真的做到其极致的话,可能全部把他拿过来,所以你必须得有一个横向扩展能力。不能想今天我的数据这个数据在MySQL可以放得下了,或者是一个Oracle可以放得下了,但你要考虑到明年、后年,甚至是三年、五年以后,因为这个架构放上去以后是一时半会不会动的,那灵活的数据模型,这些也是我们的经验,我们要这个是做一个数据汇聚。往往你的一套同一个客户系统,同一个客户模型会来自于多个不同的系统。这个时候,你有一种灵活的模型和相对的一种比较死板模型的话,你会发现这种灵活模型会比较容易的把数据整合进来,能够接受不同的一些字段的变化,也可以方便的把它合并到一个模式里面。

    • 高并发低延迟就是我们这个中台最终不仅仅是支撑分析,还要支撑前面的业务,所以必须得有这种潜在的直接穿透到前端,例如我们的移动端用户,或者会有大量的这种高并发。作为这个核心数据,高可用、备份、安全都是不用说的了。这是关于存储系统数据平台的一些最基本的一些要素,所以大家考虑的时候,可以从这方面来想这个问题。

    • 其他还有涉及到就是同步工具。批量导入能否实时同步?批量导入一般都有,但是能够实时同步,比如说因为我们要做的事情真的是比如说我们在一家银行做的需要这边刷卡,刷完卡,这个数据在三秒之内直接要进到我们的中台里面,因为上面有一些业务场景会给予中台来做一些推送。所以这个时候实时同步的能力是非常关键的,然后还有一些断点续传或者是所有的数据源的支持,这个就是比较常见的这种同步工具的一些需求了。

    • 治理开发就是我们刚才讲的很多就是说怎么样之间数据体系,你必须得有一系列的能力。数据目录、原数据管理、建模、开发、质量管理等等,匹配去重都是,需要在考察的时候,看他们中台有没有这个能力来做这些事情。

    • 数据交换的发布就是我们的data API。我们说这是一个数据开发平台,我们面对的使用者,比如大数据团队也好,或者数据管理团队也好或者DBA也好,往往不会是开发人员来做这事情。这更像是一个比较中央化的数据平台团队,所以他们关注的可能是一些管理能力,无代码能力就不用让他们写很多代码,所以这个API能否很方便、很快速地按照需求来接通到为前端做服务,这是很关键的。当然,接口的多样性也是非常关键。SQL方式,大数据、流数据,这些接口都按照我们的需求考虑是否需要。

    • 最后一点就是系统管理能力,就是常见的就是这种可视化。因为这里面做很多的事情要有一些相应的任务管理、任务设计、监控、告警啊等等,权限管理,一般的系统都会有这种需求。

    (2)技术选型:

    常见搭建数据中台的技术产品!

    数据中台包括:统一数据平台,数据同步,数据治理,数据服务四大部分。

    下表列出了这四大部分中相应的技术产品,有同步汇聚工具、有数据治理、还有数据服务。

    在这里插入图片描述

    • 数据平台最常见的是以 Hadoop 大数据为基础的。在最近十年,有很多家公司投入很多来做这个事情,把数据已经收集到中央化的一个 datalake 里面,那这个就是个很好的起点。其他的还有用数仓来做的,用 Teradata 或者是 Oracle, Gleenplum,MySQL Cluster,MongoDB,国内的话,有星环或者一些大数据公司。有一些特殊的场景,有人会用一些其它产品,比如说 ElasticSearch 会用来做一些全文搜索,但往往那个只是配合,他不会整体的放在这上面。

    • 同步工具就很多,有开源的,有商用的。开源的话,比如有 Kafka、Kettle, Spark ETL 、Talend,商用的的话要有 Informatica、Golden Gate,包括我们 Tapdata 也提供这种类似的数据同步工具。

    • 治理方面比较做的比较好的可能是开源的话,有 Apache Atlas,那如果是开源商用的话 Informatica 应该是最老牌的,Erwin 这些都是比较经典的这种数据治理的公司,可以配合这些产品来把中台里面数据进行编目和治理管理,Oracle 也有相应的产品。

    • 数据服务就是涉及到API。我们见的最多的可能还是大家用 spring 来搭建一个 API 框架,或者有一些比较现成的 API 机,像 Kong 比较流行。Kafka 是提供一种流式数据的服务,可以做 streaming,Loopback也是可以用 nodejs 的方式来提供 API。Mulesoft 和 CA 都是一个非常成熟的 API 产品,当然他们的价格也不便宜。

    • 他们的优势是他会给你一套整体的 API。不仅仅是服务方案,还有管理方案,他的监控、安全、认证、鉴权,然后把你所有的不管是 data API也好,你的业务API也好,都有个统一的管理界面和一个 gateway的方式来帮他做好。

    • 这里面大家可以看到有非常非常多的选择。如果咱们已经有的话,基本上是用已有的工具,如果没有的话就可能要好好的来看一下看看哪些厂商,或者是一些共享的方案。下边我们也会分享一个方案,可以参考一下来一个快速的选型。

    (3)数据平台产品分类:

    对数据平台比较关注的来看一下数据平台产品分类。

    1. 数据平台的这种产品从90年代开始,从关系型数据库到21世纪的数仓MPP,到后来的大数据,到现在的很多的NoSQL,NewSQL,有非常多的种类。他们都有什么样的特色呢?是否合适来做数据中台的一个存储呢?

    在这里插入图片描述

    1. 数据统一平台的特点对比:
      在这里插入图片描述

    2. 数据统一平台选项参考:
      这里简单来看一下,如果是做数据统一平台选型参考的话,从它的海量数据能力,响应时间和并发能力和他支持多结构数据的能力上,我的个人见解。比如说我们说的现在的NewSQL的吧,他就是对多结构数据支持不是特别的理想。包括RDBMS、MPP也都是这样,那这个时候大家可以考虑一下用哪种方式。这取决于你的场景,MongoDB确实他有他自己的一些弱点,比如做多表关联的时候其实并不是他的优势,我们会建议尽可能避免这种多表关联的场景。但是如果你真的是避免不了的话,那他可能就不是一个很好的选择。
      在这里插入图片描述

    3. 选型建议:
      在这里插入图片描述

    这里是我的一些小小的选型建议,从我个人的出发点,按照我的自己的跟客户的一些交流的经验看了他们的一些情况,然后也是经过一些项目的实施,就是提供的一些情况,然后也是经过一些项目的构实施提供的一些建议。

    • 如果你已经有Hadoop或者数仓的统一平台,我们很多的头部企业,大型企业都是已经有的,这个时候你是不希望从头开始构建一套新的什么所谓的中台架构。你基本上可以基于这个基础之上,配合他的数据治理,把它打造成一个数据资产体系,然后加上他的Data API。对于这种情况,我们刚才看到的很多的已有的数据中台的解决商,他都是基于这种大数据的方案来做的,所以他们的一些能力。往往是已经跟你Hadoop Hive之类的或者数仓呀做比较好的结合,那些同步工具,ETL工具都是有比较不错的结合了,你就可以在这个基础上只是用它的理念来构建。

    • 如果你还没有数据统一平台,没有数仓,没有这个Hadoop之类的话,这个时候我们觉得可以考虑一下,就是我们推荐的这种MongoDB的方案,会非常理想,因为我们相对来说是比较简单一些。起步会快,假设真的不行,你也可以很快就见效,我们叫做非常 fail fast,错就错的快一点,不要花很长的时间才发现不行,那如果你还没开始构建的话,一步到位就可以拿到。因为我们刚才讲的MongoDB在数据平台上是有很大的优势的。如果是Hadoop的话,最近几家合作的海外的那几家都三家只剩下了一家Cloudera,其他两家都已经被收掉了或者被合并了,这也是因为它的本身有很大的局限性,很复杂很难用,投入很大,收效比较小。

    • 如果你的中台主要目的想支撑前端交互式应用。那MongoDB是最理想的,因为我们的特点就是高并发、低延迟、横向扩展。然后非常面向开发,非常面向JSON API,这是非常理想的。那Hadoop的话,他一开始大数据都是以分析为主的,不是为前端为主的。

    • 反过来,如果你的中台数据目前你看不到有什么前端的业务场景会来使用。最主要的还是解决这个数据统一。而且你觉得有很多复杂的表。要做很复杂关联,这个时候一下子把它合并到一个JSON里面是几个JSON里面是比较麻烦的,那可能是MongoDB的适用度就一般了。那反而是那些基于传统的数仓的,那个会比较做的会比较好一点,相对来说是功能上比较完善一点。

    • 如果你是比较喜欢有些比较快速,能够比较轻一点的,比较简单一点的。下载下来就可以安装可就可以跑起来,那我们Tapdata这种方案会比较轻便一点。

    • 如果你没有数据工程师的话,我们MongoDB的一个的优势就是比较自然,比较直接,比较容易理解数据模型,会是一个不错的选择。

    • 如果你没有明确你这个中台搭建的想做什么,我们可能不合适,因为我们可能这个事情做出来以后没有什么太大的效果的话,你就发挥不了我们的所谓的这种价值。其他的方案,我也不知道是不是合适了。

    有了这么多解决方案,我们来看一下,如果是基于一个 MongoDB 的方案会是怎么样?我们刚才只是讲的数据平台在做一些选择,但是做一个完善的数据中台的话还需要很多其他模块,所以这里面是用到了另一个产品,就是Tapdata DaaS。通过 MongoDB 和 Tapdata DaaS 这样一个组合,一起来做这个中台的解决方案。

    第四部分——tapdata DaaS 基于 MongoDB 的数据中台落地方案

    (1)落地

    MongoDB 作为中台架构的数据平台

    • 我们先来看MongoDB作为中台架构的平台优势。
      ①MongoDB 是一个多模数据库。所谓多模数据就是他一套系统里面一套分布式集群,里面可以做很多的不同的事情,有的时候你可以把它作为一个内存数据库,可以把它作为一个目录数据库,也可以把它作为一个IOT的数据模型。就是说它的多模性特性是比较有特长的,而且它的自动扩展能力也是非常适合这种中台的统一平台的需求。多模多态,对汇聚性也是非常重要,因为我们需要支撑不同结构、半结构化、非结构化、甚至一些图片文件能够来做到这一些。
      ②另外,就是MongoDB的API友好能力,采用 JSON 作为传输格式。我们知道现在都是微服务,都是通过Data API的方式交付数据中台的数据。前面业务中台往往都是用微服务,也是通过这种RESTful API,那MongoDB的这种JSON模型对新一代的这种架构式有得天独厚的优势,你会发现你花很少的时间就可以把这个API构建好。另外,MongoDB 也原生提供这种 Streaming API 帮助来做一些流处理的事情。所以MongoDB 作为一个中台的统一平台数据库,其实是有非常得天独厚的条件。
      ③当然,除了他的多表关联是可能是缺陷。
      在这里插入图片描述
      ④MongoDB另外一个优势就是它的对象模型。我们的 JSON 模型就是非常接近于我们开发的对象,Json也好,或者是Java 里边的 Object,python 里面的 Dictionary。
      在这里插入图片描述

    • 一个传统的数仓,或者是现在的数据中台的数据统一平台,要做很多的数据治理。比如要做一系列的建模的工作有概念建模、逻辑建模、物理建模。而且物理建模就是我们所谓的物理层,那就涉及到关系模型。管理一个逻辑对象,怎么样转化成五张表,十张表,20张表遵从第三方指示,这里面其实是很复杂,也会很花时间。你要设计一个很好的模型,怎么样来支撑未来的业务,这也是为什么传统数仓会花那么多的落地项目代价来做这个事情。

    • 而MongoDB的解决方案能轻松地处理这方面的事情,这就是为什么 MongoDB 会受很多开发者的喜欢:MongoDB 在建模方面是一个非常独特的形式,它的模型是基于类似于这种逻辑模型的对象模型。你可以把它理解为差不多是一对一。业务人员一般都会明白这个概念,比如建模、逻辑建模,这些模型他们心里都有数。他们就是可能不懂那种种 DBA 说出来的的 Oracle 的这种建模方式,但是对于 MongoDB 来说,其实你只需要达到逻辑建模层的话,你就可以把这事情做了。而且这个模型建完了以后,直接可以用REST API的方式交付出去。从这一点上来说,它是有一个技术上是非常独到的一个先天性的优势,尤其对我们想做这种基于API的这种服务中台来说。

    • MongoDB 的读写分离,HTAP支持全渠道业务需求。 有一些开发者会说是 HTAP (Hybrid Transaction and Analytical Process),就是说又可以做分析业务,也可以做的交易型的业务。在MongoDB里面,我们怎么样来做这种事情呢?比如说一个集群里面,一个cluster,一个复制集,我们有五个节点,四个Secondary,一个primary。左边的primary节点可以用来直接。直接跟我们的手机或者是网页端的应用进行交互收集,采集数据,用户数据。那MongDB自动同步把的数据从primary同步到secondary里面。

    • 然后我们还可以除去左边三个,作为正常的高可用集群来说,我们还可以拿出两个节点专门用来做分析,你看他这个use=analytics。就是一个标签,就比如说这两个节点是只是用来做于分析型的,那这个时候我们就可以用它来上面。加上我们的BI connector,或者是直接用我们的MongoDB charts和compass,直接可以对接MongoDB数据库做一些展示:kpi,dashboard等等。我们也可以通过一些大数据接口,比如说spark connector 来做一些大型的machine learning或者是AI都是,有很多的这种应用场景,那这些都可以最实时的,在你最新鲜的数据上通过一个读写分离的架构上来完成,你不需要再ETL。在MongoDB里面,这个ETL的需求量是非常非常少的,因为可以通过原生的这种同步来提供数据的汇聚,数据放到这个分析集群里面。

    • MongoDB 还有一个触发器的 API 也是比较实用的。就是大家如果不是太了解的话从3.6开始有个change stream,你可以用来订阅数据库的更新事件。比如从IOT设备过来,有一个灯亮了,有一个设备进入一个地理围栏里面发个报警。你都可以通过一个非常简单的订阅方式获取这些事件,然后做一些实时的,响应式的处理,不管是在dashboard上面显示个警告,或者是把它推送到一个Message Queue 、Kafka之类的都可以,直接就用MongoDB的原生的功能来完成。

    (2)Tapdata DaaS 是什么?

    Tapdata DaaS 是钛铂数据为现代企业加速数字化转型设计的数据平台,通过提供采集、存储、组织和增强等一揽子解决方案,从而得到更加方便和友好的数据服务。

    Tapdata DaaS 提供了4个主要的功能模块,数据采集和同步、数据转换和治理、元数据管理、和数据服务。
    在这里插入图片描述

    Tapdata: 为MongoDB量身定做的中台构建工具集

    Tapdata DaaS 可以看做是 MongoDB 生态上一个工具集。 要做一个数据中台,要同步、要治理、要建模、还要做API发布,这些都不是 MongoDB 做的事情,MongoDB 主要是做数据库为它的核心的主要的功能,其他的相应的功能就可以通过一些外围的工具。而 Tapdata DaaS 可以快速的来实现这些不需要用代码的方式快速把数据的同步,建模和治理,以及发布给快速的做出来,这个大概就是一个整体,Tapdata DaaS 加 MongoDB 的架构。下图中的蓝色的部分就是中台的几个其他部分,绿色的就是MongoDB 的数据平台。

    在这里插入图片描述

    1. 数据同步及处理能力:
      结合 MongoDB , Tapdata DaaS 这套方案是可以快速落地, 可以最快的时间对接上数据进行建模、同步,然后拉到中台里面并进行把它发布出来。举一些例子,比如说可以从 Oracle database 里面把它的表的数据拖到 Tapdata DaaS 的目标的中台库里面,然后对数据进行 JSON 建模,或者是一对一建模。在这个过程中,还可以是进行实时的同步,基于日志的同步。Tapdata DaaS 数据源可以支持 SQL server、Oracle、Sybase、MongoDB、DB2 、MySQL、Redis、Elasticsearch 等等,也支持文件,比如 excel、CSV。

    2. 数据建模能力:
      基于这种内嵌的模型Embedded的模型,把一对一,一对多的关系,甚至多对一的关系就直接就合并到里面去。这个会对客户数据合并、产品数据合并、订单数据合并有非常好的效率的提升。Tapdata DaaS 提供一个可视化的建模见面,就可以很容易完成这种合并工作。

    3. 数据治理能力:
      数据进到库里面,进到中台里面。有来自于不同的数据库,几十套,上百套都有可能,每一套库里面有几百张表在里面必须有一个非常好的分类,非常好的组织能力。按照不同的目的、不同的角色、不同的规则或者数据体系给它分门别类建好在这里面,把这数据打好标签,这样的话可以快速的让大家高效的来使用到这些数据。

    4. 数据API发布能力:
      可以通过RESTful API快速的交付出去。提供图形化低代码开发工具,只需要几分钟的时间就可以简单的发布数据给其他使用方调用。兼容Open API,也可以支持行级列级的过滤。同时也会有一些API文档的测试能力,权限管控等等,这个是中台必不可少的能力之一。

    展开全文
  • 5步骤,打造你的业务中台

    千次阅读 2020-04-13 16:15:49
    数字中台建设的整体策略,核心思想是从业务抽象到领域建模,再到架构设计。因此业务中台的架构思路和整体策略保持一致,并进行必要的补充。以下,Enjoy: 01 业务抽象 在业务抽象阶段,通过业务调研和业务分析...
  • 白话解读“中台技术

    千次阅读 2019-08-14 12:47:58
    什么是中台系统?它是如何诞生的?它长什么模样?我们为什么需要它?一串串的问题不禁浮现在我们的脑海,今天我们就带着这些问题,一起走进中台。什么是中台中台诞生任何一软件系...
  • 一文读懂数据中台技术架构

    千次阅读 2020-11-02 22:11:52
    一文读懂数据中台技术架构 https://www.toutiao.com/i6836923386560512516/?tt_from=weixin&utm_campaign=client_share&wxshare_count=1&timestamp=1603853943&app=news_article&utm_source=...
  • Chrome 技术篇-一电脑设置多个独立chrome方法实例演示,chrome独立多开技术。 先看效果图,只要电脑性能允许可以无限开。 任务栏已经分开显示了,新开的Chrome是纯净的,跟原来的chrome是独立。 两个chrome互不...
  • 2、解读中台 -- 中台的作用

    千次阅读 2019-10-06 19:43:41
    中台的作用 中台应该包含哪些内容呢...中台是从多个相似的前台业务应用共享的需求产生的,因此最先提出的中台是业务中台; 数据是从业务系统产生的,而业务系统也需要数据分析的结果,那么是否可以把业务系统的数据...
  • 【一服务器上如何创建多个网站?】 本质就是Nginx监听一服务器的80端口,使用不同的域名映射到不同的Linux文件目录(站点发布的目录) 其实很简单,我们以阿里云服务器(这里有阿里云的最新优惠活动,记得领券再...
  • 搭建中台架构的几误区

    千次阅读 2022-04-20 16:53:17
    数据中台建设仅仅是企业IT变革的起点,建设一项目或者搭建一平台并不能解决企业数字化转型遇到的所有问题。 数据中台是企业数字化变革的关键,企业在决定进行数字化转型时便要根据数据规模和应用需求制定全套...
  • 前台、后台我知道,中台是什么呢? 今天一早起来,整个互联网圈都被腾讯的组织架构调整刷屏了,甚至有些人对腾讯新的6大事业群如数家珍,侃侃而谈,搞得比对自家公司的组织架构还清楚一样。 腾讯进行组织架构调整...
  • 但如果中台同时服务于多个前台应用,在资源有限的情况下,必然涉及对来自不同应用的需求的优先级排序和取舍。如果前台应用急需某一能力,但中台又不能及时提供,是否允许前台先实现,等中台有时间再来沉淀? 由此...
  • 作者 | 杨威,明略科技技术中心负责人编辑 | 夕颜出品 | AI科技大本营(ID:rgznai100)本文为CSDN即将推出的《新战场:决胜中台》专刊的第 3 篇文章。【导读】数据中台...
  • 文/技术领导力社区编辑/Emma阿里中间件高级技术专家 钟华、高级技术专家 泠茗、中间件技术专家 玄难,在公开分享和访谈中提到阿里技术中台建设实践,包括:技术中台、移动中...
  • 数据中台建设的价值架构 数据中台的终极使命是赋予数据资产价值变现的能力,无论是通过业务赋能的形式隐性变现,还是通过数据服务公开交易的直接变现。它们都需要一很重要的基础条件“数据资产化”。 数据中台...
  • 【一服务器上如何创建多个网站?】 原理分析 本质就是Nginx监听一服务器的80端口,使用不同的域名映射到不同的Linux文件目录(站点发布的目录) 首先就是多个域名可以解析到同一个ip地址。我们的虚拟主机技术...
  • 数据中台怎么选型?终于有人讲明白了

    万次阅读 多人点赞 2022-01-07 14:07:21
    数据中台怎么选型?终于有人讲明白了
  • 大白话中台系统

    千次阅读 2019-11-11 10:44:47
    什么是中台系统?它是如何诞生的?它长什么模样?我们为什么需要它?一串串的问题不禁浮现在我们的脑海,今天我们就带着这些问题,一起走进中台。  1、中台诞生  任何一软件系统都是通过帮助客户解决问题来...
  • DDD到底是什么概念,和微服务和中台之间又有什么样的联系,带你走进DDD!!
  • 01 阿里中台架构的定义 ...“中台架构,是将企业的核心能力随着业务不断发展以数字化形式沉淀到平台,形成以服务为中心,由业务台和数据中台构建起数据闭环运转的运营体系,供企业更高效的进行业...
  • 多个域名对应一个服务器,为了避免域名后增加端口号,两个域名都需要占用80端口号,使用nginx来进行配置。 2. 解决方案 目前项目,线上正在使用(100%可用)多域名对应一个服务器情况(线上ip及域名替换了下) #...
  • 1、解读中台 -- 什么是中台

    千次阅读 2019-10-06 18:57:15
    中台,通过对业务、数据和技术的抽象,对服务能力进行复用,构建了企业级的服务能力,消除了企业内部各业务部门、各分子公司间的壁垒,适应了企业,特别是大型企业集团业务多元化的发展战略。基于中台,可快速构建面向最终...
  • 何修峰,就职于滴滴业务中台,任高级技术专家一职,致力于微服务治理、提高系统工程效率、构建底层基础组件或服务,在大型分布式系统构建、微服务治理、复杂系统重构方面有丰富的经验,现负责滴滴支付中台基础工作,...
  • 全渠道零售中台与数字化转型(1)-中台的前世今身

    千次阅读 多人点赞 2019-06-25 15:37:59
    本系列博客的目标是计划使用近半年时间创造: 国内唯一一部从业务场景到技术设计,从企业战略考虑到技术细节落地的大全;... 全渠道零售中台与数字化转型(3)-中台给企业技术带来什么实际的价值? 全渠...
  • 数据中台被誉为大数据的下一站,由阿里兴起,核心思想是数据共享,2015年阿里提出“大中,小前台”的策略。2018 年因为“腾讯数据中台论”,中台再度成为了人们谈论的焦点。 2019年,似乎人人都在提数据中台,但...
  • 如果说公网IP地址,那么多台电脑的IP地址会被路由器NAT成同一IP地址进行上网。WIFI(无线路由器)是代替终端进行拨号上网或者固定ip配置接入互联网后,利用自带的无线功能通过DHCP服务,把私网ip地址分配给终端用户...
  • 持续输出 敬请关注 大数据架构 湖仓一体化 流批一体 离线+实时数仓 各种大数据解决方案 各种大数据新技术实践 持续输出 敬请关注
  • 【一服务器上如何创建多个网站?】 原理分析 本质就是Nginx监听一服务器的80端口,使用不同的域名映射到不同的Linux文件目录(站点发布的目录) 首先就是多个域名可以解析到同一个ip地址。我们的虚拟主机技术...
  • 中台什么鬼 | 白话中台战略

    千次阅读 2018-11-25 01:14:24
    从去年开始,好像就有一只无形的手一直将我与“微服务”、“平台化”、“台化”撮合在一起,给我带来了很的困扰和思考与收获。 故事的开始源于去年的技术雷达峰会,我在会上做了一场关于平台崛起的主题分享...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,076,522
精华内容 430,608
关键字:

多个中台技术