心得这个东西不记下来真的很快就没了，也许琢磨的五点过个十天半个月就只剩下两条了，记记也是算是尊重自己的思考吧。
1. 索引还是扫描
Druid文档中宣称自己是大量参考了Dremel和Powerdrill的架构，但是其中最重要的一条“扫描而不是索引”这一点在druid的设计中又是怎么体现的呢？Powerdrill的论文中详细介绍了全局和局部的字典编码，然后维度上提到更多的是partition而不是index，在这一点上我一直不太明白，什么情况下用扫描而不是索引，感觉在druid的设计上并没有贯彻下去。
2. Kafka Indexing Service
听完之后让我对使用Kafka Indexing Service表示怀疑了，解决了一个问题，但是同时也带来了一些严重问题：
- Segment碎片化：比如一天的日志花了14天才完全到达，这个时候就会生成数百个shard的小文件，这可并不是什么好事，对效率也不太友好；
- 与原有Lambda架构相冲突：在使用了Kafka Indexing Service基础上进行T+1修正就比较尴尬了，一是由于数据时间到达时间不定，生成追加shard的时间也不定，需要反复进行Segment合并来达到较优的效果；二是做修正的数据未必与实时数据一致，追加Segment的合理性存疑。
- 对Kafka的版本有要求，而我米没有动力将Kafka升到0.9以上，这个就是硬伤了。
3. 留存计算
Druid利用Data Sketch能够进行近似留存计算，但是效率比较低，耗时也比较长。一般来说一个30天的留存倒三角需要30 * 29 / 2 = 435次sketch intersection操作，如果还涉及到时间粒度从小到大的sketch union操作，这个代价可不小。分享的同学中有一位是大量采用了MySQL做Cache，感觉也行，在提供基于druid的一整套方案的时候，这个也是必不可少的。
4. 通用统计框架
在内部的数据工场中，大量的Hive任务都是在做group by a, group by a, b, group by a, b, c，如果能够把这部分任务给省掉了，想必也是功德无量——让专业的人做专业的事，让那些做着低级数据统计的人从中解脱出来。我们能够有可能做到的最大的优势就是数据工场——各种表定义、字段定义、字段的类型这样通通都是知道的。这样一个统计平台可能是这样的：
- 需要用户对数据进行一些ETL来保证数据是“平”的，JsonPath能够解决的抽取问题不需要做ETL；
- 用户能够定义维度和指标；
- 指标之前能够进行运算，比如平均浏览时长；
- 提供非精准的UV计数，精准UV计数仍然可以提供：需要用Hive对数据进行聚合的预处理，借助Sketch Hive UDF可以同时生成Sketch和Distinct Count，但是Distinct Count不再具有可聚合性，可用的查询粒度将会被固定下来（一般来说是天）；
- 基于4可以提供留存、回访类信息，比如：昨天注册的用户今天购买过XX的用户有多少；
- 查询条件、留存的条件多种多样，千变万化，需要有良好的查询条件设计。
5. Benchmark
Druid官方提供了Benchmark的方式和参考数值，有必要在集群完成搭建后进行相应的测试，这样能够对集群性能有一个较好的评估，也便于及时发现问题。
6. 回馈社区
有一些改动最好还是跟社区交流一下，交流交流才能知道解决方案是不是太LOW。等社区打上patch固然是很慢，但是可以自己在确认patch没有问题的情况下可以先打到自己的版本上，等社区版本发布之后再切过去不迟。个人的力量太渺小，适当沟通事半功倍，维护性也更强。
7. SSD
从头条的实践来看，SSD还是比较有效的，毕竟没法指望数据能够完全加载到内存中。之前一直忽略了这一部分，看来这部分需要在做完benchmark的基础上进行改进。
