怎么塔建网站,网站设计代做,网站地图模版,广州做app软件开发的公司作者#xff1a;蒋晓伟#xff08;量仔#xff09; 阿里巴巴研究员 因为侧重点的不同#xff0c;传统的数据库可以分为交易型的 OLTP 系统和分析型的 OLAP 系统。随着互联网的发展#xff0c;数据量出现了指数型的增长#xff0c;单机的数据库已经不能满足业务的需求。特…作者蒋晓伟量仔 阿里巴巴研究员 因为侧重点的不同传统的数据库可以分为交易型的 OLTP 系统和分析型的 OLAP 系统。随着互联网的发展数据量出现了指数型的增长单机的数据库已经不能满足业务的需求。特别是在分析领域一个查询就可能需要处理很大一部分甚至全量数据海量数据带来的压力变得尤为迫切。这促成了过去十多年来以 Hadoop 技术开始的大数据革命解决了海量数据分析的需求。与此同时数据库领域也出现了一批分布式数据库产品来应对 OLTP 场景数据量的增长。 为了对 OLTP 系统里的数据进行分析标准的做法是把里面的数据定期比如说每天同步到一个 OLAP 系统中。这种架构通过两套系统保证了分析型查询不会影响线上的交易。但是定期同步导致了分析的结果并不是基于最新数据这种延迟让我们失去了做出更及时的商业决策的机会。为了解决这个问题近几年出现了 HTAP 的架构这种架构允许我们对 OLTP 数据库里的数据直接进行分析从而保证了分析的时效性。分析不再是传统的 OLAP 系统或者大数据系统特有的能力一个很自然的问题是既然 HTAP 有了分析的能力它是不是将取代大数据系统呢大数据的下一站是什么
背景
为了回答这个问题我们以推荐系统为例分析一下大数据系统的典型场景。 当你看到购物应用给你展示正好想要买的商品短视频应用播放你喜欢的音乐时推荐系统正在发挥它神奇的作用。一个先进的推荐系统核心目标是根据用户的实时行为做出个性化的推荐用户和系统的每一次交互都将即时优化下一步的体验。为了支持这样一个系统后端的大数据技术栈已经演变为一个非常复杂和多元化的系统。 下图展示了一个支持实时推荐系统的大数据技术栈。 为了提供优质的实时个性化推荐推荐系统重度依赖实时特征和模型的连续更新。 实时特征可以分为两类
系统会收集大量的用户行为事件比如说浏览、点击等以及交易记录比如说从 OLTP 数据库同步过来的付款记录等。这些数据量非常巨大可能高达每秒种数千万甚至上亿条并且其中的绝大部分不是来自交易系统。为了方便以后使用这些数据会导入到系统里图中的 a同时它们会和各种维表数据做关联推导出一系列重要的特征图中的 1这些特征会实时更新到推荐系统以优化用户体验。这里的实时维表关联需要低延迟高吞吐的点查支持才能跟得上新产生的数据。系统也会使用滑动窗口等方式去计算出各种不同维度和时间粒度的特征比如说一个商品过去 5 分钟的点击数、过去 7 天的浏览量和过去 30 天的销售等。根据滑动窗口的粒度这些聚合可能通过流计算或者批处理的方式完成。
这些数据也被用来产生实时和离线机器学习的样本训练出来的模型经过验证后会持续地更新到推荐系统中。
上述所解释的是一个先进的推荐系统的核心部分但这只是整个系统的冰山一角。除此之外还需要实时模型监控、验证、分析和调优等一整套体系这包含使用实时大屏去查看 A/B 测试的结果3使用交互式分析4去做 BI 分析对模型进行细化和调优。除此之外运营还会使用各种复杂的查询去洞察业务的进展并且通过圈人圈品等方式进行针对性的营销。 这个例子展示了一个非常复杂但典型的大数据场景从数据的实时导入a到预聚合b从数据服务1持续聚合3到交互式查询4一直到批处理2。这类复杂场景对大数据系统有着非常多样化的需求在构建这些系统的实践中我们看到了两个新的趋势。
实时化业务需要快速地从刚刚收集到的数据中获得商业洞察。写入的数据需要在秒级甚至亚秒级就可见。冗长的离线 ETL 过程正在变得不可容忍。同时收集到的数据比从 OLTP 系统同步过来的数据要大得多用户浏览点击等日志类数据甚至要比它大几个数量级。我们的系统需要有能力在大量实时数据写入的同时提供低延迟的查询能力。服务 / 分析的融合传统的 OLAP 系统在业务中往往扮演着比较静态的角色。我们通过分析海量的数据得到业务的洞察比如说预计算好的视图、模型等这些获得的知识通过另外一个系统提供在线数据服务。这里的服务和分析是个割裂的过程。与此不同的是理想的业务决策过程往往是一个持续优化的在线过程。服务的过程会产生大量的新数据我们需要对这些新数据进行复杂的分析。分析产生的洞察实时反馈到服务创造更大的商业价值。服务和分析正在形成一个闭环。
现有的解决方案通过一系列产品的组合来解决实时的服务 / 分析融合的需求。比如说通过 Apache Flink 做数据的实时预聚合聚合后的数据会存储在类似 Apache Druid 这种提供多维分析的产品中并且通过 Apache HBase 这类产品来提供数据服务。这种烟囱式开发的模式会不可避免地产生数据孤岛从而引起不必要的数据重复各个产品间复杂的数据同步也使数据的一致性和安全性成为挑战。这种复杂度使得应用开发很难快速响应新需求影响了业务的迭代速度也给开发和运维都带来了较大的额外开销。 我们认为实时的服务 / 分析的融合应该通过一个统一的 Hybrid Serving/Analytical ProcessingHSAP系统来实现。 通过这样一个系统应用开发不再需要和多个不同的产品打交道不再需要去学习和接受每个产品的问题和局限这能够大大简化业务的架构提升开发和运维效率。这样一个统一的系统能够避免不必要的数据重复从而节约成本。同时这种架构还能够为系统带来秒级甚至亚秒级的实时性让业务的决策更实时从而让数据发挥出更大的商业价值。分布式 HTAP 系统虽然具有了实时分析的能力但是并不能解决大数据的问题。 首先交易系统同步过来的数据只是实时推荐系统需要处理的一小部分数据其他绝大部分数据来自日志等非交易系统用户每次购买前往往有数十个甚至数百个浏览行为大部分分析是在这些非交易数据上进行的。但 HTAP 系统并没有这部分数据所以在这些非交易数据上做分析就无从谈起。 那么是不是可以将这些非交易数据写入 HTAP 系统来进行分析呢我们来分析一下 HTAP 系统和 HSAP 系统在数据写入模式上的不同。HTAP 系统的基石和优势是支持细粒度的分布式事务交易型数据往往以很多分布式小事务的方式写入 HTAP 系统。然而来自日志等系统的数据并没有细粒度分布式事务的语意如果要把这些非交易型数据导入 HTAP 系统势必会带来不必要的开销。 相比之下 HSAP 系统并没有这种高频率分布式小事务的需求。数据写入 HSAP 系统一般有两种模式1海量的单条数据实时写入2相对低频的分布式批量数据写入。这就允许 HSAP 系统在设计上做出一系列优化从而提升性价比避免把非交易型数据导入 HTAP 系统带来的不必要开销。 就算我们不在乎这些开销假设能不计成本把数据都写入 HTAP 系统是不是就解决问题了呢答案仍然是否定的。 支持好 OLTP 的场景是 HTAP 系统的前提条件为了做到这点HTAP 系统往往采用了行存的数据格式而分析型的查询在行存的效率相比于列存有很大的数量级的劣势。具备分析的能力和能够高效地分析并不是一回事。为了提供高效分析的能力HTAP 系统必须把海量的非交易数据复制到列存但这势必带来不小的成本不如把少量的交易数据复制到 HSAP 系统成本更低同时还能更好地避免对线上交易系统产生影响。 所以我们认为 HTAP 和 HSAP 会相辅相成分别引领数据库和大数据领域的方向。
HSAP 的挑战
作为一种全新的架构HSAP 面临着和已有的大数据以及传统的 OLAP 系统相比很不一样的挑战。
高并发的混合工作负载HSAP 系统需要处理远远超出传统的 OLAP 系统的并发查询。在实践中数据服务的并发远远超出了 OLAP 查询。比如说我们在实践中见到数据服务需要处理高达每秒钟数千万个查询这比 OLAP 查询的并发高出了 5 个数量级。同时和 OLAP 查询相比数据服务型查询对延迟有着更加苛刻的要求。除此之外更大的挑战是系统在提供数据服务查询的同时需要处理非常复杂的分析型查询。这些混合查询负载在延迟和吞吐间有着非常不同的取舍。如何高效地利用系统资源处理好这些非常不一样的查询并且保证每个查询的 SLO 是一个巨大的挑战。
高吞吐实时数据导入在处理高并发的查询负载的同时HSAP 系统还需要支持海量数据的实时写入。这些实时写入的数据量远远超出了传统的 OLAP 系统的需求。比如说上面的实时推荐场景会持续写入每秒钟数千万甚至上亿条事件。和传统的 OLAP 系统的另外一个区别是 HSAP 系统对数据的实时性有着很高的要求写入的数据需要在秒级甚至亚秒级可见这样才能保证我们服务和分析结果的时效性。
弹性和可扩展性数据写入和查询负载可能会有突发的高峰这对系统提出了很高的弹性和可扩展性的要求。在实践中我们注意到数据写入峰值能达到平均的 2.5 倍查询的峰值能达到平均的 3 倍。而且数据写入和查询的峰值不一定同时出现这也需要系统有根据不同的峰值做迅速调整的能力。
HSAP 的系统设计
为了应对这些挑战我们认为一个典型的 HSAP 系统可以采用类似于上图的一个架构。存储计算分离所有的数据存储在一个分布式文件系统中我们以数据分片的方式来扩展系统Storage Manager 会管理这些数据分片ShardResource Manager 管理系统的计算资源保证系统能够处理高吞吐的数据写入和查询的需求。这种架构能够快速应对工作负载的变化当查询负载变大需要更多的计算资源的时候可以扩展计算资源当数据量快速增长的时候可以快速扩展存储资源。存储计算分离的架构保证了不需要等待移动 / 拷贝数据就能快速完成这些操作。这种架构较大地简化了运维为系统的稳定性提供了保障。
统一的实时存储为了能够支持各种查询模式统一的实时存储层至关重要。查询大体可以分为两类一类是简单的点查询数据服务类的大多是这类另一类是扫描大量数据的复杂查询分析类的大多是这类当然这是一个连续变化的过程很多查询介于两者之间。这两种查询模式对数据存储也提出了不同的要求。行存储能够比较高效地支持点查询而列存储在支持大量扫描的查询上有明显的优势。我们可以通过类似 PAX 的方式在行存和列存之间做一个折衷付出的代价是可能在点查和扫描数据的场景都不能获得最佳的性能。我们希望在两种场景都做到最优所以在系统里同时支持了行存和列存用户可以根据场景选择每个表的存储方式。对同时有两种需求的表我们通过索引的抽象允许用户同时选择两种存储系统通过索引维护的机制保证两者间的一致性。在实践中我们发现这种设计带来的效率和灵活性能够更好地支持业务。
工作负载的隔离系统在混合工作负载下的 SLO 是通过调度来保证的。在理想情况下一个大查询就应该能把所有的资源都利用起来。而当有多个查询同时运行的时候这些查询需要公平地共享资源。由于服务型的查询通常比较简单从而需要的资源比较少这种公平调度的机制能够保证服务型查询的延迟即使在有复杂的分析型查询的情况下仍然能够得到保障。作为一个分布式的系统调度可以分为分布式和进程内两部分。Coordinator 会把一个查询分解为多个任务这些任务被分发到不同的进程Coordinator 需要采取一定的策略保证公平性。同样重要的是在一个进程内我们也需要让不同任务公平地分享资源。由于操作系统并不理解任务间的关系所以我们在每个进程里实现了一个用户态的 Scheduler 去更灵活地支持工作负载的隔离。
系统的开放性很多业务已经使用了其他存储平台或者计算引擎新的系统必须考虑和已有系统的融合。对时效性要求高的查询计算和存储的一体化能够带来明显的优势。但是对时效性不高的离线计算存储层可以提供统一的接口开放数据这种开放性允许其他引擎把数据拉出去处理能够赋予业务更大的灵活度。开放性的另外一面是对存储在其他系统中数据进行处理的能力这个可以通过联邦查询的方式去实现。
HSAP 的应用
这里我们分享一下阿里巴巴搜索推荐精细化运营业务下图显示了在采用 HSAP 前这样一个系统架构的示例。 我们通过一系列存储和计算引擎HBase、Druid、Hive、Drill、Redis 等的复杂配合才能满足业务的需求并且多个存储之间需要通过数据同步任务来保持大致的同步。这种业务架构极其复杂整个业务的开发耗费了大量的时间。 我们在 2019 年的双十一使用 HSAP 系统升级了这个业务新架构得到了极大的简化。用户、商品、商家属性数据和海量的用户行为数据经过实时和离线的数据清洗统一进入 HSAP 系统由 HSAP 系统向上承接了实时大屏、实时报表、效果跟踪、实时数据应用等查询和分析服务。实时大屏、实时销售预测、实时库存监控、实时 BI 报表实时监测业务进展洞悉运营增长跟踪算法效果从而助力高效决策。实时标签、实时画像、竞对分析、圈人圈品、权益投放等数据产品助力精细化运营和决策。实时数据接口服务支持算法调控、库存监控预警等服务。一套 HSAP 系统实现了全渠道全链路的数据共享和复用解决了运营、产品、算法、开发、分析师到决策层不同业务视角的数据分析和查询需求。
总结
HSAP 架构通过统一的实时存储数据无需复制就能一站式提供简单查询、OLAP 分析、在线数据服务等多样化的数据查询和应用服务满足数据应用方的访问和接入需求。这种新架构大大地降低了业务的复杂度让我们能够快速应对新的业务需求。它提供的秒级甚至亚秒级实时性让决策更及时高效从而让数据创造出更大的商业价值。
原文链接 本文为云栖社区原创内容未经允许不得转载。
