一、什么是數(shù)據(jù)自服務

數(shù)據(jù)在企業(yè)中的處理過程，能清晰地映射出康威定律對IT系統(tǒng)的影響。在各個部門分別建設IT系統(tǒng)、組織內(nèi)部大量存在信息筒倉(silo)的年代，數(shù)據(jù)的操作由OLTP應用系統(tǒng)的開發(fā)團隊同步開發(fā)，那時幾乎每個政府信息化、企業(yè)信息化系統(tǒng)都會有一塊“報表需求”。隨后眾多組織認識到筒倉系統(tǒng)導致信息在組織內(nèi)不能拉通，不能產(chǎn)生對整體業(yè)務流程的洞察，于是開始建設以數(shù)據(jù)倉庫為代表的OLAP系統(tǒng)。

[[214388]]

這些系統(tǒng)在支撐更高級、更復雜的數(shù)據(jù)分析的同時，也對應地在組織中造就了一支專業(yè)的“數(shù)據(jù)團隊”。這些人使用非常專業(yè)的技術和工具對數(shù)據(jù)進行提取、轉換、裝載、建立數(shù)據(jù)立方、多維鉆取、生成報表。這些專業(yè)的技術和工具，普通的軟件開發(fā)人員并沒有掌握，因此對數(shù)據(jù)處理、分析和呈現(xiàn)的變更都必須歸集到這個數(shù)據(jù)團隊來完成。結果是，數(shù)據(jù)團隊的backlog里累積了來自各個部門的需求，需求的響應能力下降，IT系統(tǒng)從上線到獲得市場洞察的周期變長。

微服務架構鼓勵小型的、全功能的團隊擁有一個完整的服務(及其對應的業(yè)務)。這樣的全功能團隊不光要開發(fā)和運維IT系統(tǒng)，還要能從數(shù)據(jù)中獲得洞察——而且要快，不然就會跟不上市場變化，甚至使一些重要的業(yè)務場景無法得到支撐。因此他們不能坐等一支集中式的、緩慢的數(shù)據(jù)團隊來響應他們的需求，他們需要數(shù)據(jù)自服務能力。 要賦能數(shù)據(jù)自服務，企業(yè)的數(shù)字化平臺要考慮“兩個披薩團隊”的下列訴求：

• 需要定義數(shù)據(jù)流水線，使數(shù)據(jù)能夠順暢地流過收集、轉換、存儲、探索/預測、可視化等階段，產(chǎn)生業(yè)務價值。
• 需要用實時的架構和API在短時間內(nèi)處理大量、非結構化的數(shù)據(jù)，從中獲得洞見，并實時影響決策。
• 為了提高應變能力，系統(tǒng)中的數(shù)據(jù)不做ETL預處理，而是以“生數(shù)據(jù)”的形式首先存入數(shù)據(jù)湖，等有了具體的問題要回答時，再去組織和篩選數(shù)據(jù)，從中找出答案。
• 更進一步把數(shù)據(jù)包裝成能供外人使用的數(shù)據(jù)產(chǎn)品，讓第三方從數(shù)據(jù)中獲得新的洞見與價值。
• 為了支持數(shù)據(jù)產(chǎn)品的運營，需要實現(xiàn)細粒度授權，針對不同的用戶身份，授權訪問不同范圍的數(shù)據(jù)。

二、數(shù)據(jù)自服務解讀

下面是ThoughtWorks的數(shù)字平臺戰(zhàn)略第三個支柱“數(shù)據(jù)自服務”中所蘊涵的具體內(nèi)容。

1. 數(shù)據(jù)流水線設計

所謂流水線，是指用大數(shù)據(jù)創(chuàng)造價值的整個數(shù)據(jù)流。流水線從數(shù)據(jù)采集開始，隨后是數(shù)據(jù)的清洗或過濾，再然后是將數(shù)據(jù)結構化到存儲倉庫中以便訪問和查詢，這之后就可以通過探索或預測的方式從數(shù)據(jù)中找到業(yè)務問題的答案，并可視化呈現(xiàn)出來。

一條運轉良好的數(shù)據(jù)流水線，能有效處理移動/物聯(lián)網(wǎng)等新技術制造出的極其大量的數(shù)據(jù)，縮短數(shù)據(jù)從獲取到產(chǎn)生洞見的反饋周期，并以開發(fā)者友好的方式完成數(shù)據(jù)各個環(huán)節(jié)的處理，賦能一體化團隊。

數(shù)據(jù)流水線的實現(xiàn)有兩種可能的方式。一種方式是在各個環(huán)節(jié)采用各種特定的工具，例如前面介紹的數(shù)據(jù)流水線，各個環(huán)節(jié)都可以用開源的工具來實現(xiàn)。當然，選擇這種方式也并非沒有挑戰(zhàn)：組織必須自己編寫和維護“膠水代碼”，把各種專用工具組合成一個內(nèi)聚的整體。對組織的技術能力有較高的要求。

除了基于開源軟件實現(xiàn)自己的數(shù)據(jù)流水線，也可以考慮采用云上的數(shù)據(jù)流水線PaaS服務，例如Databricks、AWS Data Pipeline、Azure Data Factory等。這個方式的優(yōu)點是對技術能力要求較低，缺點則是造成對特定云平臺/PaaS提供商的依賴。

2. 實時架構和API

實時的數(shù)據(jù)架構和API支持短時間內(nèi)處理大量、非結構化的數(shù)據(jù)，從中獲得洞見，并“實時”影響決策。正如Mike Barlow所說：“這是關于在正確時間做出更好決定并采取行動的能力，例如在顧客刷卡的時候識別信用卡欺詐，或者當顧客在排隊結賬的時候給個優(yōu)惠，或者當用戶在閱讀某篇文章的時候推送某個廣告。”

在Cloudera的一篇文章中介紹了實時數(shù)據(jù)處理的4個架構模式，整個流水線架構在Flume/Kafka基礎上：

• 數(shù)據(jù)流吸收：低延遲將事件持久化到HDFS、HBase、Solr等存儲機制
• 近實時(100毫秒以下)的事件處理：數(shù)據(jù)到達時立即采取警告、標記、轉換、過濾等初步行動
• 近實時的事件分片處理：與前一個模式類似，但是先對數(shù)據(jù)分片
• 復雜而靈活的聚合或機器學習拓撲，使用Spark

3. 數(shù)據(jù)湖設計

數(shù)據(jù)湖概念最初提出是在2014年Forbes的一篇文章中。它的概念是：不對數(shù)據(jù)做提前的“優(yōu)化”處理，而是直接把生數(shù)據(jù)存儲在容易獲得的、便宜的存儲環(huán)境中;等有了具體的問題要回答時，再去組織和篩選數(shù)據(jù)，從中找出答案。按照ThoughtWorks技術雷達的定義，數(shù)據(jù)湖中的數(shù)據(jù)應該是不可修改(immutable)的。

[[214390]]

數(shù)據(jù)湖試圖解決數(shù)據(jù)倉庫幾方面的問題：

• 預先的ETL處理終歸會損失信息，如果事后才發(fā)現(xiàn)需要生數(shù)據(jù)中的某些信息、但是這些信息又沒有通過ETL進入數(shù)據(jù)倉庫，那么信息就無法尋回了。
• ETL的編寫相當麻煩。數(shù)據(jù)倉庫的schema發(fā)生改變，ETL也要跟著改變;應用程序的schema發(fā)生改變，ETL也要跟著改變。因此數(shù)據(jù)倉庫通常由一個單獨的團隊負責，于是形成一個功能團隊，響應速度慢。
• 數(shù)據(jù)倉庫的分析需要專門的技能，大部分應用程序開發(fā)者不掌握，再度強化了數(shù)據(jù)倉庫專門團隊;而數(shù)據(jù)倉庫團隊其實離業(yè)務很遠，并不能快速準確地響應業(yè)務對數(shù)據(jù)分析的需求。

在數(shù)據(jù)湖概念背后是康威法則的體現(xiàn)：數(shù)據(jù)能力與業(yè)務需求對齊。它要解決的核心問題是專門的數(shù)據(jù)倉庫團隊成為響應力瓶頸。當IT能力與業(yè)務需求組合形成一體化團隊以后，數(shù)據(jù)的產(chǎn)生方不再假設未來要解決什么問題，因此也不對數(shù)據(jù)做預處理，只是直接存儲生數(shù)據(jù);數(shù)據(jù)的使用方以通用編程語言(例如Java或Python)來操作數(shù)據(jù)，從而無需依賴專門的、集中式的數(shù)據(jù)團隊。

數(shù)據(jù)湖實施的***步是把生數(shù)據(jù)存儲在廉價的存儲介質(zhì)(可能是HDFS，也可能是S3，或者FTP等)。對于每份生數(shù)據(jù)，應該有一份元數(shù)據(jù)描述其來源、用途、和哪些數(shù)據(jù)相關等等。元數(shù)據(jù)允許整個組織查看和搜索，讓每個一體化團隊能夠自助式尋找自己需要的數(shù)據(jù)。任何團隊都可以在生數(shù)據(jù)的基礎上開發(fā)自己的微服務，微服務處理之后的數(shù)據(jù)可以作為另一份生數(shù)據(jù)回到數(shù)據(jù)湖。維護數(shù)據(jù)湖的團隊只做很少的基礎設施工作，生數(shù)據(jù)的輸入和使用都由與業(yè)務強關聯(lián)的開發(fā)團隊來進行。傳統(tǒng)數(shù)據(jù)倉庫的多維分析、報表等功能同樣可以作為一個服務接入數(shù)據(jù)湖。

在實施數(shù)據(jù)湖的時候，有一種常見的反模式：企業(yè)有了一個名義上的數(shù)據(jù)湖(例如一個非常大的HDFS)，但是數(shù)據(jù)只進不出，成了“數(shù)據(jù)泥沼”(或數(shù)據(jù)墓地)。在這種情況下，盡管數(shù)據(jù)湖的存儲做得很棒，但是組織并沒有很好地消化這些數(shù)據(jù)(可能是因為數(shù)據(jù)科學家不具備分析生數(shù)據(jù)的技術能力，而是更習慣于傳統(tǒng)的、基于數(shù)據(jù)倉庫的分析方式)，從而不能很好地兌現(xiàn)數(shù)據(jù)湖的價值。

4. 數(shù)據(jù)即產(chǎn)品

數(shù)據(jù)產(chǎn)品是指將企業(yè)已經(jīng)擁有或能夠采集的數(shù)據(jù)資產(chǎn)，轉變成能幫助用戶解決具體問題的產(chǎn)品。Forbes列舉了幾類值得關注的數(shù)據(jù)產(chǎn)品：

• 用于benchmark的數(shù)據(jù)
• 用于推薦系統(tǒng)的數(shù)據(jù)
• 用于預測的數(shù)據(jù)

數(shù)據(jù)產(chǎn)品是數(shù)據(jù)資產(chǎn)變現(xiàn)的快速途徑。因為數(shù)據(jù)產(chǎn)品有幾個優(yōu)勢：開發(fā)快，不需要開發(fā)出完整的模型，只要做好數(shù)據(jù)整理就可以對外提供;顧客面寬，一份數(shù)據(jù)可以產(chǎn)生多種用途;數(shù)據(jù)可以再度加工。數(shù)據(jù)產(chǎn)品給企業(yè)創(chuàng)造的收益既可以是直接的(用戶想要訪問數(shù)據(jù)或分析時收費)也可以是間接的(提升顧客忠誠度、節(jié)省成本、或增加渠道轉化率)。

在實現(xiàn)數(shù)據(jù)產(chǎn)品的時候，不僅要把數(shù)據(jù)打包，更重要的是提供數(shù)據(jù)之間的關聯(lián)。數(shù)據(jù)產(chǎn)品的供應者需要提出洞見、指導用戶做決策，而不僅僅是提供數(shù)據(jù)點。數(shù)據(jù)產(chǎn)品需要考慮用戶的場景和體驗，并在使用過程中不斷演進。

5. 細粒度授權

當數(shù)據(jù)以產(chǎn)品或服務的形式對外提供，企業(yè)可能需要針對不同的用戶身份，授權訪問不同范圍的數(shù)據(jù)，對應不同的服務水平和不同的安全級別。

一些典型的細粒度授權的場景可能包括：

• 企業(yè)內(nèi)部和外部用戶能夠訪問的數(shù)據(jù)范圍不同;
• 供應鏈上不同環(huán)節(jié)的合作伙伴能夠訪問的數(shù)據(jù)范圍不同;
• 付費與免費的用戶能夠訪問的數(shù)據(jù)范圍不同;
• 不同會員級別能夠訪問的數(shù)據(jù)范圍不同等等。

允許訪問的數(shù)據(jù)范圍屬于數(shù)據(jù)產(chǎn)品/服務自身的業(yè)務規(guī)則。《微服務設計》的第9章建議，“[服務]網(wǎng)關可以提供相當有效的粗粒度的身份驗證……不過，比允許(或禁止)的特定資源或端點更細粒度的訪問控制，可以留給微服務本身來處理”。

三、小結

為了加速“構建-度量-學習”的精益創(chuàng)業(yè)循環(huán)，業(yè)務與IT共同組成的一體化團隊不能依賴于集中式的數(shù)據(jù)團隊來獲得對業(yè)務的洞察。他們需要規(guī)劃適宜自己的數(shù)據(jù)流水線，在必要時引入實時數(shù)據(jù)架構和API，用數(shù)據(jù)湖來支撐自服務的數(shù)據(jù)操作，從而更快、更準確地從數(shù)據(jù)中獲得洞察，影響業(yè)務決策。更進一步，數(shù)據(jù)本身也可以作為產(chǎn)品對內(nèi)部用戶乃至外部用戶提供服務，并通過細粒度授權體現(xiàn)服務的差異化和安全性需求。通過建設“數(shù)據(jù)自服務”這個支柱，企業(yè)將真正能夠盤活數(shù)據(jù)資產(chǎn)，使其在創(chuàng)新的數(shù)字化業(yè)務中發(fā)揮更大的價值，這是企業(yè)數(shù)字化旅程的第三步。

【本文是51CTO專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號：思特沃克，轉載請聯(lián)系原作者】

戳這里，看該作者更多好文