Presto在滴滴的探索與實踐

?桔妹導(dǎo)讀：Presto在滴滴內(nèi)部發(fā)展三年，已經(jīng)成為滴滴內(nèi)部Ad-Hoc和Hive SQL加速的首選引擎瑞侮。目前服務(wù)6K+用戶丐枉，每天讀取2PB ~ 3PB HDFS數(shù)據(jù)榄攀，處理30萬億~35萬億條記錄，為了承接業(yè)務(wù)及豐富使用場景茅诱，滴滴Presto需要解決穩(wěn)定性逗物、易用性、性能瑟俭、成本等諸多問題敬察。我們在3年多的時間里，做了大量優(yōu)化和二次開發(fā)尔当，積攢了非常豐富的經(jīng)驗莲祸。本文分享了滴滴對Presto引擎的改進和優(yōu)化，同時也提供了大量穩(wěn)定性建設(shè)經(jīng)驗椭迎。

1. Presto簡介

▍1.1 簡介

Presto是Facebook開源的MPP（Massive Parallel Processing）SQL引擎锐帜，其理念來源于一個叫Volcano的并行數(shù)據(jù)庫，該數(shù)據(jù)庫提出了一個并行執(zhí)行SQL的模型畜号，它被設(shè)計為用來專門進行高速缴阎、實時的數(shù)據(jù)分析。Presto是一個SQL計算引擎简软，分離計算層和存儲層蛮拔，其不存儲數(shù)據(jù)，通過Connector SPI實現(xiàn)對各種數(shù)據(jù)源（Storage）的訪問痹升。

▍1.2 架構(gòu)

Presto沿用了通用的Master-Slave架構(gòu)建炫，一個Coordinator，多個Worker疼蛾。Coordinator負(fù)責(zé)解析SQL語句肛跌，生成執(zhí)行計劃，分發(fā)執(zhí)行任務(wù)給Worker節(jié)點執(zhí)行；Worker節(jié)點負(fù)責(zé)實際執(zhí)行查詢?nèi)蝿?wù)衍慎。Presto提供了一套Connector接口转唉，用于讀取元信息和原始數(shù)據(jù)，Presto 內(nèi)置有多種數(shù)據(jù)源稳捆，如 Hive赠法、MySQL、Kudu乔夯、Kafka 等砖织。同時，Presto 的擴展機制允許自定義 Connector驯嘱，從而實現(xiàn)對定制數(shù)據(jù)源的查詢镶苞。假如配置了Hive Connector，需要配置一個Hive MetaStore服務(wù)為Presto提供Hive元信息鞠评，Worker節(jié)點通過Hive Connector與HDFS交互茂蚓，讀取原始數(shù)據(jù)。

▍1.3

實現(xiàn)低延時原理**Presto是一個交互式查詢引擎剃幌，我們最關(guān)心的是Presto實現(xiàn)低延時查詢的原理聋涨，以下幾點是其性能脫穎而出的主要原因：

  • 完全基于內(nèi)存的并行計算
  • 流水線
  • 本地化計算
  • 動態(tài)編譯執(zhí)行計劃
  • 小心使用內(nèi)存和數(shù)據(jù)結(jié)構(gòu)
  • GC控制
  • 無容錯

2. Presto在滴滴的應(yīng)用

▍2.1 業(yè)務(wù)場景

  • Hive SQL查詢加速
  • 數(shù)據(jù)平臺Ad-Hoc查詢
  • 報表（BI報表、自定義報表）
  • 活動營銷
  • 數(shù)據(jù)質(zhì)量檢測
  • 資產(chǎn)管理
  • 固定數(shù)據(jù)產(chǎn)品

▍2.2 業(yè)務(wù)規(guī)模

▍2.3 業(yè)務(wù)增長

▍2.4 集群部署

目前Presto分為混合集群和高性能集群负乡，如上圖所示牍白，混合集群共用HDFS集群，與離線Hadoop大集群混合部署抖棘，為了防止集群內(nèi)大查詢影響小查詢茂腥， 而單獨搭建集群會導(dǎo)致集群太多，維護成本太高切省，我們通過指定Label來做到物理集群隔離（詳細(xì)后文會講到）最岗。而高性能集群，HDFS是單獨部署的朝捆，且可以訪問Druid般渡， 使Presto 具備查詢實時數(shù)據(jù)和離線數(shù)據(jù)能力。

▍2.5 接入方式

二次開發(fā)了JDBC芙盘、Go驯用、Python、Cli儒老、R蝴乔、NodeJs 、HTTP等多種接入方式贷盲，打通了公司內(nèi)部權(quán)限體系淘这，讓業(yè)務(wù)方方便快捷的接入 Presto 的剥扣，滿足了業(yè)務(wù)方多種技術(shù)棧的接入需求巩剖。Presto 接入了查詢路由 Gateway铝穷，Gateway會智能選擇合適的引擎，用戶查詢優(yōu)先請求Presto佳魔，如果查詢失敗曙聂，會使用Spark查詢，如果依然失敗鞠鲜，最后會請求Hive宁脊。在Gateway層，我們做了一些優(yōu)化來區(qū)分大查詢贤姆、中查詢及小查詢榆苞，對于查詢時間小于3分鐘的，我們即認(rèn)為適合Presto查詢霞捡，比如通過HBO（基于歷史的統(tǒng)計信息）及JOIN數(shù)量來區(qū)分查詢大小坐漏，架構(gòu)圖見：


3. 引擎迭代

我們從2017年09月份開始調(diào)研Presto，經(jīng)歷過0.192碧信、0.215赊琳，共發(fā)布56次版本。而在19年初（0.215版本是社區(qū)分家版本）砰碴，Presto社區(qū)分家躏筏，分為兩個項目，叫PrestoDB和PrestoSQL呈枉，兩者都成立了自己的基金會趁尼。我們決定升級到PrestoSQL 最新版本（340版本）原因是：

  • PrestoSQL社區(qū)活躍度更高，PR和用戶問題能夠及時回復(fù)
  • PrestoDB主要主力還是Facebook維護猖辫，以其內(nèi)部需求為主
  • PrestoDB未來方向主要是ETL相關(guān)的酥泞，我們有Spark兜底，ETL功能依賴Spark住册、Hive

4. 引擎改進

在滴滴內(nèi)部婶博，Presto主要用于Ad-Hoc查詢及Hive SQL查詢加速，為了方便用戶能盡快將SQL遷移到Presto引擎上荧飞，且提高Presto引擎查詢性能凡人，我們對Presto做了大量二次開發(fā)。同時叹阔，因為使用Gateway挠轴，即使SQL查詢出錯，SQL也會轉(zhuǎn)發(fā)到Spark及Hive上耳幢，所以我們沒有使用Presto的Spill to Disk功能岸晦。這樣一個純內(nèi)存SQL引擎在使用過程中會遇到很多穩(wěn)定問題欧啤，我們在解決這些問題時，也積累了很多經(jīng)驗启上，下面將一一介紹：

▍4.1 Hive SQL兼容

18年上半年邢隧，Presto剛起步，滴滴內(nèi)部很多用戶不愿意遷移業(yè)務(wù)冈在，主要是因為Presto是ANSI SQL倒慧，與HiveQL差距較大，且查詢結(jié)果也會出現(xiàn)結(jié)果不一致問題包券，遷移成本比較高纫谅，為了方便Hive用戶能順利遷移業(yè)務(wù)，我們對Presto做了Hive SQL兼容溅固。而在技術(shù)選型時付秕，我們沒有在Presto上層，即沒有在Gateway這層做SQL兼容侍郭，主要是因為開發(fā)量較大询吴，且UDF相關(guān)的開發(fā)和轉(zhuǎn)換成本太高，另外就是需要多做一次SQL解析励幼，查詢性能會受到影響汰寓，同時增加了Hive Metastore的請求次數(shù)，當(dāng)時Hive Metastore的壓力比較大苹粟，考慮到成本和穩(wěn)定性有滑，我們最后選擇在Presto引擎層上兼容。

主要工作：

  • 隱式類型轉(zhuǎn)換
  • 語義兼容
  • 語法兼容
  • 支持Hive視圖
  • Parquet HDFS文件讀取支持
  • 大量UDF支持
  • 其他

Hive SQL兼容嵌削，我們迭代了三個大版本毛好，目前線上SQL通過率9799%。而業(yè)務(wù)從Spark/Hive遷移到Presto后苛秕，查詢性能平均提升30%50%肌访，甚至一些場景提升10倍，Ad-Hoc場景共節(jié)省80%機器資源艇劫。下圖是線上Presto集群的SQL查詢通過率及失敗原因占比吼驶，'null' 表示查詢成功的SQL，其他表示錯誤原因：

▍4.2 物理資源隔離

上文說到店煞，對性能要求高的業(yè)務(wù)與大查詢業(yè)務(wù)方混合跑蟹演，查詢性能容易受到影響，只有單獨搭建集群顷蟀。而單獨搭建集群導(dǎo)致Presto集群太多酒请，維護成本太高。因為目前我們Presto Coordinator還沒有遇到瓶頸鸣个，大查詢主要影響Worker性能羞反，比如一條大SQL導(dǎo)致Worker CPU打滿布朦，導(dǎo)致其他業(yè)務(wù)方SQL查詢變慢。所以我們修改調(diào)度模塊昼窗，讓Presto支持可以動態(tài)打Label是趴，動態(tài)調(diào)度指定的 Label 機器。如下圖所示：


根據(jù)不同的業(yè)務(wù)劃分不同的label膏秫，通過配置文件配置業(yè)務(wù)方指定的label和其對應(yīng)的機器列表右遭，Coordinator會加載配置做盅，在內(nèi)存里維護集群label信息缤削，同時如果配置文件里label信息變動，Coordinator會定時更新label信息吹榴，這樣調(diào)度時根據(jù)SQL指定的label信息來獲取對應(yīng)的Worker機器亭敢，如指定label A時，那調(diào)度機器里只選擇Worker A 和 Worker B 即可图筹。這樣就可以做到讓機器物理隔離了帅刀，對性能要求高的業(yè)務(wù)查詢既有保障了。

▍4.3 Druid Connector

使用 Presto + HDFS 有一些痛點：

  • latency高远剩，QPS較低
  • 不能查實時數(shù)據(jù)扣溺，如果有實時數(shù)據(jù)需求，需要再構(gòu)建一條實時數(shù)據(jù)鏈路瓜晤，增加了系統(tǒng)的復(fù)雜性
  • 要想獲得極限性能锥余，必須與HDFS DataNode 混部，且DataNode使用高級硬件痢掠，有自建HDFS的需求驱犹，增加了運維的負(fù)擔(dān)

所以我們在0.215版本實現(xiàn)了Presto on Druid Connector，此插件有如下優(yōu)點：

  • 結(jié)合 Druid 的預(yù)聚合足画、計算能力（過濾聚合）雄驹、Cache能力，提升Presto性能（RT與QPS）
  • 讓 Presto 具備查詢 Druid 實時數(shù)據(jù)能力
  • 為Druid提供全面的SQL能力支持淹辞，擴展Druid數(shù)據(jù)的應(yīng)用場景
  • 通過Druid Broker獲取Druid元數(shù)據(jù)信息
  • 從Druid Historical直接獲取數(shù)據(jù)
  • 實現(xiàn)了Limit下推医舆、Filter下推、Project下推及Agg下推

在PrestoSQL 340版本象缀，社區(qū)也實現(xiàn)了Presto on Druid Connector蔬将，但是此Connector是通過JDBC實現(xiàn)的，缺點比較明顯：

  • 無法劃分多個Split攻冷，查詢性能差
  • 請求查詢Broker娃胆，之后再查詢Historical，多一次網(wǎng)絡(luò)通信
  • 對于一些場景等曼，如大量Scan場景里烦，會導(dǎo)致Broker OOM
  • Project及Agg下推支持不完善

詳細(xì)架構(gòu)圖見：

使用了Presto on Druid后凿蒜，一些場景，性能提升4~5倍胁黑。▍4.4 易用性建設(shè)為了支持公司的幾個核心數(shù)據(jù)平臺废封，包括：數(shù)夢、提取工具丧蘸、數(shù)易及特征加速及各種散戶漂洋，我們對Presto做了很多二次開發(fā)，包括權(quán)限管理力喷、語法支持等刽漂，保證了業(yè)務(wù)的快速接入。主要工作：

  1. 租戶與權(quán)限
  • 與內(nèi)部Hadoop打通弟孟，使用HDFS SIMPLE協(xié)議做認(rèn)證
  • 使用Ranger做鑒權(quán)贝咙，解析SQL使Presto擁有將列信息傳遞給下游的能力，提供用戶名+數(shù)據(jù)庫名/表名/列名拂募，四元組的鑒權(quán)能力庭猩，同時提供多表同時鑒權(quán)的能力
  • 用戶指定用戶名做鑒權(quán)和認(rèn)證，大賬號用于讀寫HDFS數(shù)據(jù)
  • 支持視圖陈症、表別名鑒權(quán)
  1. 語法拓展
  • 支持add partition
  • 支持?jǐn)?shù)字開頭的表
  • 支持?jǐn)?shù)字開頭的字段
  1. 特性增強
  • insert數(shù)據(jù)時蔼水，將插入數(shù)據(jù)的總行數(shù)寫入HMS，為業(yè)務(wù)方提供毫秒級的元數(shù)據(jù)感知能力
  • 支持查詢進度滾動更新录肯，提升了用戶體驗
  • 支持查詢可以指定優(yōu)先級趴腋，為用戶不同等級的業(yè)務(wù)提供了優(yōu)先級控制的能力
  • 修改通信協(xié)議，支持業(yè)務(wù)方可以傳達(dá)自定義信息嘁信，滿足了用戶的日志審計需要等
  • 支持DeprecatedLzoTextInputFormat格式
  • 支持讀HDFS Parquet文件路徑

▍4.5 穩(wěn)定性建設(shè)

Presto在使用過程中會遇到很多穩(wěn)定性問題于样，比如Coordinator OOM，Worker Full GC等潘靖，為了解決和方便定位這些問題穿剖，首先我們做了監(jiān)控體系建設(shè)，主要包括：

  • 通過Presto Plugin實現(xiàn)日志審計功能
  • 通過JMX獲取引擎指標(biāo)將監(jiān)控信息寫入Ganglia
  • 將日志審計采集到HDFS和ES卦溢；統(tǒng)一接入運維監(jiān)控體系糊余，將所有指標(biāo)發(fā)到 Kafka；
  • Presto UI改進：可以查看Worker信息单寂，可以查看Worker死活信息

通過以上功能贬芥，在每次出現(xiàn)穩(wěn)定性問題時，方便我們及時定位問題宣决，包括指標(biāo)查看及SQL回放等蘸劈，如下圖所示，可以查看某集群的成功及失敗SQL數(shù)尊沸，我們可以通過定義查詢失敗率來觸發(fā)報警：


在Presto交流社區(qū)威沫，Presto的穩(wěn)定性問題困擾了很多Presto使用者贤惯，包括Coordinator和Worker掛掉，集群運行一段時間后查詢性能變慢等棒掠。我們在解決這些問題時積累了很多經(jīng)驗孵构，這里說下解決思路和方法。

根據(jù)職責(zé)劃分烟很，Presto分為Coordinator和Worker模塊颈墅，Coordinator主要負(fù)責(zé)SQL解析、生成查詢計劃雾袱、Split調(diào)度及查詢狀態(tài)管理等恤筛，所以當(dāng)Coordinator遇到OOM或者Coredump時，獲取元信息及生成Splits是重點懷疑的地方谜酒。而內(nèi)存問題叹俏，推薦使用MAT分析具體原因。如下圖是通過MAT分析僻族，得出開啟了FileSystem Cache，內(nèi)存泄漏導(dǎo)致OOM屡谐。


這里我們總結(jié)了Coordinator常見的問題和解決方法：

  • 使用HDFS FileSystem Cache導(dǎo)致內(nèi)存泄漏述么，解決方法禁止FileSystem Cache，后續(xù)Presto自己維護了FileSystem Cache
  • Jetty導(dǎo)致堆外內(nèi)存泄漏愕掏，原因是Gzip導(dǎo)致了堆外內(nèi)存泄漏度秘，升級Jetty版本解決
  • Splits太多，無可用端口饵撑，TIME_WAIT太高剑梳，修改TCP參數(shù)解決
  • JVM Coredump，顯示"unable to create new native thread"滑潘，通過修改pid_max及max_map_count解決
  • Presto內(nèi)核Bug垢乙，查詢失敗的SQL太多，導(dǎo)致Coordinator內(nèi)存泄漏语卤，社區(qū)已修復(fù)

而Presto Worker主要用于計算追逮，性能瓶頸點主要是內(nèi)存和CPU。內(nèi)存方面通過三種方法來保障和查找問題：

  • 通過Resource Group控制業(yè)務(wù)并發(fā)粹舵，防止嚴(yán)重超賣
  • 通過JVM調(diào)優(yōu)钮孵，解決一些常見內(nèi)存問題，如Young GC Exhausted
  • 善用MAT工具眼滤，發(fā)現(xiàn)內(nèi)存瓶頸

而Presto Worker常會遇到查詢變慢問題巴席，兩方面原因，一是確定是否開啟了Swap內(nèi)存诅需，當(dāng)Free內(nèi)存不足時漾唉，使用Swap會嚴(yán)重影響查詢性能睬关。第二是CPU問題，解決此類問題毡证，要善用Perf工具电爹，多做Perf來分析CPU為什么不在干活，看CPU主要在做什么料睛，是GC問題還是JVM Bug丐箩。如下圖所示，為線上Presto集群觸發(fā)了JVM Bug恤煞，導(dǎo)致運行一段時間后查詢變慢屎勘，重啟后恢復(fù)，Perf后找到原因居扒，分析JVM代碼概漱，可通過JVM調(diào)優(yōu)或升級JVM版本解決：

這里我們也總結(jié)了Worker常見的問題和解決方法：

  • Sys load過高，導(dǎo)致業(yè)務(wù)查詢性能影響很大喜喂，研究jvm原理瓤摧，通過參數(shù)（-XX:PerMethodRecompilationCutoff=10000 及 -XX:PerBytecodeRecompilationCutoff=10000）解決，也可升級最新JVM解決
  • Worker查詢hang住問題玉吁，原因HDFS客戶端存在bug照弥，當(dāng)Presto與HDFS混部署，數(shù)據(jù)和客戶端在同一臺機器上時进副，短路讀時一直wait鎖这揣，導(dǎo)致查詢Hang住超時，Hadoop社區(qū)已解決
  • 超賣導(dǎo)致Worker Young GC Exhausted影斑，優(yōu)化GC參數(shù)给赞，如設(shè)置-XX:G1ReservePercent=25 及 -XX:InitiatingHeapOccupancyPercent=15
  • ORC太大，導(dǎo)致Presto讀取ORC Stripe Statistics出現(xiàn)OOM矫户，解決方法是限制ProtoBuf報文大小片迅，同時協(xié)助業(yè)務(wù)方合理數(shù)據(jù)治理
  • 修改Presto內(nèi)存管理邏輯，優(yōu)化Kill策略吏垮，保障當(dāng)內(nèi)存不夠時障涯，Presto Worker不會OOM，只需要將大查詢Kill掉膳汪，后續(xù)熔斷機制會改為基于JVM唯蝶，類似ES的熔斷器，比如95% JVM 內(nèi)存時遗嗽，Kill掉最大SQL

▍4.6 引擎優(yōu)化及調(diào)研

作為一個Ad-Hoc引擎粘我，Presto查詢性能越快檬输，用戶體驗越好院促，為了提高Presto的查詢性能固棚，在Presto on Hive場景计寇，我們做了很多引擎優(yōu)化工作，主要工作：

  • 某業(yè)務(wù)集群進行了JVM調(diào)優(yōu)匙姜，將Ref Proc由單線程改為并行執(zhí)行畅厢，普通查詢由30S~1分鐘降低為3-4S，性能提升10倍+
  • ORC數(shù)據(jù)優(yōu)化氮昧，將指定string字段添加了布隆過濾器框杜，查詢性能提升20-30%，針對一些業(yè)務(wù)做了調(diào)優(yōu)
  • 數(shù)據(jù)治理和小文件合并袖肥，某業(yè)務(wù)方查詢性能由20S降低為10S咪辱，性能提升一倍，且查詢性能穩(wěn)定
  • ORC格式性能優(yōu)化椎组，查詢耗時減少5%
  • 分區(qū)裁剪優(yōu)化油狂，解決指定分區(qū)但獲取所有分區(qū)元信息問題，減少了HMS的壓力
  • 下推優(yōu)化寸癌，實現(xiàn)了Limit专筷、Filter、Project灵份、Agg下推到存儲層

18年我們?yōu)榱颂岣逷resto查詢性能仁堪，也調(diào)研了一些技術(shù)方案，包括Presto on Alluxio和Presto on Carbondata填渠，但是這2種方案最后都被舍棄了，原因是：

  • Presto on Alluxio查詢性能提升35%鸟辅，但是內(nèi)存占用和性能提升不成正比氛什，所以我們放棄了Presto on Alluxio，后續(xù)可能會對一些性能要求敏感的業(yè)務(wù)使用
  • Presto on Carbondata是在18年8月份測試的匪凉，當(dāng)時的版本枪眉，Carbondata穩(wěn)定性較差，性能沒有明顯優(yōu)勢再层，一些場景ORC更快贸铜，所以我們沒有再繼續(xù)跟蹤調(diào)研Presto on Carbondata。因為滴滴有專門維護Druid的團隊聂受，所以我們對接了Presto on Druid蒿秦，一些場景性能提升4~5倍，后續(xù)我們會更多關(guān)注Presto on Clickhouse及Presto on Elasticsearch

5. 總結(jié)

通過以上工作蛋济，滴滴Presto逐漸接入公司各大數(shù)據(jù)平臺棍鳖，并成為了公司首選Ad-Hoc查詢引擎及Hive SQL加速引擎，下圖可以看到某產(chǎn)品接入后的性能提升：

上圖可以看到大約2018年10月該平臺開始接入Presto碗旅，查詢耗時TP50性能提升了10+倍渡处，由400S降低到31S镜悉。且在任務(wù)數(shù)逐漸增長的情況下，查詢耗時保證穩(wěn)定不變医瘫。

而高性能集群侣肄，我們做了很多穩(wěn)定性和性能優(yōu)化工作，保證了平均查詢時間小于2S醇份。如下圖所示：

6. 展望

Presto主要應(yīng)用場景是Ad-Hoc查詢稼锅，所以其高峰期主要在白天，如下圖所示被芳，是網(wǎng)約車業(yè)務(wù)下午12-16點的查詢缰贝，可以看到平均CPU使用率在40%以上。


但是如果看最近一個月的CPU使用率會發(fā)現(xiàn)畔濒，平均CPU使用率比較低剩晴，且波峰在白天10~18點，晚上基本上沒有查詢侵状，CPU使用率不到5%赞弥。如下圖所示：

所以，解決晚上資源浪費問題是我們今后需要解決的難題趣兄。

同時绽左，為了不與開源社區(qū)脫節(jié)，我們打算升級PrestoDB 0.215到PrestoSQL 340版本艇潭，屆時會把我們的Presto on Druid代碼開源出來拼窥，回饋社區(qū)。

本文作者


滴滴Presto引擎負(fù)責(zé)人蹋凝，負(fù)責(zé)帶領(lǐng)引擎團隊深入Presto內(nèi)核鲁纠，解決在海量數(shù)據(jù)規(guī)模下Presto遇到的穩(wěn)定性、性能鳍寂、成本方面的問題改含。搜索引擎及OLAP引擎愛好者，公眾號：FFCompute

關(guān)于團隊

滴滴大數(shù)據(jù)架構(gòu)部 OLAP & 檢索平臺組負(fù)責(zé)以 Elasticsearch迄汛、Clickhouse捍壤、Presto 及 Druid 為代表的 OLAP 引擎的內(nèi)核級極致優(yōu)化，為滴滴各個產(chǎn)品線提供穩(wěn)定可靠的 PB 級海量數(shù)據(jù)的實時數(shù)據(jù)分析鞍爱、日志檢索鹃觉、監(jiān)控及即席查詢服務(wù)。

延伸閱讀

內(nèi)容編輯 | Charlotte
聯(lián)系我們 | DiDiTech@didiglobal.com

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 人面猴
    序言：七十年代末硬霍，一起剝皮案震驚了整個濱河市帜慢，隨后出現(xiàn)的幾起案子，更是在濱河造成了極大的恐慌，老刑警劉巖粱玲，帶你破解...
    沈念sama閱讀 206,839評論 6贊 482
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件躬柬，死亡現(xiàn)場離奇詭異，居然都是意外死亡抽减，警方通過查閱死者的電腦和手機允青，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 88,543評論 2贊 382
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進店門，熙熙樓的掌柜王于貴愁眉苦臉地迎上來卵沉，“玉大人颠锉，你說我怎么就攤上這事∈泛梗” “怎么了琼掠？”我有些...
    開封第一講書人閱讀 153,116評論 0贊 344
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵，是天一觀的道長停撞。 經(jīng)常有香客問我瓷蛙，道長，這世上最難降的妖魔是什么戈毒？ 我笑而不...
    開封第一講書人閱讀 55,371評論 1贊 279
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任艰猬，我火速辦了婚禮，結(jié)果婚禮上埋市，老公的妹妹穿的比我還像新娘冠桃。我一直安慰自己，他們只是感情好道宅，可當(dāng)我...
    茶點故事閱讀 64,384評論 5贊 374
  • 惡毒庶女頂嫁案：這布局不是一般人想出來的
    文/花漫 我一把揭開白布食听。 她就那樣靜靜地躺著，像睡著了一般污茵。 火紅的嫁衣襯著肌膚如雪碳蛋。 梳的紋絲不亂的頭發(fā)上，一...
    開封第一講書人閱讀 49,111評論 1贊 285
  • 城市分裂傳說
    那天省咨，我揣著相機與錄音，去河邊找鬼玷室。 笑死零蓉，一個胖子當(dāng)著我的面吹牛，可吹牛的內(nèi)容都是我干的穷缤。 我是一名探鬼主播敌蜂，決...
    沈念sama閱讀 38,416評論 3贊 400
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼，長吁一口氣：“原來是場噩夢啊……” “哼津肛！你這毒婦竟也來了章喉？” 一聲冷哼從身側(cè)響起，我...
    開封第一講書人閱讀 37,053評論 0贊 259
  • 萬榮殺人案實錄
    序言：老撾萬榮一對情侶失蹤，失蹤者是張志新（化名）和其女友劉穎秸脱，沒想到半個月后落包，有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體，經(jīng)...
    沈念sama閱讀 43,558評論 1贊 300
  • ?護林員之死
    正文 獨居荒郊野嶺守林人離奇死亡摊唇，尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 36,007評論 2贊 325
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年咐蝇，在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片巷查。...
    茶點故事閱讀 38,117評論 1贊 334
  • 活死人
    序言：一個原本活蹦亂跳的男人離奇死亡有序，死狀恐怖，靈堂內(nèi)的尸體忽然破棺而出岛请，到底是詐尸還是另有隱情旭寿，我是刑警寧澤，帶...
    沈念sama閱讀 33,756評論 4贊 324
  • ?日本核電站爆炸內(nèi)幕
    正文 年R本政府宣布崇败，位于F島的核電站盅称，受9級特大地震影響，放射性物質(zhì)發(fā)生泄漏僚匆。R本人自食惡果不足惜微渠，卻給世界環(huán)境...
    茶點故事閱讀 39,324評論 3贊 307
  • 男人毒藥：我在死后第九天來索命
    文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望咧擂。 院中可真熱鬧逞盆，春花似錦、人聲如沸松申。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,315評論 0贊 19
  • 一樁弒父案，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽贸桶。三九已至舅逸，卻和暖如春，著一層夾襖步出監(jiān)牢的瞬間皇筛，已是汗流浹背琉历。 一陣腳步聲響...
    開封第一講書人閱讀 31,539評論 1贊 262
  • 情欲美人皮
    我被黑心中介騙來泰國打工， 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留水醋，地道東北人旗笔。 一個月前我還...
    沈念sama閱讀 45,578評論 2贊 355
  • 代替公主和親
    正文 我出身青樓，卻偏偏與公主長得像拄踪，于是被迫代替她去往敵國和親蝇恶。 傳聞我的和親對象是個殘疾皇子，可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 42,877評論 2贊 345