合集7、中台建设方法

目录：TOC\o"1-3"\h\z1、中台实践亲历 22、中台生态的形成：全面解读技术、研发、移动中台建设 63、中台如何助力标准化业务？中台关键要快！ 194、中台将使IT成为业务变革驱动力|一周一晖 295、怎么建设中台。业务中台和数据中台的组织、支撑技术和方法论 316、有赞数据中台建设实践 417、有别于BATJ，滴滴的中台数据体系建设怎么另辟蹊径？ 508、易凯资本王冉：打造“强中台”型内容公司 729、以安全中台为核心，构建关键基础设施安全运营 8910、一文看懂“数据中台”建设的方法论 9411、要不要赶个时髦，去建设一个「中台」？ 12012、学阿里中台，就要学最值钱的部分：中台建设方法论！ 12713、新零售时代的智慧中台 14214、网易数据中台建设实践 15215、王歆：大热的中台，我拿什么来爱你 16116、体验营销再进阶，天猫Club构筑“中台系统” 16417、所有的中台都是业务中台 17018、数据中台建设的浅析 17619、数据中台构建最核心的代码都在这里了，建议收藏 18120、什么是中台？企业为什么要建中台？从数据中台到AI中台。 18321、如何建设中台组织？ 20722、企业中台建设 22523、企业微服务中台落地实践和思想之我见 23324、企业数据中台的构建 24225、命保住了！五年时间，我们也搞了一个技术中台 24626、你可能并不需要中台 25927、六大巨头发力“中台”，当我们在谈中台时究竟在谈什么？ 26028、加强内部审计部门的“中台”建设 26829、基于平台构建中台 27030、关于中台，你可能不知道的那些事 28131、从ERP看企业应用中台 29132、从CBB谈中台的重用复用 29733、从“中台战略”开始，实现企业新旧动能转换 29934、不做中台会死吗？ 30435、产业洞察|中台瞭望之三：企业如何选择合适的中台“伴侣” 33636、阿里技术专家：技术中台/移动中台/研发中台，16页PPT一次讲透！ 34437、美菜网交易中台建设-34页PPT 3561、中台实践亲历一个偶然的机会，听到的中台这样一个名词；马上被它的概念所吸引，觉得这将是企业IT的重要方向。果然，接下来的时间，中台这个名词像雨后春笋一样在整个行业中传播开来，热度高涨；笔者有幸也参与到的中台的浪潮中，负责某一国际零售企业的中台建设工作，一年多来，初有成绩，想来和大家交流探讨，以回顾这一年多的实践与思考；“中台”的由来首先，还是从中台最烂大街起源开始，以方便对中台概念不熟悉的朋友来了解什么是中台。游戏公司Supercell2015年，马云带领阿里巴巴拜访了位于芬兰赫尔辛基的移动游戏公司Supercell。Supercell当时号称是世界上最成功的移动游戏公司，Supercell由6名资深游戏开发者在2010年创立，旗下拥有《部落冲突》、《皇室战争》、《海岛奇兵》和《卡通农场》这四款超级现象级产品。Supercell是一家典型的以小团队模式进行游戏开发的公司，以2到5个员工、最多不超过7个员工组成独立的开发团队，称之为Cell(细胞)，这也是公司名字Supercell（超级细胞）的由来。Supercell的成功很大原因就在于其高效的“部落”组织策略。在supercell仅有的100多人中，被分成若干个小前台组织，每个小组虽然人不多，但都包含了做一款游戏需要的所有人才。本来就不大的公司被分成若干个小组，这样做的好处是可以快速决策，快速研发，快速把产品推向市场，而游戏引擎、服务器等后台基础则不需要操心。Supercell的模式给参加此次拜访的阿里高管们很大的震撼，在大家反复的心得交流和讨论中，一个非常重要的问题引起了很多人的反思：信息时代的公司架构到底应该是怎样的？正是有了这次拜访，才真正让阿里巴巴的领导层有了足够的决心要将组织架构进行调整。在此次拜访的半年后，阿里集团CEO逍遥子发出内部邮件，组织架构全面升级，建设整合阿里产品技术和数据能力的强大中台，组建“大中台，小前台”的组织和业务体制。

现代战争中的特种部队和战略支援以上阿里中台的由来，我觉得更通俗一点理解可能是下面这样：

现代战争，多以复杂的小型局部战争形式体现，真正的前线战士只有几人或十几人组成的小型特种部队，这样的团队响应快，应变能力强，解决的任务单一明确；而战场形式瞬息万变，如何能让特种部队在任务中快速的掌握全局，需要强大的后台支援，如需要强大后台武力炮火，海陆空全方面的作战信息，以及对手的变化动向；这样的才能顺利的执行任务完成既定作战目标；对应到企业信息化战略发展中，现在同样强调以敏捷小团队，以快速应对变化市场环境。这就可以定位为小前台；而为了支撑小前台，同样需要强大的后方支援，这样才能帮助企业快速迭代，实现快速，高质量，低成本帮助企业快速试错、改善、创新，应对快速市场变化；这也就是现在最火热的中台真正的意义；为什么要做“中台”随着科技的迅猛发展，各种新需求，新技术，新场景不断涌现，“变化”是这个时代永远不过时的名词。而千年的历史告诉我们，外在的表像时常变化，但事物的本质是稳定的，变化较少或近乎不变的；‘中台’的目的就是要将企业中业务稳定，核心的能力沉淀下来，在外界需求场景变化时，能复用这些能力，快速、高质量的响应和支撑前台需求，以帮助企业在快速变化的市场形势中立于不败之地；

现在几乎所有在大厂都在做中台，阿里、腾讯、永辉、字节跳动都在中台投入巨大的资源；虽然不同行业、公司对中台的理解以及建设中台的方向会有所不同，但比较核心的中台能力包含以下几个部分：

•

可复用，统一主数据，统一业务的中台•

支撑业务和服务能力的灵活扩展•

能够支持企业商业模式和业务创新•

业务灵活扩展，支撑多场景的很好的弹性平台•

企业内横向协同，产业上下游协同•

面向场景的应用，低成本的试错

本次文章讲述的是中台的由来和为什么要做中台，接下来的文章会进入的真正的中台实践工作介绍中，从如何开始搭建中台？业务中台，数据中台，技术中台，以及中台建设过程中的各种坑，希望能和读者一起探讨！2、中台生态的形成：全面解读技术、研发、移动中台建设导读：中台的存在价值是为它的客户服务，比如业务中台和数据中台要快速响应前台应用的需求。但如果中台同时服务于多个前台应用，在资源有限的情况下，必然涉及对来自不同应用的需求的优先级排序和取舍。如果前台应用急需某一能力，但中台又不能及时提供，是否允许前台先实现，等中台有时间再来沉淀？由此可以看出，大中台立足于横向的、全局的长远考虑，而小前台则注重于解决纵向的业务应用的当前问题。大中台的发展必然涉及权衡，但如何做取舍没有标准答案，需要结合实际情况进行。01中台的演变中台的催生基石是能力共享。如果中台所提供的能力无法被共享，那就不是中台能力。如果中台只服务于一个前端应用，那就不是中台。那么哪些能力比较通用且是多个前台系统的共性需求？要回答这个问题，可从系统的组成开始分析，如图3-9所示。一个应用系统首先是为用户服务的，因此最先离不开的是系统的角色和用户。因此，建设中台的一个起步点就是先将角色和用户这些资源管理起来，形成用户共享中心。统一用户、统一权限、统一登录，可以看作是中台的雏形，但如果仅仅停留在此阶段，就退化成了单点登录。在此基础上，再发展与人相关的会员系统，比如会员的积分、积分的变动、会员的等级等就形成了会员中心。再者，用户是通过商品、订单与系统进行交互的，因此，商品的管理、订单的集中处理也是可以一起共享的。这些资源的统一集中管理后，相关的用户、会员、积分、订单等数据被存储在一起，方便全局管控。进行集中管理的资源越多，建设中台所取得的成果就会越大，就越能体现中台对前台应用的支撑作用。▲图3-9中台建设的三个步骤在资源集中管理的基础上，更重要的是抽象出系统能力。抽象是指在考虑目标事物时，去除表象的、次要的方面，而抽取相同的、主要的方面，从而做到从个别中把握一般规律。通俗一些的说法就是将目标事物模型化。只有通过抽象，设计出来的能力才能应用到类似的需求中。中台是为前台业务服务的，因此当前台业务有所更改时，中台要随需而变。这就要求中台具有很好的灵活性来支撑业务的开拓和发展：数据模型需要根据前台业务要求实现可扩展性。业务流程可根据场景和需求重新定义和编排，并可通过插件机制进行定制。中台环境需要支持多环境可部署。比如不同的基础设施环境，包括公有云、私有云及容器云等；再比如不同的微服务框架，如阿里云的EDAS、开源的SpringCloud、Dubbo等。中台的建设不是从零起步，但是中台是为业务服务的，是需要根据企业业务演进逐渐积累而成的。因此中台的建设不是一蹴而就的。02中台生态的形成中台是企业级共享能力平台，因此除了最开始提出的业务中台和数据中台，还会逐步发展出技术中台、研发中台、移动中台、AI中台、算法中台、组织中台等其他中台。1.

技术中台技术中台整合和包装了云基础设施，以及在其上建设的各种技术中间件，比如微服务、分布式缓存、消息队列、搜索引擎、分布式数据库等，并在此基础上建设和封装了简单易用的能力接口，如图3-10所示。▲图3-10技术中台技术中台的建设标准是参考在一个只提供虚拟机或容器的私有云上，建设一个业务中台或数据中台所需但私有云没有提供的技术相关组件。技术中台作为工具和组件，为建设前台应用和业务中台提供了基础设施重用的能力，大大缩短了它们的建设周期。如果数字中台（即业务中台+数据中台）是强大的中台炮火群，则技术中台提供的是如何根据需要快速搭建中台炮火阵地（即创建和部署不同环境下的中台）。如何让阵地建设得更加可靠、简捷易用（通过技术中台提供资源的动态扩展能力等）？隔离数字中台对基础设施的依赖。比如业务中台的每个业务服务中心都需要关系型数据库。关系型数据库要提供一主一备和自动切换功能，以及读写分离和只读库创建的能力。为了快速访问大数据量的表，一般需要使用分布式数据库对其进行分库分表操作。分布式缓存是提高访问效率的一个必不可少的组件。通过消息队列实现异步解耦和大流量削峰填谷，这大大增强了前台应用应对大用户并发的能力。使用CDN加速的对象存储，可极大提高前端访问的性能。数字中台是在技术中台的基础上开发、运行的，但又不能与技术中台绑定。因为数字中台关心的是如何满足业务要求，而技术中台提供基础设施底层的能力，两者相互促进但又相互隔离。2.

研发中台研发中台是关注应用开发效率的管理平台，如图3-11所示。软件开发和系统建设是一项工程，涉及项目管理、团队协作、流程、测试、部署、运营、监控等方面。▲图3-11研发中台如何将在企业应用开发过程中的最佳实践沉淀为可重用的能力，从而更好地快速迭代开发创新型的应用，也是很多企业目前的一个关注点。这个关注点也是企业能力的体现，即研发中台。研发中台为应用开发提供了流程和持续交付的能力，包括敏捷开发管理、开发流水线、部署流水线、持续交付。敏捷管理一般由问题、迭代、实施等组成，并管理研发人员的日常工作和任务。开发流水线则涉及源代码的版本管理、分支的创建、合并和提交，半成品的构建、存储和使用以及产成品的构建。将产成品部署到指定环境并上线运行是部署流水线的职责。线上的应用需要监控，包括基础设施监控、应用监控、日志洞察、浏览器监控、链路分析和追踪等功能。研发中台为应用的开发提供了流程、质量管控和持续交付的能力。3.

移动中台消费者接触得最多的企业前台触点在移动端。如何保障移动端的迭代效率和稳定性也是企业需要着重考虑的。一个电商业务一开始可能只是一个工具型的App，完成对商品全生命周期的闭环支持。随着在业务中台基础上发展出相似业务，需要平台级的移动端开发支持。继续深化发展可能还需要支持多业态。因此为快速开发移动App、H5和小程序以支撑前台业务发展所进行的最佳实践就逐渐沉淀为移动中台，如图3-12所示。▲图3-12移动中台移动App与其他前端技术比较，有其特殊性。比如移动App作为一个C/S架构，其发版模式需要通用应用市场的审核，而其客户端的更新是使用者控制的，提供远程配置、动态更新有助于控制App端。移动业务是在线业务，对网络存在强依赖，而移动链路本身的稳定性和连通率等相比有线网络有一定的不足，因此消息推送的实现需要考虑网络因素。因移动端质量相关问题，需要提供热修复等功能。对移动App本身的安全扫描和加固也是一个需要着重考虑的因素。由于前端有不同的实现技术，如果完全使用不同的开发方式，对于企业来说是重复投入，且资源和技术不能共享。因此，使用Hybrid混合开发的方式，既可以支持移动App，又可以支持H5，甚至小程序，这也是移动中台需要研究的一部分。因此，尽可能将前端组件化，比如UI组件和图表组件，在此之上组装成业务组件，能大大提高移动端开发效率和质量。4.AI中台及其他前面所提的业务中台、数据中台等都是从技术系统层面展开的中台演变。企业在进行中台建设时，容易着手的也是对技术体系的改进。但要发挥中台的能力，让中台战略实际落地到企业，并为企业的业务目标服务，需要有与中台技术架构相匹配的组织架构。从Supercell的“部落”，比如阿里巴巴的共享业务事业部、数据平台事业部，京东的前、中、后台，大家都可以看到建设中台需要两手抓，两条路线相匹配，齐头并进。如果将业务中台、数据中台等称为“战斗部队”，那么为企业提供的项目投资管理、风险管理、资源调度等的组织中台则是“战场指挥部”，指挥前线，调度后方。“大中台，小前台”这种组织形式，并不是什么新鲜事物，实际上它是一种理想化的支撑模式。前台业务足够灵活，配套支撑足够快捷，资源还能够高效复用。不过要让中台模式在企业中发挥作用，对企业本身也是有一定要求的，比如企业有一定规模，业务比较丰富，值得去提炼共性元素形成共享能力。如果同时开展多种相类似的业务，那么从业务A提炼出来的能力可能提供给业务B使用；或者虽然业务单一，但同一业务在不同地域有不同的模式，也能沉淀出很多共享能力。数据中台提供了数据分析报表来响应运营，并在此基础上提供数据能力直接服务于业务。那能不能更进一步，提供诸如个性化服务等与智能相关的能力？答案是肯定的，通过AI中台就可实现。AI中台借助数据中台的能力，尝试解决模型的训练、发布，智能服务的构建自动化，统一的元数据管理体系，模型的全生命周期管理等问题，通过AI能力平台化，降低对人员能力的要求。与数据中台利用CPU级别的资源不同，AI中台需要扩展对GPU资源管理和整合能力，为算法模型的开发者、训练者、标注管理者、数据管理者等构建智能服务的人员服务，并最终为业务人员提供智能化的服务。03中台与前台的博弈中台通过提供基础服务和解决方案为前台业务应用提供服务。中台的职责是不断提升整体平台的服务能力基线。根据中台对前台业务的支持与参与度不同（见图3-13），会产生不同的中台建设路径。▲图3-13中台对业务的参与度一个极端理解是中台是工具，即将中台作为工具平台来建设。由于工具的通用能力强，抽象层度高，所以工具可适应各行各业的企业。如此，中台的研发人员可只专注技术相关的问题，而无须关注和了解企业本身的业务。但是正由于工具无法深入业务场景，也不内含业务能力，导致中台不能沉淀业务，从而使中台开发人员与业务方沟通不顺畅，中台方无法直接为业务赋能。为了解这个问题，需要一个长期的业务理解和系统建设过程。另一极端是中台完全为业务服务。中台方能快速理解业务需求，参与业务方的数据模型讨论、流程设计等，并将其变成系统实现。中台研发人员参与业务建设，符合中台为业务服务的目的，而且中台的能力也是通过业务沉淀下来的。但是过分关注业务，过分与业务团队耦合，会受限于时间和团队的能力，不仅中台可能会没有考虑通用的业务能力，也会导致无法更专注于对中台技术的深入研究。中台如果不从抽象度、适配性等角度出发，投入建设机制性的工作，很有可能局限于某单一业务，导致中台无法很好地适应其他相关业务的要求，从而不能很好地应对业务的变化。目前很多宣传中描述的数据中台走到了图3-13所示的最左侧：把数据建设的工具称为数据中台，或把数据治理、数据建模等工具宣称为数据中台（其实只是片面地在理解数据中台）。中台最主要的能力是提供业务方可重复使用的并与业务相关的能力。数据工具的能力太泛化，会导致与业务方的距离太远，从而不能很好地为业务方赋能。从历史发展来看，一开始企业建设了一个前台应用A（如图3-14所示）。随着业务的发展，扩展到类似的业务，由于业务快速发展的需要，很有可能重新开发另一个前台应用B。但随着应用B的建设，发现应用A和应用B的很多功能和能力是重复或相似的，因此考虑是不是可以通过建设公共的部分，避免重复投入和建设。由不同前台应用抽取出来的公共部分即为中台。▲图3-14中台与前台应用的关系但是中台建设是一个新的命题，需要更强有力的团队，需要不断探索。如果中台研发团队的研发能力和时间进度无法跟上前台业务的需求变化，那么中台就只能满足部分前台业务的需求。再者，如果中台的抽象程度低、扩展性差，则会导致中台无法满足前台业务需求。这时前台应用又因为业务本身的发展目标和压力不得不自行组织团队完成这部分功能，由此可能发生本应由中台提供的能力却最终实现在业务应用中。中台越做越小，前台应用越做越大。这样一来，进一步压缩了中台的生存空间。因此，中台既需要满足业务的需求，但又不能过度参与业务。中台能力的建设首先要保证投入到中台的资源不能成为业务建设的瓶颈。中台提供的能力要具有灵活性和可定制性，便于业务方根据规范自主完成，减少沟通成本，提升效率。“大中台，小前台”，并不意味着前台不重要。相反，建设大中台就是为了更好地服务于小前台。大中台要想发挥作用，体现出自己的价值，必须通过小前台的引导。因此，判断中台建设是否成功的指标应包括：前台有没有使用中台，前台从使用中台中获得了哪些好处，中台好不好用，愿不愿意继续使用中台。04中台的进化策略虽然中台概念的提出到现在仅几年时间，但中台已经在这几年中走出了自己的路径。根据中台的进化和演变的历史及可能的方向，目前可以看到共有广度和深度两种途径，如图3-15所示。▲图3-15中台的广度和深度两种进化策略广度是指中台所涉及的内容会越来越多，即可以认为各种中台的不断出现，也可以认为是一个中台内部的共享服务中心会不断横向扩展，从一开始所提的业务中台、数据中台，逐步演化到AI中台、技术中台、研发中台等。另一方面，一个中台范围内的共享能力也在扩展，从用户中心、交易中心、营销中心等扩展到内容中心、工单中心、成长中心等。中台团队如发现某一前台业务模式很好，则将其沉淀为共享服务，从而提供更多的业务，这也是在建设和加强中台。由于中台作为中枢点同时支撑多个前台业务，因此中台成为打通前台业务的最好着力点，让不同的前台业务可以互相借力和引流，互相促进发展。中台所沉淀的共享服务能力并不要求支撑所有前台业务，只要有多于一个前台业务需要某一种能力，此能力即可沉淀为中台能力，因此我们不能大而全地建设中台。如果企业认为现在企业各系统的用户管理能力需要统一，那就可以着手进行用户中心的建设。在此基础上，如果企业发现会员需要统一管理，订单需要全局视图，那么就构建会员中心和订单中心。因此，中台的建设是可以分阶段逐步实施的，无须将所有重构全部一起推动，而后者既会增加复杂性，又会提高风险，还不能及时得到反馈。中台的成长离不开前台业务的创新。只有不断进行业务迭代和更新试错，对中台提出新的挑战和沉淀，才会让中台做得更好。另一方面，中台团队也需要有自己的产品化、平台化建设思考，并作为新业务的孵化器。中台还需要建设成为开放的体系。开放不仅仅是对企业内部开放，也要对企业外部开放。通过中台建设，企业可以将自有的系统变为开放式平台，从而为其他企业充分提供第三方的数据和服务。再者，中台本身通过开放也可以充分利用其他第三方数据和服务。开放可以接口的方式，通过开放API，开创新的商业机会和应用模式。中台的开放也意味着中台需要支持个性化需求。通过抽象能沉淀共性的流程、数据模型等。但不同业务总有不同点，这些不同的需求就需要个性化的支撑。中台和前台一般是由不同团队负责的。因此为了提高效率，中台必须留出足够灵活的扩展点，以便不同前台业务根据其需求进行定制化扩展。中台作为平台，必然需要考虑拆分整体应用形成业务组件，通过业务抽象建模，解决共性的问题，从而更好地为业务服务。对业务问题的抽象程度越高，中台对业务的适配度就越高，需要对具体业务参与度就越低，从而更能发挥中台及中台团队的价值。因为越好的抽象越能发挥业务应用开发的创造性。在考虑拆分的同时，必须设计整体框架和组装策略，即组件间的协作机制。通过协作机制，才能让各业务组件协同实现业务场景以达到业务目标。中台作为一个平台，其本身的运营也需要数据支撑。比如需要统计和观察中台以API形式提供的共享能力，从而了解中台哪些能力被业务引用及引用的频率，所使用的参数模式等；哪些设计的接口能力没有用处等。有了实际的数据，可更好地迭代中台。3、中台如何助力标准化业务？中台关键要快！

中台解决什么问题？中台解决什么问题，甚至比“中台是什么”更重要。快速支持新行业，复用成熟行业方案！全面创新型业务一个字，快！之前用多少时间上线，现在用多少时间！How的部分，链路业务流程串接》平台工作流》功能域扩展点思考题：业务流程编排的用户是谁？全景视图对应的团队有几类？业务身份如何定义？从垂直行业的烟囱型架构或者平台型架构开始演进多个交易系统、营销系统、商品系统对了，康威定律要注意中台建设需要对应的组织结构，有人说是一把手工程，有人说是CTO工程。简而言之，需要有人拍板，该合该分，有人有粮。留下了疑问，什么是好的数据中台！4、中台将使IT成为业务变革驱动力|一周一晖1、互联网公司最大的特征是共享和开放。互联网中台的建设，本质上就是让企业的数据，对内达到共享，对外达到开放，从而变成一家互联网企业。共享和开放，是建设中台的目的。但是，中台建设完成以后，企业能够得到的，不仅仅是共享和开放。

我从事信息化行业整整20年。这20年来，我看到一个很奇怪的现象：老板对于自己企业的信息化永远都不满意，总觉得别人做得比自己好。当然，这里面的原因有很多，人的问题、变革的问题，也有很多老板总是觉得别人的东西比自己的好等等，在这就不多展开了。但是，从根本上来分析，其最大的原因是业务对于信息化的要求越来越高，而IT部门从根本上来讲，是一个服务部门。以现有的信息化建设水平，根本就跟不上市场的变化。中台是另外一种思路，其实不管市场怎么变化，有很多东西还是不变的。比如说交易，始终是什么人花了多少钱买了什么商品。那些电商、微信、抖音，唯一变化的只是渠道而已。在中台的建设路径上，有一个订单中心板块，所有的订单都会集中到订单中心。门店卖出一件商品是一个订单，淘宝卖出一件商品，也是一个订单，所有渠道完成的交易都是订单，只是订单的类型不同。另外，还有一个渠道中心。天猫店、京东店、微信商城，都只是一个渠道，和线下门店没有区别。说到底，中台就是把那些不变的、共性的东西提取出来，放到共享中心。至于各种前端五花八门的逻辑，促销、各种玩法，都成为了应用层面的一种变化。也就是把业务分层，基础不变的放在共享中心，其他都在一个个APP、网页、小程序上，但是数据是一体的，之前是一个一个独立的系统，现在是一个统一的标准、统一的数据，加上各种各样灵活多变的小应用。在这样的基础上，IT将从服务的角色变成一个业务支撑平台。所谓IT搭台，业务唱戏，IT真正能够做到赋能业务。在未来，IT的角色将发生巨大的变化，将从服务的角色转变为运营的角色，将成为整个业务变革的驱动力。

当然，中台不是那么容易建设的。投入大，周期长，往往其效果也不是立刻就能展现出来的。好在现在很多企业已经看到了当前的问题，义无反顾地进行了中台的建设。现在中台的思想是如此地深入人心，大家都认可是信息化的未来方向，但是现在市场上有太多容易让人混淆的声音。基本上每一家软件公司，如果软件不是个中台，都不好意思对外宣传。现在外面有各种各样的中台，比如进销存中台、电商中台、全渠道中台……这些无非就是把以前的系统改个名字叫中台。有时候我们听到有客户说他们要上全渠道中台，我们都有点百口莫辩……如果你听了我这三期的节目，就应该理解所谓全渠道中台这种叫法本身就是错误的。电商、全渠道都属于一种应用，不用中台的技术，也能做出全渠道。如果建设好了中台，全渠道是顺其自然的事情。全渠道、电商和中台是两个不同维度的概念，前者是应用，后者是技术架构。打个比方，烧个菜，叫番茄炒蛋，番茄和蛋都是菜，这个没问题。但是如果说要烧个菜，叫番茄炒电磁炉，这就不符合逻辑了。

中台是一种IT架构，是一种信息化建设的思路，一种方法论，一种思想，甚至是一种哲学，唯独不会是一个应用。所以，在这里，我特别想和大家澄清一下，以正视听，可能会得罪一些友商，但是不吐不快。如果有人找你，给你提一个全渠道中台的方案，你应该坐下来，喝口水，心里默默地说：忽悠，接着忽悠！5、怎么建设中台。业务中台和数据中台的组织、支撑技术和方法论例举典型的需要建设中台的场景，供参考判断要不要建中台。建设中台需要考虑组织、技术支撑和方法论，往往还需要咨询服务的帮助，本文可以作为思考中台建设的大框架。什么情况下可以考虑建中台，如果要建要怎么建的问题。要建设中台，首先要考虑要不要建设中台。话说的这么绕是因为现在有很多不明就理就想建中台的。这个问题先做个初略的判断。1要不要建设中台对业务中台来说，比较符合的场景主要有：业务系统研发团队至少大几十人以上（含外包的），需求多变化快，系统又涉及多个领域（比如做ERP、电商的），业务逻辑比较复杂。这时业务中台可以把系统和业务领域划分清楚，提高研发效率。做相似行业的外包项目为主，业务规模也做的比较大的（一年有两位数的项目）。这时业务中台可以提升软件复用，降低定制化成本，提高研发效率。如果你做外包，每个项目都完全不一样，那中台也救不了你。此外还有以下场景可能不需要建设完整的中台，但适合落地与中台相关的微服务技术的：大规模互联网式在线系统，对稳定性和弹性要求高当前搞不定的。微服务或业务中台可以比较好的解决这些问题。掉到IT竖井的坑里想爬出来的，通过项目外包做的系统无法管理和维护的。微服务或业务中台可以对系统的API、文档等进行有效管理，也能实现系统间的打通。对数据中台来说，比较符合的场景主要是数据产品比较多，每天要看数据如果没数据就不知道怎么工作的运营人员比较多的业务。比如电商就是典型。如果这些数据产品和运营人员还在多个团队，那基本上数据中台没跑了。如果经常出现指标不一致、数据出错、想要的数据不知道哪里有等问题，那基本上数据中台也没跑了。并不是数据量大就需要建中台，主要还是看用数据的姿势是不是比较复杂，当前问题是不是比较多。对于这类符合的业务，数据中台能把层层数据直到最上层的指标梳理清楚，提升数据质量，从而提升运营效率。把数据理清楚了，往往还能降低数据存储和数据开发人员的成本。除了上述判断，还有一条是同行对比。如果一个行业大家都有点跃跃欲试想弄中台，那领先者一定要想办法抢先（既然是领先者了，往往也符合上述标准），不然就可能被颠覆。跟随者要不要想办法抢先从而超越领先者呢？可能不好说吧，但如果领先者已经建了，跟随者一般得紧跟，否则真可能被甩开了。如果根据上述逻辑觉得大致要考虑去搞一把中台的话，那请继续读本文以下内容，读完本文后续内容然后更具体的看看问题存不存在，条件是否具备。要建设中台，需要考虑组织、支撑技术、方法论这三个方面，往往还需要咨询服务。2组织中台作为一种有业务属性的共性能力，首先就需要一个懂业务、承担业务职责的专职的组织机构来负责。要不要建中台，首先要看领导有没有魄力去整合建立一个中台组织。因为原来的平台部通常不懂业务，懂业务的人各自分散在前台业务部门，所以建立中台组织往往涉及人员、组织架构和部门职责的调整。正因为如此，中台的建设往往需要作为一把手工程才能成功。中台组织关键要懂业务和承担业务职责。举个例子，一个大数据平台的建设运维团队不是一个中台组织。一个团队如果做了非常完善的中台产品（如开发了数据中台所需要的指标管理系统、数据仓库开发系统、数据质量管理系统等等），但只是把产品提供给业务方使用，这个团队仍然不能说是中台组织。只有当这个团队承担起指标体系的建设和管理、数据仓库的设计和实施、数据质量的保障等工作时，才可以说是中台组织。而要做到这一点，这个组织肯定是比较了解业务的，它的目标和考核也一定与业务有相关性（肯定不只是平台稳定性这样的非业务指标）。中台组织的层次与中台的层次最好是对应的，BU级的中台组织最好直接向BU老大或分管的CXO汇报，企业的中台组织最好直接向CEO或分管的CXO汇报。这里特别说明一点的是如果不建设在线业务中台，而只是采用微服务、云原生这些敏捷研发技术的话，可以不涉及组织方面的变动，就在原来的研发部实现转型。通常来说也可以实现一定的系统可用率、弹性和研发效率方面的提升。3支撑技术建设中台一般需要一套支撑技术。3.1、在线业务中台支撑技术建设在线业务中台一般需要云原生、DevOps、微服务技术体系的支撑，这是因为：微服务技术：中台是一个独立的组织负责并为多个前台业务服务，因此需要一个标准的服务接口、成熟的服务治理能力和高效的敏捷研发技术。在当前的技术环境下，采用地球人都熟悉的REST风格的同步API、消息队列异步通信作为标准的服务接口技术，采用服务框架（如SpringCloud等）、API网关、APM等作为标准的服务治理和敏捷研发技术是最合适的选择。不再建议采用传统的基于ESB的服务化（SOA）技术，因为ESB产品过多的介入到业务逻辑中，导致前台业务的变更往往需要中台团队的配合才能完成，这样就失去了建设好中台，支撑前台高效创新的意义。此外，中心化的ESB软件和复杂的基于XML的WS-xxx等协议也影响到系统的可用性和性能。可以参见MartinFowler在PofEAA中的评价，WebServices是应用集成而非应用开发的技术。DevOps技术：如果不通过DevOps使得各微服务都能自助式的部署更新，则微服务带来的敏捷性就无从发挥，反而因为服务数量的增加导致研发效率的下降，因此持续集成、持续发布等DevOps技术一般是实现微服务的必备。云原生技术：微服务和DevOps要求底层的基础设施是灵活可编程的，否则根据Amdahl定律，只要有一个必须的环节是低效的，整体的效能也提不上去。

需要强调的是中台要敏捷，这一方面是因为中台具备业务属性，且支撑了非常丰富的前台业务，前台业务的敏捷性要求有一部分就会传导的中台层；另一方面是中台的重要性使得其需要持续不断的优化，即便对外提供的服务不变，内部实现也会经常变。分布式事务技术：实施微服务拆分后，复杂的业务流程不再能通过数据库的事务机制来实现ACID特性，为此还需要服务层面的分布式事务处理技术。典型的分布式事务处理模型包括TCC、Saga、FMT等。其中TCC和Saga需要各服务实现定制化回滚逻辑，侵入性比较严重，用起来门槛比较高。FMT模式对于Java可以做到加一行注解（如@GlobalTransaction）即可实现分布式事务，剩下的由框架自动处理，用起来方便的多。Saga模式是Princeton的两位研究者在1987年提出的，灵活性和并发度最好，但需要通过语义锁等精细的设计才能发挥出来。由此可见，在线业务中台的技术支撑体系是相当复杂的，所幸的是Netflix、Google等世界领先的互联网企业由于自身业务需要打造了很多实用的技术模块，开源社区也贡献了不少力量，CNCF组织又做了很好的汇集和标准化。通过将相关技术加以整合，已经有了不错的产品可用，如网易轻舟微服务就是一套产品化设计良好、功能丰富的在线业务中台支撑技术产品。一般而言，前台也会和在线业务中台一样采用云原生等同样的技术体系，这是因为前台更需要敏捷性。在完善的中台支撑之下，前台会比较轻，还可以考虑采用FaaSServerless技术，不过目前这方面的实践还不多（特别在中国），相关的支撑技术也不是很成熟。3.2、数据中台支撑技术建设数据中台一般需要一整套如下典型的支撑技术：指标管理系统：指标是中台与前台之间最关键的接口，也是建设数据中台的牛鼻子，因为它是最核心的业务语言，且指标不一致、数据常出错是建设数据中台最常见的出发点。如果指标体系没有统一的方法论，进行统一建设，那么就很难说是数据中台。指标管理系统一般要实现一套一致的方法论（如原子/派生/复合指标、维度、修饰词等），做好指标的业务和技术口径管理，还需要支持指标的审批管理。数据中台的指标无法交给各前台业务自助式的建设。数据服务系统：类似于在线业务中台需要通过API网关提供标准化的服务，数据中台也需要一个标准化的服务方式，通常称为数据服务系统，也可以说是数据网关或数据门户。类似于别的网关类产品，数据服务系统需要提供鉴权、日志审计、流控、协议转换（如SQLDialect之间的转换）等功能，也应该发展多引擎融合查询、逻辑模型等扩展功能以提高服务接口的稳定性和实现的灵活性。元数据管理系统：元数据管理是整个数据中台的基础和中心，所有的其他系统都依赖元数据管理。元数据管理首先要做好的当然是数据模式或目录（catalog）的管理，至少要知道中台里都有什么数据。对复杂的数据中台来说，数据血缘也很重要。没有血缘信息，不知道数据间的依赖关系，数据质量肯定管不好，因为不知道一个数据的质量问题怎么来，又进而会影响什么。同样的如果没有血缘，数据资产也肯定管不好，因为不知道什么数据有价值什么没价值，这就像如果你不知道一个函数被谁调用，你就不知道它是不是死代码一样。元数据管理系统往往也需要提供一个基础的访问界面，通常称之为数据地图。数据仓库开发与管理系统：除了指标管理，数据仓库的开发是将一大堆初始数据建设梳理成一个漂亮的数据中台的核心过程。一般来讲数据中台更适合用Kimball的维度建模方法而非数据仓库之父BillInmon所提倡的方法，这是因为Inmon强调顶层设计，而Kimball强调至下而上。如果要建设数据中台，肯定是因为前台业务复杂多变，这时强调顶层设计会导致中台建设缓慢、僵化。因为中台虽然应该是由组织高层决策，但目的却是为了支持前台业务，而不是为了控制。*支持而不是控制*，这一点绝不能本末倒置。数据质量管理系统：所有复杂的系统都需要专业的质量管理，在线业务系统有一系列的弹力设计和APM等监控运维工具，数据中台也需要专业的质量管理。数据质量管理系统通常设计为支持丰富的稽核/校验/比对规则，监控数据是否准确、实时、一致，还要做到及时的报警，分析影响面，提供快速修复的手段等。但这些手段只能发现和补救问题，不能预防问题，要预防问题，还要通过测试工具减少代码bug、通过资源弹性应对性能波动、通过优先级调度优先满足重要业务需求等。相对来说，当前数据中台领域的质量管理没有在线业务领域的成熟，如在线业务领域的测试手段远比数据领域的精细，在线业务领域很常见的熔断、限流、服务降级等模式在数据领域都没有成熟的实践方法（优先级调度可以说是实现了部分的服务降级功能），随着数据中台越来越广泛和重要，这些技术应该也需要持续发展，但技术上的挑战不小。数据安全管理系统：数据中台因为汇集了组织所有有价值的数据资产，因此良好的安全管理是必须的。细粒度的权限和审计是基础，一般的还需要隐私/敏感数据的脱敏处理、数据加密（特别是将数据托管在第三方平台之上时）、数据泄漏防护（比方说一种常见的方法是限制将数据下载到本地的数据量）等技术。发展到高级阶段甚至可能还需要联邦学习、数据沙盒等技术。数据资产管理系统：在数据质量和安全单列的情况下，数据资产管理主要负责的是数据的生命周期管理、成本的统计分析与优化等工作。同时，数据中台还需要强大的大数据计算引擎、数据集成/同步/交换引擎，还往往需要一套敏捷BI系统：大数据计算引擎：数据中台要管理的数据规模和复杂度往往都很高（否则搞中台属于为赋新词强说愁），所以传统的数据库和数据仓库基本上支撑不了。当前的技术环境下，基于HadoopMapReduce或Spark几乎是唯二的选择，当然这也包括了这两者之上的Hive和SparkSQL。能有SQL就用SQL，易于维护，也易于数据血缘的收集。除此之外，流处理可能还需要Flink，交互式查询可能要引入Impala或GreenPlum。数据集成/同步/交换引擎：一方面数据中台需要强大的数据集成和同步能力才能吸纳各方数据。集成和同步的概念相近，同步更强调实时性。另一方面，数据中台往往由多种数据计算引擎构成，就需要同步或交换引擎实现不同引擎见的数据交换。敏捷BI系统：建设数据中台通常最重要的目的是为了支持业务运营和决策，为此需要基于数据中台进一步开发数据产品。敏捷BI系统是开发数据产品快速、轻型的手段，能够尽快尽早的发挥数据中台的价值。此外，对于互联网业务，统一的埋点引擎往往也是数据中台所需要的。如果埋点的逻辑都不统一的话，建数据中台的时候会发现数据的源头就是乱的，后续也都没法做。其他行业业务，数据采集也属于基础工作，也是要先做好的。由此可见，建设数据中台需要的技术支撑体系也是相当的庞大，复杂。所幸的是这十年来Google等领先的企业、Hadoop/Spark等开源社区以及大量的产商大致联合探索出了一条可行的路径，方法论和技术路线都比较统一了。以此为基础，就可以提供较成熟的数据中台技术支撑产品，如网易杭研研发的“网易猛犸V6.0+网易有数”就是一套较完整的数据中台产品。4方法论复杂事务都需要方法论的指导（和约束），组织管理有虚虚实实的一大套各种理论，研发有敏捷方法或IPD流程，中台是复杂事务，所以也需要方法论。因为中台建设涉及组织和技术两个维度，所以中台的方法论也应该要覆盖这两个维度。目前而言，技术维度的方法论相对成熟，因为复用了很多原有的方法论。4.1、在线业务中台方法论对于业务中台，微服务、网关、RESTAPI及语义化版本控制、六边形架构是侧重于技术架构的方法论，DevOps、敏捷项目管理是侧重于流程层面的方法论，领域驱动设计（DDD）是侧重于业务架构的方法论。要做好业务中台，以上方法论大概都不可或缺。大家可以看到，除了微服务跟中台大致是同步发展的之外，其他方法论都是早前就存在的东西。正因为有这么多合适的方法论存在，中台才变得可行，无论如何在短期内要发展出这么多方法论是不现实的，因为方法论的威力不仅在于它要好，还在于它要流行。技术架构和流程方面的方法论已经很流行，无需多说（六边形架构放在和DDD一起介绍）。值得关注的是领域驱动设计这么一个10多年前就被提出，这么多年一直不温不火的方法论，突然在中台领域似乎找到了它的最佳安身之所（也可以说中台找到了DDD这么一根救命稻草？）。这样的现象是会昙花一现，还是会长期持续，值得思考。DDD的核心概念是通用语言和限界上下文。通用语言指的是在一个业务领域内通用（但不是在更大的领域内也完全通用的）的概念、术语等语言，限界上下文指的是相邻通用语言之间“翻译”的边界，比如前台业务的用户可能要变成后台清算的客户。我觉得DDD的通用语言和一直以来的领域建模是比较相似的，更具创新意义的是限界上下文。在架构设计中，我们要不要构造那种拥有非常多属性，但每个使用者只使用少量属性，或者属性的名称和含义对使用者来说不贴切的对象？如果没有限界上下文的约束，可能会认为这样毕竟实现了更多的复用，是好的，但用限界上下文的理念来看，这样很可能是不好的。每个领域应该专注于自己领域的语言，领域之间要交互怎么办？加一种翻译机制，也就是限界上下文解决。领域驱动和限界上下文的理念会自然延伸出六边形架构的设计。所谓六边形架构指的是一个程序的内部只需要处理业务逻辑，他的数据/请求从哪里来，数据要存储到哪里去（或者领域事件要发布），都通过各种适配器完成。因为这样的适配器可能较多，就不再像传统的三层（三明治）架构。不过如果六边形只有一个Input和一个Output适配器的话，和三层架构就还是差不多的。我想从三层架构进化到六边形架构的主要原因还是因为现在的环境已经从传统的C/S或B/S这样只有一个前端，也只有RDBMS这样的一个后端发展到前面有Web/移动等多个端，向后也有RDBMS/NoSQL等多个端，横向也有服务化/MQ等多个端的多端环境。我不知道哪天会不会发展出一个十面埋伏架构出来。4.2、数据中台方法论数据中台的方法论也是博采众长，最核心的来自于数据仓库领域关于数据仓库规划实施和指标体系建设的方法。在数据仓库领域，有两套截然不同的方法之前一直是较劲的，一个是数据仓库之父BillInmon所倡导的至上而下的方法，另一个是另一位大师级人物Kimball所倡导的至下而上的方法。在我理解，所谓Kimball的模式之所以说是至下而上，是因为基本上中台团队只负责从ODS到DWD到DWS就完了，往上就是所谓的ADS，其实已经是面向各个业务（或者数据产品）了。你都可以说ADS层不属于数仓。这样的方法在中台作为一种新生事务没法有很强的话语权时显然是更容易做出的选择，可能未来中台概念深入人心，集团高度重视，说不定Inmon方法又会重新流行？但也可以思考这种细节上都体现了领导的管理意志的中台还是中台吗。指标设计的方法论基于Kimball方法中的粒度建模的方法，做了比较大的细化和改进。划分主题域是建数据中台的常见实践，不过主题域划分与行业强相关，比如对零售业常见的有商品、交易、流量、用户、营销等域。数据中台统一通过数据服务系统实现OneService的设计，不清楚有什么来源，不过类似于在业务架构中很常见的网关模式。数据质量、数据安全、元数据、生命周期管理也都是数据治理领域比较常见的概念，但一方面要实现针对大数据技术环境的落地，另一方面更面向业务支持而非管控来设计。实施数据中台通常还需要制定很多规范或标准，这也可以说是方法论的一方面。有很多规范是命名规范，其中数量最大的往往是数据仓库中的表，上万张表甚至更多都是很常见的，所以表的规范命名非常必要。一种好的表的命名规范，要反映其所在数仓分层、主题域、业务过程、时间周期等信息。计算任务也需要一定的命名规范。数据埋点也需要规范性的编码位置信息、内容信息和事件信息。4.3、组织维度的方法论及其他其他类型的中台也都有各自的方法论。如搜索中台，百度有比较详细的对外分享的资料，其方法论主要体现在规范了搜索系统的关键流程，如内容引入和加工、离线训练、在线召回和排序等，还会涉及到查询改写、展示设计等要点。以上说的都是中台技术维度的方法论，组织维度的方法论目前还没有看到好的系统性分析成果。在阿里中台蓝宝书（《企业IT架构转型之道》）中只有很少的篇幅介绍中台组织维度的方法论，在另一本阿里讲数据中台的书中，干脆就只字没提组织方面的内容。阿里关于中台组织的方法论，主要包括多职能小微团队、业务架构师主导、协作沟通机制、轮岗、共建、考核机制等。业界也有从一般性的组织管理维度（如垂直型组织、矩阵型组织等等）分析，过于宽泛，说了等于没说。中台组织层面的方法论可能是相对不成熟的，比如中台和前台、平台之间的边界和动向问题，似乎没有明确的方法。我认为可能主流会符合“前台->中台->平台“单向流动的中心法则。可能中台组织的终极目标是发展为平台，因为还是要追求把能力做成熟和标准，我这也可能是很反动的说法。作为集团的创新业务孵化中心，网易杭研每时每刻都针对很多业务线要并行发展，为此打造了一个又一个共享能力中心，千方百计提升创新效率。12年来感觉摸索了一些关于中台的建设经验，当然可能更多的是教训，这段经历的体会后续我将会做个梳理，发出来供大家讨论。5咨询说到咨询，我首先想到的是技术进步的驱动力发生了很大的变化，从厂商和咨询公司驱动变成了领先客户驱动。以在线业务为例，传统的SOA和WebServices技术是IBM、BEA等厂商驱动的。厂商自己不用产品但要卖产品，所以一不小心就把产品搞的不必要的复杂。另外厂商和咨询公司本来就是共生共荣的关系（像IBM咨询和产品都做），所以也得把产品搞的复杂一点吧，不然咨询公司就没生意了。新生代的微服务技术主要是领先的互联网企业驱动的，自己造产品自己用，能简单一点就简单一点，最好是做成各个业务部门自己就能用。所以新生代的中台技术是尽力将咨询的必要性尽量降低的，但是因为当前实践中台的都是很大的互联网企业，业务复杂度不可避免的很高，对于大多数想要实践中台的非互联网企业来说，仍然是需要咨询服务。现状是，当前中台的咨询非常欠缺。因为这些中台都是互联网企业搞的，当前的厂商和咨询公司都没什么能力做这块的咨询。我们可以看到正是这些咨询公司，还是在软件咨询领域很知名的，不懂中台，把什么都往中台的概念上凑。所以这样的咨询公司能做咨询吗？自己没做过业务的厂商那就更不用提了。当前也就互联网企业或有很强互联网企业背景的团队才有能力做咨询，但资源很有限。希望咨询公司们能够聚焦于真正的中台，透彻理解什么是中台，提升自己的咨询能力。6、有赞数据中台建设实践概述究竟什么是中台,业界并没有一个标准答案,各个厂商都有自己的定义.笔者比较认可的一个定义是ThoughtWorks提出的"企业级能力复用平台".各个领域涌现出很多中台产品,如业务中台,搜索中台,数据中台等.其中数据中台这个词汇越来越多的出现在视野中,从百度指数中可以看到这一趋势.本文,介绍有赞的数据中台产生的背景和建设思路.简单来说,有赞的数据中台解决的是"有赞的数据资产的加工和复用",这里提到了数据中台的两个重要功能:数据加工和数据复用,分别由数据技术中台和数据资产中台解决.数据技术中台主要解决数据的加工问题,在众多大数据组件中,帮助数据开发者简化开发过程,提高开发效率.数据资产中台主要是解决数据复用的问题,要做到数据复用,数据口径的统一是重中之重.双管齐下,提高对前台业务的支撑效率.二.数据团队面临的挑战数据团队面临的挑战主要有两方面:业务挑战技术挑战2.1业务挑战有赞是一家服务商家的SaaS公司,服务数百万各行各业的商家,提供电商解决方案.有赞数据团队的服务对象主要是各个前台业务线,所以一切故事的开始来源于业务团队.因为业务特点决定,目前有赞的数据需求有以下特点:垂直业务线众多:有赞微商城,有赞零售,有赞美业,有赞教育等业务域众多:商品,店铺,会员,交易,支付等数据需求多样:商家后台数据报表需求,运营侧数据分析需求,大促看板需求,实时报表需求等业务需求迅速迭代:业务模型的迭代演进,SaaS领域对已有功能比较高的兼容要求等...2.2技术挑战业务线各种各样的数据需求,给数据团队提出了很多挑战,主要体现在两方面:组件多,维护成本高开发门槛高组件多,维护成本高软件行业"没有银弹"在大数据领域显现的淋漓尽致.在有赞的大数据技术栈中,针对不同的场景,分别维护着众多的大数据组件.如数据基础组件的HDFS,YARN组件;离线计算元数据组件HIVEMETA,离线计算引擎HIVE,SparkSQL,Presto;实时计算框架Storm,SparkStreaming,Flink等.这些还只是组件本身并不包括组件配套的鉴权,安全,脱敏,质量相关的服务.开发门槛高比如，针对最普通的实时计算场景，任务的开发者通常考虑以下几个方面问题:数据Source流在哪儿,如何接入数据处理后的Sink是流还是其他存储,如果是其他存储系统,可用性是怎样的,单机房可用还是多机房,扩展性怎么样,写入是否有热点,是否可以配合实时链路的并行度调整做水平扩展实时任务本身的高可用部署，监控及报警消息的一致性语义是什么(atleastonce,exactlyonce还是atmostonce),每种语义对上下游服务的要求是怎么样的实时计算任务的计算资源如何配置,水位如何,大促期间如何扩容公司内部各种各样非大数据的技术组件,如何做适配...对于没有相关经验的同学,需要查阅多种组件的文档,势必会有开发成本高的困扰.三.数据中台按照产生顺序,数据中台主要包括:数据技术中台数据资产中台3.1数据技术中台构建所以,技术上的复杂性,带来了开发成本高的问题.所以易用性的本质是为了提效,数据技术中台由一些列工具型平台构成,最主要的几部分如下:基础组件运维管控数据开发平台数据资产管理平台数据指标管理统一数据服务基础组件运维管控上文也有提到,大数据基础组件种类繁多,概括下来可以分为三类:离线计算组件(HDFS,YARN,HIVE,Spark)分布式在线存储组件(HBase,Kafka,Druid)实时计算组件(Storm,SparkStreaming,Flink)每类组件的管控需求都不尽相同,比如在线存储组件对rt,可用性要求较高;实时计算组件对延迟,积压问题比较在意;离线计算组件对数据吞吐能力要求较高,但是因为是分布式计算,所以对慢盘,慢任务需要有特别关注,否则很容易一个节点拖慢整个集群.运维管理好大数据组件,做好动物管理员,本身就是一件类似数据运营的工作,找到系统的北极星指标,关注它,使用它来帮助做系统的优化.总结下来,做好数据组件的管理需要解决以下问题:确定核心指标.需要casebycase的确认每个子系统的最核心的指标,比如对HDFS系统来说,文件数目,文件操作tps,文件操作的rt,99%rt,是否有丢块等,就是核心指标,需要特别关注.监控.采集核心指标,展现到监控上,便于观察趋势,帮助问题排查和扩容等操作的判断依据.报警.根据核心指标,确定安全水位,配置报警,缩短故障发现时间.具备一定的定制开发能力.对使用组件不要求有核心feature的开发改造能力(这不符合ROI),但是在权限/安全方面,社区版本很难满足定制需求,这就需要对基础组件做一定的改造;另外需要关注社区,对于重大隐患的bug,需要打回的公司的版本.软件发布/配置发布规范.多人协作,多组件协作,需要一个完整的开发/测试/发布流程,不止对软件,对配置的发布也一定要规范.这方面曾经踩过不少的坑.故障演练,要定期的主动对技术组件做故障演练,有些组件虽然支持某类功能,但是随着数据量,负载的不同,这类功能实际效果具体是怎样的需要通过实践来确认.比如HBase支持单机宕机自动恢复,但是宕机恢复时间究竟是多少,跟集群负载,各方面的配置都是相关的,需要通过故障演练来组件优化系统.性能摸底.需要对组件做标准的Benchmark,一来掌握系统极限,二来在业务接入时能够提供准确的性能指标,帮助业务方做选型判断数据开发平台数据开发平台关注的是数据的加工,是数据开发用户(数据产品开发同学,数仓开发同学,业务线数据开发同学)最频繁接触到的产品,数据开发平台主要包括两个平台型产品,分别解决离线和实时场景的数据加工需求.离线开发平台,主要负责离线数据的加工,任务调度,数据ETL,临时查询,监控报警等实时计算平台,主要负责实时计算任务的管理,监控报警等关于这两个平台,有更具体的文章介绍(见参考文章),这里不在赘述.数据资产管理平台数据资产管理平台主要解决数据资源的管理,数据资产遍布在各个大数据组件中,有hive的表,有hbase的表,有druid的datasource,有kafka中的流,各个组件的管控系统很难互相打通,所以需要一个统一的数据资产管理服务,来统筹大数据资源的管理.总体说来,数据资产管理平台关注的是数据的静态状态,比如Hive的库表/字段,HBase的表,Kafka的Topic.提供以下几方面的工具:数据地图(方便用户查找,定位已有的数据自产并复用)数据质量(对数据资源,根据预设的规则做质量检查,提前发现潜在问题,比如每日数据量,是否有字段缺失等,并且在数据不合格的状况下能够及时通知出来)成本核算(统计各个团队,组件的成本占用,利于做成本降低之类的优化,当数据体量达到一定规模的时候,成本问题会变的越来越重要)数据血缘管理(管理所有的数据资源的依赖关系,主要用在两个场景:a.数据问题评估,当上游数据变更或者质量问题的时候,能够快速确定影响面和修复方案.b.数据生命周期管理,当下游应用下线,不再使用某个数据的时候,能够找到不被引用的数据,及时下线,避免不必要的计算)...数据指标管理如果说数据平台关注的是数据的加工/转换,既数据任务的管理;数据资产管理平台关注的是具体的数据表和字段的质量和血缘;那么指标库管理的就是数据指标的口径统一和复用.在有赞,我们通过指标库系统来管理数据指标的口径.概括来说,数据指标被分为原子指标和派生指标.原子指标为不可再分割的基础指标,由数仓团队统一开发和管理,原子指标数据一般落在数仓的DW层.但是往往业务方需要的指标,原子指标并不能满足,所以业务方需要在原子指标的基础上再次加工成派生指标.比如交易数据中gmv是原子指标,微商城业务最近30天的gmv指标就是派生指标wsc30dgmv.关于指标库,后面会有单独的文章介绍.统一数据服务数据开发平台,资产治理平台,指标库只是解决了数据的加工和口径的统一的问题.产出的数据并不是真正对外可用的.绝大多数场景,都需要数据开发的同学,将加工后的数据,通过数据交换组件,导出到线存储服务中,然后再开发数据接口,供前台业务同学调用.这里在线存储服务到接口这一层,传统的业务支撑方式中存在大量的重复开发.针对这个问题,我们设计统一数据服务,用户通过配置模板的方式,生成数据API服务,简化开发流程.有赞的统一数据服务目前刚刚上线,已经支持10+业务场景,后面会有单独的文章介绍.3.2数据资产中台构建3.1节中介绍了偏技术视角的中台,涵盖了大数据的技术架构.但是数据中台远不止技术设施,更主要的是数据资产的建设和组织,因为对业务方而言,业务方更关注的是有哪儿些数据自产可以使用,而不是通过什么底层技术实现.大数据团队提供的数据资产主要有以下几类:离线数据资产(离线数仓)数据智能服务实时数据资产(实时数仓)在用户数目上,目前离线数仓承接了大多数的数据需求,这里仅仅对离线数仓展开介绍.离线数仓中数据的开发主要发生在数据开发平台上,包括数据etl导入任务,数据开发任务,数据etl导出任务,任务流的管理和调度.借助于指标库和数仓开发规范做数据的加工.整个开发过程中,数据开发平台,数据质量管理,指标库平台会通过对命名,指标的查重等手段来强制一些开发规范的执行,从根本上解决数据指标口径一致和数据复用等问题.有赞离线数据资产如上图中蓝色部分,从底向上分为三层:公共数据层公共数据层主要承载数仓建模中的ODS层和DW层,数据的开发和口径管理由数据仓库团队负责.数据的开发和口径管理严格按照数仓开发规范和指标管理规范,提供公共的原子指标的开发.垂直业务域数据层垂直业务域数据层,该层在数仓建模中的DM层,数据的开发和口径管理由业务方的数据开发同学负责.业务方同样根据数仓开发规范和指标管理规范,完成派生指标的开发.数据服务层数据在离线数仓中开发完毕后,通过数据开发平台的ETL导出任务导出到在线存储层,然后自行封装或者通过统一数据服务,提供在线数据接口.这一分层在实时数仓中同样适用,本文不展开三.总结&展望有赞数据中台并不是一蹴而就,而是面临着业务和技术上的挑战逐渐成长到现在,当然还有很多待完善的地方,比如指标库,统一数据服务还处于刚刚起步阶段.后面有赞数据中台的建设将主要集中在成本,数据资产管理&复用,实时数仓等方面发力,帮助我们的商家和业务方挖掘更多数据价值.文章由微信公众号文章搜索助手导出，点我免费下载7、有别于BATJ，滴滴的中台数据体系建设怎么另辟蹊径？分享概要1、滴滴数据中台发展2、滴滴精益数据管理体系3、滴滴数据系统组成4、中台是买不来的前年阿里开始讲数据中台业务，去年以来这个概念很火直到最近。我在阿里待了10年的时间，也参与了中台建设，今天想跟大家分享一下背后的逻辑，还有我在滴滴的实践，以及中台本质的问题是什么。今天我的题目叫做“精益生产与敏捷创新”，任何一个中台，不管是技术中台、AI中台，本质上为了更好支撑业务，让业务能够更好的去把用户价值做出来。从技术角度来讲创造价值的核心就是两点：保证稳定且持续的研发生产持续输出既有价值；在生产过程中去找到可以改进的地方，找到新的创新点，创造更大的新价值。一、滴滴数据中台发展看几组数据，这几组数据看起来挺大的，但目的不是为了吹牛逼，目的是为了讲这个东西。其实滴滴也好，阿里巴巴也好，这些大公司数据都经历了四个阶段，每个阶段有不同的挑战，相信在座的同学不同公司也处于不同的阶段，或者说有可能也走到了这四个阶段的下一次循环。1、业务发展驱动数据进化 1）业务信息化其实滴滴很幸运，正好赶上了移动互联网那一波，把个人的位置信息进行信息化了，同时智能手机价格急剧下降，从四五千到几百块钱，任何一个群体都能买到智能手机，最大的核心变革是什么？你的位置与状态随时随地都在线，这就是完成了第一个核心业务的核心化，滴滴赶上了这波一飞冲天。2）信息数据化第二波当业务构建起来各个地方有数据被记录下来，如果10多年前有同学在做数据，当时肯定会去跟DBA吵，你这个数据量太大了，DBA肯定会说：你删数据吧。因为以前很多的数据是存在数据库里面的，而从2006年开始从记录事务本身到记录过程。这个背后的核心是什么？背后是逻辑范式的变化，因为有了互联网。互联网之前所有的交流、互动其实是中心节点下面有很多小节点单独跟他沟通。比如说我去和银行办业务，我去打电话给某一个人都是这样子的，最多一对N，互相之间是没有别的互动，去银行办各种业务，顾客间是没有互动的。但是有了互联网之后，所有的节点之间是可以被连通的，所有的节点是可以被连接的，所有的信息从记录的节点上变成了这个信息是记录到边上，这种范式变成了什么呢？数据的量巨大膨胀，这个时候面临最大的问题是算不动存不了，包括我们在讲很多的实时计算也是一样的道理，随着我们的业务发展、人是需要实时进行反馈，那就意味着实时计算需要的计算能力和存储能力变成更大的问题，当信息变成数据化之后一定会有这样的情况。当有更多的数据被记录下来的时候，数据不再仅仅是BI，意味着每个人开始去用数据，每个人用的数据很有可能自己产生的结果，同时是别人的输入，这个时候就意味着一张公司里的数据网开始在编制起来，或者说最简单的数据链条在编制起来。这个时候会出现很多扯皮的事情了，上游说自己解决自己问题，数据的问题是自己用的，为什么要给你用？你依赖我的数据就依赖，出问题我不负责。被依赖很多上游说要改一个东西，下游说不能改，你改了，所有的代码也得改。上游说不改怎么行呢，上面的业务要变。这个时候数据用的越多，扯皮事情就越来越多，为什么会扯皮呢？不是大家什么有问题，而是公司里面没有数据的文化，我们核心判断这件事情谁对谁错的价值观，背后唯一判断标准是什么呢？很多公司是没有的，因为数据越多，产生出来的各种扯皮就出现了。3）数据资产化这样就到第三个阶段，每个地方都有大量的数据，每个业务都在消费大量的数据，广告业务、运营、财务、现在还有越来越多的算法、人工智能，各个地方都在用数据，每个部门都有数据，每个部门都有自己的数据团队，这个时候开始烟囱林立。有些时候数据在一个地方用的好，可能在别的地方用的不好。当年在阿里的时候，2012年左右的时候最大的问题，怎么把消费者的数据打通。因为不同的业务环节里面同一个消费者ID可能都不一样，到滴滴后来也面临同样的问题，快车、顺风车、出租车快速的发展，从来没有考虑过数据打通问题。每个部门都觉得数据是自己的私产，我对这个数据质量保证只为自己负责。数据资产从公司角度来讲它是没有被盘点的，只在点上产生价值。在滴滴我们是面临强监管的公司，可能在别的公司大家没有受到这么强的监管。所以数据本身的安全合规对于我们讲是非常重要的事情，还好2017年加入到滴滴，对这件事情的重视程度比较高，第一个解决了隐私数据的处理，第二个数据分级管控，第三个数据的安全打标，还有关键的权限管理。最近我跑的公司也比较多，发现做一些互联网金融类的公司内部的数据都没有做权限管理，这是非常恐怖的一件事情。第三个一定得有对应的安全合规管控，这样公司才能走的长久，不然数据做的越大，很有可能就成为公司归零的大风险。第三个是数据资产面临一个问题，可能这个资产在很久之前很多咨询公司会讲一个东西叫做数据治理，包括像最近的G20各个政府的首脑也提到这个问题，数据越来越重要，数据需要流动起来才能产生价值，如果不把它标准化好，数据的价值是很难打通的。但是我们可以发现很多的企业去做数据治理的时候，这个项目都是无疾而终，或者做了项目很好，但是用着用着这个数据又不行了，不得不过一段时间又提一个大项目劳民伤财来去做这件事情，背后本质上的问题是什么呢？为什么数据治理这件事情这么困难，投入这么大资金去做，但是产出却很少，而且数据是越治一会儿又难用了，能不能让这个数据越用越好用呢？我们发现背后还是一些本质上的东西去用的。我们都在讲用大数据去赋能别人，大数据去做广告，大数据去赋能AI，让AI更高效解决各种问题。但我们有没有想过我们用数据能治理自己本身呢？这也是我们当时的思考，我们重要核心问题在数据资产化这个阶段要解决两个问题：数据质量混乱的问题；另外一个，高投入低产出问题，我好像做了标准化的事情，做了治理的事情，好像不太管用。最后，当数据梳理通顺了，这个资产在公司里面流动起来，大概在2018年左右滴滴所有的数据在内部都是开放的，当然是分等级的，需要走相应的合规申请流程，每一个人经过相应的安全申请都能获得所有的数据，相应的合规数据都能做查询、分析，甚至做研发。4）资产变现化这样的情况我们作用到第四个阶段，怎么样把数据的价值最大化？怎么样变现？现在我们来看一下主要三个方面，一个是赋能人，让数据的门槛下降，让每一个人都能把数据用起来，这是我们背后非常难的理念，在座各位很多都在做各种各样数据产品，有的是面向于工程师，有的面向分析师，但我们希望是整个数据平台体系能让公司所有的人在他需要的时候把数据用起来，把数据做到平民化。第二个现在越来越多系统应用是数据密集型的，再往下一步走是数据智能化的，需要有算法、规则、数据来反馈这样的应用系统，数据必须把它服务化，去和前台的业务集成打通。第三个滴滴是一个非常依赖数据的公司，后面我会讲为什么，绝大部分业务是靠算法来去驱动的，所以算法需要的大量特征本质上就是来源于中台数据再次加工，怎么能够更好赋能AI？这也是变现里面第三个难题。滴滴究竟在数据方面和传统的互联网或者说BATJ这样的公司有什么样的不同？左边这个图是工业领域常用的东西叫做资源投入和业务价值产出的微笑曲线，当一个公司在两头进行投入，同样投入产出会更高，公司在研发、实验、营销、运营。其实，前面的很多同学分享都提到这一点，我们去做营销投入一块钱到工程师那儿，我们能通过广告收回来多少钱。即便没有广告平台，投入到自己的营销上面拉了更多新客也会赚更多的钱，投入到研发也会让产品竞争力更高，赚更多的钱。但滴滴有点不一样，我们除了在研发实验投入资源产出的效益很高之外，我们在营销领域产出并不高，我们更多是要把它投入到生产领域。在日本精益思想里面，他们说了日本企业和中国企业最大的区别是什么？中国企业只知道在微笑的两端引进新技术获得增长，但不知道把中间这块进行更好的管理，把微笑曲线变成武藏曲线。这是一家日本企业都能活的很好很久的原因，他们把曲线拉的更平，从研发、实验、生产、运营、营销各个环节都能做到很好的竞争力。为什么滴滴微笑曲线会是这样呢？任何一家大型互联网公司本质上是这两个商业模型的内核双轮驱动，网络效应和数据智能，而且往往是网络效应是大于数据智能，但是滴滴却是反着的，本身这个平台没有太大的网络效应，乘客与乘客之间是不互动的，司机与司机也是不互动的，司机和乘客之间的连接是靠当时的时刻和那个时间节点上空间正好能匹配，系统硬拉在一起的，我们没有太多的网络效应，我们只有规模效应，乘客越多可能会吸引司机一下，司机说你这儿好拉活。司机越多可能会吸引乘客一下，这块我打车的概率也高一点，但本质上这个护城河很低。我们在这儿是没有商业模式护城河，唯一一个护城河是来自于数据智能，怎么样通过更好的算法找到更好的匹配，怎