在这一年里，云计算的应用加速无疑是一个显著的趋势。主要云服务提供商都在持续实现健康的两位数增长。这一现象反映出企业在面对虚拟环境和突发封锁导致的供应链限制时，必须迅速适应。
一年前，我们在COVID-19疫情之前将云应用视为一个逻辑发展的过程，从开发测试到创建新的云应用程序，逐步采用新的SaaS服务，并随着核心企业后端应用程序的重新平台化或转型，家庭延伸逐渐显现。然而，回顾过去一年，云应用的核心是围绕那些能够帮助企业转型的新常态而展开的用例，尤其是在工作和消费日益虚拟化的环境中，企业需要调整或开发新服务，同时传统供应链也面临更大的压力。
在过去一年中，数据、分析和云服务的主题主要集中在扩展上。虽然新数据库云服务的推出相对较少（如Amazon TiMestReaM和Oracle MySQL服务），但现有服务的扩展却非常显著，包括新缓存、查询联合以及作为云原生托管服务的第二代数据库的推出（或在某些情况下重新推出）。
责任感与可解释性并重的人工智能
在过去几周中，关于人工智能（AI）在招聘中的需求和对COVID-19大流行短期影响的讨论逐渐增加，这些趋势正在塑造对AI在软件市场影响的更现实预期。
作为数据科学家，确保AI的责任性并尽量减少偏见已经是一项巨大的挑战，而当这一技术向缺乏技术背景的从业者开放时，这一挑战将更为复杂。我们无法回到过去，关闭所有公民数据科学家的大门，因此，技术必须发挥作用，以帮助确保AI的使用保持在可控范围内。可解释的AI对于确保责任感AI计划的有效性至关重要。尽管可解释的AI并不能解决所有问题（仍需人类制定自我文档模型的标准），但缺乏可解释性将使消除偏见和不公正的努力变得徒劳。
然而，在可解释的AI方面，过去一年并没有太多进展。一年前，我们在2020年展望中提到的关于AI黑匣子挑战的讨论，至今变化依然微小。例如，过去一年中，Google Cloud的披露页面几乎没有显著变化。
展望未来，尽管责任感AI在2021年不会成为一种新趋势，但我们期待由于外部法规压力，企业在可解释性方面能有所突破。科技公司需为此负责。随着AI的普及和公众对其监督需求的增加，责任感AI的目标将继续受到重视。
数据库内机器学习成为标准配置
从提供商如Microsoft、SAP、Oracle、Informatica、SAS等公司推出的第二波云原生DBaaS服务来看，似乎出现了一种新的趋势，也就是将数据密集型的处理下推到数据库中。预计在未来一年，这一趋势将继续发展。
下推处理并不是新概念，追溯到大型机计算时代，程序与数据紧密相连。更现代的表现则是数据库存储过程和触发器。随着数据库内机器学习（ML）功能的涌现，几乎所有云数据仓库DBaaS都支持某种形式的数据库内部ML模型训练和运行。这使得数据库内的机器学习成为一种标准配置，因为（1）机器学习对数据处理要求非常高，以及（2）将所有数据移动到其他地方既成本高昂又效率低下，尤其是在讨论PB级数据时。谁愿意为转移所有数据支付费用并等待数据传输完成呢？
以下是一些实例：AWS最近在RedsHift和其图形数据库Neptune中推出了ML功能预览。Microsoft在Azure Synapse Analytics管理的SQL和Spark池中支持ML模型处理。Google BigQuery能够在数据库中运行多种ML算法。Oracle则一直支持在数据库中使用R和Python进行处理。同时，Snowflake也支持与ML工具（如Dataiku、Alteryx和Zepl）集成，以及与AutoML工具（如DataRobot、Dataiku、H2O.AI和Amazon SageMaker）的协作，以实现功能工程。
数据湖与数据仓库的竞争
数据仓库与数据湖之间的争论是安德鲁·布鲁斯特的分析中最具争议的趋势之一。支持数据仓库的人认为，云原生架构为他们提供了规模优势，多模型数据支持使他们能够处理与数据湖相关的多种变化。而数据湖的支持者则认为，在数据密集型AI模型中规模问题尤为重要，使用新兴的开源技术（如Presto、Trino查询引擎和Iceberg表格式）能够使数据湖的性能几乎与数据仓库相媲美。
实际上，数据仓库和数据湖各自有其优势。虽然云数据仓库可以处理PB级数据，但对大多数企业而言，经济因素是主要障碍：在这个规模上，数据湖往往更为经济。同时，尽管查询引擎的优化在不断提升，数据湖仍然依赖于文件扫描，其效率无法与拥有可索引、压缩和过滤功能的表相提并论。
联合查询与不同数据库间的连接表用于单个查询，由于数据移动（仅限结果集）可以最小化，因此将处理推向数据存储的位置更符合云计算的特点。在云环境中，这意味着联合查询可深入云对象存储。AWS、Azure、GCP和Snowflake的数据仓库已通过联合查询或专用查询引擎进入云存储，预计Oracle和SAP在今年也将增加这些功能。
Data Lakehouse是一个新兴概念，旨在结合数据仓库与数据湖的优势。这个术语最早由Databricks提出，指的是由数据仓库和数据湖混合而成的系统。Snowflake和Informatica最近也采用了这一术语。尽管这一术语一年前才推出，但目前已得到广泛关注，预计在未来将会有更多相关讨论。Data Lakehouse不一定使用关系数据仓库作为入口，而是依赖于“开放”数据格式，最有可能是Parquet或CSV。
展望未来，我们并不希望将数据仓库重新构想为关系数据湖或数据湖屋，因为这将使其失去原有的价值。最终，开发人员的选择将主导这一方向。传统的SQL数据库开发人员可能会倾向于关系数据湖，而使用Java或Python等语言的数据科学家和开发人员可能更青睐数据湖，或者在自然怀疑得到解决后，他们或许会选择数据湖。在许多组织中，选择数据仓库、数据湖还是数据湖屋并不是一个绝对的决定。
