携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第21天，点击查看活动详情
对于以上两种方案各有什么优劣势呢？
大宽表，空间换时间。理论上都是维表主键为唯一ID来填充所有维度，这样只是冗余存储了多条维度数据，但是在OLAP引擎里，不管是DRUID、KYLIN还是DORIS都不会造成数据量的基数膨胀。
优势：应用层查询的时候非常方便，无需关联额外的维表，直接面向大而全的宽表查询。
劣势：对应的弊端就是如果有维度数据update场景，支持的代价非常大。如果update非常频繁，这种方式就不可行了。
星型模型关联查询。
优势：维度数据与事实数据完全分离，维度数据用专门的引擎存储(如mysql、elasticsearch等等)，可以支持高频update操作，查询时通过主键关联查询维度数据。
劣势：查询层逻辑相对复杂，且多表join会导致性能受损。
架构实现
数据生产
事实数据
如上图，数据写入部分：实时数据通过Flink处理，再写入Kafka。最后通过Kafka Index Service摄入到Druid。
事实数据一般量级是非常大的，在我们的场景下，实时数据量比较大，为了减少下游KIS的压力，我们在Flink层加了一层窗口聚合。并且对最终写入kafka的数据进行了KeyBy处理，将相同维度相同取值的数据都发送到同一个topic partion。
做KeyBy操作的核心目的是为了适配Druid引擎的特性。如果以随机的方式发往kafka topic的各个partion，会导致每个partion都可能涵盖所有取值的数据。进而导致每个KIS task包含了所有取值的数据(我们生成环境KIS task数目与topic的partion数是一一对应的)，造成KIS task的segment文件大幅膨胀（两种区别的理论值为key By处理生成的segment大小为不做key by的 1/partion总数），影响实时数据的查询性能(这里如果没太看明白可以参考阅读Druid官方文档，了解Druid数据聚合、索引构建原理)。
注意：Key By操作可能会导致引发数据热点，可以通过热点数据动态加盐解决。
