weixin_44166276的博客

在我们的业务场景中，商品维度是千万级别，用户维度是亿级别，经过测试，在实时点击流中，由于数据流量比较大，关联用户信息会出现查询超时导致关联不上的场景，因为我们砍掉了实时数据的用户维度，而选择在ClickHouse进行结果数据查询时再利用Local Join的优势来关联用户维度。在我接手之前，公司数仓按照不同的业务模块划分不同的数据集市，电商业务有专门的电商集市，但是内部数据加工逻辑比较复杂、没有明确的数据分层和清晰的数据处理逻辑，基本上是面向需求开发，重复逻辑比较多，数据一致性差。

这是一本从基本操作、架构设计、进阶使用、运维管理、拓展应用、项目实战等多个维度全面讲解Doris的著作，是资深数据仓库专家兼Doris开源项目贡献者实战经验的总结，得到了Apache Doris PMC主席、Select DB创始人兼CEO以及多位Apache Doris PMC的强烈推荐。基础篇（第1-4章）：首先介绍了Doris的功能特点、架构设计、应用场景，然后讲解了Doris的编译、安装、部署、建表等基本操作，以及Doris的数据对象和数据模型。--张家峰 Apache Doris PMC。

因此，建议在默认情况下将optimizer参数设置为on，但如果出现代价估算器的估算结果与实际情况不符的情况，可以考虑将其设置为off，或者使用其他的查询优化技术，如手动设置查询执行计划等。此外，Greenplum中的内存管理也比较复杂，有时候内存不足的错误可能是由于一些其他的原因导致的。Greenplum是一个基于共享存储的分布式数据库系统，其查询优化器采用的是基于代价的优化器（Cost-Based Optimizer），它会根据查询代价估算的结果来选择最优的查询执行计划。

但是字段只是表的一个部分，而数据仓库的表不一定都有业务主键，并且数据仓库的数据流动是逐层聚合的，越往上的逻辑越抽象，越抽象越难以溯源。作为管理者，看到了表级血缘，肯定是不满意的，一个简单的逻辑包含了十几张表，根本看不出来里面的逻辑来，能不能打开黑箱，进一步透视一下？但是领导是不会接受的，我当领导就是为了不看代码的，为了让开发过程可视化的，只有可视化的东西才能满足管理要求。表级数据血缘可以大概知道，一个目标表的数据会受到哪些上游表的影响，这个影响有可能是直接的，有可能是间接的，也有可能毫无影响。

以零售业务为例，假设有订单信息表A、订单商品表B，我们在ODS层可以分别取到两个表的增量数据，如果要得到DWD层的增量，需要用同时读取订单信息表和订单商品表中变动的订单并进行关联，可以是A表的增量数据关联B表的增量union all历史全量 + B表的增量数据关联A表的增量union all历史全量，这样可以计算出DWD层的增量。但是，这些其实都是低价值密度的数据，真没有太多分析的必要性。但是，真是的情况是，数据湖也只能做到ODS层的增量或者最多DWD层的增量，有更复杂逻辑的情况下，数据湖也是无能为力的。

据公开资料显示，Apache Doris在美团、小米、京东、百度、网易、字节跳动、快手、腾讯、华为、新浪、知乎、360等大型互联网企业有深入的应用和稳定的生产运行，全球范围内的企业用户规模已超过1000家。同时，飞轮数据科技（SelectDB）提供了基于开源Doris的云原生实时数据仓库SelectDB Cloud，百度智能云、腾讯云、阿里云、火山引擎等知名云厂商也提供了基于开源Doris的云上托管服务。本从基本操作、架构设计、进阶使用、运维管理、拓展应用、项目实战等多个维度全面讲解Doris的著作，

一个查询在MPP集群中执行时，会拆成一个树状的执行树，这棵树的执行由Coordinator来协调执行，树的叶子节点也叫计划片断（PlanFragment），每一个PlanFragment分配给一个BE节点的查询执行器来执行，这就是查询执行器模块的作用。而Partition级别的缓存会智能地将SQL结果中不同分区的结果数据缓存起来，之后的查询，可以利用已缓存分区的数据加上新分区实时查询的数据得到最终的结果，从而降低重复数据的实时查询需求，减少对系统资源的消耗。如果只部署一个FE，则FE默认就是Leader。

特步，飞一般的感觉