大數據統一sql介面服務

Ⅰ 大數據正在如何改變資料庫格局

大數據正在如何改變資料庫格局

提及「資料庫」，大多數人會想到擁有30多年風光歷史的RDBMS。然而，這可能很快就會發生改變。

一大批新的競爭者都在爭奪這一塊重要市場，他們的方法是多種多樣的，卻都有一個共同點：極其專注於大數據。推動新的數據迭代衍生品大部分都是基於底層大數據的3V特徵：數量，速度和種類。本質上來講，今天的數據比以往任何時候都要傳輸更快，體積更大，同時更加多樣化。這是一個新的數據世界，換言之，傳統的關系資料庫管理系統並沒有真正為此而設計。「基本上，他們不能擴展到大量，或快速，或不同種類的數據。」一位數據分析、數據科學咨詢機構的總裁格雷戈里認為。這就是哈特漢克斯最近發現。截至到2013年左右，營銷服務機構使用不同的資料庫，包括MicrosoftSQLServer和Oracle真正應用集群（RAC）的組合。「我們注意到，數據隨著時間的增長，我們的系統不能足夠快速的處理信息」一位科技發展公司的負責人肖恩說到。「如果你不斷地購買伺服器，你只能繼續走到這幺遠，我們希望確保自己有向外擴展的平台。」最小化中斷是一個重要的目標，Iannuzzi說到，因逗首此「我們不能只是切換到Hadoop。」相反，卻選擇了拼接機器，基本上把完整的SQL資料庫放到目前流行的Hadoop大數據平台之上，並允許現有的應用程序能夠與它連接，他認為。哈特漢克斯現在是在執行的初期階段，但它已經看到了好處，Iannuzzi說，包括提高容錯性，高可用性，冗餘性，穩定性和「性能全面提升」。一種完美風暴推動了新的資料庫技術的出現，IDC公司研究副總裁CarlOlofson說到。首先，「我們正在使用的設備與過去對比，處理大數據集更加快速，靈活性更強」Olofson說。在過去，這樣的集合「幾乎必須放在旋轉磁碟上」，而且數據必須以特定的方式來結構化，他解釋說。現在有64位定址，使得能夠設置更大的存儲空間以及更快的網路，並能夠串聯多台計算器充當單個大型資料庫。「這些東西在不可用之前開辟了可能性」Olofson說。與此同時，工作負載也發生了變化。10年前的網站主要是靜態的，例如，今天我們享受到的網路服務環境和互動式購物體驗。反過來，需要新的可擴展性，他說。公司正在利用新的方式來使用數據。雖然傳統上我們大部分的精力都放在了對事務處理_銷售總額的記錄，比如，數據存儲在可以用來分析的地方_現在我們做的更多。應用狀態管理就是一個例子假設你正在玩一個網路游戲。該技術會記錄你與系統的每個會話並連接在一起，以呈現出連續的體驗，即使你切換設備或各種移動，不同的伺服器都會進行處理，Olofson解釋說。數據必須保持連續性，這樣企業才可以分析問題，例如「為什麼從來沒有人穿過水晶廳」。在網路購物方面，為什麼對方點擊配坦選擇顏色後大多數人不會購買某個特殊品牌的鞋子。「以前，我們並沒試圖解決這些問題，或者我們試圖扔進盒子也不太合適」Olofson說。Hadoop是當今新的競爭者中一個重量級的產品。雖然他本身不是一個資料庫，它的成長為企業解決大數據扮演關鍵角色。從本質上講，Hadoop是一個運行高度並行應用程序的數據中心平台，它有很強的可擴展性。通過允許企業擴展「走出去」的分布方式，而不是通過額外昂貴的伺服器「向上」擴展，「它使得我們可以低成本地把一個大的數據集匯總，然後進行分析研究成果」Olofson說。其他新的RDBMS的替代品如NoSQL家族產品，其中包括MongoDB-目前第四大流行資料庫管理系統，比照DB引擎山賣數和MarkLogic非結構化數據存儲服務。「關系型資料庫一直是一項偉大的技術持續了30年，但它是建立在不同的時代有不同的技術限制和不同的市場需求，」MarkLogic的執行副總裁喬·產品帕卡說。大數據是不均勻的，他說。許多傳統的技術，這仍然是一個基本要求。「想像一下，你的筆記本電腦上唯一的程序是Excel」帕卡說。「設想一下，你要和你的朋友利用網路保持聯系_或者你正在寫一個合約卻不適合放進行和列中。」拼接數據集是特別棘手的「關系型，你把所有這些數據集中在一起前，必須先決定如何去組織所有的列，」他補充說。「我們可以採取任何形式或結構，並立即開始使用它。」NoSQL資料庫沒有使用關系數據模型，並且它們通常不具有SQL介面。盡管許多的NoSQL存儲折中支持速度等其他因素，MarkLogic為企業定身量做，提供更為周全的選擇。NoSQL儲存市場有相當大的增長，據市場研究媒體，不是每個人都認為這是正確的做法-至少，不是在所有情況下。NoSQL系統「解決了許多問題，他們橫向擴展架構，但他們卻拋出了SQL，」一位CEO-MonteZweben說。這反過來，又為現有的代碼構成問題。SpliceMachine是一家基於Hadoop的實時大數據技術公司，支持SQL事務處理，並針對OLAP和OLAP應用進行實時優化處理。它被稱為替代NewSQL的一個例子，另一類預期會在未來幾年強勁增長。「我們的理念是保持SQL，但橫向擴展架構」Zweben說。「這是新事物，但我們正在努力試圖使它讓人們不必重寫自己的東西。」深度信息科學選擇並堅持使用SQL，但需要另一種方法。公司的DeepSQL資料庫使用相同的應用程序編程介面（API）和關系模型如MySQL，意味著沒有應用變化的需求而使用它。但它以不同的方式處理數據，使用機器學習。DeepSQL可以自動適應使用任何工作負載組合的物理，虛擬或雲主機，該公司表示，從而省去了手動優化資料庫的需要。該公司的首席戰略官ChadJones表示，在業績大幅增加的同時，也有能力將「規模化」為上千億的行。一種來自Algebraix數據完全不同的方式，表示已經開發了數據的第一個真正的數學化基礎。而計算器硬體需在數學建模前建成，這不是在軟體的情況下，Algebraix首席執行官查爾斯銀說。「軟體，尤其是數據，從未建立在數學的基礎上」他說，「軟體在很大程度上是語言學的問題。」經過五年的研發，Algebraix創造了所謂的「數據的代數」集合論，「數據的通用語言」Silver說。「大數據骯臟的小秘密是數據仍然放在不與其他數據小倉融合的地方」Silver解釋說。「我們已經證明，它都可以用數學方法來表示所有的集成。」配備一個基礎的平台，Algebraix現在為企業提供業務分析作為一種服務。改進的性能，容量和速度都符合預期的承諾。時間會告訴我們哪些新的競爭者取得成功，哪些沒有，但在此期間，長期的領導者如Oracle不會完全停滯不前。「軟體是一個非常時尚行業」安德魯·門德爾松，甲骨文執行副總裁資料庫伺服器技術說。「事情經常去從流行到不受歡迎，回再次到流行。」今天的許多創業公司「帶回炒冷飯少許拋光或旋轉就可以了」他說。「這是一個新一代孩子走出學校和重塑的東西。」SQL是「唯一的語言，可以讓業務分析師提出問題並得到答案，他們沒有程序員，」門德爾松說。「大市場將始終是關系型。」至於新的數據類型，關系型資料庫產品早在上世紀90年代發展為支持非結構化數據，他說。在2013年，甲骨文的同名資料庫版本12C增加了支持jsON（javaScript對象符號）。與其說需要一個不同類型的資料庫，它更是一種商業模式的轉變，門德爾松說。「雲，若是每個人都去，這將破壞這些小傢伙」他說。「大家都在雲上了，所以在這里有沒有地方來放這些小傢伙？「他們會去亞馬遜的雲與亞馬遜競爭？」他補充說。「這將是困難的。」甲骨文有「最廣泛的雲服務」門德爾松說。「在現在的位置，我們感覺良好。」Gartner公司的研究主任里克·格林沃爾德，傾向於採取了類似的觀點。「對比傳統強大的RDBMS，新的替代品並非功能齊全」格林沃爾德說。「一些使用案例可以與新的競爭者來解決，但不是全部，並非一種技術」。展望未來，格林沃爾德預計，傳統的RDBMS供貨商感到價格壓力越來越大，並為他們的產品增加新的功能。「有些人會自由地帶來新的競爭者進入管理自己的整個數據生態系統」他說。至於新的產品，有幾個會生存下來，他預測「許多人將被收購或資金耗盡」。今天的新技術並不代表傳統的RDBMS的結束，「正在迅速發展自己」IDC的Olofson。贊成這種說法，「RDBMS是需要明確定義的數據_總是會有這樣一個角色。」但也會有一些新的競爭者的角色，他說，特別是物聯網技術和新興技術如非易失性內存晶元模塊（NVDIMM）占據上風。

Ⅱ SQLSERVER大資料庫解決方案

在微軟的大數據解決方案中，數據管理是最底層和最基礎的一環。

靈活的數據管理層，可以支持所有數據類型，包括結構化、半結構化和非結構化的靜態或動態數據。

在數據管理層中主要包括三款產品：SQLServer、SQLServer並行數據倉庫和

Hadoop on Windows。

針對不同的數據類型，微軟提供了不同的解決方案。

具體來說，針對結構化數據可以使用SQLServer和SQLServer並行數據倉庫處理。

非結構化數據可以使用Windows Azure和WindowsServer上基於Hadoop的發行版本處理;而流數據可以使用SQLServerStreamInsight管理，並提供接近實時的分析。

1、SQLServer。去年發布的SQLServer2012針對大數據做了很多改進，其中最重要的就是全面支持Hadoop，這也是SQLServer2012與SQLServer2008最重要的區別之一。今年年底即將正式發布的SQLServer2014中，SQLServer進一步針對大數據加入內存資料庫功能，從硬體角度加速數據的處理，也被看為是針對大數據的改進。

2、SQLServer並行數據倉庫。並行數據倉庫(Parallel Data Warehouse Appliance，簡稱PDW)是在SQLServer2008 R2中推出的新產品，目前已經成為微軟主要的數據倉庫產品，並將於今年發布基於SQLServer2012的新款並行數據倉庫一體機。SQLServer並行數據倉庫採取的是大規模並行處理(MPP)架構，與傳統的單機版SQLServer存在著根本上的不同，它將多種先進的數據存儲與處理技術結合為一體，是微軟大數據戰略的重要組成部分。

3、Hadoop on Windows。微軟同時在Windows Azure平台和WindowsServer上提供Hadoop，把Hadoop的高性能、高可擴展與微軟產品易用、易部署的傳統優勢融合到一起，形成完整的大數據解決方案。微軟大數據解決方案還通過簡單的部署以及與Active Directory和System Center等組件的集成，為Hadoop提供了Windows的易用性和可管理性。憑借Windows Azure上基於Hadoop的服務，微軟為其大數據解決方案在雲端提供了靈活性。

Ⅲ 技術干貨：SQL on Hadoop在快手大數據平台的實踐與優化

快手大數據架構工程師鍾靚近日在 A2M 人工智慧與機器學習創新峰會分享了題為《SQL on Hadoop 在快手大數據平台的實踐與優化》的演講，主要從 SQL on Hadoop 介紹、快手 SQL on Hadoop 平台概述、SQL on Hadoop 在快手的使用經驗和改進分析、快手 SQL on Hadoop 的未來計劃四方面介紹了 SQL on Hadoop 架構。

SQL on Hadoop，顧名思義它是基於 Hadoop 生態的一個 SQL 引擎架構，我們其實常常聽到 Hive、SparkSQL、Presto、Impala 架構。接下來，我會簡單的描述一下常用的架構情況。

HIVE，一個數據倉庫系統。它將數據結構映射到存儲的數據中，通過 SQL 對大規模的分布式存儲數據進行讀、寫、管理。

根據定義的數據模式，以及輸出 Storage，它會對輸入的 SQL 經過編譯、優化，生成對應引擎的任務，然後調度執行生成的任務。

HIVE 當前支持的引擎類型有：MR、SPARK、TEZ。

基於 HIVE 本身的架構，還有一些額外的服務提供方式，比如 HiveServer2 與 MetaStoreServer 都是 Thrift 架構。

此外，HiveServer2 提供遠程客戶端提交 SQL 任務的功能，MetaStoreServer 則提供遠程客戶端操作元數據的功能。

Spark，一個快速、易用，以 DAG 作為執行模式的大規模數據處理的統一分析引擎，主要模塊分為 SQL 引擎、流式處理 、機器學習、圖處理。

SPARKSQL 基於 SPARK 的計算引擎，做到了統一數據訪問，集成 Hive，支持標准 JDBC 連接。SPARKSQL 常用於數據交互分析的場景。

SPARKSQL 的主要執行邏輯，首先是將 SQL 解析為語法樹，然後語義分析生成邏輯執行計劃，接著與元數據交互，進行邏輯執行計劃的優化，最後，將邏輯執行翻譯為物理執行計劃，即 RDD lineage，並執行任務。

PRESTO，一個互動式分析查詢的開源分布式 SQL 查詢引擎。

因為基於內存計算，PRESTO 的計算性能大於有大量 IO 操作的 MR 和 SPARK 引擎。它有易於彈性擴展，支持可插拔連接的特點。

業內的使用案例很多，包括 FaceBook、AirBnb、美團等都有大規模的使用。

我們看到這么多的 SQL on Hadoop 架構，它側面地說明了這種架構比較實用且成熟。利用 SQL on Hadoop 架構，我們可以實現支持海量數據處理的需求。

查詢平台每日 SQL 總量在 70 萬左右，DQL 的總量在 18 萬左右。AdHoc 集群主要用於交互分析及機器查詢，DQL 平均耗時為 300s；AdHoc 在內部有 Loacl 任務及加速引擎應用，所以查詢要求耗時較低。

ETL 集群主要用於 ETL 處理以及報表的生成。DQL 平均耗時為 1000s，DQL P50 耗時為 100s，DQL P90 耗時為 4000s，除上述兩大集群外，其它小的集群主要用於提供給單獨的業務來使用。

服務層是對上層進行應用的。在上層有四個模塊，這其中包括同步服務、ETL 平台、AdHoc 平台以及用戶程序。在調度上層，同樣也有四方面的數據，例如服務端日誌，對它進行處理後，它會直接接入到 HDFS 里，我們後續會再對它進行清洗處理；服務打點的數據以及資料庫信息，則會通過同步服務入到對應的數據源里，且我們會將元數據信息存在後端元數據系統中。

網頁爬取的數據會存入 hbase，後續也會進行清洗與處理。

HUE、NoteBook 主要提供的是互動式查詢的系統。報表系統、BI 系統主要是 ETL 處理以及常見的報表生成，額外的元數據系統是對外進行服務的。快手現在的引擎支持 MR、Presto 及 Spark。

管理系統主要用於管理我們當前的集群。HiveServer2 集群路由系統，主要用於引擎的選擇。監控系統以及運維系統，主要是對於 HiveServer2 引擎進行運維。

我們在使用 HiveServer2 過程中，遇到過很多問題。接下來，我會詳細的為大家闡述快手是如何進行優化及實踐的。

當前有多個 HiveServer2 集群，分別是 AdHoc 與 ETL 兩大集群，以及其他小集群。不同集群有對應的連接 ZK，客戶端可通過 ZK 連接 HiveServer2 集群。

為了保證核心任務的穩定性，將 ETL 集群進行了分級，分為核心集群和一般集群。在客戶端連接 HS2 的時候，我們會對任務優先順序判定，高優先順序的任務會被路由到核心集群，低優先順序的任務會被路由到一般集群。

BeaconServer 服務為後端 Hook Server 服務，配合 HS2 中的 Hook，在 HS2 服務之外實現了所需的功能。當前支持的模塊包括路由、審計、SQL 重寫、任務控制、錯誤分析、優化建議等。

•無狀態，BeaconServer 服務支持水平擴展。基於請求量的大小，可彈性調整服務的規模。

•配置動態載入，BeaconServer 服務支持動態配置載入。各個模塊支持開關，服務可動態載入配置實現上下線。比如路由模塊，可根據後端加速引擎集群資源情況，進行路由比率調整甚至熔斷。

•無縫升級，BeaconServer 服務的後端模塊可單獨進行下線升級操作，不會影響 Hook 端 HS2 服務。

•Hive 支持 SPARK 與 TEZ 引擎，但不適用於生產環境。

•SQL on Hadoop 的 SQL 引擎各有優缺點，用戶學習和使用的門檻較高。

•不同 SQL 引擎之間的語法和功能支持上存在差異，需要大量的測試和兼容工作，完全兼容的成本較高。

•不同 SQL 引擎各自提供服務會給數倉的血緣管理、許可權控制、運維管理、資源利用都帶來不便。

•在 Hive 中，自定義實現引擎。

•自動路由功能，不需要設置引擎，自動選擇適合的加速引擎。

•根絕規則匹配 SQL，只將兼容的 SQL 推給加速引擎。

•復用 HiveServer2 集群架構。

基於 HiveServer2，有兩種實現方式。JDBC 方式是通過 JDBC 介面，將 SQL 發送至後端加速引擎啟動的集群上。PROXY 方式是將 SQL 下推給本地的加速引擎啟動的 Client。

JDBC 方式啟動的後端集群，均是基於 YARN，可以實現資源的分時復用。比如 AdHoc 集群的資源在夜間會自動回收，作為報表系統的資源進行復用。

路由方案基於 HS2 的 Hook 架構，在 HS2 端實現對應 Hook，用於引擎切換；後端 BeaconServer 服務中實現路由 服務，用於 SQL 的路由規則的匹配處理。不同集群可配置不同的路由規則。

為了保證後算路由服務的穩定性，團隊還設計了 Rewrite Hook，用於重寫 AdHoc 集群中的 SQL，自動添加 LIMIT 上限，防止大數據量的 SCAN。

•易於集成，當前主流的 SQL 引擎都可以方便的實現 JDBC 與 PROXY 方式。再通過配置，能簡單的集成新的查詢引擎，比如 impala、drill 等。

•自動選擇引擎，減少了用戶的引擎使用成本，同時也讓遷移變得更簡單。並且在加速引擎過載 的情況下，可以動態調整比例，防止因過載 對加速性能的影響。

•自動降級，保證了運行的可靠性。SQL 路由支持 failback 模塊，可以根據配置選擇是否再路由引擎執行失敗後，回滾到 MR 運行。

•模塊復用，對於新增的引擎，都可以復用 HiveServer2 定製的血緣採集、許可權認證、並發鎖控制等方案，大大降低了使用成本。

•資源復用，對於 adhoc 查詢佔用資源可以分時動態調整，有效保證集群資源的利用率。

當查詢完成後，本地會輪詢結果文件，一直獲取到 LIMIT 大小，然後返回。這種情況下，當有大量的小文件存在，而大文件在後端的時候，會導致 Bad Case，不停與 HDFS 交互，獲取文件信息以及文件數據，大大拉長運行時間。

在 Fetch 之前，對結果文件的大小進行預排序，可以有數百倍的性能提升。

示例：當前有 200 個文件。199 個小文件一條記錄 a，1 個大文件混合記錄 a 與 test 共 200 條，大文件名 index 在小文件之後。

Hive 中有一個 SimpleFetchOptimizer 優化器，會直接生成 FetchTask，減小資源申請時間與調度時間。但這個優化會出現瓶頸。如果數據量小，但是文件數多，需要返回的條數多，存在能大量篩掉結果數據的 Filter 條件。這時候串列讀取輸入文件，導致查詢延遲大，反而沒起到加速效果。

在 SimpleFetchOptimizer 優化器中，新增文件數的判斷條件，最後將任務提交到集群環境，通過提高並發來實現加速。

示例：讀取當前 500 個文件的分區。優化後的文件數閾值為 100。

一個表有大量的子分區，它的 DESC 過程會與元數據交互，獲取所有的分區。但最後返回的結果，只有跟表相關的信息。

與元數據交互的時候，延遲了整個 DESC 的查詢，當元數據壓力大的時候甚至無法返回結果。

針對於 TABLE 的 DESC 過程，直接去掉了跟元數據交互獲取分區的過程，加速時間跟子分區數量成正比。

示例：desc 十萬分區的大表。

•復用 split 計算的數據，跳過 rece 估算重復統計輸入過程。輸入數據量大的任務，調度速率提升 50%。

•parquetSerde init 加速，跳過同一表的重復列剪枝優化，防止 map task op init 時間超時。

•新增 LazyOutputFormat，有 record 輸出再創建文件，避免空文件的產生，導致下游讀取大量空文件消耗時間。

•statsTask 支持多線程聚合統計信息，防止中間文件過多導致聚合過慢，增大運行時間。

•AdHoc 需要打開並行編譯，防止 SQL 串列編譯導致整體延遲時間增大的問題。

HS2 啟動時會對物化視圖功能進行初始化，輪詢整個元資料庫，導致 HS2 的啟動時間非常長，從下線狀態到重新上線間隔過大，可用性很差。

將物化視圖功能修改為延遲懶載入，單獨線程載入，不影響 HS2 的服務啟動。物化視圖支持載入中獲取已緩存信息，保證功能的可用性。

HS2 啟動時間從 5min+提升至<5s。

HS2 本身上下線成本較高，需要保證服務上的任務全部執行完成才能進行操作。配置的修改可作為較高頻率的操作，且需要做到熱載入。

在 HS2 的 ThriftServer 層我們增加了介面，與運維系統打通後，配置下推更新的時候自動調用，可實現配置的熱載入生效。

HiveServer2 的 scratchdir 主要用於運行過程中的臨時文件存儲。當 HS2 中的會話創建時，便會創建 scratchdir。在 HDFS 壓力大的時候，大量的會話會阻塞在創建 scratchdir 過程，導致連接數堆積至上限，最終 HS2 服務無法再連入新連接，影響服務可用性。

對此，我們先分離了一般查詢與 create temporay table 查詢的 scratch 目錄，並支持 create temporay table 查詢的 scratch 的懶創建。當 create temporay table 大量創建臨時文件，便會影響 HDFS NameNode 延遲時間的時候，一般查詢的 scratchdir HDFS NameNode 可以正常響應。

此外，HS2 還支持配置多 scratch，不同的 scratch 能設置載入比率，從而實現 HDFS 的均衡負載。

Hive 調度其中存在兩個問題。

一、子 Task 非執行狀態為完成情況的時候，若有多輪父 Task 包含子 Task，導致子 Task 被重復加入調度隊列。這種 Case，需要將非執行狀態修改成初始化狀態。

二、當判斷子 Task 是否可執行的過程中，會因為狀態檢測異常，無法正常加入需要調度的子 Task，從而致使查詢丟失 Stage。而這種 Case，我們的做法是在執行完成後，加入一輪 Stage 的執行結果狀態檢查，一旦發現有下游 Stage 沒有完成，直接拋出錯誤，實現查詢結果狀態的完備性檢查。

•HS2 實現了介面終止查詢 SQL。利用這個功能，可以及時終止異常 SQL。

•metastore JDOQuery 查詢優化，關鍵字異常跳過，防止元數據長時間卡頓或者部分異常查詢影響元數據。

•增加開關控制，強制覆蓋外表目錄，解決 insert overwrite 外表，文件 rename 報錯的問題。

•hive parquet 下推增加關閉配置，避免 parquet 異常地下推 OR 條件，導致結果不正確。

•executeForArray 函數 join 超大字元串導致 OOM，增加限制優化。

•增加根據 table 的 schema 讀取分區數據的功能，避免未級聯修改分區 schema 導致讀取數據異常。

•部分用戶並沒有開發經驗，無法處理處理引擎返回的報錯。

•有些錯誤的報錯信息不明確，用戶無法正確了解錯誤原因。

•失敗的任務排查成本高，需要對 Hadoop 整套系統非常熟悉。

•用戶的錯誤 SQL、以及需要優化的 SQL，大量具有共通性。人力維護成本高，但系統分析成本低。

SQL 專家系統基於 HS2 的 Hook 架構，在 BeaconServer 後端實現了三個主要的模塊，分別是 SQL 規則控制模塊、SQL 錯誤分析模塊，與 SQL 優化建議模塊。SQL 專家系統的知識庫，包含關鍵字、原因說明、處理方案等幾項主要信息，存於後端資料庫中，並一直積累。

通過 SQL 專家系統，後端可以進行查詢 SQL 的異常控制，避免異常 SQL 的資源浪費或者影響集群穩定。用戶在遇到問題時，能直接獲取問題的處理方案，減少了使用成本。

示例：空分區查詢控制。

SQL 專家系統能解決一部分 HS2 的任務執行的錯誤診斷需求，但是比如作業 健康 度、任務執行異常等問題原因的判斷，需要專門的系統來解決，為此我們設計了作業診斷系統。

作業診斷系統在 YARN 的層面，針對不同的執行引擎，對搜集的 Counter 和配置進行分析。在執行層面，提出相關的優化建議。

作業診斷系統的數據也能通過 API 提供給 SQL 專家系統，補充用於分析的問題原因。

作業診斷系統提供了查詢頁面來查詢運行的任務。以下是命中 map 輸入過多規則的任務查詢過程：

Ⅳ 求大數據分析技術

列一大堆沒用的。。。
大數據分析技術兩種理解： 一種是 大數據處理涉及到技術， 一種專是 數據挖掘技術
第一種就屬是數據處理流程： 也就是 數據採集 數據清洗 數據存儲 數據挖掘 結果可視化展示 技術。
第二種就是具體的數據挖掘演算法： 主要是 回歸 分類 關聯規則 聚類 異常檢測 這幾種
看你需要哪種？

Ⅳ 請教，怎麼將mysql里的大數據同步到 sqlserver2008里

您好，很高興為您解答。

下載安裝SQLyog v10.51，確保本機安裝了Mysql和Sql server 2008 r2。
使用SQLyog連上本地mysql資料庫
點資料庫>導入>導入外部數據 進入SQLyog外部數據導入向導，選擇「開始新的工作」，點「下一步」

在數據源類型中只有access、excel、csv、任何odbc數據源。使用前面三個中間數據格式轉換方式都可以導入不過就麻煩了。這里我們選擇任何ODBC數據源

再點擊「建立新的DSN」，彈出窗口「創建新數據源」，我們選擇「系統數據源」並進入下一步

選擇數據源驅動「SQL Server」，進入下一步點「完成」

設置一個數據源名稱，並填寫你的SQL伺服器IP，如果是本地伺服器可以直接下拉框選擇。

輸入登錄賬號密碼（看你的SQL伺服器是哪種登錄驗證方式），填寫好了就下一步、下一步、完成。

彈出配置信息窗口後就可以點「測試數據源」，看是否連接到伺服器

再回到導入向導，選下一步。
設置要導入的本地目標資料庫之後下一步，再選擇「拷貝數據到本地」下一步，勾選你要導入的數據表，後面還可以相應設置每個表要拷貝到本地那個數據表名稱，然後下一步就開始拷貝數據至本地MYSQL。

如若滿意，請點擊右側【採納回答】，如若還有問題，請點擊【追問】

希望我的回答對您有所幫助，望採納！

~ O(∩_∩)O~

Ⅵ 如何使用Big SQL訪問大數據使用詳解

使用 JDBC/ODBC 程序訪問 Big SQL
我們可以使用 JDBC/ODBC 程序來訪問 Big SQL，我們以 JDBC 程序為例，詳細介紹了使用 JDBC 訪問 Big SQL 的具體方法。
首先，我們需要在 CLASSPATH 環境變數中增加 bigsql-jdbc-driver.jar 文件，如下所示：
清單 8. 增加 CLASSPATH 環境變數
biadmin@imtebi1:/opt/ibm/biginsights/bigsql/samples/queries>
export CLASSPATH=$CLASSPATH:/opt/ibm/biginsights/bigsql/samples/queries/bigsql-jdbc-driver.jar

並創建 countbrand.java 程序，如下所示：
清單 9. countbrand.java 程序
countbrand.java

import java.io.*;
import java.sql.*;
import java.util.*;
class countbrand {
public static void main(String args[]) throws SQLException,Exception {
try {
//load the driver class
Class.forName("com.ibm.biginsights.bigsql.jdbc.BigSQLDriver");
} catch (ClassNotFoundException e) {
System.out.print(e); }
try {
//set connection properties
String user="biadmin";
String password="password";
Connection con = DriverManager.getConnection("jdbc:bigsql://172.16.42.202:7052/gosalesdw",
user,password);
Statement st = con.createStatement();
//query execution
ResultSet rs = st.executeQuery("SELECT count(*) FROM GOSALESDW.GO_BRANCH_DIM AS BD,
GOSALESDW.DIST_INVENTORY_FACT AS IF WHERE IF.BRANCH_KEY = BD.BRANCH_KEY /*+ joinMethod = 'mapSideHash',
buildTable = 'bd' +*/ AND BD.BRANCH_CODE > 20");
while(rs.next()) {
System.out.println(rs.getString(1));
}
} catch(SQLException sqle)
{ System.out.print(sqle); }
}
}

我們可以使用如下命令編譯並運行 countbrand.java 程序，如下所示：
清單 10. 編譯並運行 countbrand.java 程序
biadmin@imtebi1:/opt/ibm/biginsights/bigsql/samples/queries> javac countbrand.java
biadmin@imtebi1:/opt/ibm/biginsights/bigsql/samples/queries> java countbrand
33318

創建、載入表
同關系資料庫一樣，Big SQL 也存在模式。模式是指一組對象的集合，我們可以通過創建不同的模式來組織 Big SQL 中的數據對象。如下所示，我們創建 gosalesdw 模式來組織我們需要創建的 Hive 及 HBase 表。
清單 11. 創建 gosalesdw 模式
biadmin@imtebi1:/opt/> $BIGSQL_HOME/bin/jsqsh -U biadmin -P password
JSqsh Release 1.5-ibm, Copyright (C) 2007-2013, Scott C. Gray
Type \help for available help topics. Using JLine.
[localhost][biadmin] 1> create schema if not exists gosalesdw;
0 rows affected (total: 1m4.56s)
[localhost][biadmin] 1> quit;
biadmin@imtebi1:/opt/$HADOOP_HOME/bin/hadoop fs -ls /biginsights/hive/warehouse
drwxr-xr-x - biadmin biadmgrp
0 2013-12-21 21:20 /biginsights/hive/warehouse/gosalesdw.db

在 Big SQL 中，我們創建的模式會在 DFS 分布式文件系統中創建一個相應的目錄，該目錄可以在創建模式時指定，如果沒有指定目錄，會在 Hive 的默認目錄 /biginsights/hive/warehouse/ 下創建。我們可以通過修改 $HIVE_HOME/conf/hive-site.xml 文件中的 hive.metastore.warehouse.dir 屬性值來修改 Hive 的默認存儲路徑，如下所示：
清單 12. 修改 hive-site.xml
biadmin@imtebi1:/opt/> $BIGSQL_HOME/bin/jsqsh -U biadmin -P password
JSqsh Release 1.5-ibm, Copyright (C) 2007-2013, Scott C. Gray
Type \help for available help topics. Using JLine.
[localhost][biadmin] 1> create schema if not exists gosalesdw1 location
'/usr/biadmin/gosalesdw1.db';
0 rows affected (total: 0.87s)
[localhost][biadmin] 1> quit

biadmin@imtebi1:/opt/> $HADOOP_HOME/bin/hadoop fs -ls /usr/biadmin
Found 1 items
drwxr-xr-x - biadmin supergroup 0 2013-12-21 21:26 /usr/biadmin/gosalesdw1.db

more $HIVE_HOME/conf/hive-site.xml

hive.metastore.warehouse.dir
/biginsights/hive/warehouse

Ⅶ 如何優化大數據高並發量的系統的SQL語句提高效率

1、HTML靜態化
效率最高、消耗最小的就是純靜態化的html頁面，所以盡可能使網站上的頁面採用靜態頁面來實現，這個最簡單的方法其實也是最有效的方法。但是對於大量內容並且頻繁更新的網站，無法全部手動去挨個實現，於是出現了常見的信息發布系統CMS，像常訪問的各個門戶站點的新聞頻道，甚至他們的其他頻道，都是通過信息發布系統來管理和實現的，信息發布系統可以實現最簡單的信息錄入自動生成靜態頁面，還能具備頻道管理、許可權管理、自動抓取等功能，對於一個大型網站來說，擁有一套高效、可管理的CMS是必不可少的。
2、圖片伺服器分離
對於Web伺服器來說，不管是Apache、IIS還是其他容器，圖片是最消耗資源的，於是有必要將圖片與頁面進行分離，這是基本上大型網站都會採用的策略，他們都有獨立的圖片伺服器，甚至很多台圖片伺服器。這樣的架構可以降低提供頁面訪問請求的伺服器系統壓力，並且可以保證系統不會因為圖片問題而崩潰，在應用伺服器和圖片伺服器上，可以進行不同的配置優化，比如apache在配置ContentType的時候可以盡量少支持，盡可能少的LoadMole，保證更高的系統消耗和執行效率。 這一實現起來是比較容易的一現，如果伺服器集群操作起來更方便，如果是獨立的伺服器，新手可能出現上傳圖片只能在伺服器本地的情況下，可以在令一台伺服器設置的IIS採用網路路徑來實現圖片伺服器，即不用改變程序，又能提高性能，但對於伺服器本身的IO處理性能是沒有任何的改變。
3、資料庫集群和庫表散列
大型網站都有復雜的應用，這些應用必須使用資料庫，那麼在面對大量訪問的時候，資料庫的瓶頸很快就能顯現出來，這時一台資料庫將很快無法滿足應用，於是需要使用資料庫集群或者庫表散列。
4、緩存
緩存一詞搞技術的都接觸過，很多地方用到緩存。網站架構和網站開發中的緩存也是非常重要。架構方面的緩存，對Apache比較熟悉的人都能知道Apache提供了自己的緩存模塊，也可以使用外加的Squid模塊進行緩存，這兩種方式均可以有效的提高Apache的訪問響應能力。
網站程序開發方面的緩存，Linux上提供的Memory Cache是常用的緩存介面，可以在web開發中使用，比如用Java開發的時候就可以調用MemoryCache對一些數據進行緩存和通訊共享，一些大型社區使用了這樣的架構。另外，在使用web語言開發的時候，各種語言基本都有自己的緩存模塊和方法，PHP有Pear的Cache模塊，Java就更多了，.net不是很熟悉，相信也肯定有。