5月21日，任正非接受媒體采訪。2萬字的媒體實錄中，74歲的任正非在回答中27次提及了“數(shù)學(xué)”，例舉了諸多數(shù)學(xué)對于華為的重要性。

這不是任正非和華為第一次強調(diào)數(shù)學(xué)。這個一直偏冷門的基礎(chǔ)學(xué)科在近年來的技術(shù)浪潮和貿(mào)易戰(zhàn)背景下，再一次被提上了新的高度。

那么，數(shù)學(xué)在數(shù)據(jù)和AI研發(fā)中到底有什么作用？在這場中國的自主創(chuàng)新征戰(zhàn)中，數(shù)學(xué)人又能發(fā)揮怎樣的作用呢？

對于這個話題，或許沒有人比蔣步星更有發(fā)言權(quán)。

上個世紀80年代，蔣步星作為第一代奧數(shù)選手在德國布倫瑞克市獲得了國際數(shù)學(xué)奧林匹克競賽（imo）獲得個人金獎和團體賽冠軍。

也是在當年，他進入了清華大學(xué)計算機系理論班。1996年清華大學(xué)計算機系碩士畢業(yè)后，他先后在清華大學(xué)及紫光、長天等公司任職主持信息系統(tǒng)開發(fā)，2000年創(chuàng)立潤乾公司，致力于研發(fā)包括數(shù)據(jù)庫在內(nèi)的通用基礎(chǔ)軟件。

近日，蔣步星老師也撰長文，分享了自己如何用數(shù)學(xué)，做中國人自己的數(shù)據(jù)庫系統(tǒng)，從中可一窺一個“數(shù)學(xué)人”的家國情懷和實業(yè)精神。

以下為全文：

題目《莫非我就是被時代呼喚的數(shù)學(xué)人？》

作者：蔣步星

最近中美貿(mào)易戰(zhàn)，華為成了焦點。任老爺子一席大論，據(jù)說有27次提到了數(shù)學(xué)；緊接著，某著名公號的一篇《時代呼喚數(shù)學(xué)家》又刷了屏，直把數(shù)學(xué)家推到了風(fēng)口浪尖，讓人感覺數(shù)學(xué)的春天就要來了。

熟悉我所做工作的朋友也來問我：是不是有很多人來找我了。其實慚愧，并沒有多少，所以寫個文章蹭蹭熱點宣傳一下。

我是在用數(shù)學(xué)搞軟件，但距離主流數(shù)學(xué)很遠，而且遠未成功，不敢妄稱為“家”，因此把標題改了下，謙虛些說是數(shù)學(xué)人吧。

我在做什么？

我們在搞號稱IT三大核心技術(shù)之一的數(shù)據(jù)庫！另外兩大是CPU和操作系統(tǒng)。CPU太硬，我毫無發(fā)言權(quán)；操作系統(tǒng)略知一二，發(fā)言權(quán)也不多。數(shù)據(jù)庫領(lǐng)域嘛，確實是比較熟悉的。

我國的數(shù)據(jù)庫做得怎樣呢？

N年前，除了國外巨頭外，只有幾個國家隊在搞數(shù)據(jù)庫（所謂國家隊，其實也是企業(yè)，但主要由政府資金來支持）。不客氣說，國家隊做得很差。這無關(guān)從業(yè)人員的能力和情懷，而是路子方向的問題。國家隊做數(shù)據(jù)庫，并不是因為有需求刺激，而就是為了做而做，技術(shù)路線也基本是抄（有些直接拿開源改），這要能做好才是奇怪的事情。去年中興事件時，我寫了一篇文章《國產(chǎn)數(shù)據(jù)庫通通都沒戲！》說這個現(xiàn)象。

近年來，有許多企業(yè)加入數(shù)據(jù)庫開發(fā)的行列。企業(yè)隊和國家隊的根本不同在于，企業(yè)隊有明確的需求，也就是很清楚地知道要解決的問題。特別是互聯(lián)網(wǎng)行業(yè)中巨大用戶量的應(yīng)用，繼續(xù)使用國外數(shù)據(jù)庫，要么撐不住，要么買不起。在需求的刺激下，做出來的產(chǎn)品在某些方面就能夠達到世界領(lǐng)先水平了。在競爭中的國家隊也開始企業(yè)化轉(zhuǎn)型，能力也在不斷提升。

不過，過去的國家隊固然沒什么建樹，今天的企業(yè)隊也仍然只是在工程上進行優(yōu)化，使自家產(chǎn)品比國外產(chǎn)品更適合某類場景，并沒有獲得壓倒性的優(yōu)勢。面臨的技術(shù)難題也只是得到了一定程度的緩解，沒有從根本上解決。

其實不僅國內(nèi)，全世界范圍也是這樣。大家都只是在工程上做些優(yōu)化，甚至有些搞法也只能叫改造不能說是優(yōu)化。比如NoSQL產(chǎn)品，在吞吐率上做了提升，但嚴重犧牲了計算能力，還放棄了某些場合很重要的一致性能力；某些NewSQL產(chǎn)品為了擴展能力和一致性做了妥協(xié)；而近年來熱門的大數(shù)據(jù)庫平臺Hadoop，原本試圖顛覆傳統(tǒng)關(guān)系型數(shù)據(jù)倉庫，但搞來搞去又在回歸到SQL去了。

我怎么做數(shù)據(jù)庫？

我們發(fā)明新數(shù)學(xué)！

現(xiàn)在的數(shù)據(jù)庫在用什么數(shù)學(xué)呢？

目前主流數(shù)據(jù)庫是關(guān)系數(shù)據(jù)庫，之所以這么叫，是因為它的數(shù)學(xué)基礎(chǔ)被稱為關(guān)系代數(shù)，這是少有的幾項計算機領(lǐng)域?qū)Ｓ玫臄?shù)學(xué)。

關(guān)系代數(shù)已經(jīng)發(fā)明近五十年了，五十年前的應(yīng)用需求以及硬件環(huán)境，和今天比的差異是很巨大了，繼續(xù)延用五十年前的理論來解決今天的問題，是不是聽著就感覺太陳舊了？然而現(xiàn)實就是這樣，由于存量用戶太多，而且也還沒有成熟的新技術(shù)出現(xiàn)，基于關(guān)系代數(shù)設(shè)計的SQL，今天仍然是最重要的數(shù)據(jù)庫開發(fā)語言。雖然這幾十年來也有一些改進完善，但根子并沒有變，面對當代的復(fù)雜需求和硬件環(huán)境，關(guān)系數(shù)據(jù)庫并沒有那么得心應(yīng)手了。

舊瓶難再裝新酒。

要說清這個問題，我們要看數(shù)據(jù)庫到底在干什么事情？

數(shù)據(jù)庫這個產(chǎn)品，名字中有個庫字，會讓人覺得它主要是為了存儲的。其實不然，簡單的存儲很容易解決，數(shù)據(jù)庫真正干的事有兩條：計算、交易！存儲也是為這兩件事服務(wù)的。

計算問題

先說計算，也就是我們常說的OLAP能力。這里我更愿意用計算這個詞，而不用分析（OLAP中的A）。計算的概念更廣泛且更務(wù)實一些，它并不單指加加減減，查找、關(guān)聯(lián)都可以看成是某種計算。

什么樣的計算體系才算好呢？

又是兩條：寫著簡單、跑得快。

寫著簡單，很好理解，就是讓程序員很快能寫出來代碼來，這樣單位時間內(nèi)可以完成更多的工作；跑得快更容易理解，我們當然希望更短時間內(nèi)獲得計算結(jié)果。

那么，關(guān)系數(shù)據(jù)庫，或者說SQL，在這兩方面做得怎么樣呢？

SQL語句很象英語，有些查詢可以當英語來讀和寫（網(wǎng)上多得很，就不舉例了），這應(yīng)當算是滿足寫著簡單這一條了吧。

且慢！我們在教科書上看到的SQL經(jīng)常只有兩三行，這些SQL確實算是寫著簡單的，但如果我們嘗試一些稍復(fù)雜化的問題呢？

我經(jīng)常舉的一個其實還算簡單的例子：計算一支股票最長連續(xù)上漲了多少天？用SQL寫出來是這樣的：

SELECT MAX（連續(xù)日數(shù)） FROM （SELECT COUNT（*） 連續(xù)日數(shù) FROM （SELECT SUM（漲跌標志） OVER （ ORDER BY 交易日） 不漲日數(shù) FROM （ SELECT 交易日， CASE WHEN 收盤價》LAG（收盤價） OVER（ ORDER BY 交易日 THEN 0 ELSE 1 END 漲跌標志 FROM 股票 ）） GROUP BY 不漲日數(shù)）

這個語句的工作原理就不解釋了，程序員們可以自己嘗試一下。

這曾經(jīng)是我公司的招聘考題，通過率不足20%；因為太難，后來把它改了一種方式：把SQL語句寫出來讓應(yīng)聘者解釋它在算什么，通過率依然不高。這說明什么？說明SQL即難懂又難寫！

再看跑得快的問題，還是一個經(jīng)常拿出來的簡單例子：1億條數(shù)據(jù)中取前10名。這個任務(wù)用SQL寫出來并不復(fù)雜：

SELECT TOP 10 x FROM T ORDER BY x DESC

但是，這個語句對應(yīng)的執(zhí)行邏輯是先對所有數(shù)據(jù)進行大排序，然后再取出前10個，后面的不要了。大家知道，排序是一個很慢的動作，會多次遍歷數(shù)據(jù)，如果數(shù)據(jù)量大到內(nèi)存裝不下，那還需要外存做緩存，性能還會進一步急劇下降。如果嚴格按這句SQL體現(xiàn)的邏輯去執(zhí)行，這個運算無論如何是跑不快的。然而，很多程序員都知道這個運算并不需要大排序，也用不著外存緩存，一次遍歷用一點點內(nèi)存就可以完成，也就是存在更高性能的算法。可惜的是，用SQL卻寫不出這樣的算法，只能寄希望于數(shù)據(jù)庫的優(yōu)化器足夠聰明，能把這句SQL轉(zhuǎn)換成高性能算法執(zhí)行，但情況復(fù)雜時數(shù)據(jù)庫的優(yōu)化器也未必靠譜。

看樣子，SQL，也就是關(guān)系數(shù)據(jù)庫，在這兩方面做得并不好。這兩個并不復(fù)雜的問題都是這樣，現(xiàn)實中數(shù)千行的SQL代碼中，這種難寫且跑不快的情況比比皆是。

為什么SQL做得不夠好呢？

要回答這個問題，我們需要分析一下用程序?qū)崿F(xiàn)計算到底是在干什么。

本質(zhì)上講，編寫程序的過程，就是把解決問題的思路翻譯成計算機可執(zhí)行的精確化形式語言的過程。舉例來說，就象小學(xué)生解應(yīng)用題，分析問題想出解法之后，還要列出四則運算表達式。用程序計算也是一樣，不僅要想出解決問題的方法，還要把解法翻譯成計算機能理解執(zhí)行的動作才算完成。

用于描述計算方法的形式語言，其核心在于所采用的代數(shù)體系。所謂代數(shù)體系，簡單說就是一些數(shù)據(jù)類型和其上的運算規(guī)則，比如小學(xué)學(xué)到的算術(shù)，就是整數(shù)和加減乘除運算。有了這套東西，我們就能把想做的運算用這個代數(shù)體系約定的符號寫出來，也就是代碼，然后計算機就可以執(zhí)行了。

如果這個代數(shù)體系設(shè)計時考慮不周到，提供的數(shù)據(jù)類型和運算不方便，那就會導(dǎo)致描述算法非常困難。這時候會發(fā)生一個怪現(xiàn)象：翻譯解法到代碼的難度遠遠超過解決問題本身。

舉個例子，我們從小學(xué)習(xí)用阿拉伯數(shù)字做日常計算，實施加減乘除都很方便，所有人都天經(jīng)地義認為數(shù)值運算就該是這樣的。其實未必！我想大多數(shù)人都知道還有一種叫做羅馬數(shù)字的東西，我不知道羅馬數(shù)字體系是不是還有我們熟悉的加減乘除運算（它那個數(shù)字體系無法象阿拉伯數(shù)字這樣方便地實施這些運算，很可能運算定義也不同了），我也一直很困惑古羅馬人是如何上街買菜的？

這樣，我們知道了，程序難寫很大程度是代數(shù)的問題。

再看跑不快的原因。

軟件沒辦法改變硬件的性能，CPU和硬盤該多快就是多快。不過，我們可以設(shè)計出低復(fù)雜度的算法，也就是計算量更小的算法，這樣計算機執(zhí)行的動作變少，自然也就會快了。但是，光想出算法還不夠，還要把這個算法用某種形式語言寫得出來才行，否則計算機不會執(zhí)行。

而且，寫起來還要比較簡單，都要寫很長很麻煩，也沒有人會去用。所以呢，對于程序來講，跑得快和寫著簡單其實是同一個問題，背后還是這個形式語言采用的代數(shù)的問題。如果這個代數(shù)不好，就會導(dǎo)致高性能算法很難實現(xiàn)甚至實現(xiàn)不了，也就沒辦法跑得快了。就象上面說的，用SQL寫不出我們期望的小內(nèi)存單次遍歷算法，能不能跑得快就只能寄希望于優(yōu)化器。

我們再做個類比：

在國內(nèi)上過小學(xué)的同學(xué)大概都知道高斯計算1+2+3+.。.+100的小故事。普通人就是一步步地硬加100次，高斯小朋友很聰明，發(fā)現(xiàn)1+100=101、2+99=101、。..、50+51=101，結(jié)果是50乘101，很快算完回家午飯了。

聽過這個故事，我們都會感慨高斯很聰明，能想到這么巧妙的辦法，即簡單又迅速。這沒有錯，但是，大家容易忽略一點：在高斯的時代，人類的算術(shù)體系（也是一個代數(shù)）中已經(jīng)有了乘法！象前面所說，我們從小學(xué)習(xí)四則運算，會覺得乘法是理所當然的，其實并不是，乘法是后于加法被發(fā)明出來的。如果高斯的年代還沒有乘法，即使有聰明的高斯，也沒辦法快速解決這個問題。

現(xiàn)在，我們可以回答前面的問題：為什么關(guān)系數(shù)據(jù)庫在我們期望的那兩個方面做得不夠好？

問題出在關(guān)系代數(shù)上，關(guān)系代數(shù)就象只有加法還沒發(fā)明乘法的算法體系，很多事做不好是必然的。

而且，不幸的是，這個問題是理論上的，在工程上無論如何優(yōu)化也無濟于事，只能有限改善，不能根除。不過，絕大部分的數(shù)據(jù)庫開發(fā)者并不會想到這一層，或者說為了照顧存量用戶的兼容性，也沒打算想到這一層。于是，主流數(shù)據(jù)庫界一直在這個圈圈里打轉(zhuǎn)轉(zhuǎn)。

那么該怎么辦呢？也就是如何讓計算寫著更簡單、跑得更快呢？

發(fā)明新的代數(shù)！有“乘法”的代數(shù)。

嗯，數(shù)學(xué)來了！

交易問題

說完計算，我們再說說交易，也就是常說的OLTP能力。

現(xiàn)在是云計算的時代，幾乎所有的數(shù)據(jù)庫廠商都在忙著上云。但是，目前這個數(shù)據(jù)庫真地適合上云嗎？

其實，包括某些世界巨頭在內(nèi)的所謂云數(shù)據(jù)庫，就是把家里的數(shù)據(jù)庫物理地搬到云服務(wù)器上而已，其它方面仍然只是工程上的改造，在強一致性和可擴展性之間進行一定的權(quán)衡妥協(xié)，應(yīng)用開發(fā)過程和傳統(tǒng)數(shù)據(jù)庫沒有太大區(qū)別。當然，我們不能說這就不算是云應(yīng)用，但這種機制并未體現(xiàn)云應(yīng)用的基本特征。

云應(yīng)用的基本特征在于數(shù)據(jù)結(jié)構(gòu)的多樣性。

云應(yīng)用將打破企業(yè)界限，不象傳統(tǒng)應(yīng)用每個用戶做一個，而是云服務(wù)商提供一個系統(tǒng)面對所有用戶；應(yīng)用也不象以前那樣一期一期做下去，而要永遠在線，只能熱升級。不同用戶的數(shù)據(jù)結(jié)構(gòu)不完全一樣，同一個用戶在不同時段的數(shù)據(jù)結(jié)構(gòu)也會變，這樣就會積累大量不同結(jié)構(gòu)的數(shù)據(jù)要一起存儲和計算。這是關(guān)系數(shù)據(jù)庫在設(shè)計時沒有被考慮過的問題，因為關(guān)系代數(shù)幾乎沒有設(shè)計針對多樣性結(jié)構(gòu)數(shù)據(jù)的處理能力。

繼續(xù)采用關(guān)系數(shù)據(jù)庫（或其變種）應(yīng)對云應(yīng)用，就會面臨個性化和海量用戶之間的矛盾：想要海量用戶，就要犧牲個性化（所有用戶面對同樣數(shù)據(jù)結(jié)構(gòu)的應(yīng)用）；想要個性化（各有各的數(shù)據(jù)結(jié)構(gòu)）就要犧牲用戶量（只服務(wù)相對數(shù)量較少的用戶）。但是云應(yīng)用恰恰要求個性化和大用戶量這兩個特征并存。

交易數(shù)據(jù)庫還有個重要指標是保證一致性（網(wǎng)上解釋很多，這里不贅述）。關(guān)系數(shù)據(jù)庫雖然能夠?qū)崿F(xiàn)一致性，但資源消耗嚴重，這會導(dǎo)致并發(fā)能力下降，而多并發(fā)又是云應(yīng)用常有的特征。

關(guān)系數(shù)據(jù)庫實現(xiàn)一致性的成本過高，原因在于它的數(shù)據(jù)組織機制，這由參與操作的數(shù)據(jù)類型決定，而數(shù)據(jù)類型是被關(guān)系代數(shù)規(guī)定的。

和前面說的多樣性一樣，想要實現(xiàn)低成本的一致性，就要打破關(guān)系代數(shù)，換一種方式組織和存儲數(shù)據(jù)。

嗯，還是數(shù)學(xué)！

在路上

用了這么多篇幅說明當前數(shù)據(jù)庫采用的代數(shù)體系有問題，這是一回事。而發(fā)明一個新的代數(shù)體系，那完全是另一回事。僅僅改進某一項運算并不算很困難，但要將各種數(shù)據(jù)類型和運算整合在一個體系中，保證封閉和自洽，這就會是一個巨大的挑戰(zhàn)。

這里就封閉和自洽解釋一下。封閉性是指任何計算結(jié)果必須仍然屬于定義過的數(shù)據(jù)類型，一個不滿足封閉性的代數(shù)無法連續(xù)地運算。比如整數(shù)對加減乘封閉，而對除法不封閉，在整數(shù)范圍內(nèi)就不能連續(xù)隨意地做四則運算，要么對除法做限制，要么把整數(shù)擴展到有理數(shù)。

而自洽性是指這些運算不能出現(xiàn)矛盾的結(jié)果，比如我們要約定不能除以0，否則把某個數(shù)除以0規(guī)定成任何數(shù)都能推出邏輯矛盾，這個體系就沒法計算出正確的東西。封閉性和自洽性是合理代數(shù)體系必須滿足的條件。

同時在應(yīng)用方面，為了讓它有足夠的描述能力，也就是讓我們常見的需求都能輕松用基本數(shù)據(jù)類型和運算組合出來，這就希望數(shù)據(jù)類型和運算盡量多。但是，為了降低整體的復(fù)雜度和相應(yīng)的學(xué)習(xí)成本，又要讓數(shù)據(jù)類型和運算盡量少。這一多一少的權(quán)衡也是個學(xué)問。數(shù)學(xué)上有個最小完備集這個概念，大體就是這個意思，我們設(shè)計的數(shù)據(jù)類型和運算要正好夠，沒有多余的也沒有不足的。

結(jié)果呢，我們用了十年時間，歷經(jīng)四次推倒重構(gòu)，今天才終于能把OLAP功能發(fā)布出來，而解決OLTP的云數(shù)據(jù)庫仍在實驗環(huán)境中打磨。

當年我在清華BBS上的網(wǎng)名就是“十年磨一劍”，一語成讖。

十年磨出個什么東西呢？

磨出了新的代數(shù)！我們起了個數(shù)學(xué)味道的名字：離散數(shù)據(jù)集。基于這個代數(shù)，我們設(shè)計了新的形式語言，起名為SPL（Structured Process Language）。

這篇文章內(nèi)不合適詳細解釋離散數(shù)據(jù)集的內(nèi)容了，我只把前面的例子用SPL寫出來，簡單感受一下。

一支股票最長連續(xù)上漲多少天：

股票.sort（交易日）.group@o（收盤價《收盤價［-1］）.max（~.len（））

計算思路和前面的SQL是一樣的，但因為引入了有序運算后，表達起來要容易得多，不再繞了。

1億條數(shù)據(jù)中取前10名：

T.groups（;top（-10，x））

SPL有更豐富的集合數(shù)據(jù)類型，這條語句就表述了單次遍歷上實施簡單聚合的高效算法，不必大排序。

高性能是大數(shù)據(jù)技術(shù)的永恒追求。在新代數(shù)支持下，我們能把數(shù)據(jù)庫計算的性能提高到什么程度呢？

幾個月前，我就去年做過一場性能測試寫過一篇文章《怎樣讓國產(chǎn)芯片性能超越Intel》：用SPL在低性能芯片上實現(xiàn)的高性能算法，能遠遠超越SQL在高性能芯片上寫出的低性能算法。這是數(shù)學(xué)的力量！

我們也敢于和傳統(tǒng)數(shù)據(jù)庫叫板，包括國際巨頭在內(nèi)，面對SQL寫出的慢代碼，改用SPL后平均能提速一個數(shù)量級。這是數(shù)學(xué)的底氣！

感謝數(shù)學(xué)

《感謝數(shù)學(xué)》是我在15年前紀念陳省身教授逝世時寫的文章，其中解釋了數(shù)學(xué)給我了什么，今年有機會應(yīng)同學(xué)之邀又做了一次題為“感謝數(shù)學(xué)”的講座，進一步詮釋了數(shù)學(xué)對我的意義。這些內(nèi)容，同時也可以解釋我為什么可以做這個東西，或者應(yīng)當問得更直白一些：我為什么敢做這個東西？

要撼動有如此深厚巨大用戶基礎(chǔ)的關(guān)系數(shù)據(jù)庫，把用戶從多年的使用習(xí)慣中扳出來，當真是談何容易。我知道有無數(shù)從業(yè)人員因為兼容性而放棄創(chuàng)新，我自己也被無數(shù)次地好心勸過這路線太艱難。

“有數(shù)學(xué)，就有信心！”

數(shù)學(xué)給了我嚴格和抽象的思維。多一點嚴格認真，就能發(fā)現(xiàn)更多別人看不到的盲點；多一點抽象能力，就能比別人看得更深更遠。

馬車總歸是馬車，再優(yōu)化它還是馬車，還是要靠馬拉動。初生的汽車，操作上當然會有各種不習(xí)慣，功能上也會有眾多不如意，甚至還可能跑散架了。但它是汽車，是用發(fā)動機驅(qū)動的，假以時日不斷完善，它的巨大優(yōu)勢必將全面碾壓馬車。

在計算機的幫助下，人類第一次有了機械化處理大規(guī)模數(shù)據(jù)的能力。同時，也不可避免地遭遇許多以往不曾面對過的新問題。這些問題可能涉及到計算機的基礎(chǔ)理論，無法簡單地使用工程方法去處理，而需要發(fā)展出新的數(shù)學(xué)體系，采用新的模型才能解決。

然而，與工程上取得的巨大成功相比，計算機科學(xué)在理論方面卻非常單薄，只能數(shù)出可計算性、關(guān)系代數(shù)等幾個為數(shù)不多的領(lǐng)域。計算機界使用的數(shù)學(xué)，大部分是幾十年甚至上百年前早就被數(shù)學(xué)家們發(fā)明過的。

三百年前剛發(fā)明微積分的年代，各種猜想定理層出不窮，數(shù)學(xué)家們時不時就能把名字寫進我們的教科書，這些名垂青史的成果現(xiàn)在看來并不復(fù)雜（當時提出來并不容易），普通理工科學(xué)生都能理解。這完全不同于當代主流數(shù)學(xué)領(lǐng)域，不學(xué)二十年根本無法和人交流。

現(xiàn)在的計算機數(shù)學(xué)也正當時，處于最容易出成果的時代。我也有信心，終有一天，離散數(shù)據(jù)集理論也會寫進大學(xué)教科書！