大數據基礎知識

為了一場緊急考試,沒有正經系統學習過大數據知識的我開始惡補概念

涉及Hadoop、Hbase、Spark、Flink、Flume、Kafka、Sqoop、HDFS、Hive、Mapreduce、Impala、Spark-Sql、Elasticsearch、Yarn、Hue、Cloudera Manager,這篇文章的目的就是作為小白要把這些相關的知識概念還有可能的考點整理出來。

大數據-概念

什么是大數據

大數據(Big data或Megadata):大數據,或稱巨量數據、海量數據、大資料,指的是所涉及的數據量規模巨大到無法通過人工,在合理時間達到截取、管理、處理、并整理成為人類所能解讀的形式的數據資產。

☆大數據的5個特征(5V)

Volume(大量)、Velocity(高速)、Variety(多樣)、Value(價值)、Veracity -(真實性)

  • Volume:數據量大,包括采集、存儲和計算的量都非常大。大數據的起始計量單位至少是P(1000個T)、E(100萬個T)或Z(10億個T)。
  • Variety:種類和來源多樣化。包括結構化、半結構化和非結構化數據,具體表現為網絡日志、音頻、視頻、圖片、地理位置信息等等,多類型的數據對數據的處理能力提出了更高的要求。
  • Value:數據價值密度相對較低,或者說是浪里淘沙卻又彌足珍貴。隨著互聯網以及物聯網的廣泛應用,信息感知無處不在,信息海量,但價值密度較低,如何結合業務邏輯并通過強大的機器算法來挖掘數據價值,是大數據時代最需要解決的問題。
  • Velocity:數據增長速度快,處理速度也快,時效性要求高。比如搜索引擎要求幾分鐘前的新聞能夠被用戶查詢到,個性化推薦算法盡可能要求實時完成推薦。這是大數據區別于傳統數據挖掘的顯著特征。
  • Veracity:數據的準確性和可信賴度,即數據的質量。
大數據的數據單位

按順序給出所有單位:bit(比特))、Byte(字節)、KB、MB、GB、TB、PB、EB、ZB、YB、NB、DB、CB。(進率2^10)
1Byte = 8 Bit
1 KB(Kilobyte) = 1,024 Bytes 
1 MB (Megabyte)= 1,024 KB = 1,048,576 Bytes 
1 GB(Gigabyte) = 1,024 MB = 1,048,576 KB = 1,073,741,824 Bytes
1 TB (Terabyte)= 1,024 GB = 1,048,576 MB = 1,073,741,824 KB = 1,099,511,627,776 Bytes
1 PB(Petabyte) = 1,024 TB = 1,048,576 GB =1,125,899,906,842,624 Bytes
1 EB(Exabyte) = 1,024 PB = 1,048,576 TB = 1,152,921,504,606,846,976 Bytes
1 ZB(Zettabyte) = 1,024 EB = 1,180,591,620,717,411,303,424 Bytes
1 YB(Yottabyte) = 1,024 ZB = 1,208,925,819,614,629,174,706,176 Bytes
1 NB(NonaByte) = 1,024 YB
1 DB(DoggaByte) = 1,024 NB
1 CB (Corydonbyte )= 1,024 DB

大數據的計算模式

批處理計算 ( MapReduce,Spark):最適合于完成大數據批處理的計算模式是MapReduce,首先,MapReduce對具有簡單數據關系、易于劃分的大規模數據采用“分而治之”的并行處理思想;然后將大量重復的數據記錄處理過程總結成Map和Reduce兩個抽象的操作;最后MapReduce提供了一個統一的并行計算框架,把并行計算所涉及到的諸多系統層細節都交給計算框架去完成,以此大大簡化了程序員進行并行化程序設計的負擔。

流式計算 (Scribe ,Flume,Storm,S4,SparkStreaming)流式計算是一種高實時性的計算模式,需要對一定時間窗口內應用系統產生的新數據完成實時的計算處理,避免造成數據堆積和丟失。

迭代計算( HaLoop ,iMapReduce,Twister,Spark)為了克服Hadoop MapReduce難以支持迭代計算的缺陷,工業界和學術界對Hadoop MapReduce進行了不少改進研究。HaLoop把迭代控制放到MapReduce作業執行的框架內部,并通過循環敏感的調度器保證前次迭代的Reduce輸出和本次迭代的Map輸入數據在同一臺物理機上,以減少迭代間的數據傳輸開銷;

交互式計算

圖計算 (Pregel,PowerGrapg,GraphX)

內存計算(Dremel,Hana,redis)

大數據技術體系

image.png

大數據處理流程分為采集、存儲、處理、可視化,其中需要安全、運維技術。

大數據的核心是Hadoop生態系統,Hadoop是目前應用最為廣泛的分布式大數據處理框架,它包含大量的組件,從數據采集到數據存儲、數據處理以及數據分析等一系列技術組件。


image.png

一、數據源說明

  • 結構化數據:關系庫記錄
  • 半結構化數據:日志、郵件等
  • 非結構化數據:文件、視頻、音頻、網絡數據流等

二、數據倉庫

1、什么是數據倉庫?

在計算中,數據倉庫(DW或DWH)也稱為企業數據倉庫(EDW),是用于報告和數據分析的系統,被視為商業智能的核心組件。他們將當前和歷史數據存儲在一個地方,用于為整個企業的工作人員創建分析報告。

2、數據倉庫兩種操作方式的特點

①在線分析處理(OLAP)的特點是交易量相對較低。查詢往往非常復雜,涉及到聚合。對于OLAP系統,響應時間是一種有效性度量。數據挖掘技術廣泛使用OLAP應用程序。OLAP數據庫以多維模式(通常為星型模式)存儲匯總的歷史數據。與數據集市相比,OLAP系統通常具有數小時的數據延遲,而數據集市預計延遲將接近一天。OLAP方法用于分析來自多個來源和視角的多維數據。OLAP中的三個基本操作是:總結(合并),鉆取和切片和切塊。

②聯機事務處理(OLTP)的特點是大量短暫的在線事務(INSERT,UPDATE,DELETE)。OLTP系統強調非常快速的查詢處理并保持多訪問環境中的數據完整性。對于OLTP系統,有效性以每秒交易次數來衡量。OLTP數據庫包含詳細和當前的數據。用于存儲事務數據庫的模式是實體模型(通常是3NF)。規范化是對在該系統中數據建模技術的規范。

三、ETL與DM的區別

ETL/Extraction-Transformation-Loading——用于完成DB到DW的數據轉存,它將DB中的某一個時間點的狀態,“抽取”出來,根據DW的存儲模型要求,“轉換”一下數據格式,然后再“加載”到DW的一個過程,這里需要強調的是,DB的模型是ER模型,遵從范式化設計原則,而DW的數據模型是雪花型結構或者星型結構,用的是面向主題,面向問題的設計思路,所以DB和DW的模型結構不同,需要進行轉換。

DM/Data Mining/數據挖掘——這個挖掘,不是簡單的統計了,他是根據概率論的或者其他的統計學原理,將DW中的大數據量進行分析,找出我們不能直觀發現的規律。

Hadoop

一、Hadoop

1、什么是Hadoop?

Hadoop的定義是:一個用java語言編寫的便于大型數據集合的分布式儲存和計算的軟件框架。Hadoop是一個由Apache基金會所開發的分布式系統基礎架構。用戶可以在不了解分布式底層細節的情況下,開發分布式程序。充分利用集群的威力進行高速運算和存儲。Hadoop實現了一個分布式文件系統( Distributed File System),其中一個組件是HDFS(Hadoop Distributed File System)。HDFS有高容錯性的特點,并且設計用來部署在低廉的(low-cost)硬件上;而且它提供高吞吐量(high throughput)來訪問應用程序的數據,適合那些有著超大數據集(large data set)的應用程序。Hadoop的框架最核心的設計就是:HDFS和MapReduce。HDFS為海量的數據提供了存儲,而MapReduce則為海量的數據提供了計算。

2、Hadoop特點是什么?

①高效率(Efficient):分布式云計算,采用標準x86架構服務器大規模集群實現,每個模塊都是一個離散的處理單元,使用并行計算技術,及群內各計算節點負載均衡,當某節點負荷過高時,可智能的將負荷轉移到其他節點,并支持節點線性平滑擴展;分布式云存儲,采用x86服務器的本地硬盤實現,使用分布式文件系統,每份數據至少保存在3個節點,保證存儲設計的性能和可靠性目標。

②可靠性(Reliable):能搞自身的維護數據的多個成本,并且在任務失敗是自動的重新部署計算任務

③可擴容性(Scalable):能可靠的儲存和處理PB級的數據

④成本低(Economical):可以通過普通機器組成的服務器群來分發以及處理數據。這些服務器群總計可達數千個節點。

數據采集工具

離線數據采集:sqoop
實時數據采集:ogg
日志數據采集:logstash\flume

sqoop

Sqoop是一個用來將Hadoop和關系型數據庫中的數據相互轉移的工具,可以將一個關系型數據庫(例如 : MySQL ,Oracle ,Postgres等)中的數據導入到Hadoop的HDFS中,也可以將HDFS的數據導入到關系型數據庫中。
用于收集日志數據、對數據進行簡單處理,并寫道數據接收方。
Flume提供了從console(控制臺)、RPC(Thrift-RPC)、text(文件)、tail(UNIX tail)、syslog(syslog日志系統),支持TCP和UDP等2種模式,exec(命令執行)等數據源上收集數據的能力。

flume

Flume是Cloudera提供的一個高可用的,高可靠的,分布式的海量日志采集、聚合和傳輸的系統,Flume支持在日志系統中定制各類數據發送方,用于收集數據;同時,Flume提供對數據進行簡單處理,并寫到各種數據接受方(可定制)的能力。
可線性擴展,具有數據一致性。
Agent主要由:source,channel,sink三個組件組成.
Source:
從數據發生器接收數據,并將接收的數據以Flume的event格式傳遞給一個或者多個通道channel,Flume提供多種數據接收的方式,比如Avro,Thrift,twitter1%等
Channel:
channel是一種短暫的存儲容器,它將從source處接收到的event格式的數據緩存起來,直到它們被sinks消費掉,它在source和sink間起著橋梁的作用,channel是一個完整的事務,這一點保證了數據在收發的時候的一致性. 并且它可以和任意數量的source和sink鏈接. 支持的類型有: JDBC channel , File System channel , Memory channel等.
sink:
sink將數據存儲到集中存儲器比如Hbase和HDFS,它從channels消費數據(events)并將其傳遞給目標地. 目標地可能是另一個sink,也可能HDFS,HBase.

數據存儲工具

hdfs:分布式文件存儲系統,適合一次寫、多次讀的場景
kudu:分布式文件存儲系統,可快速更新,支撐快速讀寫場景
hbase:分布式數據庫
kafka:消息總線
hive:數據倉庫

HDFS

hdfs:基于java的hadoop分布式文件存儲系統,適合大文件分布式存儲,一次寫、多次讀的場景,比如一個1T的文件,存儲的時候,會存儲在多臺機器而不是單臺機器。
特點:

  • 易于擴展的分布式存儲系統
  • 對機器性能要求不高,運行在大量普通廉價機器
  • 數據保存3個副本,副本丟失可自動回復
  • 高擴展性,可任意增加、刪除節點
    結構:
    分為主節點、從節點
    1、主節點 namenode
  • 接收用戶操作請求
  • 維護文件系統的目錄結構
  • 管理文件與數據塊之間的關系,數據塊與datanode之間關系
    2、從節點 datanode
  • 存儲數據庫
  • 文件分成數據庫存儲
  • 文件有多個副本

BLOCKSIZE:大文件會被切分成塊,通常64或者128MB
每個數據庫會被存儲在不同的地方,通常是3個

HDFS命令:
1、列出文件和目錄清單

//根目錄下
hadoop fs -ls /
//當前目錄下
hadoop fs -ls
//用戶主目錄
hadoop fs -ls /user/foo

2、hdfs目錄操作

//建立目錄
hadoop fs -mkdir /user/foo/newdir
//刪除目錄
hadoop fs -rmdir /user/foo/newdir

3、上傳文件后目錄

//上傳文件
hadoop fs -put localfile /user/foo/newfile
//上傳目錄
hadoop fs -put localdir /user/foo/newdir
//追加上傳
hadoop fs -apendToFile localfile /user/foo/oldfile

4、查看文件

//查看文件內容
hadoop fs -cat /user/foo/file
//查看文件末尾
hadoop fs -tail /user/foo/file

5、下載文件或目錄

//下載文件
hadoop fs -get /user/foo/remotefile localfile

6、刪除文件或目錄

//刪除文件
hadoop fs -rm /user/foo/remotefile

Hbase

Hbase是建立在HDFS之上的,提供高可靠性、高性能、列存儲、可伸縮、實時讀寫的數據庫系統。HBase不同于一般的關系數據庫,它是一個適合于非結構化數據存儲的數據庫。另一個不同的是HBase基于列的而不是基于行的模式。
HBase – Hadoop Database,是一個高可靠性、高性能、面向列、可伸縮的分布式存儲系統,利用HBase技術可在廉價PC Server上搭建起大規模結構存儲集群。
HBase是Google Bigtable的開源實現,類似Google Bigtable利用GFS作為其文件存儲系統,HBase利用Hadoop HDFS作為其文件存儲系統;Google運行MapReduce來處理Bigtable中的海量數據,HBase同樣利用Hadoop MapReduce來處理HBase中的海量數據;Google Bigtable利用 Chubby作為協同服務,HBase利用Zookeeper作為對應。

  • 高可靠:存儲3份冗余,保障高可靠
  • 高性能、實時讀寫,海量數據處理能力,大數據并發數據的實時讀寫高性能
  • 面向列:列獨立索引
  • 可擴展,可快速擴充集群
  • 強一致性、行事務:同一行數據讀寫是原子的


    image.png

hive

Hive是基于Hadoop的一個數據倉庫工具,可以將結構化的數據文件映射為一張數據庫表,并提供完整的sql查詢功能,可以將sql語句轉換為MapReduce任務進行運行。Hive主要包括用戶接口、元數據存儲、解釋器、編譯器、優化器、執行器等組成部分。

  • 用戶接口:有3個,cli、client、wui。client是hive客戶端,用戶連接到hive server,wui通過瀏覽器訪問hive。
  • 元數據存儲:hive把元數據存儲在數據庫,元數據包括表名、列、分區、屬性、所在目錄等。連接到數據庫的模型分為三種:單用戶模式、多用戶模式、遠程服務器模式
  • Diver(解釋器、編譯器、優化器、執行器):產生查詢計劃,存儲在hdfs,隨后由mapreduce調用執行。
    學習成本低,可以通過類似SQL語句實現快速MapReduce統計,使MapReduce變得更加簡單,而不必開發專門的MapReduce應用程序。hive十分適合對數據倉庫進行統計分析。
    最適合應用在基于大量不可變數據的批處理作業。
    用來做數據倉庫數據加工的SQL引擎,將SQL轉換成多個作業(JOB)
    構建于hadoop的hdfs和mapreduce之上,用于管理和查詢結構化、非結構化的數據倉庫。
    目的是讓會使用SQL的工程師來進行數據加工。
    hive命令
    1、數據庫操作
//建立數據庫
create database db1
//刪除數據庫
drop database db1
//切換數據庫
user db1

2、表操作

//顯示庫中所有表
show tables
//建表
create table table1(aaa string)
//刪除表
drop table table1

spark-SQL

用來做數據倉庫數據加工的工具,是spark生態的一個子系統,與hive一樣把SQL處理成一個個job,由于是用內存計算,比mapreduce快,用于批量加工、交互式分析

impala

專注于數據倉庫下的OLAP,一般用于前臺交互式分析查詢數據用,大數據處理性能較差

Elasticsearch

文檔型數據查詢,可用于多字段查詢,適用于客戶標簽查詢、客戶資料查詢等場景。

kafka

Kafka是一種高吞吐量的分布式發布訂閱消息系統,它可以處理消費者在網站中的所有動作流數據。是一個開源流處理平臺,由scala和java編寫。
是一個分布式隊列系統。利用磁盤順序讀寫實現持久化,完全分布式結構,基于zookeeper實現了消息生產者和消費者的負載均衡。支持多個消費者做為一個整體來消費消息,支持多主題的消息發布、訂閱模式。
優點:

  • 高吞吐量、低延遲:每秒可以處理幾十萬條消息,它的延遲最低只有幾毫秒
  • 可擴展性:kafka集群支持熱擴展
  • 持久性、可靠性:消息被持久化到本地磁盤,并且支持數據備份防止數據丟失
  • 容錯性:允許集群中節點故障(若副本數量為n,則允許n-1個節點故障)
  • 高并發:支持數千個客戶端同時讀寫
    常用術語:
  • Broker:Kafka集群包含一個或多個服務器,這種服務器被稱為broker
  • Topic:每條發布到Kafka集群的消息都有一個類別,這個類別被稱為Topic。(物理上不同Topic的消息分開存儲,邏輯上一個Topic的消息雖然保存于一個或多個broker上但用戶只需指定消息的Topic即可生產或消費數據而不必關心數據存于何處)
  • Partition:Partition是物理上的概念,每個Topic包含一個或多個Partition.
  • Producer:負責發布消息到Kafka broker
  • Consumer:消息消費者,向Kafka broker讀取消息的客戶端。
  • Consumer Group:每個Consumer屬于一個特定的Consumer Group(可為每個Consumer指定group name,若不指定group name則屬于默認的group)。

適用場景:

  • 日志收集:可以用Kafka可以收集各種服務的log,通過kafka以統一接口服務的方式開放給各種consumer
  • 消息系統:解耦生產者和消費者、緩存消息等
  • 用戶活動跟蹤:kafka經常被用來記錄web用戶或者app用戶的各種活動,如瀏覽網頁、搜索、點擊等活動
  • 運營指標:kafka也經常用來記錄運營監控數據
  • 流式處理:比如spark streaming和storm

數據處理工具

離線計算:mapreduce
DAG計算:tez
內存計算:spark
實時計算:spark streaming(微批處理)、flink

mapreduce

Mapreduce是一種分布式計算模型,主要用于搜索領域,處理海量數據的計算問題。由兩個階段組成,Map和reduce,用戶主需要實現map和reduce兩個函數,就可以實現分布式計算。
特點:

  • 高可靠性:處理數據的能力值得信賴。
  • 高擴展性:在可用的計算機集簇間分配數據并完成計算任務的,這些集簇可以方便地擴展到數以千計的節點中。
  • 高效性:能夠在節點之間動態地移動數據,并保證各個節點的動態平衡,因此處理速度非常快。
  • 高容錯性:能夠自動保存數據的多個副本,并且能夠自動將失敗的任務重新分配。
    MapReduce計算框架采用master/slave架構。一個Hadoop集群是有一個Jobtracker和—定數目的Tasktracker組成。
    MapReduce計算模型適用于批處理任務。
    MapReduce是一個線性可擴展模型,服務器越多,處理時間越短。

spark

spark基于內存計算的開源集群分布式計算系統,使用scala開發。
基于內存計算,效率高于hadoop.job中間輸出和結果可以保存在內存中,從而不需要讀寫HDFS,節省了磁盤IO耗時,號稱性能比hadoop塊一百倍。
它擁有Hadoop MapReduce所具有的優點,但不同于MapReduce的是:Job中間輸出結果可以保存在內存中,從而不再需要讀寫HDFS,因此Spark能更好地適用于數據挖掘與機器學習等需要迭代的MapReduce的算法。
Spark兼容Hadoop生態系統,可以運行在Yarn上,能讀取HDFS,HBase, Cassandra以及任何Hadoop數據源
Spark可以用于以下場景:
√ Spark Shell/Spark Submit的批處理
√ Spark SQL的交互式查詢
√ Spark Streaming的實時處理應用
√ MLlib/MLbase的機器學習
√ GraphX的圖處理和SparkR數據挖掘

使用場景:

  • 復雜的批量處理,偏重處理海量數據
  • 基于歷史數據的交互式查詢,偏重于交互響應,時間在數十秒到數十分鐘,使用spark-sql
  • 基于實時數據流的數據處理,低延遲的實時處理

flink

Flink是開源的分布式,高性能,高可用,準確的流處理框架,用于在無界和有界數據流上進行有狀態計算,支持實時流處理和批處理。

開源軟件,實時處理工具,可以同時處理批處理和流處理任務
快速可靠,用作通用數據處理,速度快
使用方便,采用java\scala編程語言
flink定位時數據處理引擎,flink可以批流結合
flink最大的優勢是連續查詢。

集群資源管理

YARN

YARN (Yet Another Resource Negotiator的縮寫)是開源Hadoop 分布式處理框架中的資源管理和作業調度技術。作為Hadoop 的核心組件之一,YARN 負責將系統資源分配給在Hadoop集群中運行的各種應用程序,并調度要在不同集群節點上執行的任務。
組成:

  • ResourceManager: 擁有系統所有資源分配的決定權,負責集群中所有應用程序的資源分配,擁有集群資源主要、全局視圖。因此為用戶提供公平的,基于容量的,本地化資源調度。

  • NodeManager:主要負責與ResourceManager通信,負責啟動和管理應用程序的container的生命周期,監控它們的資源使用情況(cpu和內存),跟蹤節點的監控狀態,管理日志等,并報告給RM。

  • ApplicationManager:主要負責接收job的提交請求,為應用分配第一個Container來運行ApplicationMaster,還有就是負責監控ApplicationMaster,在遇到失敗時重啟ApplicationMaster運行的Container。

數據可視化工具

hue:CDH自帶的可視化工具,通過web界面查詢hive、impala的可視化數據,任務執行比較慢,但是比較穩定,適用于大數據處理,性能較好,用戶DPI日志離線分析、網絡信令離線分析
zepplin:可視化工具
klbana:查詢es數據

HUE

Hue是一個開源的Apache Hadoop UI系統,由Cloudera貢獻給開源社區,它是基于Python Web框架Django實現的。通過使用Hue可以在瀏覽器端的Web控制臺上與Hadoop集群進行交互來分析處理數據,例如操作Hive、Impala查詢,運行MapReduce Job等等

數據安全運維

cloudera manager:CDH自帶的工具,集群安裝、部署、配置等

cloudera manager

cloudera manager覆蓋了集群所有資源與服務的統一配置、管理、監控、診斷。
特點:

  • 零宕機滾動安裝、升級
  • 配置組件高可用、手工、自動切換
  • 配置日志、回滾
  • 服務間動態資源調配
  • 容災備份、恢復
  • LDAP、kerberos集成
  • 直接連接cloudera支持服務體系
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 228,646評論 6 533
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,595評論 3 418
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 176,560評論 0 376
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,035評論 1 314
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,814評論 6 410
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,224評論 1 324
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,301評論 3 442
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,444評論 0 288
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,988評論 1 335
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,804評論 3 355
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,998評論 1 370
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,544評論 5 360
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,237評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,665評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,927評論 1 287
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,706評論 3 393
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,993評論 2 374

推薦閱讀更多精彩內容