原标题：2021年数据展望，第一部分：人工智能和云数据仓库的未来
如果说有一个明显的预测在这原本不可预测的一年里得到了证实，那就是云计算应用的加速。只要看看每一个主要的云持续着非常健康的两位数增长率。对于企业来说，这是为了适应虚拟环境和突然被封锁的世界中受限的供应链。
一年前（COVID之前），我们将云应用视为一系列逻辑阶段，从DevTest到开发新的云中应用程序，机会性采用新的SaaS服务，随着核心企业后端应用程序的重新平台化或转型，家庭延伸现在进入视野。但是事后看来，过去一年云应用的标题是针对用例的，这些案例使企业能够转向新的常态–在工作和消费日益虚拟化的情况下，更改或开发新服务的需求，以及传统供应链面临压力的地方。
在过去的一年里，数据、分析和云服务的主要主题是扩展。我们看到新的数据库云服务的推出相对较少（Amazon Timestream和Oracle MySQL服务是今年的主要推出内容），而是现有服务的扩展，包括新的缓存、查询联合，以及作为云本机托管服务的第二代数据库的推出（或在某些情况下重新推出）。
负责任的AI和可解释的AI将并驾齐驱
我们不会在这里耙海滨。在过去的几周中，这些页面已经看到了有关人类智能作用的预测；职位招聘中对AI的需求; 在短期影响对AI的COVID大流行，这在长期正在锻炼的更现实的期望对于AI在软件市场的影响。
如果您是一名数据科学家，确保AI负责任并尽可能减少偏见就足够具有挑战性；当您向技术较少的从业人员敞开大门时，这一挑战就变得更大。我们没有办法倒转时钟，关闭所有这些公民数据科学家的大门。因此，技术将必须伸出援手，以帮助使AI处于直线和狭窄状态。可解释的AI对于使负责任的AI计划有效是必不可少的。尽管可解释的AI不会是万能药（需要人类来开发如何建立自我文档模型的标准），但如果没有可解释性，则消除偏见和不公平的努力就等于是轻率的努力。
面临的挑战是，在过去的一年中，我们在可解释的AI方面没有看到太多进展。一年前，我们在2020年的展望中概述了使AI摆脱黑匣子的挑战，并猜测在过去一年中，可解释AI的局限性变化相对较小。例如，在随后的12个月中，Google Cloud的披露页面发生了微小的变化。
展望未来，负责任的AI不会在2021年成为新趋势。但是，我们确实希望，由于法规的外部压力，由于法规的外部压力，将在解释性方面进行新的努力。科技公司负责。随之而来的是，随着AI越来越普及，以及随着公众监督需求的不断增长，负责任AI的目标将继续成为目标。
数据库内机器学习成为复选框项
乍一看，从提供商到Microsoft、SAP、Oracle、Informatica，SAS以及其他提供单独的计算，存储和微服务的提供商的第二波云原生DBaaS服务似乎正以另一种趋势出现：所谓的“将数据密集型流程下推”到数据库中。在来年，我们将看到更多两者。
推动下推并不是什么新鲜事。从一个角度来看，可以将其追溯到大型机计算的曙光中，程序和数据是互锁的，但是更现代的表现形式是数据库存储过程和触发器，它们实际上是Sybase的名片（以及为什么华尔街客户顽固地存在的关键）被一个不稳固的平台所困，我们希望SAP能够在1990年代注入新的生命。
随着数据库内ML功能的涌现，我们已经看到了这一点。几乎每个云数据仓库DBaaS都支持某种形式的数据库内部ML模型的训练和运行。数据库内ML已成为一个复选框项，因为（1）ML对于数据非常繁琐，并且（2）当有替代的方式处理所有数据时，移动所有这些数据既昂贵又效率低下。而且无论如何，在某些情况下，我们可能要讨论PB级的数据。谁愿意为转移所有费用付费，然后等待所有数据转移？
这里有一些例子。AWS最近宣布了Redshift及其图形数据库Neptune中的ML功能预览。Microsoft支持在由Azure Synapse Analytics管理的SQL和Spark池中处理ML模型。Google BigQuery支持在数据库中运行大约十种不同类型的ML算法。Oracle长期以来一直支持数据库内R和Python处理。同时，Snowflake支持使用ML工具（例如Dataiku，Alteryx和Zepl）中的SQL下推功能，以及与AutoML工具（例如DataRobot，Dataiku，H20.ai和Amazon SageMaker）的集成来支持功能工程。
在湖边小屋放松
数据仓库与数据湖之间的争夺是安德鲁·布鲁斯特（Andrew Brust）的综述中争议最大的趋势。本质上，话语可以归结为这一点。数据仓库支持者称其为云原生架构为他们提供了规模，并且多模型数据支持使他们能够支持与数据湖相关的各种变化。数据湖的支持者认为，大小问题尤其重要，尤其是当您运行数据密集型AI模型时，新兴的开源技术（例如Presto，Trino查询引擎；表格式如Iceberg）可以使数据湖的性能几乎与数据一样好仓库。
现实情况是，数据仓库和数据湖各自具有各自不同的优势。是的，云数据仓库现在可以冒险进入PB领域，但是对大多数企业而言，障碍是经济的：在这些规模上，数据湖通常会更经济。同样，无论查询引擎如何优化，数据湖都依赖于文件扫描，而这种效率永远不会像拥有可以对数据进行索引，压缩和过滤的表那样高效。
联合查询与来自不同数据库的联接表相关联以进行单个查询。由于数据移动（仅结果集）可以被最小化，因此将处理推进到数据所处的位置更适合云计算。在云中，这意味着联合查询以深入到云对象存储。来自AWS，Azure，GCP和Snowflake的数据仓库已经通过联合查询或他们自己的专用查询引擎进入了云存储，我们期望Oracle和SAP今年将增加这些功能。
Data Lakehouse是一个新手，它可以在联盟查询离开的地方进行选择。它是一年前由Databricks引入的，它是指由数据仓库和数据湖混合而成的系统。这个词已由Snowflake借用，最近又被Informatica接受（我们将在本周晚些时候对此发表更多看法）。对于仅仅在一年前推出的一个术语，此时，三分之二的人群非常多，这意味着我们可能会在来年看到更多这个术语。Data Lake房屋不一定使用关系数据仓库作为入口点，而是依靠“开放”数据格式，最有可能是Parquet或CSV。
展望未来，我们并不希望将数据仓库重新构想为关系数据湖或数据湖屋，否则一定会使其过时。最终，将由您的开发人员来推动选择。传统的SQL数据库开发人员可能会选择关系数据湖，而使用Java或Python之类的语言的数据科学家和开发人员可能更喜欢数据湖，或者，如果他们的自然怀疑论得到了解决，则可能会选择数据湖。在许多组织中，在数据仓库，数据湖或数据湖屋之间进行选择不是一个决定性的决定。
