一、大規(guī)模數(shù)據(jù)報(bào)表生產(chǎn)的挑戰(zhàn)與訴求

首先和大家分享百度商業(yè)數(shù)據(jù)產(chǎn)品及其對(duì)數(shù)據(jù)平臺(tái)的訴求。

1、百度商業(yè)數(shù)據(jù)產(chǎn)品矩陣介紹

以上百度商業(yè)矩陣主要體現(xiàn)其核心商業(yè)產(chǎn)品和數(shù)據(jù)形式：

• 百度核心商業(yè)數(shù)據(jù)產(chǎn)品，主要包括用于網(wǎng)站埋點(diǎn)統(tǒng)計(jì)和全流程托管分析的百度統(tǒng)計(jì)，反映詞匯趨勢(shì)熱度及分析洞察的百度指數(shù)，支撐廣告主追蹤熱點(diǎn)并完成投放決策的觀星盤，以及其他面向產(chǎn)品、銷售、運(yùn)營(yíng)等人員的數(shù)據(jù)產(chǎn)品；
• 成體系化的數(shù)據(jù)流轉(zhuǎn)，一是 B 端廣告主投放廣告的物料數(shù)據(jù)和投放行為日志，二是 C 端用戶訪問(wèn)、搜索及消費(fèi)相關(guān)的行為日志。兩端數(shù)據(jù)經(jīng)過(guò)用商一體的加工分析流轉(zhuǎn)到各個(gè)數(shù)據(jù)產(chǎn)品后以豐富多樣的形式呈現(xiàn)。

2、百度商業(yè)數(shù)據(jù)產(chǎn)品背后的大數(shù)據(jù)體系演進(jìn)歷史

從 08 年到現(xiàn)在的 15 年時(shí)間內(nèi)，百度商業(yè)數(shù)據(jù)產(chǎn)品背后的大數(shù)據(jù)體系已經(jīng)經(jīng)過(guò)了四個(gè)階段的演進(jìn)。第一個(gè)階段為單一業(yè)務(wù)時(shí)代，主要基于 MR 和 Linux 的定時(shí)任務(wù)，支撐小規(guī)模的產(chǎn)品孵化，技術(shù)相對(duì)老舊。第二個(gè)階段進(jìn)入多元業(yè)務(wù)時(shí)代，面向不同角色的產(chǎn)品矩陣逐漸出現(xiàn)，逐漸開(kāi)始封裝研發(fā)框架、調(diào)度系統(tǒng)等，進(jìn)入小規(guī)模的 DevOps 迭代。第三階段開(kāi)始平臺(tái)化試水，為解決數(shù)據(jù)一致性和產(chǎn)品割裂問(wèn)題，嘗試數(shù)據(jù)產(chǎn)品一盤棋，將數(shù)據(jù)任務(wù)開(kāi)發(fā)運(yùn)維全面托管并建立標(biāo)準(zhǔn)化的 DataOps。第四階段在確定 DataOps 體系有效后，將百度商業(yè)數(shù)據(jù)產(chǎn)品全面托管，幫助業(yè)務(wù)實(shí)現(xiàn)架構(gòu)現(xiàn)代化。

3、大規(guī)模報(bào)表生產(chǎn)背后的數(shù)據(jù)挑戰(zhàn)

經(jīng)過(guò)分析總結(jié)，百度商業(yè)數(shù)據(jù)產(chǎn)品在集團(tuán)內(nèi)部主要面臨以下三類挑戰(zhàn)：

• 海量數(shù)據(jù)：百度具有數(shù)萬(wàn)份的數(shù)據(jù)集、數(shù)十萬(wàn)條數(shù)據(jù)血緣關(guān)系、每天數(shù)萬(wàn)次例行計(jì)算，海量數(shù)據(jù)形成復(fù)雜的拓?fù)渚W(wǎng)絡(luò)在管理上帶來(lái)挑戰(zhàn)，一體化的數(shù)據(jù)平臺(tái)統(tǒng)一納管便于數(shù)據(jù)及血緣的查找和追蹤。
• 數(shù)百名數(shù)據(jù)開(kāi)發(fā)工程師：開(kāi)發(fā)豐富的數(shù)據(jù)產(chǎn)品需要大量的高成本數(shù)據(jù)開(kāi)發(fā)工程師，企業(yè)會(huì)產(chǎn)生高昂的用人成本，便捷高效的輔助開(kāi)發(fā)產(chǎn)品或平臺(tái)能為生產(chǎn)提效，節(jié)省人力成本達(dá)到降本增效的目的。
• 數(shù)萬(wàn)個(gè)核心報(bào)表指標(biāo)和數(shù)十個(gè)商業(yè)產(chǎn)品出口：大量的指標(biāo)和出口產(chǎn)品一旦發(fā)生故障都需要能快速解決修復(fù)，清晰的血緣管理能高效輔助問(wèn)題定位和排查分析，提高數(shù)據(jù)及產(chǎn)品的交付質(zhì)量和用戶滿意度。

4、大規(guī)模報(bào)表生產(chǎn)對(duì)數(shù)據(jù)平臺(tái)的訴求

面對(duì)數(shù)據(jù)挑戰(zhàn)，百度數(shù)據(jù)平臺(tái)通過(guò)建設(shè)大規(guī)模穩(wěn)定可靠的流水線數(shù)據(jù)報(bào)表生產(chǎn)鏈路，解決相關(guān)訴求，其核心建設(shè)思路和目標(biāo)主要包括以下兩點(diǎn)：

• 提升研發(fā)效率：通過(guò)統(tǒng)一流程、統(tǒng)一技術(shù)棧、統(tǒng)一研發(fā)套件形成生產(chǎn)級(jí)的流程規(guī)范，解決各個(gè)產(chǎn)品線數(shù)據(jù)源的基礎(chǔ)設(shè)施割裂帶來(lái)的效率問(wèn)題和規(guī)范問(wèn)題；
• 優(yōu)化產(chǎn)出穩(wěn)定性：通過(guò)建設(shè)監(jiān)控能力、運(yùn)維能力、治理能力等一系列開(kāi)箱即用的套件，解決面對(duì)大規(guī)模數(shù)據(jù)和任務(wù)手工無(wú)法解決的延遲多、恢復(fù)慢、優(yōu)化難等穩(wěn)定性隱患。

下面，重點(diǎn)分享全流程 DataOps 的設(shè)計(jì)思考。

二、全流程 DataOps 的設(shè)計(jì)思考

1、面向大規(guī)模數(shù)據(jù)報(bào)表生產(chǎn)的分層架構(gòu)

一般來(lái)說(shuō)，在做數(shù)據(jù)產(chǎn)品交付時(shí)，我們會(huì)采用分層設(shè)計(jì)的方式，百度的數(shù)據(jù)分層架構(gòu)主要分為：原始數(shù)據(jù)層、數(shù)倉(cāng)層、指標(biāo)層、報(bào)表層，各層之間通過(guò)統(tǒng)一制品的技術(shù)中間件銜接。如果將數(shù)據(jù)生產(chǎn)類比為一般的工業(yè)生產(chǎn)，那么分層架構(gòu)可以看作統(tǒng)一操作規(guī)范的生產(chǎn)流水線，統(tǒng)一制品的技術(shù)中間件可以看作統(tǒng)一標(biāo)準(zhǔn)規(guī)格的生產(chǎn)工具，兩者結(jié)合保證了數(shù)據(jù)報(bào)表生產(chǎn)的質(zhì)量和效率。

2、如何選型

面向統(tǒng)一的分層架構(gòu)，如何選型以實(shí)現(xiàn)流水線的生產(chǎn)和高效運(yùn)維呢？不同于傳統(tǒng)的完全割裂的開(kāi)發(fā)運(yùn)維方案，DevOps 通過(guò)任務(wù)調(diào)度平臺(tái)和一些數(shù)據(jù)功能的拼湊實(shí)現(xiàn)統(tǒng)一業(yè)務(wù)框架，DataOPs 則以數(shù)據(jù)為視角，重塑全流程，實(shí)現(xiàn)數(shù)據(jù)生產(chǎn)流水線，因此DataOps理念更符合我們對(duì)統(tǒng)一平臺(tái)的設(shè)想和預(yù)期。

3、面向大規(guī)模數(shù)據(jù)報(bào)表生產(chǎn)的DataOps平臺(tái)設(shè)計(jì)思考

DataOps 以數(shù)據(jù)為視角，不僅要實(shí)現(xiàn)數(shù)據(jù)研發(fā)流程托管，還需要考慮數(shù)據(jù)治理、任務(wù)監(jiān)控與運(yùn)維，保證數(shù)據(jù)生產(chǎn)的全流程在一個(gè)平臺(tái)內(nèi)完成，平臺(tái)也貫穿數(shù)據(jù)和報(bào)表的全生命周期。

4、面向大規(guī)模數(shù)據(jù)報(bào)表生產(chǎn)的 DataOps 流水

百度將流水線生產(chǎn)與開(kāi)箱即用能力的 DataOps 理念落地到 DataBoot 平臺(tái)，實(shí)現(xiàn)了數(shù)據(jù)端到端開(kāi)箱即用的監(jiān)控運(yùn)維與治理能力，覆蓋從數(shù)據(jù)的引入到使用過(guò)程數(shù)據(jù)接入層、加工層、網(wǎng)關(guān)層所有的處理套件與能力，見(jiàn)證了從原始數(shù)據(jù)到報(bào)表制品的轉(zhuǎn)化。

5、商業(yè)數(shù)據(jù)產(chǎn)品 DataOps 平臺(tái)- DataBoot 整體介紹

DataBoot 統(tǒng)一平臺(tái)基建基于百度的 IaaS 和 PaaS 平臺(tái)，構(gòu)建相關(guān)的流程工具套件如集成、建模、開(kāi)發(fā)、運(yùn)維、監(jiān)控等，結(jié)合計(jì)算框架、統(tǒng)一網(wǎng)關(guān)、血緣采集探針等中間件，并基于數(shù)據(jù)血緣建設(shè)包括全鏈路運(yùn)維、全鏈路可觀測(cè)性、全局監(jiān)控分析等進(jìn)階治理能力。

三、全流程 DataOps 平臺(tái)化實(shí)踐

1、開(kāi)發(fā)環(huán)節(jié)-大數(shù)據(jù)任務(wù)開(kāi)發(fā)一站式 WebIDE 套件

在開(kāi)發(fā)環(huán)節(jié)，我們基于 Monaco 搭建輕量級(jí)數(shù)據(jù)開(kāi)發(fā) WebIDE，通過(guò)代碼和配置并結(jié)合 jar 包支撐數(shù)據(jù)開(kāi)發(fā)。在此基礎(chǔ)上，打通百度 Icode 代碼管理平臺(tái)保證代碼不丟不漏實(shí)現(xiàn)代碼提交，打通各種計(jì)算集群使用戶無(wú)需自己搭建環(huán)境在 Web 實(shí)現(xiàn)作業(yè)調(diào)試，最后通過(guò)調(diào)度平臺(tái)實(shí)現(xiàn)作業(yè)上線。

整個(gè)數(shù)據(jù)任務(wù)開(kāi)發(fā) WebIDE 套件將數(shù)據(jù)集成加工的各種資源和插件打包形成SaaS服務(wù)，其中插件即數(shù)據(jù)集成與加工場(chǎng)景的各種能力，如集成插件、開(kāi)發(fā)框架插件等。

2、部署環(huán)節(jié)

• 彈性可擴(kuò)展 Serverless 部署架構(gòu)。

任務(wù)部署的目標(biāo)是屏蔽與數(shù)據(jù)處理無(wú)關(guān)的流程與設(shè)施，使部署過(guò)程對(duì)用戶無(wú)感，百度Serverless 部署架構(gòu)從上到下分為控制層、服務(wù)層、計(jì)算層三層?？刂茖硬捎梦⒎?wù)應(yīng)用部署數(shù)據(jù)集成加工能力的各種插件，通過(guò) Driver 模塊與服務(wù)層進(jìn)行交互。服務(wù)層為異步和長(zhǎng)作業(yè)的模式，通過(guò)函數(shù)托管平臺(tái)部署，例如質(zhì)量檢查，數(shù)據(jù)計(jì)算等所有服務(wù)均通過(guò)函數(shù)封裝，基于 workflow 實(shí)現(xiàn)函數(shù)編排，支持 corn 調(diào)度和手動(dòng)觸發(fā)執(zhí)行。最后計(jì)算層通過(guò)獨(dú)立集群分池部署實(shí)現(xiàn)不同場(chǎng)景不同策略的優(yōu)化和彈性擴(kuò)縮容資源機(jī)制。

• 服務(wù)層 Serverless 部署設(shè)計(jì)。

服務(wù)層采用 FaaS 部署，主要是基于邏輯擴(kuò)展性和極致資源彈性的考慮。其中邏輯擴(kuò)展性主要體現(xiàn)在可以基于函數(shù)粒度完成邏輯拆分與組合編排，復(fù)用通用插件和控制流插件。而極致資源彈性主要是數(shù)據(jù)報(bào)表生產(chǎn)的潮汐特點(diǎn)和突發(fā)流量資源風(fēng)險(xiǎn)需要依賴彈性擴(kuò)縮容機(jī)制以快速完成資源準(zhǔn)備和故障恢復(fù)。

• 計(jì)算層 Serverless 部署設(shè)計(jì)。

計(jì)算層支持資源池化和多租戶。部署圖中的 PoolManager 負(fù)責(zé)資源擴(kuò)縮容和回收，類似 JVM GC 的功能。SessionPool 可以自動(dòng)擴(kuò)縮容，并且可配置化的實(shí)現(xiàn)不同的資源分配規(guī)則以達(dá)到任務(wù)的分級(jí)保障目的。底層的每個(gè) K8s Pod 是一個(gè)計(jì)算實(shí)例，每個(gè) Pod 有多個(gè)container，主 container 負(fù)責(zé)和 Spark 集群進(jìn)行交互產(chǎn)生計(jì)算。

• 數(shù)據(jù)血緣探針織入式部署。

DataOps 全流程數(shù)據(jù)治理需要依賴于高置信的數(shù)據(jù)血緣，而傳統(tǒng)數(shù)據(jù)血緣采集方案一是侵入強(qiáng)難以落地；二是粒度難以到達(dá)字段級(jí)和算子級(jí)，僅能到表級(jí)血緣，無(wú)法滿足精確控制場(chǎng)景；三是準(zhǔn)度差，復(fù)雜場(chǎng)景無(wú)法識(shí)別；四是時(shí)效弱，T+1 的血緣無(wú)法滿足實(shí)時(shí)管控的生產(chǎn)要求。

因此百度設(shè)計(jì)織入式部署模式，無(wú)需業(yè)務(wù)修改代碼即可完成實(shí)時(shí)血緣采集。首先，通過(guò) Spark 擴(kuò)展探針和 Java Agent 探針在用戶提交命令時(shí)攔截實(shí)現(xiàn)無(wú)侵入探針織入，其次通過(guò)探針解析語(yǔ)法樹(shù)和實(shí)時(shí)通信的方式回寫到服務(wù)端的存儲(chǔ)模塊，最后在存儲(chǔ)模塊通過(guò)匹配策略識(shí)別高置信血緣。

3、發(fā)布環(huán)節(jié)-數(shù)據(jù)進(jìn)退場(chǎng)風(fēng)險(xiǎn)管控

通常在數(shù)據(jù)發(fā)布到生產(chǎn)環(huán)境的過(guò)程中主要存在兩種類型的問(wèn)題造成嚴(yán)重生產(chǎn)事故。一是發(fā)布的代碼邏輯存在問(wèn)題造成發(fā)布節(jié)點(diǎn)及下游所有任務(wù)執(zhí)行異常，引發(fā)全鏈路任務(wù)雪崩。二是發(fā)布的代碼性能下降造成發(fā)布節(jié)點(diǎn)及下游節(jié)點(diǎn)數(shù)據(jù)產(chǎn)出延遲的連鎖效應(yīng)引發(fā)全鏈路時(shí)效性退化。

針對(duì)上述風(fēng)險(xiǎn)，如何實(shí)現(xiàn)數(shù)據(jù)進(jìn)退場(chǎng)的安全可靠呢？目前主要通過(guò)規(guī)避單點(diǎn)風(fēng)險(xiǎn)和識(shí)別數(shù)據(jù)鏈路風(fēng)險(xiǎn)的方式保證。單點(diǎn)風(fēng)險(xiǎn)致力于解決單個(gè)任務(wù)的異常問(wèn)題，主要通過(guò)標(biāo)準(zhǔn)化的 CI/CD Pipeline 實(shí)現(xiàn)冒煙測(cè)試和基于歷史數(shù)據(jù)的 Mock 測(cè)試發(fā)現(xiàn)是否存在數(shù)據(jù)問(wèn)題。鏈路風(fēng)險(xiǎn)主要基于數(shù)據(jù)血緣、冒煙測(cè)試結(jié)果、設(shè)定的 SLA 期望值和周期性任務(wù)運(yùn)行統(tǒng)計(jì)數(shù)據(jù)以及推測(cè)算法判斷是否存在時(shí)效退化等情況，輔助用戶決策是否上線相關(guān)任務(wù)。

除了單個(gè)任務(wù)的發(fā)布以外，平臺(tái)的框架和網(wǎng)關(guān)的升級(jí)也存在風(fēng)險(xiǎn)，因此將平臺(tái)所有中間件依賴包以組件形式封裝，并且通過(guò)先選舉重要程度相對(duì)低的任務(wù)灰度發(fā)布，如果驗(yàn)證無(wú)誤后再將線上任務(wù)全部更新到組件的最新版本。最后結(jié)合平臺(tái)化的管理功能如組件管理、版本管理等實(shí)現(xiàn)一定程度的風(fēng)險(xiǎn)規(guī)避。

提供端到端一體化的監(jiān)控分析能力，不僅僅針對(duì)一個(gè)任務(wù)或一個(gè)數(shù)據(jù)集，而是基于血緣拓?fù)涞幕A(chǔ)能力監(jiān)控報(bào)表全鏈路并度量，例如計(jì)算每份數(shù)據(jù)的就緒時(shí)間和資源的分位值，根據(jù)資源的到位時(shí)間和內(nèi)存及 CPU 等資源的開(kāi)銷，能夠?qū)?shù)據(jù)延遲進(jìn)行歸因和分析。

數(shù)據(jù)任務(wù)一旦發(fā)布用戶無(wú)需自研監(jiān)控設(shè)施即可開(kāi)箱即用的達(dá)成數(shù)據(jù)報(bào)表的全鏈路可觀測(cè)。線上化的監(jiān)控能實(shí)現(xiàn)平臺(tái)級(jí)、產(chǎn)品線級(jí)、報(bào)表級(jí)、任務(wù)級(jí)、子階段等通過(guò)多層級(jí)覆蓋，輔助快速識(shí)別風(fēng)險(xiǎn)的等級(jí)快速定位問(wèn)題。另外，監(jiān)控分析一體化能夠自動(dòng)化計(jì)算出分階段耗時(shí)，自動(dòng)故障自動(dòng)歸因等在提高故障定位效率的同時(shí)節(jié)約了大規(guī)模的人力投入，通過(guò) timeline 工具套件實(shí)現(xiàn)數(shù)據(jù)報(bào)表的全鏈路分析，示例如下：

4、運(yùn)維環(huán)節(jié)-全鏈路數(shù)據(jù)回溯能力

然而，如果源頭數(shù)據(jù)存在臟數(shù)據(jù)污染下游所有指標(biāo)或報(bào)表，報(bào)表數(shù)據(jù)異常需要回溯，在沒(méi)有 DataOps 時(shí)，所有的數(shù)據(jù)回溯都需要工程師手動(dòng)完成，其運(yùn)維復(fù)雜度和風(fēng)險(xiǎn)都非常高，如誤操作、資源負(fù)載突增搶占、手動(dòng)恢復(fù)緩慢。目前平臺(tái)提供系統(tǒng)云控功能，用戶完成簡(jiǎn)單觸發(fā)即可自動(dòng)完成全流程的數(shù)據(jù)回溯，做到精確追蹤、有序運(yùn)行、及時(shí)恢復(fù)。

百度云控系統(tǒng)在租戶級(jí)別實(shí)現(xiàn)自動(dòng)化全鏈路數(shù)據(jù)回溯，跨租戶時(shí)需要規(guī)避安全和權(quán)限風(fēng)險(xiǎn)，主要通過(guò)事件通知由具有相應(yīng)權(quán)限的管理或運(yùn)維人員手動(dòng)觸發(fā)完成回溯。數(shù)據(jù)回溯的血緣觸發(fā)通過(guò) Execute Engine 實(shí)現(xiàn)時(shí)序控制、基于計(jì)算資源的并發(fā)控制、容錯(cuò)機(jī)制和監(jiān)控報(bào)警等功能自動(dòng)生成回溯的執(zhí)行計(jì)劃并將計(jì)算任務(wù)的有序分發(fā)到計(jì)算引擎。詳細(xì)實(shí)現(xiàn)如下：

5、優(yōu)化環(huán)節(jié)

最后，分享一些關(guān)于大數(shù)據(jù)計(jì)算在優(yōu)化過(guò)程中遇到的問(wèn)題和解決方案。

• 問(wèn)題分析與技術(shù)思考。

傳統(tǒng)大數(shù)據(jù)調(diào)優(yōu)方法的局限主要在三個(gè)方面，一是性能和成本的平衡，在實(shí)際業(yè)務(wù)場(chǎng)景下，任務(wù)的重要程度和優(yōu)先級(jí)是有區(qū)別的，要考慮如何在滿足性能和產(chǎn)出穩(wěn)定性要求的情況下，平衡資源成本，提高投入產(chǎn)出比；二是調(diào)優(yōu)效率，Spark 作業(yè)在性能調(diào)優(yōu)時(shí)復(fù)雜程度很高，長(zhǎng)作業(yè)多輪調(diào)參消耗掉大量的時(shí)間和人力成本；三是缺乏全局視角，研發(fā)工程師往往僅能基于一個(gè)任務(wù)或一份數(shù)據(jù)進(jìn)行調(diào)優(yōu)，單點(diǎn)調(diào)優(yōu)做得再完美或許也無(wú)法解全局的難題。

面臨如上問(wèn)題時(shí)，百度商業(yè)數(shù)據(jù)平臺(tái)在系統(tǒng)設(shè)計(jì)目標(biāo)層面達(dá)成統(tǒng)一，首先通過(guò)聲明式設(shè)計(jì)，以終為始，錨定數(shù)據(jù)報(bào)表的預(yù)期產(chǎn)出時(shí)間為時(shí)效性目標(biāo)進(jìn)行優(yōu)化，減少了用戶的心智負(fù)擔(dān)。其次，完成目標(biāo)生成、單點(diǎn)自動(dòng)化調(diào)優(yōu)和效果試驗(yàn)比對(duì)實(shí)現(xiàn)流程閉環(huán)。

• 全局?jǐn)?shù)據(jù)報(bào)表時(shí)效性優(yōu)化實(shí)驗(yàn)。

百度時(shí)效性優(yōu)化系統(tǒng)負(fù)責(zé)將該系統(tǒng)設(shè)計(jì)目標(biāo)和優(yōu)化思路落地。主要通過(guò)設(shè)新建優(yōu)化目標(biāo)并基于全局優(yōu)化策略生成待優(yōu)化項(xiàng)，然后匹配系統(tǒng)效果數(shù)據(jù)生成試驗(yàn)評(píng)估效果，并自動(dòng)完成優(yōu)化前后的各類指標(biāo)的可視化對(duì)比分析。

• 單點(diǎn)聲明式動(dòng)態(tài)調(diào)優(yōu)。

除了全鏈路調(diào)優(yōu)，百度在基于單點(diǎn)的聲明式動(dòng)態(tài)調(diào)優(yōu)也具備實(shí)踐。主要通過(guò)探針采集作業(yè)的日常開(kāi)銷和實(shí)效性等指標(biāo)并回傳到 Receiver 模塊存儲(chǔ)，然后通過(guò) Validator 判斷調(diào)優(yōu)效果是否符合預(yù)期，如果符合預(yù)期則退出，不符合則再通過(guò) Calculator 生成策略并由Processor 實(shí)現(xiàn) Spark 的動(dòng)態(tài)調(diào)參，如此反復(fù)經(jīng)過(guò)多輪調(diào)整后達(dá)到調(diào)優(yōu)效果。

四、總結(jié)與展望

當(dāng)前企業(yè)內(nèi)部逐漸重視數(shù)據(jù)價(jià)值，大家發(fā)現(xiàn)基于數(shù)據(jù)的視角 DataOps 的理念能符合大家的預(yù)期，但是隨著大模型的普及，AIOps 勢(shì)必能夠與 DataOps 良好結(jié)合，目前百度內(nèi)部也在積極的探索和實(shí)踐，期待由機(jī)器自動(dòng)化識(shí)別和調(diào)用已有套件進(jìn)一步實(shí)現(xiàn)大數(shù)據(jù)工程師生產(chǎn)力的飛躍。