由于不同的重点，传统数据库可分为以事务为中心的 OLTP 系统和分析性 OLAP 系统。随着互联网的发展，数据量呈指数级增长，单机数据库已不能满足业务需求。特别是在分析领域，查询可能需要处理大量甚至全部数据，海量数据带来的压力变得尤为紧迫。这促成了过去十年左右从 Hadoop 技术开始的大数据革命，并解决了对海量数据分析的需求。同时，数据库领域也出现了几种分布式数据库产品，以应对OLTP方案数据的增长。
要分析 OLTP 系统中的数据，标准做法是定期（例如，每天）将 OLTP 系统中的数据同步到 OLLAP 系统。此体系结构可确保分析查询不会影响联机事务。但是，定期同步导致分析结果不基于最新数据，这种延迟使我们失去了做出更及时业务决策的机会。为了解决这个问题，HTAP 体系结构近年来已经出现，这使我们能够直接分析 OLTP 数据库中的数据，从而确保分析的及时性。分析不再是传统 OLAP 系统或大数据系统的独特功能。一个自然的问题是：由于HTAP具有分析能力，它会取代大数据系统吗？大数据的下一站是什么？
背景介绍
为了回答这个问题，我们将以推荐系统为例，分析大数据系统的典型场景。
当你看到购物应用程序显示你只是想买什么和简短的视频应用程序播放你最喜欢的音乐，推荐系统正在发挥其神奇的作用。高级推荐系统的核心目标是根据用户的实时行为进行个性化推荐。用户和系统之间的每次交互都将实时优化下一个体验。为了支持这样的系统，大数据技术堆栈已经发展成为一个非常复杂和零碎的系统。
下图显示了支持实时推荐系统的大数据技术堆栈。
为了提供高质量的实时个性化推荐，推荐系统严重依赖实时功能和模型的不断更新）和交易记录（例如从 OLTP 数据库同步的付款记录等）。这些数据的数量非常大（流量可能高达数千万甚至数亿件/秒），而且大多数不是来自交易系统。为方便将来使用，这些数据将被导入系统（图中的一个），同时，它们将与各种维度表数据关联，以推断出一系列重要功能（图中的 1），这些功能将实时更新到建议系统以优化用户体验。此处的实时维度表关联需要具有低延迟和高吞吐量的点检查支持，以跟上新生成的数据。
这些数据还用于生成实时和离线机器学习示例，经过培训的模型将在验证后不断更新到推荐系统。
上面解释的是高级推荐系统的核心部分，但这只是整个系统的冰山一角？此外，还需要一套完整的系统，如实时模型监视、验证、分析和调优，其中包括：使用实时大屏幕查看 A/B 测试结果 （3），使用交互式分析 （4） 进行 BI，以及优化和调整模型。此外，该运营将利用各种复杂的查询来深入了解业务进度，并利用客户定位和产品推荐进行有针对性的营销。
此示例显示了非常复杂但典型的大数据方案，从实时数据导入 （a） 到预聚合 （b），从数据服务 （1）、连续聚合 （3） 到交互式查询 （4）到批处理 （2）。这种复杂的场景对大数据系统的需求非常多样化。我们在建立这些系统的实践中看到了两个新的趋势。
实时：业务需要从刚刚收集的数据中快速获得业务洞察力。写入的数据需要在几秒钟内甚至次秒内可见。冗长的脱机 ETL 过程变得不可容忍。同时，收集的数据比从 OLTP 系统同步的数据大得多，并且事件日志数据（如用户浏览和单击）甚至比它大几个数量级。我们的系统需要能够提供低延迟查询功能，同时以极高的吞吐量写入数据。
混合服务和分析：传统的 OLAP 系统在业务中通常发挥相对静态的作用）通过分析数据，通过另一个系统基于所获取的知识提供在线数据服务。这里的服务和分析是一个零碎的过程。相比之下，理想的业务决策过程通常是一个持续优化的在线过程。服务过程将生成大量新数据，我们需要对这些新数据进行复杂的分析。分析产生的见解将实时反馈给服务，以创造更大的商业价值。服务和分析正在形成闭环。
现有解决方案通过一系列产品的组合，满足实时服务/分析融合的需求。例如，通过 Apache Flink 对数据进行实时预聚合，聚合数据将存储在提供多维分析的 Apache Druid 等产品中，数据服务将通过 Apache HBase 等产品提供。这种烟囱开发模式必然会产生孤立的数据孤岛，从而造成不必要的数据重复。各种产品之间的复杂数据同步也使数据的一致性和安全性成为一项挑战。这种复杂性使得应用程序开发难以快速响应新需求，影响业务的迭代速度，也给开发、操作和维护带来大量额外的开销。
我们认为，实时服务/分析集成应该通过统一的混合服务/分析处理 （HSAP） 系统实现。
通过这样的系统，应用程序开发不再需要处理多个不同的产品，也不再需要学习和接受每个产品的问题和局限性，这可以极大地简化业务架构，提高开发和运营效率。这种统一的系统可以避免不必要的数据重复，从而节省成本。同时，此体系结构还可以为系统带来二级甚至低于二级的实时性能，使业务决策更加实时，从而使数据发挥更大的商业价值。
虽然分布式HTAP系统具有实时分析功能，但无法解决大数据问题。
首先，事务系统同步的数据只是实时推荐系统需要处理的数据的一小部分。大多数其他数据来自非事务系统（如日志）（用户在每次购买之前通常有数十甚至数百个浏览行为）。大多数分析都是对这些非事务性数据进行的。但是，HTAP 系统没有此部分数据，因此无法分析HTAP 系统的基石和优势是支持细粒度的分布式事务。事务数据通常以许多分布式小型事务的形式写入 HTAP 系统。但是，来自日志和其他系统的数据没有细粒度的分布式事务的语义。如果要将这些非事务性数据导入 HTAP 系统，将不可避免地带来不必要的开销。
相比之下，HSAP系统不需要这种高频分布式小交易。HSAP 系统中通常有两种数据写入模式：
- 实时写入大量单张唱片;
- 相对较低的频率分布式批处理数据写入。
这使得 HSAP 系统能够进行一系列设计优化，从而提高成本效益，避免将非事务性数据导入 HTAP 系统造成的不必要的开销。
即使我们不关心这些费用，假设我们可以将所有数据写入HTAP系统，而不考虑成本，我们能否解决问题？答案仍然是否定的。
支持 OLTP 方案是 HTAP 系统的先决条件。为此，HTAP 系统通常采用基于行的存储的数据格式，而基于行的存储的分析查询效率则大大低于列存储。拥有分析能力与高效分析的能力不同。为了提供高效的分析功能，HTAP 系统必须将大量非事务数据复制到列存储，但这肯定会带来大量成本。最好以较低的成本将少量交易数据复制到 HSAP 系统，同时可以更好地避免对在线事务系统的影响。
因此，我们认为，HTAP和HAP将相互补充，分别引领数据库和大数据的发展方向。
HSAP 的挑战
作为一个全新的架构，HSAP 面临着与现有大数据和传统 OLAP 系统截然不同的挑战。
高并发混合工作负载：
HSAP 系统需要处理远远超出传统 OLAP 系统的并发查询。
实际上，数据服务的并发性远远超出了 OLAP 查询的范围。例如，我们在实践中看到数据服务需要处理数千万个查询/秒，比 OLAP 查询的并发性高 5 个数量级。同时，与OLAP查询相比，数据服务查询对延迟的要求更为严格。此外，更大的挑战是系统需要处理非常复杂的分析查询，同时提供数据服务查询。这些混合查询有效负载在延迟和吞吐量之间具有非常不同的权衡。如何有效地使用系统资源来处理这些截然不同的查询，并确保每个查询的 SLO 是一个巨大的挑战实时写入的数据量远远超过了传统 OLAP 系统的要求。例如，上述实时建议方案将连续写入数千万甚至数亿个事件/秒。传统 OLAP 系统的另一个区别是 HSAP 系统对实时数据的要求很高。书面数据需要在几秒钟内甚至亚秒内显示，以确保我们的服务和分析结果的效率。
灵活性和可扩展性：
数据写入和查询的负载可能有突然的峰值，这给系统提出了高灵活性和可伸缩性要求。在实践中，我们注意到数据写入的峰值可以达到平均值的2.5倍，查询的峰值可以达到平均值的3倍。此外，数据写入和查询的峰值不一定同时出现，这也要求系统能够根据不同的峰值进行快速调整。
HSAP的系统设计
为了应对这些挑战，我们相信典型的 HSAP 系统可以采用类似于上图的体系结构。
存储和计算的存储分解：
所有数据存储在分布式文件系统中。我们通过分片扩展系统。存储管理器将管理这些分片。资源管理器将管理系统的计算资源，以确保系统能够处理高吞吐量数据写入和查询的要求。此体系结构可以随着工作负载的变化快速扩展，在查询负载变大时扩展计算资源，在数据量快速增长时需要更多的计算资源，并快速扩展存储资源。存储和计算的分离可确保无需等待数据移动/复制即可快速完成这些操作。这种架构大大简化了操作和维护，为系统的稳定性提供了保证。
统一实时存储：
要支持各种查询模式，统一的实时存储层至关重要。查询大致可分为两种类型，一种是点查找查询（大多数是数据服务类型），另一种是扫描大量数据的复杂分析查询（大多数是分析类型）。当然，许多查询介于两者之间。这两种查询类型也对数据存储提出了不同的要求。基于行的存储可以更高效地支持点查询，而列存储在支持具有大量扫描的查询方面具有明显的优势。我们可以在像 PAX 一样的方式在行存储和列存储之间做出妥协，代价是无法在检查和扫描数据的情况下获得最佳性能对于同时具有两个要求的表，我们允许用户通过索引抽象同时选择两种存储，系统通过索引维护机制确保两种存储之间的一致性。在实践中，我们发现这种设计带来的效率和灵活性可以更好地支持业务。
工作负载隔离
混合工作负载下系统的 SLO（服务级别目标）通过调度得到保证。理想情况下，大型查询应该能够利用所有资源。当多个查询同时运行时，这些查询需要公平共享资源。由于面向服务的点查找查询通常相对简单，需要的资源较少，因此，即使存在复杂的分析查询，这种公平调度机制仍然可以保证面向服务的查询的延迟。作为一个分布式系统，调度可分为分布式调度和流程调度。协调器将查询分解为多个任务，这些任务分发到不同的进程。协调员需要采取某些战略来确保公平。同样重要的是，我们还需要允许不同的任务在一个进程中公平地共享资源。由于操作系统不了解任务之间的关系，因此我们在每个进程中都实现了用户状态调度程序，以更灵活地支持工作负载隔离。
制度的开放性
许多企业已经使用其他存储平台或计算引擎，新系统必须考虑与现有系统的集成。查询、计算、存储的集成，需要高时效，可以带来明显的优势。但是，对于没有高时间效率的离线计算，存储层可以提供一个统一的接口来打开数据，从而允许其他引擎提取数据进行处理，并为业务提供更大的灵活性。开放性的另一面是处理存储在其他系统中的数据的能力，这可以通过联合查询实现。
HSAP的应用
在这里，我们将分享阿里巴巴的搜索推荐精炼运营业务。下图显示了采用 HSAP 之前体系结构的示例。
原始搜索建议 改进运营业务架构
我们可以通过一系列存储和计算引擎（HBase、德鲁伊、蜂巢、Drill、Redis 等）的复杂合作来满足业务需求，并且多个存储需要通过数据同步任务保持近似同步。这种业务架构极其复杂，整体的发展耗了大量时间googleusercontent. com / czgewpmafowfsslqhn1omzzv9rk5wguho33h – jzluf4woh56 – ewxbakkm2c5dl – 3454iv Ujipis rotzdxa3u3rjxoqv1osbdf47ytgv0ahsiqo5ZZLOLKJ8e8gerk2pvw7yzK41″/]
升级搜索建议 优化运营业务架构
我们在 2019 年双 11 上用 HSAP 系统升级了此业务（这是一个全球购物嘉年华，客户可以购买商品，享受大幅折扣， 在2019年双11嘉年华期间，阿里巴巴的购物者购买金额超过2684亿元人民币（379.6亿美元），HSAP系统总共支持了1.45亿次在线查询，进一步支持了非常复杂业务的分析和决策过程。在这些分析的背后，是一个大规模的数据量，其中1.3亿条实时记录在写入的情况下没有生成冗余数据，而且新架构也大大简化了。用户、商品、商家属性数据和海量用户行为数据从在线和离线 ETL 进入 HSAP 系统。HSAP系统提供实时数据可视化、实时报告、效果跟踪、实时数据应用等查询和分析服务。它通过提供实时数据可视化、实时销售预测、实时库存监控、实时 BI 报告、实时监控业务进度、监控运营增长、跟踪算法效果等服务，帮助做出更好的决策。数据产品（如实时标签、实时纵向、竞争分析、客户定位、产品推荐和奖金分配）有助于精确操作和决策。实时数据服务支持算法控制、库存监控、预警和其他服务。一组 HSAP 系统实现了所有通道和所有过程的数据共享和重用，从运营商、产品所有者、算法所有者、开发人员、分析师或高级经理的不同业务角度解决了数据分析和查询要求。
总结
通过提供统一的实时存储，无需任何数据复制，HSAP 架构为点查找查询、OLAP 分析、在线数据服务和其他多样化的查询和服务提供一站式服务。这种新体系结构大大降低了应用程序的复杂性，使我们能够快速响应新的业务需求。实时性能中的第二个甚至次秒延迟使决策更加快速和高效，从而使数据能够创造更大的商业价值。