HTAP的下一步?SoTP初探(上):從“大”數據到“小”而“寬”數據

来源:https://www.cnblogs.com/stonedb/archive/2022/11/22/16915376.html
-Advertisement-
Play Games

在今年的第七屆中國開源年會上,StoneDB 團隊在大數據分論壇發表了《HTAP 的下一步?SoTP 初探》主題演講,在本次演講中,我們首次正式對外闡釋了“SoTP 資料庫”的技術理念,本系列是演講實錄+小編補充版,權當拋磚引玉,供大家批評指正。由於內容比較多,本文為第一章節,主要講講我們提 SoT ...


在今年的第七屆中國開源年會上,StoneDB 團隊在大數據分論壇發表了《HTAP 的下一步?SoTP 初探》主題演講,在本次演講中,我們首次正式對外闡釋了“SoTP 資料庫”的技術理念,本系列是演講實錄+小編補充版,權當拋磚引玉,供大家批評指正。由於內容比較多,本文為第一章節,主要講講我們提 SoTP 的背景:From Big to Small and Wide Data

一、HTAP 的起源、流派和迷思

HTAP 起源

我們首先從起源講起,不過由於是公開演講,考慮到一些聽眾是小白,所以這裡主要是從一個比較巨集觀的關係型資料庫行業發展歷史視角來看的,關於 HTAP 更具體的技術和商業的起源背景,可以看看 StoneDB 首席架構師李浩老師寫的這篇文章:HTAP 的背景

眾所周知,圖靈獎(Turing Award)算是電腦領域里最高的一個獎項,截至今日,因為在資料庫領域有傑出貢獻而獲得圖靈獎的只有四位,分別是:

  1. 查爾斯·巴赫曼(CharlesW. Bachman),1973 年獲獎,設計並開發了網狀資料庫管理系統 IDS,推動了資料庫標準的制定,包括網狀資料庫模型、數據定義和數據操縱語言的規範說明(通俗來講,是他第一次提出了資料庫這麼個東西,可以說是咱們的祖師爺);
  2. 埃德加·弗蘭克·科德(Edgar Frank Codd),1981 年獲獎,提出了關係資料庫模型(關係型資料庫經久不衰,目前依然占據市場最多的份額);
  3. 詹姆斯·古瑞(James Gray),1998 年獲獎,主要是在大型資料庫和事務處理技術上的突破(重點研究如何保障數據的完整性、安全性、並行性,以及故障恢復,曾擔任 VLDB 期刊的主編);
  4. 邁克爾·斯通佈雷克(Michael Stonebraker),2014 年獲獎,現代資料庫系統的概念和實踐方面的基礎性貢獻(領導了影響力巨大的奠基性資料庫 Ingres 的開發,也是最早提倡發展列存資料庫的大佬之一)。

四位資料庫領域圖靈獎獲得者

除了這四位資料庫界公認的大佬外,也有其他大牛,比如:

  • 1988 年,為解決數據集成問題,IBM 的 2 位研究員 Barry Devlin 和 Paul Murphy,創造性地提出了數據倉庫(Data Warehouse)的概念;
  • 1992 年,比爾·恩門(Bill Inmon)給出了數據倉庫的定義。數據倉庫是一個面向主題的、集成的、相對穩定的、反映歷史變化的數據集合,用於支持管理中的決策制定;
  • 1993 年,E.F.Codd 提出 OLAP,以及 OLAP 12 條準則。
  • ......

能看到,早些年的資料庫界名人們,並沒有太多中國人士,和操作系統一樣,中國在這類基礎軟體上的起步和投入都不算太早,這也是資料庫領域目前成為我國 35 個“卡脖子”技術之一的原因吧。

我這裡要指出的是——相信那些在資料庫界深耕數十年的朋友們應該早就感受到了——仿佛,自從上述這些大佬奠定了關係型資料庫發展的總基調後,後續的幾十年裡,就再沒看到什麼轟動一時的創新了,或者說,影響力能達到以上這些人士的資料庫專家學者也沒那麼多了。那段時間,關係型資料庫的熱點話題好像從百家爭鳴陷入了一個相對沉寂的時期,當然,後面也斷斷續續有一些新的技術熱點,不過,能像上面這些大佬一樣直接奠定一個學科或者理論的,就比較少了。

萬籟“俱寂”時,一家知名 IT 研究與顧問咨詢機構的發聲,給關係型資料庫這個平靜的池塘丟了顆巨石:2014 年,Gartner 正式提出了 HTAP 這個概念。

Gartner’s definition in 2014: utilizes in-memory computing technologies to enable concurrent analytical and transaction processing on the same in-memory data store.


Gartner’s new definition in 2018: supports weaving analytical and transaction processing techniques together as needed to accomplish the business task.

可以看到,Gartner 重點強調了使用記憶體技術實現 HTAP 的可行性,並表示 HTAP 將為巨大的業務創新創造機會,增量市場空間巨大。

一石捲起千層浪,陷入半沉寂的關係型資料庫技術,好像迎來了春天。那個時候,商業智能(BI)已經開始廣泛滲入到眾多企業的營銷業務體系裡了,處理數據的業務分析部門對實時處理和運維最簡化的需求越來越重要,HTAP 方案的提出自然迅速地引起了行業的強勢關註,因為這玩意兒光是聽起來就省心省力,誘惑很大。

我們正在做的 StoneDB,就是對標 Oracle MySQL HeatWave 的一款開源版實時一體化 HTAP 資料庫。

HTAP 流派

HTAP資料庫時間線,參考SIGMOD'22 - HTAP Database: A Tutorial

上圖是清華大學李國良教授團隊梳理的 HTAP 資料庫的發展時間線。我們這裡再舉幾個大家耳熟能詳的企業:像資料庫巨頭 Oracle 去年就推出了 MySQL HeatWave,沒錯,Oracle 官方已經明確表示了,做 HeatWave 的目的就是為了支持 HTAP,在最近的 Oracle CloudWorld 大會上還官宣了 MySQL HeatWave Lakehouse;Google 在 HTAP 上也動作頻頻,除了搞 F1 Lightning 以外,在今年 5 月 12 日的 Google I/O 2022 開發者大會還宣佈了雲原生 HTAP 資料庫 AlloyDB for PostgreSQL;緊接著,所有雲數倉都想打的知名廠商 SnowFlake 也在 6 月 14 日的用戶大會 Snowflake Summit 2022 上官宣正式推出 HTAP 存儲引擎 Unistore;資料庫獨角獸SingleStore(前身為 MemSQL) 也早就在 HTAP 領域上頻頻發聲,頂會論文都發了。國際上的這些大廠和獨角獸都在搞 HTAP,國內的更不用說了,阿裡、百度、騰訊、華為、位元組和眾多新興創業公司(包括咱們 StoneDB),以及老牌資料庫廠商都開始宣傳自己的一些產品可以實現或者主攻 HTAP。Gartner 之前在報告里預測說,到 2024 年,HTAP 資料庫會被廣泛用到各行各業中,現在看來,真的是有這種勢頭了。

顯而易見,HTAP 這倆馬車的車輪已經壓在了資料庫行業的歷史軌跡上,正在滾滾向前,勢不可擋。但是,隨著越來越多的廠商正式加入賽道,對於 HTAP 架構的技術實現,自然產生了一些分化。

我們之前在文章《深度乾貨!一篇 Paper 帶您讀懂 HTAP》中有做介紹,這篇報告里提到,至少有四種不同的架構方式可以實現 HTAP。

An Overview of HTAP Architectures

目前 HTAP 大致有四種實現方式:

  • 方案 1(一套系統一套存儲):在一個系統里用一種數據格式滿足兩種業務需求;

  • 方案 2(一套系統兩套存儲):一個系統里同時存在行存儲和列存儲,行存儲上的更新會定期導入到列存儲里轉換成列存儲格式;

  • 方案 3(兩套系統兩套存儲):系統里同時存在 OLTP 與 OLAP 兩套引擎,分別寫入和讀取行存儲和列存儲;

  • 方案 4(多套系統松耦合):不同的異構系統之間,通過獨立的插件服務對數據進行準實時同步,對外呈現 HTAP 能力。

HTAP Database: A Tutorial,SIGMOD'22

下麵這張表圖是我們對這四種架構方案的一個簡單的綜合盤點。

HTAP 迷思

隨著一些 HTAP 產品功能能夠實現落地了,在 HTAP 架構的選擇上引起了不少爭議(我們講叫技術口水戰),這很正常,大家都想說 HTAP 是自己做得比較好嘛。比如 StoneDB 這邊就比較支持完全一體化的混合負載架構(我們稱之為真正的 HTAP 面臨的挑戰);也有的團隊比較想搞那種兩套系統疊加的架構;還有更猛的,直接說要基於 GPU/CPU 搞 HTAP,就是 RateupDB,據說是全球唯一一個基於 GPU/CPU 和並行的 HTAP 資料庫,還發了一篇 VLDB,不過好像現在銷聲匿跡了,創始人目前應該是投身一家勢頭較猛的雲數倉創業公司去了。

由此可見,HTAP 雖然引起了一陣狂歡,但是,對 HTAP 資料庫架構選擇目前業界還是沒有一套特別稱得上成熟的方案,大家也都是在打磨產品中。有的走的稍微早了一些;有的還在孵化打磨;有的已經倒在半路上了,但是一個不可否認的事實是,大家都開始說自己能或者即將能支持 HTAP 了,就和資料庫領域另外一個爆火的“雲原生”關鍵字一樣,這真可謂是“二四八月亂穿衣”了,這也算是現在 HTAP 領域上存在的迷思吧。

新的趨勢:From Big to Small and Wide data

所以,在這個時候,作為率先提出要做 MySQL 開源 HTAP 資料庫的 StoneDB,想要稍微冷靜一下。

不是說我們不做 HTAP 了,而是有了一個新的思路。這個思路,也同樣來自於咱們的老朋友、好伙伴,大家都巴不得上他們報告的權威機構——Gartner。

Gartner 在去年發佈的《Gartner 2021 十大數據和分析趨勢》報告里,特別提到了一個重要的趨勢:。From Big to Small and Wide data

The Gartner 2021 Top Trends for Data and Analytics

據 Gartner 預測,到 2025 年 70% 的組織會把重點從“大”數據轉向“小”數據和“寬”數據,為分析提供更多的場景,使人工智慧(AI)減少對數據量的需求(原文是 making artificial intelligence (AI) less data hungry)。

當然,這個趨勢的調研結論是有背景的,那就是突如其來的新冠疫情。面對新冠,很多數據幾乎是一夜式爆髮式變化增長,導致了基於大量歷史數據的機器學習和人工智慧模型變得不那麼可靠,隨著智能決策變得更加複雜和嚴格,數據和分析領導者應選擇能夠更加有效利用現有數據的分析技術。

如何更加有效利用數據分析?那就是我們講的用“小”而“寬”的數據取代“大”數據來解決問題。小數據——顧名思義,指的是能夠使用所需數據量較少,但仍能提供實用洞見的數據模型。寬數據——可以理解為多模數據,即使用寬數據分析各種小而多樣化的非結構化和結構化數據源併發揮它們的協同效果,從而增強情景態勢感知(contextual awareness,情境感知)和決策。

下麵就來詳細講解一下 Small Data 和 Wide Data 的定義。

Small data 概念

小數據的方法是指使用相對較少的數據,但仍能提供有見解的分析技術。其中包括了有針對性地使用數據要求比較低的模型,比如一些時間序列分析的技術,而不是用一刀切的方式去使用數據量要求較高的深度學習技術。

通俗地來講,使用 AI 或者 ML 技術,往往需要大量的數據源作為分析的訓練模型,但並不是數據量越多越好,特別是那些過時的歷史數據,對分析毫無意義,如果可以及時地找到一些比較精準的小數據進行分析,往往能獲得更有價值的效果。總之,小數據側重於應用分析技術,在小量的、單獨的數據集中尋找有用的信息。

Wide data 概念

寬數據允許分析師檢查和組合各種大小、非結構化和結構化數據。具體來說,寬而廣泛的數據就是將各種來源的不同數據源捆綁在一起,以進行有意義的分析。

基於寬數據的數據分析技術圍繞著結構化和非結構化數據的分析和協同,而不管數據集是否直接相關。寬數據最大的特征是可以提取或識別異構數據集之間的聯繫。

Small and Wide data 結合的作用

Gartner 知名研究副總裁 Rita Sallam 表示:“使用‘小’而‘寬’的數據能夠提供強大的分析和 AI,同時降低企業機構對大型數據集的依賴性。企業機構可以使用‘寬’數據獲得更豐富、更完整的態勢感知或 360 度視圖,這將使企業機構能夠使用分析技術做出更好的決策。”

Gartner 高級研究總監孫鑫表示:“隨著企業逐漸認識到大數據作為分析和人工智慧關鍵推動者的局限性,被稱為小數據和寬數據的方法正在慢慢涌現,小數據的方法拋開了對於大型單體數據的依賴,實現了對於小型、大型、結構化、非結構化的數據源的分析和協同。”

同時,據 Gartner 預測,到 2025 年,超過 85% 的技術供應商,將在人工智慧解決方案當中加入讓數據變得更豐富的方法和模型訓練技術,以提高模型的彈性和敏捷性,而在 2020 年,這樣做的供應商只有不到 5%。 由此可見,小數據和寬數據的市場增量巨大。

Small and Wide data 核心場景

說了這麼多“小”數據和“寬”數據,這兩個到一塊兒究竟能落地到什麼應用場景上?

從一個具體的場景為例,現在電商以及社交媒體都在做一個實時推薦的業務場景,而實時推薦的標準流程是首先通過大數據系統對客戶的購買歷史進行分析,要關註客戶購買產品的生命周期,客戶與企業之間的交互歷史;同時要去通過各種渠道去瞭解,目前客戶正在什麼環境,聽到了什麼? 正在瀏覽什麼信息?結合各種數據進行分析,最後產生 Top10 的產品推薦,然後通過 App 或者其他手段推送給客戶。

在這個過程中,需要收集的數據非常龐大,包括各種結構化數據,例如歷史訂單,客戶個人信息等,另外客戶的上網日誌,網頁瀏覽歷史,客戶的位置信息, 行動軌跡,這些數據的體量都非常大,而一旦涉及到千萬乃至上億的用戶,同時上萬種產品的場景下,這個數據量就是天文數字,而等待所有這些數據都收集完整併進行 AI 建模預測,則很可能是 1-2 天之後的事情了。

所以,為了儘可能快地對客戶當前狀況進行反饋,並推出相應的推薦方案,必須把數據鏈條縮短:首先通過在生產系統端,貼合用戶的購買歷史和行為,對整個場景進行約束,從海量數據分析,變成小數據量的分析,把推薦產品從幾萬,縮小到幾十的範圍,這個時候,就是從大數據到“小”數據的過程。然後在此基礎之上,通過補足其他渠道的信息,包括圖像、聲音、瀏覽日誌等等,對幾十的範圍進行進一步的精準化定位。這個時候,則體現了“寬”數據的價值。

預計小數據和寬數據技術將產生積極的結果,即:

  • 零售需求預測(Retail demand forecasting)
  • 實時行為智能( Real time behavioral intelligence)
  • 超個性化和整體客戶體驗的改善( Hyper personalization and improvement of the overall customer experience)
  • 人生安全
  • 欺詐檢測
  • 自適應自動系統(比如自適應 AI)等等

雖然“小”數據和“寬”數據技術的確切結果還沒有出現,但這個概念肯定是未來可期的,因為這些技術能夠在過去或歷史趨勢不再相關的領域提供卓有成效的洞察分析能力。

對於從“大”數據到“小”數據的過程,一個趨勢就是,數據分析不必一定從數倉開始, 而是從前端業務系統,結合一定的場景,首先發起快捷的數據分析, 解決場景定位,方案範圍初篩等數據的初步處理,讓後繼的分析儘可能地聚焦在指定的領域,一方面減少計算量,同時加速後繼決策的速度。

所以業務系統在承擔業務交易的時候,必須增加一定的數據分析和篩選的能力, 這個和傳統的業務系統是純粹 OLTP 系統的定義不一樣, 將來業務系統的能力將會從 OLTP 向 HTAP 逐步變遷。

這一塊還有很多東西可以講,後續我們繼續探討,今天就先點一下。作為在數據分析領域耕耘多年的資料庫團隊,我們對這個觀點是非常認可的。因為,經常做數據分析的人都知道,隨著使用數據的場景越來越多,數據支撐運營的場景也越來越多,很多情況下,數據驅動運營需要的是近期的熱數據,而不是長時間的數據。而這個“熱數據”,再更精確一些講,就應該是“熱”的“小”而“寬”數據。

這恰恰和 StoneDB 提倡的基於 MySQL 的 HTAP 資料庫要能夠支持實時與中小數據量場景不謀而合(正常 10T 左右,最高不超過 100T,當然了,要是擴展成 LakeHouse,支持的數據量會更多)。也和 SingleStore 講的觀點很類似:沒有 HTAP,機器學習和人工智慧都是不切實際的。

基於此,我們提出一個 idea,即 StoneDB 這種強調對熱數據實時分析的 HTAP 資料庫,也可以叫做 SoTP 資料庫。

SoTP 初探

SoTP,即 Serving over TP。

Serving 是什麼?SoTP 的定義和驅動又是什麼?這個留給我們下一篇文章繼續解讀,歡迎關註 StoneDB 公眾號。

StoneDB 2.0 雲原生分散式實時 HTAP 架構詳細設計以 RFC 形式持續進行,歡迎大家關註我們最新進展,更歡迎給我們開源協作的模式和方法提出改進意見,一起通過開源的方式共建 StoneDB ~

https://github.com/stoneatom/stonedb/issues/436

  • StoneDB 代碼已完全在 Github 開源:

https://github.com/stoneatom/stonedb

  • StoneDB 官網:

https://stonedb.io/


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • apt-mirror 製作麒麟桌面版內網源 一、修改apt軟體安裝源 1、修改source.list安裝源 vi /etc/apt/sources.list 添加: deb http://archive.kylinos.cn/kylin/KYLIN-ALL 10.1 main universe mu ...
  • 3.1命令的基本格式 3.1.1 命令提示符 [[email protected] ~]# 這就是Linux系統的命令提示符。各部分含義如下: ●[]:這是提示符的分隔符號,沒有特殊含義。 ●root:顯示的是當前的登錄用戶,這裡使用的是root用戶登錄。 ●@:分隔符號,沒有特殊含義。 ●localho ...
  • 需要將系統語言切換為英文,即可完成註冊,後面使用可以用中文 註冊碼: 4C21U-2KK9Q-M8130-4V2QH-CF810 ...
  • 本文主要翻譯自 Arm Cortex-M7 Processor Technical Reference Manual r1p2 其中章節 Memory System / L1 caches / Store Buffer 。 Store Buffer Cache中的數據,在寫入memory或 AXIM ...
  • 有時項目外設比較多,很容易造成串口不夠用的情況。 最近就遇到了,新增加一個GPS模塊串口的,串口現在外部只有原來的調試串口可以用,所以 嘗試將調試口更改為普通串口。 經過網上看大神們的文章和自己摸索,總結如下: V3S 修改調試串口步驟: 第一步修改設備樹: 路徑~/corelinux/v3ssdk ...
  • 1. 前文回顧 在上篇文章 《深入理解 Linux 虛擬記憶體管理》 中,筆者分別從進程用戶態和內核態的角度詳細深入地為大家介紹了 Linux 內核如何對進程虛擬記憶體空間進行佈局以及管理的相關實現。在我們深入理解了虛擬記憶體之後,那麼何不順帶著也探秘一下物理記憶體的管理呢? 所以本文的目的是在深入理解虛擬 ...
  • 分庫分表,是企業裡面比較常見的針對高併發、數據量大的場景下的一種技術優化方案,也是一個非常高頻的面試題。但是,因為很多人其實並沒有非常豐富的分庫分表的經驗,所以能把這個問題回答得比較好的人其實還挺少的。 那麼,本文就來試圖把關於分庫分表的事情,一次性講個清楚。 ...
  • 一、MySQL簡介 ​ MySQL是一種關係型資料庫管理系統,關係資料庫將數據保存在不同的表中,而不是將所有數據放在一個大倉庫內,這樣就增加了速度並提高了靈活性。 二、安裝與下載 1、下載流程 1、訪問官方(www.mysql.com) 2、點擊‘DOWNLOADS’,進入下載界面 3、下拉,找到‘ ...
一周排行
    -Advertisement-
    Play Games
  • 1.部署歷史 猿友們好,作為初來實習的我,已經遭受社會的“毒打”,所以請容許我在下麵環節適當吐槽,3Q! 傳統部署 ​ 回顧以往在伺服器部署webapi項目(非獨立發佈),dotnet環境、守護進程兩個逃都逃不掉,正常情況下還得來個nginx代理。不僅僅這仨,可能牽扯到yum或npm。node等都要 ...
  • 隨著技術的進步,跨平臺開發已經成為了標配,在此大背景下,ASP.NET Core也應運而生。本文主要基於ASP.NET Core+Element+Sql Server開發一個校園圖書管理系統為例,簡述基於MVC三層架構開發的常見知識點,前一篇文章,已經簡單介紹瞭如何搭建開發框架,和登錄功能實現,本篇... ...
  • 這道題只要會自定義cmp恰當地進行排序,其他部分沒有什麼大問題。 上代碼: 1 #include<bits/stdc++.h> 2 using namespace std; 3 int n,s,h1,h2,cnt; 4 struct apple{ 5 int height,ns;//height為蘋 ...
  • 這篇文章主要描述RPC的路由策略,包括為什麼需要請求隔離,為什麼不在註冊中心中實現請求隔離以及不同粒度的路由策略。 ...
  • 簡介: 中介者模式,屬於行為型的設計模式。用一個中介對象來封裝一系列的對象交互。中介者是各對象不需要顯式地相互引用,從而使其耦合鬆散,而且可以獨立地改變他們之間的交互。 適用場景: 如果平行對象間的依賴複雜,可以使用中介者解耦。 優點: 符合迪米特法則,減少成員間的依賴。 缺點: 不適用於系統出現對 ...
  • 【前置內容】Spring 學習筆記全系列傳送門: Spring學習筆記 - 第一章 - IoC(控制反轉)、IoC容器、Bean的實例化與生命周期、DI(依賴註入) Spring學習筆記 - 第二章 - 註解開發、配置管理第三方Bean、註解管理第三方Bean、Spring 整合 MyBatis 和 ...
  • 簡介: 享元模式,屬於結構型的設計模式。運用共用技術有效地支持大量細粒度的對象。 適用場景: 具有相同抽象但是細節不同的場景中。 優點: 把公共的部分分離為抽象,細節依賴於抽象,符合依賴倒轉原則。 缺點: 增加複雜性。 代碼: //用戶類 class User { private $name; fu ...
  • 這次設計一個通用的多位元組SPI介面模塊,特點如下: 可以設置為1-128位元組的SPI通信模塊 可以修改CPOL、CPHA來進行不同的通信模式 可以設置輸出的時鐘 狀態轉移圖和思路與多位元組串口發送模塊一樣,這裡就不給出了,具體可看該隨筆。 一、模塊代碼 1、需要的模塊 通用8位SPI介面模塊 `tim ...
  • AOP-03 7.AOP-切入表達式 7.1切入表達式的具體使用 1.切入表達式的作用: 通過表達式的方式定義一個或多個具體的連接點。 2.語法細節: (1)切入表達式的語法格式: execution([許可權修飾符] [返回值類型] [簡單類名/全類名] [方法名]([參數列表]) 若目標類、介面與 ...
  • 測試一、虛繼承與繼承的區別 1.1 單個繼承,不帶虛函數 1>class B size(8): 1> + 1> 0 | + (base class A) 1> 0 | | _ia //4B 1> | + 1> 4 | _ib //4B 有兩個int類型數據成員,占8B,基類邏輯存在前面 1.2、單個 ...