美空何静从当前实时场景下的核心需求出发，来看阿里在面对这些场景诉求时提出的方案是什么？实时数仓并不是只有一种固定架构，这里会根据不同的场景来设计不同的技术方案，最后通过实际的案例来看实时数仓架构的演化过程。

　　现在每个人都在谈实时，实时有很多含义，实时写入、实时分析、实时加工、实时分析应用，多个环节非常复杂，其实背后都体现了业务变化。早期数字化转型的时候都是看数字大屏，给领导层做决策，在之后的数据应用分两个方向，一个方向是做精细化运营分析，数字决策从领导层到基层演变。领导层通常有对应的IT团队来帮忙制作报表，到了基层的时候灵活分析就显得格外重要，因为没有足够的IT资源来协助做更多更个性的报表以满足此类需求，就有很多自助分析的应用出现，支持使用者灵活拖拽方式自定义报表；另一个方向是数据要直接服务在线业务，做实时推荐、实时画像、实时风控，这些和在线业务系统紧密结合的场景，对延迟、QPS要求远高于传统分析系统，大数据系统从内部的运营系统变为在线的业务系统，这是我看到的两个重要趋势。

　　对于一个复杂的大数据平台来讲，数据源一般有两种，日志的埋点系统和数据库的业务系统，通过实时和批量两种方式进入大数据平台，明细表一般会通过聚合得到类似7天点击率、30天留存、90天喜好等指标。

　　由上图所示，左半部分是数据的加工环节，通过实时写入的明细数据a，经过聚合，结合数仓明细层-聚合层-应用层的分层，最终产生需要的结果数据；右半部分是数据的使用环节，最简单的使用是交互式、探索式分析，使用方可以根据使用的特征进行过滤、统计、对比，选择不同的维度组合。第二种是面向大屏，包括UV、GMV的计算，希望事件产生的时候数据实时变化，发生即可见；第三种是一些在线业务的使用，类似A/B测试、在线推荐应用、实时风控等，这类系统也需要访问大数据平台，去了解用户的画像是什么，商品的画像是什么，做u2u，i2i等相关度推荐，了解行为标签，做风控打分告警。所以说大数据平台不仅要支撑内部的分析应用，也要支撑在线应用。这是一套批流多路、混合负载的复杂系统。

　　在支撑这类混合负载的大数据平台时，过去大多数公司首先采用可扩展的、可以调用更多计算资源的离线加工引擎处理规模数据，如Hive，Spark，MaxCompute等，业务方往往会希望数据非常实时，希望事件产生时就有在线加工的效果，比如股票推荐，随着股票交易记录的产生就得告诉用户哪支股票值得关注，不能等股票交易结束第二天再来告诉用户统计出来哪只股票可以进入。

　　所以就有很多事件产生直接做加工的场景，通过像Flink、Spark Streaming这样的流式加工技术来实现计算前置，并将计算结果保存在HBase、Redis等系统提供快速访问；还有一路，计算规模不如离线，但交互式分析能力比离线统计更灵活，包括clickhouse、druid这样的实时系统，支持数据的实时写入，以数据接近源时的状态直接灵活分析。

　　这样整体架构分离线、实时、在线三种链路，三种链路对应不同的技术架构及存储引擎，数据产生了割裂，割裂之后还需要补充联邦查询技术，对外提供一个统一的查询入口，但是数据散布在不同的系统里面，也许可以解决统一数据界面的问题，但性能和一致性很难保证，性能上联邦查询是和最慢的执行过程对齐，一致性上一个源头多条链路，加工逻辑很难保证处处一致，日常数据偏差和核对工作量很大。

　　很多时候还需要缓存系统，大数据加工的结果集存在一个缓存系统，实时的需求让整个系统呈现一种“纷繁复杂”的状态。从架构师角度看，不同的箭头代表了不同的业务场景，但从运维角度来看是一个近乎灾难的状态。因为当数据消费端，比如报表数据发生显著变化时，无法确定是数据加工逻辑有误还是源数据数据质量的问题，链路太多，太长，需要花费大量时间查错、排错，任何一个环节数据质量出问题，数据结构要调整，数据脚本写错，都会影响对下游的使用，整体系统的维护性就很差。

　　时效性分为两种，端到端延迟短意味着事件产生到应用侧的流转时间越短越好，从分钟-秒-毫秒，我叫它实时系统；准时意味着做决策时依赖的数据足够准确有效，我叫它准时系统。端到端延迟最短的场景下往往不是人做决策的场景，是一些风控类、推荐类的场景，是机器做决策的场景，需要在事件产生的时候根据事件的特征判断，通常采用计算前置的方式，会把计算逻辑通过Flink等流式计算的方式提前写好，当事件产生的时候直接算出结果，实时做自动的决策；但人做决策一定是通过数据对比、排序、关联之后，才去做决策，人做决策也需要时效的要求，但分钟级一般也可以满足需求，不影响决策结果，准时系统更多的是计算后置，可以做灵活的查询组合、对比分析。

　　这是两个不同的计算场景，很多时候都笼统称为实时系统，但其实背后依赖的技术是不一样的，如果追求的是端到端延迟短，需要采用计算前置；如果是决策的时候希望数据足够新鲜有效，也需要灵活自助，需要采用计算后置的方式。当需要灵活看不同维度组合的排行榜时就要采用计算后置的方式。

　　当数据散布在多个系统时，就需要有很好的数据质量发现和纠正的能力。数据是否满足在加工各个环节中的状态可被检查，当出现数据质量问题时，是否可以通过明细数据来溯源；其次，当发现数据质量问题之后，会花费多少时间来修复数据质量问题？数据质量修正往往是某个字段、某些记录的更新，在当前追求规模性、可拓展性的大数据系统中，是否可以支持灵活单行单列的更新？数据散布在多个系统中时，逐个分别更新，更新效率是否满足。

　　成本可以分为开发成本、运维成本和人力成本，而开发成本相对更重要：将技术和业务解耦，技术团队保证数据资产的可复用，业务团队可以自助开发，这样才能降低更多的技术成本，开发同学只需要维护数据数仓的稳定性和执行效率，报表的开发可以交由业务同学来完成；运维成本说的是弹性伸缩及容错能力，面对各类促销、绩效报账等业务洪峰时是否能及时扩容，洪峰过后是否支持弹性缩容，从而最大程度降低公司的成本；还有人力成本，一个懂得源码、能搞定存储查询的高技能大数据人才需要花费大量精力去培养，最后还得应对人才流失的分险，这肯定是不划算的。因此一个好的系统门槛要相对较低，开发接口标准要相对简单、标准来降低成本，以满足未来会使用SQL的人都可以使用大数据的趋势。

　　1.0 是数据结构具备表模型能力，丰富SQL的表达能力，具备企业级数仓的管理形态。

　　2. 0是满足高吞吐的写入，支持灵活的更新能力及写入之后交互式查询，写入即可见，也支持一定的实时加工的能力。

　　3.0 包括了端到端的实时加工的能力，同时可以同时支撑多种负载，包括OLAP和在线服务，支持读写隔离、高可用，满足复杂大数据平台的用数需求；也要支持实时离线一体的能力，离线数据可以对实时数据进行修正和补充，进一步丰富实时的场景，两个系统之间需要原生集成的能力。

　　当前大数据的发展形态可以对比上世纪六十、七十年代，当时程序员都在考虑数据该怎么存储，是写到一个文件、还是网状结构、层级结构，每个程序员都需要自己管理状态；到80年代的时候，随着关系型DB、SQL语言的崛起，将状态存储在数据库中，用ER模型来简化数据组织，用SQL来表达对数据的访问；而在10年前大数据崛起之后，基于对存储和查询的效率考量，针对数据的存储特征会将数据存储于不同的系统中，但多数分析方式还是基于SQL来实现；因此未来人们谈论更多的应该是分析技术，而良好的分布式及扩展特性的大数据技术会成为每个数据平台背后的基本原理，但是本质上还是分析系统。

　　事务类系统(OLTP)基本上是行存，面向行的更新，追求TPS足够高以及ACID的保证；分析类系统追求的是分析、统计场景下足够的高效，多采用分布式、并行、列存等技术；而服务类系统(Serving)以Redis、Hbase为主，提供高性能的简单读写服务。所以一份数据从OLTP系统产生、同步到OLAP系统做分析和加工，再同步到Serving系统提供数据服务，整个同步及转移过程存在数据不一致，针对这种风险有了HTAP和HSAP的创新方向，HTAP使用门槛相对较低，OLTP系统产生之后可以直接分析，有一定的负载隔离能力，但在数据模型方面仍有局限，很难直接去做分析式应用；而HSAP以数仓模型来解决数据服务的问题，虽然事务能力稍微弱些，但是能更好地支撑在线系统的高吞吐和高效率。

　　阿里巴巴基于内部数据场景的需求演进研发了实时数仓系统Hologres，它基于一站式实时数仓的HSAP（Hybrid Serving & Analytical Processing，分析服务一体化）理念，在存储层，既支持批量数据的导入，也支持在线的实时写入与更新，不管是离线的数据还是实时的数据都可以存储在一个系统，在服务层，支持多种负载，保证了高性能的在线点查应用，也支持灵活的多维分析，提供统一数据服务层，减少数据割裂。

　　在阿里内部实时系统链路基本上会由三个组件来完成MaxCompute、Hologres、Flink，也是阿里一体化数仓的最佳实践。

　　从上图可以看到事件流左侧包括用户及交易数据、行为埋点数据，而这些数据通过数据同步服务有三种链路可以进行加工。

　　第一种链路是实时链路，埋点数据大家一般只关心session里面用户的一个点击路径，这样的话通过Flink的实时加工可以把每秒钟百万级的数据转换为每秒钟几万的数据进行分析，而在埋点的原始数据中保留的都是ID字段，因此在实时加工链路还需要做维表的lookup来将维表拉宽，这时就需要用到Hbase、Redis等提供高性能点查能力的组件，而阿里很多系统采用Hologres的行存表点查支持这种场景，同时保存Flink加工完后的轻度汇总数据，类似统计PV、UV偏实时的场景就需要用这种实时链路来完成。

　　下面的链路是离线加工链路，离线的调用资源及稳定性更好，同时时效性要求不高，一般都是T+1时效，因此在计算类似7天、30天、60天的漏斗留存指标时，阿里内部会用MaxCompute来进行批量加工，加工完后的结果数据同步到在线系统，而明细数据因为数据量大，访问频率低，通常不会导入到在线系统，Hologres和MaxCompute之间有联邦查询的能力，数据不做移动通过外表可以做关联的分析，满足了下钻去看明细数据的需求。

　　中间的链路是数据简化加工，以明细层和轻度汇总层为主，通过Hologres来向下游服务。在线服务及报表应用都通过Hologres统一出口来进行访问，提高了安全监控及开发效率。

　　，满足高性能实时写入与更新，支持列存及多种索引，支持主键更新及局部更新，支持复杂Join和嵌套查询。

　　，支持用户画像及在线推荐、Flink实时维表关联场景，支持行列共存，高QPS点查能力。

　　，对MaxCompute、DLF、OSS数据湖中的表进行秒级交互式查询，每秒百万行数据同步。

　　Hologres技术特点的实现依靠整体技术环境的提升，第一是网络越来越稳定，高带宽、低延迟，Hologres因此将所有存储的可靠性、存储状态的迁移到外部网盘Pangu来处理，这样实现了计算节点无状态，任何计算节点宕机直接重新启动新容器即可，做扩容的时候也不需要做文件的Copy，几分钟就可以实现上百个节点的扩展。

　　同时，Hologres还利用了磁盘自身的随机访问能力并借鉴了传统数仓所采用的一些技术，例如多节点分片、单节点分段，编码压缩，聚簇索引、位图索引等多种索引。

　　最后是发挥极致的CPU能力，基于当前CPU内部多核化的趋势，需要使用更贴近操作系统底层的C++开发、将向量化、异步化算子发挥到极致，这也是把系统性能发挥到机制的重要环节。

　　Hologres采用存储计算分离架构，分为计算节点和存储节点，存储采用的是阿里自研的Pangu文件系统(类似HDFS，但是性能及可靠性更优)，而计算节点由多个worker node容器组成，扩充计算能力通过worker node横向增加来实现，worker node之上是接入节点，负责做SQL逻辑的解析、优化等，然后将SQL转换为分布式算子交由worker node计算。

　　在Hologres中，Shard的概念在存储和计算都有，这个特性我称之为shard的一体两面性，从物理资源上来讲，shard是保存在存储节点，表述的是一组表的部分数据，而计算节点的shard可以认为是对应数据在运行时的一个内存状态，某一份shard的所有读和写都由绑定的worker node来负责。

　　这也体现了离线和在线系统本质上的差异，离线系统计算节点和存储节点完全是解耦开来的，计算节点空闲了才会进行后面计算，而在线系统需要把离线和在线的状态做一个耦合来实现极致的效率，也就是当机器启动的时候，worker node就绑定了shard，并接管了对应的CPU和内存资源。

　　以Oracle计算存储分离的Shared Storage技术架构为例，各个计算节点认为使用一个网盘，这个时候需要对内网访问的带宽能力、可靠性、延迟性要求很高，因此硬件成本极高，可扩展性有限；后续演进到Shared Nothing架构，计算节点和存储节点完全分离，每个节点都是独立的，类似Greenplum就采用这种架构，这个架构节点有状态，所以迁移扩容、故障恢复的门槛会更高，稳定性也依赖各个节点的可靠性。而Hologres结合了Shared Storage开发上的便利度和Shared Nothing上访问本地盘效率的能力，采用了计算存储解耦的方式，并且采用本地盘进行缓存提升效率。

　　Hologres采用类LSM结构并搭配了内存表Memtable，最大化写入吞吐量以及最小化数据可见延迟，具备很好的随机读写能力，数据先写入到WAL中，WAL数据存储在Pangu中，然后再写到内存中的Memtable，实现了数据写进来就可以读的效果，当满足一定的阈值后就会将内存数据按照LSM分层去刷写到磁盘中，使用Append only的方式来实现数据高吞吐的写入，在读取的时候将内存和磁盘的数据合并以保持最新的状态，后台会有Compaction进程周期性对分层文件进行合并压缩。

　　在用户画像、Flink维表关联等场景，需要通过ID来查询数据，这时一行的数据在一个IO块时，通过行存的主键去查询的时候效率很高；而列存是把一列的数据存在一个IO块里，通过某些标签做统计分析时列存更具优势。

　　对于SQL的执行来说，Hologres会分为标准查询和简单查询两种链路，类似对单张表某个字段的访问的可以通过索引很快定位到某个IO块的查询称为简单查询，这种情况会直接走Fixed Plan链路，直接分发到存储引擎，绕过了复杂的优化、调度模块等，从而实现了简单查询的高性能吞吐；而需要做多表关联的普通查询时，就需要优化器等分析，生成计划和算子，然后再分发到存储引擎，而查询引擎分为HQE和PQE，HQE（Hologres Query Engine）是Hologres自研的向量化查询引擎，而PQE（Postgres Query Engine）是对原Postgresql引擎进行了分布式优化，当一些原生的PG算子或数据类型HQE还不支持的时候，就会转发到PQE上去。当前HQE已经支持90%的算子查询，后续会做到完全覆盖PG的原生算子。

　　Hologres在负载隔离方面做了很多创新，支持共享数据的多实例部署模式，主实例和从实例在计算资源上是物理隔离的，但是数据只有一份，在共享的Pangu上；多实例同Region部署共享存储，实时高可用，多Region部署数据自动复制，秒级灾备，当指定一个实例是写实例时，其他实例就是读实例，当写实例写好之后，其他实例实时可见做到了数据一致性；同时计算资源物理隔离，实例之间故障隔离，当写入实例宕机后，不会影响只读实例。

　　Hologres表的更新操作会产生binlog，当把RDS的binlog写入到Hologres后，Hologres产生的binlog可以继续给Flink二次加工，实现了Hologres binlog+Flink层与层之间有状态的连续加工，实现端到端的实时加工，替代了传统使用Kafka+Flink+ClickHouse的场景，不仅减少了数据存储开销，更重要是可以直接通过SQL的方式校验数据，修正数据，对于检查数据质量有很大的帮助。需要注意的点是Hologres的数据是分shard来保存，binlog在shard内部是有序的，并不是全局有序。

　　Hologres对JSON数据做了列式存储优化，通过自动解析JSON结构，将可以重用的节点转成列式存储，并进行压缩，从而提升查询效率，实现JSON访问接近原生列存的效率。

　　实时物化视图是为了加强Hologres的实时加工能力，用户可以基于一张base表，指定物化视图的逻辑，类似上图对于点击流PV、UV的统计，用户查询物化视图可以看到最新的PV和UV的数据统计；目前已经支持单表的实时聚合、源表的INSERT操作，后续持续支持源数据的更新和删除操作。

　　企业级安全能力由数据加密、访问控制和容灾备份三部分组成，数据加密是实现脱敏、加密、解密等功能，访问控制是通过IP白名单等控制，而容灾是同城跨机房及异地跨Region等的灾备，支持历史版本的定期备份与恢复。

　　实时数仓的架构会分为三种做法来说明，第一种做法是解决即席查询的问题，满足查询灵活性要求非常高的场景。

　　这种系统左侧部分称为实时缓存平台，右侧是数仓的部分，业务库或埋点库的源数据通过Kafka或其他消息中间件写到数仓，这个时候写数仓分为两部分，一个是明细表 ODS 部分，一个是维度表的部分。维度表的部分基本是通过离线数仓，例如加工好用户的标签信息。而明细数据就是业务库的实时映射部分。业务库正常改查明，明细数据也应正常改查。这时在数仓中可以采用更轻量级的方式比如说通过视图的方式对你的原始数据进行汇聚和封装，最终业务层看到的数据不管是宽表、汇总表还是主题表，都是业务层有语义含义的一张表，分析的灵活性非常高，因此每次查询的时候，其实数据库里查询的都是底层 ODS 中的数据，所以数据的实时性非常好。但是这个方式的缺点是效率不会很好，原始数据一般都很大，百亿千亿级别的数据汇总起来查询效率才足够高，但是目前每次查询都是上亿表来进行关联，效率不可能高。

　　因此，这种方案适合老板经常随机并需要实时看一些指标，或者不明确统计指标，先简单包装业务等需要时再计算的开发场景。

　　第二种做法是推荐更多团队使用的方式，在数据进入数仓之前通过Flink来做数据清洗和轻度加工，然后数仓通过汇聚层之后的加工，把明细数仓加工到汇总层和应用来，把大数据变成小数据，支撑在线的更高 QPS 的应用。

　　这种方式和第一种的区别是通过依赖调度系统来将物化视图表达的逻辑转换为表，即CDM/ADS层的数据为实际物理表，统一由调度框架来进行调度，数据实时性依赖调度框架周期配置，根据业务的灵活度可以实现分钟级回刷小时或天的数据，这样的话数据修正的成本就很低，都可以通过回刷的逻辑来实现业务上的更新，将计算的复杂度压缩到数仓层。

　　第三种做法是在Flink里边既做明细层加工，也做汇总层加工，从轻度汇总变成一个高度汇总加工，来满足类似实时风控、大屏这种对数据的准确度、灵活度要求并不高，但是端到端延迟非常敏感的场景。因为Flink是计算前置的，因此如果没提前写好计算逻辑，那类似订单排序这样的场景，只实现了一种排序方式，当想看到不同维度的排序数据时不能立刻实现，因此灵活性并不高，但是如果是提前定义好的指标，就会采用这种增量计算的方式。

　　整个数据都在Flink里面做计算，计算之后写一张结果表存到数仓里边，数据分层对应Kafka不同的topic，并通过分层数据的落盘，这里同步到下游Kafka的数据也同时保存一份到数仓中，方便后面数据的检查和修正。这样的话整体逻辑简单，并且保证了数据质量。

　　上面是CCO 这个架构的演变历史，其实跟很多公司国际发展历史差不多。最早的时候公司也是老板提出要求，说我分析要越来越实时化，在线API的数据可不可以实时化等？这个时候是一个典型的端到端开发的状态。一个业务场景不同的开发会通过使用的实现方式，有的写成流式计算，有的写成脚本微批次调度，业务上线非常快，结果是不同的报表间可能就差了一个字段，但是中间过程无法复用，典型的烟囱式开发，没办法做数据资产的积累。

　　慢慢地，绝大部分公司开始进入到第二个阶段，提出了数仓的概念，通过数仓的分层来实现公共部分的沉淀及资产的复用，同时为了支撑在线的应用，会使用Hbase或Redis来实现缓存或在线点查的场景，同时根据不同的使用场景来将数据写到不同的存储系统。

　　第三个阶段可能是代表未来的方向，也在阿里内部进行了大量的实践，你会看到事件分离线加工的部分和在线加工的部分，离线和在线部分都会把结果写到一个地方去，然后通过一个Hologres统一对外提供服务，简化了运维的效率，并保障了开发效率。

　　如上图右下角所示，展示了第二阶段的一个痛点，不同分层间通过Kafka来驱动，明细数据存储到Hbase中，同时还有各种的数据同步，会导致有大量的同步作业来解决数据不一致的问题，没法做很好的资产沉淀。

　　而Hologres通过简化存储层，实时数据都可以通过行存的方式写入，同时也支持很高的吞吐能力，又支持很强的点查能力，还能通过binlog将数据分发到不同的业务BU，这样的话其实做到了数据资产的沉淀，也做了很好的批流统一，从开发效率上讲还是有很高的提升。

　　第一个是多流合并的一个场景，多流合并是一个状态空间非常复杂的事情，因为不能确定哪个流先到，因此利用Hologres更新强的能力，就可以将两个流做为两个独立的作业同时写到同一个表中，这意味着落库即连接，不管哪个流的数据先到都会做一次更新操作，而Hologres的binlog还继续驱动下一层的加工，因此整个状态的存储空间做了一个极大的简化，让问题排查也变得很简单，可以通过排除一行数据对应列是否为空来确定对应的流数据是否正常到达。

　　上面是高可用能力的一个升级，从业务库里边写进一张高吞吐的行存表，支持每秒百万级的吞吐能力，然后通过 Binlog 拆分到不同业务实例，业务实例根据支撑不同的在线业务场景来进行资源的动态调配。同时阿里内部还做了灾备的能力，通过Hologres内部binlog的同步来实现多机房数据的备份，提高可靠性。

　　A1：支持update，单行单列都可以更新，Hologres的update功能在业界应该属于头部序列，行存的update效率要高于列存，列存的整行更新的效率高于局部的更新效率。

　　Q2：行列共存的模式本质上是数据会存两份吗？怎么识别什么数据需要行列共存？是用户自己指定还是系统自动识别？

　　A2：系统自动识别一个查询是使用行存还是列存。行列共存实现是底层存储中本来列存的是对应列的数据，但是我们把整行数据压缩成一个单一列，存在了列存中，原则上是存了两份。所以这个时候查询引擎会去根据具体的查询来判断，结合算子的cost来判断是走行存还是列存。

　　A3：我的直观感受是Flink的状态空间太大，比如4个流一起去连接的时候，无法确定对应流的时序性，因此需要在Flink中维护一个非常大的状态空间。同时为了确认数据结果是否正确，会保存4条流的明细数据，这样才能有很好的排错能力。

　　刘一鸣，花名合一，阿里云智能高级产品专家，主要负责云原生一体化数仓引擎能力的演进和商业化，支持MaxCompute和Hologres两款核心自研引擎。在大数据、数据仓库、开源软件行业有10年以上工作经验。

　　DataFun：专注于大数据、人工智能技术应用的分享与交流。发起于2017年，在北京、上海、深圳、杭州等城市举办超过100+线+线上沙龙、论坛及峰会，已邀请超过2000位专家和学者参与分享。其公众号 DataFunTalk 累计生产原创文章800+，百万+阅读，15万+精准粉丝。