Saturday, February 21, 2009
Monday, February 9, 2009
用 java 将文件的编码从GBK 转换成 UTF8
private static void transferFile(String srcFileName, String destFileName) throws IOException {
String line_separator = System.getProperty("line.separator");
FileInputStream fis = new FileInputStream(srcFileName);
StringBuffer content = new StringBuffer();
DataInputStream in = new DataInputStream(fis);
BufferedReader d = new BufferedReader(new InputStreamReader(in, "GBK"));// , "UTF-8"
String line = null;
while ((line = d.readLine()) != null)
content.append(line + line_separator);
d.close();
in.close();
fis.close();
Writer ow = new OutputStreamWriter(new FileOutputStream(destFileName), "utf-8");
ow.write(content.toString());
ow.close();
}
将一个GBK编码的文件转成UTF8 编码的文件，有兴趣的话，你可以试下
不知道为什么, 用 ultraEdit 以二进制查看生成的文件时，文件头部并没有以 EF BB BF 开头，但是以 windows 记事本打开后，另存为，可以发现其为 utf8 的． 我的 eclipse 的工作区的编码是 utf-8的，转换前，打开A.java 是乱码，转换后就可以正常显示了．
如果你觉得有什么问题，可以联系我，一起讨论下.....
//参考了 字符，字节和编码 http://www.regexlab.com/zh/encoding.htm
................
我也想去自动检测文件编码类型，网上找了下，有个jar包可以搞定，还没仔细去看
我的数据库学习“曲线”收藏
■ 文／牛新庄
编者按：牛新庄，数据库维护、优化和架构专家；曾获得国内数据库领域最高荣誉——“2006年中国首届杰出数据库工程师”； 数年前曾被IBM全球软件部以年薪60万元人民币聘用，而他却婉然拒绝。这样一个躲藏在幕后的“牛人”，有着怎样的学习、发展之路？为此，本刊特邀牛新庄博士，请他讲述一个真实版的“数据库之路”。
选定发展方向
1999年，我在开始读研时就给自己确定了以后的发展方向。
当时有两个方向：网络，数据库技术。因为在2000年之时，网络大热，市场上拥有CCNP、CCIE证书的人特别牛。所以我当时也考下了CCNP证书，但后来发现网络方向涉及很多硬件层面的东西，这些都对厂商的依赖性太强，个人发挥空间不大。而我喜欢钻研，所以慢慢开始转向专攻数据库技术。
在认准数据库这个方向后，我开始深入学习数据库理论方面的知识。当时，人大王珊教授的《数据库系统原理教程》一书，我读了几十遍。在学习数据库理论的同时，我开始接触并深入学习DB2和Oracle，并从1999年开始使用DB2 V5.2。那时，市场上关于DB2方面的技术书籍几乎没有，互联网也不像现在这么发达。因为我的导师做一个课题需要用到DB2数据库，但是我只能依靠查看DB2随机文档来学习。那时，我还自己兼职，通过帮别人做些小软件赚钱，外加课题经费，以支付考OCP认证和DB2认证的费用。
到现在为止，我一直认为考认证是一个很好的学习动力。因为考试费用不菲，如果不想浪费钱只能拼命看书。我在读研的2000年就通过了OCP 8i认证，后来又陆续通过DB2 V5.2认证。这些认证极大地增强了我的自信。同时，在帮助导师用PB、Delphi等编程工具做应用开发时，我有意识地增强对SQL的学习，这对我后来的性能调优工作非常有帮助。
这里我想说的是，做好一个时期的人生规划非常重要。我们首先要有一个明确的努力方向和规划，然后有意识的往这个方向努力。这种积极主动的学习要比被动学习效率高很多。
第一次做培训
“机遇偏爱于有准备的头脑”，这句话虽是老生常谈，却是人生真谛。记得2000年底，我在网上看到一个帖子说需要一个人去安装DB2数据库，差旅报销，每天500元，我喜出望外。因为这项工作需要有DB2认证才能去，而我那时DB2高级系统管理和应用开发的认证都有，所以很快就通过了对方的审核。但是当我到客户现场时才发现，不是安装DB2而是要给客户讲课，当时我就傻眼了，因为讲课需要的知识远比安装配置数据库要难得多，更何况我之前根本没有讲过课。没办法，压力也是动力，只能前一天夜里看教材备课到凌晨5点。短短睡了两个小时后，8点半去讲课。四天讲课下来，我总共休息了12个小时。还好自己毕竟有DB2应用开发经验和DB2认证做基础，总算勉强应付了过去。只是没想到的是，这次并不算顺利的培训，竟是我未来几年培训生涯的开始。
将培训当学习的动力
经过第一次讲课后，我看到了自己的差距，知道仅有认证是不够的。客户的很多问题，书本上没有答案，需要自己在实践经验上做努力。另外，讲课前讲师需要把一些原理、概念性的东西弄清楚，也需要对数据库进行深入学习。
后来，IBM培训部通过一些渠道知道我能讲DB2且拥有相关证书，就找我讲授DB2系列课程。所以，从2001年开始，我就经常作为IBM官方讲师讲授DB2系列的所有课程。我自认为讲课是一个很好的学习过程，因为课前要深入了解概念，对于自己的理论深入学习有很大帮助。同时，课堂上学员的实际操作问题也会强迫自己做更深入的研究。
我对培训有这样的认识：学员听你讲三个小时，要远远胜过自己看3小时的书。如果把一堂课的内容比喻成一杯水，那老师至少应该提前储备一桶水。所以，在讲课之前，我精心准备实验，深入和学员交流。我讲课从不照本宣科，而是自己准备了很多教材外比较实用的知识来扩展教材内容。同时争取上课过程中把一些概念用浅显易懂的例子来讲解。要想做到这些，首先自己必须对这个概念有深刻的理解才行，这一切都在客观上促进了自己的学习。
随着培训的增多，有部分客户开始找我做实际的调优工作。记得我第一次去为客户现场调优是2001年，去大连大通证券解决锁等待问题。客户环境用的是AIX和CICS。当时虽然问题解决了，但自己心里还是比较虚，因为对AIX和CICS不了解，万一是这两个方面有问题，自己就没办法搞定了；这让我认识到一个复杂系统的调整往往需要具备多方面的知识。这件事之后，我在网上买了一个140的IBM工作站小机，自己安装AIX并开始学习。
数据库学习Tips
根据我对数据库的理解，目前市场上虽然有Oracle，DB2，Informix，Sybase和SQL Server数据库，但Informix数据库已经被IBM收购，而Sybase数据库在技术和市场上正走向没落，占据市场主要份额的就是Oracle，DB2和SQL Server数据库。SQL Server数据库非常好，但是很遗憾的是只能在Windows平台使用。所以如果你深入研究SQL Server数据库，我只能说获取高薪的概率稍低，而且坦白的说，使用SQL Sever数据库的企业一般是中小企业居多。而国内做Oracle数据库的人太多，如果你想在Oracle领域出人头地，难度极大。但是，做DB2数据库的人反而不太多，物以稀为贵。况且，DB2数据库广泛应用在银行、电信、制造行业、零售行业、保险行业等“高薪”领域中，所以我强烈建议学习DB2数据库，做IBM技术一般获取高薪的概率相对会大一些。我们的时间精力是有限的，所以必须选择好方向然后努力为之。除了SQL Server，这几个数据库我都在使用，我个人感觉除了功能外，对于运行稳定而言，相对于Oracle不太稳定的优化器，DB2无疑是最稳定的，它的优化器无比强大。如果能在锁方面再有更先进的技术，那么DB2将是完美的。
这期间，我一边学习，一边通过了AIX的全部认证。记得非常清楚的是，为了做HA的实验，我花费了很大工夫。因为那时小型机不像今天这么普及，无法搞到7133阵列。后来我又学习了CICS、WebSphere、MQ和存储。就这样，在我培训的过程中，发现自己哪方面薄弱并且感觉这个方向有前途，我就会开始学习。不过，那时我的技术主要还是围绕IBM产品为主。由于自己对培训比较用心且颇受客户好评，找我做培训的国内培训机构开始变多。这个期间我自己的技术水平也增长很快。
2002年11月，我参加了首届 “IBM DeveloperWorksLive! China 2002”大会，并获得IBM首次在国内评选的“杰出软件技术专家”奖，当时在6名获奖者中名列第2。这个奖项客观上对我在客户群的拓展方面起到很大帮助。找我解决问题的人更多了，所以2002—2003年也成了我技术提升最快的两年。
这两年内，我陆续学习了HP-UX、WebSphere和MQ并通过认证。我自己的感觉是，如果你把一门技术研究得非常深、非常透，由于触类旁通的缘故，再去学习另一门技术时就很轻松。所以，我在学完AIX再去学习HP-UX时，感觉非常轻松。同样，在学习ORACLE和DB2后再去学习Informix也同样很容易。通过这种纵向的深入和横向的比较，各种产品的所长所短也会非常清楚，自己的技术视野无意间更加全面化。而且通过对一个产品的深入，你往往能够发现这个产品的缺点和需要改进的地方。就拿DB2来说，每次版本更新的新特性,在新版本未上市前我就可以猜得差不多了。这主要有三个原因：一是我贴近真实用户，了解他们的真正需求；二是自己一直在用且不断总结思考；三是这些特性别的数据库有，而DB2没有，那在下个版本就会增加。所以相对来说，我自身对新版本的新特性学习就非常轻松了。就DB2而言，我拥有DB2 V5.2 、V7.1、V8.1和DB2 V9的全部认证，而且我应该是国内第一个把DB2 V8认证全部通过的人，当然，这其中也有巧合的成分。
重要的一点是：学习过程中，要不断地把实践和理论融合，知其然更知其所以然，这样提升就会快很多。
现场救援“赶场”记
2004—2005年是我最忙碌的两年，那时候找我讲课的培训机构和需要性能调优的客户非常多，基本上整天在天上飞。培训机构找我讲课常常需要提前一个月预约。那两年内，除了过年几天，其他时间都是在做培训和诊断、调优，足迹遍及国内主要城市。我自己基本上是国内六大银行开发中心和数据中心培训的指定讲师，并为北京银信科技、山东农信、广东农信，交行大集中IBP等项目做数据库技术顾问。
那时的我年轻、精力充沛。记得最刺激的一次是2004年9月的一天，上午9点为上海移动IT部门做AIX动态逻辑分区（DLPAR）培训，结束时是17点。之后，立刻坐出租车前往扬州，于20点到达扬州供电局并协助他们进行电力负荷控制系统项目上线，一直奋战到凌晨3点半。接着，又连夜乘出租车赶往上海，在凌晨6点到达酒店。休息两小时后，8点出发，准时出现在上海移动培训现场。那时我对报酬不太在意，想的主要是用心积累技术经验和客户资源。在我看来，能够不断通过实践让自己成长是第一要义。而且，去的客户现场越多，处理的问题就越多，也就越多地发现自己的不足，然后再拼命学习，不断积累、总结和思考，进入了一个良性循环。
至今我仍然怀念那段充实、紧张而充满激情的光辉岁月。2004年和2005年，一方面因为以独立咨询顾问的个人身份无法出具发票；另一方面，项目越做越大，尤其是很多银行的数据库架构和维护项目涉及合同金额也越来越大，需要签订正式公司合同。于是，我就分别在上海、北京注册了公司。当然这些年我并非都是一帆风顺，也犯过一些重大错误，例如：我曾经在2002年5月1日把海南美兰机场的数据库调死，导致机场航班信息管理系统瘫痪。早期也曾经因为调整某证券系统宕机而影响股民交易，这些都对客户造成了影响，但这些都是成长必须要走的路。经过这两次事件后，我自己也思考、总结了很多，在之后的调优工作中我基本上再没有犯过错误。
我的秘诀：学习、积累、规划
2006年8月我获得“2006年中国首届杰出数据库工程师”称号，算是对我多年学习数据库的一个总结。自2007年开始，我专注于做一些大客户的运维工作，并相应减少了培训次数。2008年，我被建设银行以年薪217万聘请为资深技术专家来维护Oracle和Informix数据库。就做技术而言，以一己之力能挣到年薪几百万常常令我感到自豪，也让我感受到技术的魅力，觉得自己多年来对技术的钻研得到了认可。
之所以讲述我的技术之路，主要目的是给大家一些参考，尽可能多地去了解社会的需求，有意识给自己制定人生规划。我自己认为，多年来能取得这样的成绩，勤奋、努力和坚持一直是我最看重的。因为有了这些，才不至于当机遇光顾时，你却不知所措。
现在很多年轻人，恰恰缺少的就是这样的忘我与痴迷，在我熟悉的数据库技术领域，很多年轻人越来越早地将注意力集中在薪水和职位上，这是很不明智的行为。其实，往往那些将诸如高薪与职位忘怀的人反而能更快地取得成功。“不经一番寒彻骨，安得梅花扑鼻香？”这样的道理人人都懂，可能够真正去实践的人却并不多。结合我的学习经验与感悟，我总结有16字要诀：去除浮躁，认真学习，不断积累，寻找机遇。
最后，我用这句话与大家共勉：古之成大事者，不唯有超世之才，亦唯有坚韧不拔之志也！
作者简介：
牛新庄博士，研究方向为数据仓库和数据挖掘。是IBM官方资深培训讲师（培训DB2,AIX,MQ,WebSphere和CICS）。2002年获IBM杰出软件专家奖，2006年获“首届中国杰出数据库工程师奖”、“2006年IT168技术卓越奖”。是中信银行、山东农信、广东农信等公司资深技术顾问，中国建设银行总行特聘资深技术专家。拥有OCP，AIX，DB2，HP-UX，MQ，CICS和WebSphere等二十多项国际认证。著有《Oracle数据库开发讲座——Oracle9i Jdeveloper与J2EE实务应用》、《DB2应用开发实战指导》、《循序渐进DB2-系统管理、运行维护与应用案例》、《深入解析DB2-高级管理、内部体系结构与诊断案例》和《DB2性能调整与优化》等书。
（本文来自《程序员》杂志0901期）
Sunday, February 1, 2009
資料庫系統是榔頭; MapReduce 則是螺絲起子
最近年來不管是雲端運算(Cloud computing) 或是網格運算(Grid computing) 都相當的熱門, 而它們的核心技術 MapReduce 則受到相當程度的重視. 04 年時 MapReduce 一開始被 Google 所提出來, 它本身是一種程式開發的模式,可以用來處理大量的資料. 但因為長時間以來, 不管是在學校或是業界, 資料庫系統都廣泛的被教授和使用,很多人一看到"處理大量的資料", 自然的就會把 MapReduce 跟資料庫系統放在一起, 拿來做比較等等, 因而產生一些錯誤的認知.
目前任職在 Google 的 Mark 日前撰寫了一篇文章 Databases are hammers; MapReduce is a screwdriver 來說明這兩者的不同. 這篇文章是我個人認為目前在網路上說明 MapReduce 文章當中寫的最貼切且淺顯易懂的. 經過原作者的同意 , 我把它翻譯成中文, 希望讓更多人藉著閱讀這篇文章來了解 MapReduce.
資料庫系統是榔頭; MapReduce 則是螺絲起子.
有一群朋友們把一篇關於批評MapReduce的文章傳給我. 我曾經猶豫是否我應該寫些什麼, 因為目前為止有很多關於MapReduce的東西正被開發中, 而且被Google的同仁們廣泛的使用. 但是這篇文章真的是有點惱人, 我理當回應它. 所以我在這邊先做個澄清, 我並不是以一位Google員工的身份來評論它.(事實上, 我在工作上並沒有使用MapReduce). 這純粹是用我自己的時間, 發表我個人的意見. 如果您覺得這是一篇愚蠢的文章, 那是我個人的錯跟Google無關. 如果您覺得這篇文章寫的很出色, 那也是我個人的榮幸跟Google無關. Google 並沒有要求我寫這篇文章, 同樣的我也沒有要求 Google 的同意. 這僅只是我個人的行為, 了解嗎?
我會對這件事情有興趣的原因是因為這跟我的博士研究有關. 回想起研究所那時候, 我的研究是關於在非科學性的應用軟體上, 將平行運算的技術應用在結構化資料上.這差不多是 MapReduce 所要做的事情. 而我所提出的解決方案是某種階層式的分散(scatter)/收集(gather)運算子,非常接近 MapReduce 運作的方式. 那最大的差異在哪邊? 那就是 MapReduce 打敗了我, 設計MapReduce 的人注意到我沒注意到的東西, 並且利用了它使得 MapReduce 程式更乾淨, 更容易開發.
讓我們從頭開始, MapReduce 是啥, 它能做什麼?
今天假設你在工作, 你需要做某件事情, 但是它在你的電腦上會跑蠻久的時間, 你不想等但是你也不想要花幾百萬去買台超級電腦, 那你要怎樣才能夠讓它跑快一點? 有一個方法是買一群便宜的電腦, 讓它們同時一起幫你執行工作. 另一方面你也注意到辦公室內有很多台電腦, 幾乎每個員工座位上都有一台, 在某個時間點上大部分的電腦並沒有在做太多事情, 那為何不利用它們呢? 當你的機器不甚忙碌的時候, 你允許你的同事借用你當下並不在使用的資源, 當你需要的時候也可以借用他們的機器. 所以當你需要執行大的工作的時候, 你可以輕鬆的找到好幾打的機器來用.
這個方法最大的問題在於, 大部分的程式並沒撰寫成可以在多台的機器上執行的模式, 它們被寫成只能在一臺機器上執行. 而要把一件困難的工作分到很多台機器執行上是件困難的事情.
MapReduce 是一種程式語言開發模式, 它讓你可以透過撰寫特有的制式化程式, 輕鬆的把工作分散到一群機器上面去執行. 它基本的概念在於你把工作分成兩部份 Map 以及 Reduce. Map 基本上負責把問題分成好幾份並且送到不同的機器去,所以它們可以同時被處理. Reduce 則接收每份問題的處理的結果, 最後組合成單一的答案.
MapReduce 運作的關鍵在於, 把輸入的資料在概念上當成成一個包含很多筆紀錄的 list, 透過 map 這些紀錄被分配到不同的機器上去處理. map 計算的結果是一個包含許多 key/value 組的 list. Reduce 會取得同樣 key 值的所有 value, 並組合成為最後的單一 value. 也就是 Map 將資料產生成為 key/value 組, reduce 則組合結果給你單一的結果. 你無法知道這個工作是被分成100份或是2份, 而最後應該是跟只有單一 map 時候是一樣的. (這就是 MapReduce 和我博士研究方法不同的地方, 領悟到把結果當作是 key/value map 來看,你會得到非常乾淨且一致的歸納流程. 雖然我的 scatter/gather 模式是同樣的概念 , 但是我的 reduces 跟 Map/Reduce 比起來相對的醜陋許多.)
MapRedue 美麗的地方在於撰寫它是多麼的簡單, 在平行處理程式語言的領域上從來沒這麼簡單過.
回到該篇批評 MapReduce 的文章, 他們批評 MapRduce, 其實基本上並不是基於關聯式資料庫(Relational databaes) 的概念.
當我第一次花時間學習關聯式資料庫的時候, 我的老闆告訴我ㄧ個關於資料庫專家的故事, 是我認為最貼切的故事. 這個故事是說關聯式資料庫的專家們發現了這個世界上最美麗,最漂亮,最完美的榔頭, 完美到不會太重,也不會太輕,恰到好處的可以把釘子給釘進去,它的柄是根據所有者手的角度去特製化的, 所以釘一整天也不會起水泡.同時它也是裝飾的很漂亮的榔頭, 上面有寶石鑲嵌跟黃金的工飾在適當的地方, 絲毫不會減損榔頭的功能. 它真的是一個最偉大的榔頭.資料庫專家們熱愛他們的榔頭, 因為它是多麼美妙的工具. 而且他們真的利用這個工具做出許偉大的東西. 他們是如此的喜歡關聯式資料庫,以致於認為這是這是他們唯一需要的工具. 如果你給他們一個螺絲釘, 他們會把它當成釘子一樣的釘進去. 當你提醒他們說, 嘿這樣會弄壞東西 , 那是螺絲釘不是釘子, 他們會說"我知道阿, 但是我有這隻極好的榔頭 , 你不能期待我使用那鱉腳的小螺絲起子"
現況是這樣, 他們有關聯式資料庫, 關聯式資料庫絕對是個傑出的東西, 是個驚人的工具可以幫我們做出驚人的軟體. 我自己曾經利用關聯式資料庫完成許多工作, 沒有它, 我將沒有辦法完成一些令我感到驕傲的事情. 我完全不想貶低關聯式資料庫, 它真的是偉大的系統.但是不是每件事情都是關聯式資料庫, 不是每件事情天生就適合把它當作關聯來看待. 所有對 Mapreduce 的指責都源於"這不是我們關聯式資料庫會做的方式", 而並沒有了解到事情的重點. 關聯式資料庫的平行處理並不是很好, 你知道有多少關聯式資料庫可以有效的把工作分給 1,000 台普通機器? 關聯式資料庫無法很好的處理非表格式的資料, 像是面對遞迴資料的處理上可以說是是聲名狼藉. MapReduce 不是為了要取代關聯式資料庫, 它是提供一種輕便的程式語言開發方式, 讓大家可以快速且以平行的方式在一群機器上面執行, 僅止於這樣.
轉貼from:Hadoop Taiwan User Group
Subscribe to:
Posts (Atom)