什么是数据中台
在询问“什么是数据中台”之前，先来回答一下“要不要做”，毕竟建“数据中台”对于企业来说是战略级需求。所以，下面我们先来一起更加透彻地理解“数据中台”这个概念，只有彻底理解了事物的本质，才能轻松做出“适不适合”的判断，毕竟先要知根知底，才能“对症下药”。
到底什么是数据中台 ？按照网络上的定义有以下几种：
数据中台是数据服务(Data API)工厂；
数据中台是一个能够满足业务创新的一个中间层；
数据中台是指通过数据技术，对海量数据进行采集、计算、存储、加工，同时统一标准和口径
以上定义描述都不是太恰当，也不是很容易被人理解。
下面让我们来换一个角度回答以下三个问题，从而重新定义什么是数据中台：
1、它能做什么；
2、它需要什么；
3、它怎么做。
在现在的大数据时代，越来越多的企业开始重视并着手探索着数据的价值，希望通过数据运营的方式赋能业务，让数据成为企业业务增长的新能源。但是在真正落地去做数据运营、数据决策的过程当中，企业普遍都会遇到“独 - 数据烟囱式林立”、 “断 - 数据理解、认知以及分析断层”、“缺 - 缺数据、缺标准、缺治理”、“难 - 知数据难、懂数据难、要数据难”四大难题。
【数据中台四大难题】
1、独 - 数据烟囱林立：每个部门都有建立了自己烟囱式的IT系统或者建立烟囱式独立的数据分析平台和数据仓库，这样就会导致数据共享非常的难，即有数据的重复、数据平台的重复开发，同时也带来数据重复的存储，造成企业资源和成本的浪费；
2、断 - 数据理解、认知以及分析断层：数据生产者和数据消费者对于数据的理解和数据价值在认知上没有得到统一，造成理解和认知上的断层；
3、缺 - 缺数据、缺标准、缺治理：企业各个业务线没有统一的数据治理的标准、没有存储好数据，甚至没有数据，根本就不知道从哪里获取数据；
4、难 - 知数据难、懂数据难、要数据难：企业业务部门与部门之间的数据没有统一规范，要理解彼此的数据难，做互连互通就更加难。
而数据中台的产生就是为了解决以上四大题。
首先，通过整合汇集企业原有烟囱式IT系统的多个业务线和散落在多个平台的数据，让所有的数据都融合到大数据平台，建立统一的数据采集能力，同时整合大数据处理、计算、存储以及数据服务能力，通过这样的方式，来降低大数据的开发成本和使用成本；
其次，集合各个领域的数据，运用新的模式、新的创新方法，让数据产生更大价值；
最后，实现"大中台、小前台"的愿景，做到前台变成一个真正敏捷的作战单元。
第一个问题，数据中台能做什么呢。它能解决企业数据统一采集、数据统一存储、数据相互联通以及数据统一使用的能力，让一切业务数据化，一切数据业务化。
第二个问题，它需要什么。需要干净、透明、智慧的数据；需要一套标准的数据体系；需要一套完整的技术支撑能力。
第三个问题，它怎么做。首先先要以业务数据化为前提，数据标准入湖为基础，建立数据资产统一管理中心，然后才能发展成高效承载数据中台建设的数据运营平台能力中心。
总结一下，数据中台是全域级、可复用的数据资产中心与数据能力中心，可以提供干净、透明、智慧的数据资产与高效、易用的数据能力，使得业务能够数字化运营。
解释如下：
全域级：数据中台需要从最顶层的行业领域到企业的垂直领域的数据，同时需要覆盖多个领域的数据，只有覆盖了多个领域的数据汇集，才能更好的进行数据统计/分析/挖掘，发挥出数据的价值；
可复用：数据的能力、数据平台的能力、产品能力都要具备可复用性，同时也可以快速敏捷为多个前台业务部门提供技术支持
数据资产中心：不是像之前的数据仓库一样汇集在一起就是数据资产中心。还要保证数据是干净的、透明的、智慧的。
要保证数据是干净的、质量是高的、可信的，并且是没有脏数据的；
在有安全、隐私、授权、加密等数据权限机制下，可以安全的共享给其他业务线的数据；
需要的不是死数据，要活数据，要是能和业务部门业务场景相互结合的数 据，要具备能够为业务沉淀，给出业务关联的算法、数据模型
数据能力中心：具有为业务做数据运营平台的能力
数据中台建设的价值和意义
建设数据中台的价值
采、存、通、用是目前对数据中台价值最好的解释，数据中台需要具备“采 - 数据统一采集”、“存 - 数据统一存储”、“通 - 数据相互联通”、“用 - 数据统一使用的能力”四大能力，才能最终让一切业务数据化，一切数据业务化。
【数据中台四大价值】
1、采 - 数据统一采集：采用统一的数据报送方式采集企业各个业务系统的数据，促进数据与业务流程整合。主要需要采集的数据有企业内部业务数据、应用系统产生的数据、埋点数据、爬虫数据、日志数据、第三方数据等；
2、存 - 数据统一存储：通过三层/四层建模的方式对数据进行更科学的存储，使得平台能够快速支持数据快照、数据复制、远程数据同步等方式场景应用。在企业建设数据中台构建数据存储能力的同时，需要遵循可靠、可扩展、易管理、易维护四要素；
3、通 - 数据互联互通: 第一步是打通用户行为数据和业务数据的互通，比如通过数据埋点采集获取到的数据，有时间、地理位置、硬件设备和用户的购买行为、浏览记录、访问时长、停留时长等；第二步是要打通企业内部各个业务线的数据，比如企业要做产业链的上下游，就需要打通用户数据、内容数据、销售数据，结合“人”、“物”、“场景”三个维度，形成更加立体、精准、科学的画像；
4、用 - 数据统一使用：提供统一的数据服务能力，让一切业务数据化，一切数据业务化。比如有用户画像系统、广告营销系统、推荐引擎、搜索引擎等
因此，构建数据中台对于企业来说，本质上是在构建数据共享能力的中心，帮助业务解决数据存储、计算、使用的问题。同时也解决了企业烟囱式IT系统信息化建设遗留下来的各个系统之间的互通问题，并在此基础上构建属于企业新的数据智能场景的应用创新。
建设数据中台的意义
【数据中台六大意义】
从以下六个方面和大家一起去探讨，企业数据中台建设的意义：
第一、汇聚数据、打通数据链路，承上启下
数据中台最终的目标是让“一切业务数据化，一切数据业务化”，先将所有的数据汇聚到数据中台来，打通各个业务线的数据流转、数据链路，了解企业数据现状，知道有什么数据，缺什么数据。这样以后无论是做可视化BI报表分析、用户画像、推荐/搜索/广告等数据应用都统一从数据中台获取数据，如果没有数据，数据中台就要负责去寻找到数据应用相关的数据，为数据应用赋能，做业务和技术上的能力支撑，只有通过这样的方式去梳理盘点企业的数据，才能通过分析/挖掘找到更多与数据相关的应用场景。
第二、统一规范、构建数据资产，驱动业务
通过数据中台的建设，实现数据资产管理和数据治理流程的统一化、在线化、标准化、智能化，使得建设团队的人员的培养和知识面上的传承能够在线的完成。同时，企业数据中台构建高效、可复用的数据能力中心，使得业务能够通过数字化运营的方式，赋能业务、驱动业务。
第三、数据重用、减少企业成本，提高效率
汇聚数据，打通数据链路后，在为数据应用提供数据服务的时候，减少数据的重复开发、减少数据平台的重复开发，减少数据重复的存储，从而减少企业成本。同时，建立统一的数据存储、数据使用模型中心、能力中心，将相关业务领域的数据做汇聚，解决了数据互联互通的诉求，实现数据价值上的一加一大于二。
第四、数据模型、通过业务滋养，驱动创新
目前，在企业内，很多公司无论是报表需求或取数需求等，基本上都还是停留在烟囱式的IT系统，这样会导致数据知识、数据价值得不到沉淀和持续发展，数据模型不能成为真正意义上的可重用性，没有办法快速的支撑数据应用的响应与创新。
究其原因是企业团队成员对于数据模型的认知出现断层，觉得数据模型“稳定”多好啊，但是其实这种一味的稳定不变，长期下去，在某种程度上就是在故步自封，这样的做法必然会导致其他的、新的类似数据模型产生。目前的套路和做法都是把多个小表通过数据建模的方式变成一张“万能”的大宽表，这样在前期查询速度快，好维护，但是这里面会出现一个问题，就是当随着新的业务不断增加，宽表越来越大，大到后续无法维护怎么办呢？比如用户画像的标签、业务报表分析的盲从，都会导致数据运用上的堆砌以致于后续连数据一致性、数据的唯一性都保证不了，最终造成企业管理成本的增加，人力投入的增大。
所以，在构建数据模型的时候，还要考虑到数据标准与数据模型的延展性和拓展性，不能一味的追求“稳定”，应当多与业务相互结合，通过业务的不断滋养，从而才能驱动数据模型进行持续的服务创新，从最初的单一的字段到逐渐演变成企业最为宝贵的模型资产。
第五、纵观大局、创新式挖掘，推动全局
一个企业要建数据中台，一定会是企业战略级的需求，所以在汇集数据，打通数据后，还要建立统一的数据清洗的流程，得到干净、透明、智慧的数据。先试着通过一些小场景先把数据运用起来，看效果的好坏，然后才能去做其他数据应用探索，最终推动全局业务的数据应用，使得数据应用产生真正的业务价值。
第六、结合业务、探索新的场景，实现创新
目前企业都在全力谋求转型，通过数据赋能业务，然而，企业的转型和赋能的关键在于企业是否具备快速的创新能力，除了数据、算法、计算力这些核心的驱动力，是远远不够的。数据中台的能力往往最终决定在于速度上，只有速度提升上去了，才能快速小成本的方式去试错，去迭代数据运用，实现业务的创新和提升数据"变现"的能力。
总结，数据中台的建立一定不是一蹴而就的，是一个相对漫长的过程，每个企业都应该根据企业自身的实际情况，把握好短期利益和长期利益的博弈和撕杀，打造属于自己企业独有的中台能力。
在这个过程中，需要遵循一些原则：
1、在认知上，建立使用数据人员正确的数据价值观，对数据要怀有敬畏之心，合理的存储，保证收集回来数据的安全性和隐私性、互通性；
2、在流程上，需要打通企业的组织架构之间的壁垒，一定要站在企业战略层面的高度来驱动，并且有组织架构的保障，而不能像传统烟囱式IT信息化建设一样找厂商买一个套件或者单纯起一个外包项目的方式以及应用机制需要顺势而变，调整成符合数据中台建设规划的方式；
3、在工作上，需要改变原来的工作模式，所以的数据工作人员都要深入的研究业务、数据和模型，从端到端的去实践，打造出数据中台，才是最大的价值创造，才能使得持续创新成为可能；
4、在实践上，通过长期对数据的收集、整理分析/挖掘、数据资产的管理下，还需要逐步建立起数据中台对于业务的话语权，不仅只是做接受需求的一方，更要通过数据的能力，提出合理的建议，为业务带来新的增长点。只有这样，才能发挥数据真正的价值，让数据中台成为企业最为宝贵的资产。
数据仓库、数据平台和数据中台对比
在大数据时代，凡是AI类项目的落地，都需要具备数据、算法、场景、计算力四个基本元素，缺一不可。处理大数据已经不能仅仅依靠计算力就能够解决问题，计算力只是核心的基础，还需要结合不同的业务场景与算法相互结合，沉淀出一个完整的智能化平台。数据中台就是以云计算为数据智能提供的基础计算力为前提，与大数据平台提供的数据资产能力与技术能力相互结合，形成数据处理的能力框架赋能业务，为企业做到数字化、智能化运营。
目前，外界与业内很多人对于数据中台的理解存在误区，一直只是在强调技术的作用，强调技术对于业务的推动作用，但在商业领域落地的层面上，更多时候技术的发展和演进都是需要跟着业务走，技术的发展和进步需要基于业务方的需求与数据场景应用化的探索来反向推动。这个也就是为什么最近知乎、脉脉都在疯传阿里在拆“大中台”？个人猜想，原因是没有真正理解中台的本质，其实阿里在最初建设数据中台的目的主要是为了提升效率和解决业务匹配度问题，最终达到降本增效，所以说“拆”是假的，在“拆”的同时一定在“合”，“拆”的一个方面是企业战略布局层面上的规划，架构升级，如果眼界不够高，格局不够大，看到的一定只是表面；另一方面不是由于组织架构庞大而做“拆”的动作，而是只有这样才能在效率和业务匹配度上，做到最大利益化的解耦。
数据中台出现的意义在于降本增效，是用来赋能企业沉淀业务能力，提升业务效率，最终完成数字化转型。
因为，数据中台本身绝对是不可复制的，从BCG矩阵的维度结合各家市场资源、市场环境、市场地位以及业务方向来看，几乎所有企业的战略目标都是不一样的。如果，有人说能把中台卖给你、对于中台的解读只讲技术，不讲业务，只讲产品，不讲业务，不以结合企业业务目标来解决效率和匹配度为目的的都有耍流氓嫌疑。数据中台的使命和愿景是让数据成为如水和电一般的资源，随需获取，敏捷自助，与业务更多连接，使用更低成本，通过更高效率的方式让数据极大发挥价值，推动业务创新与变革。
为了进一步统一大家的认知，更加清晰的认识数据中台出现的意义，本篇按顺序介绍如下:
数据中台演进的过程
数据仓库、数据平台和数据中台的概念
数据仓库、数据平台和数据中台的架构
数据仓库、数据平台和数据中台的区别与联系
数据中台演进的过程
从数据处理的维度来聊一聊数据中台经历的四个阶段：数据库阶段、数据仓库阶段、数据平台阶段、数据中台阶段。
1、数据库阶段：OLTP（事务处理）是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，记录即时的增、删、改、查。比如银行交易、电商交易等
2、数据仓库阶段：数据仓库系统的主要应用主要是OLAP（联机分析处理），支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。比如复杂的动态报表分析、用户价值分析等
3、数据平台阶段：其实，目前业界并没有对大数据平台做统一的定义，一般情况下，只要使用了Hadoop/Spark/Storm/Flink等这些分布式的实时或者离线计算框架，建立计算集群，并在上面运行各种计算任务，具有数据互联互通、支持多数据集实时同步、支持数据资源管理、实现多源异构数据的整合管控；提供完善的大数据分析基础运行环境，提供统一二次开发接口等能力的，就算的上理解上的大数据平台。主要是为了解决大数据存储计算 + 数据应用管理 + 任务监控 + 数据资产管理 + 开发管理 + 可视化报表需求等
4、数据中台阶段：指具有全域级、可复用的数据资产中心与数据能力中心，对海量数据进行采集、计算、存储、加工，同时统一标准和口径，提供干净、透明、智慧的数据资产与高效、易用的数据能力来，能够对接OLTP（事务处理）和OLAP（报表分析）的需求，从业务架构设计到模型设计，从数据研发到数据服务，做到数据可管理、可追溯、可规避重复建设，强调的是数据业务化的能力
【数据中台经历的四个阶段】
拿电商行业来举个例子，更好的让大家理解数据中台演进的四个阶段
1、数据库阶段
电商创业早期启动非常容易，门槛相对来说较低，试错成本较少。三五个小伙伴组个小团队，做一个可以下单的前端页面，云上搭几台服务器再加上一个MySQL数据库，形成一个简单的OLTP系统，就可以给用户去使用，它的主要作用用于保证数据持久化存储和简单商品交易查询。
现在估计很多小型电商与小程序创业者的初期都是这么干的，甚至找个外包团队做完就开始对于市场试错。原因很简单，从ROI来看，项目前期业务数据量不大，简单的GB级别，每天的订单和流量数都比较少，后端数据库只要做简单的单条数据的查询和展示就能够满足了需求，根本就没有什么高并发，批量处理等高深技术，就连做在初期做数据统计/分析用Excel就足于满足需求
当用户、商品和流量上升的时候，可以采取两种过渡方案。方案一是对于查询速度慢、性能不足，升级单机配置，通过缓存优化 + 数据库优化（SQL语句优化、SQL索引优化、分库分表、SQL脚本优化）+ 内存优化 + 线程池优化 + 使用NIO通信机制 + 阻塞队列（程序优化），虚拟机（docker）+ SSD + 合适的IO模型等方式对单机配置做最大性能上的优化；方案二是改变原有的模式，加服务器和多个业务数据库，对数据库表进行分库分表加单索引、双索引以支撑业务交易的稳定和高并发，通过这种方式来支撑业务数字和指标，同样可以快速的从业务数据库里查询出来。
最终，随着客户、订单和外部流量的逐步上升，数据量从GB发展成TB级别，数据库通过普通查询存在较大的压力，只能做升级改造，于是就有了数据仓库的诞生。
2、数据仓库阶段
随着业务指数级的增长，数据量增长的同时公司的组织架构慢慢变得庞大、复杂，面临的问题也越来越多，越来越深入。公司上层关心的问题，从最初简单的想知道“昨天、今天的GMV”、“上周的PV、UV是多少”、“某品类商品的环比、同比的增长比例是多少”，慢慢演化到希望通过数据进行精细化运营和用户的价值模型分析。希望通过数据统计/分析/挖掘，分析出用户在某种特定的使用场景中，比如“18~25岁女性用户在过去三个月对服装类商品的购买行为与节假日促销活动之间的关系”。
当公司运营和高层，提出此类非常具体的case，希望通过数据统计/分析/挖掘对公司运营决策起到关键性作用的问题，其实是很难从业务数据库从直接调取出来。
原因是由于数据库是面向事务的设计，数据仓库是面向主题设计的。数据库一般存储在线交易数据，为捕获数据而设计，在设计上数据库是尽量避免冗余，一般采用符合范式的规则来设计。比如，业务数据库中的数据结构是为了完成商品交易而设计的，不是为了查询和分析的便利设计的。数据仓库存储的一般是历史数据，为分析数据而设计，在设计上是有意引入冗余，采用反范式的方式来设计。数据库和数据仓库两个基本的元素都有维表和事实表。（维表是看问题的角度，比如时间，部门、人，维表放的就是这些东西的定义，事实表里放着要查询的数据，同时有维表的ID）。
因此，数据仓库的出现，并不是要取代数据库，而是为了更好的做数据分析和报表需求分析，主要处理OLAP（联机分析处理）需求。
但是，随着客户、订单和外部流量的逐步上升，数据量从TB发展成PB级别，原来的技术架构越来越不能支持海量数据处理，这时候又有了数据平台的诞生。
3、数据平台阶段
第一、企业业务系统过多，彼此数据没有打通。涉及分析数据的过程当中，需要先从各个系统寻找到相应的数据，然后提取数据进行整合打通，才能做数据分析。在这个过程中人为进行整合出错率高，分析效果不及时，导致整体的效率低下，数据迁移、数据同步的滞后与错误；
第二、业务系统压力大，架构相对笨重，做数据分析计算消耗资源很大。需要通过将数据抽取出来，经过独立服务器来处理数据查询、分析任务，来释放业务系统的压力；
第三、性能问题，公司业务越来越复杂，数据量越来越大。历史数据的积累严重，数据没有得到使用。原始数据系统不能承受更大数据量的处理时，数据处理效率严重下降。
于是，通过整合Hadoop/Spark/Storm/Flink等分布式的离线与实时计算框架，建立计算集群，并在上面运行各种计算任务，搭建大数据平台，使得平台具有数据互联互通、支持多数据集实时同步、支持数据资源管理，实现多源异构数据的整合管控能力；可以提供完善的大数据分析基础运行环境，提供统一二次开发接口等能力的，用这些能力来解决大数据存储与计算问题，提升数据分析效率以及用户画像系统/推荐/搜索/广告系统的运用落地。
4、数据中台阶段
数据量的指数级增长，从PB发展成EB级别，为了更好的赋能业务，企业启动中台战略，打通各个业务线的数据，整合汇集数据，在底层通过技术手段解决数据统一存储和统一计算问题，在数据服务层通过数据服务化的Data API的方式，打通数据平台和前台的业务层对接，结合算法，把前台业务的分析需求和交易需求直接对接到中台来，通过数据中台处理和逻辑运算，然后在反向赋能业务，真正做到意义上的『一切业务数据化，一切数据业务化』。
数据仓库、数据平台和数据中台的概念
数据仓库是为企业所有级别的决策制定过程，提供所有类型数据支持的战略集合。它是单个数据存储，出于分析性报告和决策支持目的而创建。可以为需要业务智能的企业，提供指导业务流程改进、监视时间、成本、质量以及控制。是一个相对具体的功能概念，是存储和管理一个或多个主题数据的集合，为业务提供服务的方式主要是分析报表
数据平台是在大数据基础上出现的融合了结构化和非结构化数据的数据基础平台，变成一个集数据接入、数据处理、数据存储、查询检索、分析挖掘等、应用接口等为一体的平台，为业务提供服务的方式主要是直接提供数据集
数据中台是全域级、可复用的数据资产中心与数据能力中心，可以提供干净、透明、智慧的数据资产与高效、易用的数据能力，使得业务能够数字化运营，为业务提供服务的方式主要是提供数据服务能力
数据仓库的优势是具有元数据，通过表的方式很好的规整了数据。数据需要加工，数仓是通过分层的模式，每往上走一层，数据信息损耗会逐渐增加
数据平台优势是可以提供高级分析功能和数据资源管理中心，主要有数据互联互通，支持多数据集实时同步；支持数据资源管理，实现多源异构数据的整合管控；提供完善的大数据分析基础运行环境，提供统一二次开发接口等
数据中台具有一个全局的元数据管理系统，管理的方式同样是以表为主，粒度到字段级别。数据中台这个元信息包含了各个子存储的元信息，以数据中台需要的形态进行组织，变成数据资产管理中心，通过数据地图来来进行承载，就像互联管道一样做数据分发中转管理，可以很好的找到我们要的数据以及对数据进行关联和处理、分析，进一步加速企业从数字化转型为业务价值的过程
数据仓库、数据平台和数据中台的架构
数据仓库架构
1、采集层
从各种数据源中采集数据和存储到数据到存储在基于Hadoop分布式文件系统HDFS上，期间做ETL操作。其中数据采集一般采用Flume收集日志，采用Sqoop将RDBMS以及NoSQL中的数据同步到HDFS上
数据源主要有：日志数据（服务器日志 + 系统日志等）+ 业务数据库（Mysql、Oracle等）+ 埋点数据（服务端埋点 + 移动端埋点数据等）+ 其他数据（Excel手工录入的数据、合作伙伴提供的接口数据、第三方爬虫数据、合法购买的第三方数据等）
2、存储与分析层
主要有离线计算 + 实时计算
存储系统：基于Hadoop分布式文件系统对采集层的数据进行存储
消息系统：加入Kafka防止数据丢失
离线计算：是对实时性要求不高的部分，通常将计算结果保存在Hive中
实时计算：使用Spark Streaming、Storm消费Kafka中收集的日志数据，然后通过实时计算，将结果保存在Redis中
机器学习：用Spark MLlib提供的机器学习算法
3、共享层
通过离线和实时计算的数据分析与计算后的结果存储在数据共享层，做数据共享层，主要做数据分发和调度中心。因为通过Hive、MR、Spark、SparkSQL分析和计算的结果，是存储在HDFS上，业务和应用不可能直接从HDFS上获取数据。其中使用Kylin作为OLAP引擎做多维度分析
4、数据应用
报表展示 + 数据分析 + 即席查询 + 数据挖掘
5、任务调度与监控
数据平台架构
1、采集层
基于Hadoop分布式文件系统对采集层的数据进行存储。
结构化数据：通过两种途径抽取并存放到HDFS分布式文件系统中，能够序列化的数据，直接存放到HDFS中;不能够序列化的数据,通过数据整理后统一存放在分布式数据库环境中, 再经过序列化后和整理后还不能序列化的数据一样直接存放到HDFS中;
半结构化和非结构化数据：各种日志数据(通常序列化半结构化数据)直接存放到HDFS中;点击流和数据接口中的数据(通常序列化半结构化数据)直接存放到HDFS中；非结构化的数据直接存放到HDFS中
2、数据层
一方面，把相关业务结构化数据和有一定格式关系的半结构化的数据存放在Hadoop Hive数据仓库中，基于业务需求，按照特定的业务主题域进行数据集市的构建；另一方面把相关业务中半结构化的数据直接存放在HDFS分布
3、计算层
离线计算 + 实时计算
4、应用层
可视化数据分析报表 + 搜索/推荐/广告具体的场景应用
5、任务调度与监控
阿里数据中台架构
1、为了保证快速、高效、高质量数据接入，建立统一数据质量管理平台 + 数据能力中心
2、通过数据采集和接入为切入角度，按照业态接入内部数据（比如淘宝、天猫、盒马等）+ 外部数据（爬虫数据、第三方合作数据、埋点数据等）
3、把数据抽取到计算平台，通过以“业务板块 + 业务过程 + 分析维度”为架构去构建“数据共享中心”，构建OneData体系
4、在数据共享中心的上层，以业务/自然对象 + 萃取标签“为架构构建“数据唯一中心”，构建OneID体系，打通消费者数据体系、企业数据体系、内容数据体系等
5、经过深度加工后，得到干净、透明、智慧的数据赋能产品与业务线；通过统一的数据服务中间件“OneService”提供统一数据服务，让『一切业务数据化，一切数据业务化』
数据仓库、数据平台和数据中台的区别与联系
数据仓库、数据平台和数据中台的区别与联系：
1、在概念层面上
数据平台和数据中台的技术能力都是基于数据仓库发展而来没，在数据建设理论上一脉相承，他们处理的对象都是海量数据，服务目的、商业价值也同意类似。其实中平台和中台，两者在能力上都有对外都提供Open API服务。
一方面，中台是业务应用，不具体代表着某种技术，它不是最终用户能直接使用的，必须结合企业的各个数据业务场景；另一方面，平台是不带有业务特征性质的，主要汇集其他人的能力，整合成平台的能力，相对来说是静态的，而中台是动态变化的本身，需要通过数据驱动的方式来滋养业务，不断训练调整业务模型和业务算法提供的能力，提供给其他系统和平台集成的能力。
2、在数据层面上
数据仓库的数据来源主要来源于RDBMS，其中存储的数据格式以结构化数据为主，这些数据并非企业全量数据，而是根据企业业务需求做针对性整合、抽取。数据平台和数据中台的数据来源的期望都是全域级的数据，主要有结构化数据、半结构化数据、非结构化数据等
3、在目标层面上
数据仓库基于单机的，一旦数据量变大，会受单机容量、计算以及性能等方面的限制。主要用来做报表分析，目的性相对来说单一，只是针对相关分析报表用到基础数据，进行抽取、整合、数据清洗和分析。比如，新增一张报表，就要从底层到上层再做一次，流程上相对来说繁琐；
数据平台建立是为了解决数据仓库不能处理非结构化数据和报表开发周期长的问题以及计算和性能等问题。汇集整合打通数据，数据清洗后，当业务提出需求的时候，把业务方需要的若干个小数据集单独提取出来，以数据集的形式提供给业务方去使用；
数据中台通常会对来自多方面的基础数据进行数据清洗后，然后按照主题域的概念建立多个以事物为主的主题域；和数据平台在底层建设上都是基于分布式计算平台和存储平台，理论上可以通过无限扩充平台的计算和存储能力。目标是都是为了融合整个企业的全域级数据，打通数据之间的隔阂，消除数据标准和口径不统一的问题。
4、在应用层面上
建立在数据中台上的数据应用场景，不仅仅只是面向于数据报表开发分析与展示处理，更多是将数据变成服务化的方式，然后提供给业务系统，比如面向用户的画像系统，搜索/推荐/广告营销系统等。