混合服务/分析处理（HSAP）或将取代大数据

混合服务/分析处理（HSAP）具有强大的分析能力，那么会取代大数据技术吗？大数据的下一步发展是什么？

由于侧重点不同，传统数据库可以分为以事务为中心的联机事务处理 （OLTP） 系统和以分析为中心的联机分析处理（OLAP）系统。随着国际互联网的发展，数据量呈指数级增长，离线数据库已经无法满足企业的业务需求。特别是在分析领域，查询可能需要遍历大部分数据甚至全部数据，而海量数据带来的压力使得采用新技术变得尤为紧迫。这推动了过去十年左右以Hadoop技术开始的大数据革命，并满足了对海量数据分析的需求。与此同时，在数据库领域出现了几种分布式数据库产品，以应对联机事务处理 （OLTP）场景数据的增长。

为了分析联机事务处理 （OLTP）系统中的数据，标准做法是定期（例如每天）将联机事务处理 （OLTP）系统中的数据同步到联机分析处理（OLAP）系统。该架构确保分析查询不会影响在线事务处理。但是，定期同步导致分析结果并不是基于最新数据，并且这种延迟可能使企业失去及时做出业务决策的机会。为了解决这个问题，近年来出现了混合事务分析处理（HTAP）架构，它使企业能够直接分析联机事务处理 （OLTP）数据库中的数据，从而确保分析的及时性。分析不再是传统联机分析处理（OLAP）系统或大数据系统的独特功能。那么一个问题是：由于混合事务分析处理（HTAP）具有分析能力，它将取代大数据系统吗？大数据的下一站是什么？

背景介绍

为了回答这个问题，以下将以推荐系统为例来分析大数据系统的典型场景。

当购物应用程序推荐人们想要购买的商品，以及播放喜欢的音乐时，推荐系统将发挥其神奇的作用。高级推荐系统的核心目标是根据用户的实时行为进行个性化推荐。用户与系统之间的每次交互都会实时优化下一次体验。为了支持这样的系统，大数据技术堆栈已经发展成为一个非常复杂且分散的系统。

为了提供高质量的实时个性化推荐，推荐系统非常依赖于实时功能和模型的持续更新。

实时功能可以分为两类：

推荐系统将收集大量用户行为事件（如浏览、点击等）和交易记录（如从OLTP数据库同步的支付记录等）。这些数据量非常大（流量可能高达每秒数千万甚至数亿条），而且大部分数据都不是来自交易系统。为了方便以后的使用，这些数据将导入到系统中，同时将它们与各种维度表数据相关联，推导出一系列重要特征，并实时更新到推荐系统中，优化用户体验。这里的实时维度表关联需要低延迟和高吞吐量的点检查支持，以跟上新生成的数据。

推荐系统还将使用滑动窗口和其他方法来计算各种维度和时间粒度的特征（例如，过去5分钟的点击次数，过去7天的观看次数，以及过去30天内某一商品的销售额等）。根据滑动窗口的粒度，这些聚合可以通过流计算或批处理来完成。

这些数据还用于生成实时和离线的机器学习样本，经过验证的模型将在推荐系统中不断更新。

以上解释的是高级推荐系统的核心部分，但这只是整个系统的冰山一角。此外，还需要一套完整的系统，如实时模型监控、验证、分析和调整，其中包括：使用实时大屏幕查看A/B测试结果、使用交互式分析用于商业智能，以及优化和调整模型。此外，运营部门还将使用各种复杂的查询来深入了解业务进展情况，并利用客户定位和产品推荐进行有针对性的营销。

这个例子展示了一个非常复杂但典型的大数据场景，从实时数据导入到预聚合，从数据服务、连续聚合、到交互式查询再到批处理。这种复杂的场景对大数据系统的需求非常多样化。在构建这些系统的实践中，可以看到两个新趋势。

（1）实时：业务需要从刚刚收集的数据中快速获得业务洞察力。写入的数据需要在几秒钟内可见。漫长的离线ETL（抽取、转换、加载）流程变得令人无法忍受。与此同时，所收集的数据远远超过从联机分析处理（OLAP）系统同步的数据，事件日志数据（例如用户浏览和单击）甚至比其大几个数量级。企业的系统需要能够提供低延迟查询功能，同时以极高的吞吐量写入数据。

（2）混合服务和分析：传统的联机分析处理（OLAP）系统通常在业务中扮演相对静态的角色。可以通过分析数据来获得业务洞察力（例如预先计算的视图和模型等），并基于获取的知识通过另一个系统提供在线数据服务。这里的服务和分析是一个分散的过程。与其相反，理想的业务决策过程通常是持续优化的在线过程。服务过程将生成大量新数据，需要对这些新数据进行复杂的分析。分析产生的见解会实时反馈给服务，以创造更大的商业价值。服务和分析正在形成一个闭环。

现有解决方案通过一系列产品的组合来满足实时服务/分析融合的需求。例如，通过Apache Flink进行数据的实时预聚合，聚合的数据将存储在提供多维分析的产品（如Apache Druid）中，而数据服务将通过诸如Apache HBase之类的产品提供。这种烟囱开发模式将不可避免地生成数据孤岛，从而导致不必要的数据重复。各种产品之间复杂的数据同步也使数据的一致性和安全性成为一个挑战。这种复杂性使应用程序开发难以快速响应新需求，影响了业务的迭代速度，还给开发、操作和维护带来了额外的大量开销。

专家认为，实时服务/分析集成应通过统一的混合服务/分析处理（HSAP）系统实现。通过这样一个系统，应用开发不再需要处理多个不同的产品，也不再需要学习和应用每个产品的问题和局限性，可以显著简化业务架构，提高开发和运行效率。这样一个统一的系统可以避免不必要的数据重复，从而节省成本。同时，该体系结构还可以为系统带来二级甚至亚二级的实时性能，使业务决策更加实时，从而使数据发挥更大的商业价值。

尽管分布式混合服务/分析处理（HSAP）系统具有实时分析功能，但无法解决大数据的问题。

首先，事务系统同步的数据只是实时推荐系统需要处理的数据中的一小部分。大多数其他数据来自日志等非事务系统（用户在每次购买前通常有几十甚至数百次的浏览行为）。大多数分析都是在这些非事务数据上进行的。但是，混合事务分析处理（HTAP）系统没有这部分数据，因此无法进行分析。

这些非事务数据能否写入混合事务分析处理（HTAP）系统进行分析？以下分析一下混合事务分析处理（HTAP）系统和混合服务/分析处理（HSAP）系统在数据写入模式上的差异。混合事务分析处理（HTAP）系统的基础和优势是支持细粒度的分布式事务。事务性数据通常以许多分布式小事务的形式写入混合事务分析处理（HTAP）系统。但是，来自日志和其他系统的数据并没有细粒度分布式事务的语义。如果要将这些非事务性数据导入到混合事务分析处理（HTAP）系统中，必然会带来不必要的开销。

与其相反，混合服务/分析处理（HSAP）系统不需要这种高频分布式的事务。混合服务/分析处理（HSAP）系统中通常有两种数据写入模式：

（1）海量单笔记录的实时写入;

（2）频率相对较低的分布式批处理数据写入。

这使混合服务/分析处理（HSAP）系统可以进行一系列优化设计，从而提高成本效益，并避免由于将非事务性数据导入混合事务分析处理（HTAP）系统而导致的不必要的开销。

即使企业不在乎这些支出，假设可以不计成本地将所有数据写入混合事务分析处理（HTAP）系统中，那么能否解决问题？其答案是否定的。

支持联机事务处理 （OLTP）方案是混合事务分析处理（HTAP）系统的先决条件。为此，混合事务分析处理（HTAP）系统通常采用基于行存储的数据格式，而基于行存储中的分析查询效率大大低于列存储。具有分析能力并不等于能够有效分析，为了提供有效的分析功能，混合事务分析处理（HTAP）系统必须将大量非事务数据复制到列存储中，但这势必带来大量成本。最好以较低的成本将少量事务数据复制到混合服务/分析处理（HSAP）系统，同时，可以更好地避免对在线事务系统的影响。

因此，混合服务/分析处理（HSAP）和混合事务分析处理（HTAP）将会互补，并将分别引领数据库和大数据的发展方向。

混合服务/分析处理（HSAP）面临的挑战

作为一种全新的架构，混合服务/分析处理（HSAP）面临着与现有大数据和传统联机分析处理（OLAP）系统截然不同的挑战。

高并发混合工作负载：混合服务/分析处理（HSAP）系统需要处理的并发查询远远超出了传统的联机分析处理（OLAP）系统。

实际上，数据服务的并发性远远超出了联机分析处理（OLAP）查询。例如，人们在实践中已经看到，数据服务每秒需要处理数千万个查询，这比联机分析处理（OLAP）查询的并发性要高出5个数量级。同时，与联机分析处理（OLAP）查询相比，数据服务查询对延迟的要求更加严格。而且，更大的挑战是系统在提供数据服务查询的同时需要处理非常复杂的分析查询。这些混合查询有效载荷在延迟和吞吐量之间具有不同的权衡。如何有效利用系统资源来处理这些完全不同的查询，并确保每个查询的服务水平目标（SLO）是一个巨大的挑战。

混合服务/分析处理（HSAP）系统在处理高并发查询负载的同时，还需要支持海量数据的实时写入。实时写入的数据量远远超过了传统联机分析处理（OLAP）系统的要求。例如，以上实时推荐场景将持续每秒写入数千万甚至数亿个事件。与传统联机分析处理（OLAP）系统的另一个区别是混合服务/分析处理（HSAP）系统对实时数据的要求很高。为了确保服务和分析结果的效率，其书面数据需要在几秒钟甚至几秒钟内可见。

灵活性和可扩展性：数据写入和查询的负载可能会出现突发峰值，这对系统的灵活性和可扩展性提出了很高的要求。在实际应用中，注意到数据写入的峰值可以达到平均值的2.5倍，查询的峰值可以达到平均值的3倍。此外，数据写入和查询的峰值不一定同时出现，这也要求系统具有根据不同峰值进行快速调整的能力。

混合服务/分析处理（HSAP）的系统设计

为了应对这些挑战，典型的混合服务/分析处理（HSAP）系统可以采用以上相似的架构。

存储和计算的存储分解：所有数据都存储在分布式文件系统中，企业通过切分来扩展系统。存储管理器将管理这些碎片。资源管理器对系统的计算资源进行管理，保证系统能够处理高吞吐量的数据写入和查询要求。该架构可以随着工作负载的变化而快速扩展，当查询负载变大时可以扩展计算资源，当数据量快速增长时，可以快速扩展存储资源。存储和计算的分离确保了这些操作可以快速完成，而无需等待数据的移动/复制。该架构显著简化了操作和维护，为系统的稳定性提供了保证。

统一实时存储：为了支持各种查询模式，统一的实时存储层至关重要。查询可以大致分为两种类型，一种是点查询（其中大多数是数据服务类型），另一种是扫描大量数据的复杂分析查询（其中大多数是分析类型）。当然，两者之间有许多查询。这两种查询类型也对数据存储提出了不同的要求。基于行的存储可以更有效地支持点查询，而列存储在支持具有大量扫描的查询中具有明显的优势。需要在行存储和列存储之间做出折衷，但其代价是在检查和扫描数据的情况下无法获得优质性能。希望在两种情况下都能达到优质效果，因此系统同时支持行存储和列存储，并且用户可以根据方案选择每个表的存储。对于同时具有两个需求的表，允许用户通过索引抽象同时选择两种存储，系统通过索引维护机制确保两者之间的一致性。在实践中，发现此设计带来的效率和灵活性可以更好地支持业务。

工作负载隔离

通过计划来保证在混合工作负载下系统的服务水平目标（SLO）。在理想情况下，大型查询应该能够利用所有资源。当多个查询同时运行时，这些查询需要公平地共享资源。由于面向服务的点查找查询通常相对简单，并且需要较少的资源，因此这种公平的调度机制可以确保即使存在复杂的分析查询，也仍然可以保证面向服务的查询的等待时间。作为分布式系统，调度可以分为分布式调度和过程调度。协调器将查询分解为多个任务，这些任务分配给不同的进程。协调人员需要采取某些策略来确保公平。同样重要的是，企业还需要允许不同的任务在流程中公平地共享资源。由于操作系统不了解任务之间的关系，因此在每个进程中都实现了一个用户状态调度程序，以更灵活地支持工作负载隔离。

系统的开放性

许多企业已经使用了其他存储平台或计算引擎，因此新系统必须考虑与现有系统的集成。查询、计算和存储的集成需要很高的时间效率，可以带来明显的优势。但是，对于没有高时间效率的脱机计算，存储层可以提供一个统一的接口来打开数据，这使得其他引擎能够提取数据进行处理，并给业务带来更大的灵活性。开放性的另一方面是处理存储在其他系统中的数据的能力，这可以通过联合查询来实现。

混合服务/分析处理（HSAP）的应用

以下将分享阿里巴巴集团的搜索推荐优化运营业务。

原始搜索推荐完善的运营业务架构

可以通过一系列存储和计算引擎（HBase、Druid、Hive、Drill、Redis等）的复杂协作来满足业务需求，多个存储需要通过数据同步任务来保持近似同步。这种业务架构极其复杂，整个业务架构的开发需要大量的时间。

升级搜索推荐优化运营业务架构

阿里巴巴2019年的网站购物购买额超过2684亿元人民币（379.6亿美元），而阿里巴巴已在2019年的“双十一”通过混合服务/分析处理（HSAP）系统对其业务进行了升级。混合服务/分析处理（HSAP）系统总共支持1.45亿个在线查询，这进一步支持了非常复杂的业务的分析和决策过程，同时，这些分析背后还包含具有1.3亿个实际数据的大规模数据记录而不会生成冗余数据。

阿里巴巴新的架构更加简化。用户、商品、商家的数据和大量用户行为数据从在线和离线ETL进入混合服务/分析处理（HSAP）系统。混合服务/分析处理（HSAP）系统提供查询和分析服务，例如实时数据可视化、实时报告、效果跟踪、实时数据应用等。它通过提供实时数据可视化、实时销售等服务帮助做出更好的决策。预测、实时库存监控、实时商业智能报告、实时监控业务进度、监控运营增长、跟踪算法效果、实时标签、实时肖像、竞争分析、客户定位、产品推荐以及奖金分配等数据产品有助于精确的运营和决策。实时数据服务支持算法控制、库存监视和预警以及其他服务。一套混合服务/分析处理（HSAP）系统实现了所有渠道和所有过程的数据共享和重用，从而从运营商、产品所有者、算法所有者、开发人员、分析师或高级经理的不同业务角度解决了数据分析和查询要求。

通过提供统一的实时存储而不需要任何数据复制，混合服务/分析处理（HSAP）架构为点查找查询、联机分析处理（OLAP）分析、在线数据服务以及其他各种查询和服务提供了一站式服务。这种新的架构显著降低了应用程序的复杂性，并使企业能够快速响应新的业务需求。实时性能中的秒级甚至亚秒级延迟使决策更加迅速和高效，从而允许数据创造更大的商业价值。