心得這個東西不記下來真的很快就沒了，也許琢磨的五點過個十天半個月就只剩下兩條了，記記也是算是尊重自己的思考吧。
1. 索引還是掃描
Druid文檔中宣稱自己是大量參考了Dremel和Powerdrill的架構(gòu)，但是其中最重要的一條“掃描而不是索引”這一點在druid的設(shè)計中又是怎么體現(xiàn)的呢？Powerdrill的論文中詳細(xì)介紹了全局和局部的字典編碼，然后維度上提到更多的是partition而不是index，在這一點上我一直不太明白，什么情況下用掃描而不是索引，感覺在druid的設(shè)計上并沒有貫徹下去。
2. Kafka Indexing Service
聽完之后讓我對使用Kafka Indexing Service表示懷疑了，解決了一個問題，但是同時也帶來了一些嚴(yán)重問題：
- Segment碎片化：比如一天的日志花了14天才完全到達(dá)，這個時候就會生成數(shù)百個shard的小文件，這可并不是什么好事，對效率也不太友好；
- 與原有Lambda架構(gòu)相沖突：在使用了Kafka Indexing Service基礎(chǔ)上進(jìn)行T+1修正就比較尷尬了，一是由于數(shù)據(jù)時間到達(dá)時間不定，生成追加shard的時間也不定，需要反復(fù)進(jìn)行Segment合并來達(dá)到較優(yōu)的效果；二是做修正的數(shù)據(jù)未必與實時數(shù)據(jù)一致，追加Segment的合理性存疑。
- 對Kafka的版本有要求，而我米沒有動力將Kafka升到0.9以上，這個就是硬傷了。
3. 留存計算
Druid利用Data Sketch能夠進(jìn)行近似留存計算，但是效率比較低，耗時也比較長。一般來說一個30天的留存倒三角需要30 * 29 / 2 = 435次sketch intersection操作，如果還涉及到時間粒度從小到大的sketch union操作，這個代價可不小。分享的同學(xué)中有一位是大量采用了MySQL做Cache，感覺也行，在提供基于druid的一整套方案的時候，這個也是必不可少的。
4. 通用統(tǒng)計框架
在內(nèi)部的數(shù)據(jù)工場中，大量的Hive任務(wù)都是在做group by a, group by a, b, group by a, b, c，如果能夠把這部分任務(wù)給省掉了，想必也是功德無量——讓專業(yè)的人做專業(yè)的事，讓那些做著低級數(shù)據(jù)統(tǒng)計的人從中解脫出來。我們能夠有可能做到的最大的優(yōu)勢就是數(shù)據(jù)工場——各種表定義、字段定義、字段的類型這樣通通都是知道的。這樣一個統(tǒng)計平臺可能是這樣的：
- 需要用戶對數(shù)據(jù)進(jìn)行一些ETL來保證數(shù)據(jù)是“平”的，JsonPath能夠解決的抽取問題不需要做ETL；
- 用戶能夠定義維度和指標(biāo)；
- 指標(biāo)之前能夠進(jìn)行運(yùn)算，比如平均瀏覽時長；
- 提供非精準(zhǔn)的UV計數(shù)，精準(zhǔn)UV計數(shù)仍然可以提供：需要用Hive對數(shù)據(jù)進(jìn)行聚合的預(yù)處理，借助Sketch Hive UDF可以同時生成Sketch和Distinct Count，但是Distinct Count不再具有可聚合性，可用的查詢粒度將會被固定下來（一般來說是天）；
- 基于4可以提供留存、回訪類信息，比如：昨天注冊的用戶今天購買過XX的用戶有多少；
- 查詢條件、留存的條件多種多樣，千變?nèi)f化，需要有良好的查詢條件設(shè)計。
5. Benchmark
Druid官方提供了Benchmark的方式和參考數(shù)值，有必要在集群完成搭建后進(jìn)行相應(yīng)的測試，這樣能夠?qū)盒阅苡幸粋€較好的評估，也便于及時發(fā)現(xiàn)問題。
6. 回饋社區(qū)
有一些改動最好還是跟社區(qū)交流一下，交流交流才能知道解決方案是不是太LOW。等社區(qū)打上patch固然是很慢，但是可以自己在確認(rèn)patch沒有問題的情況下可以先打到自己的版本上，等社區(qū)版本發(fā)布之后再切過去不遲。個人的力量太渺小，適當(dāng)溝通事半功倍，維護(hù)性也更強(qiáng)。
7. SSD
從頭條的實踐來看，SSD還是比較有效的，畢竟沒法指望數(shù)據(jù)能夠完全加載到內(nèi)存中。之前一直忽略了這一部分，看來這部分需要在做完benchmark的基礎(chǔ)上進(jìn)行改進(jìn)。
