提示：中台重在⽅法论和技术中台架构。
一、 从中台到数据中台
1 、中台
1.1、 关于中台我们需要记住两个时间点
2015年：阿⾥的中台战略始于2015年前后
2018年底：数据中台开始流⾏起来
1.2、 中台到底是要解决什么问题
⼀句总结：中台是为了通过服务化的⽅式实现技术、资源复⽤，解决快速⽀撑业务发展的问题。
在传统IT时代，项⽬的发展相对稳定，并不需要像互联⽹时代那么快速的去迭代和试错，所以这种结构并⽆问题。
在互联⽹快速发展的今天，竞争越来越激烈。只有以⽤户为中⼼，快速适配⽤户的需求，不断迭代和试错，才能让企业在竞争当中⽴于不败。
以阿⾥的中台为例：
阿⾥凭借强⼤的中台能⼒，⽀撑了业务的快速发展(⾃⼰的新业务，收购的业务等等)，⼤家可以想⼀下，如果没有中台战略，要想⽀撑盒⻢⽣鲜的业务得耗费多少⼈⼒和物⼒。
再以华为为例：
华为把作战⼩分队⽐喻为前台项⽬团队，把中台⽐喻成战地指挥部。在这个⽐喻当中，中台的作⽤就是提供资源⽀持：要数据给数据、要技术给技术。正是因为有了中台战略，华为才能快速孵化出华为⼿机、华为荣耀、华为云等品牌。
2、数据中台
2.1、 数据中台整体概览
前⾯说到的中台跟⼤数据关系不⼤，⼤家还在关注怎么快速⽀撑业务，随着⼤数据的发展，到了2018年底数据中台开始流⾏起来，很多互联⽹公司包括⼀些传统企业都在喊数据中台的⼝号。在这些公司⾥确实有很多企业尝到了中台战略的甜头，希望把中台战略推⼴到数据层⾯，但是更多的企业在玩概念跟⻛。
⼤家要玩数据中台，⽬的总结下来⼀句话：通过服务化的⽅式增强数据的共享能⼒以实现数据的复⽤，解决数据研发、数据分析、数据运营时碰到的痛点问题：
（1）指标⼝径定义不⼀致
（2）数据研发效率低问题
（3）数据质量问题频发
（4）⼤数据建设成本越来越⾼
（5）数据发现的能⼒低下导致数据好不好⽤的问题
总结一下，数据中台是啥？简单来说⼀个⼩图。
2.2、 数据中台架构
数据中台架构：为了⽀撑数据中台⽽设计的⼤数据平台架构。
数据中台架构有问题将直接导致数据中台建设⻁头蛇尾甚⾄失败。
始于2018年底，互联⽹企业、传统企业都在开始提出建设数据中台，如果不是真正的了解数据建设的痛点，很多时候会⻁头蛇尾。
因为没有明确的数据中台建设的⽬标，没有很清晰的落地场景、落地成果⽆法直观的量化，最终导致数据中台规划很⼤，落地的时候遇到很多困难和挑战：研发效率低、数据质量差、成本⾼等等。
3、其他相关概念
（1）⼤数据平台：解决⼤数据可⽤性问题
（2）数据中台(开始涉及到业务了)：解决数据好不好⽤的问题，能不能推动业务发展的问题，部分数据业务下沉到中台来做，提⾼数据及资源的复⽤率，降本增效。
⼤数据平台是⼯⼚，数据中台=⼯⼚+⼯⼚⽣产的数据产品。
（3）数据中台架构
为了⽀撑数据中台⽽设计的⼤数据平台架构，相⽐传统⼤数据平台架构需要提供更多能⼒。
（4）数仓
基于⼤数据平台⾯向OLAP（联机事物分析）业务的数据产品，基于数仓产品可以衍⽣出其他的产品，⽐如⽤户画像、推荐系统都得以数据仓库为基础。
（5）数据湖
数据湖是⼀个存储企业的各种各样原始数据的⼤型仓库，其中的数据可供存取、处理、分析及传输。数据湖是数仓的⼀个数据来源之⼀。
二、 无数据中台的苦恼
这⾥以阿⾥数据中台为例，来阐述下数据中台建设的重要性。
1、 无中台数据体系
在没有建设数据中台之前，⼀般公司的数据体系如下图：
2、 无数据中台面临的挑战
⼀旦出现上图的问题，说明你公司的业务正在快速发展，数据规模正在⻜速增⻓，⼤数据投⼊正在快速增加。
（1）⽼板就该开始怀疑⼈⽣了，投了这个多钱为啥还是这样
（2）CTO、 CIO、 CDO开始冒汗，不知道怎么跟⽼板交代
（3）数据负责⼈头⽪开始发麻，上下都没法解释
（4）数据开发者们忙的像超⼈，还在被各种投诉，领导还不理解
3、 原因分析
烟囱式开发模式
传统的数据研发效率低，都是接到需求，从底向上分层开发（ ODS->DWD->DWS->ADS），压根没有考虑复⽤，有可能ODS层数据早就存在了，⼤量的中间表可以复⽤。
（1）数据治理缺失
谁访问了我的表，我的表在哪⾥，下线⼀张表也不知道谁使⽤我的这张表
（2）数据使用门槛高
业务部⻔要使⽤数据，要么提供标准的数据产品，要么采⽤SQL⽅式提取数据，很多运营、产品不会写SQL，全部产品化投⼊太⼤还不能复⽤。
（3）缺少全链路的数据质量监控
⼤数据链路是很⻓的，重跑⾮常困难。
（4）⽆成本意识
为了快速出结果，没有考虑成本，不使⽤的资源没有及时下线。
（5）深层次原因
流程规范缺失：没有完善的流程和规范，⼤家只在关注需求，有了需求就开发，导致越来越失控。
技术架构跟不上：保证流程和规范可以⾼效的被执⾏，所以依赖技术架构，这块需要⼤量的人力投入
组织架构分散：部⻔⾃⼰构建⾃⼰的⼩数仓， N多个⼩数仓相互割裂，跨数仓同步数据困难。
三、 建设数据中台
1、数据中台建设的方法论
数据中台建设的⽅法论就是我们的指导思想，主要分为2⼤块：
（1）数据统⼀管理
（2）服务化
1.1、数据统⼀管理
数据统⼀管理有如下⽅法/要点：
（1）按主题域管理
数据按照业务主题域管理，⽐如⽤户域、订单域、物流域等等。
（2）数据完备
数据中台中的数据尽可能完备，从业务过程⻆度看覆盖范围是完善的（各主题域要覆盖所有业务，提前梳理和熟悉整体的业务，⼲掉烟囱），从分层的⻆度来看，尽量避免跨层构建，即避免明细层数据和轻度汇总层数据缺失。
ODS 层：原始数据层，存放原始数据，直接加载原始⽇志、数据，数据保持原貌不做处理。
DWD层 ：明细数据层结构和粒度与ods层保持⼀致，对ods层数据进⾏清洗(去除空值，脏数据，超过极限范围的数据)，也有公司将该层叫DWI层。
DWS层：（轻度汇总层，按业务要求的最细粒度汇总） 服务数据层 以dwd为基础，进⾏轻度汇总。⼀般聚集到以⽤户当⽇，设备当⽇，商家当⽇，商品当⽇等等的粒度。 在这层通常会有以某⼀个维度为线索，组成跨主题的宽表，⽐如 ⼀个⽤户当⽇的签到数、收藏数、评论数、抽奖数、订阅数、点赞数、浏览商品数、添加购物⻋数、下单数、⽀付数、退款数、点击⼴告数组成的多列表。
ADS层：数据应⽤层， 也有公司或书中把这层叫成为app层、 dal层、 dm层，叫法繁多。 ⾯向实际的数据需求，以DWD或者DWS层的数据为基础，组成的各种统计报表。统计结果最终同步到RDS以供BI或应⽤系统查询使⽤。
我们这⾥所说的数据集市指的是狭义的数据集市，也就是加⼯好的数据可以拿出来了（好⽐摆在”集市“上卖）。
广义的数据集市可以理解为部⻔级别的数仓，正好跟数据中台是反着来的。
（3）制定并推⾏命名规范
好的命名规范应该根据表名就知道所属的主题域、分层、表类型(快照表、增量表)。
（4）提⾼数据模型复⽤性
模型设计尽量考虑复⽤性，不要⼀个表的数据被翻来覆去重复加⼯，⽽是统⼀成⼀个模型供⼤家复⽤。
（5）统⼀指标⼝径
指标⼀致性：不同的系统出现相同的指标名
1.2、服务化
如果没有数据服务化，数据接⼊和访问不是⼀个标准化的流程，则会导致⼀系列问题。要把整个数据开发的流⽔线通过系统的⽅式去打通。
2、数据中台技术体系
数据中台的落地是需要⼀套技术体系来⽀撑的，数据中台架构就是这套体系的具体实现：
3、 数据中台组织架构
数据中台是“⼀把⼿”⼯程，需要从上到下进⾏,企业要想建设数据中台，⾄少需要 CIO 或者 CTO 层⾯推动，最好是最⼤boss推动。中台是战略层⾯的事情⽽不是战术层⾯，⾃下向上推动⼏乎没有可能，⽐如涉及标准统⼀等。
具体来说，数据中台是⼀个集数据采集、融合、治理、组织管理、智能分析为⼀体，将数据以服务⽅式提供给前台应⽤，以提升业务运⾏效率、持续促进业务创新为⽬标的整体平台。从下⽽上往往只能看到其中⼀个点，难免会以偏概全，毕竟⼤部分员⼯很难站在⼀定的⾼度去做⼀个”看⼗年、做⼀年“的规划，特别是当⼀件事和眼前的 KPI 难以达成平衡时，中台的⼯作会受到各个⽅⾯的挑战。因此，⾼层的坚定⽀持是中台战略的第⼀必要条件。
当企业⾼层决定建设数据中台后，下⼀步就要考虑中台团队的⼈员组成以及整个团队在组织架构中的位置。对于是否要进⾏⼤的组织架构调整，⾸先要看企业的业务复杂程度。类似阿⾥巴巴、京东等⼤⼚需要通过组织架构调整来保障战略顺利推进，但规模相对较⼩的企业可能没有必要进⾏组织架构调整；其次，取决于企业决策者对数据中台战略的态度，是否将其放到整个公司的战略⾼度，类似阿⾥巴巴、京东等⼤⼚已经将数据中台作为重要战略，陆续进⾏了组织架构变更。
典型的数据中台组织架构如下：
组织架构是基础，各个团队分散到各个部⻔，数据中台基本不会建⽴起来的。⼀般典型的做法是，整个数据中台团队由原来的⼤数据团队整编过来，直接汇报给CTO/CIO，也可能会报给⽼板，整个部⻔⼀般会有⼀个⼤数据总监来负责。
（1）数据产品团队：负责数据产品、数据中台的整体规划，制定数据相关规范监督落地
（2）数据平台团队：平台⼯具的研发，整体架构的演进，⼀般会⾼配⽐较厉害的架构师
（3）数据开发团队：⽇常数据研发、数据集成、计算、治理等等
（4）数据应⽤团队：数据应⽤产品研发，⼀般是⾯向业务过程、⾏业的、通⽤的数据应⽤
四、开源数据中台架构
数据中台整体建设是CTO、⼤数据总监、⼤数据负责⼈该考虑的，起码得考虑1年以上，建设周期1年起步（分阶段），作为架构师应该考虑的是⽀撑数据中台建设的架构。
1、数据中台架构应该具备的能⼒
（1）基础设施/基础平台
存储引擎
计算引擎
辅助服务
（2）数据集成
（3）数据开发
（4）⼯作流调度
（5）数据治理
数据质量
元数据管理
数据安全
（6）数据可视化
（7）DevOps
（8）其他数据服务
2、老师（资深架构师Felix）设计的数据中台架构
五、数据中台战略思考
1、数据体系及架构的演进
数据体系演进：数据仓库->数据平台->数据湖->数据中台(通⽤业务下沉)
技术架构演进： hive->CDH体系->更全->更全
2、 数据中台未来发展⽅向
2.1、实时数据中台
⽬前各⼤公司数据中台中实时数据计算占⽐少，模型复⽤率低，公共计算逻辑下沉做得不好。未来需要把现在的理念推⼴到实时加⼯链路，构建实时数据中台。
2.2、云原⽣数据中台
基于k8s，弹性资源调度，实现在线和离线混布，提⾼资源使⽤效率。
2.3、⾃动化数据研发流⽔线(DataDevOPS)
可视化操作，可视化ETL，数据开发⾃动化流⽔线。
2.4、智能元数据管理
智能数据发现，智能元数据分析。
2.5、通⽤数据产品建设
更多的企业会研发⾃⼰的通⽤数据产品，甚⾄有更多通⽤的数据产品被开源出来，例如⽤户⾏为分析产品。
3、中台战略反思
3.1、中台并⾮万能钥匙
中台并⾮万能钥匙，当初为了解决组织和效率的问题，⼤多数企业开始跟⻛建设，最后发现有效果但是矫枉过正了，把太多的东⻄放在了中台导致不利于业务创新。
中台并不是不⽀持创新，正相反，阿⾥中台孵化出“盒⻢鲜⽣”这样的现象级产品，如果没有中台，不可能半年打造出⼀整套线上线下新零售系统。
准确的说， 中台适合做“组合式创新”，没法做“颠覆式创新”。所谓组合式创新，是把现有⼏个能⼒进⾏组合，形成新的能⼒，它强调能⼒的标准化，这个恰恰是中台所擅⻓的。以“盒⻢鲜⽣”为例，它复⽤了中台的商品、库存、⽤户、⽀付、 AI、安全等多个服务能⼒，经过重新组合，形成了“零售新物种”。
但是， 颠覆式创新，是从根上做创新，它要打烂前台、中台、后台，颠覆现有模式和能⼒。⽐如智能制造颠覆传统制造、智能⼿机颠覆传统⼿机，你没法在现有⽣产线上去创造，只有打破原有模式。所以， 中台不⽀持颠覆式创新，这是中台的基因所决定的。
把最抽象的部分留在中台，这样中台就剩下很薄的⼀层，通过这⼏年沉淀下来的通⽤能⼒来提⾼效率，可以⼤⼤减少⼈⼒，释放出来的⼈去前台做个性化的改造。
3.2、不同企业应该量体裁⾐
初创公司正经历从0到1的阶段：没必要建设中台，⽣存下去最重要，中台还没搭建好公司可能就死了。
中⼩型公司从1到N的阶段适合搭建中台：⽣存问题已经解决，在项⽬没有太复杂之前下沉通⽤业务，为后续业务爆发做准备。
中⼤型公司从N到N+1阶段中台战略势在必⾏。
4、 碎⽚化中台
中台会越来越薄+碎⽚化中台。
2015年底阿⾥推出“中台”战略，将庞⼤的业务服务能⼒，都装进了“业务中台”⾥，包括交易中⼼、⽀付中⼼、清算中台、⽤户中⼼、产品中⼼等13个业务域，这是阿⾥中台早期的架构图：
随着阿⾥中台战略的深⼊， 2018年阿⾥提出了“业务-数据双中台”战略，可以理解为升级版的中台战略，依托阿⾥云ET⼤脑，向社会输出中台能⼒和⽅法论。阿⾥的中台⼀分为⼆：数据中台、业务中台，如下图：
这⼀“拆”，仿佛打通了中台战略的任督⼆脉，从此⼀发不可收拾，相继拆分出：移动中台、技术中台、⻛险能⼒中台、研发效能中台等等。⾄此，阿⾥在“拆”中台的路上，越⾛越远。
5、中台战略的三个阶段
碎⽚化中台，是中台架构演进的必经阶段，各⾏业经过⼏年的实践，也逐渐沉淀出⼀些贴合⾃⼰⾏业的中台实践。不同⾏业，不同企业，遇到的问题不同，解决的路径也是不⼀样的。从中台演进的过程来看，⼤致分成三个阶段。
（1）阶段1：业务中台
企业从业务顶层规划、业务建模开始，梳理出各业务领域的边界、服务能⼒，进⽽指导系统的服务化建设，⽐较好的实践有：企业EAI、微服务等等。
（2）阶段2：双中台
企业具备了业务领域建模、数据治理⽅⾯的能⼒，逐步建⽴起基于业务中台和数据中台的“双中台”模式，在这个过程中，沉淀⾃⼰的中台⽅法论和实践。值得注意的是， 由于业务领域建模和数据治理的⾏业性、专业性太强，这类⼈才⼤概率只能在企业内部培养。
（3）阶段3：碎⽚化中台
在完成业务中台、数据中台的建设之后，企业组织的效率已经有了显著提升，企业成本也随之降低。这个时候，中台建设进⼊到了碎⽚化中台阶段，组织内部按业务线或职能进⾏更细粒度拆分，⽐如：安全中台、财务中台、移动中台、客服中台、供应商中台、物流中台等等。
原文链接：https://blog.csdn.net/dajiangtai007/article/details/123692199