May-Hologres个人页面-阿里云开发者社区

正确设计Hologres实时数仓，性能提升10倍+

概要：天猫双11对于零售通团队来说也是全年最大的一场战役，数据响应需要更实时，但也会相应增加更多的个性化指标，业务面临的挑战也会更大。本文将会讲述阿里巴巴零售通数据平台如何优化Hologres实时数仓，达到性能提升10倍+的效果，完美支撑双11营销活动、实时数据大屏等核心场景。也希望通过此文对Hologres新用户起到一定的帮助作用，通过合理的数仓设计实现事半功倍的性能效果。作者：曹泰铭（潇铭）阿里巴巴数据技术产品部-B系数据业务-零售通数据-高级数据工程师汪宇（旋宇）阿里巴巴数据技术产品部-B系数据业务-零售通数据-高级数据工程师背景阿里巴巴零售通团队是阿里巴巴B2B事业群针对线下零售小店（便利店/小超市）推出的一个为城市社区零售店提供订货、物流、营销、增值服务等的互联网一站式进货平台，实现互联网对线下零售业的升级，同时也为有志于线上线下零售业的创业群体提供创业平台。整个平台的架构图如下所示，是一个流批分离且以离线为主的架构。零售通数据团队负责对离线MaxCompute数仓和实时Flink数仓的建设和维护，对内部小二和外部生态伙伴提供决策支持，数据服务和数据产品建设。因为Hologres与MaxCompute有着极好的兼容性，并且能够对MaxCompute毫秒级加速，财年初零售通数据团队作为业务数据中台基于Hologres在业务上进行了大量的尝试，包括实时数仓公共层，冷热混合计算，查询加速等场景，因为Hologres的加入，相同的需求量，以前的架构需要2天才能完成，而现在在2小时内就能完成，大大提升了开发效率，得到了研发们的一致好评。天猫双11对于零售通团队来说也是全年最大的一场战役，数据响应需要更实时，但也会相应增加更多的个性化指标，业务面临的挑战也会更大。基于Hologres日常在业务的优秀表现，团队也决定使用Hologres作为双11核心开发产品，应用于双11核心场景包括营销活动中心，实时数据大屏等。在10月份对全链路进行了几次压测，Hologres在100%压测压力下CPU和内存资源在100%线上徘徊，属于压线通过。本以为能顺利通过大促考验，但在2020-11-01这天，在大量查询QPS和高并发的数据写入峰值下，Hologres的RT延迟一度达到90秒，没有达到预期。在Hologres团队的紧急支持下，通过整体结构的调整以及相关性能调优，整体性能提升了10倍+，顺利扛住2020-11-01的流量洪峰，同时通过此次调整也平稳的支持了整个双11期间的流量洪峰（包括2020-11-11当天的波峰），为双11划下了圆满句号。事后我们针对整个事件做了全链路复盘，发现主要问题还是出在对于Hologres的原理了解不够深入，包括技术原理、Table Group、表结构设计等，导致某些用法还不是最优，这也导致在实际业务场景中，Hologres的性能没有发挥到最大化。我们将会通过此文讲诉阿里巴巴零售通团队如何根据业务场景合理的设计Hologres实时数仓，包括表结构、Table Group设计等，以到达更优的性能表现。也希望通过此文对Hologres新用户起到一定的帮助作用，通过合理的资源利用实现事半功倍的性能效果。 11月1日现场还原首先我们先来还原一下11月1日的现场反馈，以更直观的方式来看看当时Hologres承受的压力和相关表现（注：监控页面为Hologres在阿里内部的监控页面，与公有云的监控页面和指标项略有不同）：查询QPS: 每秒完成query的数量，一般代表数据库性能和压力，23:30后的增长代表压力负荷增长（业务方开始大量关注/查询报表），00:15分的骤降代表性能降低，1点之后的降低代表业务水位下降。查询延迟（RT）：15分左右陡升到25s，大概持续15分钟；Hologres超负荷运作，性能下降。 CPU使用率：代表正在运转的core数量。我们的实例有几百个core用于计算，但在峰值严重超负载50%+； Woker CPU使用率：Woker的CPU负载情况，和CPU使用率基本一致，峰值超负载50%+。这两个指标代表大量Query将会无法及时处理，在队列中等待，延迟将会较大增加，实例也有停摆的风险。 Blink写入RPS：代表每秒实时数据的写入量，0点是实时订单写入的峰值。当时有较多数据导入，对Worker产生较大的负荷，影响实例性能（比如RT，CPU使用率等），所以对部分blink写入脚本采取紧急降级操作，峰值过后1:10恢复降级，产生第二波较大的写入。问题定位和优化手段在Hologres团队的帮助下，经过反复的排查，发现问题主要有以下几个原因： 1）主要问题: Table Group&Shards数设置不合理，在高并发读取和写入峰值时，造成集群资源浪费和性能下降。零售通Hologres实例总计有几百core的计算资源，几TB的内存资源，和十几TB的存储资源。在实例创建后会根据实例规格生成默认数量的Table Group，然后每个Table Group会自动创建对应的Shard数（按照现有的规格，Shard数有300个），实例中存储的表都会被默认分发至这些Shard中。开发视角的Table Group和Shard 首先，先从开发者视角来理解一下Table Group和Shard的相关概念和原理：在Hologres中，1个DB包含多个Table Group，每个Table Group包含多个Table，每个Table只能属于一个Table Group。一个Table Group唯一对应一组Shard，由这组Shard来负责其中表的数据存储和查询，其包含的Shard个数称为Shard Count，Table Group一旦建立，Shard数不可调整。一个Table Group拥有的Shard数量（即Shard Count，后同）是它的一个重要属性。Shard数多的Table Group，其数据写入和查询分析处理可以得到更大的并行度，一定范围内，增大Shard数可以加快数据写入和查询分析的速度，但Shard数也并非越多越好，更多Shard数需要更多的节点间通信资源、计算资源以及内存资源，在资源不满足的时候，或者Query很小时可能会导致适得其反的效果。再结合具体的业务场景，当一个双表Join的SQL执行时，按照现有Shard数，执行计划会产生一个300*300 Shard的笛卡尔积（两张表都被分散300份），这在shuffle阶段对CPU和内存产生巨大的压力，也就意味着需要更多的节点间通信资源、计算资源以及内存资源。除此之外，单表的数据随机分散到300个Shard的过程中容易出现数据倾斜的问题，如下图所示设置Table Group和Shard建议零售通团队的业务场景大都是数据量偏少、表大小也非常不均匀，对于保障的优先级也不一致，所以上面将的所有表都放在一个300个Shard的Table Group中对实际业务并不适用，这就导致当流量增大时，没有办法有效利用Hologres的Local Join能力，导致CPU的开销剧增。正确的做法是按照使用场景、Join频次、表大小，分裂设计成不同的Table Group中存放数据；一方面可以提升集群性能提高计算速度，另一方面可以节省资源同时一定程度上实现资源合理分配隔离。新建Table Group的原则：数据量过大，可新建独立的较大Shard数的Table Group。当察觉写入性能变慢 or 读取200万行一个Shard时建议新建Table Group；有大量数据量很小的表，可适当独立出一个小Shard数的Table Group，减小Query启动开销；需要Join的表，尽量放在同一个Table Group；为Table Group设置合理的Shard数：Shard数不是越大越好，过大的Shard数会造成资源的浪费&负载过高，过小的Shards数会导致大数据量下读写性能不足以及不能抵挡较大的并发，下面也是经验总结出来的Shard数设置（仅供参考，实际需要根据实例规格和业务要求来设置）查询性能要求：若是业务对于查询要求较高，Shard数的设置是表在SQL中扫描的分区范围内的总行数的均值/200万 = 1 Shard 写入性能需求：Shard数和数据写入性能呈一定的正相关性，单个Shard的写入能力是相对固定的，Shard越多，写入的并发越多，写入的吞吐越高。因此，如果表有较高RPS的写入需求，需要增大Shard数。具体完整的计算方法参考如何选择合适的Shard数，也可以咨询Hologres技术小哥。 Table Group重构设计针对Table Group的设计，零售通对当前Hologres实例的期待是作为分析型OLAP实时数据库，在财年不扩充资源的情况下对现有表和业务需求梳理后有以下诉求：存放数仓中公共明细层，公共汇总层，维表；并能对公共层较明细的数据进行快速分析&开发（Local Join）；表单分区一般在数千万行量级营销活动分析数据产品的接口层存储，表格行数较少一般在单分区3000行以下，表格数量较少（10个以下）的Local Join，并发较高但不太会和外部表格频繁关联经营管理中心数据产品的接口层存储，表格行数较大，单分区可以到4亿行，不需要in，一般做灵活多维度汇总，并发较低商品评估中心数据产品的接口层存储，表格行数单分区千万行，一般不需要Join，不需要汇总，但需要根据条件在where中进行明细筛选最后决定设立4个Table Group：公共层TG：存放维表，明细表，公共汇总表，Local Join 以及汇总，分配较多资源营销+大屏TG：大屏及营销活动应用，数据量较少，主要用于历史对比，实时应用并发读写较大；采用20个Shard, 之前300个Shard是极大的资源浪费经营管理中心TG：经营管理中心各明细粒度表格，设置50个Shard 商品or行业TG：存放商品和类目结果数据，设置40个Shard 2）次要问题1：表结构设计数仓建设中，最重要的一个环节就是合理的设计表结构，包括表的数据类型、表的索引等。尤其是索引，合理的索引设计将会提高几倍甚至几十倍的性能。通过重新梳理表结构，发现业务并没有合理的设置表索引，这是导致性能不符合预期的原因之一，于是我们也对索引进行了改造。值得注意的是，当前和数据布局有关的索引的建立必须要在建表初期完成，后面不可以更改/新增，独立于数据布局的索引，比如bitmap，可以后面再按需修改。所以需要提前根据场景设计好表结构，以免做重复工作。 distribution_key 如果创建了Primary Key索引（也是唯一性约束，用于数据更新），默认为distribution_key。Distribution_key如果为空，默认是随机分发。如果distribution_key设置不合理，数据会不均匀分布于Shard中。计算过程中会产生Redistribute Motion算子数据重新分布打散，带来冗余的网络开销。如设置合理，则可以避免这种情况。通常设置关联（Join）的列或Group by的列或分散更随机的列作为distribution_key，来尽量打散数据到不同的Shard。请注意这里选择单列作为distribution_key即可。 Segment_key 分段键，用于文件块的边界划分，查询时基于Segment_key可以快速定位数据所在文件块，选择与写入时间戳相关的字段在查询时有加速的效果。一般用于时间戳这样的时序数据，Segment_key通常只用一列，遵循左对齐原则。Segment_key使用的限制比较多，要求文件在向Hologres写入时是按照Segment_key的顺序排序完成后再写入，即select后按照Segment_key进行order_by再写入，才会生效；一般适用于纯实时写入的自增/类自增字段（e.g.下单时间）。 Clustering_key 聚簇索引，是文件内的排序列，用于范围查询（RangeQuery）的快速过滤。与MySQL的聚簇索引不同，Hologres用来布局数据，不是布局索引，因此修改Clustering_key，需要重新数据导入，且只有一组Clustering_key，一般Clustering_key不超过2列。通常建议将where条件里面的筛选列设置为Clustering_key Bitmap 位图索引，对于等值过滤场景有明显的优化效果，多个等值过滤条件，通过向量高效计算; 适用于哑变量（基数低）的列，相当于哑变量一列变多列的实现。 Dictionary_encoding 字典编码列索引，可以将字符串的比较转为数字的比较，对于字符串类型可以有效压缩，特别是基数低的列，达到加速Group by，Filter的效果。Hologres在建表时会自动给text类型加上Bitmap索引和字典编码列索引，以实现更优的性能，但是需要注意的是，在不满足需要的场景下需要根据业务场景添加或删除相应的索引，因为dictionary_encoding会消耗编码解码的资源。下图是Hologres索引匹配原则，可以通过该图了解一下索引的执行原理：可以通过执行analyze参数，来获取表的统计信息，帮助Hologres在读取计算时将执行计划优化。 analyze tablename; 下面结合具体的示例展示怎样优化表结构： table1是一个数千万到亿行的明细表，对其他表（维表）有频繁Local Join的需求，和较大的并发写入； 1）根据业务查询和写入需求，将表放在公共层的Table Group中并分配60个Shard来满足读写需求。 2）因为是明细表，有大量的关联和等值/筛选场景，添加了较为全面索引配置：分析场景应用较多，有大量聚合，Group by操作，选择列存。 distribution_key：正常来讲应该满足常用Join的列+能尽量分散的列作为distribution_key；这张表作为明细表，很多列都会用于关联，所以不太好选一个key出来，选多个key的话反而会造成性能下降（要全部key都被使用才有效），最后决定选择较符合条件的id3作为distribution_key；这里像id1和id2是哑变量字段，适合同时配置Bitmap索引和字典编码列索引，方便Group by 和等值查询；对于日期（ds）设置为分区字段。明细表在查询和使用时日期都是必不可免的字段，通过设置分区，可以有效缩小每次查询的扫描范围；另一方面也可以较安全的进行运维和排查问题。当前表不适用Segment_key，因数据离线/实时两种插入模式，排序成本较高，暂不设置。对于Clustering_key，按照使用频次，目前的选择是id1+id2。最终DDL如下（因涉及业务敏感数据，只展示部分DDL）： BEGIN; CREATE TABLE public.table1 ( "stat_date" text, "id0" text, ....., "id3" text, "id2" text, "name2" text, ..., "id1" text, ...., "ds" text NOT NULL ) PARTITION BY LIST (ds); --如果是用来新建TableGroup,则需要下面第一句，已有TableGroup则不需要 call set_table_property('table1', 'shard_count', '60'); CALL set_table_property('table1', 'distribution_key', 'id3'); CALL SET_TABLE_PROPERTY('public.table1', 'orientation', 'column'); CALL SET_TABLE_PROPERTY('public.table1', 'clustering_key', 'id1,id2'); CALL SET_TABLE_PROPERTY('public.table1', 'bitmap_columns', '...,id1,id2,...'); CALL SET_TABLE_PROPERTY('public.table1', 'dictionary_encoding_columns', '...,id1,id2,...'); CALL SET_TABLE_PROPERTY('public.table1', 'time_to_live_in_seconds', '7776000'); COMMIT; 3）次要问题2：应用缓存对于重要高频报表添加合适的缓存来缓解数据库压力，离线报表可以设置时间较长的缓存，实时报表可以考虑在应用端增加 5s, 10s, 30s，1min等多个档位的缓存。 4）次要问题3：不合理压测计划在之前几次全链路压测中，对于Hologres实例进行读和查的多方面压测，虽然压测读的量到位了，但是没有同步压测数据库写入峰值，在实际场景中读的性能会受到写入数据洪流的压力和影响；尤其Hologres存在两种主要的写入方式（外表同步内表，实时写入内表）；在压测和实际使用的过程中需要特别注意读写峰值一起压测。优化后业务效果通过优化后，在双11这天0点的流量高峰期，在0点写入和Query读取同时达到业务峰值的情况下，Hologres支持的数据产品的RT平均响应时间稳定在100ms左右，为使用数据产品的业务同学/分析同学，在双11提供稳定毫秒级的实时OLAP决策数据支持。同时也非常平稳的支持了营销活动中心&实时大屏等核心的高并发业务产品，以及BI同学实时取数分析等场景，CPU水位稳定在30%以下，内存水位也稳定在50%以下。同时通过本次天猫双11，我们也发现Hologres作为实时数据存储，在分析方面有巨大的潜力，在满足写入性能的同时，一方面可以和现有离线数据关联分析，另一方面是能支持高性能的OLAP分析数据。这也团队后续使用Hologres作为数据团队新实时数仓架构的核心组件奠定了基础。后续规划经过双11之后，研发团队下个阶段将利用Hologres进行更大范围的实时数仓改造： Hologres作为行存实时公共层（替代之前timetunnel作为新中间件）开放下游数据库订阅, 保持对内整个架构和对外多个架构的数据一致性，以及解决实时结果数据在timetunnel中不可见，二次操作成本高的痛点。下游应用层订阅公共层实时数据，应用层数据按照保障级别和local_Join的需要进行实例级别分割，资源隔离。举例：以渠道数据化实例为例，这部分数据大部分对外开放给CRM系统和生态三方合作伙伴，对一致性，及时性和并发都有较高的要求，容易出现数据故障；在数据层面上也会有较频繁的Local Join诉求；综合来看作为单独实例分割，包给予充足的资源保障。

Hologres助力AliExpress双11实时数仓升级

概要：刚刚结束的2020天猫双11中，MaxCompute交互式分析（Hologres）+实时计算Flink搭建的云原生实时数仓首次在核心数据场景落地，为大数据平台创下一项新纪录。借此之际，我们将陆续推出云原生实时数仓双11实战系列内容，本篇将重点介绍Hologres在阿里巴巴AliExpress的最佳实践，并助力AliExpress实时数仓升级，节约成本近50%，提效300%。 AliExpress中文名是全球速卖通，是阿里巴巴面向国际市场打造的跨境电商平台，被广大卖家称为“国际版淘宝"，在2020年全球疫情肆虐的大背景下迎来了自己的10周年，伴随业务全球市场的拓展，AliExpress也同样遇到了大多数电商都会遇到的问题：流量红利逐步消失、拉新成本飞速上升以及引流效率的逐渐疲软等。业务发展需要从原始的野蛮生长逐步转向流量的精细化运营，于是帮助业务看清站内流量的分发及承接效率的流量通道也就应运而生了。关于电商平台元素的解析有大家比较熟悉的“人、货、场”分法，人和货相对好理解，场可以理解为消费者和商品之间创建特殊链接的产品形式，如搜索、推荐、店铺、猜你喜欢等，流量通道便是以更加结构化的方式描述平台元素之间的关系，实现更好研究不同场域流量效率的目的。在仅持续48小时（国际11不同于国内，持续2天）的双11大促过程中，数据更新的频率直接决定了业务做决策的频次，流量通道数据实时化的需求迫在眉睫。文章接下来希望带你一起还原借助Hologres卓越性能落地流量通道实时分析体系的过程。一、流量通道实时化数仓架构调研流量通道升级前停留在准实时架构，整体数据的时效为H+3（3小时前数据可查），所以接下来的重点工作变成了实时架构的设计及实现，综合AliExpress内部及其他BU的应用场景，主流实时数仓架构演进主要如下： 1）基于Flink+多数据引擎的Lambda数仓架构 Lambda实时数仓也是业界相对通用的解决方案，数据采集之后根据业务需求分为实时层与离线层，分别进行实时处理和离线处理。处理结果在数据服务层对接数据应用之前会进行数据的合并，从而实现实时数据与离线数据同时服务于在线数据应用和数据产品。离线层处理：采集数据归并到离线数仓之后，首先会统一到ODS层。对ODS层的数据进行简单数据清洗，构建DWD层（明细层）。在数据建模的过程中，为了提高数据分析效率以及进行业务分层，会对DWD层的数据进行进一步的加工和处理，相当于预计算。预计算结果在对接数据服务之前还会转储到一些离线存储系统中。实时层处理：逻辑与离线层类似，但是更加讲究时效性。实时层同样是对上游数据库或者系统的数据进行实时数据的订阅和消费。消费数据之后会将其写到实时的DWD层或DWS层。实时计算引擎提供的是计算能力，最终处理结果需要写到一些实时存储中，例如KV Store等。很多场景离线层还有一个重要的功能就是对实时层数据问题的修正，其次基于成本和开发效率的考虑，实时层一般保留两到三天的数据，而月、年的数据等更长的数据存储在离线数仓中，使用时需要离线数据和实时数据的结合场景，方式是引入了更多产品，如MySQL、ADB等。在流量通道场景，大促相关的分析往往需要对比历史同比或环比数据，比如需要和去年或者是前年的双11做对比分析，同样需要考虑到离线数据回刷或者数据一致性的问题。AliExpress已有的实时数仓也属于Lambda架构的范畴，流处理层的几个关键思路如下： Flink承担绝大部分的解析+聚合计算。消息队列TimeTunnel中沉淀抽象明细层和汇总层结果。按照维度表数据量级，选择使用Lindorm或者MaxCompute存储。根据下游应用场景特点将结果数据导入不同的存储引擎，例如为了提供高QPS的点查询引入Lindorm；为了对离线数据进行交互式分析，会引入ADB等。伴随业务的高速增长和数据膨胀，数据质量、运维复杂、成本高、业务敏捷性等问题也逐渐突显，具体如下：一致性问题：离线/实时2套代码、2套语义、2份数据。流和批执行的代码数据处理逻辑的不同，导致同一份源数据处理结果可能不一致，同时离线数据和实时数据合并过程需要不断地进行数据结构的重新定义，数据的转储、变化、合并，都可能引入数据一致性问题。常听到“流批一体”技术核心就是解决一致性问题。多套系统环环相扣，架构复杂，延迟风险大：数据计算链路长，穿插在若干Flink任务中间的TT sink节点降低了系统了鲁棒性，当某一个下游任务发现了数据异常，其向上溯源及排查成本被放大。而流式计算任务由于其实时的特性，往往给到开发定位和止血问题的时间都在小时级别，有时涉及线上系统甚至会要求分钟级别。开发周期长，业务不敏捷：复杂架构带来还有较高的开发、变更成本，任何一套数据或业务方案上线之前都需要进行数据校对、数据验证。数据校对过程中一旦出现问题，其定位和诊断将十分复杂，在极端情况下，实现一个实时任务的代码逻辑只占开发时间的20%不到，剩下80%时间都用于漫长的比对任务开发，数据校验调试，任务调优运维等，这对研发效能提升是非常大挑战。元数据管理困难、存储成本高：数据服务部分，针对不同的业务场景选择不同的数据库引擎，一方面存储成本成本增加，同时管理这些系统也变得异常麻烦，当底层存储引擎多样的时候，尤其是包含了很多KV引擎时，由于schema free的特点，我们很难有一种简洁友好的方式管理表及字段。 2）基于Flink+Lindorm实时数仓架构鉴于以上痛点，是否可以用Flink+Lindorm简化实时部分呢？Lindorm 是一个分布式的 No-SQL 数据库，数据以键值对形式存储，支持高并发、毫秒级响应的点查询，同时Flink作为当前业界最先进的流计算引擎，其动态表状态管理及回撤机制能满足大部分指标计算需求。从架构图可以看出，所有指标的计算，包括表关联、指标聚合、维表查询，都在Flink 引擎中完成。具体地讲，Flink 引擎实时处理消息，在引擎内存中保存指标的结果，当指标有更新时，会将结果通过回撤机制（指标结果的新旧值）通知下游算子，将指标结果的最新值更新到 Lindorm 中。这种方案最大的特点是指标的计算都是通过Flnk流引擎实现，然后将预计算好的多维 Cube 导入到 Lindorm 这个低延迟的分布式数据库中，从而可以实现亚秒级的查询响应。然而，这种架构存储明显的弊端：计算逻辑，资源消耗大：指标按不同维度组合都需要保存在 Flink 内存中，当指标粒度越细或指标时间跨度越大时，资源消耗越大。查询灵活性不足：计算逻辑需预先定义，无法灵活调整 Query。在流量通道的场景中，会有行业/产品/商品/商家等类似多维灵活交叉分析的场景。 3）基于Flink+Druid实时数仓架构 Flink+Druid如何呢？Druid 是一个分布式、支持实时多维 OLAP 分析的数据处理系统。它的关键特性在于支持根据时间戳对数据进行预聚合摄入和聚合分析，支持亚妙极高并发查询。此方案Flink只需要负责简单的ETL工作，指标的计算由 Druid 完成。Druid 按预先定义的指标计算模板进行预聚合计算存储，并对外提高查询服务。但是该方案的局限性也非常明显：查询灵活度不够：指标计算逻辑需预先按模板定义，同时数据预聚合存储，复用性明细降低了。表关联能力性能差：Druid在表关联场景支持比较弱，在流量通道的场景中，转化率相关指标的计算逻辑复杂，同时需要大量实时表的关联聚合。以上两种方案，在某些特定场景下均有较好的应用价值，比如 Flink+Lindorm 方案很适合实时大屏等时效性要求非常高的场景；Flink+Druid 方案则较适合超大数据量（万亿级）单表的实时多维分析场景。而对于流量分析场景，这两种方案都存在明显的局限性，无法满足我们的需求。二、基于Flink+Hologres实时数仓的实现偶然的机会，在公司内部看到淘系搜索推荐、客服体验事业部等在尝试Flink+Hologres的方式实现实时数仓，详细了解后，给了我们很大的信心，其中最吸引我们的能力有三点： Hologres高性能的写入：可以支持上百W+ RPS，同时支持数据实时写入即可查。 Hologres高性能的查询：基于 MPP 架构的分布式 ROLAP （Relational OLAP）分析引擎，各节点职责对等，各自负责一部分数据的处理（Shared Nothing），开发了向量化执行引擎，利用日志合并树、bitmap索引与 CPU 的 SIMD（单指令多数据，Single Instruction Multiple Data）等特性，充分发挥硬件优势，即使面对大数据量计算的场景，通常也能达到 CPU 性能的极限，达到高效计算的目的。具备同时支持PointQuery，Ad-hoc，OLAP，实时离线联邦分析等多业务场景的能力，让对外服务统一引擎成为可能。 Hologres丰富可扩展的存储：Hologres丰富可扩展的存储：Hologres支持行存和列存两种存储格式，采用计算与存储分离架构，便于水平弹性伸缩，可以支持海量（TB到PB）的数据存储。基于此，我们设计了流量通道实时架构：交互式计算：Flink只做简单明细层数据的产出，指标汇总在Hologres实时交互式触发。流批一体：历史明细数据提前导入Hologres内表，基于Hologres引擎同当天分区数据实时汇总比对。联邦查询：部分小维表直接作为Hologres外部表，做离线加速方式查询关联。图5-流量通道具体Flink+Hologres实时数仓实现那Flink+Hologres升级版实时数仓架构是如何解决Lindorm/Druid架构存在的问题呢？资源消耗大：Flink+Lindorm方案最大的局限性在于，所有维度的计算都通过Flink完成，Flink是纯内存有状态的流式计算，每到一条消息都需要对内存状态进行读取更新。维度组合复杂、聚合周期跨度较大时，内存往往会成为瓶颈，使得无法应对细粒度的分析需求。在流量通道场景场景中，查询均为人工触发，所以QPS相对较低，同时运营查询维度相对固定，实时CUBE存在大量的计算浪费，预期利用Hologres 强大的交互式查询能力，可以大大降低计算资源的消耗。灵活性不足：上述提及的两种方案，由于物理存储的是指标数据，都存在灵活性不足的缺点。当需新增不同维度的指标时，这两种方案都需要重新创建任务计算新指标，而新指标历史数据的回刷成本极高。基于Hologres的方案可以直接存储明细数据，具备满足各种查询维度的能力。表关联能力弱：流量通道分析遵循漏斗分析模型，从用户浏览->收藏加购->下单支付各阶段看流量转化的表现，所以存在大量大表关联操作。借助Hologres的特性，对主要分析链路的明细数据表进行精心设计，以满足流量分析场景中的大表关联需求。从整个分析链路来看，最终可以细化到每个设备在网站的行为表现，所以我们选取了设备id 作为表的分布键，充分利用 Hologres 的 Local Join 能力，使得大表的关联操作得以在秒级以内完成返回。运维成本高：大促往往具有数据量成倍增长的特点，因此需要在大促前进行资源预估以及扩容，而当大促结束后，为了不让资源浪费，会进行相应的缩容操作。对比Flink+Lindorm方案，由于计算负载都在Flink任务中，所以扩缩容主要集中在Flink任务上。而对Flink任务进行扩缩容的成本非常高，需要对每个任务独立执行停止-扩容/缩容-启动操作。Hologres的计算节点是云原生的，具有良好的弹性伸缩能力，因此，本方案在运维成本上基本可以忽略不计，大大降低了开发人员的工作量。三、业务价值从开始接触Hologres，到Hologres真正落地具体场景，Hologres带来诸多显著业务价值，主要体现在决策实时化，研发提效，降成本三方面。 1）成本节约50% 更简单的Flink计算逻辑，对比Flink+Lindorm方案，流量通道场景至少节省 6000 Cores。更简单的数据模型，无DWS实际存储，触发式计算代替了DWS预计算。 2）决策效率提升300% 实时准确的业务决策：双11有限48小时内，实时带来最大的价值便是根据流量实时的表现作出当前最直接的应对，保障应对方案的准确性和时效性，今年大促整体的有效的数据复盘从过去的1次提升为3次，时效价值提升300%，让我们对未来有了更大的想象空间。如图，2-3点这个区间运营发现会场通道浏览转化持续走低，及时调整后，实时数据验证提升效果符合预期。灵活的多维数据分析：实时数据产出后，分析师，业务运营等角色可以根据需求进行实时数据的筛选，过滤和分析展示，双11前烽火台（内部使用的数据产品）快速沉淀了行业、产品、商家、商品、海外仓等多视角通道效率分析的能力，其中商品、海外仓部分完成由运营同学自助完成。 3）研发效率提升30% 基于Flink+Hologres架构带给DA同学最大的惊喜便是研发效率的明显提升，项目初期评估整体需要40人日，伴随中间层数据侧产出，指标生产、数据验证、分析报表搭建等工作并行展开，实际人日减少11天，提效近30%，使得我们在大促前有更多的精力来做Hologres SQL调优及性能压测的工作。 4）更简单的数据加工链路事实明细层：直接开放公共层明细数据给到运营/BA/BI小二，需求交互方式SQL化，指标口径实时验证，开发效率由天级缩减至小时级，海外仓需求4合1，效率提升400%。事实汇总层：DWS视图化虽然增加了诸多性能方面的挑战，但更短的问题排除路径、更灵活的指标变更（无需数据回刷）带来的好处是显而易见的。数据展示：BI/BA可通过FBI/Vshow+Hologres方式自助搭建实时大屏，提升了业务自助数据分析的体验，解决了每年大促遇到的业务诉求和数据开发资源的Gap。 5）让业务打仗随时上膛-俄罗斯topBrand临时圈选今年俄罗斯受卢布贬值的影响(相对美元贬值，AE商品价格以美元计价，相对消费者来说价格变高)，双11最后的4小时标类行业用户下单意愿疲软，运营临时新增topBrand圈选需求，按照行业维度筛选出高于行业平均IPVUV价值但IPVUV低于行业平均值的商品，针对这部分商品做流量的加持，从而促进整体GMV目标的达成。四、对于Hologres的期望期待Hologres未来可以继续在流批一体、HSAP上做更深入的探索，也希望与Hologres保持更加深入的合作，期待的Hologres架构与能力如下：资源隔离：长期看批流统一计算后，大Query/小Query难以避免资源的抢占，资源组隔离即对计算资源进行弹性划分，不同资源组之间的计算资源在物理上完全隔离。通过账号绑定到不同的资源组，SQL查询根据绑定关系自动路由至对应的资源组执行命令，用户可以选择为不同的资源组设置不同的查询执行模式，从而满足用户实现实例内部多租户、混合负载的需求，当然如果Hologres调度可以自动优化资源抢占问题就更加完美了。流批一体：批和流一套引擎，运行在一套资源底座上，天然削峰填谷，自然混布，不仅节省了开发成本，同时也大幅节省了运维成本和资源成本。存储统一（方向一）：MaxCompute可以直接访问Hologres数据，准实时链路逐步升级实时，Hologres数据支持归档MaxCompute，逐步去除离线ODS，实现离线&实时数据的统一。计算统一（方向二）：基于Hologres一体的流批一体数据业务，MPP模式错峰执行流批任务。分时弹性：数仓系统的负载存在明细的时段波动，低峰期资源往往处于闲置阶段。分时弹性功能允许用户灵活定制弹性计划（每天定时），在业务高峰期来临之前自动进行扩容满足业务流量，即满足了业务流量高峰的需求，又降低了使用成本，同时结合资源组功能，甚至可以让某个资源组在低峰期时0节点，成本极低。数据分层：按表粒度、表的二级分区粒度独立选择冷、热存储介质，比如指定用户维表数据全部存储在本地SSD，或指定交易表的一部分分区数据存储在本地SSD，冷分区存储在OSS上，以达到最低的存储成本。行列混存：维度表订阅TT流实现维表实时更新，行列混存方式帮助维度表同时具备行存表的更新，列关联聚合的理想性能。行列自动转化：Flink/业务数据实时写入时，选择行存表，单记录全字段更新删除操作更友好，行存表如果可以自动转换为列存表，同时进行组合排序或多维排序，让列存表提供贴合业务场景的最佳查询性能。物化视图：简化数据清洗流程(ETL: Extract, Load, Transform)，帮助用户加速分析，如：大屏类业务加速，配合BI工具使用，或者是缓存一些公共中间结果集用以加速慢查询。作者：陈功（昀西），阿里巴巴数据技术及产品部技术专家李月（志歉），阿里巴巴数据技术及产品部技术专家

May-Hologres个人页面-阿里云开发者社区

个人介绍

擅长的技术

交互式分析（Hologres）2020年12月刊

正确设计Hologres实时数仓，性能提升10倍+

【月刊】交互式分析（Hologres）2020年11月刊

开放下载！《阿里云实时数仓Hologres最佳实践合集》

Hologres助力AliExpress双11实时数仓升级

交互式分析（Hologres）2020年12月刊

正确设计Hologres实时数仓，性能提升10倍+

【月刊】交互式分析（Hologres）2020年11月刊

开放下载！《阿里云实时数仓Hologres最佳实践合集》

Hologres助力AliExpress双11实时数仓升级

首次揭秘云原生Hologres存储引擎

首次公开！阿里巴巴云原生实时数仓核心技术揭秘

Hologres+Flink流批一体首次落地4982亿背后的营销分析大屏

Hologres助力飞猪双11实时数据大屏秒级响应

Hologres+MaxCompute数据仓库服务化详解

开源OLAP迁移至Hologres

Hologres+Flink实时数仓详解

快速上手Hologres

Hologres产品介绍与技术揭秘

揭秘双11丝滑般剁手之路背后的网络监控技术

Hologres是如何完美支撑双11智能客服实时数仓的？

【月刊】交互式分析（Hologres）2020年10月刊

58快狗打车基于Hologres的实时离线统一数据服务

天猫国际通过Hologres进行排行榜的实时交互式分析

店开天下，阿里云助力客如云数据中台建设

交互式分析（Hologres）2020年12月刊

正确设计Hologres实时数仓，性能提升10倍+

【月刊】交互式分析（Hologres）2020年11月刊

开放下载！《阿里云实时数仓Hologres最佳实践合集》

Hologres助力AliExpress双11实时数仓升级

首次揭秘云原生Hologres存储引擎

首次公开！阿里巴巴云原生实时数仓核心技术揭秘

Hologres+Flink流批一体首次落地4982亿背后的营销分析大屏

Hologres助力飞猪双11实时数据大屏秒级响应

Hologres+MaxCompute数据仓库服务化详解

开源OLAP迁移至Hologres

Hologres+Flink实时数仓详解

快速上手Hologres

Hologres产品介绍与技术揭秘

揭秘双11丝滑般剁手之路背后的网络监控技术

Hologres是如何完美支撑双11智能客服实时数仓的？

【月刊】交互式分析（Hologres）2020年10月刊

58快狗打车基于Hologres的实时离线统一数据服务

天猫国际通过Hologres进行排行榜的实时交互式分析

店开天下，阿里云助力客如云数据中台建设