日韩精品一区二区亚洲下载,91精品成人自产拍在线观看,久久91视频观看

大數據時代，越來越多的組織轉型為數據驅動型組織。這類組織的特點是以數據挖掘商業價值，從而驅動企業做出正確的商業決策。然而，如何有效分析數據并挖掘出其商業價值仍然困擾著諸多企業，誠如管理大師彼得?德魯克(Peter Drucker)曾經的感慨：“迄今為止，我們的信息技術產生的還僅僅是數據，而不是信息、更不是知識！” 數據倉庫——商務智能的基石 Gartner在1996年提出商務智能（Business Intelligence）這一概念，并吸引了越來越多的企業關注和投入。在Gartner的一項關于CIO在2018年新增額外支出的優先技術的調查中，有18%的政府和公共部門的CIO表示將增加企業在商務智能和分析方面的支出。Gartner的另一項商務智能報告也指出，到2020年全球的商務智能市場容量預計將達到228億美元。說到這里，想必大家有些疑問：甲骨文不是另有專門提供商務智能分析相關的云應用和解決方案嗎？沒錯，但老P今天要談的不是應用層面，而是希望從中間平臺層和底層基礎架構的自動化技術所能為商務智能提供的價值來探討一二。原因很簡單，商務智能必須依托于數據倉庫。數據倉庫為海量數據分析提供了核心物理架構，它匯總了各種來源的關鍵信息，并以結構化的方式存儲起來，供商務智能和分析工具使用。特別是對于需要快速制定決策的數據驅動型組織，數據倉庫停運、運行變慢或信息供給缺乏所帶來的后果不言而喻。   在談數據倉庫實現之前，老P希望和大家澄清兩個概念：數據倉庫和數據展現。數據展現比較容易理解，就是將數據用各種方式展現出來，例如在醫院，我們可以用數據展現某種疾病的治愈時間，進一步，我們可以展現在使用了一種新藥后這種疾病的治愈時間，再進一步，可以展現該種疾病在使用了新藥并且做手術以后病人的治愈時間。無論用幾個維度，其核心是展現。而數據倉庫要告訴你過去為什么發生這樣的事，今后可能發生怎樣的事。數據倉庫的難點不僅僅是數據處理，還包括數據處理和業務的高度融合，只懂其中一項是不行的。傳統的數據倉庫實施時間是按年來計算的，而且投資巨大。而Oracle自治數據倉庫云就是把數據處理的門檻降到很低，不需要高深的數據處理背景的技術人員和巨大的初始投資，而把這一切都交給Oracle Cloud。 當數據倉庫云實現自治 今年3月底，Larry Ellison在美國發布了Oracle自治數據倉庫云。這是全球首款自治管理、自治安全和自治修復數據庫云服務，利用機器學習來實現和提供業界領先的性能、安全能力和可用性，而且整個過程無需人工干預。<img src="https://img.togogo.net/tggPic/content/2018-09/1536205972356.jpg" data-ke-src="https://img.togogo.net/tggPic/content/2018-09/1536205972356.jpg" alt=""> Oracle數據庫具備的分析能力、安全功能和高可用性都在自治數據倉庫云中得以充分體現。即使在倉儲工作負載和數據量發生變化時，也無需任何復雜的配置、調優和管理。<ul class="list-paddingleft-2" style="color:#333333;font-family:-apple-system-font, BlinkMacSystemFont, "font-size:17px;text-align:justify;background-color:#FFFFFF;"><li>自治管理——無需人工進行數據庫的建立、安全防護、監測、備份、恢復、故障排除和調優，同時也避免了人為錯誤。可在運行時自動升級和打補丁。</li><li>自治安全——自動防御外部攻擊及防治惡意的內部用戶。可在運行時自動進行安全更新，以防止網絡攻擊，也可自動加密所有數據。</li><li>自治修復——自動進行計劃和非計劃的停機保護，可用性高達99.995%，包括計劃性維護在內，每月停機時間不超過2.5分鐘。</li></ul>隨著我們越來越多地關注到人工智能、區塊鏈、物聯網等新興科技的爆發和廣泛運用，落實到科技的本質來講，技術始終是要賦能于人的。而“自治”技術可以實現無需人工管理、修復和防御保護。我們可以很自信地說，甲骨文用“自治”印證了：科技是人的延伸。而Oracle自治數據倉庫云作為最新推出的“自治”產品，當然可以列為與新興技術充分融合的甲骨文“紅科技”中的一員大將。它以技術創新為企業的數字化、自動化、智能化轉型發展提供了源源不斷的動力。具體來說，它的面世解決了企業兩大核心問題：解放勞動力，釋放商業價值。 自治調優可解放勞動力 傳統的數據倉庫需要管理員進行深度介入，但Oracle自治數據倉庫云的面世將改變這一現狀，數據倉庫需要大量人力介入的特點將會發生變化。例如，數據庫管理員日常都面臨著一大挑戰：如何自動生成存儲索引，讓應用程序快速提取日常報告或即席查詢所需的數據？現在，Oracle自治數據倉庫云則無需數據庫管理員手動調優或者干預，就可自動、透明并持續地生成索引。此外，企業還能受益于Oracle自治數據倉庫云的自動擴展功能。Oracle自治數據倉庫云可讓客戶靈活調用CPU：在高強度使用期間調用更多的CPU，在峰值需求結束后可選擇縮減規模，甚至徹底關閉處理功能。如此一來，企業僅需支付存儲費用，有效消除了額外成本。 讓人力真正發揮其價值 說到這里，可能有人會疑惑了：“性能優化、自治修復、自治安全、擴大和收縮CPU——這些特性都十分有益于企業。那么可憐的數據庫管理員怎么辦？他們將會被取代嗎？”老P很負責地告訴你：“當然不會。因為他們終于可以去做之前積壓的工作，真正發揮自己的價值！”讓我們來捋清數據庫管理員的日常工作：一是與企業業務無關的工作，這在所有數據庫中都很常見，包括數據倉庫。二是與企業業務有關的工作。Oracle自治數據倉庫云可讓數據庫管理員“有所為，有所不為”地工作。什么是“有所不為”？是他們不再承擔配置、調優、部署、備份和優化這些與企業業務無直接關系的工作。什么是“有所為”？是指數據庫管理員可以把精力放在與企業業務有關的工作上，包括數據建模、集成新的數據來源、應用程序調優和端到端服務水平管理等。然而，數據安全仍然需要得到管理。就此而言，甲骨文負責給數據倉庫打補丁，但不偷看客戶的數據。這意味著數據庫管理員仍然需要知道數據在哪里，它們代表什么，哪些人、哪些應用程序可以看哪些數據信息。所以，數據庫管理員仍然有很多工作需要做，現在還不用急著寫求職簡歷。對于很多企業高管來說，Oracle自治數據倉庫云可以進一步優化可用性和性能，不僅讓企業將人才的價值發揮在真正需要的地方，更讓它們輕松地管理和使用數據，做到數據驅動商業決策。我們有理由相信，這場自動化技術革新，必將帶來更為杰出的商務智能。

1984 年，Rob Pike 和 Brian W. Kernighan 在 AT&T 貝爾實驗室技術期刊上發表了名為 “Unix 環境編程[1]” 的文章，其中他們使用 BSD 的 cat -v 例子來認證 Unix 哲學。簡而言之，Unix 哲學是：構建小型、單一的應用程序 —— 不管用什么語言 —— 只做一件小而美的事情，用 stdin / stdout 進行通信，并通過管道進行連接。聽起來是不是有點耳熟？是的，我也這么認為。這就是 James Lewis 和 Martin Fowler 給出的 微服務的定義[2] 。<blockquote style="color:#333333;font-family:Optima-Regular, PingFangTC-light;font-size:14px;text-align:justify;">簡單來說，微服務架構的風格是將單個應用程序開發為一套小型服務的方法，每個服務都運行在它的進程中，并用輕量級機制進行通信，通常是 HTTP 資源 API 。</blockquote>雖然一個 *nix 程序或者是一個微服務本身可能非常局限甚至不是很有用，但是當這些獨立工作的單元組合在一起的時候就顯示出了它們真正的好處和強大。*nix程序 vs 微服務下面的表格對比了 *nix 環境中的程序（例如 cat 或 lsof）與微服務環境中的程序。< 如顯示不全，請左右滑動 ><table cellpadding="4" width="694" style="margin:0px 0px 10px;padding:0px;width:378px;"><tbody><tr><th style="text-align:left;font-weight:400;background:#F7F7F7;"> </th><th style="text-align:left;font-weight:400;background:#F7F7F7;">*nix 程序</th><th style="text-align:left;font-weight:400;background:#F7F7F7;">微服務</th></tr></tbody><tbody><tr><td style="border:1px solid #DDDDDD;">執行單元</td><td style="border:1px solid #DDDDDD;">程序使用 stdin/stdout</td><td style="border:1px solid #DDDDDD;">使用 HTTP 或 gRPC API</td></tr><tr><td style="border:1px solid #DDDDDD;">數據流</td><td style="border:1px solid #DDDDDD;">管道</td><td style="border:1px solid #DDDDDD;">？</td></tr><tr><td style="border:1px solid #DDDDDD;">可配置和參數化</td><td style="border:1px solid #DDDDDD;">命令行參數、環境變量和配置文件</td><td style="border:1px solid #DDDDDD;">JSON/YAML 文檔</td></tr><tr><td style="border:1px solid #DDDDDD;">發現</td><td style="border:1px solid #DDDDDD;">包管理器、man、make</td><td style="border:1px solid #DDDDDD;">DNS、環境變量、OpenAPI</td></tr></tbody></table>讓我們詳細的看看每一行。執行單元*nix 系統（如 Linux）中的執行單元是一個可執行的文件（二進制或者是腳本），理想情況下，它們從 stdin 讀取輸入并將輸出寫入 stdout。而微服務通過暴露一個或多個通信接口來提供服務，比如 HTTP 和 gRPC API。在這兩種情況下，你都會發現無狀態示例（本質上是純函數行為）和有狀態示例，除了輸入之外，還有一些內部（持久）狀態決定發生了什么。數據流傳統的，*nix 程序能夠通過管道進行通信。換句話說，我們要感謝 Doug McIlroy[3]，你不需要創建臨時文件來傳遞，而可以在每個進程之間處理無窮無盡的數據流。據我所知，除了我在 2017 年做的基于 Apache Kafka 小實驗[4]，沒有什么能比得上管道化的微服務了。可配置和參數化你是如何配置程序或者服務的，無論是永久性的服務還是即時的服務？是的，在 *nix 系統上，你通常有三種方法：命令行參數、環境變量，或全面的配置文件。在微服務架構中，典型的做法是用 YAML（或者甚至是 JSON）文檔，定制好一個服務的布局和配置以及依賴的組件和通信、存儲和運行時配置。例如 Kubernetes 資源定義[5]、Nomad 工作規范[6] 或 Docker 編排[7] 文檔。這些可能參數化也可能不參數化；也就是說，除非你知道一些模板語言，像 Kubernetes 中的 Helm[8]，否則你會發現你使用了很多 sed -i 這樣的命令。發現你怎么知道有哪些程序和服務可用，以及如何使用它們？在 *nix 系統中通常都有一個包管理器和一個很好用的 man 頁面；使用它們，應該能夠回答你所有的問題。在微服務的設置中，在尋找一個服務的時候會相對更自動化一些。除了像 Airbnb 的 SmartStack[9] 或 Netflix 的 Eureka[10] 等可以定制以外，通常還有基于環境變量或基于 DNS 的方法[11]，允許您動態的發現服務。同樣重要的是，事實上 OpenAPI[12] 為 HTTP API 提供了一套標準文檔和設計模式，gRPC[13] 為一些耦合性強的高性能項目也做了同樣的事情。最后非常重要的一點是，考慮到開發者經驗（DX），應該從寫一份好的 Makefile[14] 開始，并以編寫符合 風格[15] 的文檔結束。優點和缺點*nix 系統和微服務都提供了許多挑戰和機遇。模塊性要設計一個簡潔、有清晰的目的，并且能夠很好地和其它模塊配合的某個東西是很困難的。甚至是在不同版本中實現并引入相應的異常處理流程都很困難的。在微服務中，這意味著重試邏輯和超時機制，或者將這些功能外包到服務網格service mesh是不是一個更好的選擇呢？這確實比較難，可如果你做好了，那它的可重用性是巨大的。可觀測性在一個獨石monolith（2018 年）或是一個試圖做任何事情的大型程序（1984 年），當情況惡化的時候，應當能夠直接的找到問題的根源。但是在一個 <pre class=""><ol class="list-paddingleft-2"><li>yes | tr \\n x | head -c 450m | grep n</li></ol></pre> 或者在一個微服務設置中請求一個路徑，例如，涉及 20 個服務，你怎么弄清楚是哪個服務的問題？幸運的是，我們有很多標準，特別是 OpenCensus[16] 和 OpenTracing[17]。如果您希望轉向微服務，可預測性仍然可能是較大的問題。全局狀態對于 *nix 程序來說可能不是一個大問題，但在微服務中，全局狀態仍然是一個需要討論的問題。也就是說，如何確保有效的管理本地化（持久性）的狀態以及盡可能在少做變更的情況下使全局保持一致。總結一下最后，問題仍然是：你是否在使用合適的工具來完成特定的工作？也就是說，以同樣的方式實現一個特定的 *nix 程序在某些時候或者階段會是一個更好的選擇，它是可能在你的組織或工作過程中的一個最好的選擇[18]。無論如何，我希望這篇文章可以讓你看到 Unix 哲學和微服務之間許多強有力的相似之處。也許我們可以從前者那里學到一些東西使后者受益。

首頁

關于騰科

騰科師資

學員天地

技術家園

企培定制

新聞中心

聯系我們

友情鏈接