[db:标签]��合[db:标签]��务/分析处理(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)系统通常采用基于行存储的数据格式，而基于行存储的分析和查询效率远低于列存储。能够分析并不意味着能够有效地分析。为了提供有效的分析功能，混合事务分析处理(HTAP)系统必须将大量非事务性数据复制到列存储中，但这不可避免地会带来大量成本。最好以较低的成本将少量交易数据复制到混合服务/分析处理(HSAP)系统，同时可以更好地避免对在线交易系统的影响。

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

混合服务/分析处理(HSAP)面临的挑战

作为一个全新的架构，混合服务/分析处理(HSAP)面临着与现有大数据和传统在线分析处理(OLAP)系统完全不同的挑战。

高并发混合工作负载:混合服务/分析处理(HSAP)系统需要处理的并发查询远远超过传统的在线分析处理(OLAP)系统。

事实上，数据服务的并发性远远超出了在线分析处理(OLAP)查询。例如，人们在实践中已经看到，数据服务每秒需要处理数千万个查询，这比在线分析处理(OLAP)查询的并发性高五个数量级。同时，与在线分析处理(OLAP)查询相比，数据服务查询对延迟有更严格的要求。此外，更大的挑战是系统需要在提供数据服务查询的同时处理非常复杂的分析查询。这些混合查询负载在延迟和吞吐量之间有不同的权衡。如何有效地使用系统资源来处理这些完全不同的查询，并确保每个查询的服务级别目标(SLO)是一个巨大的挑战。

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

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

混合服务/分析处理的系统设计(HSAP)

为了应对这些挑战，典型的混合服务/分析处理(HSAP)系统可以采用上述类似的体系结构。

存储和计算的存储分解:所有数据都存储在分布式文件系统中，企业通过分区来扩展系统。存储管理器将管理这些片段。资源管理器管理系统的计算资源，以确保系统能够处理高吞吐量的数据写入和查询需求。该体系结构可以随着工作负载的变化而快速扩展，当查询负载变大时，计算资源可以扩展，当数据量快速增加时，存储资源可以快速扩展。存储和计算的分离确保了这些操作可以快速完成，而无需等待数据被移动/复制。这种架构大大简化了操作和维护，并确保了系统的稳定性。统一实时存储:为了支持各种查询模式，统一实时存储层非常重要。查询可以大致分为两种类型，一种是点查询(大部分是数据服务类型)，另一种是复杂分析查询(大部分是分析类型)。当然，他们之间有许多疑问。这两种查询类型也对数据存储提出了不同的要求。基于行的存储可以更有效地支持点查询，而列存储在支持大量扫描的查询方面具有明显的优势。需要在行存储和列存储之间进行权衡，但代价是在检查和扫描数据时无法获得高质量的性能。我们希望在这两种情况下都能获得高质量的结果，所以系统同时支持行存储和列存储，用户可以根据方案选择每个表的存储。对于同时具有两种需求的表，允许用户通过索引抽象同时选择两种存储，系统通过索引维护机制保证两者之间的一致性。在实践中，发现这种设计带来的效率和灵活性可以更好地支持业务。

工作负载隔离

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

系统的开放性

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

混合服务/分析处理应用(HSAP)

以下将分享阿里巴巴集团的搜索建议，以优化其运营业务。

最初的搜索推荐了一个完美的运营业务架构

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

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

2019年阿里巴巴网站购物采购金额超过2684亿元(379.6亿美元)，2019年阿里巴巴通过“双十一”混合服务/分析处理(HSAP)系统升级业务。混合服务/分析处理(HSAP)系统共支持1.45亿次在线查询，进一步支持非常复杂的业务的分析和决策过程。同时，这些分析

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

混合服务/分析处理(HSAP)架构提供统一的实时存储，无需任何数据复制，为点搜索查询、在线分析处理(OLAP)分析、在线数据服务和其他各种查询和服务提供一站式服务。这种新的体系结构大大降低了应用程序的复杂性，使企业能够快速响应新的业务需求。实时性能的几秒钟甚至几秒钟的延迟使决策更快、更有效，从而允许数据创造更大的业务价值。