从阿里核心场景看实时数仓发展趋势发布会上，阿里资深技术专家从阿里核心场景出发，解读了实时数仓“在线、敏捷、一体”的发展新趋势。停止”。通过本文，我们将深入解读实时数仓发展面临的问题，以及核心发展趋势，帮助您更好地进行产品选型和数仓规划。实时数仓是现在大数据领域非常流行的一个概念（同样流行的大概是湖仓一体化）。经过十多年的发展，大数据已经成为每个企业的标配。传统上，离线数仓（开源以Hive/Spark为代表，闭源以AliMaxCompute、Snowflake、AWSRedshift、GoogleBigQuery等为代表，以及Vertica、Oracle、HANA等传统IT厂商）、流媒体计算（以Flink/SparkStructuredStreaming为代表）、数据服务层（HBase、MySQL、ES、Redis等）共同构成了大数据处理的标准架构：Lambda架构。Lambda架构提供实时数据服务（serving）能力。但Lambda架构的典型问题是开发复杂、数据冗余和分析不灵活。近年来，以ClickHouse、ApacheDoris、AliHologres为代表的实时数仓如雨后春笋般涌现。通过详细数据的实时写入+灵活的交互查询，实现了Lambda架构。在实时性、灵活性、成本、管理和运维等多方面都取得了很好的平衡。随着2021年双十一的完美落幕，实时数仓技术也在阿里巴巴双十一场景中经历了多年的实践和发展。从早期基于不同操作的烟囱开发，到引入基于领域分层建模的数据仓库，再到分析服务集成的全新一体化一站式架构，开发效率逐步提升，数据质量更有保障，技术含量更高创新的沉淀，让我们看到了未来数据仓库发展和应用的一些可能性和趋势。下面说说从阿里双11看到的实时数仓发展的一些趋势。1、实时数仓已经成为业务的标配。第一个趋势是实时数仓成为标配。业务对时效性和灵活性的要求越来越高，这使得实时数据成为刚需。实时数仓在成本和灵活性方面的巨大优势，使得企业优先选择实时数仓作为实时数据的生产、存储和使用平台。在阿里巴巴，Hologres服务于约90%的BU，集群规模超过60万核，并保持100%的增长率。在这些业务中，还有比较常见的实时数仓场景，比如：数字化运营：该场景中，上游对接Flink进行数据流处理；下游对接BI工具、数据大屏等，实现业务的自助开发和上线。大大提高了开发效率和灵活性，支持所见即所得的开发体验。网络流量分析和Metrics分析：通过对网络流量等Metrics数据的实时存储和监控，快速预警和定位潜在的设备故障。万亿级记录查询秒级响应，秒级故障检测。实时物流跟踪：通过实时数据仓库对物流信息进行实时跟踪，保证物流流转状态的实时更新和实时查询。除了这些比较常见的实时数仓场景，因为分析服务集成（HybridServing/AnalyticsProcessing，以下简称HSAP）能力（以及对应的Hologres高速纯实时写入能力和枚举能力）),Hologres也被用在很多非典型的实时数仓场景中。例如：商家广告选群：Hologres为商家（toB）提供高QPS、低延迟的选群和广告投放服务。无人车配送：Hologres承载无人车上货物的订单和物流指标信息，为B端站实时上报物流信息，从而帮助站主完成包裹智能分拣、移动化等任务投递；为用户，再通过系统调度运力，实现“定时送货上门、送货到楼”。搜索推荐中的特征存储和样本存储：利用Hologres强大的point-check能力，实现实时特征存储、实时特征存储和实时算法效果分析。客户全链路体验：客服部门将客户的相关多渠道数据存储在Hologres中，直接向消费??者提供各种详细查询能力（toC）。……类似的场景还有很多。数据的实时“看”和“用”成为企业快速发展的原动力。2、实时数仓支持在线生产系统第二个趋势是实时数仓越来越成为生产系统的一部分。传统上，一个实时数据仓库（datawarehouse）是一个非生产系统。因为主要面向内部客户，虽然大屏重要性高，但实时数仓不在生产的关键环节。也就是说，如果实时数仓不可用，对客户的影响不大。这也是为什么大多数实时数仓产品与数据库等系统在高可用、资源隔离、容灾等能力上存在较大差距的原因。传统上，对外服务是通过离线/流式处理+结果校验的方式提供的，即与用户交互的关键环节是结果校验（HBase、Redis、MySQL等系统托管）。这种模式的优点是简单可靠，但局限性也很大，能够提供的服务功能非常有限且不灵活。业务渴望以可控的方式向外部客户（toB，toC）开放内部实时数仓能力，并保持内外部系统数据和逻辑的一致性。上述阿里广告、无人车配送、客户全链路体验等场景，都是toB甚至toC的案例，随着实时数仓作为服务提供，用户提出了更高的要求服务的并发性、可用性和稳定性。这也是Hologres过去一年重点发力的地方。Hologres在过去的一年里引入了多副本、热升级、快速故障转移、资源隔离、读写分离、容灾等能力，实现了生产级高可用，并在今年的双十一得到了很好的应用举几个例子：去年，阿里巴巴的首席客户办公室（CCO）实现了双链路写入和存储冗余，以确保高可用性。今年双11采用Hologres原生高可用解决方案，去掉手动双链路，节省了备份数据链路上实时任务开发和数据比对的人力投入，减少了链路切换时的数据不一致，降低了整体开发人工成本下降200。人日数比去年减少50%以上；实时再保险减少100+备份链路操作，计算资源减少2000CU。阿里巴巴数据产品与技术部（DataTechnology，以下简称DT）采用Hologres读写分离方案，让高吞吐写入和灵活查询互不干扰；分析查询QPS提升80%的同时，查询抖动明显降低。我们认为实时数仓的生产系统化是必然趋势，相信所有的实时数仓产品都会逐步加大这方面的开发投入。3.分析服务集成（HSAP）第三个趋势是分析服务集成（HSAP）。Hologres是这方面的始作俑者。源头是阿里巴巴集团内部的业务对分析服务的整合有着强烈的需求。分析服务集成的最佳实践首先在阿里落地，但我们也看到行业内越来越多的产品。与企业在宣传和实践分析服务方面的整合。AnalysisServiceIntegration（HSAP）可以从几个层面来理解：最基本的是用户可以使用一个技术栈（Flink+Hologres）来解决Ad-hocQuery分析（内部）和在线服务（内部，toB，toC）)两项任务，从而降低开发和运维成本。传统上，实时数仓实现的是Ad-hocQuery，而lambda架构实现的是在线服务。这两者在技术栈、数据链接、开发维护等方面完全不同，但处理的数据来源往往是同一个数据，导致大量冗余的开发操作，数据一致性也是一个难题大问题。通过使用统一的技术栈同时满足这两方面的需求，让开发、运维、治理变得更简单。以阿里CCO的场景为例，数据写入Hologres行存储表后（行存储表写入吞吐量高，主键查询速度快，binlog更新成本低），binlog的Hologres表将被Flink第二次消费和处理，存储在Hologres的列存表中提供分析（列存对于统计查询速度快）。行存表提供在线服务/查询，列存表提供分析能力。更高层次的HSAP是用户可以使用一份数据在一个平台上实现Ad-hocQuery和在线服务，同时实现良好的资源隔离和可用性。比如今年双十一DT部门推出了Hologres读写分离方案（两个Hologres实例分别负责实时写入和实时查询，但共享一个底层数据存储），多个读实例负责不同类型的查询，从而保证读写隔离、分析查询和业务查询隔离，数据只有一份。也就是所谓的OneData,MultiWorkload。除了上述分析服务整合带来的好处外，另一个显着优势是服务上线速度显着加快。融合之后，分析和服务的界限变得模糊，所以服务开发和分析没有太大的区别，服务可以认为是一种简单的分析，有固定的模式。这样一来，传统上复杂的服务上线流程就大大简化了。当临时开发急需时，也可以立即上线，无需繁琐的手续。我们相信，随着Hologres等产品的发展，集成分析服务的理念将会落地到更多的场景中。而这也将像Hologres这样反哺HSAP产品，更好地将HSAP的概念、方法论、支持能力沉淀在产品中，让更多的用户更容易从HSAP中获益。4、实时数据治理成为刚需。第四个趋势是实时数据治理变得越来越重要。实时数据对企业有着致命的吸引力。因此，企业会自觉不自觉地逐步加大对实时数仓的投入。但由于实时性要求，各企业的实时数仓往往没有实现离线数仓的严格方法论和管理制度。因为没有治理，大量冗余或不合理的数据往往会导致成本急剧增加和数据可信度下降。在阿里这样的超大型企业，这个成本会凸显出来，成为对实时数仓的刚性需求。通过对实时数仓、离线数仓、流式计算、消息队列等全链路数据进行数据治理，可以实现数据无“合法场所”，在提升成本的同时节约成本数据质量和真正转换数据成为企业的资产。5、类数据库实时数据仓库第五个趋势是类数据库实时数据仓库。大数据诞生于对传统数据库的扬弃。从NoSQL到NewSQL，大数据产品走上了独立于数据库的道路。但就像从NoSQL到NewSQL一样，大数据产品中的实时数仓也在向数据库学习，提供与数据库更好的兼容性，让用户能够以更低的成本使用实时数仓产品。这包括几个方面：可操作的SQL以及在协议和语法上与传统数据库的兼容，让开发者可以使用熟悉的工具（BI、开发工具等）进行连接和开发。这方面大数据的积累还不如数据库几十年的积累。相当一部分商科学生对数据库非常精通，但是大数据（尤其是实时数仓）入门并不容易。数据模型和语义更接近传统数据库。例如，传统数仓产品缺少PrimaryKey的概念，数仓产品往往不能保证操作的原子性，限制了很多场景的应用。比如Clickhouse缺少数据库意义上的主键（CK说的主键是另外一回事，非唯一约束），所以不适合处理数据库CDC同步场景。近两年，大数据行业可以明显看到这方面的提升。最典型的例子是以DeltaLake、Iceberge、Hudi为代表的近实时数仓加入ACID能力。当然，受制于架构，这种近实时的ACID在频繁更新场景下的性能和延迟存在瓶颈。在阿里巴巴，大量的场景都需要这种基于主键的更新能力。以阿里巴巴内部场景为例：数据库实时同步：通过将上游分库分表和多个业务数据库实时同步（镜像）到一个大数据数据仓库中，可以为业务数据提供强大的分析能力，而这需要很好地处理纯实时的高频UPDATE和DELETE操作。Flink计算产生的UPDATE和DELETE（RETRACTION）操作：比如统计GMV，Flink在结果更新时会产生UPDATE记录，在某些场景下会产生RETRACTION记录（DELETE），需要下游系统来处理这个出色地。两种类型的事件。风控等业务的计算由多个作业完成。这些作业共同实时更新一个大的宽表（每个作业更新一些字段），这就需要下游系统提供基于主键的局部更新能力。传统上，此类服务由HBase、Redis等NoSQL系统或MySQL、PostgreSQL等数据库RDS承担。但是NoSQL的问题是分析能力普遍较弱，而数据库的问题是写入性能和规模受限。这些业务在大数据处理中很常见。但在阿里面临的挑战是，由于规模巨大（尤其是双11这样的场景），对基于主键的更新性能和延迟有严格的要求。Hologres的设计从一开始就考虑了这两点。Hologres完全兼容PostgreSQL11的协议、语法、函数等，许多PostgreSQL扩展（如PostGIS）可以直接使用。同时，Hologres提供完整的主键概念和强大的更新能力，并提供单SQLACID。今年双11，有业务实测每秒350万+的实时写更新性能。这些能力大大放宽了实时数仓的应用场景，将NoSQL和RDS承载的传统场景转变为实时数仓，为用户提供更强大的分析处理工具。实时数仓的类数据库改造不等同于HTAP数据库。与HTAP相比，HSAP弱化了交易能力。因为在服务场景下，不需要传统数据库完整的事务能力。而这种放弃带来了实时写入性能和查询性能的极大提升，以及可伸缩性的提升（因为不需要全局事务管理器）。所以HSAP比HTAP更适合大数据场景。6.实时数据仓库开发的敏捷性最后一个趋势是开发方法的变化。实时数仓的发展越来越敏捷，以适应灵活多变的分析场景。以往数据仓库的开发往往遵循经典的方法论，采用ODS->DWD->DWS->ADS逐层开发的方式，层与层之间采用事件驱动或微批调度。分层带来更好的语义层抽象和数据复用，但也增加了对调度的依赖，降低了数据的时效性，降低了灵活数据分析的敏捷性。实时数据仓库驱动实时业务决策，决策通常需要丰富的上下文信息。因此，传统的根据业务高度定制化的ADS开发方式受到了极大的挑战。上千张ADS表维护难度大，利用率低，更多业务方希望通过DWS甚至DWD进行多角度的数据对比分析，这对业务端的计算效率、调度效率、IO效率提出了更高的要求查询引擎。凭借计算算子向量化重写、精细化索引、异步执行、多级缓存等多种查询引擎优化技术，Hologres的计算能力在各个版本都得到了极大的提升。因此，我们看到越来越多的用户正在采用敏捷开发方式。在预计算阶段，只需要数据质量清洗，基本的大表关联拓宽，建模到DWD和DWS就可以减少构建任务。同时，在真正分析时，在交互式查询引擎中执行灵活的查询。通过秒级交互分析体验，支持数据分析大众化的重要趋势。7.总结阿里巴巴是业内较早使用实时数据仓库处理海量数据的公司。阿里实时数仓的发展也逐渐进入深水区。无论是生产的系统化、分析服务的集成化、实时数据治理（平台化），还是数据库化和敏捷化，实时数仓都随着业务需求的快速发展而快速迭代，每年的大戏如双11越闪越亮，成为生意中不可或缺的伙伴和助手。业务驱动技术，数据带来价值，实时数仓Hologres与阿里巴巴核心业务共同成长打磨，从多维复杂OLAP分析到高QPS点检，高性能实时写入更新到高可用，提供大数据平台统一分析服务导出，满足一站式实时数仓、全流程、全场景的存储、开发、管理、服务。我们相信实时数据仓库的这些趋势也适用于整个行业。我们会逐步利用阿里云产品双十一积累的能力，帮助客户用好实时数仓，共同成长！【本文为专栏作者《阿里巴巴官方技术》原稿，转载请联系原作者】点此查看作者更多好文
