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