大数据平台随着业务的发展，其架构也在不断演进，数据接入更实时更全面，数据计算更实时，数据标准更统一，朝着数据融合存储，流批一体化架构方向演进。从数据仓库到数据湖，支持数据的实时变更，支持各类数据的融合存储。从文件数据供给到数据服务API提供，数据服务价值更显性化。

数据湖与数据仓库不同

架构方案对比

优点是目前主流方案，保护原有投资，数据准确度高，不易出错；缺点是架构复杂，运维成本高。

优点是架构相对简化，数据来源单一，共用一套代码，开发效率高；缺点数据全部存在队列中，计算资源要求高。

优点是自由度高，可以满足数据分析师的实时自助分析需求，减轻了计算引擎的处理压力；缺点是必须要求消息队列中保存存量数据，且因为是将计算部分的压力转移到了查询层，对查询引擎的吞吐和实时摄入性能要求较高。

我们逐渐将架构划分为数仓和数据库的双层架构，把数据先加载到数据湖中，通常我们会选择Hadoop数据库作为自建数据湖。如果要做高效的查询或者报表的输出，我们会对数据再加工，放入高性能的数仓中，如ClickHouse或Doris等。

针对传统意义的数据湖，若在对象存储或者Hadoop上能够构建出具备数仓语义的一个格式，使得我们在湖上的格式有更强的能力去做数仓，则需要具备几个条件：

湖上可靠的数据管理：即需要一种开放的高性能的数据组织方式。采用传统方式定义表时，缺乏一种高效的表的组织方式。我们通常用 Hive表，它就是一个目录，没有特殊的能力。我们需要一种更高效的组织能力，兼顾一些仓的特性。
支持机器学习和数据科学：湖仓一体的技术需要有一套开放的标准或者开放的接口。大家在用数仓的时候，会发现它是存算一体的数仓，存储就是为了计算所定制。虽然性能很好，但不开放，也就是所有的生态都要建立在上面，但数据湖则是天然开放，Flink和Spark等其他引擎都能使用这些数据。
最先进的SQL性能：若湖仓一体只是湖，那么很轻易就能办到，但是它的性能会比较差。如果要使表具备仓的性能，比如能够匹敌类似Snowflake或者Redshift这样的性能，则需要一个高性能的SQL引擎，这也是Databricks做了Photon引擎的原因，有了这些，我们就可以真正在湖上构建出一个高性能的数仓，也就是“湖仓一体”。