這幾天用spark和es寫了點(diǎn)統(tǒng)計(jì)和查詢，記錄下這過程中踩過的一些坑羹饰。
先說說spark中的坑吧伊滋，記得之前在書上看spark算子的時(shí)候碳却，是這么說action和transformation的區(qū)別的：transformation變換/轉(zhuǎn)換算子：這種變換并不觸發(fā)提交作業(yè)，完成作業(yè)中間過程處理笑旺。action行動(dòng)算子：這類算子會(huì)觸發(fā) sparkcontext 提交 job 作業(yè)昼浦。
當(dāng)時(shí)看過之后也沒太在意這句話，可是這幾天真正實(shí)踐的時(shí)候出現(xiàn)了一個(gè)百思不得其解的問題筒主。好吧关噪，當(dāng)我信心滿滿的寫完一堆map,filter,groupby的時(shí)候開始調(diào)試，問題來了乌妙，map函數(shù)的斷點(diǎn)死活進(jìn)不去使兔，頓時(shí)開始懷疑人生......后來偶然間和一個(gè)網(wǎng)友討論這事兒，才得知這里的奧秘,map屬于transformation藤韵，它是會(huì)延遲加載的虐沥，只有當(dāng)你調(diào)用了rdd.collect才會(huì)觸發(fā)map去執(zhí)行，也就是上面說的那兩類算子的區(qū)別泽艘。
第二個(gè)問題欲险，我要從es里面查詢每天的流量數(shù)據(jù)，然后拿到里面的每條數(shù)據(jù)根據(jù)ip分組統(tǒng)計(jì)該ip的訪問次數(shù)匹涮，然后就噌噌寫完了天试，當(dāng)時(shí)想的是用es查詢，分組統(tǒng)計(jì)直接spark reducebykey然低。寫慣了java面向?qū)ο蟮拇a秋秤，自然而然的就在循環(huán)里調(diào)了連接spark-es的context，然后reducebykey了脚翘。很顯然這樣功能是實(shí)現(xiàn)了灼卢，但是性能卻會(huì)有很大影響，而且spark的函數(shù)有點(diǎn)類似于面向過程的思想来农，這么調(diào)用顯然不符合思想鞋真，最終換成了es的分組聚合。
最后一個(gè)es的奇葩的問題沃于，按照時(shí)間范圍搜索的時(shí)候涩咖，明明有數(shù)據(jù)在那個(gè)范圍內(nèi)，死活就是搜索不出來繁莹，后來發(fā)現(xiàn)mapping里這個(gè)字段竟然是string類型的檩互，好坑，然后各種刪mapping咨演，再重建闸昨。最后把那個(gè)字段的日期定義成了date，再次搜索完美解決，還需要注意一個(gè)地方饵较，時(shí)間的查詢條件最好寫成毫秒值拍嵌，那樣的話就不會(huì)出現(xiàn)什么日期轉(zhuǎn)化異常，省的在這上面浪費(fèi)時(shí)間了循诉。
剛接觸es好多坑還需要繼續(xù)踩横辆，歡迎有用到這些技術(shù)的朋友一起探討！
