建站
咨詢
售后
建站咨詢
新聞中心
寬表數(shù)據(jù)庫是一種用于存儲大量數(shù)據(jù)的數(shù)據(jù)庫，其特點是能夠存儲非常大的數(shù)據(jù)表并支持復(fù)雜查詢。它由列式存儲和分布式結(jié)構(gòu)組成，能夠存儲數(shù)以百萬計的行數(shù)和數(shù)以千計的列數(shù)。
創(chuàng)新互聯(lián)是一家專注于成都網(wǎng)站設(shè)計、成都網(wǎng)站建設(shè)、外貿(mào)網(wǎng)站建設(shè)與策劃設(shè)計,汾西網(wǎng)站建設(shè)哪家好?創(chuàng)新互聯(lián)做網(wǎng)站,專注于網(wǎng)站建設(shè)十載,網(wǎng)設(shè)計領(lǐng)域的專業(yè)建站公司;建站業(yè)務(wù)涵蓋:汾西等地區(qū)。汾西做網(wǎng)站價格咨詢:13518219792
優(yōu)勢：
1. 支持大規(guī)模存儲：寬表數(shù)據(jù)庫是針對大規(guī)模數(shù)據(jù)處理而設(shè)計的，它的存儲能力高達千萬甚至億級別的記錄。
2. 處理速度快：寬表數(shù)據(jù)庫使用列存儲技術(shù)，可以支持高效的數(shù)據(jù)壓縮和歸檔，加快數(shù)據(jù)的讀取和查詢速度。
3. 可擴展性強：寬表數(shù)據(jù)庫具有良好的擴展性，可以實現(xiàn)集群式的存儲和負載均衡技術(shù)，適應(yīng)高并發(fā)的數(shù)據(jù)處理環(huán)境。
4. 支持復(fù)雜查詢：寬表數(shù)據(jù)庫可以支持多種復(fù)雜的查詢方式，包括多層嵌套查詢、關(guān)聯(lián)查詢、分組查詢等。
5. 高可靠性和穩(wěn)定性：寬表數(shù)據(jù)庫可以實現(xiàn)數(shù)據(jù)備份和恢復(fù)功能，同時支持高可用和容錯性能，確保數(shù)據(jù)的安全和穩(wěn)定性。
劣勢：
1. 技術(shù)門檻高：寬表數(shù)據(jù)庫的設(shè)計和使用需要較高的技術(shù)門檻，需要專業(yè)的技術(shù)人才進行維護和操作。
2. 成本高昂：寬表數(shù)據(jù)庫需要大量硬件和軟件資源來支持其存儲和計算需求，成本較高。
3. 使用復(fù)雜：寬表數(shù)據(jù)庫需要對數(shù)據(jù)及其存儲方式有深刻的理解，操作復(fù)雜，需要較高的使用門檻。
4. 不適合小規(guī)模數(shù)據(jù)存儲：相對于小型數(shù)據(jù)存儲來說，使用寬表數(shù)據(jù)庫的成本相對較高，而且如此龐大的數(shù)據(jù)集可能不適合處理小規(guī)模的數(shù)據(jù)。
5. 不適合實時處理：寬表數(shù)據(jù)庫的處理特點和處理方式適合于大量數(shù)據(jù)和復(fù)雜查詢，而不適合要求數(shù)據(jù)實時處理的場景。
寬表數(shù)據(jù)庫作為一種大規(guī)模數(shù)據(jù)存儲和處理方式，具有一定的優(yōu)勢和局限性。在實際使用中需要根據(jù)自身的需求進行權(quán)衡和選擇。對于批量的數(shù)據(jù)加載、復(fù)雜的查詢和高容錯、高可用性的場景，寬表數(shù)據(jù)庫是一個值得存在的選擇。
相關(guān)問題拓展閱讀：
- BI 不是可以拖拉拽取數(shù)嗎？為什么還要 SQL 取數(shù) ? | 專家視角
BI 不是可以拖拉拽取數(shù)嗎？為什么還要 SQL 取數(shù) ? | 專家視角
36氪企服點評專家團——呂品
————正文————
BI 工具不是可以直接拖拉拽取數(shù)嗎 ？為什么還要寫 SQL 取數(shù) ? 這是很多初次接觸商業(yè)智能 BI 的朋友會提到的一個問題，因為在他們接觸到一些 BI 市場或者產(chǎn)品宣傳的時候，很多人就是這么來介紹BI 的。
簡單來說，這個問題背后的邏輯等同于：
拿著碗和筷子不是可以直接吃飯嗎 ？為什么還要自己動手做飯 ？有沒有想過，即使是直接吃飯，飯總是要有人來做的吧，無論這個人是自己還是別人，“做飯”這個過程并不會少帆宏。
所以，從這個問題背后能看出來還是有很多人對于 BI 的理解還是存在一定的誤區(qū)，我們可以從以下這幾個角度來分析講解一下。
可視化 BI
很多人對于 BI 的印象就停留在數(shù)據(jù)的可視化圖表，但可視化圖表只是 BI 的最終呈現(xiàn)，可視化的拖拉拽并不是 BI 的全部。
一個完整的商業(yè)智能 BI 解決的應(yīng)該是端到端（ End to End ) 的問題，需要從各個業(yè)務(wù)系統(tǒng)的數(shù)據(jù)源取數(shù)，通過 ETL （ Extract 抽取、Transformation 轉(zhuǎn)換、Loading 加載 ）的過程
將要分析的數(shù)據(jù)從規(guī)范的不可分析的、或不規(guī)范不可分析的數(shù)據(jù)最終變?yōu)橐?guī)范的、可分析的形式
，最終通過 BI 可視化拖拉拽的方式將數(shù)據(jù)進行有效的、帶有邏輯性的組織形成可視化分析報表。
派可數(shù)據(jù)大屏可視化分析
而大部分的 BI 工具如果重在強調(diào)前端可視化的能力，這類 BI 工具的定位就是解決數(shù)據(jù)可視化分析展現(xiàn)的問題，屬于 BI 前端可視化報表工具，但并不能代表 BI 的全部。
如何形象的理解 BI
如果把 BI 可視化實現(xiàn)的過程比作到餐廳出菜的過程，那就是：
數(shù)據(jù)源環(huán)節(jié) vs 菜市場
從各個業(yè)務(wù)系統(tǒng)取數(shù)
—— 按照餐廳營業(yè)需求準備所需菜品的原材料，就需要到各個市場買菜。不同的業(yè)務(wù)系統(tǒng)對應(yīng)不同的菜市場，不同的菜市場有不同的攤位對應(yīng)的就是業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫中不同的數(shù)據(jù)表。攤位上的菜就可以理解為數(shù)據(jù)表中的數(shù)據(jù)，要分析什么就取什么樣的基礎(chǔ)數(shù)據(jù)。
數(shù)據(jù)倉庫 vs 后廚倉庫
數(shù)據(jù)倉庫環(huán)節(jié)
—— 從各個市場買回來的菜堆在哪里呢？后廚倉庫。有的菜是今天要用的，有的菜是明天要用的，所以先買回來堆起來。從各個系統(tǒng)抽取上來的數(shù)據(jù)也是如此，這些數(shù)據(jù)有的來源于 Oracle 系統(tǒng)，有的來源于 MySQL 或者 SQL Server，按照分析需求從不同的數(shù)據(jù)庫抽取之后放到自己的數(shù)據(jù)倉庫中集中管理起來。
ETL 過程
—— 廚師做個豬肉燉粉條不可能把整扇豬肉、一顆一顆的大白菜扔到鍋里，一定是豬肉切片，大白菜去除壞掉的葉子，菜該切切，態(tài)褲冊肉該剁剁剁。同時，還會備好一些輔助的佐料等原材料，最后把所有的原材料放到操作臺上，這個就是備菜（ 擇菜、洗菜、切菜 ）的過程。
數(shù)據(jù)也是如此，把數(shù)據(jù)從各個業(yè)務(wù)系統(tǒng)先
抽?。?Extract ）
上來，等同于把放在不同倉庫格子的菜拿過來。數(shù)據(jù)要做
轉(zhuǎn)換（ Transformation ）
，比如一些臟數(shù)據(jù)的處理、格式的轉(zhuǎn)換、數(shù)據(jù)計算口徑的統(tǒng)一、指標的計算等等，就如同洗菜、擇菜、切菜的過程。最后將處理之后的數(shù)據(jù)按照一定的模型或者格式
加載（ Loading ）
到指定的可被前端調(diào)用的數(shù)據(jù)表中，就如同把所有備好的菜放到一起準備下鍋。
報表可視化 Reporting vs 上菜
Reporting 報表可視化就是最后的呈現(xiàn)，也通常視為 BI 的前端，所以也叫做 BI 前端可視化。用戶需要什么樣的可視化報表，就如同用戶點菜一樣可以高度定制化，前提是基于已有的原材料（數(shù)據(jù)）。
派可數(shù)據(jù)大屏可視純洞化分析
所以，大家可以看到從業(yè)務(wù)系統(tǒng)數(shù)據(jù)取數(shù)到最后的報表呈現(xiàn)實際上經(jīng)歷了很多的階段。
在商業(yè)智能 BI 開發(fā)過程中，80% 的時間在處理底層數(shù)據(jù)（ 跑菜市場、買菜、運菜、擇菜、洗菜、切菜到備好菜 ），20% 的時間在做可視化分析報表（ 做菜 ）。
底層數(shù)據(jù)的處理重點就是 ETL 過程，而實現(xiàn) ETL 過程的主要方式就是通過 ETL 工具（ 例如：Kettle、Informatica、Pentaho、IBM DataStage、Microsoft SSIS 等 ）或其它 ETL 框架結(jié)合 SQL 查詢語句、Stored Procedure 存儲過程等方式來組織和管理數(shù)據(jù)處理的先后順序。
特別是企業(yè)級 BI 項目建設(shè)，不僅僅是簡單的 ETL 過程還需要涉及非常專業(yè)的數(shù)據(jù)架構(gòu)設(shè)計、數(shù)據(jù)倉庫建模、分層設(shè)計等數(shù)據(jù)倉庫的構(gòu)建，這里面最常用的開發(fā)語言就是 SQL。
BI 直接取數(shù)分析并不可行
很多 BI 工具會經(jīng)常強調(diào)直連取數(shù)，這樣就不需要寫 SQL，直接通過表與表之間的關(guān)系進行表間建模，形成一個大寬表，文本類型的就是維度 Dimension，數(shù)值類型的變成度量 Measure，通過 BI 前端可視化進行拖拉拽操作形成很多 Ad-hoc Report 即席報表。
在實際演示案例的時候也是如此，最常見的就是一個標準的、數(shù)據(jù)格式極為標準規(guī)范的 EXCEL 表上傳一下按照上面的方式來一遍；要么就是銷售訂單表和銷售明細表關(guān)聯(lián)一下，算算訂單數(shù)量、訂單金額等等。
其實驗證一下 BI 工具的這種直連且拖拉拽的能力到底有多強非常簡單，讓業(yè)務(wù)部門提幾個實際的分析需求，現(xiàn)場拿 BI 產(chǎn)品從實際的業(yè)務(wù)系統(tǒng)中取數(shù)來驗證一下是否那么容易就明白了。
以下面一個小 DEMO 為例，可以使用任意的國內(nèi)外 BI 可視化分析工具嘗試一下當直連到這張表的時候，是不是就可以直接、任意的進行拖拉拽分析。
案例：統(tǒng)計外包業(yè)務(wù)的人工效率（時長）
背景：某金融公司把一部分貸款業(yè)務(wù)外包出去給第三方公司，第三方公司業(yè)務(wù)人員每與客戶聯(lián)系一次，就會根據(jù)溝通的狀態(tài)記錄一下，形成了以下的業(yè)務(wù)數(shù)據(jù)表 DurationTime，有以下三個核心字段：
ID – 客戶的身份證號，唯一標識 ID
Operation – 一個操作記錄，重點節(jié)點有 0034、0036、0048
Date – 一個操作記錄的時間日期（實際上是時間，為了簡化用日期表示）
業(yè)務(wù)系統(tǒng)中的原始數(shù)據(jù)表
計算規(guī)則如下：
1) 計算，，的時間間隔。
2) 如0036之前沒有0034，不可單獨計算的時間間隔。
3) 如0036后跟著多個0048，則取到最晚的一個0048的時間間隔。
4) 如0034后跟著多個0048，則取到最早的一個0048的時間間隔。
5) ….
實際的計算規(guī)則多達 20 多種，就以上面 4 條計算規(guī)則為例，最后的計算結(jié)果是：
Transformation 表
為了得到上面的最終結(jié)果，通常往往會創(chuàng)建一些中間轉(zhuǎn)換表，用來記錄轉(zhuǎn)換的過程，便于檢查和糾正邏輯，這種表我們通常叫做 Transformation 表。
業(yè)務(wù)系統(tǒng)中的原始數(shù)據(jù)表的數(shù)據(jù)規(guī)范嗎 ？非常規(guī)范。但是適合分析嗎 ？并不適合。所以在 BI 分析之前要做什么？
那就是寫 SQL、ETL 取數(shù)，把這種在業(yè)務(wù)系統(tǒng)中規(guī)范的不可分析的、或不規(guī)范的不可分析的變成規(guī)范的、可分析的數(shù)據(jù)格式 —— 結(jié)果表。
在實際的 BI 項目開發(fā)過程中，來自各個業(yè)務(wù)系統(tǒng)數(shù)據(jù)源的數(shù)據(jù)大部分情況下就是一種不可直接分析的狀態(tài)，與分析思維不同，他們是描述業(yè)務(wù)過程的。
還會有一種說法是：可以直連業(yè)務(wù)數(shù)據(jù)源，通過寫 SQL 查詢一個數(shù)據(jù)集再通過前端 BI 可視化分析工具來呈現(xiàn)做可視化分析報表行不行？ 我們的建議是，除了以下幾種情況，不要這樣做：
之一，這類可視化分析報表基本上就是一次性的，一年可能就改不了幾回。
第二，本身數(shù)據(jù)量不大，使用頻率也不會非常的高。
原因在于：
沒有合理的建模、指標計算復(fù)用性太差、影響業(yè)務(wù)系統(tǒng)性能、無法應(yīng)對后續(xù)日益增長和不斷變化的業(yè)務(wù)分析需求，按照這種方式做的 BI 基本上不會超過兩年就會面臨推翻重做的風(fēng)險。
所以，在使用 BI 的時候，不管是直連業(yè)務(wù)系統(tǒng)數(shù)據(jù)源的表進行表間關(guān)系建模，還是通過寫 SQL 查詢數(shù)據(jù)結(jié)果集的方式直連業(yè)務(wù)系統(tǒng)，在大多數(shù)情況下都不合理，BI 開發(fā)人員應(yīng)極力避免采用這樣的數(shù)據(jù)操作方式，這些還都是在沒有涉及到多異構(gòu)數(shù)據(jù)源取數(shù)、主數(shù)據(jù)檔案不一致、組織架構(gòu)缺失補位、緩慢漸變維度等問題的前提下。
BI 直接取數(shù)分析什么樣的情況下是可行的 ？
也有朋友說到，我們公司就是直連數(shù)據(jù)庫取數(shù)做可視化分析的。我們讓朋友回去問了一下，原來連接的是企業(yè)已經(jīng)構(gòu)建好的數(shù)據(jù)倉庫。在這種情況下，底層的數(shù)據(jù)模型相對比較標準，數(shù)據(jù)也經(jīng)過了非常良好的格式轉(zhuǎn)換，可以直接使用一些前端 BI 可視化分析工具進行快速的分析，這樣的一種搭配就非常好。
所以，BI 直連數(shù)據(jù)庫不是不可行，但得分清楚直連的是業(yè)務(wù)系統(tǒng)的數(shù)據(jù)源數(shù)據(jù)庫，還是直連的是已經(jīng)通過 SQL 從業(yè)務(wù)系統(tǒng)的數(shù)據(jù)源取數(shù)和建模處理后的數(shù)據(jù)倉庫、數(shù)據(jù)集市。
派可數(shù)據(jù)自助開發(fā)平臺包括數(shù)據(jù)倉庫與BI可視化分析
IT 和業(yè)務(wù)的邊界就在這里，IT 負責(zé)底層數(shù)據(jù)建模、數(shù)據(jù)倉庫的構(gòu)建，業(yè)務(wù)基于已經(jīng)建好的基礎(chǔ)分析模型通過 BI 前端可視化分析工具來進行拖拉拽的可視化分析操作。
倘若是這樣，也確實實現(xiàn)了不通過 SQL 取數(shù)使用 BI 前端工具就可以做報表的目標。但絕對不能認為，不通過 SQL 取數(shù)就可以對接任何業(yè)務(wù)系統(tǒng)數(shù)據(jù)源做任何 BI 可視化分析。
所以，當一家企業(yè)底層已經(jīng)有架構(gòu)非常良好的數(shù)據(jù)倉庫，這個時候使用一個輕量的 BI前端可視化分析工具基本上就夠用了。但如果所在企業(yè)底層還沒有良好的數(shù)據(jù)倉庫系統(tǒng)，只寄希望單純的使用一個 BI 前端可視化報表工具解決一切分析問題，這個時候就需要認真思考一下是否可行。
www.36dianping.com
原文標題：《BI 不是可以拖拉拽取數(shù)嗎？為什么還要 SQL 取數(shù) ? | 專家視角》
作者： 呂品
本文來源于36氪企服點評
數(shù)據(jù)庫 寬表的介紹就聊到這里吧，感謝你花時間閱讀本站內(nèi)容，更多關(guān)于數(shù)據(jù)庫 寬表,什么是寬表數(shù)據(jù)庫？優(yōu)劣勢有哪些？,BI 不是可以拖拉拽取數(shù)嗎？為什么還要 SQL 取數(shù) ? | 專家視角的信息別忘了在本站進行查找喔。
成都創(chuàng)新互聯(lián)建站主營：成都網(wǎng)站建設(shè)、網(wǎng)站維護、網(wǎng)站改版的網(wǎng)站建設(shè)公司，提供成都網(wǎng)站制作、成都網(wǎng)站建設(shè)、成都網(wǎng)站推廣、成都網(wǎng)站優(yōu)化seo、響應(yīng)式移動網(wǎng)站開發(fā)制作等網(wǎng)站服務(wù)。
網(wǎng)站標題：什么是寬表數(shù)據(jù)庫？優(yōu)劣勢有哪些？(數(shù)據(jù)庫寬表)
URL標題：http://m.5511xx.com/article/ccsidhd.html
