欧美精品久久一区,黄色片在线播放,成人一二三区视频

mysql超時(shí)設(shè)置的問題

ivaneeo — Tue, 06 Nov 2012 08:29:00 GMT

com.mysql.jdbc.CommunicationsException: The last packet successfully received from the server was58129 seconds ago.The last packet sent successfully to the server was 58129 seconds ago, which is longer than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection property 'autoReconnect=true' to avoid this problem.

查了一下，原來是mysql超時(shí)設(shè)置的問題
如果連接閑置8小時(shí) (8小時(shí)內(nèi)沒有進(jìn)行數(shù)據(jù)庫操作), mysql就會(huì)自動(dòng)斷開連接, 要重啟tomcat.

解決辦法：

一種. 如果不用hibernate的話, 則在　connection url中加參數(shù): autoReconnect=true

jdbc.url=jdbc:mysql://ipaddress:3306/database?autoReconnect=true&autoReconnectForPools=true

    二種。用hibernate的話, 加如下屬性:
        true
        true
        true

    三。要是還用c3p0連接池:
        1
        0
        0
        true

　四。最不好的解決方案

使用Connector/J連接MySQL數(shù)據(jù)庫，程序運(yùn)行較長時(shí)間后就會(huì)報(bào)以下錯(cuò)誤：

Communications link failure，The last packet successfully received from the server was *** millisecond ago.The last packet successfully sent to the server was *** millisecond ago。

其中錯(cuò)誤還會(huì)提示你修改wait_timeout或是使用Connector/J的autoReconnect屬性避免該錯(cuò)誤。

后來查了一些資料，才發(fā)現(xiàn)遇到這個(gè)問題的人還真不少，大部分都是使用連接池方式時(shí)才會(huì)出現(xiàn)這個(gè)問題，短連接應(yīng)該很難出現(xiàn)這個(gè)問題。這個(gè)問題的原因：

MySQL服務(wù)器默認(rèn)的“wait_timeout”是28800秒即8小時(shí)，意味著如果一個(gè)連接的空閑時(shí)間超過8個(gè)小時(shí)，MySQL將自動(dòng)斷開該連接，而連接池卻認(rèn)為該連接還是有效的(因?yàn)椴⑽葱ｒ?yàn)連接的有效性)，當(dāng)應(yīng)用申請(qǐng)使用該連接時(shí)，就會(huì)導(dǎo)致上面的報(bào)錯(cuò)。

1.按照錯(cuò)誤的提示，可以在JDBC URL中使用autoReconnect屬性，實(shí)際測試時(shí)使用了autoReconnect=true& failOverReadOnly=false，不過并未起作用，使用的是5.1版本，可能真像網(wǎng)上所說的只對(duì)4之前的版本有效。

2.沒辦法，只能修改MySQL的參數(shù)了，wait_timeout最大為31536000即1年，在my.cnf中加入：

[mysqld]

wait_timeout=31536000

interactive_timeout=31536000

重啟生效，需要同時(shí)修改這兩個(gè)參數(shù)

ivaneeo 2012-11-06 16:29 發(fā)表評(píng)論

Hive與HBase的整合

ivaneeo — Mon, 10 Jan 2011 07:22:00 GMT

開場白：
Hive與HBase的整合功能的實(shí)現(xiàn)是利用兩者本身對(duì)外的API接口互相進(jìn)行通信，相互通信主要是依靠hive_hbase-handler.jar工具類 (Hive Storage Handlers)，大致意思如圖所示：

口水：
對(duì) hive_hbase-handler.jar 這個(gè)東東還有點(diǎn)興趣，有空來磋磨一下。

一、2個(gè)注意事項(xiàng)：
1、需要的軟件有 Hadoop、Hive、Hbase、Zookeeper，Hive與HBase的整合對(duì)Hive的版本有要求，所以不要下載.0.6.0以前的老版本，Hive.0.6.0的版本才支持與HBase對(duì)接，因此在Hive的lib目錄下可以看見多了hive_hbase-handler.jar這個(gè)jar包，他是Hive擴(kuò)展存儲(chǔ)的Handler ，HBase 建議使用 0.20.6的版本，這次我沒有啟動(dòng)HDFS的集群環(huán)境，本次所有測試環(huán)境都在一臺(tái)機(jī)器上。

2、運(yùn)行Hive時(shí)，也許會(huì)出現(xiàn)如下錯(cuò)誤，表示你的JVM分配的空間不夠，錯(cuò)誤信息如下：
Invalid maximum heap size: -Xmx4096m
The specified size exceeds the maximum representable size.
Could not create the Java virtual machine.

解決方法：
/work/hive/bin/ext# vim util/execHiveCmd.sh 文件中第33行
修改，
HADOOP_HEAPSIZE=4096
為
HADOOP_HEAPSIZE=256

另外，在 /etc/profile/ 加入 export $HIVE_HOME=/work/hive

二、啟動(dòng)運(yùn)行環(huán)境
1啟動(dòng)Hive
hive –auxpath /work/hive/lib/hive_hbase-handler.jar,/work/hive/lib/hbase-0.20.3.jar,/work/hive/lib/zookeeper-3.2.2.jar -hiveconf hbase.master=127.0.0.1:60000
加載 Hive需要的工具類，并且指向HBase的master服務(wù)器地址，我的HBase master服務(wù)器和Hive運(yùn)行在同一臺(tái)機(jī)器，所以我指向本地。

2啟動(dòng)HBase
/work/hbase/bin/hbase master start

3啟動(dòng)Zookeeper
/work/zookeeper/bin/zkServer.sh start

三、執(zhí)行
在Hive中創(chuàng)建一張表，相互關(guān)聯(lián)的表
CREATE TABLE hbase_table_1(key int, value string) STORED BY 'org.apache.hadoop.hive.hbase.HBaseStorageHandler' WITH SERDEPROPERTIES ("hbase.columns.mapping" = ":key,cf1:val") TBLPROPERTIES ("hbase.table.name" = "xyz");

在運(yùn)行一個(gè)在Hive中建表語句，并且將數(shù)據(jù)導(dǎo)入
建表
CREATE TABLE pokes (foo INT, bar STRING);
數(shù)據(jù)導(dǎo)入
LOAD DATA LOCAL INPATH '/work/hive/examples/files/kv1.txt' OVERWRITE INTO TABLE pokes;

在Hive與HBase關(guān)聯(lián)的表中插入一條數(shù)據(jù)
INSERT OVERWRITE TABLE hbase_table_1 SELECT * FROM pokes WHERE foo=98;
運(yùn)行成功后，如圖所示：

插入數(shù)據(jù)時(shí)采用了MapReduce的策略算法，并且同時(shí)向HBase寫入，如圖所示：

在HBase shell中運(yùn)行 scan 'xyz' 和describe "xyz" 命令，查看表結(jié)構(gòu)，運(yùn)行結(jié)果如圖所示：

xyz是通過Hive在Hbase中創(chuàng)建的表，剛剛在Hive的建表語句中指定了映射的屬性 "hbase.columns.mapping" = ":key,cf1:val" 和在HBase中建表的名稱 "hbase.table.name" = "xyz"

在hbase在運(yùn)行put命令，插入一條記錄
put 'xyz','10001','cf1:val','www.javabloger.com'

在hive上運(yùn)行查詢語句，看看剛剛在hbase中插入的數(shù)據(jù)有沒有同步過來，
select * from hbase_table_1 WHERE key=10001;
如圖所示：

最終的效果
   以上整合過程和操作步驟已經(jīng)執(zhí)行完畢，現(xiàn)在Hive中添加記錄HBase中有記錄添加，同樣你在HBase中添加記錄Hive中也會(huì)添加，表示Hive與HBase整合成功，對(duì)海量級(jí)別的數(shù)據(jù)我們是不是可以在HBase寫入，在Hive中查詢喃？因?yàn)?span style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 0px; ">HBase 不支持復(fù)雜的查詢，但是HBase可以作為基于 key 獲取一行或多行數(shù)據(jù)，或者掃描數(shù)據(jù)區(qū)間，以及過濾操作。而復(fù)雜的查詢可以讓Hive來完成，一個(gè)作為存儲(chǔ)的入口(HBase)，一個(gè)作為查詢的入口(Hive)。如下圖示。


   呵呵，見笑了，以上只是我面片的觀點(diǎn)。

先這樣，稍后我將繼續(xù)更新，感謝你的閱讀。

相關(guān)文章：
Apache Hive入門2
Apache Hive入門1

HBase入門篇4
HBase入門篇3
HBase入門篇2
HBase入門篇

–end–

豆瓣讀書 向你推薦有關(guān) HBase、 Hadoop、 Hive、 MapReduce、云計(jì)算、架構(gòu)設(shè)計(jì)、類別的圖書。

ivaneeo 2011-01-10 15:22 發(fā)表評(píng)論

Facebook的新實(shí)時(shí)消息系統(tǒng)：Hbase——每月存儲(chǔ)1350+億條消息

ivaneeo — Mon, 10 Jan 2011 06:57:00 GMT

Facebook的新實(shí)時(shí)消息系統(tǒng)：Hbase——每月存儲(chǔ)1350億條消息

你或許已經(jīng)知道，facebook已經(jīng)介紹過全新的social inbox產(chǎn)品，集成了email，IM，短信，文本信息，facebook的在線消息。最為重要的是，他們每個(gè)月要存儲(chǔ)超過1350億條消息。他們?nèi)绾未娣胚@些信息呢？facebook的Kannan Muthukkaruppan在《郵件的底層技術(shù)：HBase》一文中給了一個(gè)十分意外的答案——HBase，打敗了MySQL，Cassandra和其他一些技術(shù)，成為facebook的選擇。

為什么說是一個(gè)意外的答案？facebook創(chuàng)造了Cassandra，并且其就是為郵件類型的應(yīng)用而打造的，但是他們發(fā)現(xiàn)Cassandra的最終一致性模型并不適合他們的全新的實(shí)時(shí)郵件產(chǎn)品。Facebook同樣擁有大量的MySQL架構(gòu)，但是他們發(fā)現(xiàn)性能會(huì)隨著數(shù)據(jù)和索引的增加變差。他們同樣可以選擇自己來開發(fā)一個(gè)新的存儲(chǔ)模型，但是他們最終選擇了HBase。

HBase是一個(gè)可擴(kuò)展的、并且支持海量數(shù)據(jù)下的高并發(fā)記錄級(jí)別更新操作的表存儲(chǔ)產(chǎn)品——為郵件系統(tǒng)量身定做。HBase同樣支持基于BigTable模型的key-value存儲(chǔ)。這樣能夠很好的支持按key來查找記錄以及按范圍來搜尋或者過濾，這也是郵件系統(tǒng)的特性之一。然而，復(fù)雜一點(diǎn)的查詢卻并不被支持。查詢是通過一個(gè)叫Hive的工具來進(jìn)行分析的，這是facebook創(chuàng)造的用以處理他們幾個(gè)P的數(shù)據(jù)倉庫的，Hive是基于Hadoop文件系統(tǒng)HDFS，這也是HBase所采用的文件系統(tǒng)。

Facebook檢視了他們的應(yīng)用場景，指出他們?yōu)槭裁匆x擇HBase。他們所需要的系統(tǒng)應(yīng)該能處理以下兩種數(shù)據(jù)：

一個(gè)較小的臨時(shí)數(shù)據(jù)集，是經(jīng)常變化的。
一個(gè)不斷增加的數(shù)據(jù)集，是很少被訪問的。

有點(diǎn)意思哈。你閱讀了收件箱里的郵件，以后就很少再去看它一眼了。這兩種截然不同的數(shù)據(jù)使用方式，你可能會(huì)用兩個(gè)系統(tǒng)來實(shí)現(xiàn)。但是顯然HBase就能搞定這一切。目前尚不清楚它是如何（在兩種數(shù)據(jù)集上）來實(shí)現(xiàn)通用的搜索功能的，盡管它集成了多種搜索引擎。

他們系統(tǒng)的一些關(guān)鍵特性：

·HBase：

·擁有一個(gè)比Cassandra更簡答的一致性模型。

·非常好的可伸縮性和性能。

·大多數(shù)特性對(duì)他們的需求來說是足足有余的：自動(dòng)負(fù)載平衡和故障轉(zhuǎn)移，支持壓縮，單機(jī)多個(gè)切片（multiple shards）。

·HDFS是HBase使用的文件系統(tǒng)，支持冗余復(fù)制，端到端的校驗(yàn)以及自動(dòng)恢復(fù)平衡。

·facebook的運(yùn)維團(tuán)隊(duì)在使用HDFS方面有豐富的經(jīng)驗(yàn)，他們是Hadoop的大客戶，Hadoop就是使用HDFS作為分布式文件系統(tǒng)的。

·Haystack用來做為存儲(chǔ)附件用的。

·重頭開始寫了一個(gè)自定義的應(yīng)用server，以便處理大量來自不同源的消息。

·在ZooKeeper的頂層實(shí)現(xiàn)了一個(gè)“用戶發(fā)現(xiàn)服務(wù)”。

·使用了一系列的基礎(chǔ)服務(wù)：email帳戶驗(yàn)證，好友關(guān)系鏈，隱私控制，消息傳送控制（消息是通過chat系統(tǒng)發(fā)送還是通過短信系統(tǒng)發(fā)送）。

·保持了他們一貫的作風(fēng)，小團(tuán)隊(duì)做出令人驚訝的事情：15個(gè)工程師花了1年的時(shí)間發(fā)布了20個(gè)新的基礎(chǔ)服務(wù)。

·facebook不打算只使用一個(gè)數(shù)據(jù)庫平臺(tái)并在這之上實(shí)現(xiàn)標(biāo)準(zhǔn)化應(yīng)用，他們會(huì)針對(duì)不同的應(yīng)用使用不同的平臺(tái)。

Facebook在HDFS/Hadoop/Hive上有了豐富的經(jīng)驗(yàn)，并且成為HBase的大客戶，這讓我夜不能寐。與一個(gè)十分流行的產(chǎn)品合作并成為其產(chǎn)業(yè)鏈的一部分是所有產(chǎn)品的夢(mèng)想。這正是HBase所得到的。由于HBase涵蓋了諸如持久性，實(shí)時(shí)性，分布式，線性擴(kuò)展，健壯性，海量數(shù)據(jù)，開源，key-value，列導(dǎo)向（column-oriented）等熱點(diǎn)。我們有理由相信它能變得更加流行，特別是基于它被facebook使用的事實(shí)。

（原文作者Todd Hoff，C++代碼規(guī)范的作者）

Posted by kaoshijuan on 2010 年 11 月 23 日 at 上午 9:22 under 未分類.
1 Comment.

ivaneeo 2011-01-10 14:57 發(fā)表評(píng)論

informatica重點(diǎn)

ivaneeo — Thu, 19 Apr 2007 07:43:00 GMT

1.
    Transformation代表Informatica Server對(duì)數(shù)據(jù)的操作。
    Transformation分類：Active和Passive
       輸入跟輸出的記錄數(shù)會(huì)發(fā)生改變
       不能re-linked到另一個(gè)data stream
       例子：Aggregator, Filter, Joiner, Normalizer, Rank, Update Strategy, Advanced External Procedure,
        ERP Source Qualifier and Source Qualifier, Application Source Qualifier, Router, Sorter
    Passive transformations
       輸入跟輸出的記錄數(shù)一樣
       可以re-linked到另一個(gè)data stream
        例子：Expression, External Procedure, Lookup, Sequence Generator Stored Procedure, Input,
Output, XML Source Qualifier
    Transformations分類 : connected 和 unconnected,unconnected transformation在其他的組件中被調(diào)用并且有返回值。

ivaneeo 2007-04-19 15:43 發(fā)表評(píng)論

數(shù)據(jù)的清洗轉(zhuǎn)換

ivaneeo — Wed, 18 Apr 2007 01:12:00 GMT

ETL的簡介：

ETL即數(shù)據(jù)抽取（Extract）、轉(zhuǎn)換（Transform）、裝載（Load）的過程，它是構(gòu)建數(shù)據(jù)倉庫的重要環(huán)節(jié)

1、數(shù)據(jù)清洗

數(shù)據(jù)清洗的任務(wù)是過濾那些不符合要求的數(shù)據(jù)，將過濾的結(jié)果交給業(yè)務(wù)主管部門，確認(rèn)是否過濾掉還是由業(yè)務(wù)單位修正之后再進(jìn)行抽取。不符合要求的數(shù)據(jù)主要是有不完整的數(shù)據(jù)、錯(cuò)誤的數(shù)據(jù)、重復(fù)的數(shù)據(jù)三大類。

　　(1)不完整的數(shù)據(jù)：這一類數(shù)據(jù)主要是一些應(yīng)該有的信息缺失，如供應(yīng)商的名稱、分公司的名稱、客戶的區(qū)域信息缺失、業(yè)務(wù)系統(tǒng)中主表與明細(xì)表不能匹配等。對(duì)于這一類數(shù)據(jù)過濾出來，按缺失的內(nèi)容分別寫入不同Excel文件向客戶提交，要求在規(guī)定的時(shí)間內(nèi)補(bǔ)全。補(bǔ)全后才寫入數(shù)據(jù)倉庫。

　　(2)錯(cuò)誤的數(shù)據(jù)：這一類錯(cuò)誤產(chǎn)生的原因是業(yè)務(wù)系統(tǒng)不夠健全，在接收輸入后沒有進(jìn)行判斷直接寫入后臺(tái)數(shù)據(jù)庫造成的，比如數(shù)值數(shù)據(jù)輸成全角數(shù)字字符、字符串?dāng)?shù)據(jù)后面有一個(gè)回車操作、日期格式不正確、日期越界等。這一類數(shù)據(jù)也要分類，對(duì)于類似于全角字符、數(shù)據(jù)前后有不可見字符的問題，只能通過寫 SQL語句的方式找出來，然后要求客戶在業(yè)務(wù)系統(tǒng)修正之后抽取。日期格式不正確的或者是日期越界的這一類錯(cuò)誤會(huì)導(dǎo)致ETL運(yùn)行失敗，這一類錯(cuò)誤需要去業(yè)務(wù) 系統(tǒng)數(shù)據(jù)庫用SQL的方式挑出來，交給業(yè)務(wù)主管部門要求限期修正，修正之后再抽取。

　　(3)重復(fù)的數(shù)據(jù)：對(duì)于這一類數(shù)據(jù)——特別是維表中會(huì)出現(xiàn)這種情況——將重復(fù)數(shù)據(jù)記錄的所有字段導(dǎo)出來，讓客戶確認(rèn)并整理。

　　數(shù)據(jù)清洗是一個(gè)反復(fù)的過程，不可能在幾天內(nèi)完成，只有不斷的發(fā)現(xiàn)問題，解決問題。對(duì)于是否過濾，是否修正一般要求客戶確認(rèn)，對(duì)于過濾掉的數(shù)據(jù)，寫入Excel文件或者將過濾數(shù)據(jù)寫入數(shù)據(jù)表，在ETL開發(fā)的初期可以每天向業(yè)務(wù)單位發(fā)送過濾數(shù)據(jù)的郵件，促使他們盡快地修正錯(cuò)誤,同時(shí)也可以做為將來驗(yàn) 證數(shù)據(jù)的依據(jù)。數(shù)據(jù)清洗需要注意的是不要將有用的數(shù)據(jù)過濾掉，對(duì)于每個(gè)過濾規(guī)則認(rèn)真進(jìn)行驗(yàn)證，并要用戶確認(rèn)。

2、數(shù)據(jù)轉(zhuǎn)換

數(shù)據(jù)轉(zhuǎn)換的任務(wù)主要進(jìn)行不一致的數(shù)據(jù)轉(zhuǎn)換、數(shù)據(jù)粒度的轉(zhuǎn)換，以及一些商務(wù)規(guī)則的計(jì)算。

　　(1)不一致數(shù)據(jù)轉(zhuǎn)換：這個(gè)過程是一個(gè)整合的過程，將不同業(yè)務(wù)系統(tǒng)的相同類型的數(shù)據(jù)統(tǒng)一，比如同一個(gè)供應(yīng)商在結(jié)算系統(tǒng)的編碼是XX0001,而在CRM中編碼是YY0001，這樣在抽取過來之后統(tǒng)一轉(zhuǎn)換成一個(gè)編碼。

　　(2)數(shù)據(jù)粒度的轉(zhuǎn)換：業(yè)務(wù)系統(tǒng)一般存儲(chǔ)非常明細(xì)的數(shù)據(jù)，而數(shù)據(jù)倉庫中數(shù)據(jù)是用來分析的，不需要非常明細(xì)的數(shù)據(jù)。一般情況下，會(huì)將業(yè)務(wù)系統(tǒng)數(shù)據(jù)按照數(shù)據(jù)倉庫粒度進(jìn)行聚合。

　　(3)商務(wù)規(guī)則的計(jì)算：不同的企業(yè)有不同的業(yè)務(wù)規(guī)則、不同的數(shù)據(jù)指標(biāo)，這些指標(biāo)有的時(shí)候不是簡單的加加減減就能完成，這個(gè)時(shí)候需要在ETL中將這些數(shù)據(jù)指標(biāo)計(jì)算好了之后存儲(chǔ)在數(shù)據(jù)倉庫中，以供分析使用。

三、ETL日志、警告發(fā)送

1、 ETL日志

　　ETL日志分為三類。一類是執(zhí)行過程日志，這一部分日志是在ETL執(zhí)行過程中每執(zhí)行一步的記錄，記錄每次運(yùn)行每一步驟的起始時(shí)間，影響了多少行數(shù)據(jù)，流水賬形式。一類是錯(cuò)誤日志，當(dāng)某個(gè)模塊出錯(cuò)的時(shí)候?qū)戝e(cuò)誤日志，記錄每次出錯(cuò)的時(shí)間、出錯(cuò)的模塊以及出錯(cuò)的信息等。第三類日志是總體日志，只記錄 ETL開始時(shí)間、結(jié)束時(shí)間是否成功信息。如果使用ETL工具,ETL工具會(huì)自動(dòng)產(chǎn)生一些日志，這一類日志也可以作為ETL日志的一部分。記錄日志的目的是隨時(shí)可以知道ETL運(yùn)行情況，如果出錯(cuò)了，可以知道哪里出錯(cuò)。

　　2、警告發(fā)送

　　如果ETL出錯(cuò)了，不僅要形成ETL出錯(cuò)日志，而且要向系統(tǒng)管理員發(fā)送警告。發(fā)送警告的方式多種，一般常用的就是給系統(tǒng)管理員發(fā)送郵件，并附上出錯(cuò)的信息，方便管理員排查錯(cuò)誤。

　　ETL是BI項(xiàng)目的關(guān)鍵部分，也是一個(gè)長期的過程，只有不斷的發(fā)現(xiàn)問題并解決問題，才能使ETL運(yùn)行效率更高，為BI項(xiàng)目后期開發(fā)提供準(zhǔn)確的數(shù)據(jù)。

ivaneeo 2007-04-18 09:12 發(fā)表評(píng)論