|
已經是到北京的第五個年頭了,從最開始的想做手機游戲而學習編程,到后來做 Web 開發,又開始做日志分析,接觸到了 Hadoop ,最終確定下來自己的技術方向。曾經以為五年的時間,差不多都應該做出自己的產品來,而實際情況卻是:一直在用的技術還了解的只是皮毛。所以,雖然在 IT 這個行業已經可以說自己工作了五年時間,但感覺自己還只是剛剛起步,跑在前面的大有人在,自己還要繼續努力。
從去年開始接觸的 Hadoop ,當時的日志分析已經遇到了瓶頸,用 Hadoop 一試,確實性能提高不少,只可惜,當時的公司因為各方面的原因,開始關注云存儲這個方向,雖然即使到了現在我也不太好判定這個戰略方向的轉變 是對還是錯,但是對于當時只是普通員工的我來說,剛好發現了一個實用的技術卻沒有時間和機會研究、應用,讓人都有點惱火??赡芟裎疫@樣的凡夫俗子,還沒有 達到能站在和老板相同高度看待問題的程度,而我能做的,換家公司,找一個能應用自己感興趣的技術的公司。于是, 2011 年,就又以跳槽開始了。
但 是我并沒有想到今年會跳兩次,我一直都感覺自己是個踏踏實實的人,但實際情況卻是這幾年北京這幾個同學我換的工作最多。我也很明白:頻繁的換工作,害的其 實是自己。每一份工作,都需要花一定的時間去適應,就拿試用期來說,一般的都應該是三個月吧,一年換兩份工作,光試用期就半年出去了,真正能踏踏實實做點 事的時間,又能有多少呢?本來在年初換工作時,打算結婚也被拿了出來說事,還想著有上一年的時間,在老家付個首付,沒有想到,造化弄人,六月份的時候,一 邊看著轉正的通知郵件,一邊和主管協商著什么時候離職。
但 我并不后悔去了這家公司,雖然只有短短兩個月的時間,卻讓我學到了很多東西,開闊了視野。原來還有這樣讓人認同的企業文化,原來還有經歷這么豐富的同事, 原來還有這么愛帶著兄弟們吃喝玩樂的主管,原來程序員的生活,不一定就是加班加班,原來我們可以讓自己的生活更精彩。尤其是在去了一趟杭州之后。第一次坐 飛機,下飛機的時候耳膜難受的要死,聲音都快聽不見了,而我們只有一天的時間,第二天就又要飛回北京,我是想著趕緊休息休息,而同事是一邊說著西湖、蘇堤 啥的就雙眼冒光,大晚上的整個繞西湖走了一圈,沒把我累死。不過也確實感受到了和北京不一樣的生活方式和態度,那些就在岸邊上的茶莊,彰顯著和北京燒烤攤 不一樣的韻味。只是,當終于下了飛機,換了快軌,出了地鐵之后,又一次回到北京的地面上時,我竟然都有種過年時候回到了老家的感覺,原來,在一個城市生活 上一段時間,哪怕只是幾年,或多或少的,竟然會產生感情。
可 惜的是,我還沒有體會的多深,因為公司內部的原因,我們的項目沒用做成,大家因為這個項目聚在了一起,項目沒了,大家也就都散了。而且散的那么快,快的都 不可思議。應聘到了一個公司,一個項目做不成,那還可以做別的,一個公司可以有好多項目,而我們這個項目組的成員,明顯大家都很有自己的想法,只想做自己 想做的事,而并不是到了一個公司后就開始混日子。那么既然是這樣,我想我應該祝福他們,后來一個月后,主管又聯系我們聚了一次,大家果然都在做自己擅長、 喜歡的工作,雖然已經不在一個團隊,但由衷的為他們感到高興。
應該說,今年我本來是起了一個好頭,在項目組中有這些有著共同理想的同事,但因為中間的變故,團隊散了,我也慢慢的走向了墮落。現在回想起來,簡直都覺得有點不可思議。
在等待離職的日子里,我看完了《七龍珠》全集,還有《盜墓筆記》,看到最新的更新 ( 當時還沒有完結 ) ,每天去了之后就是看漫畫、看小說,本來之前因為項目的原因,一個月的時間把 Demo 寫的差不多都可以進行演示了,結果變故一來,立馬就好像泄了氣的皮球一樣,什么準備結婚,什么鉆研技術,一概不管,完全就把上班當成了去網 吧。自然,白天都成這樣了,晚上還期望能老老實實的看書嗎,不可能了,再然后,等再到了新公司之后,看書的習慣就怎么也沒用再培養起來。
到 了新公司,這個應該老實點了吧,畢竟當時都已經六月份了,半年的時間都已經過去了,如果再折騰折騰,整個一年就過去了,技術這玩意,要說看看書就能學會, 我還真是做不到,必須得有實際的東西去做,在項目上應用,才能快速的掌握。道理也都明白,可就是中間經歷了那么一檔子事之后,整個人都浮躁了起來,再想回 到以前的狀態,真的很難,只能是慢慢的適應。
這 一適應就又是三個月,十一假期時候,交接過來的老版本的日志分析系統出了次問題,正好趕上在唐山參加同學婚禮,三十號下午到的唐山,晚上和同學侃到一兩 點,四五點又起來接新娘盤頭,參加一天的婚禮下午又坐車回北京,休息了一個晚上之后,從二號早上七點開始恢復數據,一直到三號早上六點,之前也加班搞過通 宵,但像這次這樣整還真是頭一次,完事之后啥感覺?要說程序寫的不好能害死人,程序交接的不好,更能害死人。
假期之后,替換老系統的計劃提上了日程,和之前的不一樣,也不用再寫什么 Demo 先演示啥的,論證已經通過,直接開始用就是。 Hadoop 、 HBase 、 Hive 、 Chukwa 、 Sqoop ,一個都不能少,有很多時候其他組的同事看到我在整 Hive 都奇怪:你們組就每天調 SQL ?
有的時候我自己都快搞不清業務關系,以及寫好的 hql 的執行條件,以至于寫了一大堆的腳本,而其他同事在某一處想調試時,光這個執行順序我就得好好解釋一遍,突然發現,我現在的這套程序,雖然聽 上去比之前老版本的簡單,但實際執行的步驟復雜,隨著考慮問題的增多,我的腳本也越來越多,慢慢的,可能就和老系統差不多了,只不過,老系統是一個腳本執 行 N 多程序,我是 N 多程序對應著自己的腳本。原來,程序員看別人的程序與看自己的程序,在最開始的時候,是有私心的。
把 HBase 中表的存儲空間從 150G 優化到了 120G , hql 分析時間由兩個小時優化到了半個小時,好像有那么點成果,可是自己一直對執行效率不是很滿意,搗鼓了一個多月一直都沒啥進展,直到在和同事的討論中,聽取了別人的建議,再結合自己的業務,存儲一下從 120G 優化到了不到 5G ,執行時間也從三個小時優化到了十分鐘。但是,這樣就已經可以了嗎?不行, 2012 ,還得繼續。此外,明白了一個道理:和別人多溝通、多分享,比自己一個人埋頭苦干要強百倍。
剩下的,對來年做個規劃吧, 2012 了,該辦的事必須得抓緊時間辦啊。
關 于看書,之前看過一篇文章,提到程序員都是自學成才,通過項目,通過好書,尤其是精讀一本好書。只是可惜,計算機類的圖書,越是好書塊頭越大,看前頭幾章 的時候壓力最大,“這得啥時候才能看完呢?”雖然這是個錯誤的觀點吧,但有時候還是忍不住會去想,這個時候,毅力、恒心真的很重要,當然,如果是結合項目 需要來看,那就更好了,一邊看一邊能解決實際問題,這樣看書肯定是效率百倍。如果能再按照書中給出的練習強度來檢查學習程度,那就更加 OK 了,只是,結合自身實際來看,這個也需要點恒心。
列下書單吧,希望自己能堅持完成。
《深入理解計算機系統》
《 Java 編程思想》
《 C++ 編程思想》
《微積分學教程》
關 于英語,快放假了無所事事時,看到了篇講如何學習英語的文章,很受啟發,英語這玩意,先別說它重不重要,要想學,關鍵還是看自己有沒有興趣,有興趣,再結 合合理的學習方法,如果能堅持一段時間,我想,應該是能見到點效果的吧。這個事情想了很長時間,但一直都只是停留在想想的階段,從來就沒有說實際行動過一 次。如果再不抓住這一年的時間,恐怕以后自己會找到更多的借口,所以,把這個也寫上吧,一年的時間,說長不長,說短不短,多給自己安排點事,別再留出看漫 畫的時間來。
列下目標吧,希望自己能堅持完成。
能看完一本原版英文小說
能聽懂一部無字幕英文電影的對白
關于技術, Hadoop 現在只是應用,對它的源碼還沒有怎么看,接下來打算從比較簡單入手,慢慢的,由淺入深吧,希望能對它的底層實現有更加清晰的認識。這個在日常工作中天天都用的到,按說應該是花時間最多的,希望能比前兩個成績多點吧。
目標的話,能分析一遍 Hadoop 及其子項目的源碼。
計劃列了不少,能全部完成的話還真得拜了佛,但不管怎樣,能堅持完成二三,也算是對 2012 有個交代,一年的時間,激情會慢慢消磨殆盡,但如果能時不時的繃緊這根弦,把它養成習慣,或許也就省了燒香了。
有了創業的想法,如何邁出第一步?曾經我跟朋友講過很多次,我告訴他:如果你有想法,一定要立即執行,不要考慮能不能成功的問題。
但是輪到自己的時候就會很猶豫,我本質上來說也是很喜歡研究技術的人所以創業的話我會希望完全自己編寫程序,但是自己寫所要學習的知識太多了,花費的時間太長了,一開始考慮的太多,反而忘了如何走出第一步。
這 么多年來一直想做一個網站,但是目的并不太明確,現在終于有了一點頭緒,于是全身都燃燒起來了,但是接下來的事情,放假,結婚,南北兩地跑,一刻不能清 閑,連續兩周沒有上網。雖然激情沒有冷卻,但是已經比剛開始思考的東西多了很多,各種奇思妙想,創新點子都冒出來了,只是苦惱了,一直都無法付諸實踐。其 中很多想法都是到了網站達到一定程度才能做的。
這段時間考慮了太多的東西,不懂得如何推廣網站,需要學習,網站的內容需要用戶來創造,如何才能吸引用戶來這里落地安家,如何保證安全,如何定位、規范內容,起個什么名字,申請什么域名,選擇什么語言,投資多少錢,找人合作嗎,如何應對競爭,如何盈利.....
各 種考慮紛至沓來,腦子亂糟糟,反而不知道如何走出第一步了,只感覺自己成功的希望很渺小,那股子激情越來越弱,現實太殘酷,勇氣已經快要消失了,唯一剩下 的一個念頭是:做這個網站可以逼自己學到東西,所以不論能不能掙錢,都有做這個網站的價值。于是還是鼓起勇氣對自己說,一定要把這個網站做出來。
現在看的太遠也不是什么好事,當務之急應該是把網站搭起來。我覺得應該是邊做邊學。如果暫時做不到就先放下來,把它當做自己的一個目標。
再想想網站的詳細定位,想個好名字就去申請域名和空間。哪怕只有一個主頁,第一步一定要邁起來。面對困難不敢邁步的人,永遠不能成功。
數據庫安全涉及的問題
數據庫安全是當今最重要的問題。您的數據庫可能允許顧客通過互聯網購買產品,它也可能包含用來預測業務趨勢的歷史數據;無論是哪種情況,公司都需要可靠的數據庫安全計劃。
數據庫安全計劃應該定義:
允許誰訪問實例和/或數據庫
在哪里以及如何檢驗用戶的密碼
用戶被授予的權限級別
允許用戶運行的命令
允許用戶讀取和/或修改的數據
允許用戶創建、修改和/或刪除的數據庫對象
DB2安全機制
DB2中有三種主要的安全機制,可以幫助 DBA 實現數據庫安全計劃:身份驗證(authentication)、授權(authorization) 和特權(privilege)。
身份驗證是用戶在嘗試訪問DB2實例或數據庫時遇到的第一種安全特性。DB2身份驗證與底層操作系統的安全特性緊密協作來檢驗用戶ID和密碼。DB2還可以利用Kerberos這樣的安全協議對用戶進行身份驗證。
授權決定用戶和/或用戶組可以執行的操作以及他們可以訪問的數據對象。用戶執行高級數據庫和實例管理操作的能力由指派給他們的權限決定。在 DB2 中有5種不同的權限級別:SYSADM、SYSCTRL、SYSMAINT、DBADM和LOAD。
特權的粒度比授權要細,可以分配給用戶和/或用戶組。特權定義用戶可以創建或刪除的對象。它們還定義用戶可以用來訪問對象(比如表、視圖、索引和包)的命 令。DB2 9中新增的一個概念是基于標簽的訪問控制(LBAC),它允許以更細的粒度控制誰有權訪問單獨的行和/或列。
客戶機、服務器、網關和主機
數據庫環境常常由幾臺不同的機器組成;必須在所有潛在的數據訪問點上保護數據庫。在處理 DB2 身份驗證時客戶機、服務器、網關和主機的概念尤其重要。
數據庫服務器是數據庫實際所在的機器(在分區的數據庫系統上可能是多臺機器)。DB2數據庫客戶機是對服務器上的數據庫執行查詢的機器。這些客戶機可以是本地的(駐留在與數據庫服務器相同的物理機器上),也可以是遠程的(駐留在單獨的機器上)。
如果數據庫駐留在運行AS/400(iSeries)或OS/390(zSeries)的大型機上,它就稱為主機或主機服務器。
網關是一臺運行DB2 Connect產品的機器。DB2客戶機可以通過網關連接駐留在主機上的DB2數據庫。
網關也稱為DB2 Connect服務器。安裝了 Enterprise Server Edition產品的系統也內置了DB2 Connect功能。
DB2身份驗證
DB2 身份驗證控制數據庫安全計劃的以下方面:
誰有權訪問實例和/或數據庫
在哪里以及如何檢驗用戶的密碼
在發出attach或connect命令時,它在底層操作系統安全特性的幫助下完成這個任務。attach命令用來連接DB2實例,connect命令用來連接DB2實例中的數據庫。下面的示例展示了DB2對發出這些命令的用戶進行身份驗證的不同方式。具體如下
用創建 DB2 實例時使用的用戶ID登錄到安裝 DB2 的機器上。發出以下命令:
$ db2 attach to db2inst1
Instance Attachment Information
Instance server = DB2/LINUX 9.7.5
Authorization ID = DB2INST1
Local instance alias = DB2INST1
在這里,隱式地執行身份驗證。使用登錄機器的用戶ID,并假設這個ID已經經過了操作系統的檢驗。
$ db2 connect to sample user db2inst1 using a
Database Connection Information
Database server = DB2/LINUX 9.7.5
SQL authorization ID = DB2INST1
Local database alias = SAMPLE
在這里,顯式地執行身份驗證。用戶db2inst1和密碼a由操作系統進行檢驗。用戶db2inst1成功地連接到示例數據庫。
db2 connect to sample user test1 using password new chgpass confirm chgpass
與上例中一樣,用戶ID db2inst1和密碼password由操作系統進行檢驗。然后,操作系統將db2inst1的密碼從a改為chgpass。因此,如果再次發出例 2 中的命令,它就會失敗。
DB2身份驗證類型
DB2使用身份驗證類型決定在什么地方進行身份驗證。例如,在客戶機---服務器環境中,是客戶機還是服務器檢驗用戶的 ID和密碼?在客戶機---網關---主機環境中,是客戶機還是主機檢驗用戶的ID和密碼?
DB2 9能夠根據用戶是試圖連接數據庫,還是執行實例連接和實例級操作,指定不同的身份驗證機制。在默認情況下,實例對于所有實例級和連接級請求使用一種身份驗 證類型。這由數據庫管理程序配置參數AUTHENTICATION來指定。V9.1 中引入了數據庫管理程序配置參數 SRVCON_AUTH。這個參數專門處理對數據庫的連接。例如,如果在DBM CFG 中進行以下設置:
$ db2 get dbm cfg|grep -i auth
Server Connection Authentication (SRVCON_AUTH) = KERBEROS
Database manager authentication (AUTHENTICATION) = SERVER_ENCRYPT
那么在連接實例時會使用SERVER_ENCRYPT。但是在連接數據庫時會使用KERBEROS身份驗證。如果在服務器上沒有正確地初始化KERBEROS,但是提供了有效的用戶ID/密碼,那么允許這個用戶連接實例,但是不允許他連接數據庫。
下表總結了可用的 DB2 身份驗證類型。在客戶機---網關---主機環境中,這些身份驗證選項在客戶機和網關上設置,而不是在主機上。本節將詳細討論如何設置這些選項。
類型 | 描述 |
SERVER | 身份驗證在服務器上進行。 |
SERVER_ENCRYPT | 身份驗證在服務器上進行。密碼在客戶機上進行加密,然后再發送到服務器。 |
CLIENT | 身份驗證在客戶機上進行(例外情況見 處理不可信的客戶機 )。 |
*KERBEROS | 由 Kerberos 安全軟件執行身份驗證。 |
*KRB_SERVER_ENCRYPT | 如果客戶機設置是 KERBEROS,那么由 Kerberos 安全軟件執行身份驗證。否則使用 SERVER_ENCRYPT。 |
DATA_ENCRYPT | 身份驗證在服務器上進行。服務器接受加密的用戶 ID 和密碼,并對數據進行加密。這個選項的操作方式與 SERVER_ENCRYPT 相同,但是數據也要加密。 |
DATA_ENCRYPT_CMP | 身份驗證方式與 DATA_ENCRYPT 相同,但是允許不支持 DATA_ENCRYPT 的老式客戶機使用 SERVER_ENCRYPT 身份驗證進行連接。在這種情況下,數據不進行加密。如果進行連接的客戶機支持 DATA_ENCRYPT,就會進行數據加密,而不能降級到 SERVER_ENCRYPT 身份驗證。這個身份驗證類型只在服務器的數據庫管理程序配置文件中是有效的,而且在客戶機或網關實例上使用 CATALOG DATABASE 時是無效的。 |
GSSPLUGIN | 身份驗證方式由一個外部 GSS-API 插件決定。 |
GSS_SERVER_ENCRYPT | 身份驗證方式由一個外部 GSS-API 插件決定。在客戶機不支持服務器的 GSS-API 插件之一的情況下,使用 SERVER_ENCRYPT 身份驗證。 |
注意:這些設置只對 Windows 2000、AIX、Solaris 和 Linux® 操作系統有效。
在服務器上設置身份驗證
在數據庫服務器上,在數據庫管理程序配置(DBM CFG)文件中使用 AUTHENTICATION 參數設置身份驗證。請記住,DBM CFG文件是一個實例級配置文件。因此,AUTHENTICATION參數影響這個實例中的所有數據庫。以下命令演示如何修改這個參數。
要查看配置文件中的身份驗證參數:
$db2 get dbm cfg
要將身份驗證參數修改為 server_encrypt
:
$ db2 update dbm cfg using authentication server
$db2stop
$db2start
注:雖然更新完注冊表參數后,直接執行 db2 get dbm cfg|grep -i auth可以看到注冊表參數已經修改完畢。但是為使其生效,還是需要重啟實例。
某些身份驗證類型(比如GSSPLUGIN、KERBEROS 和 CLIENT)要求設置其他數據庫管理程序配置參數,比如 TRUST_ALLCLNTS、SRV_PLUGIN_MODE 和 SRVCON_PW_PLUGIN。關于這些設置的更多細節見下文。
在網關上設置身份驗證
使用catalog database命令在網關上設置身份驗證。在這里的示例中,我們將使用名為myhostdb 的主機數據庫。
要將網關身份驗證類型設置為 SERVER,應該在網關機器上發出以下命令:
db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate
注意,身份驗證不會在網關本身執行。在DB2 Version 8中,身份驗證必須在客戶機或主機數據庫服務器上執行。
在客戶機上設置身份驗證
我們來考慮兩臺單獨的客戶機上的兩種情況。我們將一個客戶機配置為連接服務器機器上的數據庫(DB2 UDB LUW 分布式平臺),另一個客戶機連接主機上的數據庫(例如 DB2 for zSeries)。
連接服務器數據庫的客戶機: 在針對要連接的數據庫的數據庫目錄項中,客戶機身份驗證設置必須匹配數據庫服務器上的設置(但是 KRB_SERVER_ENCRYPT、DATA_ENCRYPT_CMP 和 GSS_SERVER_ENCRYPT 例外)。
我們假設服務器身份驗證類型設置為 SERVER。在客戶機上發出以下命令對名為 sample 的服務器數據庫進行編目:
$db2 catalog database sample at node nd1 authentication SERVER
注:如果沒有指定身份驗證類型,客戶機將默認使用 SERVER_ENCRYPT。
連接主機數據庫的客戶機: 我們假設網關上的身份驗證類型設置為SERVER。如果沒有指定身份驗證類型,那么在通過 DB2 Connect訪問數據庫時假設采用SERVER_ENCRYPT身份驗證。身份驗證在主機數據庫服務器上進行。從客戶機發出以下命令會導致客戶機向網關 發送未加密的用戶 ID 和密碼:
db2 catalog database myhostdb at node nd1 authentication SERVER
現在假設網關上的身份驗證類型設置為SERVER_ENCRYPT。身份驗證同樣在主機數據庫服務器上進行。用戶ID和密碼在客戶機上進行加密,然后再發送到網關,并在網關上進行加密,然后再發送到主機。這是默認的做法。
處理不可信的客戶機
如果服務器或網關將身份驗證類型設置為CLIENT,那么這意味著期望客戶機對 用戶的ID和密碼進行身份驗證。但是,一些客戶機的操作系統沒有本機安全特性。這種不可信的客戶機包括在Windows 98和Windows ME上運行的DB2。DB2 V9.1不支持 Windows 98 或 Windows ME,但是它支持低版本的客戶機,所以仍然可能必須處理不可信的V8客戶機。
在 DBM CFG 文件中有兩個額外參數,用于在服務器或網關身份驗證方法設置為CLIENT,而不可信的客戶機試圖連接數據庫或DB2實例時,決定應該在哪里進行身份驗證。這些參數是 TRUST_ALLCLNTS和TRUST_CLNTAUTH 參數。
當服務器或網關身份驗證類型為CLIENT 時,除了TRUST_ALLCLNTS和 TRUST_CLNTAUTH 參數之外,還有兩個因素會起作用。第一個因素是用戶 ID 和密碼是否是顯式提供的,第二個因素是進行連接的客戶機的類型。有三種DB2客戶機:
不可信的客戶機 :如上所述
主機客戶機 :運行在 zSeries 這樣的主機操作系統上的客戶機
可信客戶機 :運行在具有本機安全特性的非主機操作系統(比如 Windows NT、2000、2003、XP 以及所有形式的 Unix / Linux)上的客戶機
當身份驗證設置為 CLIENT 時
下表總結了如果服務器的身份驗證類型設置為 CLIENT,那么在每種類型的客戶機向服務器發出連接命令時將在哪里進行身份驗證。
是否提供了 ID/密碼? | TRUST_ALLCLNTS | TRUST_CLNTAUTH | 不可信的客戶機 | 可信的客戶機 | 主機客戶機 |
No | Yes | CLIENT | CLIENT | CLIENT | CLIENT |
No | Yes | SERVER | CLIENT | CLIENT | CLIENT |
No | No | CLIENT | SERVER | CLIENT | CLIENT |
No | No | SERVER | SERVER | CLIENT | CLIENT |
No | DRDAONLY | CLIENT | SERVER | SERVER | CLIENT |
No | DRDAONLY | SERVER | SERVER | SERVER | CLIENT |
Yes | Yes | CLIENT | CLIENT | CLIENT | CLIENT |
Yes | Yes | SERVER | SERVER | SERVER | SERVER |
Yes | No | CLIENT | SERVER | CLIENT | CLIENT |
Yes | No | SERVER | SERVER | SERVER | SERVER |
Yes | DRDAONLY | CLIENT | SERVER | SERVER | CLIENT |
Yes | DRDAONLY | SERVER | SERVER | SERVER | SERVER |
DRDAONLY 意味著只信任主機客戶機,而不管使用 DRDA 進行連接的 DB2 Version 8 客戶機。
下面的示例說明如何在服務器和客戶機上設置身份驗證類型和參數:
在服務器上設置身份驗證:
$db2 update dbm cfg using authentication client
$db2 update dbm cfg using trust_allclnts yes
$db2 update dbm cfg using trust_clntauth server
$db2stop
$db2start
在客戶機上設置身份驗證:
$db2 catalog database sample at node nd1 authentication client
在上面的示例中,如果從任何客戶機發出命令
db2 connect to sample
那么身份驗證在客戶機上進行。如果從任何客戶機發出命令
db2 connect to sample user test1 using password
那么身份驗證在服務器上進行。
DB2的安全插件架構
DB2 V8.2引入了安全插件的概念。這個概念在DB2 V9.1中得到了進一步增強。通過使用標準的 GSS-API 調用,用戶可以編寫一個安全插件并將對用戶 ID 進行身份驗證的工作交給一個外部安全程序。這種方式的一個示例是DB2本身的KERBEROS身份驗證。在一臺機器上安裝 DB2 ESE或應用程序開發客戶機時,安裝過程中將有一些示例應用程序代碼放入實例目錄,如果查看 samples\security\plugins 目錄,就會看到如何編寫安全插件的示例。本節將概述如何在 DB2 安全架構中使用插件,但是不討論如何編寫或編譯插件本身。關于這個主題的詳細描述,請參考 DB2 UDB 安全性: 理解 DB2 Universal Database 安全性插件 。
Kerberos 身份驗證
Kerberos 身份驗證為DB2提供了一種無需通過網絡發送用戶ID和密碼的用戶身份驗證方法。Kerberos安全協議作為第三方身份驗證服務執行身份驗證,它使用傳 統的密碼術創建一個共享的密鑰。這個密鑰成為用戶的憑證,在請求本地或網絡服務時在所有情況下都使用它檢驗用戶的身份。通過使用Kerberos安全協 議,可以實現對遠程DB2數據庫服務器的單點登錄。
首先,討論如何設置DB2來使用Kerberos身份驗證。如上所述,Kerberos身份驗證在DB2 中是使用插件架構實現的。默認的kerberos 插件的源代碼在samples/security/plugins
目錄中,稱為IBMkrb5.c
。在DB2 中使用Kerberos之前,必須在客戶機和服務器上啟用和支持 Kerberos。為此,必須滿足以下條件:
1、客戶機和服務器必須屬于同一個域(用 Windows 術語來說,是可信域)。
2、必須設置適當的主體(Kerberos 中的用戶 ID)。
3、必須創建服務器的keytab文件,實例所有者必須能夠讀這個文件。
4、所有機器必須有同步的時鐘。
可以在 Kerberos 產品附帶的文檔中找到關于設置 Kerberos 的更多信息。
為了在 DB2 中啟用 Kerberos 身份驗證,必須先告訴客戶機在哪里尋找將使用的Kerberos 插件。在客戶機上,運行以下命令:
DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE
在這個示例中,使用默認的 KERBEROS 插件。如果使用的Kerberos實現需要特殊功能的話,DBA可以修改這個插件來執行特殊功能。
還可以告訴客戶機它正在針對哪個服務器主體進行身份驗證。這個選項可以避免Kerberos身份驗證的第一步,即客戶機尋找它要連接的實例的服務器主體。在客戶機上對數據庫進行編目時可以指定AUTHENTICATION參數。它的格式是:
DB2 CATALOG DB dbname AT NODE node name AUTHENTICATION KERBEROS TARGET PRINCIPAL service/host@REALM
這一步是可選的。
DB2 CATALOG DB sample AT NODE testnd AUTHENTICATION KERBEROS TARGET PRINCIPAL gmilne/gmilne02.torolab.ibm.com@TOROLAB.IBM.COM
設置 Kerberos 身份驗證的下一步是設置服務器。srvcon_gssplugin_list
參數可以設置為支持的GSS-API插件的列表,但是只允許有一個Kerberos 插件。如果這個列表中沒有Kerberos 插件,那么自動地使用默認的IBMkrb5插件。如果希望允許所有身份驗證(實例連接和數據庫連接)使用Kerberos,那么執行以下命令:
DB2 UPDATE DBM CFG USING AUTHENTICATION KERBEROS
或者
DB2 UPDATE DBM CFG USING AUTHENTICATION KRB_SERVER_ENCRYPT
如果只希望 DB2 使用 Kerberos 對數據庫連接進行身份驗證(對實例連接使用 SERVER),那么執行以下命令:
DB2 UPDATE DBM CFG USING SVRCON_AUTH KERBEROS
或者
DB2 UPDATE DBM CFG USING SVRCON_AUTH KRB_SERVER_ENCRYPT
根據實例的位長度(32 或 64 位),DB2將在實例啟動時自動地裝載 IBMkrb5 插件。
其他身份驗證設置
如果查看 V9.1 實例中的DBM CFG,會看到影響DB2對用戶ID進行身份驗證的方式的各種設置。正如前面提到的,有針對標準操作系統用戶ID身份驗證的設置(CLIENT、 SERVER、SERVER_ENCRYPT、DATA_ENCRYPT、DATA_ENCRYPT_CMP),還有將身份驗證工作交給外部程序的插件 (KERBEROS、KRB_SERVER_ENCRYPT、GSSPLUGIN、 GSS_SERVER_ENCRYPT)。本節專門介紹其他一些配置變量如何影響對用戶的身份驗證。
Client Userid-Password Plugin (CLNT_PW_PLUGIN) =
Group Plugin (GROUP_PLUGIN) =
GSS Plugin for Local Authorization (LOCAL_GSSPLUGIN) =
Server Plugin Mode (SRV_PLUGIN_MODE) = UNFENCED
Server List of GSS Plugins (SRVCON_GSSPLUGIN_LIST) =
Server Userid-Password Plugin (SRVCON_PW_PLUGIN) =
Cataloging allowed without authority (CATALOG_NOAUTH) = NO
Bypass federated authentication (FED_NOAUTH) = NO
在上面的列表中,去掉了已經討論過的參數。
CLNT_PW_PLUGIN | 這個參數在客戶端的 DBM CFG 中指定。它指定用來進行客戶機和本地身份驗證的客戶機插件的名稱。 |
GROUP_PLUGIN | 默認值是空(NULL)。將它設置為用戶定義的插件就會調用這個插件進行所有組枚舉,而不依賴于操作系統的組查找。這與后面討論的授權部分相關。 |
LOCAL_GSSPLUGIN | 這個參數指定默認的 GSS-API 插件庫的名稱,當數據庫管理程序配置的身份驗證參數值設置為GSSPLUGIN 或 GSS_SERVER_ENCRYPT 時,這個庫用來進行實例級的本地授權。 |
SRV_PLUGIN_MODE | (YES/NO) 這個參數的默認設置是 NO。當改為 YES 時,以 FENCED 模式啟動 GSS-API 插件,其工作方式類似于 FENCED 存儲過程。FENCED 插件的崩潰不會導致 DB2 實例崩潰。在插件還處于開發階段時,建議以 fenced 模式運行它們,這樣的話插件中的邏輯問題和內存泄漏就不會導致實例崩潰。在確定插件是可靠的之后,應該以 unfenced 模式運行以提高性能。 |
SRVCON_GSSPLUGIN_LIST | 一 個插件列表,當使用 KERBEROS、KRB_SERVER_ENCRYPT、GSSPLUGIN 或 GSS_SERVER_ENCRYPT 時,服務器上的數據庫管理程序在身份驗證期間將使用這些插件。列表中的每個插件應該用逗號(‘,’)分隔,它們之間沒有空格。插件按照優先次序列出,首先 使用列表中的第一個插件對發送的用戶 ID/密碼進行身份驗證。只有當列出的所有插件都返回了錯誤時,DB2 才會向用戶返回身份驗證錯誤。 |
SRVCON_PW_PLUGIN | 在指定 CLIENT、SERVER 或 SERVER_ENCRYPT 身份驗證時,這個參數允許用戶修改 DB2 用來檢驗用戶 ID 和密碼的默認身份驗證方法。在默認情況下,它的值是 NULL,因此使用默認的 DB2 方法。 |
CATALOG_NOAUTH | (YES/NO) 默認值是 NO。將這個參數修改為 YES 就允許不屬于 SYSADM、SYSCTRL 或 SYSMAINT 組成員的用戶修改機器上的 Database、Node、Admin 和 DCS 編目。如果登錄的用戶使用不可信客戶機(定義見上文),或者登錄所用的用戶 ID 不允許連接數據庫或實例,但是用戶又必須在客戶機上進行編目,只有在這種情況下這個參數才是有用的。 |
FED_NOAUTH | 如 果 fed_noauth 設置為 yes,身份驗證設置為 server 或 server_encrypt,聯邦設置為 yes,那么在實例上避免進行身份驗證。它假設身份驗證在數據源上進行。當 fed_noauth 設置為 yes 時系統會發出警告。在客戶機和 DB2 服務器上都不進行身份驗證。知道SYSADM身份驗證名稱的任何用戶都擁有聯邦服務器的 SYSADM 權限。 |
一、問題:鐵路的售票系統的數據量是海量嗎?
不是。因為數據量不大,真不大。
每一個車次與車次間是獨立的,每車次不超過2000張票,一天發車不超過50萬車次;
以預售期15天來講,15*0.1億張不超過1.5億筆的熱線數據,稱不上海量數據的。
再加上可以按線路分庫,更是不到千萬級的單表容量。已經發車完成的進入歸檔分析。
即數據庫按路線使用不同的服務器,不同的車次放在不同的表中。并發量鎖真不大。
當然,如果不分庫分表,再加上不歸檔處理,鐵路的售票系統的數據量看起來是海量的;
關鍵是這海量的數據沒有意義。
二、如何分庫分表?
2.1 分庫,考慮數據間沒有直接關系和服務器如何部署
鐵路的售票系統為例來說,按路線分庫,再按車次分表是合理的。
設路線有1萬條,按每1000條需要兩臺服務器(一臺熱機沉余),不到20臺服務器
如果使用SAN存儲,則使用SAN作為存儲,本機作為熱機沉余,只需要10臺。
當然使用mySQL這種經濟型數據庫,服務器需要更多來防災;
即可以采用雙寫或多寫的方式來保證數據的絕對安全。
2.2分表,考慮數據間不存在重疊,即數據滿足二分原則
鐵路的售票系統的任意兩個車次是沒有關系的,所以可以分表。
電信的某個用戶的通話和其它用戶的通話記錄,也是沒有關系,所以可以分表處理
(實際上電信的系統,分庫分表后也是不大的,難在后臺的計費、結算等規則)
三、數據庫訪問接口
1. 元數據:如何識別到當前要處理的數量在哪張表?
鐵路的售票系統會有一個車次管理系統,例2012年2月12日 D3206 車次,
按預先設計的在哪臺服務器的哪個庫,建哪個表。
2.建立元數據的規則:即具體如何分庫分表的規則
這個就是數據庫的訪問接口。
3.數據庫訪問接口的透明程度
即哪個層知道哪些元數據信息。
例,是否讓窗口售票的客戶端來解析元數據的規則然后緩存,還是通過中間件來解析緩存的
具體各層使用怎樣透明程度,和業務性質、節點和數據中心的拓撲等有關。
四、歷史數據歸檔與分析
1.使用分庫分表后,數據需要歸檔,分析處理的程序變得復雜,但使聯機交易變得簡單
2.分析:要注意是針對熱線數據分析、歸檔數據分析、混合分析有關,
通過分庫分表和歸檔,更方便使用分布式的統計方案。
具體可以參考,淘寶的開放平臺架構師寫的文章:
結論:分庫分表跟不分庫分表,整個架構是完全不一樣的。
像鐵票的售票系統、淘寶、電信、銀行等,絕對要采用分庫分表的數據存儲方案,
來解決數據量的增長而不影響性能的問題。
像淘寶等互聯網應用還要解決帶寬即CDN問題。
新版谷歌分析增加了好幾個實用功能,包括即時分析報告,訪問者流(參見《“訪問者流”功能添加入Google Analytics中》),還有“多渠道通路分析”。從專業到專家,差別有時候就是一個工具,多渠道通路分析,就是讓你變成專家的好工具。之前轉發的博客《轉發整理:究竟哪種營銷手段為B2C網站帶來訂單》,如果要了解到底哪種營銷手段為小明帶來訂單,用多渠道通路可以很直觀的看出來。
單渠道通路分析,在老版本的google analytics已經存在,很多電子商務網站都使用過,如下圖:
這 就是常說的可視化通路(或者叫轉化率漏斗),4887個用戶將商品放入購物車,最后854個用戶購買,購物流程的轉化率是17.47%。超過80%的用 戶,在購物過程中流失了。通過這個漏斗,我們可以分析購物流程哪個環節出了問題,然后改造對應的頁面,提升用戶購物體驗,從而達成更高的轉化率。
上 面的可視化通路被稱作單渠道通路,對于網站本身的UED(用戶體驗設計)很有用。那么有沒有一種方法,能夠幫我們分析出各種推廣渠道的效率和效果呢?一個 更直接的問題是:我的EDM電子郵件營銷的效果好,還是Google Adwords的效果好呢?或者我該嘗試一下社會化媒體facebook?——這就是多渠道通路解決的問題。
多渠道通路谷歌的介紹文字
https://support.google.com/analytics/bin/answer.py?hl=zh-Hans&answer=1191180&topic=1191164&ctx=topic
引用上面文字的定義:
在 Google Analytics(分析)中,轉化和電子商務交易會在訪問者完成轉化后計入引薦該訪問者的最近一個廣告系列、搜索或廣告。但是,在此之前的網站引薦、搜索字詞和廣告對此次轉化有何貢獻?訪問者從最初表現出購物意愿到最終決定購買,經歷了多長時間?
“多渠道路徑”報告可以為您展示各營銷渠道(即網站流量來源)如何共同發揮作用來實現銷售和轉化,從而解答這些問題和其他問題。
例 如,許多人可能會在 Google 上搜索您的品牌后,進入您的網站進行購買。不過,他們可能是在閱讀博客文章時發現了您的品牌,也可能是在搜索某些產品或服務時發現的。利用“多渠道路徑” 報告,您可以了解先前的引薦網址、搜索字詞以及在其他渠道的展示對您的銷售有何幫助。
我們結合幾個實例來看:
上圖是多渠道通路的總覽界面,位于“轉化”-“多渠道通路”-“Overview”
上圖的數據可以看出,73.55%的實際購買用戶,都是通過自然排名到達的。42.32%的用戶,通過直接訪問網址的方法到達的。兩者加起來超過100%,因為有交集(見紅色框)。交集部分有19.9%用戶。從這個圖可以直觀看出購買用戶的來源情況。
而在老版本的谷歌分析中,如果一個用戶有了購買行為,你只能從數據中觀察到這個用戶這一次購買的進入途徑。舉例:某用戶第一次在google搜索“cheap gadgets free shipping”,進入了 buyonme.com 網站,然后收藏了這個網站。兩天后,該用戶通過收藏夾再次訪問buyonme.com,然后下了一個訂單達成預設轉化目標,老版本GA只能統計這個目標來自于Direct Visit,而新版本GA可以追溯歷史,判斷這個轉化目標的實現與當時的搜索有關。
再看看更直觀的一個圖:
上面的圖顯示了實際購買用戶的購買路徑。
排在第一位的是單次自然排名搜索用戶,第二位的是直接訪問用戶(包括收藏夾訪問),第三位是用戶兩次通過搜索引擎自然排名搜索后購買,第四位是用戶先搜索找到網站第二次通過收藏夾或直接輸入網址產生的購買。
以上數據,對于廣告投放策略以及用戶購買行為分析,非常有用。
作者: 譚硯耘@用戶體驗與可用性設計-科研筆記
版權屬于: 譚硯耘 (TOTHETOP至尚國際 )
版權所有。轉載時必須以鏈接形式注明作者和原始出處
http://www.webusability.cn/google-analytics-multi-channel-funnels-800/
如果你希望與作者交流,請發送郵件到 tanyanyun/at/163.com 別忘了修改小老鼠
package me.test;
import java.lang.reflect.*; //導入反射需要的包
public class ReflectTest {
public static void main(String[] args) throws Exception
{
/* 下面通過反射完成對一個對象中成員的替換
* 并且執行執行私有方法
* 完成對 Poiont類的對象中所有的 String的對象的d換成x
* 并且類中無修改方法
*/
Point pt=new Point(3,5); //創建一個Point對象
Field fx=pt.getClass().getField("x") ; //獲取x的映射類對象
Field fy=pt.getClass().getDeclaredField("y");//因為y是私有的所以要調用這個方法
Method m2=Point.class.getDeclaredMethod("showPrivate") ;//獲得私有方法映射類
//利用反射調用共有輸出
m2.setAccessible(true) ;// 修改showPrivate 權限 改變為可以調用
m2.invoke(pt) ;//執行私有方法
//利用成員反射輸出x 和 私有的 y
System.out.println(fx.getInt(pt));//反射輸出x
fy.setAccessible(true) ;//改變私有為可訪問
System.out.println(fy.getInt(pt));//輸出私有y
//替換成員后并且反射私有方法輸出
changeString(pt) ;//反射替換成員值
System.out.println(pt);
}
public static void changeString(Object obj) throws Exception//反射替換對所有String進行替換
{
Field[] f=obj.getClass().getFields() ; //獲得成員映射數組
for(Field tem : f) //迭代for循環
{
if(tem.getType()==String.class) //內存中只有一份String字節碼
{
String oldString=(String)tem.get(obj) ; //返回內容
String newString=oldString.replace('d', 'x');//將所有b替換為x
tem.setAccessible(true);
tem.set(obj, newString) ;//替換成員值
}
}
}
}
public class Point
{
public int x ;
private int y ;
public Point(int x, int y) {
super();
this.x = x;
this.y = y;
}
public String a="dsfdsfd" ; //只有 共有可以替換
public String b="fdsfdsfewewwwww" ;
public String c="adddssss" ;
private void showPrivate() //私有方法輸出
{
System.out.println("x="+this.x+"\n"+"y="+this.y);
System.out.println(this.a);
System.out.println(this.b);
System.out.println(this.c);
}
public String toString()
{
return this.a+"\n"+this.b+"\n"+this.c;
}
jQuery菜單插件,用于創建與動態(動畫)背景菜單。每個菜單項可以是背景圖像,這樣,當鼠標從一個菜單項移動到另一個背景圖像被替換使用的動畫過渡。
設計網站導航使用jQuery的javascript菜單應干凈和舒適的!今天我所收集的30個最佳jQuery的菜單,如jQuery的菜單導航,jQuery的菜單列表,jQuery的垂直菜單,jQuery的滑動菜單,jQuery的浮動菜單,jQuery的橫向菜單