大数据的下一步是什么?混合服务/分析处理(HSAP)
发布时间：2025-03-05 点击：31
混合服务/分析处理(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倍。此外，数据写入和查询的峰
如何做邮件营销
云服务器和虚拟主机哪家好
启用数字域名成功的终端案例
阿里云服务器怎么导入景象
购买云服务器之后如何获得ip
苹果新域名出席？该域名竟然是用来做这个？
告诉你新手写软文需要注意什么
云服务器挂代理ip
由于侧重点不同，传统数据库可以分为以事务为中心的联机事务处理 (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倍。此外，数据写入和查询的峰
如何做邮件营销
云服务器和虚拟主机哪家好
启用数字域名成功的终端案例
阿里云服务器怎么导入景象
购买云服务器之后如何获得ip
苹果新域名出席？该域名竟然是用来做这个？
告诉你新手写软文需要注意什么
云服务器挂代理ip