一、数据仓库
数据仓库平台逐步从BI 表为主到分析为主、到预测为主、再到操作智能为目标。
商务智能（BI，Business Intelligence）是一种以提供决策分析性的运营数据为目的而建立的信息系统。是属于在线分析处理：On Line Analytical Processing(OLAP)，将预先计算完成的汇总数据，储存于魔方数据库(Cube) 之中，针对复杂的分析查询，提供快速的响应。在前10年，BI 表项目比较多，是数据仓库项目的前期预热项目（主要分析为主的阶段，是数据仓库的初级阶段），制作一些可视化 表展现给管理者。
（1）它利用信息科技，将分散于企业内、外部各种数据加以整合并转换成知识，并依据某些特定的主题需求，进行决策分析和运算；
（2）用户则通过 表、图表、多维度分析的方式，寻找解决业务问题所需要的方案；
（3）这些结果将呈 给决策者，以支持策略性的决策和定义组织绩效，或者融入智能知识库自动向客户推送。
1、数据仓库基本定义
（1）数据仓库(Data Warehouse)是一个面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non-Volatile）、反映历史变化的（Time Variant）数据集合，用于支持管理决策和信息的全局共享。其主要功能是将组织透过资讯系统之联机事务处理(OLTP)经年累月所累积的大量资料，透过数据仓库理论所特有的资料储存架构，作一有系统的分析整理，以利各种分析方法如联机分析处理(OLAP)、数据挖掘(Data Mining)之进行，并进而支持如决策支持系统(DSS)、主管资讯系统(EIS)之创建，帮助决策者能快速有效的自大量资料中，分析出有价值的资讯，以利决策拟定及快速回应外在环境变动，帮助建构商业智能(BI)。[1]：引自全球数据仓库之父 W.H.Inmon。
（2）所谓主题：是指用户使用数据仓库进行决策时所关心的重点方面，如：收入、客户、销售渠道等；所谓面向主题，是指数据仓库内的信息是按主题进行组织的，而不是像业务支撑系统那样是按照业务功能进行组织的。
（3）所谓集成：是指数据仓库中的信息不是从各个业务系统中简单抽取出来的，而是经过一系列加工、整理和汇总的过程，因此数据仓库中的信息是关于整个企业的一致的全局信息。
2、数据仓库系统作用和定位
数据仓库系统的作用能实现跨业务条线、跨系统的数据整合，为管理分析和业务决策提供统一的数据支持。数据仓库能够从根本上帮助你把公司的运营数据转化成为高价值的可以获取的信息（或知识），并且在恰当的时候通过恰当的方式把恰当的信息传递给恰当的人。
（1）是面向企业中、高级管理进行业务分析和绩效考核的数据整合、分析和展现的工具；
（2）是主要用于历史性、综合性和深层次数据分析；
（4）能够提供灵活、直观、简洁和易于操作的多维查询分析;
（5）不是日常交易操作系统，不能直接产生交易数据；
数据仓库针对实时数据处理，非结构化数据处理能力较弱，以及在业务在预警预测方面应用相对有限。
3、数据仓库能提供什么
4、数据仓库系统构成
数据仓库系统除了包含分析产品本身之外，还包含数据集成、数据存储、数据计算、门户展现、平台管理等其它一系列的产品。CXO UNION（CXO联盟）、数字化转型 、数字化 、华东CIO大会、中国数字化转型展、CDLC中国数字化灯塔大会、CXO数字化研学之旅
二、数据湖
数据湖(D图6.数据仓库产品构成ata Lake)是Pentaho的CTO James Dixon提出来的(Pentaho作为一家BI公司在理念上是挺先进的)，是一种数据存储理念——即在系统或存储库中以自然格式存储数据的方法。
1、维基百科对数据湖的定义
目前，Hadoop是最常用的部署数据湖的技术，所以很多人会觉得数据湖就是Hadoop集群。数据湖是一个概念，而Hadoop是用于实现这个概念的技术。
2、数据湖能给企业带来多种能力
数据湖能给企业带来多种能力，例如，能实现数据的集中式管理，在此之上，企业能挖掘出很多之前所不具备的能力。另外，数据湖结合先进的数据科学与机器学习技术，能帮助企业构建更多优化后的运营模型，也能为企业提供其他能力，如预测分析、推荐模型等，这些模型能刺激企业能力的后续增长。数据湖能从以下方面帮助到企业：
（1）实现数据治理（data governance）。
（2）通过应用机器学习与人工智能技术实现商业智能。
（3）预测分析，如领域特定的推荐引擎。
（4）信息追踪与一致性保障。
（5）根据对历史的分析生成新的数据维度。
有一个集中式的能存储所有企业数据的数据中心，有利于实现一个针对数据传输优化的数据服务。
（7）帮助组织或企业做出更多灵活的关于企业增长的决策。
3、数据仓库与数据湖差异
（1）在储存方面上，数据湖中数据为非结构化的，所有数据都保持原始形式。存储所有数据，并且仅在分析时再进行转换。数据仓库就是数据通常从事务系统中提取。
（2）在将数据加载到数据仓库之前，会对数据进行清理与转换。在数据抓取中数据湖就是捕获半结构化和非结构化数据。而数据仓库则是捕获结构化数据并将其按模式组织。
（3）数据湖的目的就是数据湖非常适合深入分析的非结构化数据。数据科学家可能会用具有预测建模和统计分析等功能的高级分析工具。而数据仓库就是数据仓库非常适用于月度 告等操作用途，因为它具有高度结构化。
（4）在架构中数据湖通常，在存储数据之后定义架构。使用较少的初始工作并提供更大的灵活性。在数据仓库中存储数据之前定义架构。CXO UNION（CXO联盟）、数字化转型 、数字化 、华东CIO大会、中国数字化转型展、CDLC中国数字化灯塔大会、CXO数字化研学之旅
三、数据中台
1、产生的背景
企业在过去信息化的历程中形成了大量生产经营及专业业务应用成果，同时也累积了大量的企业数据资产。限于传统的数据仓库技术手段，数据管理和分析能力成为信息化工作中的短板。企业信息系统众多，系统管理独立，数据存储分散，横向的数据共享和分析应用仅由具体业务驱动，难以对全局数据开展价值挖掘，从规模上和效果上都无法真正体现集团庞大数据资产的价值。市场竞争和产业链日益全球化，企业不只满足于内部数据的分析，更要通过互联 、微信、APP等新技术手段结合外部市场数据进行整体分析。CXO UNION（CXO联盟）、数字化转型 、数字化 、华东CIO大会、中国数字化转型展、CDLC中国数字化灯塔大会、CXO数字化研学之旅
（1）传统的数据仓库不能满足数据分析需求。
企业在数据分析应用方面呈现“五大转变”（从统计分析向预测分析转变、从单领域分析向跨领域转变、从被动分析向主动分析转变、从非实时向实时分析转变、从结构化数据向多元化转变），并且对统一的数据中台平台诉求强烈，对数据中台的运算能力、核心算法、及数据全面性提出了更高的要求。
（2）数据中台的处理架构发生了变化。
一是以Hadoop、Spark等分布式技术和组件为核心的“计算&存储混搭”的数据处理架构，能够支持批量和实时的数据加载以及灵活的业务需求。二是数据的预处理流程正在从传统的ETL结构向ELT转变。传统的数据仓库集成处理架构是ETL结构，这是构建数据仓库的重要一环，即用户从数据源抽取出所需的数据，经过数据清洗，将数据加载到数据仓库中去。而大数据背景下的架构体系是ELT结构，其根据上层的应用需求，随时从数据中台中抽取想要的原始数据进行建模分析。
2、数据中台建设是数字化转型的关键支撑
数据中台成为热点，“中台”这个概念，是相对于前台和后台而生，是前台和后台的链接点，将业务共同的工具和技术予以沉淀。数据中台是指数据采集交换、共享融合、组织处理、建模分析、管理治理和服务应用于一体的综合性数据能力平台，在大数据生态中处于承上启下的功能，提供面向数据应用支撑的底座能力。
广义上来给数据中台一个企业级的定义：“聚合和治理跨域数据，将数据抽象封装成服务，提供给前台以业务价值的逻辑概念”。
中台战略核心是数据服务的共享。中台战略并不是搭建一个数据平台，但是中台的大部分服务都是围绕数据而生，数据中台是围绕向上层应用提供数据服务构建的，中台战略让数据在数据平台和业务系统之间形成了一个良性的闭环，也就是实现应用与数据之间解藕，并实现紧密交互。
（1）敏捷前台：一线作战单元，强调敏捷交互及稳定交付的组织能力建设。
（2）业务中台：能力固化与赋能，固化通用能力，赋能前线部队，提升配置效率，加快前线响应，产品化业务化，开辟全新生态。
（3）数据中台：资产整合与共享，整合多维数据，统一资产管理，连通数据孤岛，共享数据资源，深入挖掘数据，盘活资产价值。
（4）稳定后台：以共享中心建设为核心，为前中台提供专业的内部服务支撑。
3、数据中台定义及处理架构
数据中台是指通过企业内外部多源异构的数据采集、治理、建模、分析，应用，使数据对内优化管理提高业务，对外可以数据合作价值释放，成为企业数据资产管理中枢。数据中台建立后，会形成数据API，为企业和客户提供高效各种数据服务。
数据中台整体技术架构上采用云计算架构模式，将数据资源、计算资源、存储资源充分云化，并通过多租户技术进行资源打包整合，并进行开放，为用户提供“一站式”数据服务。
利用大数据技术，对海量数据进行统一采集、计算、存储，并使用统一的数据规范进行管理，将企业内部所有数据统一处理形成标准化数据，挖掘出对企业最有价值的数据，构建企业数据资产库，提供一致的、高可用大 数据服务。
数据中台不是一套软件，也不是一个信息系统，而是一系列数据组件的集合，企业基于自身的信息化建设基础、数据基础以及业务特点对数据中台的能力进行定义，基于能力定义利用数据组件搭建自己的数据中台。
4、数据中台带来价值
数据中台对一个企业的数字化转型和可持续发展起着至关重要的作用。数据中台为解耦而生，企业建设数据中台的最大意义就是应用与数据解藕。这样企业就可以不受限制地按需构建满足业务需求的数据应用。
（1）构建了开放、灵活、可扩展的企业级统一数据管理和分析平台， 将企业内、外部数据随需关联，打破了数据的系统界限。
（2）利用大数据智能分析、数据可视化等技术，实现了数据共享、日常 表自动生成、快速和智能分析，满足集团总部和各分子公司各级数据分析应用需求。
（3）深度挖掘数据价值，助力企业数字化转型落地。实现了数据的目录、模型、标准、认责、安全、可视化、共享等管理，实现数据集中存储、处理、分类与管理，建立大数据分析工具库、算法服务库，实现 表生成自动化、数据分析敏捷化、数据挖掘可视化，实现数据质量评估、落地管理流程。CXO UNION（CXO联盟）、数字化转型 、数字化 、华东CIO大会、中国数字化转型展、CDLC中国数字化灯塔大会、CXO数字化研学之旅
四、传统数据仓库与数据中台的差异点
作为工业企业，一般采用混搭架构
推荐文章一：《中台是个什么鬼》
一、中台迷思
到处都在喊中台，到处都是中台，中台这个词在我看来已经被滥用了。
（1）在一部分人眼里：中台就是技术平台，像微服务开发框架、DevOps平台、PaaS平台，容器云之类的，人们都叫它“技术中台”；
（2）在一部份人眼里：中台就是微服务业务平台，像最常见的什么用户中心、订单中心，各种微服务集散地，人们都叫它“业务中台”；
（3）在一些人眼里：中台应该是组织的事情，在释放潜能：平台型组织的进化路线图 (豆瓣)中就提出了平台型组织和组织中台的概念，这类组织中台在企业中主要起到投资评估与投后管理的作用，类似于企业内部资源调度中心和内部创新孵化组织，人们叫它“组织中台”。
看完本篇你就会理解，上边的这几类“中台”划分还是靠谱的，更多我看到的情况是，大家为了响应企业的“中台战略”，干脆直接将自己系统的“后端”或是“后台”改个名，就叫“中台”。
中台到底是什么？它对于企业的意义到底是什么？当我们谈中台时我们到底在谈些什么？
想要寻找到答案，仅仅沉寂在各自“中台”之中，如同管中窥豹，身入迷阵，是很难想清楚的。不如换个?度，从各类的“中台迷阵”中跳脱出来，尝试以更高的视角，从企业均衡可持续发展的角度来思考中台，反推它存在的价值。
为了搞明白中台存在的价值，我们需要回答以下两个问题：
（1）企业为什么要平台化？
（2）企业为什么要建中台？
1、企业为什么要平台化？
先给答案，其实很简单：
因为在当今互联 时代，?户才是商业战场的中心，为了快速响应用户的需求，借助平台化的力量可以事半功倍。不断快速响应、探索、挖掘、引领?户的需求，才是企业得以?存和持续发展的关键因素。
那些真正尊重用户，甚?不惜调整?己颠覆?己来响应?户的企业，将在这场以?户为中心的商业战争中得以?存和发展；反之，那些在过去的成就上故步?封，存在侥幸?理希望?户会像之前一样继续追随?己的企业，则会被用户淘汰。
很残酷，但这就是这个时代最基本的企业?存法则。
平台化之所以重要，就是因为它赋予或加强了企业在以用户为中心的现代商业战争中最最最核心的能力：?户响应力。这种能力可以帮助企业在商战上先发制?，始终抢得先机。
可以说，在互联 时代，商业的斗争就是对于用户响应力的比拼。CXO UNION（CXO联盟）、数字化转型 、数字化 、华东CIO大会、中国数字化转型展、CDLC中国数字化灯塔大会、CXO数字化研学之旅
又有点远大空是不是？我们来看?个经典的例子:
例子1
说起中台，最先想到的应该就属是阿?的“?中台，?前台”战略。阿??通过多年不懈的努力，在业务的不断催化滋养下，将?己的技术和业务能力沉淀出一套综合能力平台，具备了对于前台业务变化及创新的快速响应能力。
例子2
海尔也早在?年前就已经开始推进平台化组织的转型，提出了“平台?营体?撑?线?营体”的战略规划和转型?标。构建了“?单合一”、“?户付薪”的创客文化，真正将平台化提?到了组织的?度。
例子3
华为在几年前就提出了“?平台炮火支撑精兵作战”的企业战略，“让听得到炮声的人能呼唤到炮火”，这句话形象的诠释了大平台?撑下小前台的作战策略。
这种极度灵活又威力巨?的战法，使之可以迅速响应瞬息万变的战场，一旦锁定目标，通过大平台的炮火群，迅速精准对于战场进行强大的火?支援。
可?，在互联?热火朝天，第四次工业革命的曙光即将到来的今日，企业能否真正做到“以用户为中心”，并不断提升自己的用户响应力来追随甚至引领用户的脚步，持续规模化创新，终将决定企业能否在这样充满挑战和机遇的市场上笑到最后，在商业上长久保持创新活力与竞争力。
而平台化恰好可以助力企业更快更好的做到这些，所以这回答了第一个问题——企业需要平台化。
2、企业为什么要建中台？
好，到此我们想明白了为什么需要平台化。但是平台化并不是一个新概念，很多企业在这个方向上已经做了多年的努力和积淀。那为什么最近几年“中台”这个相对较新的概念又会异军突起？对于企业来讲，传统的“前台+后台”的平台化架构又为什么不能满足企业的要求呢?
这就引出了我们的第二个问题：企业为什么要建中台？
定义一下前台与后台
（2）后台：由后台系统组成的后端平台。每个后台系统一般管理了企业的一类核心资源（数据+计算），例如财务系统、产品系统、客户管理系统、仓库物流管理系统等，这类系统构成了企业的后台。基础设施和计算平台作为企业的核心计算资源，也属于后台的一部分。
后台并不为前台而生
定义了前台和后台，对于第二个问题（企业为什么要建中台），同样先给出我的答案：
因为企业后台往往并不能很好的支撑前台快速创新响应用户的需求，后台更多解决的是企业管理效率问题，而中台要解决的才是前台的创新问题。
大多数企业已有的后台，要么前台根本就用不了，要么不好用，要么变更速度跟不上前台的节奏。
我们看到的很多企业的后台系统，在创建之初的目标，并不是主要服务于前台系统创新，更多的是为了实现后端资源的电子化管理，解决企业管理的效率问题。
这类系统要不就是当年花大价钱外购，需要每年支付大量的服务费，并且版本老旧，定制化困难；要不就是花大价钱自建，年久失修，一身的补丁，同样变更困难，也是企业所谓的“遗留系统”的重灾区。
总结下来就两个字“慢”和“贵”，对业务的响应慢，动不动改个小功能就还要花一大笔钱。
有人会说了，你不能拿遗留系统说事儿啊，我们可以新建后台系统啊，整个2.0问题不就解决了？
但就算是新建的后台系统，因为其管理的是企业的关键核心数据，考虑到企业安全、审计、合规、法律等限制，导致其同样往往?法被前台系统直接使用，或是受到各类限制?法快速变化，以?持前台快速的创新需求。
此时的前台和后台就像是两个不同转速的?轮，前台由于要快速响应前端用户的需求，讲究的是快速创新迭代，所以要求转速越快越好；?后台由于?对的是相对稳定的后端资源，?且往系统陈旧复杂，甚至还受到法律法规审计等相关合规约束，所以往往是稳定至上，越稳定越好，转速也自然是越慢越好。
所以，随着企业务的不断发展，这种“前台+后台”的?轮速率“匹配失衡”的问题就逐步显现出来。
随着企业业务的发展壮大，因为后台修改的成本和?险较?，也就驱使我们尽量选择保持后台系统的稳定性。
但因为还要响应用户持续不断的需求，自然就会将大量的业务逻辑(业务能力)直接塞到了前台系统中，引入重复的同时还会致使前台系统不断膨胀，变得臃肿，形成了一个个?泥球的“烟囱式单体应用”，渐渐拖垮了前台系统的“?户响应?”。
用户满意度降低，企业竞争力也随之不断下降。
对于这样的问题，Gatner在2016年提出的一份《Pace-Layered Application Strategy》 告中，给出了一种解决方案，即按照“步速”将企业的应用系统划分为三个层次（正好契合前中后台的三个层次），不同的层次采用完全不同的策略。
而Pace-Layered Application Strategy也为“中台”产生的必然性，提供了理论上的支撑。
Pace-Layered Application Strategy
在这份 告中Gatner提出，企业构建的系统从Pace-Layered的?度来看可以划分为三类: SOR(Systems of record )，SOD(Systems of differentiation)和SOI(Systems of innovation)。
处于不同Pace-Layered的系统因为?的不同、关注点不同、要求不同，变化的“速率”自然也不同，匹配的也需要采?不同的技术架构、管理流程、治理架构甚至投资策略。
?前面章节我们提到的后台系统，例如CRM、ERP、财务系统等，它们?多都处于SOR的Pace-Layered。
这些系统的建设之初往往是以规范处理企业底层资源和企业的核?可追溯单据(例如财务单据，订单单据)为主要?的。它们的变更周期往往比较?，?且由于法律律审计等其他限制，导致对于它们的变更需要严谨的申 审批流程和更高级别的测试部署要求，这就导致了它们往往变化频率低、变化成本高、变化?险高、变化周期?，?法满?由?户驱动的快速变化的前台系统要求。
我们又要尽力保持后台(SOR)系统的稳定可靠，?要前台系统(SOI)能够?而美，快速迭代。就出现了上文提到的“齿轮匹配失衡”的问题，感觉鱼与熊掌不可兼得。
正当陷入僵局的时候，天空中飘来一声IT谚语：
软件开发中遇到的所有问题，都可以通过增加?层抽象而得以解决!
?此，?声惊雷滚过，“中台”脚踏七彩祥云，承载着SOD(Systems of differentiation) 的前世寄托，横空出世。
我们先试着给中台下个定义：
中台是真正为前台而生的平台（可以是技术平台，业务能力甚至是组织机构），它存在的唯一目的就是更好的服务前台规模化创新，进而更好的响应服务引领用户，使企业真正做到自身能力与用户需求的持续对接。
中台就像是在前台与后台之间添加的?组“变速齿轮”，将前台与后台的速率进行匹配，是前台与后台的桥梁。它为前台而生，易于前台使用，将后台资源顺滑流向用户，响应用户。
中台很像Pace-Layered中的SOD，提供了比前台（SOI）更强的稳定性，以及?后台（SOR）更高的灵活性，在稳定与灵活之间寻找到了?种美妙的平衡。
中台作为变速齿轮，链接了用户与企业核心资源，并解决了配速问题：
有了“中台”这?新的Pace-Layered断层，我们就可以将早已臃肿不堪的前台系统中的稳定通用业务能力“沉降”到中台层，为前台减肥，恢复前台的响应力；
又可以将后台系统中需要频繁变化或是需要被前台直接使用的业务能力“提取”到中台层，赋予这些业务能力更强的灵活度和更低的变更成本，从而为前台提供更强大的“能力炮火”支援。
所以，企业在平台化的过程中，需要建设自己的中台层（同时包括技术中台、业务中台和组织中台）。CXO UNION（CXO联盟）、数字化转型 、数字化 、华东CIO大会、中国数字化转型展、CDLC中国数字化灯塔大会、CXO数字化研学之旅
3、小结
思考并回答了文初提出的两个关于中台价值的核心问题，解决了我对于中台产生的一些困惑，不知道对你有没有启发？我最后再来总结一下：
以用户为中心的持续规模化创新，是中台建设的核心目标。企业的业务响应能?和规模化创新能力，是互联?时代企业综合竞争?的核?体现。平台化包括中台化，只是帮助企业达到这个目标的?段，并不是?标本身。
中台(无论是技术中台、业务中台还是组织中台)的建设，根本上是为了解决企业响应力困境， 弥补创新驱动快速变化的前台，稳定可靠驱动变化周期相对较慢的后台之间的?盾，提供?个中间层来适配前台与后台的配速问题，沉淀能?，打通并顺滑链接前台需求与后台资源，帮助企业不断提升用户响应?。
所以，中台到底是什么根本不重要，如何想方设法持续提高企业对于?户的响应力才是最重要的。而平台化或是中台化，只是恰巧走在了了这条正确的大道上。
二、到底中台长啥样？
列举了这么多各式各样的中台，最后都扯到了组织层面，是不是有种越听越晕的感觉？好像什么东西加个“中台”的后缀都可以靠到中台上来？那估计很快就会看到例如AI中台、VR中台、搜索中台、算法中台……对了，算法中台已经有了……
让我们引用一段阿里玄难在接受采访时提到对于中台的一段我非常认同的描述：
甄别是不是中台，还要回到中台要解决的问题上，也就是我上面主要关注的问题。我认为一切以”以用户为中心的持续规模化创新”为目的，将后台各式各样的资源转化为前台易于使用的能力，帮助我们打赢这场以用户为中心的战争的平台，我们都可以称之为中台：
（1）业务中台提供重用服务，例如用户中心、订单中心之类的开箱即用可重用能力，为战场提供了强大的后台炮火支援能力，随叫随到，威力强大；
（2）数据中台提供了数据分析能力，帮助我们从数据中学习改进、调整方向，为战场提供了强大及时的雷达监测能力，帮助我们掌控战场；
（3）移动及算法中台提供了战场一线火力支援能力，帮助我们提供更加个性化的服务，增强用户体验，为战场提供了陆军支援能力，随机应变，所向披靡；
（4）技术中台提供了自建系统部分的技术支撑能力，帮助我们解决了基础设施，分布式数据库等底层技术问题，为前台特种兵提供了精良的武器装备；
（5）研发中台提供了自建系统部分的管理和技术实践支撑能力，帮助我们快速搭建项目、管理进度、测试、持续集成、持续交付，是前台特种兵的训练基地及快速送达战场的机动运输部队；
（6）组织中台为我们的项目提供投资管理、风险管理、资源调度等，是战场的指挥部，战争的大脑，指挥前线，调度后方。
所以，评判一个平台是否称得上中台，最终评判标准不是技术，也不是长什么模样，还是得前台说了算，毕竟前台才是战争的关键，是感受得到战场的残酷、看得见用户的那部分人。
前台想不想用，爱不爱用，好不好用；帮了前台多大的忙，从中台获得了多大的好处，愿意掏出多少利润来帮助建设中台，这些才是甄别中台建设对错好坏的标准。对于中台来讲，前台就是用户，以用户为中心，在中台同样适用。
推荐文章二：《十年数据技术发展趋势》
回看这几年，分布式系统领域出现了很多新东西，特别是云和 AI 的崛起，让这个过去其实不太 sexy 的领域一下到了风口浪尖，在这期间诞生了很多新技术、新思想，让这个古老的领域重新焕发生机。站在 2010s 的尾巴上，我想跟大家一起聊聊分布式系统令人振奋的进化路程，以及谈一些对 2020s 的大胆猜想。
无论哪个时代，存储都是一个重要的话题，今天先聊聊数据库。在过去的几年，数据库技术上出现了几个很明显的趋势。CXO UNION（CXO联盟）、数字化转型 、数字化 、华东CIO大会、中国数字化转型展、CDLC中国数字化灯塔大会、CXO数字化研学之旅
存储和计算进一步分离
我印象中最早的存储 – 计算分离的尝试是 Snowflake，Snowflake 团队在 2016 年发表的论文《 The Snowflake Elastic Data Warehouse 》是近几年我读过的最好的大数据相关论文之一，尤其推荐阅读。Snowflake 的架构关键点是在无状态的计算节点 + 中间的缓存层 + S3 上存储数据，计算并不强耦合缓存层，非常符合云的思想。从最近 AWS 推出的 RedShift 冷热分离架构来看，AWS 也承认 Snowflake 这个搞法是先进生产力的发展方向。另外这几年关注数据库的朋友不可能不注意到 Aurora。不同于 Snowflake，Aurora 应该是第一个将存储 – 计算分离的思想用在 OLTP 数据库中的产品，并大放异彩。Aurora 的成功在于将数据复制的粒度从 Binlog 降低到 Redo Log ，极大地减少复制链路上的 IO 放大。而且前端复用了 MySQL，基本做到了 100% 的应用层 MySQL 语法兼容，并且托管了运维，同时让传统的 MySQL 适用范围进一步拓展，这在中小型数据量的场景下是一个很省心的方案。
虽然 Aurora 获得了商业上的成功，但是从技术上，我并不觉得有很大的创新。熟悉 Oracle 的朋友第一次见 Aurora 的架构可能会觉得和 RAC 似曾相识。Oracle 大概在十几年前就用了类似的方案，甚至很完美的解决了 Cache Coherence 的问题。另外，Aurora 的 Multi-Master 还有很长的路要走，从最近在 ReInvent 上的说法来看，目前 Aurora 的 Multi-Master 的主要场景还是作为 Single Writer 的高可用方案，本质的原因应该是目前 Multi-Writer 采用乐观冲突检测，冲突检测的粒度是 Page，在冲突率高的场合会带来很大的性能下降。
我认为 Aurora 是一个很好的迎合 90% 的公有云互联 用户的方案：100% MySQL 兼容，对一致性不太关心，读远大于写，全托管。但同时，Aurora 的架构决定了它放弃了 10% 有极端需求的用户，如全局的 ACID 事务 + 强一致，Hyper Scale（百 T 以上，并且业务不方便拆库），需要实时的复杂 OLAP。这类方案我觉得类似 TiDB 的以 Shared-nothing 为主的设计才是唯一的出路。作为一个分布式系统工程师，我对任何不能水平扩展的架构都会觉得不太优雅。
分布式 SQL 数据库登上舞台，ACID 全面回归
回想几年前 NoSQL 最风光的时候，大家恨不得将一切系统都使用 NoSQL 改造，虽然易用性、扩展性和性能都不错，但是多数 NoSQL 系统都抛弃掉了数据库最重要的一些东西，例如 ACID 约束，SQL 等等。NoSQL 的主要推手是互联 公司，互联 公司的简单业务加上超强的工程师团队，NoSQL 丢掉的东西当然能用某些工具简单搞定。但最近几年大家渐渐发现低垂的果实基本上没有了，剩下的都是硬骨头。
最好的例子就是作为 NoSQL 的开山鼻祖，Google 第一个搞了 NewSQL （Spanner 和 F1）。在后移动时代，业务变得越来越复杂，要求越来越实时，同时对于数据的需求也越来越强。尤其对于一些金融机构来说，一方面产品面临着互联 化，一方面不管是出于监管的要求还是业务本身的需求，ACID 是很难绕开的。更现实的是，大多数传统公司并没有像顶级互联 公司的人才供给，大量历史系统基于 SQL 开发，完全迁移到 NoSQL 上肯定不现实。
在这个背景下，分布式关系型数据库，我认为这是我们这一代人，在开源数据库这个市场上最后一个 missing part，终于慢慢流行起来。这背后的很多细节由于篇幅的原因我就不介绍，推荐阅读 PingCAP TiFlash 技术负责人 maxiaoyu 的一篇文章《从大数据到数据库》，对这个话题有很精彩的阐述。
云基础设施和数据库的进一步整合
在过去的几十年，数据库开发者都像是在单打独斗，就好像操作系统以下的就完全是黑盒了，这个假设也没错，毕竟软件开发者大多也没有硬件背景。另外如果一个方案过于绑定硬件和底层基础设施，必然很难成为事实标准，而且硬件非常不利于调试和更新，成本过高，这也是我一直对定制一体机不是太感兴趣的原因。但是云的出现，将 IaaS 的基础能力变成了软件可复用的单元，我可以在云上按需租用算力和服务，这会给数据库开发者在设计系统的时候带来更多的可能性，举几个例子：
1、 Spanner 原生的 TrueTime API 依赖原子钟和 GPS 时钟，如果纯软件实现的话，需要牺牲的东西很多（例如 CockroachDB 的 HLC 和 TiDB 的改进版 Percolator 模型，都是基于软件时钟的事务模型）。但是长期来看，不管是 AWS 还是 GCP 都会提供类似 TrueTime 的高精度时钟服务，这样一来我们就能更好的实现低延迟长距离分布式事务。
2、 可以借助 Fargate + EKS 轻量级容器 + Managed K8s 的服务，让数据库应对突发热点小表读的场景（这个场景几乎是 Shared-Nothing 架构的老大难问题），比如在 TiDB 中通过 Raft Learner 的方式，配合云的 Auto Scaler 快速在新的容器中创建只读副本，而不是仅仅通过 3 副本提供服务；比如动态起 10 个 pod，给热点数据创建 Raft 副本（这是我们将 TiKV 的数据分片设计得那么小的一个重要原因），处理完突发的读流量后再销毁这些容器，变成 3 副本。
3、冷热数据分离，这个很好理解，将不常用的数据分片，分析型的副本，数据备份放到 S3 上，极大地降低成本。
4、 RDMA/CPU/ 超算 as a Service，任何云上的硬件层面的改进，只要暴露 API，都是可以给软件开发者带来新的好处。
例子还有很多，我就不一一列举了。总之我的观点是云服务 API 的能力会像过去的代码标准库一样，是大家可以依赖的东西，虽然现在公有云的 SLA 仍然不够理想，但是长远上看，一定是会越来越完善的。
所以，数据库的未来在哪里？是更加的垂直化还是走向统一？对于这个问题，我同意这个世界不存在银弹，但是我也并不像我的偶像，AWS CTO Vogels 博士那么悲观，相信未来是一个割裂的世界（AWS 恨不得为了每个细分的场景设计一个数据库）。过度地细分会加大数据在不同系统中流动的成本。解决这个问题有两个关键：
数据产品应该切分到什么粒度？
用户可不可以不用知道背后发生了什么？
第一个问题并没有一个明确的答案，但是我觉得肯定不是越细越好的，而且这个和 Workload 有关，比如如果没有那么大量的数据，直接在 MySQL 或者 PostgreSQL 上跑分析查询其实一点问题也没有，没有必要非去用 Redshift。虽然没有直接的答案，但是我隐约觉得第一个问题和第二个问题是息息相关的，毕竟没有银弹，就像 OLAP 跑在列存储引擎上一定比行存引擎快，但是对用户来说其实可以都是 SQL 的接口。
SQL 是一个非常棒的语言，它只描述了用户的意图，而且完全与实现无关，对于数据库来说，其实可以在 SQL 层的后面来进行切分，在 TiDB 中，我们引入 TiFlash 就是一个很好的例子。动机很简单：
1、用户其实并不是数据库专家，你不能指望用户能 100% 在恰当的时间使用恰当的数据库，并且用对。
2、数据之间的同步在一个系统之下才能尽量保持更多的信息，例如，TiFlash 能保持 TiDB 中事务的 MVCC 版本，TiFlash 的数据同步粒度可以小到 Raft Log 的级别。另外一些新的功能仍然可以以 SQL 的接口对外提供，例如全文检索，用 SQL 其实也可以简洁的表达。这里我就不一一展开了。
我其实坚信系统一定是朝着更智能、更易用的方向发展的，现在都 21 世纪了，你是希望每天拿着一个 Nokia 再背着一个相机，还是直接一部手机搞定。CXO UNION（CXO联盟）、数字化转型 、数字化 、华东CIO大会、中国数字化转型展、CDLC中国数字化灯塔大会、CXO数字化研学之旅
【CXO联盟企业会员】中国华融资产管理、柳州钢铁、永辉超市、中国金茂、中国蒙牛乳业、 易公司、五矿发展、中国铁塔、包钢钢联、海大集团、天能动力国际、四川路桥建设集团、徐工集团工程机械、中国核工业建设、远大产业、海康威视、金田铜业、快手科技、隆基绿能科技、贝壳、中国广核电力、中化国际、中国石油集团工程、中南建设、牧原食品、大秦铁路、歌尔、中国永达汽车服务、本钢板材、中信证券、中梁集团、广州汽车、南京钢铁、中储发展、华润电力、中国国际航空、美的置业、雅居乐、白银有色集团、安徽建工、浙能电力、天音通信、冠捷电子科技、怡亚通供应链、中石化石油工程技术服务、白云山医药、北京首都开发、中国旅游、紫光、海信家电、中联重科、中国东方航空、浪潮电子信息产业等。
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！