主頁 > 軟體設計 > 回首資料平臺建設心路,探索資料架構新方向

回首資料平臺建設心路,探索資料架構新方向

2020-12-17 11:26:02 軟體設計

回首資料平臺建設心路,探索資料架構新方向

  • 一、引言
  • 二、對平臺的簡單認識
    • (一)關于資料集成
    • (二)更好的離線計算
    • (三)離線&實時&AI
  • 三、平臺發展新機遇
  • 四、平臺建設挑戰
    • (一)資料開發全鏈路
    • (二)資料“超市”建設
    • (三)換種角度看產品
    • (四)建設資料聯邦
  • 五、平臺未來展望

一、引言

本人錢包里有幾百塊一直沒有花出去的現金,在錢包中睡了大概有幾個月,不是我這幾個月沒花錢,而是因為這幾個月身邊結婚的少了,禮金——現金于我的最大使用場景,尤其今年新冠肺炎疫情的發生,培養了人們諸多新型消費習慣,無接觸購物、直播帶貨、社區團購等新渠道、新服務不斷涌現,隨著寬帶基礎設施的完善、5G時代的到來,在線娛樂、在線教育、在線醫療、短視頻直播等接受度越來越高,但現金支付的場景越來越少,幾乎日常生活中全部的支付場景已經線上化,數字化的時代已經悄然來臨,作為一個大資料從業者,我主要從事著資料平臺開發的作業,大資料平臺該如何建設和發展的問題經常會讓我陷入沉思,這里從個人角度出發,分享我對資料平臺與資料架構的淺薄觀點,

二、對平臺的簡單認識

(一)關于資料集成

資料集成指的是將多種、多樣的資料進行匯聚的一種行為,大資料中我們常用ETL來進行更加詳細的表達這種行為,ETL是每個大資料平臺不可或缺的一部分,宗旨一般都是為企業提供穩定、可靠、安全的資料傳輸服務,多年前以DataX為代表的離線資料同步工具已經具備了多源異構資料同步能力,而近年來離線存盤體系并沒有發生大面積的更迭,所以如果一個ETL產品的定位是離線資料同步,那經過這幾年的沉淀和發展其產品應該已經足夠成熟,

但是技術的推陳出新總是讓人措手不及,當前階段新的業務需求和下游技術的發展都對更具時效性的ETL提出了訴求,比如需要目標端對接更多管道類大資料組件(如:Kafka、Pulsar等)以及源頭端需要適配更多接資料庫及組件(如:Canal、Databus、Maxwell、Debezium等),而下一階段將資料“入湖上云”更是一個觸手可及的市場,可以肯定的是各大云廠商會帶著自己的遷移工具到企業中去,而一個橫向的、跨云的資料同步服務工具也會有市場空間的,綜上來講,一個離線資料同步產品如果想快速回應新的訴求并抓住下一階段的市場機會,一次系統架構調整相比較于在現有產品上添磚加瓦應該是更具有意義的,或者說一個全新的技術體系產品也可能是更好的選擇,

在這里插入圖片描述

(二)更好的離線計算

根據專家估計,隨著近年來資料規模呈幾何級數高速增長,到2030年需要處理的資料量會大大超過處理能力的上限,從而導致大量資料因無法或來不及處理,而處于未被利用、價值不明的狀態,這些資料被稱為“暗資料”,由此引起的整個網路、存盤、計算、傳輸、結構等方面的變革我們暫且不展開,本文我們將討論內容限定為企業內部,那么從谷歌發布大資料的三篇文論至今,大資料的存盤和計算的技術已經很成熟,現有的計算框架足以應對當前的計算需求,但,也只是應對,企業級計算能力的前提下,如何更好的將金融、證券、保險等行業的跑批耗時大幅度的壓縮,我認為可以從以下三方面入手:

  • 打造存算分離的架構
    通過將資料的存盤和計算分離,存算分離能夠有效避免服務器的浪費、降低服務器更新頻率、提高可擴展性、提高資源利用率,才能做到動態的向計算密集型作業分配更多的算力(算力的潮汐),最終成為降低企業IT成本的直接、有效手段,

  • 優化存盤
    在資料方面通過對現有資料進行去重、拉鏈、生命周期管理、冷熱資料分離、清理外圍資料等方面的優化,降低存盤清理,提高資料價值密度,在存盤架構方面通過對資料塊大小調整、小檔案管理、元資料管理等一些方法,有效降低NameNode請求壓力,從而大幅的提高NameNode在線率,

  • 磁盤故障感知
    在這里插入圖片描述
    根據上面“硬碟驅動器故障浴盆曲線”(左圖)及“前四年硬碟驅動器故障率”(右圖)可以看出,硬碟故障是影響跑批時效性的一個定時炸彈,不管近年來的磁盤質量有多大提升,也只不過是延長了故障爆發的時間而已,所以在這樣的情況下,做到磁盤故障感知尤其的重要,我認為磁盤故障處理與感知有下面三個階段:

    • 現階段:發現故障->隔離壞盤->磁盤換新->資料平衡
    • 下一階段:預測->重點觀察->隔離壞盤->磁盤換新->資料平衡,本階段的難點作業在于“預測”,我認為可以根據磁盤的生產時間、上架時間、良品率、同型被更換數量、近期R/W速度波動……等等指標進行建模,實作磁盤的故障預測,并根據實際結果對模型調優,
    • 最終階段:通過存算分離的架構,將計算任務上收而非當前的下放,接下來將資料上云,進一步釋放本地存盤壓力,解放資料運維作業,專注云上計算,

(三)離線&實時&AI

有一句話是:“實時計算不會取代離線計算”,談“替換”需要太大的勇氣,更何況在一些傳統資料架構企業或業績導向企業,實時計算更多的是在扮演一些體驗優化、離線計算功能補充的角色,當前的應用深度和企業資料架構并不利于使實時計算成為一個業務驅動引擎,而在諸如滴滴、順豐等互聯網與物流企業中,他們對實時計算有天然的需求,便捷的實時資料獲取,使得實時計算平臺可以實作大量的低延時業務的需求;阿里巴巴內部已經基于實時計算引擎(Flink)改造出了一個通用演算法平臺(Alink),可以看到的是在不久的未來,離線、實時、AI一定是朝著融合的方向發展,這里我們可以先看一下目前實時計算的架構圖,如下:

在這里插入圖片描述
相對低成本的實時資料獲取是實時計算發展的基礎,得益于Flink技術的繁榮發展,未來的實時計算將會成為一座橋梁,一邊連接傳統的離線計算一邊探索與AI的融合,簡單羅列如下:

  • 基于Hive元資料且特定場景下的流批一體;
  • 實時計算支持特征工程、在線學習、在線預測等 AI 場景;
  • 擺脫中間件以來,不斷完善的CDC能力;
  • Flink中更強大的復雜事件處理(CEP)服務;

在這里插入圖片描述

三、平臺發展新機遇

如今塞班、黑莓紛紛退出歷史舞臺,三星手機的銷量也今非昔比,這么多年技術領域不變的是一直在變化,而在變的只是變化周期和速度,2C或靠平臺運營來實作公司主要收入的商業模式更容易收到技術革新的沖擊或帶動,在數字化轉型的大趨勢下,以推動企業現有架構變革或希望通過新技術、新思路來豐富業務增長點的探索顯得迫切而有必要,所以在渠道拓展方面對新技術的嗅探、新產品的范訓、新的對外合作模式的創新等,都是一些具體的方式;在技術方面進行探索,最大化的通過技術的變革來創新業務模式、升華服務質量,比如:

  • 推進HTAP的研究和探索,更快捷的支撐實時決策場景;
  • 擁抱云計算,推進海量資料的敏感欄位加密技術,實作將密態資料或非敏感資料上云,降低企業內部存盤、運維成本,實作更快的基于云的彈性計算;
  • 通過邊緣計算,集合內部大資料平臺和云上資源,對IoT、客戶、設備等資料進行計算和模型預測;
  • 豐富平臺產品矩陣,隨著5G、云計算、邊緣計算的到來,首先對現有系統進行云原生改造;其次積極探索新技術可能拉動的產品真空,豐富產品矩陣;
  • 加快聯邦技術落地,通過資料聯邦與聯邦學習,降低資料存盤和使用成本,擴大模型訓練集,提高訓練效果;
  • 推進流批一體落地,借助Hive的統一元資料與Flink的流批一體技術,在資料湖的基礎上加快流批一體技術的落地,推動全面實時化;

四、平臺建設挑戰

建設并非因為要建設而建設,建設是為了更好的解決需求、完成目標,而平臺的不斷演進可以更好的服務現有需求并開創新的可能,

(一)資料開發全鏈路

對大資料平臺而言,資料的抽取、存盤、加工、管理、開放運營等是大資料的核心能力,資料開發平臺等系統的投產極大程度降低了資料的加工、使用門檻,滿足了基本的資料研發需要,但是在元資料管理、資料研發規范性、資料質量把關、安全審計等治理方面仍然存在較大的改進空間,通過更接下來的平臺建設進一步提升易用性、提升資料穩定性、提高資料質量和資料安全、增強資料調度能力,進而在資料融合加工基礎上進一步的完善資料治理體系,從而實作更好的資料開放共享,以便更快捷的支撐應用系統的建設和成長顯得尤為重要,

在這里插入圖片描述

(二)資料“超市”建設

資料能說話、資料助決策,大企業中對資料的訴求和使用好比家庭購物買菜,菜市場和超市都可以買菜,但是菜市場具有占地面積大、對周圍交通及環境影響大的特點,而超市則顯得比較靈活和便捷,能夠更好的適應城區,目前很多業務場景下對資料的使用好像在菜市場買菜,需要接觸每個攤位主(資料負責人/提數人員/……),分別溝通來買菜(提數)并逐個結算,而超市則提供了磁區、分類、分級的產品供應,并實作了自由選擇、統一結算的服務,并且超市往往對顧客隔離了材料加工、包裝(資料加工)的程序,更好的購物環境、更優質的服務、更快捷的體驗,所以建設好我們的資料超市不但是對我們資料的梳理和分類,實作資料運營也將會把我們的資料服務能力提升到一個新的臺階,給資料使用人員一種更好的使用體驗,

(三)換種角度看產品

  • 打造云產品
    軟體運行的環境從主機到虛擬機再到發展到容器,企業降本的訴求一直反壓著技術進行著不斷的變革,云的出現不僅改變了傳統IT行業的構架,更是加速了傳統行業的轉型和升級,節約了傳統企業的IT投入,更是為Paas、SaaS提供了極大的便利,積極擁抱云原生技術,深入推進企業上云,加速企業數字化改造,

  • 用產品的眼光看產品
    傳統的以小組為單位的產品布局提供了很明確的產品責任人和發展模式,其產品的發展方向和速度往往由上層和內部因素共同決定,而面對飛速發展的技術變革、跨產品發展需求等,此模式比較容易形成“畫地為牢”的局限性,反而不容易做到快速搶占新產品市場、實作跨界產品需求,所以如果我們反問自己,什么是對這個產品最好的?哪個方向的迭代對產品更好?本產品是否要集成其他小組已有產品的功能?本產品是否具有市場競爭力以及前瞻性?
    互聯網下的產品往往是“跨界”的,此類產品往往不會過于聚焦于單一的某個功能,但往往是以某個核心功能為中心的上下游功能共同組成了本產品的功能矩陣,實作產品即決方案,提升產品的市場競爭力,降低產品在企業落地難度,

(四)建設資料聯邦

“眾人拾柴火焰高”,以一個企業內部的資料積累來進行用戶行為屬性判斷、標簽加工等事情還是略顯薄弱,如果能夠實作通過獲取外部資料、三方行為資料的使用,通過全天候、多維度的行為分析來最終判定一個主體的屬性和標簽,將會有利于更好的對主體把控,通過資料上云,實作行業云內資料的共享,實作本地資料與云上資料的聯邦,外部產品矩陣、外部資料聯邦等等,目的就是對內部提供更加優質的服務,實作更多、更好的產品范訓、更精確的客戶定位、賦能業務、最終實作更好的實作數字化轉型,

五、平臺未來展望

中原銀行經過4年的大資料平臺建設,已經從原始的人海戰術實作了大資料系統的平臺化,這很大程度上要歸功于我們在大資料平臺建設的輕裝上陣和極有魄力的領導力,回顧過去展望未來,大資料平臺的演進之路大致如下:
在這里插入圖片描述
在2020年末2021伊始的時間節點,結合業界發展趨勢,我認為下一代的大資料平臺發展將會形成人工智能和大資料的雙引擎局面,對人工智能而言則是需要探索與大資料的融合,于大資料而言,除了與人工智能的融合外也要快速實作新一代的資料存盤、計算、使用等方面的變革,基于這個想法大資料平臺建設架構大致如下:

在這里插入圖片描述
最后,希望大資料平臺每年都有更好的呈現,每一次陣痛的變革都是為了堅守最原始的初心,

作者:思甜,資料銀行部

轉載請註明出處,本文鏈接:https://www.uj5u.com/ruanti/236054.html

標籤:其他

上一篇:初級前端工程師如何快速成長和尋求突破

下一篇:react路由嵌套路由及路由傳參

標籤雲
其他(157675) Python(38076) JavaScript(25376) Java(17977) C(15215) 區塊鏈(8255) C#(7972) AI(7469) 爪哇(7425) MySQL(7132) html(6777) 基礎類(6313) sql(6102) 熊猫(6058) PHP(5869) 数组(5741) R(5409) Linux(5327) 反应(5209) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4554) 数据框(4311) css(4259) 节点.js(4032) C語言(3288) json(3245) 列表(3129) 扑(3119) C++語言(3117) 安卓(2998) 打字稿(2995) VBA(2789) Java相關(2746) 疑難問題(2699) 细绳(2522) 單片機工控(2479) iOS(2429) ASP.NET(2402) MongoDB(2323) 麻木的(2285) 正则表达式(2254) 字典(2211) 循环(2198) 迅速(2185) 擅长(2169) 镖(2155) 功能(1967) .NET技术(1958) Web開發(1951) python-3.x(1918) HtmlCss(1915) 弹簧靴(1913) C++(1909) xml(1889) PostgreSQL(1872) .NETCore(1853) 谷歌表格(1846) Unity3D(1843) for循环(1842)

熱門瀏覽
  • 面試突擊第一季,第二季,第三季

    第一季必考 https://www.bilibili.com/video/BV1FE411y79Y?from=search&seid=15921726601957489746 第二季分布式 https://www.bilibili.com/video/BV13f4y127ee/?spm_id_fro ......

    uj5u.com 2020-09-10 05:35:24 more
  • 第三單元作業總結

    1.前言 這應該是本學期最后一次寫作業總結了吧。總體來說,對作業的節奏也差不多掌握了,作業做起來的效率也更高了。雖然和之前的作業一樣,作業中都要用到新的知識,但是相比之前,更加懂得了如何利用工具以及資料。雖然之間卡過殼,但總體而言,這幾次作業還算完成的比較好。 2.作業程序總結 相比前兩個單元,此單 ......

    uj5u.com 2020-09-10 05:35:41 more
  • 北航OO(2020)第四單元博客作業暨課程總結博客

    北航OO(2020)第四單元博客作業暨課程總結博客 本單元作業的架構設計 在本單元中,由于UML圖具有比較清晰的樹形結構,因此我對其中需要進行查詢操作的元素進行了包裝,在樹的父節點中存盤所有孩子的參考。考慮到性能問題,我采用了快取機制,一次查詢后盡可能快取已經遍歷過的資訊,以減少遍歷次數。 本單元我 ......

    uj5u.com 2020-09-10 05:35:48 more
  • BUAA_OO_第四單元

    一、UML決議器設計 ? 先看下題目:第四單元實作一個基于JDK 8帶有效性檢查的UML(Unified Modeling Language)類圖,順序圖,狀態圖分析器 MyUmlInteraction,實際上我們要建立一個有向圖模型,UML中的物件(元素)可能與同級元素連接,也可與低級元素相連形成 ......

    uj5u.com 2020-09-10 05:35:54 more
  • 6.1邏輯運算子

    邏輯運算子 1. && 短路與 運算式1 && 運算式2 01.運算式1為true并且運算式2也為true 整體回傳為true 02.運算式1為false,將不會執行運算式2 整體回傳為false 03.只要有一個運算式為false 整體回傳為false 2. || 短路或 運算式1 || 運算式2 ......

    uj5u.com 2020-09-10 05:35:56 more
  • BUAAOO 第四單元 & 課程總結

    1. 第四單元:StarUml檔案決議 本單元采用了圖模型決議UML。 UML檔案可以抽象為圖、子圖、邊的邏輯結構。 在實作中,圖的節點包括類、介面、屬性,子圖包括狀態圖、順序圖等。 采用了三次遍歷UML元素的方法建圖,第一遍遍歷建點,第二、三次遍歷設定屬性、連邊,實作圖物件的初始化。這里借鑒了一些 ......

    uj5u.com 2020-09-10 05:36:06 more
  • 談談我對C# 多型的理解

    面向物件三要素:封裝、繼承、多型。 封裝和繼承,這兩個比較好理解,但要理解多型的話,可就稍微有點難度了。今天,我們就來講講多型的理解。 我們應該經常會看到面試題目:請談談對多型的理解。 其實呢,多型非常簡單,就一句話:呼叫同一種方法產生了不同的結果。 具體實作方式有三種。 一、多載 多載很簡單。 p ......

    uj5u.com 2020-09-10 05:36:09 more
  • Python 資料驅動工具:DDT

    背景 python 的unittest 沒有自帶資料驅動功能。 所以如果使用unittest,同時又想使用資料驅動,那么就可以使用DDT來完成。 DDT是 “Data-Driven Tests”的縮寫。 資料:http://ddt.readthedocs.io/en/latest/ 使用方法 dd. ......

    uj5u.com 2020-09-10 05:36:13 more
  • Python里面的xlrd模塊詳解

    那我就一下面積個問題對xlrd模塊進行學習一下: 1.什么是xlrd模塊? 2.為什么使用xlrd模塊? 3.怎樣使用xlrd模塊? 1.什么是xlrd模塊? ?python操作excel主要用到xlrd和xlwt這兩個庫,即xlrd是讀excel,xlwt是寫excel的庫。 今天就先來說一下xl ......

    uj5u.com 2020-09-10 05:36:28 more
  • 當我們創建HashMap時,底層到底做了什么?

    jdk1.7中的底層實作程序(底層基于陣列+鏈表) 在我們new HashMap()時,底層創建了默認長度為16的一維陣列Entry[ ] table。當我們呼叫map.put(key1,value1)方法向HashMap里添加資料的時候: 首先,呼叫key1所在類的hashCode()計算key1 ......

    uj5u.com 2020-09-10 05:36:38 more
最新发布
  • 【中介者設計模式詳解】C/Java/JS/Go/Python/TS不同語言實作

    * 中介者模式是一種行為型設計模式,它可以用來減少類之間的直接依賴關系,
    * 將物件之間的通信封裝到一個中介者物件中,從而使得各個物件之間的關系更加松散。
    * 在中介者模式中,物件之間不再直接相互互動,而是通過中介者來中轉訊息。 ......

    uj5u.com 2023-04-20 08:20:47 more
  • 露天煤礦現場調研和交流案例分享

    他們集團的資訊化公司及研究院在一個礦區正在做智能礦山的統一平臺的 試點,專案投資大概1億,包括了礦山的各方面的內容,顯示得我們這次交流有點多余。他們2年前開始做智能礦山的規劃,有很多煤礦行業專家的加持,他們的描述是非常完美,但是去年底應該上線的平臺,現在還沒有看到影子。他們確實有很多場景需求,但是被... ......

    uj5u.com 2023-04-20 08:20:25 more
  • 《社區人員管理》實戰案例設計&個人案例分享

    設計是一個讓人夢想成真程序,開始編碼、測驗、除錯之前進行需求分析和架構設計,才能保證關鍵方面都做正確 ......

    uj5u.com 2023-04-20 08:20:17 more
  • 軟體架構生態化-多角色交付的探索實踐

    作為一個技術架構師,不僅僅要緊跟行業技術趨勢,還要結合研發團隊現狀及痛點,探索新的交付方案。在日常中,你是否遇到如下問題 “ 業務需求排期長研發是瓶頸;非研發角色感受不到研發技改提效的變化;引入ISV 團隊又擔心質量和安全,培訓周期長“等等,基于此我們探索了一種新的技術體系及交付方案來解決如上問題。 ......

    uj5u.com 2023-04-20 08:20:10 more
  • 【中介者設計模式詳解】C/Java/JS/Go/Python/TS不同語言實作

    * 中介者模式是一種行為型設計模式,它可以用來減少類之間的直接依賴關系,
    * 將物件之間的通信封裝到一個中介者物件中,從而使得各個物件之間的關系更加松散。
    * 在中介者模式中,物件之間不再直接相互互動,而是通過中介者來中轉訊息。 ......

    uj5u.com 2023-04-20 08:19:44 more
  • 露天煤礦現場調研和交流案例分享

    他們集團的資訊化公司及研究院在一個礦區正在做智能礦山的統一平臺的 試點,專案投資大概1億,包括了礦山的各方面的內容,顯示得我們這次交流有點多余。他們2年前開始做智能礦山的規劃,有很多煤礦行業專家的加持,他們的描述是非常完美,但是去年底應該上線的平臺,現在還沒有看到影子。他們確實有很多場景需求,但是被... ......

    uj5u.com 2023-04-20 08:19:07 more
  • 《社區人員管理》實戰案例設計&個人案例分享

    設計是一個讓人夢想成真程序,開始編碼、測驗、除錯之前進行需求分析和架構設計,才能保證關鍵方面都做正確 ......

    uj5u.com 2023-04-20 08:18:57 more
  • 軟體架構生態化-多角色交付的探索實踐

    作為一個技術架構師,不僅僅要緊跟行業技術趨勢,還要結合研發團隊現狀及痛點,探索新的交付方案。在日常中,你是否遇到如下問題 “ 業務需求排期長研發是瓶頸;非研發角色感受不到研發技改提效的變化;引入ISV 團隊又擔心質量和安全,培訓周期長“等等,基于此我們探索了一種新的技術體系及交付方案來解決如上問題。 ......

    uj5u.com 2023-04-20 08:18:49 more
  • 05單件模式

    #經典的單件模式 public class Singleton { private static Singleton uniqueInstance; //一個靜態變數持有Singleton類的唯一實體。 // 其他有用的實體變數寫在這里 //構造器宣告為私有,只有Singleton可以實體化這個類! ......

    uj5u.com 2023-04-19 08:42:51 more
  • 【架構與設計】常見微服務分層架構的區別和落地實踐

    軟體工程的方方面面都遵循一個最基本的道理:沒有銀彈,架構分層模型更是如此,每一種都有各自優缺點,所以請根據不同的業務場景,并遵循簡單、可演進這兩個重要的架構原則選擇合適的架構分層模型即可。 ......

    uj5u.com 2023-04-19 08:42:41 more