午夜噜噜,欧美A片在线,久久9热,97视频人人,抽插美女大逼网页,蜜乳一区二区三区四区五区六区 ,黄色视频国产免费,黄片免费在线观看 s

當(dāng)前絕大部分?jǐn)?shù)據(jù)倉庫都會采用 SQL，SQL 發(fā)展了幾十年已經(jīng)成為數(shù)據(jù)庫界的標(biāo)準(zhǔn)語言，用戶量巨大，所以支持 SQL 對于數(shù)據(jù)倉庫來講也是很正常的。但是，在當(dāng)代大數(shù)據(jù)背景下，業(yè)務(wù)復(fù)雜度節(jié)節(jié)攀升，在以計(jì)算為主要任務(wù)的數(shù)據(jù)倉庫場景下，SQL 似乎越來越不夠用了。典型表現(xiàn)是一些數(shù)據(jù)倉庫開始集成 Python 的能力，將 Python 這樣的非 SQL 語言融入到數(shù)據(jù)倉庫中。且不論兩種風(fēng)格迥異的開發(fā)語言是否能很好融合互補(bǔ)，單看這樣的趨勢已經(jīng)足夠表現(xiàn)出業(yè)界對 SQL 能力的一些質(zhì)疑。

我們這里要介紹一種非 SQL 型數(shù)據(jù)倉庫 esProc，由于沒有使用 SQL 作為查詢語言（而是 SPL），可以暫且將其看成一種新型數(shù)據(jù)倉庫。

GitHub：https://github.com/SPLWare/esProc

為什么 esProc 不再使用 SQL 了呢？

要回答這個(gè)問題，我們還要繼續(xù)為什么數(shù)據(jù)倉庫有了 SQL 還要引入 Python 的話題。引入 Python 要解決哪些問題呢？

我們知道，SQL 對過程計(jì)算的支持很差，即使有了 CTE 語法在描述復(fù)雜計(jì)算時(shí)仍然十分復(fù)雜，經(jīng)常要嵌套多層且反復(fù)關(guān)聯(lián)。同時(shí)，SQL 的集合是無序的，非常不擅長有序計(jì)算，涉及序運(yùn)算經(jīng)常會寫得很繁瑣甚至很難寫出來。SQL 本身的語言特性注定不善于完成某些復(fù)雜計(jì)算，而這類計(jì)算在數(shù)據(jù)倉庫類的數(shù)據(jù)分析型場景中并不少見。比如在計(jì)算電商漏斗分析（瀏覽商品、加購物車、下單、付款等多步的用戶流失率）的場景用 SQL 就很難實(shí)現(xiàn)。而這樣涉及多個(gè)前后步驟、結(jié)果反復(fù)使用的場景用 Python 這樣支持分步和有序運(yùn)算的語言實(shí)現(xiàn)則要簡單得多。

也就是說，SQL 的能力是缺失的。

但是，如果因此引入 Python 等第三方語言來彌補(bǔ)能力上的缺失，又會帶來技術(shù)棧的復(fù)雜問題。還是那句話，Python 能不能彌補(bǔ)這些缺失尚且不論，兩者能否很好融合也不管，但是多種技術(shù)風(fēng)格帶來的系統(tǒng)復(fù)雜度上升，從而導(dǎo)致高開發(fā)成本和運(yùn)維成本是跑不掉的了。

除了能力方面的欠缺，采用 SQL 的關(guān)系數(shù)據(jù)庫還存在封閉性的問題。

數(shù)據(jù)庫的作用主要是交易（TP），這就需要眾多約束保證數(shù)據(jù)一致等，因此數(shù)據(jù)入庫時(shí)只有滿足條件才能進(jìn)來，進(jìn)來才能使用。這種只有裝入內(nèi)部才能使用的特性我們稱之為封閉性。數(shù)據(jù)倉庫是基于數(shù)據(jù)庫發(fā)展而來的，封閉性的特點(diǎn)也繼承了下來。

封閉性對于 TP 業(yè)務(wù)是非常重要的。但是，對于以分析計(jì)算為主的 AP 業(yè)務(wù)，這個(gè)封閉性不僅毫無意義，甚至還有很大缺點(diǎn)。封閉性要求數(shù)據(jù)進(jìn)入內(nèi)部才能使用，這會導(dǎo)致多個(gè)數(shù)據(jù)庫之間的數(shù)據(jù)無法進(jìn)行任意組合和運(yùn)算，這就極大限制了數(shù)據(jù)倉庫的應(yīng)用場景。

不僅如此，現(xiàn)代數(shù)據(jù)應(yīng)用的數(shù)據(jù)源十分廣泛，除了不同數(shù)據(jù)庫，經(jīng)常會面對五花八門的數(shù)據(jù)來源和類型。封閉的 SQL 數(shù)據(jù)庫不能針對庫外的數(shù)據(jù)開放其計(jì)算能力，就只能把外部數(shù)據(jù)先導(dǎo)入才能計(jì)算。這會增加一步 ETL 動(dòng)作，增大工作量并加大數(shù)據(jù)庫負(fù)擔(dān)的同時(shí)，還喪失了數(shù)據(jù)的實(shí)時(shí)性。這些外部數(shù)據(jù)的格式常常不規(guī)范，導(dǎo)入進(jìn)有強(qiáng)約束的數(shù)據(jù)庫并不是一件很容易的事。而且，即使做 ETL 也要先把未整理的數(shù)據(jù)先入庫才能利用數(shù)據(jù)庫的計(jì)算能力，結(jié)果把 ETL 做成 ELT，加大數(shù)據(jù)庫負(fù)擔(dān)。

封閉性還不方便用戶自由實(shí)施空間換時(shí)間。我們知道，存儲資源相對于計(jì)算資源要便宜得多，如果我們針對不同計(jì)算目標(biāo)把數(shù)據(jù)以多種方式冗余存儲，就可能獲得更好的查詢體驗(yàn)。但是，SQL 要用表來存儲數(shù)據(jù)，自建表太多又會導(dǎo)致元數(shù)據(jù)變大，嚴(yán)重增加運(yùn)維成本。表數(shù)量太多還會導(dǎo)致數(shù)據(jù)倉庫出現(xiàn)容量和性能問題，面臨擴(kuò)容壓力。很多大型機(jī)構(gòu)的中央數(shù)據(jù)倉庫中會有成千上萬的中間表，積累多年而不敢刪除，數(shù)據(jù)庫容量、性能、運(yùn)維壓力都很大。

SQL 在性能方面也不理想。

我們知道，SQL 的執(zhí)行效率取決于數(shù)據(jù)庫優(yōu)化引擎的優(yōu)化程度，好的數(shù)據(jù)庫會根據(jù) SQL 的計(jì)算目標(biāo)（而非字面意思）選擇更高效的執(zhí)行方式。但這種自動(dòng)優(yōu)化機(jī)制僅對簡單的情況下有效，一旦 SQL 變得稍復(fù)雜優(yōu)化引擎就不起作用了，只能根據(jù) SQL 的字面表達(dá)去執(zhí)行，結(jié)果性能陡降。像前面提到的漏斗分析，有人用 SQL 寫出 3 步的漏斗計(jì)算到數(shù)據(jù)庫執(zhí)行，結(jié)果性能低到不可用的程度。關(guān)于 SQL 性能不佳的情況相信諸位在實(shí)際業(yè)務(wù)中并不少見，很多跑批場景一個(gè) SQL 跑個(gè)把小時(shí)的情況比比皆是，這些都是 SQL 性能不高引起的。

SQL 能力不足，加上封閉性又導(dǎo)致使用沉重，性能也不高。這是當(dāng)前 SQL 型數(shù)據(jù)倉庫面臨的主要問題。

在 SQL 的基礎(chǔ)上引入 Python 能力也不能解決問題。除了我們上面提到的技術(shù)棧復(fù)雜問題會導(dǎo)致使用和運(yùn)維成本過高外，Python 還沒法獲得高性能。

本身 Python 對大數(shù)據(jù)計(jì)算的支持就比較差，對于超出內(nèi)存容量的數(shù)據(jù)計(jì)算并沒有提供相應(yīng)的外存計(jì)算類型（如游標(biāo)），導(dǎo)致處理大數(shù)據(jù)異常復(fù)雜。同時(shí)，Python 并不支持真正的多線程并行，Python 的并行是偽并行，對于 CPU 來說就是串行，甚至比串行還慢，難以充分利用現(xiàn)代 CPU 多核的優(yōu)勢。

更主要的是，由于 Python 要基于 SQL 數(shù)據(jù)庫表進(jìn)行運(yùn)算，這些表（存儲）為數(shù)據(jù)庫私有外界無法干預(yù)。但很多高性能計(jì)算是需要根據(jù)計(jì)算目標(biāo)來組織數(shù)據(jù)的，如將數(shù)據(jù)按照關(guān)聯(lián)字段排序就可以使用更高效的有序歸并算法，存儲無法干預(yù)就不能實(shí)現(xiàn)這些算法，性能自然也無法得到保證。此外，Python 讀取數(shù)據(jù)庫數(shù)據(jù)還涉及 IO 成本，這些都會導(dǎo)致計(jì)算性能不高。

看來要解決 SQL 的這些問題就只能拋棄 SQL 了。

其實(shí)非 SQL 的計(jì)算技術(shù)一直都有，比較典型的代表是 Spark。Spark 誕生之初使用 Scala 作為編程語言，再借助其大規(guī)模的分布式計(jì)算能力大有革命 SQL 的態(tài)勢。不過很遺憾，隨著使用的深入我們發(fā)現(xiàn) Spark 并沒有取代 SQL 的能力（實(shí)現(xiàn)繁瑣、性能低），加之 Scala 的使用難度，讓 Spark 又不得不回到 SQL 的懷抱。

接下來我們來看看非 SQL 數(shù)據(jù)倉庫 esProc 的能力，會有哪些不同。

esProc SPL

esProc 數(shù)據(jù)倉庫的形式化語言是 SPL，并沒有使用業(yè)界普遍采用的 SQL。原因就在于 SQL 能力缺失、體系封閉、性能不高，而 SPL 能很好解決這些問題。

能力完備

首先，SPL 天然支持過程計(jì)算。

過程計(jì)算可以有效降低復(fù)雜業(yè)務(wù)的實(shí)現(xiàn)難度，同樣的 100 行代碼，分成 100 個(gè)語句還是只有 1 個(gè)語句，其復(fù)雜度完全不是一個(gè)層面的。SQL 雖然在 CTE 語法和存儲過程的支持下具備了一定程度的過程化，但仍遠(yuǎn)遠(yuǎn)不夠。SPL 在這方面提供了天然支持，將復(fù)雜計(jì)算分解成多步從而降低實(shí)現(xiàn)難度。

其次，SPL 提供了更豐富的數(shù)據(jù)類型和運(yùn)算支持。

相比 SQL 沒有顯著的記錄數(shù)據(jù)類型（單條記錄會被 SQL 作為只有一條記錄的臨時(shí)表處理，也就是個(gè)單成員的集合），SPL 提供了專業(yè)的結(jié)構(gòu)化數(shù)據(jù)對象序表，并在序表的基礎(chǔ)上提供了豐富的計(jì)算類庫，從而使得 SPL 具備了完善且簡單的結(jié)構(gòu)化數(shù)據(jù)處理能力。

比如部分常規(guī)計(jì)算：

Orders.sort(Amount) // 排序Orders.select(Amount*Quantity>3000 && like(Client,"*S*")) // 過濾Orders.groups(Client; sum(Amount)) // 分組Orders.id(Client) // 去重join(Orders:o,SellerId ; Employees:e,EId) // 連接

有了過程化和序表的支持，SPL 就可以完成更加豐富的運(yùn)算。比如對有序運(yùn)算的支持 SPL 就更為直接和徹底。還有分組運(yùn)算，SPL 可以保留分組子集，即集合的集合，這樣可以很方便完成我們分組后對分組結(jié)果的進(jìn)一步操作。相比之下，SQL 沒有顯式的集合數(shù)據(jù)類型，無法返回集合的集合這類數(shù)據(jù)，不能實(shí)現(xiàn)獨(dú)立的分組，就只能強(qiáng)迫分組和聚合作為一個(gè)整體來計(jì)算了。

此外，SPL 對聚合運(yùn)算也有新的理解，聚合結(jié)果除了常見的單值 SUM、COUNT、MAX、MIN 等之外，也可以是個(gè)集合。比如常常出現(xiàn)的 TOPN 計(jì)算，SPL 也看作和 SUM、COUNT 一樣的聚合計(jì)算，既可以針對全集也可以針對分組子集。

其實(shí) SPL 還有很多特性不僅比 SQL 更加完善，相對 Python 也更加豐富。像離散性可以讓構(gòu)成數(shù)據(jù)表的記錄游離于數(shù)據(jù)表外獨(dú)立反復(fù)使用；普遍集合支持任何數(shù)據(jù)構(gòu)成的集合并參與運(yùn)算；連接運(yùn)算區(qū)分了三種不同連接類型可以因地制宜；……。

有了這些完備的計(jì)算能力，不僅代碼編寫簡單，更不需要借助其他計(jì)算能力，技術(shù)棧簡單，在一個(gè)體系內(nèi)就可以搞定所有問題。

體系開放

不同于 SQL 數(shù)據(jù)庫需要數(shù)據(jù)先入庫再計(jì)算（封閉性），SPL 面對多樣性數(shù)據(jù)源時(shí)可以直接計(jì)算，具備良好的開放性。

SPL 沒有傳統(tǒng)數(shù)據(jù)倉庫中“庫“的概念，也沒有元數(shù)據(jù)概念，更沒有約束。任何可訪問到的數(shù)據(jù)源都可以看作 SPL 的數(shù)據(jù)，并可被直接計(jì)算。計(jì)算前不需要先“入庫”，計(jì)算后也可以用接口寫出目標(biāo)數(shù)據(jù)源中，不需要刻意“出庫”。

SPL 對常見的數(shù)據(jù)源都封裝了訪問接口，如各種關(guān)系數(shù)據(jù)庫（JDBC 數(shù)據(jù)源）、MongoDB、HBase、HDFS、HTTP/Restful、…，以及 SalesForces、SAP BW、…。這些數(shù)據(jù)源在邏輯上地位基本相同，訪問后都可以單獨(dú)或混合計(jì)算，不同之處僅僅在于訪問接口以及不同接口表現(xiàn)出來的性能。

文件存儲

在數(shù)據(jù)存儲方面，SPL 與傳統(tǒng)數(shù)據(jù)倉庫也有很大不同。

SPL沒有元數(shù)據(jù)，直接采用文件存儲，可以使用任意開放文件類型，SPL 為了保證計(jì)算性能還設(shè)計(jì)了專門的二進(jìn)制文件格式。

目前 SPL 提供了兩種文件類型：集文件和組表。集文件采用了壓縮技術(shù)（占用空間更小讀取更快），存儲了數(shù)據(jù)類型（無需解析數(shù)據(jù)類型讀取更快），支持可追加數(shù)據(jù)的倍增分段機(jī)制，利用分段策略很容易實(shí)現(xiàn)并行計(jì)算，保證計(jì)算性能。組表支持列式存儲，在參與計(jì)算的列數(shù)（字段）較少時(shí)會有巨大優(yōu)勢。組表上還實(shí)現(xiàn)了索引，同時(shí)支持倍增分段，這樣不僅能享受到列存的優(yōu)勢，也更容易并行提升計(jì)算性能。

存儲和計(jì)算不再綁定還很方便實(shí)現(xiàn)存算分離，進(jìn)而實(shí)施彈性計(jì)算，也更易于云化。

文件存儲的成本更低，在 AP 類計(jì)算場景下用戶可以隨意設(shè)計(jì)空間換時(shí)間的方案，無非就是多存幾個(gè)文件，即使冗余數(shù)據(jù)文件多到上萬（現(xiàn)代文件系統(tǒng)處理這個(gè)規(guī)模的文件數(shù)據(jù)很輕松）也完全沒有負(fù)擔(dān)。而且使用文件系統(tǒng)的樹狀結(jié)構(gòu)很容易分門別類管理這些數(shù)據(jù)文件，運(yùn)維成本更低。

延伸閱讀：跑在文件系統(tǒng)上的數(shù)據(jù)倉庫

高性能

基于靈活的文件存儲，我們就可以根據(jù)計(jì)算目標(biāo)靈活設(shè)計(jì)數(shù)據(jù)組織（存儲）形式以實(shí)現(xiàn)高性能。除了高性能存儲支持外，SPL 還提供了諸多大數(shù)據(jù)與高性能計(jì)算機(jī)制和算法支持。

SPL 首先在運(yùn)算能力上提供了游標(biāo)計(jì)算來應(yīng)對超出內(nèi)存容量的大數(shù)據(jù)計(jì)算。

=file("orders.txt").cursor@t(area,amount).groups(area;sum(amount):amount)

同時(shí)還為內(nèi)外存計(jì)算都提供了并行計(jì)算支持。簡單增加一個(gè) @m 選項(xiàng)就可以實(shí)現(xiàn)并行充分利用 CPU 多核的能力，非常方便：

=file("orders.txt").cursor@tm(area,amount;4).groups(area;sum(amount):amount)

除了游標(biāo)和并行計(jì)算外，SPL 還內(nèi)置了很多高性能算法。像 TOPN 運(yùn)算，SPL 把這種運(yùn)算和普通的聚合運(yùn)算同樣看待后，寫出來的取前 N 名的語句中就不會有排序動(dòng)作，執(zhí)行效率因此更高。

類似的，SPL 還提供了很多這樣的高性能算法。包括：

內(nèi)存計(jì)算類的二分法、序號定位、位置索引、哈希索引、多層序號定位、……
外存查找類的二分法、哈希索引、排序索引、帶值索引、全文檢索、……
遍歷計(jì)算類的延遲游標(biāo)、遍歷復(fù)用、多路并行游標(biāo)、有序分組匯總、序號分組、……
外鍵關(guān)聯(lián)類的外鍵地址化、外鍵序號化、索引復(fù)用、對位序列、單邊分堆、……
歸并與連接類的有序歸并、分段歸并、關(guān)聯(lián)定位、附表、……
多維分析類的部分預(yù)匯總、時(shí)間段預(yù)匯總、冗余排序、布爾維序列、標(biāo)簽位維度、……
集群計(jì)算類的集群復(fù)組表、復(fù)寫維表、分段維表、冗余與備胎容錯(cuò)、負(fù)載均衡、……

有了高性能文件存儲和高性能算法的支持，esProc 在實(shí)際應(yīng)用中經(jīng)常獲得比傳統(tǒng) SQL 數(shù)據(jù)倉庫幾倍到幾十倍，有的甚至達(dá)到上千倍的性能提升。

看起來，相對于 SQL，SPL 就沒有劣勢？

這當(dāng)然不可能，這世界上沒有全面都好的東西。

SQL 經(jīng)過幾十年的積累發(fā)展，很多數(shù)據(jù)庫都擁有很強(qiáng)的優(yōu)化引擎。對于適合用 SQL 完成的簡單場景運(yùn)算，可以將普通程序員寫出來的慢語句優(yōu)化出較好的性能，從這個(gè)意義上講，對程序員的要求相對較低。某些場景（比如多維分析）已經(jīng)被優(yōu)化多年，某些 SQL 引擎也可以跑出相當(dāng)好的極致性能。

相比之下，SPL 沒有做多少自動(dòng)優(yōu)化的功能，要跑出高性能，幾乎全靠程序員寫出低復(fù)雜度的代碼。程序員需要經(jīng)過一定的培訓(xùn)和練習(xí)來熟悉 SPL 的理念和庫函數(shù)，多一個(gè)上手的門檻。而且 SPL 目前是用 Java 實(shí)現(xiàn)的，雖然獲得了兼容性好、移植性強(qiáng)以及易于云化的好處，但也受限于 JVM 而無法充分利用 CPU 和內(nèi)存。某些簡單運(yùn)算場景下的性能還是趕不上被充分優(yōu)化的 SQL 引擎。

數(shù)據(jù)倉庫不一定非要 SQL，還有 SPL。

GitHub：https://github.com/SPLWare/esProc

重磅！開源SPL交流群成立了

簡單好用的SPL開源啦！

為了給感興趣的技術(shù)人員提供一個(gè)相互交流的平臺，

特地開通了交流群（群完全免費(fèi)，不廣告不賣課）

需要進(jìn)群的朋友，可長按掃描下方二維碼

本文感興趣的朋友，請到閱讀原文去收藏 ^_^

不用 SQL 的開源數(shù)據(jù)倉庫

能力完備

體系開放

文件存儲

高性能