gydtep
发表于 2020-10-1 11:34:57
在Hive 3.x中支持的Materialized View，利用了Apache Calcite对执行计划进行重写。
gydtep
发表于 2020-10-1 13:52:16
Spark会把用户查询语句进行解析，依次转化为Unresolved Logical Plan（未绑定的逻辑计划）、Resolved Logical Plan（绑定的逻辑计划）、Optimized Logical Plan（优化的逻辑计划）、Physical Plan（物理计划）。
gydtep
发表于 2020-10-1 15:06:33
其中，未优化的逻辑计划根据用户查询语句不同，会有较大区别，而Relational Cache作为优化的一部分，放在逻辑计划优化过程中也较为合适，因此我们拿到的用户查询计划会是优化中的逻辑计划。
gydtep
发表于 2020-10-1 17:34:25
包括对于Cache数据进行进一步的Filter、Project、Sort甚至Aggregate等操作，使其与匹配节点完全等价，然后更新逻辑计划节点的引用绑定，无缝替换到逻辑计划中，这样就能轻松获得最终的重写后的计划。
gydtep
发表于 2020-10-2 15:00:17
主要是验证目标聚合所需的属性或者聚合函数都能从某个Grouping ID对应的聚合结果中计算出来，比如粗粒度的Sum可以对细粒度的Sum进行二次Sum求和，
gydtep
发表于 2020-10-2 16:06:25
这里面需要根据聚合的语意判断是否能够二次聚合。如果时Grouping Set的聚合，二次聚合之前还需选择正确的Grouping ID进行过滤。经过二次聚合后，步骤大体和普通的重写一致，只需替换到目标计划中即可。
gydtep
发表于 2020-10-3 15:23:30
如果，你的应用有全文检索需求，建议你优先迁移到 Elasticsearch 平台上来，其提供丰富的 Full text queries 会让你惊讶，一次用爽，一直用爽。
gydtep
发表于 2020-10-3 15:44:11
Elasticsearch 最擅长的就是查询，基于倒排索引核心算法，查询性能强于 B-Tree 类型所有数据产品，尤其是关系型数据库方面。当数据量超过千万或者上亿时，数据检索的效率非常明显。
gydtep
发表于 2020-10-3 17:58:57
这里会面临几个问题，一个问题是大批量明细数据的输出，如何能在极短的时间内写到数据库，传统上很多数据平台选择关系型数据库提供查询，比如 MySQL，之前在这方面吃过不少亏
gydtep
发表于 2020-10-3 18:00:18
瞬间写入性能极差，根本无法满足要求。另一个问题是对外查询，如何能像应用系统一样提供性能极好的查询，不限制查询条件，
