Flink+Hologres升级版实时数仓架构是如何解决Lindorm/Druid架构存在的问题呢？

• 资源消耗大：Flink+Lindorm方案最大的局限性在于，所有维度的计算都通过Flink完成， Flink是纯内存有状态的流式计算，每到一条消息都需要对内存状态进行读取更新。维度组 合复杂、聚合周期跨度较大时，内存往往会成为瓶颈，使得无法应对细粒度的分析需求。 在流量通道场景场景中，查询均为人工触发，所以QPS相对较低，同时运营查询维度相对 固定，实时CUBE存在大量的计算浪费，预期利用Hologres 强大的交互式查询能力，可以 大大降低计算资源的消耗。

• 灵活性不足：上述提及的两种方案，由于物理存储的是指标数据，都存在灵活性不足的缺 点。当需新增不同维度的指标时，这两种方案都需要重新创建任务计算新指标，而新指标 历史数据的回刷成本极高。基于Hologres的方案可以直接存储明细数据，具备满足各种查 询维度的能力。• 表关联能力弱：流量通道分析遵循漏斗分析模型，从用户浏览->收藏加购->下单支付各阶 段看流量转化的表现，所以存在大量大表关联操作。借助Hologres的特性，对主要分析链 路的明细数据表进行精心设计，以满足流量分析场景中的大表关联需求。从整个分析链路 来看，最终可以细化到每个设备在网站的行为表现，所以我们选取了设备id 作为表的分布 键，充分利用 Hologres 的 Local Join 能力，使得大表的关联操作得以在秒级以内完成返 回。

• 运维成本高：大促往往具有数据量成倍增长的特点，因此需要在大促前进行资源预估以及 扩容，而当大促结束后，为了不让资源浪费，会进行相应的缩容操作。对比 Flink+Lindorm方案，由于计算负载都在Flink任务中，所以扩缩容主要集中在Flink任务 上。而对Flink任务进行扩缩容的成本非常高，需要对每个任务独立执行停止-扩容/缩容-启 动操作。Hologres的计算节点是云原生的，具有良好的弹性伸缩能力，因此，本方案在运 维成本上基本可以忽略不计，大大降低了开发人员的工作量。 以上内容摘自《阿里云实时数仓Hologres最佳实践合集》电子书，点击https://developer.aliyun.com/topic/download?id=996 可下载完整版