当前，越来越多的企业从实时数据分析中获得了更多的收益。根据 IDC 的报告，某头部股份制银行实时风控平台业务量、数据量和处理量庞大，业务渠道多达 20 余条。各个渠道对于数据处理的实时性要求和数据复杂度指标要求极高,比如指标计算单点 TPS 要求达 1 万以上，数据计算的集群吞吐量要求达 100 万笔/秒以上，平均时延要求在 100 毫秒以内。
基于以上数据处理需求，该行建立起一套统一高效的智能化交易风险管理架构，提升了集团网络金融业务的安全性。截至 2018 年 9 月，该行智能风控平台监控的网络金融交易业务总笔数达到 11.5 亿笔，累计阻断各类高风险交易达到 36.8 万笔，为客户规避了 2.4 亿元的损失。
越来越多的大数据计算场景正在从规模化走向实时化。比如在各类直播大屏场景、城市大脑的交通检测场景、银行风控场景中，都逐步从过去的T+1 分析走向实时分析。
上图展示了常见的实时数仓应用场景，包括传统的 BI 报表、实时大屏等。此类场景从过去基于离线数仓的 T+1 分析升级到实时的数据分析，供业务进行实时决策。同时，实时数仓还能用于人群运营，比如完成用户画像分析、人群圈选等场景。在推荐类场景下，还可以做智能化、个性化的推荐，甚至延伸到智能客服的场景。比如用户的问题经由 NLP分析生成向量，在实时数仓中查询得到近似的推进结果，以支撑智能客服的场景。实时数仓还能用于实时监控的分析场景，比如做实时的订单分析、物流跟踪以及线上直播质量监控等。
阿里云根据大量用户案例总结了当前客户在实时数仓中典型的业务痛点，主要包括以下三个方面：
① 对于时效性、准确性、性价比有强烈的需求。客户对于数据实时写入的要求极高，查询延时敏感，查询维度繁多，且维度并不固定，新增维度的频率极高，需要同时兼顾明细查询和聚合查询两种不同的负载。
② 由于手机应用、小程序等场景日益增多，客户对于半结构化数据的分析需求日益强烈，大量半结构化的日志数据转化为结构化的数据，清洗链路极长。同时，半结构化数据结构经常变更，结构化之后也需要经常变更表结构，且日志数据信息有限，需要动态补充以满足个性化需求的变化。
③ 实时数仓上的业务需求和实时任务变更频繁，表结构和业务的频繁变更导致实时计算的任务需要频繁重启才能满足业务的需求。
根据以上痛点，阿里云推出了以下新功能，主要集中在数据写入、查询与分析以及企业级能力三个方面。
阿里云 Flink 与 Hologres深度集成，助力企业快速构建一站式实时数仓。
首先，可以通过阿里云 Flink 实时写入 Hologres，实现高性能写入与更新，数据写入即可见，无延迟，满足实时数仓高性能、低延迟的写入需求。其次，可以通过阿里云 Flink 全量读取、Binlog读取、CDC读取、全增量一体化等多种方式读取 Hologres 源表中的数据，无需额外主键，统一计算和存储，加速数据流转的效率。阿里云 Flink 读取Hologres维表，助力高性能维表关联、数据打宽等多种应用场景。
阿里云 Flink 与 Hologres元数据打通，通过 Hologres Catalog实现元数据自动发现，极大提升作业开发和正确性。
通过阿里云 Flink 与 Hologres的实时数仓标准解决方案，能够支撑多种数仓应用，如实时推荐、实时风控等，满足企业的实时分析需求。
随着业务的迭代和发展，数据源的表结构变更频繁，用户需要及时修改数据同步作业，以适配最新的表结构，这也带来了较高的运维成本，影响了同步管道的稳定性和数据的时效性。
阿里云 Flink 和 Hologres 支持通过 Catalog 实现元数据的自动发现和管理。配置 CREATE TABLE AS 语法，用户可以通过一行 SQL 实现数据的同步和表结构的变更自动同步。CREATE TABLE AS语法会解析成 Flink 作业，Flink 作业源头支持读取数据的变更和表结构的变更，并将变更同步到下游，且数据和表结构的变更都可保序。
比如CREATE TABLE AS语句运行时，可以根据 MySQL 中的表结构变更和数据变更自动生成相应的 SQL ，将元数据的变更以及数据的变更同步到Hologres中。整个过程无需启停任务和修改 Flink SQL 。
如上图所示，如果上游 MySQL 中的 user 表新增了一列 age 并且插入一条 ID 为27、年龄为 30 的记录，user 表上的数据和表结构都能实时同步到下游的 Hologres的user 表中，ID为12、16和 19 的历史数据，新增的列都会自动补上NULL值。
第二个场景，在实时数仓构建中，用户经常需要将整个数据库同步到数仓中做进一步分析。每张表一次写同步任务的方式不但浪费资源，也会对上游数据库产生较大压力。
针对此类用户的痛点，阿里云提供了整库同步的特性。整库同步通过 CREATE DATABASE AS 的语法配合 Catalog实现。比如上图中的 MySQL Catalog 和 Hologres Catalog 互相配合，搭配 CDS 的语法，即可完成 MySQL 到 Hologres的全增量数据同步。
CDS 的语句会解析成 Flink 任务来执行 Flink 作业，自动解析源表的表结构和相应的参数，并将指定的多个数据库同步到下游的Hologres数仓中。过程中用户无需手写任何表的 DDL，用户也无需在 Hologres中创建表，可快速实现数据的整库同步。
CDS 作业默认具有表结构变更的同步能力，所有表结构的同步变更都会按照顺序同步至下游 Hologres实时数仓中。 CDS 语法也支持过滤不同的需要同步的表，如上图，仅需两条 SQL，即可将MySQL 的order_db 中的所有表同步到 Hologres 。
分库分表是高并发业务系统中采用的经典数据库设计，也是实际业务中常见的一种架构。通常需要将分库分表的业务数据汇总到一张数仓中的大表，方便后续数据分析，即分库分表合并同步的场景。
针对以上这种场景，阿里云提供了分库分表同步的功能。通过在CTS语法中支持源库和源库的正则表达式，源库的分表可以高效合并同步到下游 Hologres 数仓中。如上图所示， SQL 中的源库名 order_db.*是一个正则表达式，可以匹配当前 MySQL 实例下的 order_db01、order_db02、order_db03 三个库。
针对分库分表的场景，用户只需提供分库分表的正则表达式，即可将分库分表合并同步到下游的 Hologres数仓中的 order 表中。与其 CDS 语句一样，分库分表默认提供表结构变更自动同步的特性，下游 Hologres表的 schema 为所有分表合并后的最宽 schema 分库。
分表同步时，每一行记录所属的库名和表名会作为两个额外的字段同步到 user 表中。库名、表名和原主键会一起作为下游 Hologres user 表中的联合主键，保证Hologres user 表上的逐渐唯一性。
数据写入的实时性是实时数仓的重要能力之一。对于 BI 等延迟不敏感的业务场景，写入延迟几秒甚至几分钟都是可接受的。但对于很多生产系统，比如实时风控、实时大屏等场景，要求数据写入即可见，如果写入出现延迟，会严重影响线上的业务决策。
在实时数仓处理链路中，Hologres 作为一站式实时数仓，提供海量数据高性能的实时写入，数据写入即可查，无延迟。
数仓场景数据来源复杂，涉及到多种数据源的更新、修正场景。 Hologres可以通过主键提供高性能的 upsert能力,写入和更新过程保证exactly-once 语义，满足对数据的合并更新等需求。通过独特的FixedPlan 优化技术，在整个写入场景中有别于传统数据库，写入过程无需经过优化器、协调器、查询引擎、存储引擎等多个主键，数据直接写入，极大提升了写入和更新的吞吐量。
上图右下柱状图为 Hologres 128 CU实例下10个并发写入 20 列的列存表测试结果。其中数轴表示每次写入的记录数，横轴表示4个不同的写入场景，分别为：
l Append Only：写入表无主键，写入能力230万+的RPS。
l INSERT：写入表有主键，如果主键冲突就丢弃新行，写入能力200万RPS
l UPDATE-1： 写入表有主键，表中原始数据量为2亿，按照主键Upsert，写入能力80万的RPS。
l UPDATE-2：写入表有主键，表中数据量为20亿，按照主键做Upsert，写入能力70万的RPS。
按照主键做 upsert，写入能力为 70 万 RPS，可以发现，随着数据量增加， RPS 没有明显降低，写入的吞吐量都处于极高水平。
Hologres具备基于共享存储的多实例、高可用部署模式。在该方案中，用户可以创建多个实例，实例代表了不同的计算资源，但所有实例共享一份存储。其中一个实例作为主实例，支持数据的读写操作，其他实例作为只读从实例，不同实例之间的数据内存储状态为毫秒级实时同步，物理上数据存储只有一份。
在该方案中，数据统一，权限配置统一。但是计算负载通过物理资源的分隔实现了百分百的计算资源隔离，读写请求不会争抢资源，也体现了更好的故障隔离能力。主实例目前最多支持挂载四个子实例。如果是同一个 region 部署，则共享存储；如果是不同的 region 部署，则数据需要复制多份存储。
该方案在大促场景下被多个核心业务反复验证，可靠性极高。通常建议一个个主实例负责数据写入和加工，一个子实例负责内部 OLAP 经营分析，另外一个子实例用于对外的数据服务，可以根据不同的场景、不同的算力需求分配不同的计算资源规格。
Binlog是 Hologres的特色新功能，它让 Hologres不再是数据的终点，也可以起点。 Hologres Binlog 类似传统数据库的 Binlog ，支持对每次数据更新的详细记录，包括 insert、delete、before update、after update 四种事件类型。
通过 Binlog 可以驱动事件的实时加工，有多种使用场景，包括数仓内分层的实时加工，通过 binlog 实现数据在各个层次之间的连续加工，比如从 ODS 到 DWD 到 DWS最终到 ADS 层；支持数据在实例之间实时同步，比如公共层实例到业务层实例进行实时的加工和同步，从Shared Instance到Application Instance；同时也可以用于数据的行列转换，目前有了新的行列共存结构，该场景的需求略有减少；还可以用于监控数据的变化，通过 Flink 和 Hologres binglog 的组合关系，支持了有状态的全链路实时事件驱动的开发场景。
JSON是 Hologres近期重点发力领域，因为数据采集越来越灵活，数据加工也越来越敏捷。过去需要打宽的JSON数据往往保留了原始的不规范结构，如何处理这种 schemaless的场景尤为重要。
传统 JSON作为数据格式，提供了存储的灵活性，但是限制了分析的效率。为了访问 JSON中部分节点，往往不得不读取 JSON整个数据结构，效率非常低下，存储也难以压缩。 Hologres 创新了 JSON数据的存储方式，采用类似列存的存储格式，将JSON中不同的路径映射为虚拟的列，提供原生的列存压缩索引能力。
在查询层自动下推 JSON访问算子，极大加速了 JSON数据过滤统计的效率。在协议层完全兼容了PostgreSQL的规范，支持了 JSON、JSONB 等数据类型，支持 PostgreSQL 原生的各种改造访问。可以认为 JSON是 Hologres推荐的数据类型，适用于日志分析的场景。
JSON列式存储指使用列式存储 JSON 的数据，由于列存的压缩效率更高，可以有效提高数据的存储效率，节省存储空间。
常见场景比如某视频网站的厂商希望查询男性用户的数量和平均年龄，数据按照上图左边的 JSON 类型去进行存储，以此对应的 SQL 如图所示。此时需要查询结果时，需要扫描并读取所有 JSON 数据，再做汇总，才能得到最终的结果。但是如果使用了列式存储，则整个数据存储结构如上图所示。按照列讲 Key value 的数值展开，然后使用列存的方式进行存储压缩。此时如果需要查询男性用户的用户数量和平均年龄，则只需要扫描两列数据，可以明显的提升查询效率。
新版本支持了实时物化视图。物化视图是一个通用的概念，一般数据库需要定期刷新物化视图，存在一定的数据滞后性。而 Hologres的物化视图无需手动刷新，数据在写入时即进行预计算，记录物化视图。
简单的业务场景，比如某客户有 100 多家门店，需要实时查看各家门店的营收情况，以便实时调整经营策略。用户明细如上，其中存储了订单的明细数据，有订单号、客户号、门店 ID、订单日期、订单金额等。创建物化视图后，在数据写入明细表后，Hologres会进行实时物化。用户写 SQL 时，系统可自动改写 SQL 直接查询物化视图，以提升整体的查询性能。
除了以上能力以外，我们还提供了更多企业级安全能力，比如数据加密和脱敏。不仅包括 Hologres 自身的数据落盘加密能力，还可直接加速 max compute 中的加密数据。同时也提供了数据脱敏能力，并完成了与数据保护伞的对接。设置脱敏规则上，可以使用数据保护伞一体化的设置Hologres 和 max compute 的脱敏规则。其次，在访问控制上提供了 IP 白名单、定向 VPC 访问和行为审计的能力。容灾备份上，提供了同城容灾、异地容灾以及多版本备份恢复控制的能力。
以某知名全球 top 20 的游戏公司业务为例，通过阿里云 Flink+Hologres实时数仓方案，替换开源的 Flink+Presto+HBase+ClickHouse 架构，极大简化了数据处理链路，统一了数据数仓架构，统一存储查询性能得到 100% 甚至更多的提升，完美支撑了数据分析业务、广告投放、实时决策等多个场景，助力业务快速增长。
客户原有数仓全套使用开源架构，架构图如上图所示。其中开源 Flink 做 ETL 处理，处理后写入 Clickhouse、StarRocks 等多种OLAP引擎中。该架构主要存在痛点如下几个痛点：
第一，ETL链路复杂。为了解决数据实时ETL ，客户通过 Flink CDC +Hudi做流批一体。但由于上游业务数据经常变更表结构，且开源的 Flink 无 schema evolution ，每次表结构变更都需要重新启动任务，操作繁索，浪费大量的开发时间。同时，Hudi的查询性能无法满足业务需求，还需使用 Presto做查询加速，造成链路冗余。
第二，OLAP架构冗余，查询慢，用户主要依靠买量发行作为游戏推广的重要手段。为了解决广告归因的实时决策场景对于查询加速的需求，部署了开源的 Presto+Clickhouse+HBase 等多套集群，搭建混合的OLAP平台，带来许多问题：
(1) 平台需要维护多套集群，导致运维变得非常复杂。
(2) 开发需要在各种 SQL 中切换，比如 ClickHouse SQL 、PrestoSQL以及Phoenix SQL等，为开发团队带来了诸多困扰和更高的学习门槛、使用成本。
(3) 由于 ClickHouse 缺乏主键，在归因分析中使用 Last Click 模型带来了大量额外工作。
(4) OLAP引擎的查询性能无法很好地满足业务需求，无法根据数据进行实时决策。
(5) 数据需要在多个 OLAP 系统中存储，造成存储冗余，导致成本压力剧增。
基于以上痛点，客户决定重新进行技术选型，使用阿里云的 Flink+ Hologres来替换现有的开源架构。通过阿里云 Flink+Hologres替换后的数据链路如下：
数据通过 Flink CDC 写入 Kafka 做前置清洗，清洗后通过 Flink 进行 ETL 操作，Flink ETL 后的数据实时写入 Hologres，通过 Hologres替换了Kafka作为数仓的中间数据层，统一了流批存储。在 Hologres中，根据 ODS、DWD、DWS 层汇总加工。在 ODS 层，Flink订阅 Hologres Binlog，计算写入 Hologres 的 DWD 层， 由DWD层的 Hologres进行汇总成为 DWS层，最后由DWS 对接上层的报表和数据服务等业务。
为了存储统一，将原有的离线 Hive 数据替换为阿里云的 max compute，以 max compute 作为离线的主要链路。得益于Hologres和 max compute 高效的互通互访能力，Hologres 通过外表离线加速查询 max computer 数据，并将历史数据定期归档到 max compute 中。
架构升级后，客户业务得到了显著收益。依托阿里云 Flink+Hologres数据可以实时写入 Hologres，写入即可见，并且 Hologres 有主键，能够支撑高性能的写入更新能力，提供了百万级更新和毫秒级延迟。阿里云 Flink 提供 schema evolution 的能力，能够自动感知上游表结构变更并同步到Hologres 中。改造后的实时 ETL 链路通过 Binlog 日志完成，降低了整个链路的维护成本。
Hologres相比开源的 ClickHouse 能够达到秒级延迟，性能提高100%甚至更多， join 的查询性能相比原有的链路有 10 倍以上提升。通过 Hologres提供了统一的数据查询出口，升级后数仓架构变得更加灵活、简洁、统一。存储只需要一套系统即可以满足业务的需求，降低了运维压力和维护成本。好的，谢谢各位，今天分享到此为止。
