【導讀】在當今快速變化的商業環境中，資料的實時性和準確性是企業制勝的關鍵。然而，資料孤島、資料分散、處理時效差等難題卻成為制約企業發展的瓶頸。本文將圍繞實時資料技術在汽車行業的應用與實踐經驗分享展開。
本次分享主要涵蓋三個方面展開。
第一，關於資料技術的起源以及其與傳統IT技術在應用系統構建方面的差異。
第二，應用資料過程中所產生的痛點，以及如何應對這些問題。
第三，總結實際操作中的經驗，包括一些客觀規律，以及在規律下如何提升資料使用效果。
01
汽車行業資料技術實踐
汽車行業具有很長的IT實踐歷史，傳統的IT技術主要用於構建ERP系統、營銷、供應鏈等業務領域，以一汽集團為例，其IT實踐經歷多個經濟週期。
從1953年中國最早的汽車工廠建立至今，一汽集團經歷了70多年的發展。在這段歷史中，穿越了多個經濟週期，因此對於技術的應用可能需要更長的時間跨度來總結。在經濟週期的四個階段，即過熱、滯漲、衰退和復甦中，我們可以清晰地看到傳統業務系統和我們今天要討論的資料類、建設類專案之間的關係。首先是擴張階段，當經濟狀況良好時，企業資金充裕，可以開展ERP和財務等專案，以提高整體運營效率。然而，當效率提升進度過半時，大機率會伴隨出現資料類專案，最典型的例子就是財務或營銷方向的BI。即，ERP建設的成效，體現為建設BI平臺，以滿足領導層的資料分析和報表需求。當經濟開始下滑，銷售額增長放緩，逐漸進入滯脹和衰退期時，企業需要節約成本，此時供應鏈專案應運而生，數倉類專案也會隨之出現。然而，這個階段的驅動力往往是模仿性的，即依靠其他廠商或自身過去的經驗，進一步擴大數倉類、資料分析類、智慧資料類專案的規模。當進入衰退期後半段，就會出現一種避險型的驅動力，即企業意識到經驗無效，且行業存在生死風險，需要透過IT、資料類專案來提高風險識別能力，此時，輿情或駕駛艙類專案成為企業的關注點。
因此，我們可以總結出，在四階段經濟週期或者長經濟週期的視角下，我們的IT投入和伴隨的資料技術類投入，具有很強的週期性和規律性。這種規律實際上就是我們進行資料類專案，如數倉、資料湖、資料整合、報表等的專案週期律。
02
資料技術實踐痛點：建設深入而收益遞減
經濟盛衰驅動的技術投入週期中，我們被動地跟隨市場的步伐，追隨社會經濟的節奏前進時，將會面臨哪些具體的情境呢？
首先，隨著我們在ERP、財務系統、營銷系統以及生產製造工藝系統等方面的不斷擴充套件，以及專案深入進行，工作細緻程度和崗位專業化加劇，我們會發現IT系統的效益呈遞減趨勢，呈現IT投入的業務效果邊際遞減趨勢，因此，透過IT投入來進一步提升業務效能變得非常困難，從而進入了一個IT投入回報的瓶頸期。
然而，在這個瓶頸期中，我們又該如何進一步提升我們的效能呢？此時，資料類專案的重要性便凸顯出來，ERP和營銷等業務系統的目的，是提高業務動作的可控性，在其上增加資料分析系統，會提高業務動作和鏈條的可觀測性，進而發現更多的可控性環節。這種業務系統與資料系統的相伴相生的週期投資模式，能夠對業務和組織帶來持續的收益，對映到技術領域的DT和IT連續投入規律，正是由這個原理所導致的。
抽象成一般的規律，業務標準化、流程化、制度化的過程，目的是提高其可控性，而當可控性到達臨界時，透過提高可觀測性來進一步提升業務和組織的效能。從學術角度來看，這就是控制論中的可控性與可觀測性的對偶關係問題。
03
實踐思路與規律總結
在本次技術和經濟週期中，從2004年大資料技術誕生，2010年國內引入，2015年左右集團內部引入，至今為止，我們取得了哪些成果呢？
首先，我們建立了實時的資料湖。因為資料倉儲是個自古就存在的效率問題，從90年代末開始做數倉，到2014-15年大資料技術、Hadoop技術出現後，我們就需要考慮數倉過渡到資料湖的問題，那麼，它應該採用何種架構呢？經過幾年的實踐和總結，它應該是業務和資料互為驅動力的結構，或者稱之為對立統一。同時，為了解決資料分析的時效性，如物聯網資料、車聯網資料或感測器資料，我們需要面向業務的Hadoop、流處理技術產品。
最終我們要解決的是，表狀態的資料向流態轉化的流程，同時，我們在流態中的資料亦需向表內部進行轉換，而這兩種過程實則構成了一個互逆的狀態，體現為企業中的湖倉二元結構，或者宏觀上稱之為湖倉一體。
它有兩個使命，第一，保證資料的準確性，這是不可或缺的條件，不能像網際網路那樣，有些廣告推薦中的流資料可能存在精度、準確性不足的情況，這在企業ToB領域中是絕對不能接受的；第二，需要保證速度，因為傳統的數倉是t+1的，需要隔日處理，這等於放棄了資料驅動業務的機制。那麼，在既要保證準確性又要保證速度的前提下，如何基於自身客觀條件，在業務資料、數倉、大資料叢集以及Kafka這樣的分散式流匯流排等資源的基礎上，實現及準確又快的資料處理？
經過深入研究，我們發現，實際上有兩種引擎可以滿足我們的需求，第一種被稱為表包流，即我們在表的形式中使用流態引擎進行計算。只有流態引擎才能達到絕對的高速，也就是說，我們將大量的MySQL、Oracle資料讀取出來後，經過實時處理，然後將其送入匯流排或資料庫叢集中，整個過程需要實時完成。這便是從傳統的數倉向我們現有的這種無限算力的大資料叢集的轉變過程，也就是表到流的過程。
TapDataLive Data Platform（TapData實時資料平臺）方案其實是專注於解決該問題的，也就是在形式看起來兩側都是表，但它的處理引擎是流化的，最終其效能、效能、可擴充套件性均可以得到保證。
第二種則是流包表，即在Kafka的結構中，我們是否可以進行某種表型別的操作，如join、union或聚合計算等，這些操作的解決方案是類似Spark、Flink、Paimon的思路。
綜上，表包流和流包表這兩種方案，分別承擔了架構圖中的表向流的轉換器和流向表的轉換器的角色。總體來看，在當前的技術階段，大資料技術與資料庫技術尚未完全融合，或者說其融合的價效比仍較低的階段，我們成功地實現了一種結合，即在企業內部既完成了業務庫這種計算精準的業務庫向大資料的轉換，實現實時處理，同時也解決了在流式資料中獲取大量的IoT資料、車聯網資料，在Kafka中流式資料向資料庫內轉換的過程。
這個完整的資料迴圈模式，是比較適合企業構建實時資料湖的技術邏輯。而TapData其實也是提供了一個強有力的工具，在這個過程中既解決了準的問題，也解決了快的問題。以上，是我們在實際操作過程中設計出來的，具有可行性的實時資料湖的架構。
在構建了資料湖之後，我們發現了一些顯著的收益，這些收益在我們十多年前構建數倉時是無法感受到的。
首先，資料的速度得到了極大的提升，當我們獲得了真正的全域資料，包括集團範圍內的十幾個整車廠以及超過100個子公司，跨越了幾十萬人的規模的實時資料時，會發現所看到的內容與過去完全不同。從資料分佈來看，遠期的歷史資料，例如一年以上的資料，其中蘊含著大量的規律，例如汽車行業的銷量在1-12月中，哪幾個月銷售量較多？哪幾個月銷售量較少？如果想購買汽車，上市後第幾個月的折扣更高？哪個月的折扣更低？從歷史資料中是可以找到答案的。
而近期資料，即上個季度到一年的資料，可以觀察到最近幾個月市場究竟發生了什麼？哪些品牌？哪些價格？哪些區間發生了格局性的變化？例如比亞迪釋出新車後引發了怎樣的市場反應？限購訊息前後會發生什麼波動？如果能夠深入挖掘其中的每一個事件就會發現許多有用的資訊，例如競爭對手的關係、產品之間的變動等等，這些資訊可以用來支援決策，最典型的應用就是用於銷量預測。
最後，我們討論的是最近的資料，即當期的資料，也就是我們當天到近幾個月內每一條的資料，如果都能獲取的話，那麼當業務系統中出現了某一條銷量或者線索的時候，就能夠實時地將其傳遞給需要的部門，下一個業務動作就可以由資料來推動。
最典型的例子就是當一個客戶走進4S店，他需要維修車輛，是否可以讓移動出行服務商，比如專門從事滴滴服務的人，為他提供一張優惠券？就像我們在網際網路上的一些推送一樣，這種動作只有在業務資料充分的實時且順利流動，推資料和拉資料我們都能順利地完成，而且成本並不高的情況下，才能將這種業務動作結合起來。
最終所提煉的效果就是，有能力供應實時保鮮的資料，搭建一個資料鏈路只需要15分鐘，然後就能將六大部門、幾十個場景、數百套系統全部連線起來，而且能應對資料鏈路的變動。
下面介紹我們最新的一些案例，第一個，關於進出口的，我們向國外銷售汽車的時候，跨雲資料同步非常困難，因為資料來自國外，包括歐洲甚至是中東的，我們實現了跨雲的實時資料同步；第二個，資料中心內部的兩個資料庫，或者說是不同部門之間的資料庫，雙向同步就是a到b再回a，而且要實時不能有延遲的，因為要保證業務動作能夠連續進行；第三個，主資料平臺的建設，在我們擁有眾多資料庫，如幾百甚至幾千套系統時，如果要了解其內部結構，用於資料治理任務，或者建設資料資產，那麼，實時捕捉系統結構的變化並傳遞，就有能力完成主資料、後設資料以及參考資料的修正或評估工作等。
總之，資料的不同時效性在業務中的影響完全不同，當我們具備了實時的資料能力，就能夠直接推動業務操作。
接下來是第二個重要效果，就是報表的效率問題。在大型組織中，特別是在央國企、大型財團，或者是一線網際網路企業，都要面臨領導的“管理體驗”難題。領導需要檢視大量報表，如果擁有十幾萬員工、分佈在好幾個城市、幾百個分支機構，面對這麼複雜的組織，生成報表時將面臨極大的困難，甚至出現了本月的報表直到下個月過完了都出不來的情況，即，生成一份月度報表所需的時間可能超過30天。
實踐出的規律是，企業報表時效性與組織複雜度呈現強相關，也就是“企業大則報表慢”。具體表現是，隨著組織規模的擴大，統計的延遲也會相應增加。當我們有了實時倉庫和湖的能力後，企業大則報表慢的問題就可以解決，因為我們已經將整個組織內的資料實時地流動起來，也就是說，透過技術手段把上圖中這條線向左移動，解決了組織規模大但報表速度未減緩的問題。
實際上，我們已經成功實施了財務、質量、營銷、製造、研發以及行政人事這六大典型部門，這些業務部門面臨著大量的報表延遲問題，給領導層彙報的時候，總是沒有辦法提供新鮮的統計結果。在我們掌握了實時倉庫和湖的能力之後，業務方又構建了大量的監控系統，能夠及時觀察到業務組織的動作。
反之，如果沒有高效的資料，業務部門仍然需要等待兩到三週才能生成報表。假設要統計全集團範圍內的某種質量問題，他們需要等待最後一份資料的到達，他們才能完成彙總，這個等待的週期是非常驚人的。因此，組織複雜度與時效性衝突的問題透過我們的實時資料湖方案得以解決，甚至由此催生了一系列監控系統，這無疑是技術驅動業務改善的典型效益。
接下來是實踐中總結出來的規律，首先需要探討的問題是對資料的認知過程是什麼樣子的？根據我們長達10年甚至更久的企業經驗總結，如果想要使用資料，實際上必須經歷一個逐步深入的過程，而且無法跳過裡面的階段，否則就會失敗。具體來說，首先要先開啟資料Excel或CSV看到資料；第二步是搜尋資料，使用Control-F找到需要的關鍵詞；第三步是拼裝資料，用union和join按照特定條件將兩張表合併；第四步是視覺化資料，即能夠直觀地看到資料的形態；最後需要理解資料，即能夠在頭腦中形成資料的含義，並在應用程式中使用它，輸入一個條件，隨之提供一個結果，在業務動作中表達含義或起作用。
在這個過程中的五個階段的一種物化或技術化表達方式，是在資料倉儲層次中使用的 ODS-DW-ADS層次邏輯。從數倉層次的使用頻度上，存在一個分佈不均的現象，最底層的資料，即ODS資料，其使用頻率實際上佔比很高。我曾諮詢過多家專門製作報表的企業級機構，以及一些資深架構師，詢問他們直接從原始資料製作報表，即簡單清理後的報表所佔比例。普遍認為，這個比例應在70%以上。而經過DW中逐層推演、思考、分析師處理和建模後的報表，可能僅佔20%。最後一種拖拉拽生成的內容可能僅佔不到5%，且這個比例是相當穩定的經驗數值。
那麼這ODS-DW-ADS層次使用頻度的分佈情況揭示了什麼呢？實際上，在企業中觀察到的一種現象稱為資料資產積累迴圈或報表積累迴圈，即創造內容的人和資料分析師創造的模型和新的經驗沉澱為固定報表的過程。意味著只要發現了新的資料認知，經過一段時間，大家發現這個報表經常需要檢視，那麼它就會變成標準化的內容，用數倉建模並直接生成，這個迴圈的建立就意味著需要持續進行這五個步驟，即接觸、檢索、拼裝、視覺化和理解。這個迴圈的建立，使得企業內部不斷沉澱內容。那麼它的認知成果是什麼呢？就是DIKWI模型，我們加入了一個名為直覺的元素，因為當理解一個非常熟悉的領域時，可以猜測出一些東西，這就是直覺，即資料、資訊、知識、智慧、直覺的遞進。
此時，會產生一個衍生的問題，這也是這張圖中最令人困惑的部分，即我們在研究了多年的資料湖和數倉之後，實際上誕生了一種名為資料中臺的概念。很多人會有一個問題，資料中臺上了之後，問題是否就能得以解決了呢？或者說，已經部署了諸多資料中臺，為何資料問題依舊未能根除？答案通常是否定的。
剖析資料中臺概念，最大特徵是讓業務人員能夠運算元據，即資料中臺其主要功能在於最佳化視覺化及分析過程，然而，對於大型及具有一定規模的機構而言，其大部分資料消費場景主要集中在佔比70%以上的資料接觸和檢索階段，即已固化的那部分內容。換言之，資料中臺的主要作用恰恰是在資料消費較少的20%環節，這意味著資料中臺的架構是逆著報表積累迴圈的，實踐中的資料中臺專案會出現短期緩解問題，長期惡化問題的現象。這也解釋了為何資料中臺會演變為新版BI，以及為何資料中臺無法支撐實時業務，無法在業務流程中發揮作用。此外，資料中臺也無法壟斷並治理企業的資料消費，原因在於資料中臺的技術特性將其定位在了資料認知的後半程，如果重金投入資料中臺，必然影響資料其他階段的建設，造成資料問題持續性的搞而不定的現象。
那麼，是否存在一些資料技術領域的客觀規律，能夠指導我們前進呢？實際上，確實存在這樣的規律，其中最為基礎的原則，我們稱之為算量守恆定律。
在當前的技術條件下，假設我們以目前市場上可購買的 CPU、記憶體、GPU等裝置為參考，無論我們計算何種固定演算法，無論是排序、複雜檢索，還是某種聚合計算，在不同的計算平臺、不同的程式語言之間，其效能差異不會超過兩個數量級，也就是在100倍以內，即在我們當前的技術條件下，計算一個事物所需的時間是相對穩定的。例如，Python 的計算耗時是C語言的55倍。
由此引申出的一個重要結論是，如果我們想要大規模地縮短計算時間，或者說如果提高它的實時性和時效性，最有效的方法就是預先計算，也就是說，在編寫程式碼時，解決效率問題，最優先考慮的是讀取和生成資料的格式。
那麼，根據算量守恆定律，我們得出了一個規律，既然我們要提高時效性，縮短計算時間，那麼我們就需要進行冗餘，也就是增加它的份數，即預計算的效率就來自於預計算引起的冗餘，那麼，冗餘的膨脹邏輯也就是它膨脹的機制是什麼，這是我們需要研究的核心問題。
概括回顧一下，我們的冗餘膨脹機制已經歷了四代發展。
第一代是統計學驅動的，主要涉及平均值、標準差、峰度偏斜等概念。我們會根據資料的技術特徵進行計數，在使用之前，會預先計算出這些統計和特徵，以便在需要時直接提取。SPSS、Excel、裝置預警用的時序資料庫等工具都能夠快速地完成這項工作。
第二個階段是管理學驅動的，即我們能否迅速地計算出在業務認知中出現的一些指標，如利潤率、週轉率、產批零售量以及計劃完成率等，這些都是我們可以預先計算的。典型場景是財務分析領域對企業三表的分析。
第三階段是業務模型驅動，其中最具代表性的是Cube，也就是數倉的核心部分，透過拉齊各個領域，利用維度來實現整合。此時，我們實現了全組織的業務視野，包括同比、環比、市佔率變化等，這些都是我們在業務模型中，在Cube中可以預先計算出來的。
第四階段是機率論驅動的神經網路引數，也就是現在的AI技術，它是基於機率論驅動的高維度資料微分計算結果。我們首先將資料中的邏輯機率固定在神經網路中，即訓練過程，然後由神經網路推算出我們所需的機率，也就是推理的過程，即推算出最大機率的那個點是什麼。
四代的膨脹方式，在技術上並不是完全的繼承關係，更多的是應用領域不斷擴大的過程，更是對資料更廣泛適配的過程。其中蘊含著對夏農資訊理論的反向應用的趨勢，值得更深層次的探索。
此外，對資料本體第一性原理，是否有什麼新的認知呢？實際上，在《流系統設計》這本書中就提到了流表相對論的問題。
當我們深入剖析這個問題時，我們發現了流的流表二象形問題，並不僅僅是元件的批流相對論問題，而是資料本身存在一個兩象性問題。
第一，表的本質上是格式化的一條一條的訊息，即資料的表化就是一個對齊的過程；第二，流實際上是這個表的內容變化的集合，也就是表的變化的記錄。所以，資料的分析大機率是由表來承擔的，而對其進行詳細記錄或變更痕跡則需要流的參與。
那麼，無論任何一條資料或大量資料，無論是單個表單還是一系列子表，都可以將其轉化為表格形式，或者構建為資料資訊流，則資料天生就具備兩象性，只是要考慮的是，不同情況下，什麼地方應用資料流的特性，什麼地方應用表的特性。在什麼情況下對資料的流和表的形態進行轉換，並且是在什麼樣子的時間、空間約束條件下進行的轉換，約束條件下需要什麼樣子的算力模式、併發規模、檢查條件等技術方案。
總結以上的分享，根本的出發點是對於資料的流表二象性的探索，在算量守恆定律的技術約束下，面向不同的資料冗餘機制，誕生了各種資料結構和計算機理，在企業和組織的資料認知過程中，解決報表效率和資料價值問題，體現為實時資料湖的物理形態，作用在企業和組織行為的可管理和可觀測能力上，最終在經濟週期的不同階段交替起作用。
關於 TapData
TapData Inc.「深圳鈦鉑資料有限公司」，成立於2019年9月，核心員工來自 MongoDB、Oracle、百度等，研發人員佔比超80%，至今已獲五源資本等多家頭部風投數千萬美元融資。已服務中國移動、中國聯通、南方電網、中國一汽、中芯國際、周生生、富邦銀行等數十家行業標杆企業。TapData 堅持“開放+開源”戰略，推出 TapData Cloud，將無程式碼資料實時同步的能力以 SaaS 的形式免費開放，目前已積累 1,000+ 雲版和企業版客戶，覆蓋金融、製造、零售、能源、政府等多個行業。此外，TapData 社群版也已釋出，正在面向開發者逐步共享其核心功能。
TapData Live Data Platform是一個以低延遲資料移動為核心優勢構建的現代資料平臺。企業可以用來實現核心資料系統之間的實時同步、實時交換及實時處理。當實時資料需求日益增多時，企業可以結合分散式儲存，使用 TapData 將孤島資料無縫集中到中央資料平臺，為眾多下游業務提供一站式的實時資料交換和釋出服務。
產品優勢：
- 開箱即用與低程式碼視覺化操作
- 內建 100+ 資料聯結器，穩定的實時採集和傳輸能力
- 秒級響應的資料實時計算能力
- 穩定易用的資料實時服務能力
【推薦閱讀】
- 如何高效整合分散資料，構建統一的實時資料平臺？
- 流式處理 vs 批處理，新資料時代的資料處理技術該如何選擇？
- TapData 醫療美容行業數字化白皮書上線
- 戰略資訊 | TapData 牽手思想科技，開啟資料管理新篇章！