摘要：如何將各種大數據技術棧整合在一起，發揮出大數據技術的最大價值成爲業界都在關注的問題。
最近，隨着健康碼的流行，大數據又重回大衆的視野。作爲新基建產業的原油，數據逐步邁向信息產業的核心。不過隨着數據量級的不斷擴大，從數據倉庫到數據湖再到倉湖一體，如何將各種大數據技術棧整合在一起，發揮出大數據技術的最大價值成爲業界都在關注的問題。
越來越大的數據，想說愛你不容易
權威的諮詢機構IDC對於大數據的定義是現有技術難以處理的數據。從歷史來看，在谷歌提出大數據三駕馬車的論文時，當時的關係型數據庫技術的確難以處理大規模的數據。傳統SQL在谷歌海量的查詢記錄面前，根本跑不出結果。
當前，科技企業要處理的數據量還在迅速增長，以筆者所在的銀行爲例，創新性的產品令銀行要存儲越來越多的數據，以開放銀行和數字貨幣最爲典型。比如開放銀行產品推出之前，無論是櫃檯、ATM、網上銀行還是手機銀行，銀行的交易都是由自身完全可控的設備或APP發起的，而開放銀行產品無處不在、無時不在，要求銀行必須要記錄客戶的行爲數據，這也就使銀行要處理更多更龐大的數據。同樣的情況也出現在數字貨幣上，我國的央行數字貨幣(DCEP)一個最重要的屬性就是離線錢包，這也就意味着DCEP必然要記錄之前不會體現在銀行賬面上的現金交易信息，這也會將金融交易的數據量級再上臺階。
在諸多行業業務上雲如火如荼的大背景下，從工業互聯網及IoT的角度看，數據的量級不斷創新高，從我瞭解到的情況，各大廠的數據量級正在以年化80%左右的速度增長，因此可以說大數據技依舊術方興未艾，未來還有廣闊的發展空間。
從數據庫到數倉，再到數據湖
在梳理數據存儲模型演進的歷史後，明顯可以發現，這是一個隨着數據量級不斷擴大，數據模型不斷將傳統特性退化掉的過程，在這個演化當中存儲的效率不斷提升。
從最早關係型數據庫的視角看，數據庫是工廠的車間，數據是原材料。車間爲了進行原材料加工，有大量的操作設備，原材料隨時會被重塑修改，不適合進行大量材料的儲存場所。
關係型數據庫在大量數據存儲方面的短板直接催生了Hadoop等大數據技術的革命，從大數據的視角看，大數據自身就是儲存倉庫，而數據已經是加工完成的成品，沒有被重塑修改回滾的需求。比如HDFS的實現中所有數據只能寫入一次，無法修改，這其實是退化掉數據的特性，以換取海量數據的儲存與查詢性能。
而隨着大數據應用的進一步拓展，業界發現價值密度更低的非結構化數據也有儲存及挖掘的必要。比如客服的對話可能是語音、文字甚至是圖像、視頻，這都不是傳統意義上數據庫、數倉可以處理的結構化數據，因此用於儲存非結構化的數據湖出現了，在數據湖中數據標準化、結構化的特性也退化了。
三座大山，大數據所不能承受之重
第一座大山是處理時效：在瞭解數據存儲模型的演進過程後，我們可以看出關係型數據庫、數據倉庫與數據湖的底層構建模型並不相同，彼此兼容性不佳。這首先就會催生出數據處理的時效性問題，對於處理時效的要求可能是大數據工程師與產品經理之間永遠無法達到的協議。
以筆者所在的銀行爲例，分析數據在交易核心數據庫中跑批處理，再ODS抽取ETL分析到數倉，再進一步訓練流式計算，最後再入湖，其時效最快也是T+1日，而且Hadoop和數據湖的開源生態中很多組件並不兼容，日常運維已捉襟見肘，想提速也無從下手，但業務對了轉瞬即逝的營銷機會又如此渴求，T+1分鐘可能都會嫌慢。
如果還回答不出更細節、隱含的問題，比如非線性問題，還要把數據複製到SAS中做機器學習，再做統計的指標體系，去做進一步挖掘。數據要在這裏搬動三次，複製三份冗餘，還要管理數據一致性，每天數據中心運維的大量工作在做數據搬家。
第二座大山是數據治理: 現在，數據中心也開始要做一個融合性的計算框架。比如，現在AI要做online訓練，淘寶推薦引擎，滴滴打車的路徑動態規劃都在做即時數據，這都需要很高的數據治理水平進行支撐。
數據治理作爲擺在大數據工程師面前的一大痛點，去年初微盟發生了舉世矚目的刪庫事件，可以看到從2月23日刪庫中斷事件，到3月1日的數據全面找回，再到3月3日的數據恢復整個事件持續了一週多的時間。
對微盟這樣體量的電商來說，損失無疑是巨大的，股市市值的蒸發是一方面，更重要的是科技公司從本質上是經營數據的公司，而數據丟失事件與銀行金庫被盜事件從某種程度來說是同樣性質的事件，都會對當事公司的聲譽造成極大的影響。造成這個問題的本質還是由於數據治理水平，只有將數據按照重要性把數據分類，並分別制訂治理策略，才能在真正有用的數據丟失時找到最切實可行的應對辦法，眉毛鬍子一把抓難以真正降本提效。
按照筆者的觀察，目前從治理角度，可以將數據分爲以下三種類型：
- 應用數據：也就是交易類應用所產生的數據。爲了滿足業務需要構建業務IT系統，隨着IT業務系統的不斷運行，大量應用數據就產生了，這些數據經過ETL加工進入數據倉庫，進行再處理，供業務應用。這些數據都是單一的關係型數據，數據量級是GB的。
- 用戶行爲數據：隨着互聯網和電商的快速發展，大量人的操作行爲和使用行爲產生的數據，像谷歌、臉書等大數據互聯公司，都記錄人的形成產生的數據。上網行爲、瀏覽行爲、購買行爲、評論行爲、刷微博，做抖音等都可以產生大量數據。這些數據不再是單一的結構化數據，出現了大量文檔、音頻和視頻數據，數據量級是TB級的。
- 硬件日誌數據：進入萬物互聯的時代，大量機器傳感器，IoT設備都會產生大量數據。這些設備 7*24小時產生數據，數據格式也是多種多樣，有的是日誌數據，有的是時序數據，有的是網格數據等等，數據量級是PB的。
從數據治理角度上講，上述數據的備份需求是不同的，如果混到一起，那快速恢復業務根本無從談起。而從數據使用的角度上講，隨着海量的行爲及日誌類數據的出現，數據的價值必然要從數據治理的角度去要價值。
針對行爲及日誌等重要性等級不高的數據，一般採用異地磁帶備份的方式，使用溫備乃至冷備的試進行，不過從目前情況看不少企業尤其是創業型企業，都沒有百年老店的觀念，在初創時期對於這方面考慮和規劃還不夠，規劃沒做好，將來必然會對企業發展有負面影響。
這又就引出第三座大山 - 災備規劃：但也經常被公司管理人員所忽略，大多數初創公司不會提前規劃災備體系，公司上規模之後再進行災備建設又是mission impossible。一般來說兩地三中心中的生產與同城中心是雙活的可以快速接管業務，異地中心數據延遲同步，以應對一些刪庫刪表類的誤操作。正如剛剛所說Hadoop與數據湖兩套體系中的開源組件兼容性很差，能讓兩者協同工作已屬不易，再補充建設災備節點難上加難。
一般來說目前比較流行的災備體系是兩地三中心的架構，也就是至少在兩個地域建設三個數據中心，其中:
-
-
- 主中心：正常情況下全面提供業務服務
- 同城中心：一般與主中心處在同一省份，主中心使用同步複製的方式來向同城災備中心傳輸數據，保證同城中心數據複本爲最新，隨時可以接管業務，以保證RTO的指標。但是同城中心無法應對此類刪庫事件。
- 異地中心：一般使用延時異步複製（延時時間一般爲30分鐘左右）的方式向異地災備中心傳輸數據，其中同步複製的好處是一旦主中心被人工破壞，那麼不會立刻涉及異地中心。以保證RPO的指標。
-
總結災備體系的最佳實踐就是兩地三中心；同城保證業務連續性，優先負責用戶體驗;異地保證數據連續性，確保企業生存底線。上雲後的災備規劃也一定要納入設計範圍，一旦沒有提前的規劃，後續的補齊填坑的工作非常麻煩。
雲原生打開大數據未來的正確方式
從上面三座大山可以看出，大數據最終用戶的最佳選擇就是在雲平臺上找到大數據的一棧式解決方案，屏蔽底層組件的差別，才能提高效率，低成本運維，因此可以說與雲計算無縫對接的雲原生技術肯定會是未來的方向。
而華爲云云原生大數據以其容器化集成及全棧大數據雲平臺的兩大特性，很好解決了大數據技術在實際落地中的特點，我們用“大數據的操作系統”來定義華爲雲的雲原生大數據會更加直觀貼切：
容器化集成：基於Mesos的資源管理，支持Marathon和Kubernetes的容器編排框架，採用雲原生架構的數據平臺。底層是對容器化的支持，以及對Hadoop、Spark、Kafka、Tensorflow、Hive等這些大數據開源組件的容器化發佈，這就是打地基。
華爲雲通過開源的Docker、K8S、Mesos等技術，對主流的Hadoop、Hive、Spark、Kafka等多種大數據技術組件進行了容器化集成，實現大數據應用與底層運行環境之間的解耦，推出了應用雲平臺（PaaS）與容器大數據平臺。也就是說華爲雲的用戶不用再過度關心底層開源組件的運維了，可以更加專注於自身的業務。
全棧大數據雲：在大數據開源組件容器化的基礎上，華爲雲還把數據開發平臺統一集成，推出了數據湖治理中心DGC（Data Lake Govenance Center， 鏈接：https://www.huaweicloud.com/product/dayu.html ），包括數據採集、數據規範、數據開發、數據服務、數據治理、數據可視化等多項工具。數據集成開發平臺與應用雲平臺（PaaS）與容器大數據平臺打包交付。 並已經服務了能源、教育、醫療健康、物聯網、金融等領域的數十家客戶，據筆者掌握的信息，華爲雲的客戶復購率近100%。
更進一步，華爲雲最近還推出了一套幫助政企構建數據體系的數據使能DAYU服務 （鏈接：https://www.huaweicloud.com/solution/dataenabling.html） ，結合華爲數字化轉型實踐和30多年在ICT基礎設施領域積累的技術，攜手行業合作伙伴，爲客戶提供一站式數據全生命週期管理解決方案，打造“全域、服務化、資產化、智能、安全”的數據體系，釋放數據價值。
展望未來，雲原生大數據技術還可以充分利用AI技術降本增效：
- 利用人工智能將冷熱數據分層分離，讓計算和存儲資源充分利用，有效降低數據管理成本。
- 通過分析系統運行狀態和日誌數據信息，利用人工智能建模，來實現動態系統參數調整和系統優化，顯著降低系統數據管理者的運維成本。
- 利用機器學習技術幫助系統建立更加準確高效的在線預警與實時監測系統，來實現智能化的運維管控和資源調配，幫助系統管理人員將更多的時間和精力集中在更重要的系統任務上。