2.3 大數據戰略的落地

如果企業在云原生數字化應用運營一段時間后，建立了持續創新的文化并積累了一定數量的數據，就可以考慮建立基于大數據且由AI驅動的高階數字化戰略。在第二代平臺時代，企業部署IT系統的時候通常會有咨詢公司提供同行的成熟案例。企業只要把同行成功實施的軟件大體不變地安裝下來，再加入少量定制功能即可。而在基于大數據和由AI驅動的高階數字化戰略中，不能照搬同行的成熟案例和經驗。首先，行業領袖的數字化軟件基本上是在PaaS平臺自主開發的，它的軟件不能被拷貝。即使可以拷貝，它的軟件的升級速度也使得拷貝版本很難跟上。其次，企業的高階數字化戰略的輸出通常是訓練過的并且符合自身需要的數學模型的參數。即使將這些模型和參數拷貝到自己的企業，也與企業的核心優勢不匹配。那么，成功地將高階數字化戰略落地的企業案例是否可以被學習呢？答案是依然可以，但需要進行更高層次的抽象，學習這些大數據企業高階數字化戰略成功背后的“元數據”。所謂元數據，是數據庫里面描述其他數據的數據。本節將討論高階數字化戰略成功背后的元數據：

?大數據和AI人才

?AI驅動的開發方法和文化

?大數據基礎設施

一旦企業建立了基于這些元數據的數字化戰略，就能在基于大數據的智能應用上推陳出新并持續創新。

2.3.1 大數據和AI人才

第一階段的數字化應用開發的主角是軟件工程師。他們可以根據數字化業務的需求，在PaaS云上采用云原生的方式持續迭代應用開發。進入基于大數據和AI的高階數字化階段以后，企業需要引入兩個新的角色：數據工程師（Data Engineer）和數據科學家（Data Scientist）。

數據工程師主要負責企業大數據基礎設施的建設以及企業內部數據的收集。這個角色和傳統的DBA角色類似，但是比起傳統的DBA，他們管理的數據基礎設施的規模更大，采集的數據量更大。更明確地說，傳統DBA一般管理Oracle、MySQL和PostgreSQL等關系數據庫系統下的事務型數據庫，而數據工程師不僅要管理這些關系數據庫，還要創建和管理Hadoop或者Greeplum等系統下的分析型大數據系統。在這些大數據系統里，還需要創建一定的數據模型來存儲和管理企業的數據。這類分析型數據模型也與傳統事務型數據模型有很大差別。以用戶的收貨地址為例，傳統事務型數據模型只需捕獲到用戶的當前地址，而分析型數據模型通常需要捕獲用戶歷史中所有更新過的地址。作者所在公司就有一個專門的數據工程師團隊，他們幫助企業建立基于Greenplum的大數據系統，創建分析型數據模型，收集企業運營產生的數據。數據工程師的教育背景通常是計算機專業，或者受過計算機專業培訓。

數據科學家對于大部分管理者而言是個全新的職能崗位。相比軟件工程師和數據工程師，他們未必需要有計算機專業背景，而是可能來自于數學、統計和物理專業。其實，華爾街早年的量化分析師就算得上數據科學家，他們的主要工作就是創建各種數學模型。早期的數學模型主要建立在統計方法上面，現在的機器學習模型主要建立在大數據上。因為AI驅動的數字化戰略的崛起，使得數據科學家的人才缺口急劇擴大。數據科學家作為正式的工種與大數據的概念同時產生。《哈佛商業周刊》在2012年的10月刊上曾發表過一篇名為《數據科學家：21世紀最性感的工作》的文章。文章給出了一個例子：斯坦福大學物理學博士畢業生Goldman通過自己創建的數據模型來給領英用戶推薦可能認識的朋友。這個模型給出的推薦相較其他來源的內容在領英同一個頁面位置的點擊率要高出30%。IBM在2017發布的報告中曾預測美國的數據科學相關的崗位數量到2020年將增加364000個，總數將達到272萬以上。可見，工作崗位需求的增長速度遠高于人才供給增長速度。這也使得數據科學家的薪水漲幅驚人。

對于企業而言，建設數據工程師和數據科學家團隊可以從以下兩方面努力：

1）選擇好的大數據和AI平臺，盡量平民化數據模型，降低人才的進入門檻。

2）選擇合作伙伴，在實踐中培養人才。作者所在公司的數據科學家團隊會通過結對方式，在實踐中幫助轉型企業建立他們的數據科學家團隊。從供給端看，高等教育機構和產業領袖應重視數據科學人才的培養，并從產業和教育的角度共同促進人才培養。

因為數據工程師和數據科學家崗位的出現，企業通常會設置首席數據官（Chief Data Officer, CDO）來代表數據科學家出席公司執行層的圓桌會議。CDO在公司的戰略建議權很大程度上能夠反映該企業所處的數字化轉型的階段。如果CDO的決策影響力很大，通常意味著該企業已進入AI驅動的階段。后面我們將在AI驅動的公司文化中深入討論這個問題。

最后要強調的是，這三類人才不是互斥的。優秀的軟件工程師通常具有扎實的計算機科學知識的功底，他們也可能同時擅長數據工程和數據科學。但是企業要同時在這三方面下功夫。原因有以下兩方面：一是這類“三位一體”的通才可遇不可求；二是即使有這樣“三位一體”的人才團隊，也會因為工程量巨大而不得不分而治之。因此，作者建議，在人才培養方面，團隊的每個成員都要有兩方面知識的重疊。例如，軟件工程師要懂得數據模型，數據工程師要懂得數據科學，數據科學家要懂得應用開發。這樣的配置有助于提高團隊的溝通效率，也能增強團隊成員之間的同理心。

2.3.2 AI驅動的開發方法和文化

AI驅動的開發方法要求應用、數據和模型三位一體地螺旋迭代上升。《Cloud Foundry：從數字化戰略到實現》一書中提到的測試驅動和持續交付的方法對此同樣適用。這種情況下對于產品經理的要求比較高，他需要和各個團隊的技術負責人一起協調創建產品開發的任務列表（Backlog）。為了確保敏捷性，在人才配備方面，應盡量確保人才具備應用、數據和模型這三種技能中的兩種。各個團隊在接口方面要保證一定的穩定性，例如，在模型團隊的輸入/輸出比較明確的情況下，應用開發團隊只要根據模型的輸出來決定應用的輸出即可。這樣用戶看到的應用輸出就是穩定的，隨著模型團隊的改進，用戶會感覺到應用的輸出越來越智能。比如，前面提到過的新聞閱讀終端的例子，用戶會看到內容的版式相對穩定。同時，因為模型團隊的精度提高，每個版面的內容將越來越精準地反映用戶偏好。這里提到的方法聽上去不難，但是要順利實施，讓這些方法發揮出最大的效用，企業的文化土壤也需要做出相應的調整。

AI驅動的開發文化要求企業在戰略決策層面加入一個新的維度，即考慮如何將建立在大數據之上的模型智能第一時間通過數字應用反饋給用戶。比如，新聞閱讀終端的決策者要考慮如何根據用戶的歷史訪問數據建立模型，以通過模型在第一時間把相關的內容推薦給讀者；視頻內容網站也要考慮同樣的問題，因為準確的內容推薦會讓用戶消費更多的視頻。

加入一個新的維度到決策過程中聽上去很容易，但實施起來卻非常困難。反過來考慮，如果這個事情很容易推進，那么傳統的新聞瀏覽終端早就自動進化到類似于頭條新聞這樣的新一代新聞閱讀終端。傳統新聞閱讀終端和現代應用終端的差別就在于我們所說的新維度：新的新聞終端從創立第一天就把競爭屬性建立在用戶內容推薦模型上。讀者可以想象一下，假設一個提供傳統新聞閱讀服務的公司的董事長將一個知名的數據科學家引入公司擔任首席數據官，讓他幫助公司建立AI驅動的新聞閱讀終端。很可能他進公司的第一天就要對各個業務部門提出各種要求：

?新聞采編部門要對內容進行更加精細的標注。

?應用開發團隊需要注入大量的代碼來獲取用戶閱讀行為習慣數據。

?數據工程團隊要建立大數據基礎設施以收集用戶數據。

?數據科學家團隊要建立模型對內容進行推薦，應用開發團隊要根據推薦呈現內容。

這個過程不是一次性完成的，而是螺旋性迭代的。更為糟糕的時候，在看到產出之前會經歷一段時間的投資，甚至影響原有新聞終端發布內容的速度。用不了多久，原有的采編部門、開發團隊和數據團隊就開始向董事長抱怨，一次兩次董事長可能堅持下來，但如果抱怨次數太多，董事長就可能放棄AI優先的戰略。然后，得出一個錯誤的結論：現在實施AI驅動的戰略為時過早。而事實上，AI驅動的戰略是正確的，只是沒有落地到對應的文化土壤。

在這樣一種AI驅動的文化里面，CDO要從一開始就在公司執行層的圓桌會議中有一席之地，而且其他功能的主管（CIO/CTO）一開始就要習慣照顧到CDO的訴求。從公司戰略層面，如果認為大數據和AI戰略是突破性創新，按照《創新者的窘境》一書中的理論，最好還是成立一家新的機構。CDO成為那家新機構負責人，和現有的高管以業務關系合作，從而保持一定獨立性。如果公司從戰略層面認為大數據和AI還處于連續性創新階段，那么CDO一開始就要避免設置過高的目標。在實施深度學習之前，可以利用高級分析功能找出一些小的改進點，采用持續改進的方法讓其他高管看到效果。按照《Cloud Foundry：從數字化戰略到實現》的方法論，其實軟件應用開發的成功率已經非常高。但是相比軟件應用開發，大數據和AI項目的失敗率要高很多。

2.3.3 大數據基礎設施的建設

前面提到，在大數據和AI驅動的企業數字化戰略中，應用、數據和模型是螺旋式上升的。在企業實施大數據和AI戰略之前，還有一項必要的前期工作，那就是大數據基礎設施建設。通常，企業進入第一階段的數字化轉型以后，已經有了一些云上IT基礎設施，包括一些簡單的應用開發運維（DevOps）環境。這里將討論建立第二階段的大數據基礎設施的必要性和實際選型中的考慮。

1．必要性

在討論大數據基礎設施的建設之前，我們先看看其他的物理基礎設施。2008年，作者從美國回國度假，看到國內正在飛速建設高速公路和高鐵的基礎設施。當時正值美國房產泡沫危機，雷曼兄弟公司倒閉。作者在想：“國內這些設施的建設是以刺激經濟為目標呢？還是以應用（例如電子商務和春運）需求滿足為目標，或者兼而有之？”經過10年的建設，我們看到很多不可能成為可能：游客乘坐高鐵可以在10個小時內從一個城市到達國內的大部分其他城市，電商的物流可以在12小時內完成產品投遞（美國的亞馬遜需要24～48小時）。10年前一個經營生鮮產品的企業無法想象如何在線上進行交易，而今天，生鮮產品也面臨線上的激烈競爭。

在我國基礎設施蓬勃發展的時候，美國的云計算基礎設施也在蓬勃發展。2006年，谷歌提出云計算的概念以后，亞馬遜推出了第一款公有云計算服務AWS，雖然分析界對其并不看好，但是硅谷公司確實看到了一個基礎設施帶來的時代變更。作者當時在甲骨文公司（Oracle）的服務器技術部門從事網格計算的資源調控（Grid Control）工作。2007年，甲骨文公司看到了時代變更，它的網格計算部門也開始大規模部署到云計算，為甲骨文云計算奠定基礎。2010年，阿里云已經在虹橋機場附近樹立起云計算的廣告牌。現在，騰訊云、阿里云和華為云將中國云基礎設施建設推向新高潮。筆者在2008年做企業調研，了解企業對于云計算的接受度時，大家普遍的觀點是不會把自己的軟件運行在外部。到2017年，阿里云的營收額達到了66億人民幣（美國的亞馬遜云更達到了180億美元之巨），公有云已經成為企業的影子IT部門（換言之，如果企業自己的IT部門做得不好的話，業務部門就會采購公有云）。

如果感覺現在談公有云基礎設施和交通基礎設施有些事后諸葛亮的話，那么我們回歸到大數據正題，它是當今世界正在發生的一場如火如荼的數字化基礎設施的建設。在交通基礎設施的建設上，美國的高速公路建設領先于中國，但是中國的高鐵網通過躍背（leapfrog）效應領先美國；在云基礎設施方面，中國的云供應商緊跟美國；而在大數據基礎設施的建設上，中國則和美國齊頭并進。

在前面關于ABC關系的討論中提到過，機器學習和AI模型是一個特定類型的數學模型。這些模型隨著數據量的上升，精度會相應提高。可以預見，未來企業的競爭要么基于模型，要么基于數據，要么兼而有之。一般企業不具備模型的基礎理論研究能力，而且學術機構一旦在模型上有所突破就會很快向所有機構開放。所以，企業要想在機器學習的競爭中獲得優勢，大數據基礎設施更為關鍵。大數據基礎設施建設是企業可以操作且必須操作的。進取型企業為了在未來競爭中獲得優勢，已經開始腳踏實地建設大數據基礎設施，這不僅有利于支持現有的機器學習應用，也為現在尚未知道的未來模型做好準備。就好像從前建設高鐵和高速公路的時候，雖然沒有預見到今天蓬勃發展的物流業，但是卻為今天的物流創新做好了準備。

在作者接觸過的中國500強企業中，大部分企業在大數據的基礎設施中投入了千臺以上的服務器，并且設有專門的數據基礎設施團隊。這些基礎設施上一般運行了Greenplum和Hadoop等多個現代大數據平臺軟件，支持著企業業務團隊的各種請求。同時，大數據基礎設施也遵循獨立原則，以保證數據的完整性和安全性。

2．選型

在今天五花八門的產品和技術當中，商業決策者選擇一個適合自己的技術作為基礎來投資十分重要。作者在為大型公司戰略層提供咨詢的過程中，通常建議它們從以下幾個維度考慮：

?硬件標準開放性

?軟件源代碼開放性

?原創技術團隊穩定性

?云化

（1）硬件標準開放性

雖然技術提供方可以直接提供生產好的硬件，但是企業應該考慮是否可以獲得硬件配置規格，并且這個配置規格需要建立在商品化的硬件組件上面。所謂商品化，就是可以從市場上直接購買，而非定制生產和研發。這個考量可以幫助企業避免被鎖定在特定的硬件上而失去自主可控的創新能力。

（2）軟件源代碼開放性

這是指技術提供方給出的基礎源代碼是否對外開源，而且是否建立在Apache許可等比較好的開源許可上面。通常，技術提供方的興趣主要在于獲得軟件許可收入，所以他們提供的服務數量有限。基于開放源代碼的技術一般有龐大的服務社群，企業能夠獲得更加豐富的第三方支持渠道。另外，開源也能避免企業被鎖定在閉源軟件上，從而喪失自主可控創新能力。

（3）原創技術團隊穩定性

這一點可能是當今最重要的一個考量因素。在開源和開放經濟學的理念下，企業支付的軟件許可費最終是為了獲得原創技術團隊的創新能力，或者說是企業分攤原創技術團隊需要獲得市場定價的成本和合理利潤。但市場上的開源技術有諸多誤區：

第一種誤區是繼承技術供應商放棄開發的開源產品。市場上的很多開源軟件產品是技術供應方不再想維護，從公益的角度將源碼開放出來的。這意味著原創技術團隊不再持續投入。繼承這樣的開源代碼和自己從頭開發的成本幾乎等同乃至更高。

第二種誤區是認為知名企業的團隊創建的開源項目就是好技術。很多互聯網公司本身的利潤來源不是軟件收入，所以為了提高技術團隊的實力，公司會鼓勵技術團隊寫出好的開放性代碼并提供給社區。這樣的產品和代碼很難長時間保持熱度，隨著主業產品方向的改變，代碼的原創團隊很可能被分配到其他項目上而不再對源代碼進行維護和改進。

第三種誤區就是使用社區業余愛好者發起的開源產品。大家都希望看到興趣愛好支撐的創新，這也是一個好的起點。如果社區團隊不能探索出一套穩定的自治模式，最終會失去原創團隊。在一個好的自治模式下，通常會出現一個持續穩定的商業公司來支撐對應的開源產品。舉個例子，Redhat和Linux社群就是一個非常健康的關系。相比之下，OpenStack技術和Hadoop技術在多年之后還沒有形成一個維系原創團隊持續投入的模式。

（4）云化

目前主流的大數據技術都可以直接運行在物理硬件上，而且它們通常也實現了《Cloud Foundry：從數字化戰略到實現》中定義的云計算的基本功能。例如，它們實現了軟硬件分離、橫向水平擴展等。具體來說，像Greenplum這樣的大數據系統中的任何一個物理機器故障，插入新的硬件系統都可以重構這個故障的硬件，同時業務的增長也可以通過加入更多的服務器來滿足。它的缺點是企業要維護兩套系統：大部分數字化應用運行在一套基于I層云和P層云的云計算系統上；大數據系統運行在幾百臺服務器的物理裸機上面。這種配置會導致管理成本上升。現在的主流技術供應商都把大數據系統加入云計算的PaaS層云服務里面，例如AWS的Redshift和Alibaba基于開源Greenplum的HybridDB。截至本書完稿時，這個技術變遷還在進行中。

這里作者想強調的是，不要等待技術供應商把運行在物理機器上的大數據系統向I層云上遷移而成為PaaS云技術的一部分，作為數字化轉型高階階段的管理者要關注把PaaS云的云原生應用遷移到PaaS云的大數據上。也就是說，不是從數字化應用的需要來考慮大數據的建設，而是要考慮大數據的建設能夠為應用提供的可能，從而實現從滿足需求到創造需求的觀念轉變。