数据湖、数据仓库、数据中台有什么区别

数据湖、数据仓库和数据中台，他们并没有直接的关系，只是他们为业务产生价值的形式有不同的侧重。
数据湖作为一个集中的存储库，可以在其中存储任意规模的所有结构化和非结构化数据。
在数据湖中，可以存储数据不需要对其进行结构化，就可以运行不同类型的分析。
数据仓库，也称为企业数据仓库，是一种数据存储系统，它将来自不同来源的结构化数据聚合起来，用于业务智能领域的比较和分析，数据仓库是包含多种数据的存储库，并且是高度建模的。
数据中台是一个承接技术，引领业务，构建规范定义的、全域可连接萃取的、智慧的数据处理平台，建设目标是为了高效满足前台数据分析和应用的需求。
数据中台距离业务更近，能更快速的相应业务和应用开发的需求，可追溯，更精准。
数据湖、数据仓库更多地是面向不同对象的不同形态的数据资产。
而数据中台更多强调的是服务于前台，实现逻辑、标签、算法、模型的复用沉淀。
数据中台像一个“数据工厂”，涵盖了数据湖、数据仓库等存储组件，随着数据中台的发展，未来很有可能数据湖和数据仓库的概念会被弱化。
小结数据空间持续增长，为了更好地发挥数据价值，未来数据技术趋于融合，同时也在不断创新。

参考：
数据湖作为一个集中的存储库，可以在其中存储任意规模的所有结构化和非结构化数据。
在数据湖中存储数据不需要对其进行结构化，就可以运行不同类型的分析。
可以认为数据湖是一个存储企业各种各样原始数据的大型仓库，其中的数据可存取、处理、分析及传输。
数据仓库也称为企业数据仓库，是一种数据存储系统，它将不同来源的结构化数据聚合起来，用于业务智能领域的比较和分析。
数据仓库是包含多种数据的存储库，可提供结构化数据模型。
数据仓库建设可以通过ESB等工具将企业中零散、杂乱、不统一的数据进行规划整合，并将业务系统的数据经过抽取、清洗转换加载进数仓中。
数据中台泛指通过数据处理、分析等技术，对企业内外部海量数据进行采集、计算、存储、加工、分析等一系列活动，凸显数据价值，加强企业对数据的利用。
可以通过MDM主数据管理平台、DRP数据填报平台、DAP数据分析平台来支持数据中台的搭建。
数通畅联专注于企业IT架构、SOA综合集成、数据治理分析领域，感谢您的阅读与

参考：

01 数据仓库数据仓库(Data Warehouse)，也称为企业数据仓库，它是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合存储系统，它将来自不同来源的结构化数据聚合起来，用于业务智能领域的比较和分析，数据仓库是包含多种数据的存储库，并且是高度建模的。
数据仓库系统的作用能实现跨业务条线、跨系统的数据整合，为管理分析和业务决策提供统一的数据支持。
数据仓库能够从根本上帮助你把公司的运营数据转化成为高价值的可以获取的信息（或知识），并且在恰当的时候通过恰当的方式把恰当的信息传递给恰当的人。
数据仓库针对实时数据处理和非结构化数据处理能力较弱，以及在业务在预警预测等方面应用有一定的限制。
02 数据湖数据湖(Data Lake)是Pentaho公司CTO James Dixon提出来一种数据存储理念—即在系统或存储库中以自然格式存储数据的方法。
数据湖作为一个集中的存储库，可以在其中存储任意规模的结构化和非结构化数据。
在数据湖中，可以存储不需要对其进行结构化的数据，这样就可以运行不同类型的分析。
下面的定义是维基百科所给出的“数据湖”定义。
数据湖（Data Lake）是一个存储企业的各种各样原始数据的大型仓库，其中的数据可供存取、处理、分析及传输。
数据湖是以其自然格式存储的数据的系统或存储库，通常是对象Blob或文件。
数据湖通常是企业所有数据的单一存储，包括源系统数据的原始副本，以及用于报告、可视化、分析和机器学习等任务的转换数据。
数据湖可以包括来自关系数据库（行和列）的结构化数据，半结构化数据（CSV，日志，XML，JSON），非结构化数据（电子邮件，文档，PDF）和二进制数据（
数据湖能够帮助企业实现数据的集中式管理等多种能力；
数据湖融合了先进的数据科学、机器学习和人工智能技术，帮助企业构建更加优化的数据运营模型，为企业提供预测分析、推荐模型等能力，这些模型能够刺激企业能力的持续增长，不断赋能于企业增长。
数据湖能从
03 数据平台数据平台是在大数据基础上出现的融合了结构化和非结构化数据的数据基础平台，为业务提供服务的方式主要是直接提供数据集。
数据平台的出现是为了解决数据仓库不能处理非结构化数据和报表开发周期长的问题，所以先撇开业务需求、把企业所有的数据都抽取出来放到一起，成为一个大的数据集，其中有结构化数据、非结构化数据等。
当业务方有需求的时候，再把他们需要的若干个小数据集单独提取出来，以数据集的形式提供给数据应用。
大数据时代，数据平台一般被称之为大数据平台。
狭义上的大数据平台和传统数据平台的功能一致，只是技术架构和数据容量方面的不同，但广义的大数据平台通常被赋予更多的使命，它不仅存储多样化的数据类型，还具有报表分析等数据仓库的功能，以及其他数据分析挖掘方面的高级功能。
04 数据中台数据中台通过对企业内外部多源异构的数据采集、治理、建模、分析和应用，使数据对内优化管理提高业务价值，对外进行数据合作让业务价值得到释放，使之成为企业数据资产管理中枢。
数据中台建立后，会形成数据API服务，为企业和客户提供高效各种数据服务。
数据中台对一个企业的数字化转型和可持续发展起着至关重要的作用。
数据中台为解耦而生，企业建设数据中台的最大意义就是应用与数据之间的解藕，这样企业就可以不受限制地按需构建满足业务需求的数据应用。
构建了开放、灵活、可扩展的企业级统一数据管理和分析平台， 将企业内、外部数据随需关联，打破了数据的系统界限。
利用大数据智能分析、数据可视化等技术，实现了数据共享、日常报表自动生成、快速和智能分析，满足企业各级部门之间的数据分析应用需求。
深度挖掘数据价值，助力企业数字化转型落地。
实现了数据的目录、模型、标准、认责、安全、可视化、共享等管理，实现数据集中存储、处理、分类与管理，建立大数据分析工具库、算法服务库，实现报表生成自动化、数据分析敏捷化、数据挖掘可视化，实现数据质量评估、落地管理流程。
05 数据仓库 VS 数据湖相较而言，数据湖是较新的技术，拥有不断演变的架构。
数据湖存储任何形式（包括结构化和非结构化）和任何格式（包括文本、音频、视频和
根据定义，数据湖不会接受数据治理，但专家们一致认为良好的数据管理对预防数据湖转变为数据沼泽不可或缺。
数据湖在数据读取期间创建模式。
与数据仓库相比，数据湖缺乏结构性，而且更灵活，并且提供了更高的敏捷性。
值得一提的是，数据湖非常适合使用机器学习和深度学习来执行各种任务，比如数据挖掘和数据分析，以及提取非结构化数据等。
06 数据仓库 VS 数据平台由于数据仓库具有历史性的特性，其中存储的数据大多是结构化数据；
而数据平台的出现解决了数据仓库不能处理非结构化数据和报表开发周期长的问题。
通过
07 数据仓库 VS 数据中台数据仓库和传统的数据平台，其出发点为一个支撑性的技术系统，即一定要先考虑我具有什么数据，然后我才能干什么，因此特别强调数据质量和元数据管理；
而数据中台的第一出发点不是数据而是业务，一开始不用看你系统里面有什么数据，而是去解决你的业务问题需要什么样的数据服务。
在具体的技术处理环节，二者也有明显不同，数据的预处理流程正在从传统的ETL结构向ELT结构转变。
传统的数据仓库集成处理架构是ETL结构，这是构建数据仓库的重要一环，即用户从数据源抽取出所需的数据，经过数据清洗，将数据加载到数据仓库中去。
而大数据背景下的架构体系是ELT结构，其根据上层的应用需求，随时从数据中台中抽取想要的原始数据进行建模分析。
08 总结根据

参考：
一堆厂商和互联网公司出的一些概念 实际落地效果极差 还停留在PPT宣传阶段 除了互联网公司本身给一个成功案例出来 ？
还是原来的技术改个名字继续忽悠
参考：
数据湖、数据仓库、数据中台，有什么区别？
元年科技认为数据湖、数据仓库和数据中台，他们并没有直接的关系，只是他们为业务产生价值的形式有不同的侧重。
数据仓库算产品，数据中台的精髓在于其机制，数据中台不是一个产品，而是一套体系，是一种组织架构，数据中台的开发和建设既可以建立企业数据仓库基础上，也可以建立在企业大数据平台基础上，区别就在于企业的数据应用场景是否多元化。
数据湖：作为一个集中的存储库，可以在其中存储任意规模的所有结构化和非结构化数据。
在数据湖中，可以村村数据不需要对其进行结构化，就可以运行不同类型的分析。
数据仓库：1.一个相对具体的功能概念，是存储和管理一个或多个主题数据的集合。
数据仓库，也称为企业数据仓库，是一种数据存储系统，它将来自不同来源的架构或数据聚合起来，用于业务职能领域的比较和分析，数据仓库是包含多种数据的存储库，并且是高度建模的。
2.支持管理决策分析，主要应用于BI；
3.存储的数据大多是根据需求有针对性抽取的结构化历史数据，能够生成各类报表，但这些报表都无法实时产生，因此，尽管能提供部分业务价值，但不能直接影响业务。
数据中台：元年科技认为：数据中台解决的是企业数据的“存”、“通”、“用”的难题，帮助企业实现连接数据孤岛，让一切业务数据化。
数据中台是一个承接技术，引领业务，构建规范定义的，全域可连接萃取的、智慧的数据处理平台，建设目标是为了高效满足前台数据分析和应用的需求。
数据中台发展经历了四个阶段，分别是：数据库阶段、数据仓库阶段、数据平台阶段、数据中台阶段，从数据的角度来梳理这个过程分别是：1、数据库阶段，主要是OLTP（联机事务处理）的需求；
2、数据仓库阶段，OLAP（联机分析处理）成为主要需求，主要解决BI和报表需求的技术问题3、大数据平台阶段，大数据平台阶段，主要解决海量数据性能和多数据源，多异构数据的整合加工问题4、数据中台阶段，数据中台阶段更强调数据复用和共享，多业务场景服务，同时强调企业组织管理架构的提升。
更多数据中台干货知识，请
我一直是在互联网行业，就以互联网行业来说。
先大概列一下互联网行业数据仓库、数据平台的用途：整合公司所有业务数据，建立统一的数据中心；
提供各种报表，有给高层的，有给各个业务的；
为网站运营提供运营上的数据支持，就是通过数据，让运营及时了解网站和产品的运营效果；
为各个业务提供线上或线下的数据支持，成为公司统一的数据交换与提供平台；
分析用户行为数据，通过数据挖掘来降低投入成本，提高投入效果；
比如广告定向精准投放、用户个性化推荐等；
开发数据产品，直接或间接为公司盈利；
建设开放数据平台，开放公司数据；
。
。
。
。
。
。
上面列出的内容看上去和传统行业数据仓库用途差不多，并且都要求数据仓库/数据平台有很好的稳定性、可靠性；
但在互联网行业，除了数据量大之外，越来越多的业务要求时效性，甚至很多是要求实时的 ，另外，互联网行业的业务变化非常快，不可能像传统行业一样，可以使用自顶向下的方法建立数据仓库，一劳永逸，它要求新的业务很快能融入数据仓库中来，老的下线的业务，能很方便的从现有的数据仓库中下线；
其实，互联网行业的数据仓库就是所谓的敏捷数据仓库，不但要求能快速的响应数据，也要求能快速的响应业务；
建设敏捷数据仓库，除了对架构技术上的要求之外，还有一个很重要的方面，就是数据建模，如果一上来就想着建立一套能兼容所有数据和业务的数据模型，那就又回到传统数据仓库的建设上了，很难满足对业务变化的快速响应。
应对这种情况，一般是先将核心的持久化的业务进行深度建模（比如：基于网站日志建立的网站统计分析模型和用户浏览轨迹模型；
基于公司核心用户数据建立的用户模型），其它的业务一般都采用维度+宽表的方式来建立数据模型。
这块是后话。
整体架构下面的
可能叫法有所不同，本质上的角色都大同小异。
我们从下往上看：数据采集数据采集层的任务就是把数据从各种数据源中采集和存储到数据存储上，期间有可能会做一些简单的清洗。
数据源的种类比较多：网站日志：作为互联网行业，网站日志占的份额最大，网站日志存储在多台网站日志服务器上，一般是在每台网站日志服务器上部署flume agent，实时的收集网站日志并存储到HDFS上；
业务数据库：业务数据库的种类也是多种多样，有Mysql、Oracle、SqlServer等，这时候，我们迫切的需要一种能从各种数据库中将数据同步到HDFS上的工具，Sqoop是一种，但是Sqoop太过繁重，而且不管数据量大小，都需要启动MapReduce来执行，而且需要Hadoop集群的每台机器都能访问业务数据库；
应对此场景，淘宝开源的DataX，是一个很好的解决方案（可参考文章 《异构数据源海量数据交换工具-Taobao DataX 下载和使用》），有资源的话，可以基于DataX之上做二次开发，就能非常好的解决，我们目前使用的DataHub也是。
当然，Flume通过配置与开发，也可以实时的从数据库中同步数据到HDFS来自于Ftp/Http的数据源：有可能一些合作伙伴提供的数据，需要通过Ftp/Http等定时获取，DataX也可以满足该需求;其他数据源：比如一些手工录入的数据，只需要提供一个接口或小程序，即可完成数据存储与分析毋庸置疑，HDFS是大数据环境下数据仓库/数据平台最完美的数据存储解决方案。
离线数据分析与计算，也就是对实时性要求不高的部分，在我看来，Hive还是首当其冲的选择，丰富的数据类型、内置函数；
压缩比非常高的ORC文件存储格式；
非常方便的SQL支持，使得Hive在基于结构化数据上的统计分析远远比MapReduce要高效的多，一句SQL可以完成的需求，开发MR可能需要上百行代码；
当然，使用Hadoop框架自然而然也提供了MapReduce接口，如果真的很乐意开发Java，或者对SQL不熟，那么也可以使用MapReduce来做分析与计算；
Spark是这两年非常火的，经过实践，它的性能的确比MapReduce要好很多，而且和Hive、Yarn结合的越来越好，因此，必须支持使用Spark和SparkSQL来做分析和计算。
因为已经有Hadoop Yarn，使用Spark其实是非常容易的，不用单独部署Spark集群，关于Spark On Yarn的相关文章，可参考：《Spark On Yarn系列文章》实时计算部分，后面单独说。
数据共享这里的数据共享，其实指的是前面数据分析与计算后的结果存放的地方，其实就是关系型数据库和NOSQL数据库；
前面使用Hive、MR、Spark、SparkSQL分析和计算的结果，还是在HDFS上，但大多业务和应用不可能直接从HDFS上获取数据，那么就需要一个数据共享的地方，使得各业务和产品能方便的获取数据；
和数据采集层到HDFS刚好相反，这里需要一个从HDFS将数据同步至其他目标数据源的工具，同样，DataX也可以满足。
另外，一些实时计算的结果数据可能由实时计算模块直接写入数据共享。
数据应用业务产品业务产品所使用的数据，已经存在于数据共享层，他们直接从数据共享层访问即可；
报表同业务产品，报表所使用的数据，一般也是已经统计汇总好的，存放于数据共享层；
即席查询即席查询的用户有很多，有可能是数据开发人员、网站和产品运营人员、数据分析人员、甚至是部门老大，他们都有即席查询数据的需求；
这种即席查询通常是现有的报表和数据共享层的数据并不能满足他们的需求，需要从数据存储层直接查询。
即席查询一般是通过SQL完成，最大的难度在于响应速度上，使用Hive有点慢，目前我的解决方案是SparkSQL，它的响应速度较Hive快很多，而且能很好的与Hive兼容。
当然，你也可以使用Impala，如果不在乎平台中再多一个框架的话。
OLAP目前，很多的OLAP工具不能很好的支持从HDFS上直接获取数据，都是通过将需要的数据同步到关系型数据库中做OLAP，但如果数据量巨大的话，关系型数据库显然不行；
这时候，需要做相应的开发，从HDFS或者HBase中获取数据，完成OLAP的功能；
比如：根据用户在界面上选择的不定的维度和指标，通过开发接口，从HBase中获取数据来展示。
其它数据接口这种接口有通用的，有定制的。
比如：一个从Redis中获取用户属性的接口是通用的，所有的业务都可以调用这个接口来获取用户属性。
实时计算现在业务对数据仓库实时性的需求越来越多，比如：实时的了解网站的整体流量；
实时的获取一个广告的曝光和点击；
在海量数据下，依靠传统数据库和传统实现方法基本完成不了，需要的是一种分布式的、高吞吐量的、延时低的、高可靠的实时计算框架；
Storm在这块是比较成熟了，但我选择Spark Streaming，原因很简单，不想多引入一个框架到平台中，另外，Spark Streaming比Storm延时性高那么一点点，那对于我们的需要可以忽略。
我们目前使用Spark Streaming实现了实时的网站流量统计、实时的广告效果统计两块功能。
做法也很简单，由Flume在前端日志服务器上收集网站日志和广告日志，实时的发送给Spark Streaming，由Spark Streaming完成统计，将数据存储至Redis，业务通过访问Redis实时获取。
任务调度与监控在数据仓库/数据平台中，有各种各样非常多的程序和任务，比如：数据采集任务、数据同步任务、数据分析任务等；
这些任务除了定时调度，还存在非常复杂的任务依赖关系，比如：数据分析任务必须等相应的数据采集任务完成后才能开始；
数据同步任务需要等数据分析任务完成后才能开始；
这就需要一个非常完善的任务调度与监控系统，它作为数据仓库/数据平台的中枢，负责调度和监控所有任务的分配与运行。
前面有写过文章，《大数据平台中的任务调度与监控》,这里不再累赘。
总结在我看来架构并不是技术越多越新越好，而是在可以满足需求的情况下，越简单越稳定越好。
目前在我们的数据平台中，开发更多的是
这样，可以使更多的资源专注于业务之上。

参考：
描述的简单一些，也许不太准确，但是方便理解。
好比你有块地，上门种了许多农作物，你还有几个仓库，是对收货的农作物分门别放的，有的装蔬菜，有的装水果。
为了方便管理，你建了个台账，并对地块和仓库生产以及存储的物品信息进行管理，以后不敢是谁，只要查台账就能知道哪块地种了什么，哪个仓库放了什么，啥时候该浇水，啥时候能收成。
地就是数据湖，仓库就是数据仓库，台账就是数据中台。

参考：
it圈就喜欢搞各种新名词，都是国外的，软件做的一塌糊涂。