Java、大数据开发学习要点（持续更新中…）

答：用户数量大(每个用户对应一行)，每个用户的标签众多，这样的大数据量适合用Hbase这样的分布式数据库存储，并且Hbase是列式存储，标签扩展方便。并且本系统中是按照用户id查询Hbase对应rowkey来查找具体列的等值查询，可通过布隆过滤器进行优化，并且HFile有序存储的特征可以根据索引进行列信息的快速等值查找。而MySQL，首先超过百万行的查询性能就会急剧下降；其次标签扩展不方便，增加一个标签所有行数据都要更改(行式存储的劣势)；最后，查询需要进行索引的建立、优化、维护等工作不如HBase来的直接了当。

²用户行为明细为什么用ClickHouse？为什么存用户行为明细？用CK有什么缺点，怎么解决？

答：首先，用户行为明细的查询数据库要符合以下条件，响应速度快、支持复杂数据查询、并发查询能力强(这点CK不擅长)，综合来看CK比较符合。其次，为存储用户行为明细是因为规则是动态的无法事先确定会有怎么样的规则发布，那么当新的规则出现时，行为查询的粒度将会发生不可预知的改变，这种场景就需要OLAP的即席查询来支持临时聚合和复杂分析。最后，CK的缺点在于并发能力不高，在Flink高并行度的数据处理场景下会导致CK性能骤降，解决方案为实际行为明细查询存在冗余查询，可以使用本地查询缓存机制来减少冗余查询，从而减少对CK查询的请求数。

ps:其实也可以用Hbase一站式解决，rowkey设计为用户id，日志中其他信息k-v形式存储在列族中。查询时根据rowkey查询，与需要查询的行为事件返回数据，再写逻辑进行统计次数或者次序统计。或者直接整合Phenix。但是：
1.Hbase还是定位为海量数据存储，在数据分析的上即使整合Phenix复杂查询的时间也是秒级的，并且对于复杂的计算SQL更加容易表达。
2. 从Hbase中查询根据rowkey和指定列查询很方便，但是查询后的需要将符合的数据都加载到内存中计算，进行复杂计算逻辑的编写，后期系统拓展需要给每个规则编写对应逻辑，没有SQL维护方便(并且系统将SQL生成与引擎截耦合更加利于后期系统规则扩展和维护)。

• 事实：被判断的主体和属性，如账号某项行为发生次数。
• 条件：判断的逻辑，某事实中的某属性。
• 阈值：判断的依据，某条件下属性的临界阈值。
• 时间要素：规则可由运营专家凭经验填写，也可由数据分析师根据历史数据发掘，但因为规则与现实需求的契合会随时间而变，所以无一例外都需要动态调整。
• 其他：为了方便开发的一些记录，比如规则拆分后的时间要素，规则原始的时间要素、CK的查询SQL语句、中间计算缓存等信息。

3.1规则封装

  原子规则可以被封装成包含触发事件、事件属性、阈值和事件要素的类来描述：