什么是中台？
按照数据咨询公司Thoughtworks首席咨询师王健给出的10个字定义，中台就是：“企业级的能力复用平台”
- 1）“企业级”划定了中台的范围，区分开了单系统的服务化与微服务
- 2）“能力”指定了中台的主要承载对象，能力的抽象解释了各种各样中台的存在
- 3）“复用”定义了中台的核心价值，过去的平台化对于易复用性并没有给予足够关注。中台的兴起，使得人们的目光更多的从平台内部，转换到平台对于前台业务的支撑上
- 4）“平台”说明了中台的主要形式，区别于应用系统拼凑的方式，通过对于更细粒度能力的识别与平台化沉淀，实现企业能力的柔性复用，对于前台业务更好的支撑
“中台”的传说
作为这一波“中台”概念的源头，第一个传说必须来自阿里。“游戏公司”的传说，大致是这样，2015年阿里的马老师带队参观了芬兰一家厉害的游戏公司 Supercell，它有很多成功的游戏产品，其独特优势是能够快速推出新产品，而依靠的就是中台系统。
马老师受到了启发，回到阿里开始推进中台建设在组织架构层面成立了单独的中台部门即“共享业务事业部”，系统层面建设了用户中心、支付中心等共享服务同时支持淘宝、天猫、1688 等业务条线，最终也实现了快速的前台产品研发。这些中台服务被统称为“业务中台”。
通过这个故事，我们可以得出第一个结论。中台应该提供“共享服务能力”，这种共享源于对业务场景的抽象、提炼、沉淀。
关于中台的第二个传说是“变速齿轮”。当前的IT 架构通常是由前台和后台组成，前台系统接触用户，后台系统提供基础服务。两者一个需要灵活快速，一个需要稳定高效，两者在变更速率上不匹配，制约了对用户需求的快速响应。中台的诞生衔接了前后台系统，保证后台稳定的同时又支持了前台的灵活。
中台的类型有哪些？
按照目前普遍的说法，中台分为6类：
- 1）数据中台：提供数据分析能力，帮助企业从数据中学习改进，调整方向
- 2）业务中台：提供重用服务，例如用户中心、订单中心之类的开箱即用可重用能力
- 3）算法中台：提供算法能力，帮助提供更加个性化的服务，增强用户体验
- 4）技术中台：提供自建系统部分的技术支撑能力，帮助解决基础设施、分布式数据库等底层技术问题
- 5）研发中台：提供自建系统部分的管理和技术实践支撑能力，帮助快速搭建项目、管理进度、测试、持续集成、持续交付
- 6）组织中台：为项目提供投资管理、风险管理、资源调度等支持
中台示例解释
数据中台是什么？
数据中台是一套可持续“让企业的数据用起来”的机制，是一种战略选择和组织形式，是依据企业特有的业务模式和组织架构，通过有形的产品和实施方法论支撑，构建的一套持续不断把数据变成资产并服务于业务的机制。
数据中台是处于业务前台和技术后台的中间层，是对业务提供的数据能力的抽象和共享的过程，数据中台通过将企业的数据变成数据资产，并提供数据能力组件和运行机制，形成聚合数据接入、集成、清洗加工、建模处理、挖掘分析，并以共享服务的方式将数据提供给业务端使用，从而与业务产生联动，而后结合业务系统的数据生产能力，最终构建数据生产>消费>再生的闭环，通过这样持续使用数据、产生智能、反哺业务从而实现数据变现的系统和机制。
数据来自于业务，并反哺业务，不断循环迭代，实现数据可见、可用、可运营。
- 通过数据中台把数据变为一种服务能力，既能提升管理、决策水平，又能直接支撑企业业务。
- 数据中台不仅仅是技术，也不仅仅是产品，而是一套完整的让数据用起来的机制。
- 既然是“机制”，就需要从企业战略、组织、人才等方面来全方位地规划和配合，而不能仅仅停留在工具和产品层面。
数据中台通过数据技术，对海量数据进行采集、计算、存储、加工，同时统一标准和口径。数据中台把数据统一之后，会形成标准数据，再进行存储，形成大数据资产层，进而为客户提供高效服务。这些服务跟企业的业务有较强关联性，是这个企业独有且能复用的。
数据处理需求的演进历程
数据处理需求的演进历程
数据处理经历了四个阶段，分别是：
- 数据库阶段：OLTP（事务处理）是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，记录及时的增、删、改、查。比如银行交易、电商交易等。
- 数据仓库阶段：数据仓库系统的主要应用主要是OLAP（联机分析处理），支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。比如复杂的动态报表分析、用户价值分析等
- 数据平台阶段：其实，目前业界并没有对大数据平台做统一的定义，一般情况下，只要使用了Hadoop/Spark/Storm/Flink等这些分布式的实时或者离线计算框架，建立计算集群，并在上面运行各种计算任务，具有数据互联互通、支持多数据集实时同步、支持数据资源管理、实现多源异构数据的整合管控；提供完善的大数据分析基础运行环境，提供统一二次开发接口等能力的，就算的上理解上的大数据平台。主要是为了解决大数据存储计算 + 数据应用管理 + 任务监控 + 数据资产管理 + 开发管理 + 可视化报表需求等
- 数据中台阶段：指具有全域级、可复用的数据资产中心与数据能力中心，对海量数据进行采集、计算、存储、加工，同时统一标准和口径，提供干净、透明、智慧的数据资产与高效、易用的数据能力来，能够对接OLTP（事务处理）和OLAP（报表分析）的需求，从业务架构设计到模型设计，从数据研发到数据服务，做到数据可管理、可追溯、可规避重复建设，强调的是数据业务化的能力
数据中台 & 数据仓库 & 数据平台 & 数据湖
数据仓库、数据湖、数据平台、数据中台总结如下：
四者之间关系说明：
数据中台、数据仓库和数据湖没有直接的关系；数据中台、数据平台、数据仓库和数据湖在某个维度上为业务产生价值的形式有不同的侧重；
- 数据中台：是企业级的逻辑概念，体现企业数据向业务价值转化的能力，为业务提供服务的主要方式是数据 API；
- 数据平台：是在大数据基础上出现的融合了结构化和非结构化数据的数据基础平台，为业务提供服务的方式主要是直接提供数据集；
- 数据中台距离业务更近，能够更快速的响应业务和应用开发需求，从而为业务提供速度更快的服务；
- 数据中台可以建立在数据仓库和数据平台之上，是加速企业从数据到业务价值的过程的中间层。
四者区别：
数据中台的价值
1.数据中台是企业数据化建设的基础设施
- 数据中台解决了企业全域数据汇聚的问题，打通以往的数据孤岛，沉淀数据资产，实现数据之间的价值共通，可基于数据中台满足复杂的数据应用场景。
2.提升数据质量
- 数据中台基于Onedata方法论构建统一的公共层，保证了源头数据的一致性，且实现数据按照统一口径只加工一次，实现全局指标、标签的统一，大大提高数据质量。
3.建立数据标准
- 数据中台建设会促使企业还要建设数据标准或规范，比如数据接入规范、数据集成规范、数据存储规范、数据处理规范、数据使用权限规范、数据共享规范、数据销毁规范、数据安全规范等。
- 这些标准都是数据中台建设阶段也需要建设的体系。有数据标准/规范体系护航，数据中台才能更好的运转；也只有依托数据中台，数据标准才能更好的执行和落地。
4.节约企业数据应用成本
- 基于数据中台的元数据管理的数据血缘，可以实现数据投入产出比的评估，及时发现并下线低ROI的数据，也避免数据重复加工。由此降低数据的研发、存储和计算成本，降低企业数据应用成本。
- 下面分别从两个角度去阐述所产生的降本和增效价值：通过提供赋能于具体业务场景的数据应用，帮助业务端更精准的发现客户、分析客户等，用数据滋养各线业务，使整个业务运营过程体验更友好和高效，并缩短运营周期。
- 降本：数据中台通过复用数据能力组建，快速完成数据链路的搭建，减少重复研发的人力和维护成本；
- 增效：通过快速复用组建完成数据链路搭建，让数据从接入>加工>使用的整个周期缩短，减少业务端的数据获取等待时延，为业务方赢得更多的展业时间和机会。
5.健全各部门协作机制
- 数据中台承担着一定的实现企业战略目标的使命，数据中台的建设过程势必需要对应的组织和制度来支撑中台的建设和运营。数据中台这种体系化工程将横向拉通企业数据的相关方，包括中台建设团队、中台运维团队、数据产品经理团队、数据运营团队等，形成企业真正的数据组织。利用系统化的解决方案配合一定的管理机制，实现业务人员、数据研发、产品经理、数据分析师等角色的高效协同，提升各角色之间的协作效率。
数据中台要解决什么问题？
痛点：
1.指标口径不一致：通常表现在3各方面：业务口径不一致、计算逻辑不一致、数据来源不一致。
- 业务口径不一致：业务口径不一致的指标，应该要有不同的标识去区分，比如上面提到的销售额这一指标，明明口径是不一致的，但却没有区分，容易让业务误解。
- 计算逻辑不一致：业务口径的描述往往是一段话，但对于一些计算逻辑比价复杂的指标，一段话通常是描述不清楚的，如果碰巧两个相同业务口径的指标是不同的数据研发实现的，极有可能会出现计算逻辑不一致的情况。
- 数据来源不一致：对于部分指标，有多个数据源可供选择，如果数据源正好有些细微差异不被发现时，即使加工逻辑一样，也有可能结果不一致。另外，实时数据和离线数据也会有一定差异。
因此，要实现一致性，就要确保对同一个指标，只有一个业务口径，只加工一次，且数据来源必须一致。
2.烟囱式建设数据平台，大量源被浪费，响应速度慢
- 主要在于烟囱式的开发模式，使得数据复用性低，导致大量重复逻辑代码的研发，影响需求响应速度。
- 比如，两个指标都需要对同一份原始数据进行清洗，原则上来说，只用一个任务对原始数据做清洗，产出一张明细表，另一个指标开发时，便可直接引用已经清洗好的明细表，这样便可节省一个清洗逻辑的研发工作量。但现实往往是对同一份原始数据做了两次清洗。因此，要解决需求响应速度慢的问题，就要提升数据的复用性，确保相同数据只加工一次，实现数据的共享。
3.取数效率低
- 主要表现在两个方面：一方面是找不到数据，另一方面是取不到数据。
- 要解决找不到数据的问题，就要构建企业数据资产目录，让数据使用者快速找到并理解数据。取不到数据的主要是非技术人员不会写SQL去提取数据，所以可以为其提供自助取数工具，使其简单快速的获取数据。
4.数据质量低
- 面对业务已经沉淀的大量数据，逐步形成了企业的数据资产。而这些数据资产如何成为可持续使用的，为企业带来价值的数据，需要数据治理进行提升数据质量，比如设计数据质量校验的规则和使用流程，设计数据管控权限，数据如何安全输出及共享的设计等，如何在整体上发挥出数据的协同效应，为业务提供更高价值的数据服务链路，数据中台可以将这些数据能力整合到一起，对业务端提供稳定的持续的服务能力。
根据上面的问题分析，数据中台就是要解决找数据，理解数据、问题评估、取数及可视化展现这五个问题。整个平台的故事也是围绕这个五个点。从根本上解决：
- 找数：数据从什么地方来到什么地方去，将数据和业务过程结合起来，实现数据的快速查询
- 理解数据：通过数据的血缘关系，数据关联关系及数据的说明信息，让数据开发人员，业务人员快速理解数据
- 问题评估：数据分析人员拿到需求，可以通过该平台实现问题的自动评估，大大提高数据分析效率
- 取数：用户可以不再关心数据的来源，不再担心数据的一致性，不再依赖RD的排期开发。通过所选即所得的方式，满足了用户对业务核心指标的二次加工、报表和取数诉求
- 数据可视化：依托于我们的BI可视化系统和数据中台的打通，数据分析人员可以快速的将数据中台创建的数据模型快速的转换成可视化报表。
数据中台要做什么？
数据中台是企业数字化运营的统一数据能力平台，能够按照规范汇聚和治理全局数据，为各个业务部门提供标准的数据能力和数据工具，同时在公司层面管理数据能力的抽象、共享和复用。数据中台与传统数据仓库和大数据平台的最根本差异，就是强调从工具和机制上支持对数据能力的全局抽象、共享和复用。 应该说，数据中台是建立在数据仓库和大数据平台之上的，让业务部门可以更好、更有效率地使用数据的运营管理层。
数据中台通过提供工具、流程和方法论，实现数据能力的全局抽象、共享和复用，赋能业务部门，提高实现数据价值的效率。数据中台需要具备数据汇聚整合、数据提纯加工、数据服务可视化、数据价值变现4个核心能力，让企业员工、客户、伙伴能够方便地应用数据。
- 第一，实现这些目标必须有相应的数据能力，也就是从数据中产生价值的能力。
- 第二，要实现这些目标，必须完成全局的数据汇聚和治理。
- 第三，企业必须高效完成从汇总好的数据到价值的转换，需要进行数据能力的抽象，然后实现能力的共享和复用。
- 第四，在实现数据能力的共享和复用的过程中，需要协调复用和效率的矛盾。
针对数据中台需要构建的目标，数据中台需要实现如下功能和服务：
一、构建服务和系统
1.构建全局一致的指标词典，实现指标体系化管理
- 按照数仓主题域的方式对所有指标统一命名、分类，明确指标口径、数据来源、计算逻辑，产出企业的指标词典，由专门团队来负责指标口径的管控；
- 设计上线方便业务人员查询的指标词典管理系统，所有的数据产品、数据报表都引用指标系统的口径，当鼠标Hover到某个指标上时，浮现该指标的指标口径定义。
2.统一数仓建模，构建全局一致的公共层，提升数据复用性
- 制定统一的数仓建模规范，在模型设计阶段，强制相同聚合粒度的模型，度量不能重复，保证相同粒度的指标、度量只加工一次；建设数据地图，方便数据研发能快速查找并准确理解数据。
3.提供企业数据地图和自助取数系统
- 数据中台构建了企业数据地图，数据使用者可通过数据地图快速了解企业当前有哪些数据，在哪张表里可以看到，关联了哪些指标和维度；
- 非技术人员可通过自主取数工具，选取指标，勾选指标的可分析维度，添加筛选条件，点击查询，就可以方便获取数据。
4.配置数据质量稽核规则和数据预警
- 通过配置数据质量稽核规则和数据预警，对数据一致性、完整性、正确性和及时性进行监控，确保第一时间发现、恢复、通知数据问题。
5.上线数据成本治理系统
- 数据治理系统可实现表维度、任务维度、应用维度的全面数据治理。比如一个30天内没有被访问的报表，我们认为其产出价值较低，这时我们可以结合这个报表的所有上游表和下游表产出任务，计算这张表的加工成本，有了价值和成本，便可计算出ROI，根据RO评估，实现低价值报表的及时发现和下线。
二、整合数据中台核心功能
1.汇聚整合
- 数据中台需要对数据进行整合和完善，提供适用、适配、成熟、完善的一站式大数据平台工具，在简便有效的基础上，实现数据采集、交换等任务配置以及监控管理。
- 数据中台必须具备数据集成与运营方面的能力，能够接入、转换、写入或缓存企业内外部多种来源的数据，协助不同部门和团队的数据使用者更好地定位数据、理解数据。
2.提纯加工
- 数据就像石油，需要经过提纯加工才能使用，这个过程就是数据资产化。企业需要完整的数据资产体系，围绕着能给业务带来价值的数据资产进行建设，推动业务数据向数据资产的转化。
- 数据中台必须连通全域数据，通过统一的数据标准和质量体系，建设提纯加工后的标准数据资产体系，以满足企业业务对数据的需求。
3.服务可视化
- 为了尽快让数据用起来，数据中台必须提供便捷、快速的数据服务能力，让相关人员能够迅速开发数据应用，支持数据资产场景化能力的快速输出，以响应客户的动态需求。
- 多数企业还期待数据中台可以提供数据化运营平台，帮助企业快速实现数据资产的可视化分析，提供包括实时流数据分析、预测分析、机器学习等更为高级的服务，为企业数据化运营赋能。
- 数据资产必须服务于业务分析才能解决企业在数据洞察方面的短板，实现与业务的紧密结合。
4.价值变现
- 数据中台通过打通企业数据，提供以前单个部门或者单个业务单元无法提供的数据服务能力，以实现数据的更大价值变现。
- 企业期待数据中台能提升跨部门的普适性业务价值能力，更好地管理数据应用，将数据洞察变成直接驱动业务行动的核心动能，跨业务场景推进数据实践
数据中台团队需要什么样的角色
- 业务专家团队：了解业务、梳理业务场景，确定数据资产与业务场景的一一对应关系，确定业务场景的优先级，为数据中台的建设提供依据。
- 数据工程团队：建设和维护数据中台，包括 ETL、数据采集，以及数据中台性能和稳定性保证，利用中台的工具采集、存储、加工、处理数据。
- 数据分析团队：分析数据价值、探索场景，生产更多的数据服务。
- 数据治理团队：梳理数据标准、构件数据安全和隐私规范，利用开源去中心化的数据治理工具（比如 atlas、wherehows）来围绕业务场景解决数据质量和安全问题。
- 智能算法团队：为数据分析、业务探索提供智能和算法工具。
企业中台典型架构
中台意味着了前中后的三层体系架构，三者的变更速率可以实现更平缓的过渡，从而兼顾整个体系的灵活与稳定。如下图阿里的双中台架构：
上图中（阿里）标注了组织架构层面的前台、中台和后台
上图中（民生银行）的数据中台体系技术方案给出了上面的架构图，明确了“数据后台”的范围，其涵盖了 Hadoop 平台、实时分析平台等，有点技术平台的味道。
上图中（农行）“薄前台、厚中台、强后台”IT 架构体系 中对前中后三个层次描述得更为明确，将大数据平台和 PAAS、IAAS 基础设施划入了后台。
看过两家银行架构，我们似乎可以得到一个推论：后台是技术平台或基础设施。但这两者通常是与业务无关的，会制约前台业务的灵活性吗？基础设施和技术平台同时支持了前台和中台，在层级并不是一个递进关系呀？这个分层似乎有点奇怪，有点牵强。
反复思考后，我认为阿里提出的“用户中心”、“支付中心”所代表的“业务中台”是指企业组织层面的中台，更准确说法是“由业务中台部门所主导的业务能力共享平台”。
- 前台部门直接面对用户和创造利润；
- 阿里“共享服务事业部”更多参与到了业务中，非常适合中台的定位。
- 而后台主要是辅助作用，通常也就不会受到用户需求的影响，企业甚至行业间的差异都比较小，因此在以快速响应为核心的方案中将其忽略也就顺理成章的事了。
进一步研究发现，本文观点与网易对中台的看法较为接近。对于数据中台，网易杭州研究院执行院长汪源给出的定义如下，“所有的中台都是业务中台，数据中台是业务中台的特殊形式。中台是区别于平台的，具备业务属性、支撑多个前台业务的产品，其本质是公司业务能力的沉淀。”
带着这个观点，我们重新解读两个故事。在“游戏公司”的故事中，业务中台是指企业能力层面的中台，“中”是指所属部门在组织架构的位置。“变速齿轮”的故事，符合我们在系统设计方面的经验，更适合指导企业架构层面的中台系统建设。
两个结论都是正确的，但不在同一个平面，我们不必将基础设施拉进来凑数。
企业能力层面（二元架构）
从架构的视角看，前台与“大中台”组成的二元架构实质就是前后台架构。
- 前台系统是直接实现业务需求的各类数据分析系统，或者联机系统的查询分析模块，前台系统紧随业务而变化。
- 中台归属于科技部门，从而降低与业务部门的关联性，可以从企业全局视角进行优化。中台的核心思想就是复用，将不同业务场景的通用能力抽离出来，下沉到一个共享平台，更好的支持前台系统的灵活变化。
这种架构思想的经典案例就是数据仓库。
一、传统数据仓库（数据中台 1.0）
理论上，数据仓库实现复用的核心是企业数据模型，以咨询公司的先验模型为基础，在业务发展过程中逐渐提炼出共性、稳定的需求丰富数据仓库，消除加工逻辑和存储上的冗余；
而数据集市实现个性化、易变的需求。从这个意义上来讲，数据仓库就是数据中台的 1.0 版本。不幸的是，工程实践中存在很多问题：
- 首先，判别业务稳定与否是个不小的挑战，充斥着各种主观标准，难以在大范围达成共识；
- 其次，即使那些稳定的需求，当其成为某个数据集市的核心需求时，考虑到对该集市其他功能的支撑作用，将该功能纳入数据仓库意味着整个集市的下沉，因而不具可行性；
- 此外即便是易变的需求，当确认了需求的权威性后，也会出现在集市之间共享的情况，数据集市之间联系也就自然发生了。
由于上述原因，集市规模越来越大，逻辑愈加复杂，横向联系逐渐增多，数据仓库则发展缓慢。
- 这种架构最大的问题不是集市体量大，而在于它的不稳定性。因为其直接服务于业务部门，任何组织架构上的调整都会带来集市的合并分拆，甚至在组织架构不变的情况下，部门经营策略的更改也会成为新建或分拆系统的动力。
- 当某类产品成为企业发展重点时，会出现为产品建立独立分析系统的诉求，例如互联网信贷产品分析系统；当某个渠道的关注度提升时，又会希望按照渠道汇总各类信息，例如对电子银行分析系统；
- 再或者对某个客户群体的重视，将催生以客户特征为边界的集市，例如私人银行客户分析系统。
一个问题常常困扰我们，企业到底应该建设多少个数据集市? 我想，正如康威定律的核心思想，“组织形式等同系统设计”，这个答案永远都在随着组织形式而改变。作为架构师，我们不希望存在复杂而需求易变的系统，因此我们选择接受易变性，寄希望于降低系统的复杂度，阿里所提出的“大中台、小前台”成为一个不错的选择。
二、互联网数据中台（数据中台 1.5）
最初，互联网企业和很多中小规模的传统企业一样，是没有数据仓库的，往往以效率优先的原则建设特定系统满足数据应用需求，这类系统实质就是“数据集市”。
企业规模扩大，“数据集市”数量不断增加，这时重复加工、口径不统一、成本不经济的问题就会浮现出来，当然最更要的是对快速交付的期待。
2017 年，阿里提出的数据中台 维持了数据仓库架构的基本二元结构，如下图：
- 垂直数据中心、公共数据中心、萃取数据中心是在数据处理逻辑上的分层，与传统数据仓库的分层有相近之处；
- 统一数据服务中间件（OneService）是新增部分，体现了 DT 时代对数据价值的重视，需要更直接的方式使用数据。
OneService 并不是单纯的 API 服务，同时涵盖了 SQL 查询、数据批量等方式。是否保留这些方式，我有一些不同的理解。
- 首先是数据批量方式，从数据仓库的实施经验来看，集市通常会有自我闭环趋势，力图减少对其他系统的依赖，其积累数据后必然进一步扩充功能，批量数据集成方式事实上是能够为前台的膨胀提供了基础。约束“小前台”最操作性的方式，AIP 服务调用方式替换数据集成，由于数据不落地，前台不易积累数据以独自完成业务需求，必须依赖中台的支持。
- 再来看 SQL 查询接口，其主要用于支持 BI 工具。SQL 直接体现了服务端的数据表结构，与物理模型设计和具体技术产品形成紧密耦合，降低了“大中台”后续发展的弹性，甚至造成对单一数据库产品的绑定。使用 API 可以降低这种耦合，付出的代价是弱化了前台系统对数据加工能力。随着 Json 接口成为 BI 工具的标准功能，API 替代 SQL 接口也具有很高的可行性。
因此，我认为依赖统一的 API 服务打通前台与中台的联系，前台系统之间不再有直接联系，整体保持星型架构，能够保证“大中台、小前台”架构的持续性，如下图所示
企业架构层面（三层架构）
正如“变速齿轮”论，前后台的二元架构难以平衡灵活与稳定的矛盾。我们进入架构层面的讨论，其拆分为三层架构，如下图所示
“服务联邦层”位于三层架构的中间地带，是我们前文中提到的“数据中台系统”，即“小中台”。“小中台”整合“粗粒度服务”支持前台系统。
- 数据后台：提供稳定的“细粒度服务”作为“小中台”的整合素材，我将一类主要的服务提供方称为“数据服务群”。
- “数据服务群”：是数据服务的集合，业务相关性是一个重要整合维度，但同时也可以根据性能需求使用不同的底层技术平台而剥离为不同的服务群，服务群本身是有落地数据存储的，不同服务群之间可能存在一定冗余，比如客户、机构等数据。
- 同时数据仓库（强模型数据）、数据湖（弱模型数据）、文本检索系统（非结构化数据）、历史数据查询系统（冷数据），也可提供一般性能需求的服务，与“数据服务群组”共同构成了数据后台。
- 技术平台仅提供支撑作用，不归属于中台或后台。
一、技术可行性
- “小中台”的主要工作是进行数据集合运算，实现原有集市沉降下来的业务逻辑。
- “小中台”与数据后台基于 API 进行异步非阻塞通讯，目的是为了解耦具体技术产品和数据模型。
- “小中台”要基于后台服务返回结果集完成各类 SQL 等效操作，有些同学可能会怀疑技术可行性。其实，今天 NewSQL 数据库广为所采用的数据库引擎与 KV 存储引擎分离的设计模式，同样使用了服务接口进行通讯。
- “小中台”不涉及数据的写入、更改，几乎没有事务处理，技术难度会大幅降低。
二、压缩 SQL 使用范围
- 相比阿里的数据中台，本文提出的整体架构最大程度降低了 SQL 的使用。一个敏捷的架构必然是可治理的，而数据仓库难以治理的顽疾正在于以 SQL 为核心的 ETL 工作。
- SQL是一种领域特定语言（DSL），虽然很强大但并不是很好的工程语言。由于它不能在内存中定义和操作复杂的数据结构，如果要做模块化的逻辑封装，模块的输入输出必须是数据库表，这就带来了 I/O 损耗，大量的模块化，必然带来导致 I/O 性能的显著下降。而这些模块存在的方式只是脚本，缺少治理工具，大量零散的模块如何管理也是一个难题。
- 系统实施者必须在模块化和性能间权衡，性能是显性的，直接影响用户体验且有明确的度量指标；模块化是隐形的，而且缺少度量工具。因此实际工程中，很少真正做到逻辑的模块化，数据库表的层次不规范，甚至出现数千行 SQL 语句从源表加工数据直接写入结果表。由于缺少治理工具，规范难以执行，久而久之大家也就默认了这样的事实。
- 我们付出的代价是可测试性极差，每次逻辑的变化都要通过对代码的修改来实现而并不是新增逻辑。试想一段上千行、逻辑纵横交错的 SQL 语句，要在其中修改某个单点逻辑，没有高覆盖率的单元测试用例，如何确保正确性，最终只能依靠细心和运气，代码质量必定是脆弱的，不能称为真正的工程化项目，治理和敏捷都无从谈起。
三、降低数据存储冗余
- 整体架构也在最大程度上压缩数据存储。三个层次中，只有数据后台会落地保存数据，“小中台”主体由服务组成，仅保留客户、机构等维度数据，用于提升处理效率。系统间数据冗余是业务逻辑重复开发的土壤，需要在顶层架构设计中尽量规避。
- 打个比方，三层架构就像一条汽车产业链，“小中台”是作为龙头的整车生产厂，后台是各种配件厂、发动机厂，前台是 4S 店负责直接接触客户和简单的改装。
- 整车厂为了避免占用资金和仓储，不会囤积过多的配件，而是根据整车订单量向配件厂动态调配。我们也尽量避免数据的冗余，降低传输和存储成本，缩短数据批量加工时间。
- 整车厂可能会复用成熟车型的部分配件（比如轮胎、发动机），改变部分配件快速推出新车型，就像我们通过中台完成业务需求的主要逻辑。
- 前台的主要功能是产品交付和简单需求的满足，比如提供内饰甚至可以给汽车开天窗，但当多数用户提出该需求时，整车厂会直接推出天窗版，以更标准化的方式完成，也就是前台功能向中台的转移。
- 对于配件厂商，只要保证配件持续稳定供给，如果某款配件使用在多种畅销车型上，订单量会大幅提升，就要升级对应的产品线提升产能，生产线的变化并不影响到整车厂。
- 与之相似的，某些细粒度服务被多个粗粒度服务调用时，导致并发访问的提高，需要改变技术方案以处理并发和控制延时，可能会从 Oracle 切换到 HBase 或分布式数据库上，但中台和前台都不会感知到这些变化。
四、三层架构小结
- 总的来说，三层架构的核心设计思想是通过 API 服务衔接前中后台，减少数据搬家造成的冗余控制前台的膨胀，以无状态服务为核心使中台其具备横向扩展能力，后台避免锁定技术产品和数据模型，可以根据需求的变化灵活切换到不同的解决方案；
- API 服务相对 SQL 脚本具有更好的工程化特性，更便于治理，能够形成完善的敏捷体系，从而达到快速交付需求的目标。
- “数据中台”并不是银弹，也存在不足。以服务为核心的中台模式并不能做百分之百的需求覆盖，仍然有一些特殊情况存在，例如一些复杂度高查询通过“服务联邦层”实现可能过于繁琐，性能有明显损耗；一些批处理任务需要数据文件形式交付，如营销名单、催收名单等，需要特定的方式处理。
- “数据中台”实施过程中的挑战主要体现在“需求控制”和“技术栈变更”两个方面。中台是典型的横向切分方式，必然会削弱业务需求的整体性，需要纵向增强对需求的统一管理，协调前中后台之间的联系。传统的 SQL 为核心的技能无法支撑本文的架构，开发者技术栈的大幅变更也考验企业的技术能力和决心。
白话理解数据中台
中台就是公共服务平台，数据中台就是将数据加工以后封装成一个公共的数据产品或服务。
家里厨房有油/盐/酱油/醋/料酒/生抽…很多种调料（数据），你（业务部门）特别喜欢吃糖醋排骨/糖醋鱼/糖醋里脊/糖醋猪蹄…（各种业务应用），你老妈（IT部门）觉得每天都按照比例调制糖醋汁很麻烦很浪费时间还每次都有偏差（每次数据有误差）。
于是你老妈决定按照“1料酒；2酱油；3白糖；4醋；5水”的比例（数据算法）调制好一大桶糖醋汁（数据产品），以后每天倒一点糖醋汁就可以很快做出一盘糖醋XX（业务应用）。
这个调制糖醋汁的过程就相当于构建了 一个数据中台，糖醋汁就是数据产品。数据产品往往不是直接提供给用户使用的，而是提供给业务应用使用的（类似于糖醋汁不是用来直接喝的，而是用来做糖醋XX的）。另外，为了调制更快更准确，可能还需要买一些密封大桶/漏斗/量杯（ETL/BI 等数据工具）。
当然，如果你家十天半个月才做一次糖醋XX(低频)，那就没有必要调制一大桶糖醋汁放那儿（不需要构建这个数据产品）。类似这个逻辑，如果你家每天都做八宝粥，则可以把八种粮食（数据）混合好放一个大桶里做成八宝粥混料（数据产品）。
如果你老妈的糖醋XX做的特别好开了个餐馆，每天做给几百个人吃（需求量变大），就需要调制更多糖醋汁买个冰箱存起来（数据仓库），这也解决了随用随跳（实时取数）的效率瓶颈。所以，在做数据中台之前，先自问一下：
有没有糖醋汁、八宝粥混料的需求？（有没有数据产品的需求？）
有多少人吃？（使用这个数据产品的需求量大不大？）
多久吃一次？（需要这个数据产品的频率高不高？）
如果以上都合理，就可以开始规划数据中台了。数据中台的核心理念在于“数据取之于业务，用之于业务”，即它相比于数据平台注重的是对业务的积累和沉淀，构建了从数据生产到消费，消费后产生的数据再回流到生产流程的闭环过程。
小结：
- 数据中台不仅仅是技术，也不仅仅是产品，而是一套完整的让数据用起来的机制。
- 数据中台通过对海量数据进行采集、计算、存储、加工，同时统一标准和口径。数据中台把数据统一之后，会形成标准数据，再进行存储，形成大数据资产层，进而为客户提供高效服务
- 数据中台是建立在数据仓库和大数据平台之上的，让业务部门可以更好、更有效率地使用数据的运营管理层。
- 数据中台需要具备数据汇聚整合、数据提纯加工、数据服务可视化、数据价值变现4个核心能力
- 前台需要快速响应前端用户的需求，快速创新、快速迭代，后台系统需要扎实稳定，建成之后往往不能随意改动，正如“变速齿轮”论，个人更倾向于 "企业架构层面（三层架构）"的架构设计来平衡前后台灵活与稳定的矛盾。
参考：
- https://www.cnblogs.com/jingsupo/p/12284133.html
- https://www.cnblogs.com/zsql/p/15762957.html
- http://www.dlwanglong.cn/news/202003/032085.html
- https://blog.csdn.net/m0_56143415/article/details/122706613
- https://www.jianshu.com/p/e6a764174e14
- https://www.cnblogs.com/xichji/p/11981554.html