樂意資料庫

❶ 數據倉庫和資料庫有什麼區別和聯系

簡而言之，資料庫是面向事務的設計，數據倉庫是面向主題設計的。

資料庫一般存儲在線交易數據，數據倉庫存儲的一般是歷史數據。

資料庫設計是盡量避免冗餘，一般採用符合範式的規則來設計，數據倉庫在設計是有意引入冗餘，採用反範式的方式來設計。

資料庫是為捕獲數據而設計，數據倉庫是為分析數據而設計，它的兩個基本的元素是維表和事實表。維是看問題的角度，比如時間，部門，維表放的就是這些東西的定義，事實表裡放著要查詢的數據，同時有維的ID。

單從概念上講，有些晦澀。任何技術都是為應用服務的，結合應用可以很容易地理解。以銀行業務為例。資料庫是事務系統的數據平台，客戶在銀行做的每筆交易都會寫入資料庫，被記錄下來，這里，可以簡單地理解為用資料庫記帳。數據倉庫是分析系統的數據平台，它從事務系統獲取數據，並做匯總、加工，為決策者提供決策的依據。比如，某銀行某分行一個月發生多少交易，該分行當前存款余額是多少。如果存款又多，消費交易又多，那麼該地區就有必要設立ATM了。

顯然，銀行的交易量是巨大的，通常以百萬甚至千萬次來計算。事務系統是實時的，這就要求時效性，客戶存一筆錢需要幾十秒是無法忍受的，這就要求資料庫只能存儲很短一段時間的數據。而分析系統是事後的，它要提供關注時間段內所有的有效數據。這些數據是海量的，匯總計算起來也要慢一些，但是，只要能夠提供有效的分析數據就達到目的了。

數據倉庫，是在資料庫已經大量存在的情況下，為了進一步挖掘數據資源、為了決策需要而產生的，它決不是所謂的「大型資料庫」。那麼，數據倉庫與傳統資料庫比較，有哪些不同呢?讓我們先看看W.H.Inmon關於數據倉庫的定義:面向主題的、集成的、與時間相關且不可修改的數據集合。

「面向主題的」:傳統資料庫主要是為應用程序進行數據處理，未必按照同一主題存儲數據;數據倉庫側重於數據分析工作，是按照主題存儲的。這一點，類似於傳統農貿市場與超市的區別—市場裡面，白菜、蘿卜、香菜會在一個攤位上，如果它們是一個小販賣的;而超市裡，白菜、蘿卜、香菜則各自一塊。也就是說，市場里的菜(數據)是按照小販(應用程序)歸堆(存儲)的，超市裡面則是按照菜的類型(同主題)歸堆的。

「與時間相關」:資料庫保存信息的時候，並不強調一定有時間信息。數據倉庫則不同，出於決策的需要，數據倉庫中的數據都要標明時間屬性。決策中，時間屬性很重要。同樣都是累計購買過九車產品的顧客，一位是最近三個月購買九車，一位是最近一年從未買過，這對於決策者意義是不同的。

「不可修改」:數據倉庫中的數據並不是最新的，而是來源於其它數據源。數據倉庫反映的是歷史信息，並不是很多資料庫處理的那種日常事務數據(有的資料庫例如電信計費資料庫甚至處理實時信息)。因此，數據倉庫中的數據是極少或根本不修改的;當然，向數據倉庫添加數據是允許的。

數據倉庫的出現，並不是要取代資料庫。目前，大部分數據倉庫還是用關系資料庫管理系統來管理的。可以說，資料庫、數據倉庫相輔相成、各有千秋。

補充一下，數據倉庫的方案建設的目的，是為前端查詢和分析作為基礎，由於有較大的冗餘，所以需要的存儲也較大。為了更好地為前端應用服務，數據倉庫必須有如下幾點優點，否則是失敗的數據倉庫方案。

1.效率足夠高。客戶要求的分析數據一般分為日、周、月、季、年等，可以看出，日為周期的數據要求的效率最高，要求24小時甚至12小時內，客戶能看到昨天的數據分析。由於有的企業每日的數據量很大，設計不好的數據倉庫經常會出問題，延遲1-3日才能給出數據，顯然不行的。

2.數據質量。客戶要看各種信息，肯定要准確的數據，但由於數據倉庫流程至少分為3步，2次ETL，復雜的架構會更多層次，那麼由於數據源有臟數據或者代碼不嚴謹，都可以導致數據失真，客戶看到錯誤的信息就可能導致分析出錯誤的決策，造成損失，而不是效益。

3.擴展性。之所以有的大型數據倉庫系統架構設計復雜，是因為考慮到了未來3-5年的擴展性，這樣的話，客戶不用太快花錢去重建數據倉庫系統，就能很穩定運行。主要體現在數據建模的合理性，數據倉庫方案中多出一些中間層，使海量數據流有足夠的緩沖，不至於數據量大很多，就運行不起來了。

❷ 什麼是基礎數據信息平台

一直想整理一下這塊內容，既然是漫談，就想起什麼說什麼吧。我一直是在互聯網行業，就以互聯網行業來說。
先大概列一下互聯網行業數據倉庫、數據平台的用途：

• 整合公司所有業務數據，建立統一的數據中心；

• 提供各種報表，有給高層的，有給各個業務的；

• 為網站運營提供運營上的數據支持，就是通過數據，讓運營及時了解網站和產品的運營效果；

• 為各個業務提供線上或線下的數據支持，成為公司統一的數據交換與提供平台；

• 分析用戶行為數據，通過數據挖掘來降低投入成本，提高投入效果；比如廣告定向精準投放、用戶個性化推薦等；

• 開發數據產品，直接或間接為公司盈利；

• 建設開放數據平台，開放公司數據；

• 。。。。。。




• 上面列出的內容看上去和傳統行業數據倉庫用途差不多，並且都要求數據倉庫/數據平台有很好的穩定性、可靠性；但在互聯網行業，除了數據量大之外，越來越多的業務要求時效性，甚至很多是要求實時的 ，另外，互聯網行業的業務變化非常快，不可能像傳統行業一樣，可以使用自頂向下的方法建立數據倉庫，一勞永逸，它要求新的業務很快能融入數據倉庫中來，老的下線的業務，能很方便的從現有的數據倉庫中下線；




• 其實，互聯網行業的數據倉庫就是所謂的敏捷數據倉庫，不但要求能快速的響應數據，也要求能快速的響應業務；




• 建設敏捷數據倉庫，除了對架構技術上的要求之外，還有一個很重要的方面，就是數據建模，如果一上來就想著建立一套能兼容所有數據和業務的數據模型，那就又回到傳統數據倉庫的建設上了，很難滿足對業務變化的快速響應。應對這種情況，一般是先將核心的持久化的業務進行深度建模（比如：基於網站日誌建立的網站統計分析模型和用戶瀏覽軌跡模型；基於公司核心用戶數據建立的用戶模型），其它的業務一般都採用維度+寬表的方式來建立數據模型。這塊是後話。




• 整體架構下面的圖是我們目前使用的數據平台架構圖，其實大多公司應該都差不多：




• 邏輯上，一般都有數據採集層、數據存儲與分析層、數據共享層、數據應用層。可能叫法有所不同，本質上的角色都大同小異。




• 我們從下往上看：




• 數據採集數據採集層的任務就是把數據從各種數據源中採集和存儲到數據存儲上，期間有可能會做一些簡單的清洗。





• 數據源的種類比較多：




• 網站日誌：




• 作為互聯網行業，網站日誌占的份額最大，網站日誌存儲在多台網站日誌伺服器上，




• 一般是在每台網站日誌伺服器上部署flume agent，實時的收集網站日誌並存儲到HDFS上；




• 業務資料庫：




• 業務資料庫的種類也是多種多樣，有Mysql、Oracle、SqlServer等，這時候，我們迫切的需要一種能從各種資料庫中將數據同步到HDFS上的工具，Sqoop是一種，但是Sqoop太過繁重，而且不管數據量大小，都需要啟動MapRece來執行，而且需要Hadoop集群的每台機器都能訪問業務資料庫；應對此場景，淘寶開源的DataX，是一個很好的解決方案（可參考文章 《異構數據源海量數據交換工具-Taobao DataX 下載和使用》），有資源的話，可以基於DataX之上做二次開發，就能非常好的解決，我們目前使用的DataHub也是。




• 當然，Flume通過配置與開發，也可以實時的從資料庫中同步數據到HDFS。




• 來自於Ftp/Http的數據源：




• 有可能一些合作夥伴提供的數據，需要通過Ftp/Http等定時獲取，DataX也可以滿足該需求；




• 其他數據源：




• 比如一些手工錄入的數據，只需要提供一個介面或小程序，即可完成；





• 數據存儲與分析毋庸置疑，HDFS是大數據環境下數據倉庫/數據平台最完美的數據存儲解決方案。





• 離線數據分析與計算，也就是對實時性要求不高的部分，在我看來，Hive還是首當其沖的選擇，豐富的數據類型、內置函數；壓縮比非常高的ORC文件存儲格式；非常方便的SQL支持，使得Hive在基於結構化數據上的統計分析遠遠比MapRece要高效的多，一句SQL可以完成的需求，開發MR可能需要上百行代碼；




• 當然，使用Hadoop框架自然而然也提供了MapRece介面，如果真的很樂意開發Java，或者對SQL不熟，那麼也可以使用MapRece來做分析與計算；Spark是這兩年非常火的，經過實踐，它的性能的確比MapRece要好很多，而且和Hive、Yarn結合的越來越好，因此，必須支持使用Spark和SparkSQL來做分析和計算。因為已經有Hadoop Yarn，使用Spark其實是非常容易的，不用單獨部署Spark集群，關於Spark On Yarn的相關文章，可參考：《Spark On Yarn系列文章》




• 實時計算部分，後面單獨說。




• 數據共享這里的數據共享，其實指的是前面數據分析與計算後的結果存放的地方，其實就是關系型資料庫和NOSQL資料庫；





• 前面使用Hive、MR、Spark、SparkSQL分析和計算的結果，還是在HDFS上，但大多業務和應用不可能直接從HDFS上獲取數據，那麼就需要一個數據共享的地方，使得各業務和產品能方便的獲取數據；和數據採集層到HDFS剛好相反，這里需要一個從HDFS將數據同步至其他目標數據源的工具，同樣，DataX也可以滿足。




• 另外，一些實時計算的結果數據可能由實時計算模塊直接寫入數據共享。





• 數據應用

• 業務產品
  




• 業務產品所使用的數據，已經存在於數據共享層，他們直接從數據共享層訪問即可；




• 報表




• 同業務產品，報表所使用的數據，一般也是已經統計匯總好的，存放於數據共享層；




• 即席查詢




• 即席查詢的用戶有很多，有可能是數據開發人員、網站和產品運營人員、數據分析人員、甚至是部門老大，他們都有即席查詢數據的需求；




• 這種即席查詢通常是現有的報表和數據共享層的數據並不能滿足他們的需求，需要從數據存儲層直接查詢。




• 即席查詢一般是通過SQL完成，最大的難度在於響應速度上，使用Hive有點慢，目前我的解決方案是SparkSQL，它的響應速度較Hive快很多，而且能很好的與Hive兼容。




• 當然，你也可以使用Impala，如果不在乎平台中再多一個框架的話。




• OLAP




• 目前，很多的OLAP工具不能很好的支持從HDFS上直接獲取數據，都是通過將需要的數據同步到關系型資料庫中做OLAP，但如果數據量巨大的話，關系型資料庫顯然不行；




• 這時候，需要做相應的開發，從HDFS或者HBase中獲取數據，完成OLAP的功能；




• 比如：根據用戶在界面上選擇的不定的維度和指標，通過開發介面，從HBase中獲取數據來展示。




• 其它數據介面
  




• 這種介面有通用的，有定製的。比如：一個從Redis中獲取用戶屬性的介面是通用的，所有的業務都可以調用這個介面來獲取用戶屬性。





• 實時計算現在業務對數據倉庫實時性的需求越來越多，比如：實時的了解網站的整體流量；實時的獲取一個廣告的曝光和點擊；在海量數據下，依靠傳統資料庫和傳統實現方法基本完成不了，需要的是一種分布式的、高吞吐量的、延時低的、高可靠的實時計算框架；Storm在這塊是比較成熟了，但我選擇Spark Streaming，原因很簡單，不想多引入一個框架到平台中，另外，Spark Streaming比Storm延時性高那麼一點點，那對於我們的需要可以忽略。




• 我們目前使用Spark Streaming實現了實時的網站流量統計、實時的廣告效果統計兩塊功能。




• 做法也很簡單，由Flume在前端日誌伺服器上收集網站日誌和廣告日誌，實時的發送給Spark Streaming，由Spark Streaming完成統計，將數據存儲至Redis，業務通過訪問Redis實時獲取。




• 任務調度與監控在數據倉庫/數據平台中，有各種各樣非常多的程序和任務，比如：數據採集任務、數據同步任務、數據分析任務等；





• 這些任務除了定時調度，還存在非常復雜的任務依賴關系，比如：數據分析任務必須等相應的數據採集任務完成後才能開始；數據同步任務需要等數據分析任務完成後才能開始；這就需要一個非常完善的任務調度與監控系統，它作為數據倉庫/數據平台的中樞，負責調度和監控所有任務的分配與運行。




• 前面有寫過文章，《大數據平台中的任務調度與監控》,這里不再累贅。




• 總結在我看來架構並不是技術越多越新越好，而是在可以滿足需求的情況下，越簡單越穩定越好。目前在我們的數據平台中，開發更多的是關注業務，而不是技術，他們把業務和需求搞清楚了，基本上只需要做簡單的SQL開發，然後配置到調度系統就可以了，如果任務異常，會收到告警。這樣，可以使更多的資源專注於業務之上。

❸ 如何做成一個DBA，有沒有好的學習計劃

一、DBA技術
1、作為一個DBA，你必須要精通SQL命令、各種資料庫架構、資料庫管理和維護、資料庫調優，必要的時候，還需要為開發人員搭建一個健壯、結構良好、性能穩定的資料庫環境。
2、資料庫是構建在操作系統之上的，你還需要精通系統技術。當然，完全不必要學習系統管理員那樣高深的技術理論。
3、你還需要掌握伺服器硬體、軟體技術理論。便於資料庫基於伺服器問題出現的時候，能夠及時提出解決方案。
4、還要理解資料庫在伺服器、系統軟體中如何實現和運作的。

二、了解DBA職責：
1、監視資料庫。
2、記錄和統計系統和性能的表現技術信息。
3、構造資料庫框架、配置資料庫實例。
4、維護資料庫網路安全，過濾非法查詢信息。
5、及時備份資料庫
6、利用備份，還原資料庫，甚至是遷移資料庫。
7、為開發人員定製、配置專用的測試伺服器。
8、資料庫技術最新的研發方向。
9、資料庫調優。
10、完整熟悉資料庫操作流程。
11、診斷資料庫，找出資料庫的不足之處和生成資料庫解決方案。
12、完整培訓資料庫系統那個環境。
13、與系統管理員保持良好的合作關系。
14、創建有效的、定期維護的安全的資料庫。
三、初級DBA學習
1、關系資料庫理論
這是很多DBA的入門基礎理論。目前市場上主流的資料庫都是關系型資料庫，當然關系型資料庫理論也成為了DBA的基礎技術理論。只有對於關系型資料庫理論達到了一個層次，對於關系型資料庫管理系統(RDBMS)才能更好地應用，無論是Oracle資料庫，IBM的DB2，還是微軟的SQL Server。目前，很多的大學都有關系型資料庫理論的課程。推薦一本關系型資料庫理論書籍，Elmasri and Navathe編寫的資料庫系統基礎，Bejamin/Cummings Press。
2、系統學習SQL語句
對於DBA而言，使用得最多的還是SQL查詢語句。因此，掌握SQL語言是非常必要的。只有當SQL查詢語言，成為了一種你DBA生涯的職業習慣的時候，你才能真正意義上成為合格的DBA。在目前所有的資料庫中，SQL查詢語言全部通用。本質上來講，SQL查詢語言是DBA和資料庫交互的必要工具。這里有一本非常好的書籍，《Oracle Database 11g完全參考手冊》，屬於DBA非常重要的技術參考文檔。
3、逐漸參與基本的資料庫管理工作
對於資料庫管理而言，有兩本比較好的書籍，《Oracle Database 11g DBA手冊》和《Oracle Database 11g備份與恢復指導》。這都是Oracle比較好的技術文檔，同時也是基本的資料庫管理工作的理論基礎。對於DBA而言，關系型資料庫理論和SQl查詢語言理論是DBA真正的技術理論基礎，資料庫管理工作更多的時候只是一種工具。而且，實踐才是檢驗和提高DBA技術的唯一標准。從資料庫日常管理工作中學習，從實踐中提高，才是DBA成長的唯一出路。
4、繼續學習資料庫技術
參與Oracle培訓，獲得Oracle認證其實對於DBA而言，還遠遠不夠。IT行業是一個技術更新速度非常頻繁的行業。而DBA行業的技術更新，更是遠勝於IT行業。以Oracle為代表的資料庫廠商，都投入了大量的資金和資源到技術研發中去，Oracle的技術基本都是每三個就會進行一次大的更新。這也是很多的Oracle官方培訓機構普遍採用PDF電子教材的根本原因所在。去閱讀，去學習，去不斷豐富自己的技術理論和實踐能力。
5、不斷嘗試參與案例
對於DBA而言，日常的資料庫管理工作，還只是基本職能之一。要想在DBA行業走得更遠，豐富自己的技術實力才是王道。所以，嘗試不斷地去測試案例，不斷地去資料庫中尋找疑難雜症，不斷地提出解決方案，從眾多的解決方案中尋找優秀的方案，吸取經驗，也是DBA學習的另外一種非常有效的手段。畢竟，日常的資料庫管理都不會遇到太多的問題，需要自己去創建模型，自己去創建案例。當然，如果日常管理的資料庫都能不斷出現各種各樣的問題，那說明你在DBA的道路上，還仍重而道遠。
6、尋找良師
在DBA行業發展，一個優秀的引路人是DBA生涯最好的指明燈。他們往往能夠在你的DBA生涯中，給予你比較寶貴的建議，傳授給你比較好的經驗的積累，使你在DBA的道路上，盡可能少地走彎路。
7、參與本地討論組
目前，各種交互平台上，DBA技術討論組非常多，甚至還有很多跨城市、跨國家的用戶討論組。這其中，本地討論組是一種非常好的資源，很多時候還會舉行線下的聚會，討論資料庫相關的話題。
四、中級DBA進階
請記住，SQL語言、關系型資料庫理論和基本的資料庫管理任務，是作為一名初級DBA所必備的技術理論和實踐基礎。如果你已經成為初級DBA，並確信掌握了上面三種技術，而且也開始厭倦不斷地閱讀技術文檔。那麼接下來的建議將帶你進入中級DBA的技術殿堂。
1、學習操作系統和伺服器硬體
我們知道，資料庫是建立在操作系統和伺服器硬體之上的。操作系統，作為硬體和資料庫之間交互的中間層，在日常的資料庫維護工作中，也是經常遇到諸多疑難雜症的。如果是Unix操作系統則需要熟悉和掌握Unix命令行語句。如果是Windows Server操作系統，則需要學習操作系統的維護、管理和優化。當然，作為承載資料庫和操作系統的伺服器硬體，也是很有必要的。
2、學習一門開發語言
對於資料庫而言，並不是單獨存在的。作為後台運行的資料庫，很多時候都有前端的操作界面和功能的實現。畢竟，並不是所有的軟體開發者都精通資料庫編程。特別在一些大型的IT企業，DBA往往都需要和軟體開發程序員合作，搭建軟體運行和數據存儲的後台資料庫。學習一門開發語言，能夠讓你很好地理解資料庫開發在程序設計中的意義和作用。並能在和軟體開發程序員的合作中，更好地實現程序員理想的功能。
3、取得認證
對於已經成為DBA的你而言，認證將不再作為DBA行業的敲門磚。更多的時候，認證對於初級DBA而言，是一種學習的過程，同時也是自我價值的實現過程。同時，在參與認證考試的時候，也能夠從和其他DBA的交流中，學習一些從未接觸過的技術或者經驗。
成為一名中級DBA，OCP(Oracle Certified Professional)是你必須考取的認證。作為資料庫行業的大佬，Oracle的技術實力是不言而喻的。而且，DBA行業的最高級別認證，也是屬於Oracle認證體系的。
更重要的是，取得一門認證，對於你的DBA生涯的發展而言，是大有裨益的。所以，去取得認證吧。
4、獲得技術資源庫
對於DBA而言，Technet賬戶是必須的。這是眾多DBA少有的技術、資源交流聚集地。在共享Oracle知識，分享Oracle資源的同時，也能夠尋找並獲取對你而言有價值的Oracle資源。
5、更多的交流
隨著新一代互聯網技術的興起和發展，越來越多的新奇的交互手段層出不窮。即時交流工具、新聞組、論壇、irc、聊天室，都可以成為DBA們交流的舞台。但是，傳統的新聞組和論壇，依然保有無可比擬的技術優勢，可以回答你提出的資料庫問題。真正優秀的交流社區，資料庫高手們是樂意與你分享他們的技術經驗的。
Usenet newsgroup------comp.databases.oracle.server和comp.databases.oracle.misc，這是兩個世界性的Oracle資料庫技術新聞組。當然，需要比較好的英文功底。
Quest Pipelines------中等的Pipelines，筆者的最愛。
五、成就高級DBA
高級DBA更多的時候，被人成為資料庫專家。經過長期的學習和實踐，你已經准備好像高級DBA發起沖刺了。如果准備好了，下面的內容將幫你在DBA的道路上走得更遠。
1、閱讀資料庫技術文檔
對於DBA而言，真正的技術寶庫，就是資料庫廠商給出的官方技術文檔幾乎所以的技術理論都涵蓋到這些技術文檔中。而且，原版的技術文章更具價值。目前市面上，幾乎所有的資料庫書籍都是技術文檔的解讀。當然，這需要你有過硬的英文閱讀能力。而且，每個版本的技術文檔都有區別。Oracle Database 11g就在Oracle Database 10g的基礎上，加入了11g的新特徵和新技術。當然，有的高級DBA並沒有讀過技術文檔，這在很大程度上，只是特例。如果一個版本的技術文檔，你通讀至少12次以上，相信每次都會有新的感悟，你也會逐漸了解到資料庫真正的技術核心價值。
2、探尋各個領域的專家之路
高級DBA幾乎是資料庫領域真正的專家。而涉及到資料庫領域，備份與恢復、調優等領域很多。從最簡單的開始，嘗試了解全部的技術手段和解決問題方案，嘗試成為這個領域的專家。之後再逐漸擴展到其他領域。對於IT行業而言，技術更新換代的速度非常快，而以Oracle為代表的資料庫廠商，都擁有自己強大的資料庫技術研發團隊。幾乎每3個月，Oracle技術就會更新一次。去學習，保持技術水平的領先性，你一定能成為資料庫專家。
3、繼續參與社會化媒體的討論
經過長期的學習和實踐，相信你已經積累了自己的社會化媒體DBA技術交流平台。積極地去參與資料庫技術討論，將會讓你在DBA的道路上走得更遠。如果一個平台沒有什麼有價值的技術討論，不妨嘗試換一個平台。
4、總結自己的技術經驗
學習只是一個成長的經歷，總結才能在不斷學習中，找出自己的不足之處。所以，以學技術白皮書的方式，去嘗試總結自己多年來所學到的技術和積累的經驗。不斷梳理資料庫技術和理論架構，你會發現，自己技術的不足之處很難有所建樹。針對這些不足之處可以適當得強化和提高。當你嘗試總結的時候，你會吃驚地發現，曾經都快遺忘的技術理論又開始出現在腦海里，這是非常美妙的體驗。
5、成為Oracle解決方案專家
對於DBA而言，不斷積累遇到的資料庫問題，甚至是故意破壞資料庫以探尋資料庫疑難問題，是每個DBA幾乎都要經歷的過程。高級DBA基本都是Oracle解決方案專家，能夠根據Oracle資料庫出現各種問題，很快地提出解決方案。
6、成為Oracle性能調優專家
Oracle資料庫日常問題的解決、性能優化，幾乎成為了每個僱用DBA企業都十分關注的問題。性能調優對於企業而言，能夠在很大程度上節約企業的成本。一個Oracle性能調優專家能夠在很大程度上，以最優的Oracle資料庫解決方案來實現最好的Oracle資料庫存儲。
7、成為承載能力計劃專家
評估一個資料庫的承載能力，幾乎成為了高級DBA的必修課。如何准確預估數據增長量、交易增長量，從而更好的規劃、設計資料庫的承載能力，以最優的軟硬體配置實現企業利益的最大化，這才是高級DBA的價值所在。
8、關注新技術
雖然，在國內，新技術的實現需要一段很長的時間。但是，盡早掌握資料庫新技術，對於高級DBA而言是非常必要的。總有大型的企業，需要不斷革新和改進自己的資料庫技術，這就要求高級DBA不斷關注新技術，學習新技術。