亚洲免费av电影一区二区三区,日韩爱爱视频,51精品视频一区二区三区,91视频爱爱,日韩欧美在线播放视频,中文字幕少妇AV,亚洲电影中文字幕,久久久久亚洲av成人网址,久久综合视频网站,国产在线不卡免费播放

        ?

        基于Hadoop的海量氣象雷達小文件存儲研究

        2015-12-02 02:28:54楊芙容王永麗王文明
        成都信息工程大學學報 2015年3期
        關(guān)鍵詞:海量內(nèi)存氣象

        楊芙容, 王永麗, 王文明

        (成都信息工程大學信息安全工程學院,四川成都610225)

        0 引言

        近年,氣象現(xiàn)代化業(yè)務(wù)飛速發(fā)展,為廣大用戶提供更加全面、更加精細化的氣象服務(wù),其中,氣象雷達近年呈高速發(fā)展的態(tài)勢,受到世界多數(shù)國家和國際氣象組織的高度重視[1]。尤其是多普勒天氣雷達技術(shù)日益普遍的使用,獲得了更多的探測數(shù)據(jù)信息,提高了天氣的監(jiān)測能力,對預(yù)報強對流天氣等具有非常重要意義。同時,氣象現(xiàn)代化造成氣象數(shù)據(jù)的成倍增長,對系統(tǒng)的存儲和處理能力提出很高的要求。

        傳統(tǒng)的關(guān)系型數(shù)據(jù)庫系統(tǒng)在存儲和管理數(shù)據(jù)上出現(xiàn)負載飽滿讀寫性能不理想等問題[2],迫切需要新的海量數(shù)據(jù)處理方案,在眾多的海量數(shù)據(jù)處理平臺中,Apache Hadoop[3]已經(jīng)迅速成為存儲和處理海量數(shù)據(jù)的首選平臺之一。國際上著名的互聯(lián)網(wǎng)門戶網(wǎng)站雅虎、社交網(wǎng)絡(luò)服務(wù)網(wǎng)站Face Book,以及國內(nèi)淘寶、百度等眾多知名的IT企業(yè),先后采用Hadoop開發(fā)出適合自己的數(shù)據(jù)管理平臺。Hadoop具有吞吐量大、效率高、容錯性高、可靠性高、成本低等優(yōu)點,能夠擴展到云環(huán)境,適用于氣象雷達這種有多種處理需求的應(yīng)用場景。

        1 Hadoop核心組成

        Hadoop是Apache軟件基金會旗下的一個開源分布式計算平臺,核心組件包括 HDFS、Map Reduce、HBase等[4],HDFS形成Hadoop的文件分布式系統(tǒng);HBase是一個面向列的分布式數(shù)據(jù)庫,可靠性高、可伸縮、提供實時讀寫;Map Reduce是Hadoop的數(shù)據(jù)處理模塊,能對存儲在HDFS和HBase中的大規(guī)模數(shù)據(jù)進行高效的分布式并行處理。

        HDFS采用主從式架構(gòu)設(shè)計模式(master/slaver structure),一個名稱節(jié)點(Name Node)和若干數(shù)據(jù)節(jié)點(Data Node)構(gòu)成HDFS集群。Name Node是 HDFS中的管理者,負責存儲和管理文件系統(tǒng)的命名空間(name space),文件目錄的元數(shù)據(jù),集群配置(cluster configuration)和存儲塊的復(fù)制情況等信息。Name space是一個分層結(jié)構(gòu)的文件和目錄,記錄權(quán)限,修改和訪問時間,命名空間和磁盤空間配額等屬性。DataNode是HDFS的基本組成部分,提高文件數(shù)據(jù)的存儲服務(wù)。它將文件以分塊形式存儲到本地文件系統(tǒng),并周期性地將所存塊的信息發(fā)送給Name Node。

        HBase的設(shè)計源于Big Table的啟發(fā),在HDFS上開發(fā)的一個分布式數(shù)據(jù)庫。數(shù)據(jù)集,主要存儲處理大規(guī)模的非結(jié)構(gòu)化和半結(jié)構(gòu)化的數(shù)據(jù)。Hbase使用LSM樹型結(jié)構(gòu),將需要修改的數(shù)據(jù)直接寫入內(nèi)存。操作數(shù)據(jù)時直接定位到相應(yīng)的HRegion server,在region上找到匹配的數(shù)據(jù),而且引入高速緩存,使HBase能提供實時計算服務(wù)。

        2 小文件問題

        把海量小文件(小于16MB的文件)直接存儲在HDFS上存在的問題簡稱為小文件問題[5]。為節(jié)省內(nèi)存空間和提高傳輸效率,氣象雷達文件在存儲和使用前通常先做壓縮處理,壓縮后文件大小在幾KB到幾百KB之間,屬于小文件范疇,這就可能引發(fā)小文件問題。

        (1)Name Node內(nèi)存溢出

        Name Node直接把文件系統(tǒng)的元數(shù)據(jù)存儲在主存中,通常一個文件的元數(shù)據(jù)占250bytes內(nèi)存,每個塊的3個復(fù)制文件的元數(shù)據(jù)占368bytes[6],文件數(shù)目越大,占用的Name Node內(nèi)存空間也成倍數(shù)增加。此外,DataNodes定時向Name Node發(fā)送塊報告信息,Name Node收集這些信息,作為塊映射信息存儲在內(nèi)存中。當文件數(shù)目很大時,這部分信息所占內(nèi)存不容忽視。由式(1)可以看出減少Name Node內(nèi)存占用的主要方法是減少Name Node管理的文件個數(shù)和塊數(shù)目。

        其中M是Name Node的內(nèi)存占用,N文件數(shù),β代表塊的映射信息,HBS是設(shè)定的塊大小,默認取整為64 M,Li是每個小文件的大小表示比值向上取整,a為Name Node所占內(nèi)存,這部分內(nèi)存很小。

        (2)訪問延遲高

        當讀取大量的小文件出現(xiàn)高訪問延遲主要有3個原因:首先,HDFS客戶端每操作一個文件都需要訪問一次Name Node元數(shù)據(jù),引發(fā)元數(shù)據(jù)服務(wù)器的頻繁相互作用的延遲。如640 MB的大文件(10個64 MB文件)I/O吞吐量,HDFS客戶端只需要訪問Name Node 5次,而在相同大小下(如10240個64 KB文件),客戶需要訪問Name Node 5120次,這種延遲很明顯。其次,HDFS失去塊間關(guān)系。HDFS有自己的放置策略,可以在可擴展性、讀效率、寫帶寬之間達到很好的平衡。但沒有考慮文件的連續(xù)性,連續(xù)文件不一定連續(xù)放置,甚至可能被放在不同的塊中[7]。再者,HDFS目前沒有提供預(yù)取函數(shù)降低I/O延遲,沒有為數(shù)據(jù)的放置和預(yù)取機制考慮文件的相關(guān)性,從HDFS中讀取小文件時,通常需要多次查找和在Data Node和Data Node之間反復(fù)來回跳轉(zhuǎn)。

        (3)Map任務(wù)過多

        在HDFS中文件按塊存儲,文件不滿64 MB(Block默認64 MB)也占用一個Block。Map任務(wù)通常一次處理一個塊輸入,這樣Block數(shù)目越多,Map任務(wù)越多,而實際上,每個map只處理很少的數(shù)據(jù)量,這就造成額外的簿記開銷,大量時間浪費在任務(wù)啟動和結(jié)束上。如處理1 GB的一個大文件需要16個64 MB的塊,而處理1 GB的1萬個左右100 KB的小文件需要1萬個64 MB的塊。這1萬個小文件的map效率要比大文件map效率低幾十到幾百倍。

        3 優(yōu)化方案設(shè)計

        目前,基于HDFS的海量小文件存儲和訪問效率問題的解決方法主要分為3類。

        (1)利用Hadoop自身提供的方法合并小文件,如hadoop 歸檔[8](Hadoop archive,HAR)、Sequence File[9]等,但這些方法存在很多問題,最突出的是訪問效率低下。

        (2)針對具體的應(yīng)用提出對應(yīng)的文件合并、組合方法,通常在HDFS上添加一個小文件處理模塊[10],由處理模塊完成數(shù)據(jù)的合并、更新、刪除、緩存等操作:Xuhui Liu等[11]將地理位置信息相鄰的多個小文件合并成一個大文件,為檢索到小文件的位置,為其建立一個全局的位置索引,減少Name Node的內(nèi)存占用。但是當小文件數(shù)據(jù)量非常大時,全局的位置索引文件就變得十分龐大,每次定位一條數(shù)據(jù)耗費大量時間,文件的檢索速率低;Bo Dong等[12]提出將同一個課程 PPT的多個圖片小文件合并成大文件,在Data Node上為每個文件建立一個本地的單獨索引查詢方法,分擔Name Node的查詢負擔。但合并文件超過默認塊大小時,該方法比較復(fù)雜,需要人為干預(yù)小文件的合并和建立索引操作。

        (3)改進系統(tǒng)的架構(gòu)。文獻[13]提出一種增強型的HDFS,擴展單一的Name Node成分層Name Node的架構(gòu),同時擴展的HDFS架構(gòu)中集成高速緩存,提高文件的讀取效率。劉小俊等[14]提出將 RDBMS和 Hadoop結(jié)合,前端RDBMS作為小文件訪問入口和合并工具,后端Hadoop存儲和處理海量數(shù)據(jù),發(fā)揮各自的優(yōu)勢。但總的來說,改進架構(gòu)非常復(fù)雜,成本高而且較難實現(xiàn)。

        3.1 基本思想

        多普勒天氣雷達通常每幾分鐘(6 min)完成一個體掃,每個體掃文件里包含N·(Z、V、W)一次產(chǎn)品文件、一個VOL和根據(jù)需要設(shè)定的多個二次產(chǎn)品文件,其中N表示每次抬高的仰角層數(shù),一天24小時不間斷采集雷達數(shù)據(jù)。

        為節(jié)省磁盤空間和網(wǎng)絡(luò)帶寬,把每個體掃的產(chǎn)品文件采用壓縮方式存儲。針對氣象雷達數(shù)據(jù)的特征,壓縮后將文件格式命名為:年月日_時分秒.掃描層號.產(chǎn)品Type.掃描模式.產(chǎn)品參數(shù)20141214-125233.00.004.000-0.47.zdb,表示20141214.12:52:33.表示:第0層.v產(chǎn)品.000掃描式.0.47產(chǎn)品參數(shù)(仰角)的一個V產(chǎn)品文件。

        表1 壓縮文件命名格式

        壓縮后體掃文件大小在幾KB到幾百KB之間,其中一次產(chǎn)品文件壓縮后文件大小為通常幾到幾十KB,這部分數(shù)據(jù)對系統(tǒng)的數(shù)據(jù)處理實時性要求比較高,在存儲時選擇HBase。HBase基于HDFS之上,可以將操作分散到多個節(jié)點上并行處理,執(zhí)行效率很高,能夠提供實時計算服務(wù)。其他的VOL文件和二次產(chǎn)品文件通常對系統(tǒng)的實時性要求不高,是由一次產(chǎn)品文件根據(jù)需要計算整合。對于這些文件采用Sequence File合并技術(shù),以VOL文件和二次產(chǎn)品文件的文件名為key、文件內(nèi)容為value的形式進行合并,減少元數(shù)據(jù)的內(nèi)存占用量,節(jié)省Name Node的內(nèi)存空間。全文存儲系統(tǒng)架構(gòu)模型如圖1所示。

        圖1 存儲系統(tǒng)架構(gòu)模型

        3.2 一次產(chǎn)品文件的存儲

        HBase無模式無類型,由行和列組成。行和列的坐標交叉決定表格單元格(cell)。cell的內(nèi)容是未解釋的字符數(shù)組。HBase具有很好的可伸縮性,表可以數(shù)十億個數(shù)據(jù)行“高”;表可以很“寬”(數(shù)百萬個列)。表的模式直接反映存儲形式,可以提供高效的數(shù)據(jù)結(jié)構(gòu)的序列化、存儲和檢索。HBase處理幾十KB的小文件時,查詢效率很高[15],把ZVW一次產(chǎn)品文件直接存儲在HBase中有利于提高文件的讀取效率。

        HBase行鍵設(shè)計:HBase通過行鍵(row key)、列族(Column Family)、列和版本4個維度定位某條數(shù)據(jù),它不能像傳統(tǒng)數(shù)據(jù)庫一樣支持where等條件查詢,只能全盤掃面或按row key檢索數(shù)據(jù)。HBase存儲模型設(shè)計時,首先需要根據(jù)業(yè)務(wù)設(shè)計行鍵,檢索記錄的主鍵,可以利用其存儲排序特性提高性能。

        在天氣雷達業(yè)務(wù)中,雷達產(chǎn)品文件一般以時間和產(chǎn)品參數(shù)作為標識,這兩個維度也是常用的檢索條件,因此設(shè)計時間+產(chǎn)品參數(shù)的行鍵設(shè)計方案。為能將region server的負載均衡,防止出現(xiàn)所有新數(shù)據(jù)都在一個region server上堆積的現(xiàn)象,設(shè)計row key時采用隨機散列與預(yù)分區(qū)二者相結(jié)合的方法。預(yù)分區(qū)開始就預(yù)建好一部分region,這些region都維護著自已的star tend keys,由MD5方式生成隨機字符串,寫數(shù)據(jù)能均等地命中這些預(yù)建的region,解決寫熱點問題,大大地提高性能。

        HBase列族設(shè)計。HBase表中列族需要提前定義,是表chema的重要組成部分。不同列族的數(shù)據(jù)是存儲在不同的HFile中,所以一般把同時訪問的數(shù)據(jù)放在一個列族中,而在氣象雷達應(yīng)用中,因為業(yè)務(wù)需要訪問全要素,所以把同一類型的數(shù)據(jù)都放置在一個列族中;以首字母和產(chǎn)品參數(shù)作為列族和列的標識符。例如列FP∶Z、FP∶V都屬于FP(First Product)這個列族。

        3.3 VOL文件和二次產(chǎn)品文件的存儲

        由于VOL文件和二次產(chǎn)品文件的存儲和訪問對系統(tǒng)的實時性要求不高,而且經(jīng)過壓縮后的VOL文件和二次產(chǎn)品文件大小通常為幾十到幾百KB,采用Hadoop提供的應(yīng)用程序編程接口 API:Sequence File[16],主要由一個Header后跟多條Record組成。Header主要包含版本、Key、value類名、壓縮方式判斷、自定義信息和同步標識等,同步標識用于快速定位到記錄的邊界。每條Record以鍵值對的方式進行存儲,表示字符數(shù)組。

        Sequence File根據(jù)壓縮與否有3種存儲形式,Value壓縮、block壓縮和不壓縮存儲,通過Sequence File類的內(nèi)部類Compression Type表示。采用不壓縮方式存儲 io.seqfile.compression.type=NONE。

        Sequence File通過創(chuàng)建Sequence File.Write實現(xiàn)寫入,然后調(diào)用writer.append(key,value)打包記錄。它就像為存儲提供一個容器,將多個小文件打包統(tǒng)一存儲。在存儲氣象雷達數(shù)據(jù)時,采用Sequence File技術(shù)將文件進行合并處理,將VOL和二次產(chǎn)品文件的文件名作為key,文件的內(nèi)容作為value序列化合并成一個大文件,合并后的文件元數(shù)據(jù)信息存儲在Name Node中,節(jié)省Name Node的內(nèi)存空間。

        4 實驗測試

        4.1 測試環(huán)境

        測試使用4臺服務(wù)器構(gòu)建集群,其中1臺作為主服務(wù)器 master,3 臺從節(jié)點 node1、node2、node3;服務(wù)器配置Intel(R)Core(TM)2 Quad CPU Q8200@2.33 GHz 2.34 CHz,內(nèi)存4GB硬盤500GB,操作系統(tǒng) Red Hat Enterprise Linux Sever release 6.5,Hadoop版本是1.2.3,HDFS副本數(shù)dfs.replication設(shè)置為3,HDFS最小塊設(shè)置為默認值64 MB,Second Name node配置在node1上。HBase版本是0.94.1,使用HBase自帶的zookeeper。

        4.2 實現(xiàn)方法

        實驗測試中數(shù)據(jù)是某臺多普勒氣象雷達2014年6月觀察的數(shù)據(jù),701134條記錄,壓縮后總大小為11.2 GB,每條記錄都在1~500 KB,其中一次產(chǎn)品文件壓縮文件大都小于100 KB。

        Name Node的內(nèi)存受限問題一直是制約其對海量小文件存儲的關(guān)鍵因素,因此減少Name Node的內(nèi)存占用具有重要意義。HDFS設(shè)計建立在更多地響應(yīng)“一次寫入,多次讀出”任務(wù)的基礎(chǔ)之上,因此提高文件的讀取速率也至關(guān)重要。故從Name Node的內(nèi)存占用和文件讀取時間兩個方面進行測試和評估方案。這里把提出的方法和直接存儲HDFS方案進行比較。

        4.3 實驗結(jié)果

        Name Node內(nèi)存占用(MB/文件個數(shù))

        圖3 Name Node內(nèi)存占用

        圖3表示2種方案對不同數(shù)量的文件存儲時,Name Node內(nèi)存使用情況,文件數(shù)量由0、5000、10 000依次遞增至25 000。綠色線表明在對小文件不做任何處理直接存儲時,隨著小文件數(shù)目的增加,內(nèi)存占用量呈現(xiàn)線性增長趨勢。采用將VOL文件和二次產(chǎn)品Sequence File合并技術(shù)打包存儲極大地減少元數(shù)據(jù)的內(nèi)存占用,同時一次產(chǎn)品文件是存儲在HBase上的,節(jié)省了Name Node的內(nèi)存空間。

        讀操作(s/文件個數(shù))

        圖4 讀取時間

        由于氣象數(shù)據(jù)在存儲和調(diào)用時多數(shù)時間操作時間連續(xù)的那些文件,所以分別測試時間連續(xù)的50 000~250 000個文件。而在存儲方案中把一次產(chǎn)品和其他產(chǎn)品文件采用兩種不同的方式存儲,在測試讀取時間時需要分別討論。分別將HBase和sequence File訪問時間與直接HDFS讀取時間比較。測試結(jié)果表明,HBase對一次產(chǎn)品文件的響應(yīng)時間遠小于直接從HDFS讀取氣象文件的時間。而對氣象雷達數(shù)據(jù)的操作頻繁牽涉到對一次產(chǎn)品文件的訪問,HBase提供實時操作服務(wù),極大地提升文件的訪問速率,節(jié)省了文件的讀取時間。

        5 結(jié)束語

        針對氣象雷達數(shù)據(jù)的特征,先把每個產(chǎn)品文件采用壓縮方式存儲,壓縮后每個產(chǎn)品文件大小為幾KB到幾百KB,節(jié)省了Data Node的內(nèi)存空間。由于每個體掃中的一次產(chǎn)品文件對數(shù)據(jù)處理的實時性要求比較高,針對這些特殊原因,在存儲時選擇HBase,它提供實時計算,處理速度非??臁2捎脮r間+產(chǎn)品參數(shù)的行主鍵設(shè)計方案,利用隨機散列與預(yù)分區(qū)保證負載均衡,最終提高一次產(chǎn)品文件的讀取效率。

        此外,一個體掃周期除了生成ZVW一次產(chǎn)品文件,還生成一個VOL文件和根據(jù)需要計算生成多個二次產(chǎn)品,對系統(tǒng)的實時性要求不高,而且大小通常為幾十到幾百KB。對于這些文件直接存儲在HBase上加重其負擔,同時HBase更適合處理幾十KB的文件,文件過大降低其處理速度,所以利用Hadoop自身提供的Sequence File技術(shù)先小文件合并為大文件,Name Node中只需要存儲合并后的文件元數(shù)據(jù),節(jié)省Name Node的內(nèi)存空間。

        HBase不支持輔助索引,但在氣象數(shù)據(jù)檢索時效性上仍需要使用輔助索引[17],在接下來的工作中,將考慮設(shè)計適合氣象數(shù)據(jù)的輔助索引模塊;同時對 Sequence File中的VOL和二次產(chǎn)品文件設(shè)計索引和查找算法,以提高其查找速度。

        [1] 伍志方,曾沁,易愛民,等.短時大暴雨的多普勒雷達探測及暴雨預(yù)警信號發(fā)布[J].災(zāi)害學,2006,21(2):59-63.

        [2] 陳東輝,曾樂,梁中軍,等.基于HBase的氣象地面分鐘數(shù)據(jù)分布式存儲系統(tǒng)[J].計算機應(yīng)用,2014,34(9):2617-2621.

        [3] Shvachko K,Kuang H,Radia S,et al.The Hadoop Distributed File System[C].In:IEEE 26th symposium on mass storage systems and technologies(MSST).IEEE;2010:1-10.

        [4] Jilan Chen,Dan Wang,Lihua Fu,et al.An Improved Small File Processing Method for HDFS[C].International Journal of Digital Content Technology and its Applications(JDCTA).2012,(6):200-205.

        [5] Tom White.The Smal Files Problem[EB/OL].Http://www.clouder.com/blog/2009/02/02/the small files problem/.

        [6] Tom White.The Smal Files Problem[EB/OL].Http://issues.apache.org/jira/browse/Hadoop-1687.

        [7] Bo Dong,QinghuaZheng,F(xiàn)engTian,et al.An optimized approach for storing and accessing small files on cloud storage[C].elsevier.2012,(6):1847-1862.

        [8] Chatuporn,Vorapongkitipun,Natamut,Nupairoj.Improving Performance of Small File Aceessing[C].International Joint Conference on Computer Science and Software Engineering(JCSSE)2014(11):200-205.

        [9] 趙曉勇,楊揚,孫莉莉,等.基于Hadoop的海量MP3文件存儲架構(gòu)[J].計算機應(yīng)用,2012,6(1):1724-1726.

        [10] K P Jayakar,Y B Gurav.Managing Small Size Files through Indexing in Extended Hadoop File System[C].International Journal of Advance Research in Computer Science and Management Studies.2014,8(8):161-167.

        [11] Liu X,Han J,Zhong Y,et al.Implementing webgis on hadoop:a case study of improving small file i/o performance on hdfs.[C]In:IEEE international conference on cluster computing and workshops,2009,12,(1):1-4.

        [12] BoDong,Qiu Jie,Qinghua Zheng,et al.A novel approach to improving the efficiency of storing and accessing small files on hadoop:a case study by Power Point files[C].Proceedings of the 7th Int ernational Conference on Services Computing.Piscataw ay,N J,USA:IEEE,2010:65-72.

        [13] Xiayu Hua,Hao Wu,Zheng Li,et al.Enhancing throughput of the Hadoop Distributed File System for interaction-intensive tasks[C].2014:2770-2779.

        [14] 余思,桂小林,黃汝維,等.一種提高云存儲中小文件存儲效率的方案[J].西安大學報,2011,45(6):60-63.

        [15] Ganggang Zhang,Min Zuo,Xinliang Liu,et al.Improving the efficiency of storing SNS small files in HDFS[C].CCIS 426.2014:154-160.

        [16] 薛勝軍,刪寅.基于Hadoop的氣象信息數(shù)據(jù)倉庫建立與測試.計算機測量與控制[J].2012,20(4):926-928.

        [17] Chen P,AN J.The key as dictionary compression method of inverted index table under the HBase database[J].Journal of Software,2013,8(5):1086-1093.

        猜你喜歡
        海量內(nèi)存氣象
        氣象
        一種傅里葉域海量數(shù)據(jù)高速譜聚類方法
        氣象樹
        《內(nèi)蒙古氣象》征稿簡則
        海量快遞垃圾正在“圍城”——“綠色快遞”勢在必行
        當代陜西(2019年14期)2019-08-26 09:42:00
        “春夏秋冬”的內(nèi)存
        當代陜西(2019年13期)2019-08-20 03:54:22
        大國氣象
        一個圖形所蘊含的“海量”巧題
        基于內(nèi)存的地理信息訪問技術(shù)
        基于文件系統(tǒng)的分布式海量空間數(shù)據(jù)高效存儲與組織研究
        中文字幕久久熟女人妻av免费| 亚洲av成人无码网站大全| 放荡的闷骚娇妻h| 国产高清在线91福利| 国产三级韩三级日产三级| 邻居少妇张开腿让我爽了一夜| 亚洲精品午睡沙发系列| 91短视频在线观看免费| 台湾无码av一区二区三区| 国产欧美精品在线一区二区三区| 精品国产免费Av无码久久久| 久久精品国产亚洲av蜜桃av| 国产偷闻女邻居av在线观看| 久久久久99人妻一区二区三区| 国产人妻久久精品二区三区特黄| 免费看一级a女人自慰免费| 日本高清色一区二区三区| 丝袜美腿福利视频在线| 欧美黑寡妇特a级做爰| 女人与牲口性恔配视频免费| 特黄三级一区二区三区| 亚洲国产精品婷婷久久| 曰韩亚洲av人人夜夜澡人人爽| 国内免费AV网站在线观看| 国产日产免费在线视频| 美女露出自己的性感大胸一尤内衣 | 免费福利视频二区三区| 久久99天堂av亚洲av| 国产成人无码免费视频在线| 无尽动漫性视频╳╳╳3d| 西西人体大胆视频无码| 青青久在线视频免费视频| 国产极品少妇一区二区| 美女视频黄的全免费视频网站 | 亚洲综合区图片小说区| 日本a在线播放| 久久狼人国产综合精品| 国产乱妇无乱码大黄aa片| 国产AV无码专区亚洲AⅤ| 大屁股流白浆一区二区| 日本不卡高字幕在线2019|