智能数据云，将改变人类使用数据的习惯，
让使用数据变得更加简单，
让最有价值的数据被看见！
Kyligence联合创始人兼CTO李扬
Kyligence成立五年多来，我们一直专注在数据服务与管理方向，目前已经服务金融、零售、制造等全球头部客户。在这个过程中，我们一直在思考，并不断和客户探讨一个话题：
数据仓库的未来，应该是什么样子？
随着海量数据高速增长、数据特征越来越多样、数据源越来越繁杂以及技术间的整合和平台间的集成带来的难度，无论是传统的数据仓库，还是近几年热门的数据湖、湖仓一体等，虽然都解决了一部分问题，但也有不少弊端显露。特别是人工智能和云计算的发展，本就该给数据服务带来更多可能，所以我想通过这篇文章谈谈我们对数据仓库发展的看法以及对未来的展望。
从数据仓库到数据湖，顾此失彼
近几年，随着数据湖、湖仓一体概念的兴起，业界对于它们与数据仓库之间的对比甚至争论始终不断。这三种技术平台在不同程度上为客户解决了一些痛点，不过随着行业需求的演变，它们的价值定位又发生了一些变化。
1
数据仓库
数据仓库（DataWarehouse）的早期概念数据集市（DataMarts）在70年代由AC尼尔森提出。年BillInmon发表了名为《业务信息系统架构》的论文，从而正式介绍了数据仓库的概念和建设方法论。随后在年，RalphKimball发表“数据仓库工具箱”介绍了维度建模。从此，数据仓库在Bill的自顶向下模式和Kimball的自底向上模式之间争吵，直到现在。
数据仓库以主题模型为核心，能够支持企业数据管理和分析的核心诉求，数据仓库本身并不“生产”任何数据，同时自身也不“消费”任何数据，数据来源于外部，并且开放给外部应用，这也是为什么叫“仓库”，而不叫“工厂”的原因。
在数仓理论发展至今的30年间，越来越多企业选用数据仓库架构作为数据平台建设的标准和核心，分层构建多维数据模型和业务模型层。下游通过ETL工具对接各类数据源进行数据整合，上游数据应用进行数据消费提供分析决策。
不过，随着互联网等数字经济的蓬勃发展，数据量呈现爆发式增长，非结构化数据、半结构化数据不断涌现，数据更新也更加频繁，数据仓库难以支持这些场景的需求，即大数据著名4V问题：volume,variety,velocity,veracity。此外，还存在无法与数仓外的数据协同的问题，尤其是目前多云、多数据源等现实，使得“数据仓库”重新形成了“数据孤岛”，让业务人员很难获得全局数据视图。
2
数据湖
数据湖（Datalake）这一技术概念在年由Pentaho公司的创始人兼首席技术官詹姆斯·狄克逊（JamesDixon）提出。它是一种将数据以原始格式存储在同一个系统或存储库的理念，以便于收集多个数据源的数据以及各种数据结构的数据。数据湖依托于可扩展的、低成本分布式存储或云对象存储，创建了一个适用于所有格式数据的集中式数据存储，可以存储包括关系数据库的数据、半结构化数据、非结构化数据甚至二进制数据，将企业中的所有数据保存于同一个存储介质中，以用于报告、可视化、分析和机器学习等用途。
数据湖以离线批处理为主，能够灵活处理和分析结构化和非结构化数据，并快速得到结果，以缓解数仓的尴尬。但数据湖缺少数据管理能力，以及对数据质量的保障。对于数据管理团队来说，尽管管理了很大的数据量，但真正哪些数据是最有价值的，却始终不得而知。
图片来源：Gartner
正如Gartner在年的MarketGuideforQueryAccelerators报告中所描述的，数据仓库期望有数据湖的可扩展性，而数据湖则希望有数据仓库的企业级分析和管理能力。
3
湖仓一体，进阶之路
湖仓一体的概念最早起源于Databricks提出的Lakehouse：它是一种开放的架构，结合了数据湖和数据仓库特点，直接在数据湖的低成本存储上，实现与数据仓库中类似的数据结构和数据管理功能。在具体实现上，Databricks通过DeltaLake这款基于ApacheParquet加强升级的存储产品，实现了诸如事务支持、模式执行（SchemaEnforcement）等传统数据湖相对薄弱的能力，提供了一种“湖中建仓”的可能。除了DeltaLake，目前业界也有相同定位的其他产品，例如Netflix开源的Iceberg和Uber开源的Hudi等。
图片来源：Databricks
湖仓一体的概念非常具有吸引力，提供灵活的多样性算力和存算分离方案。但是在实际客户场景中，仍面临以下的问题：
所有数据通过“ETL”或者数据处理来存放到一起，不管是云存储还是分布式存储，依然要求“集中”式的管理所有数据；
湖仓一体提供的数仓能力，相比传统数仓来说仍然是有限的，例如不支持跨表的事务、外键检查等能力，以及一些企业级能力；
用户往往已经在数仓建设上有大量的投入，例如大量的业务应用、成百上千个ETL任务，迁移工作量巨大无比。
更有甚者，将Hadoop和MPP数据仓库糅合在一起，希望通过捆绑的方式同时来提供湖和仓的能力，让不同的分析负载用不同的技术平台来承载，来支持复合负载。经过我们的实践以及对业界的观察，这个方案虽然看上去很美好，但运维复杂、技术栈不一，从而给整体的运维、稳定性、可管理性等都带来了巨大的挑战。
那么，还有没有更好的解决方案？
智能数据云让使用数据更简单！
在讨论“下一代”之前，我们先来看看时代大背景有了哪些变化，哪些前提和假设与之前有了不同：
从专家到平民分析师：被使用的数据才是资产，不被使用的数据则是负债。过去，使用数据和解释数据是少数专家的权力。要充分发挥数据的价值，必须有越来越多的普通人来使用数据。这意味着“数据分析师”的人数将成百倍的增加，所以数据系统如何降低使用门槛，如何应对成百倍上升的工作负载，将成为极大的挑战；
数据从汇聚到注定分散：随着世界各国严控数据安全，欧洲有GDPR，中美有各自的数据安全法，对跨国企业来说，建立一个集中型的数据湖已经不可能。此外，出于行业数据管控的目的，亦或防止被存储厂商锁定，多云、混合云部署在国内也成为趋势。因此，对于数据孤岛的整合思路将由汇聚（Collect）渐渐转向联接（Connect）。
从“已知”到“未知”：要想领跑数字化转型，企业仅重复已知的数据应用场景已经不够了，更需要的是一种数据创新的能力，探索未知的数据关联，发现未知的业务规律，开创未知的数据应用场景。
图片来源：Gartner
不难看出，对于今天的数据仓库和数据湖产品而言，在以上大背景下提出的新需求都难以满足。尤其是目标用户由专家转变为普通人这一点，意味着今天所有以关系模型和SQL为基础的数据服务都存在过高的技术门槛。原因很简单，我们不可能要求普通人先学会关系数据库原理，理解了表、视图、主键外键、Join运算等知识之后，才能使用数据服务，这是不现实的。
那么，下一代普通人也能用的数据仓库，
应该是什么样的呢？
智能数据云
我们称之为智能数据云（IntelligentDataCloud），它让使用数据像使用水、使用电一样方便，人人都能随取随用，自助使用。
从技术角度来看，智能数据云是之前数据仓库、数据湖、湖仓一体等技术体系的继承和延续，既有数据湖低成本的存储可扩展性，也有数据仓库的强化数据结构和数据管理能力。同时，在此之上，智能数据云提供更高一层的业务数据对象管理能力，并从业务对数据的读写需求出发，使用AI增强的方式自动化和简化技术层面的人工数据操作和数据管理。向外，智能数据云提供普通人可用的数据服务；向内，智能数据云以业务为导向自动化数据的操作和管理。
1
智能数据云的主要功能
管理数据的业务语义（BusinessSemantics），将管理目标从技术对象上升到业务对象；
围绕业务数据对象，提供普通业务人员可使用的数据视图、数据探索和数据创新等服务；
穿透业务层面和技术层面，提供统一的元数据管理和数据治理；
同时支持面向汇聚（Collect）和面向联接（Connect）的数据整合，不强迫数据移动；
AI增强的自动化调优和运维，如自动查询加速、自动业务建模、无代码ETL等；
继承数据湖、数据仓库、湖仓一体等现有体系的优势，如半结构化数据支持、事务支持、BI支持、流式处理、机器学习、数据开放性等。
2
智能数据云架构图
智能数据云架构图如下图所示，我们来自下而上介绍一下：
共享的数据目录SharedDataCatalog
汇聚各个数据源的数据目录，在整个智能数据云中共享。这是元数据级别的汇总，数据本身可以移动，也可以不移动，这点显著区别于数据湖。在企业内通过众筹模式，数据专家们可以协作标记、过滤、排序、整合、置信，最终共同维护一个共享数据目录。当数据源众多，人工智能爬虫可以代替人扫描所有数据源，收集信息和处理文字，自动生成一个初始的数据目录。
业务语义增强BusinessSemanticsEnrichment
为数据目录补充业务信息上下文，形成知识图谱和语义网络，构成了业务语义层的下半部分。有了业务语义，能让IT以外的普通业务人员也看懂数据、使用数据、甚至通过关联整合创造新的数据集。同时，带语义的元数据也能更好地指导人工智能，以业务目标为导向，自动优化整个数据系统。
业务数据对象BusinessDataObjects
即业务层面的数据对象，如指标、标签、多维分析模型、图模型等，有了业务语义描述，就构成了业务语义层的上半部分。业务数据对象通过组合多个技术数据对象计算而来，如关系表、视图等。为提升性能，业务数据对象可以有自己的储存实体，如索引、物化视图等。或根据监管审计要求，业务数据对象也可以仅以虚拟形式存在，在查询时穿透到各个数据源，联合在线计算。业务数据对象通常被组织成层级结构，如：数据实体业务对象主题主题域，形成企业级信息架构，以用作统一的数据治理和安全管控。
数据运维自动化DataOpsAutomation
由于业务语义增强打通了数据的技术定义和业务定义，绝大部分的数据运维将以无代码（或低代码）的自动化方式运行。用户只需