数据中台需求的出现，是企业数字化转型的一个标志性的转折，数据中台成为热点，标志着，“在企业信息化或者数字化的历史上，数据从来没有距离业务这么近，数字化转型正从流程优先走向数据优先”。要想从根本上理解数据中台是什么，要认识到数据和软件的关系
信息化和数字化的本质区别是：
“信息化是用软件工程技术局部支撑和改良业务，数字化是用数字化技术重塑和转型业务本身”，而数据则是构成数字化业务世界的原子材料。
数据从应用诞生的那一天开始就存在，但是，数据并不是第一天就被存储和利用的，应用和数据的发展是不同步的，数据的地位是不断演进，越来越重要的，经历了以下五个阶段：
阶段1：数据没有被存储
早期的应用，是为了解决某一个单点的问题，比如计算器，计算过程的数据是不被存储的，但是计算的过程中，数据是客观存在的。这个阶段，数据是应用的过程产物，产生即丢弃，并不被存储。
阶段2：只有少量结果数据被存储和查询
当应用的功能丰富后，软件从解决单点问题的工具演进到处理一类业务问题，从而有了多个功能模块。典型的例子是办公自动化系统、进销存系统，这个时候少量的结果数据被存储起来，并且也有了对数据的查询、统计的需求。这个时候，数据是关键业务的记录。
阶段3：数据仓库出现，数据被大量存储
接着，企业级管理系统比如ERP、MES、CRM的出现，企业管理层需要跨条线，跨职能了解和掌握整体的经营情况，从而根据这些数据来帮助企业做决策。这个时候商务智能，传统数据仓库系统应运而生的出现了，数据在企业管理中的作用开始显现。但是这个时候的数据距离业务很远，为业务提供支持的速度很慢，往往是先有了业务想法和需求，先有“领导要看什么”，然后在去采集和处理对应的数据做出什么报表给到领导
阶段4：数据的深入价值开始被挖掘
传统数据仓库还是基于流程的，原因是数据仓库的需求还是来自于预先的设计，来自于固有流程数据的整合。而这个时候，企业的业务已经有了一定的复杂度，企业管理人员希望从数据当中发现一些隐藏的未知的价值和规律。而这个时候预定义的查询条件，预定义的业务主题已经不能满足这样的需求，所以在数据仓库基础上，产生了数据挖掘的技术，业务从数据中发现市场的规律，洞察客户的兴趣，产生一些人们不知道的信息。这个阶段在市场营销、生产调度等影响因子较多，动态性较大的业务领域，数据的重要性愈加凸显。
以上四个阶段，基本上都处于“业务数据化”的阶段
阶段5：业务数据化，数据成为企业核心资产
到了数字化时代，所有的一切都被数字化的技术所重构，而数据是构成数字化世界的基础。数据如同石油一样，成为新时代的资源，从数据当中挖掘价值，从数据当中去产生创新已经成为了所有企业的共识。这个时候，数据成为了企业的核心资产，所有的业务都被数据化。
那么，数据中台到底是什么呢？
用一句话来简单的介绍，“数据中台是数据服务(Data API)工厂”，数据中台的核心是Data API。
Data API是数据中台的核心，它是连接前台和后台的桥梁，通过API的方式提供数据服务，而不是直接把数据库给前台、让前台开发自行使用数据。至于产生DataAPI的过程，怎么样让DataAPI产生得更快，怎么样让DATA API更加清晰，怎么样让DATA API的数据质量更好，这些是要围绕数据中台去构建的能力。
某多产业现代物流集团，在2017年就通过构建企业级数据中台，为业务人员提供了数据资产创新服务，将数据以API的形式提供给前台，从而将新产品从想法到上线的时间，提高了数倍。
在金融领域，所有的产品、服务、交易本身就是数据化的。我们看到最复杂的业务领域，电信行业现在的网络建设，网络优化，大部分工作都是在电脑上，利用各种工具软件来处理基站和网络的数据，将网络洞察数据转换成网络扩容需求数据，将扩容需求数据设计成网络架构数据，在讲网络架构数据处理成各种不同设备型号的配置数据，同步的产生财务、物流、服务数据等。整个过程90%的工作量在处理各类数据，最后把结果数据传递到现实世界，安排发货，安装，验收等行为。而现在所提倡的工业4.0，智能制造本身也是将生产过程数据化，在数字化世界里用数据来重构工厂本身，从而利用数字化的强大的计算能力，快速的搜索能力，数据的预测能力来增强和优化业务本身。
未来企业的业务运营，从操作本质上来讲就是加工和处理数据。数据中台就是企业的数据服务工厂，完成从数据到价值的加工过程。
传统的信息化建设过程中，数据对业务的贡献是靠人看报表，从数据中理解和发现了新的思想后，通过传统的沟通方式（开会，新需求）来对业务产生影响和指导的。
数字化时代，数据中台对于企业的价值，是加速从数据到价值的过程，提高企业的响应力。
原来从数据报表的产生到改变业务行为是以周为单位去计算的，而数据中台的价值是通过抽象和生产数据服务，更快的影响和改变业务行为本身，这就是有的企业将数据服务直接嵌入到交易系统中，实时通过数据洞察来改变业务流程和应用本身。
某金融科技企业，构建自己的实时风控数据中台，将原来的报表系统变成实时的智能预警平台，将合规评估从事后的模式，直接改变成事前的模式，就像在业务的高速公路上建设了一个个的风控检查站，检查站通过高速的建模，实时数据分析，能够在不影响业务速度的情况下，实时对来往的车辆做风控评估，如果有的车辆有风险，则实时预警。
将传统的数据服务，从事后管控的模式提高到事前评估的模式，打造高数据响应力的企业是数据中台对于业务的核心价值。
数据中台还能够为企业解决数据开发和应用开发不同步的问题。
我们要接受并认可一个现实问题，那就是，企业的数据开发是跟不上应用的开发速度，更是跟不上业务的变化速度的。这是一个不可调和解决的问题，从市场变化到业务需求，到应用开发到沉淀成数据，这三者的速度是天生不一致的，这样的不一致会带来很多的问题，包括有开发效率的问题，有团队协作的问题，有技术能力的问题。比如，为什么开发一个报表需要十几个人天，并且大部分时间都是花在找数据，对数据，算数据上。为什么同样的一个数据需求，不同的项目就要开发两边，不能共用，不能做到一个数据出口？为什么一般的Java开发人员不能掌握数据处理，ETL的能力？
数据中台就是要将这些能力都沉淀到一个体系中，变成数据开发的能力，变成可以复用，二次加工的数据服务工厂，加快数据开发和协作的速度。
我们可以广义上来给数据中台一个企业级的定义：“聚合和治理跨域数据，将数据抽象封装成服务，提供给前台以业务价值的逻辑概念”。
从T+N到T+0，数据中台将融合OLTP和OLAP，为前台业务提供更快的数据类业务服务
十几年前，数据处理的流程分成两类，联机交易处理类（OLTP）和联机分析处理类(OLAP)，分别对应两类业务需求：“T+0”和”T+N”，这是因为软件的计算能力有限，生产系统无法容纳历史数据的查询统计功能，否则就会导致海量数据的查询，拖垮生产系统的正常交易。所以不得已一个业务系统分成了两个：交易型系统和分析型系统，前者用来处理最新的交易业务，后者用来对历史的、集成的、多维的数据进行分析，支撑业务。
我们举一个常见的电商价格策略调整的场景，原来的电商系统的价格是提前设置好的录入到电商系统数据库的，电商系统是OLTP也就是在线交易系统。电商系统对于实时性能要求很高，处理的并发交易量很大，为了提高数据库的处理速度，电商系统只保存一段时间内的交易数据，而把历史数据都归档到数据仓库系统也就是OLAP系统里。电商的运营部门定期会在OLAP系统里挖掘历史数据来分析不同的商品的交易数据和价格的关系，然后决定电商系统的价格是不是需要调整。所以传统电商系统，产品价格的变化需要一个比较长的周期的。到了今天，价格本身受影响的维度越来越多，市场需要电商系统的价格能够实时的根据历史数据进行变化，这样一来，传统的OLTP和OLAP分离的架构就不能够满足业务需求了。
随着大容量高速存储技术的发展、计算能力的提升、微服务、大数据架构的出现，OLTP和OLAP在逐渐融合：应用系统能够实时的基于多维、多渠道、历史数据的分析来定制化交易流程和和行为。OLTP和OLAP从平行的关系，变成垂直的关系。
刚才举的电商的例子是互联网时代的典型场景，而对于比较传统的金融保险行业来说，目前也正面临着这样的挑战。很多保险产品的报价需要进行信息搜集，评估，审核，而这个过程就是数据的采集，建模，评估，模拟的过程，过去这样的业务都是”T+N”，就是从接到交易申请到给出结果，需要N天，而现在市场的竞争愈加激烈，更快，更准确的给出报价，所以业务要就能够尽量做到”T+0”，实时响应市场的需求。
这就意味着要把原来的OLAP的历史数据分析，建模，评估的过程和OLTP系统里的交易数据进行融合分析才能够做到。
我们观察到，从金融保险到电信制造，原来传统的”T+N”的需求都在朝”T+0”演进，大家都在寻找高响应力，快速反馈的实时分析型数据数据处理架构，将数据从原来传统的经营分析领域演进到直接参与业务交易。
所以我们认为未来的交易型系统，都会变成分析型交易系统(Analytic Transcation Processing)，具有跨域、全量数据分析的支持能力，用数据分析来支持交易的动态敏捷变化，高速响应市场和用户的需求，而OLTP和OLAP也会在云计算，微服务，大数据等技术支撑下逐渐融合。
