文·blogchong
接上一篇《從0到1構(gòu)建數(shù)據(jù)生態(tài)系列之二：拓荒》，這篇我們來(lái)好好拆解一下我們的藍(lán)圖。
1 寫(xiě)在之前
之前有朋友在后臺(tái)留言說(shuō)，從第二篇中(即上一篇：拓荒)，可以看出文章略顯匆忙，并沒(méi)有把拓荒的一些過(guò)程細(xì)節(jié)給描繪出來(lái)。
這里檢討一下，我坦白、我認(rèn)罪。
當(dāng)時(shí)那個(gè)話(huà)題一寫(xiě)開(kāi)來(lái)的時(shí)候，突然就發(fā)現(xiàn)這是一個(gè)巨大的話(huà)題，隨便發(fā)散下去又一大篇了，所以我還是在這一張穿插著把上一張的部分內(nèi)容補(bǔ)充完整。
當(dāng)然，至今為止，我已經(jīng)把未來(lái)三章的內(nèi)容規(guī)劃出來(lái)了，這樣更容易把控這個(gè)系列的質(zhì)量。
所以，請(qǐng)期待，請(qǐng)不要放棄治療。
回歸話(huà)題，這一部分我將結(jié)合架構(gòu)圖中的東西，講述我們是如何拆解完整的數(shù)據(jù)規(guī)劃到執(zhí)行的過(guò)程，并且期間一些思考方式也會(huì)一起分享出來(lái)(感覺(jué)這更是重點(diǎn))。
2 ?結(jié)合業(yè)務(wù)需求拆解架構(gòu)圖
這里，我們把之前一章已經(jīng)上過(guò)的架構(gòu)圖再貼一次：
先簡(jiǎn)單的從整體上說(shuō)一下這個(gè)架構(gòu)圖。
從架構(gòu)圖中，我們可以看出來(lái)，我們整個(gè)數(shù)據(jù)架構(gòu)中，需要做的事情很多。
隨著數(shù)據(jù)的流向，從下到上，主要分三層：
(1) 第一層是數(shù)據(jù)收集層，負(fù)責(zé)基礎(chǔ)數(shù)據(jù)的收集工作；
(2) 第二層是數(shù)據(jù)存儲(chǔ)以及處理層，負(fù)責(zé)數(shù)據(jù)存儲(chǔ)，以及對(duì)數(shù)據(jù)進(jìn)行深度處理，數(shù)據(jù)的轉(zhuǎn)換，價(jià)值的挖掘等；
(3) 最上層是應(yīng)用層，基于下面的數(shù)據(jù)處理，進(jìn)行價(jià)值轉(zhuǎn)換；當(dāng)然還有貫穿整個(gè)過(guò)程的監(jiān)控以及任務(wù)調(diào)度相關(guān)的工作。
第一層中，主要有四個(gè)數(shù)據(jù)來(lái)源：用戶(hù)行為埋點(diǎn)上報(bào)數(shù)據(jù)、服務(wù)日志的數(shù)據(jù)、后端的業(yè)務(wù)數(shù)據(jù)、互聯(lián)網(wǎng)的公開(kāi)數(shù)據(jù)。
第二層中，我們主要的核心框架是hadoop的核心生態(tài)，基于HDFS的存儲(chǔ)(本質(zhì)上hive的存儲(chǔ)也是基于HDFS)，以及基于spark的部分實(shí)時(shí)處理的需求場(chǎng)景，主要是平臺(tái)級(jí)的架構(gòu)。
當(dāng)然，至于說(shuō)具體的處理以及數(shù)據(jù)的加工、挖掘詳細(xì)數(shù)據(jù)業(yè)務(wù)，后續(xù)其他章節(jié)再詳述。
第三層中，我們直接面向的是業(yè)務(wù)方。
一方面是數(shù)據(jù)生態(tài)中最基礎(chǔ)最常見(jiàn)的的數(shù)據(jù)智能商業(yè)化分析，我們以EXCEL封裝成郵件日?qǐng)?bào)周報(bào)的形式提供另一方面是平臺(tái)化的BI系統(tǒng)，以及高度自助性的數(shù)據(jù)自助查詢(xún)系統(tǒng)。
在深度挖掘方面，推薦是一個(gè)大方向，基于數(shù)據(jù)的當(dāng)代搜索也是數(shù)據(jù)生態(tài)的重要組成部分，以及業(yè)務(wù)畫(huà)像、用戶(hù)畫(huà)像(絕對(duì)核心價(jià)值所在)等。
當(dāng)然，除了以上這些，還有一些基于數(shù)據(jù)的推送服務(wù)啊、榜單數(shù)據(jù)啊、精準(zhǔn)營(yíng)銷(xiāo)系統(tǒng)啊，都是數(shù)據(jù)進(jìn)一步有效應(yīng)用，以及數(shù)據(jù)化價(jià)值的直接體現(xiàn)。
收回話(huà)題，在時(shí)間有限，人力有限，并且基礎(chǔ)是0的前提下，事情解決的順序就顯得尤為重要了。
當(dāng)前的業(yè)務(wù)需求。
想要使用數(shù)據(jù)，前提是有數(shù)據(jù)。所以，我們第一個(gè)需要解決的問(wèn)題是數(shù)據(jù)源，但是核心的驅(qū)動(dòng)價(jià)值因素是我們的業(yè)務(wù)需求。
我們第一個(gè)業(yè)務(wù)需求就是從數(shù)據(jù)上洞察產(chǎn)品的運(yùn)營(yíng)效果，電商的各種數(shù)據(jù)運(yùn)營(yíng)需求，指導(dǎo)內(nèi)容數(shù)據(jù)化運(yùn)營(yíng)、電商數(shù)據(jù)化運(yùn)營(yíng)以及通過(guò)數(shù)據(jù)改進(jìn)產(chǎn)品。
跟業(yè)務(wù)強(qiáng)相關(guān)的基礎(chǔ)數(shù)據(jù)是產(chǎn)品的業(yè)務(wù)數(shù)據(jù)庫(kù)，這個(gè)是現(xiàn)成的，只要打通數(shù)據(jù)流通即可。
與用戶(hù)行為強(qiáng)相關(guān)的則是最直接的用戶(hù)行為埋點(diǎn)上報(bào)數(shù)據(jù)，以及用戶(hù)使用服務(wù)，在應(yīng)用服務(wù)中留下的訪問(wèn)LOG。
基于服務(wù)日志LOG解析數(shù)據(jù)，一方面如果需要從服務(wù)LOG中清洗出有用數(shù)據(jù)，前提是服務(wù)中已經(jīng)有意識(shí)的進(jìn)行相關(guān)信息的LOG落地，這一點(diǎn)，很遺憾，當(dāng)時(shí)并沒(méi)有這個(gè)前瞻性。
其次，從服務(wù)LOG中清洗數(shù)據(jù)的代價(jià)略高，且信息量有限。
所以，在這個(gè)階段中，我們并沒(méi)有打算直接從服務(wù)LOG中清洗數(shù)據(jù)，因?yàn)樵诜?wù)LOG中埋入數(shù)據(jù)收集點(diǎn)位，也是一個(gè)巨大的改造工程，但效果并不一定好。
我們將最快限度的打通業(yè)務(wù)數(shù)據(jù)庫(kù)與數(shù)據(jù)中心的通道，然后以最快速度的對(duì)業(yè)務(wù)方提供可參考性的數(shù)據(jù)化日?qǐng)?bào)。
打通行為數(shù)據(jù)到數(shù)據(jù)應(yīng)用的鏈路，結(jié)合用戶(hù)行為數(shù)據(jù)，進(jìn)一步優(yōu)化數(shù)據(jù)化運(yùn)營(yíng)體系，以及為產(chǎn)品優(yōu)化迭代提供數(shù)據(jù)支撐。
構(gòu)造最基礎(chǔ)的數(shù)據(jù)中心平臺(tái)，打通數(shù)據(jù)收集到數(shù)據(jù)分析應(yīng)用的鏈路，為業(yè)務(wù)方、決策層提供數(shù)據(jù)化運(yùn)營(yíng)決策方案，為產(chǎn)品迭代提供最真實(shí)的數(shù)據(jù)反饋支撐。
這就是我們數(shù)據(jù)部門(mén)第一個(gè)戰(zhàn)略目標(biāo)，什么深度挖掘，什么推薦系統(tǒng)，這些在這個(gè)時(shí)候統(tǒng)統(tǒng)都不要想太多啦，飯需要一口一口的吃！
我們之所以需要拆分階段目標(biāo)，依然是投入與產(chǎn)出比的問(wèn)題！
當(dāng)我們有一個(gè)大目標(biāo)時(shí)，我們需要把目標(biāo)進(jìn)行拆分，進(jìn)一步拆分為階段可實(shí)施、成果可見(jiàn)的階段性目標(biāo)，在這里同樣適用。
并且，記住，你的老板是不懂技術(shù)的，他才不會(huì)管你的平臺(tái)又建設(shè)到什么什么程度，集群又搭建了多少臺(tái)，他只會(huì)問(wèn)，這都一兩個(gè)月了，你們數(shù)據(jù)怎么還沒(méi)有給公司帶來(lái)價(jià)值??？！(哈哈，有點(diǎn)黑BOSS的感覺(jué))
不過(guò)這肯定是現(xiàn)實(shí)，不同位置上的人關(guān)注的核心重點(diǎn)不一樣?？赡苣阈枰P(guān)注整體的進(jìn)度，而業(yè)務(wù)層只關(guān)心你的產(chǎn)出給他帶來(lái)什么幫助。
是的，拆解大目標(biāo)有利于我們快速入手啟動(dòng)項(xiàng)目；成果階段化，更具有鼓勵(lì)性，成就感；最后就是階段性目標(biāo)的實(shí)現(xiàn)情況更容易量化你的效率。
從人力的需求評(píng)估角度上說(shuō)，也是有道理的，只有隨著你的體系一步一步完善，你才知道哪個(gè)環(huán)節(jié)真正的缺人，缺什么人，這點(diǎn)很關(guān)鍵。
不過(guò)最本質(zhì)的問(wèn)題，還是投入與產(chǎn)出比。
我們?cè)谧鋈艘患虑榈臅r(shí)候，都需要注意投入與產(chǎn)出的比例，在一定的時(shí)間段內(nèi)、投入一定的精力、產(chǎn)出一定比例的成果。
有這種價(jià)值觀，處理事務(wù)才更有效率！
3 如何做機(jī)器需求的評(píng)估
要打通數(shù)據(jù)收集到數(shù)據(jù)分析業(yè)務(wù)的輸出鏈路，那么，你需要一個(gè)數(shù)據(jù)平臺(tái)進(jìn)行支撐。甚至，后續(xù)你將持續(xù)開(kāi)挖的數(shù)據(jù)核心價(jià)值，也是基于平臺(tái)上做的。
所以，我們需要一個(gè)數(shù)據(jù)平臺(tái)，而說(shuō)到平臺(tái)，則機(jī)器資源是繞不過(guò)去的一個(gè)問(wèn)題。
那么，如何去評(píng)估你的集群需要多少臺(tái)機(jī)器呢？每個(gè)機(jī)器又是以一個(gè)什么樣的角色而存在呢？
在評(píng)估之前，你首先清楚的了解到，你平臺(tái)上需要承載的業(yè)務(wù)，包括內(nèi)部的處理業(yè)務(wù)以及對(duì)外暴露的數(shù)據(jù)業(yè)務(wù)。
其次，你需要考慮后續(xù)一個(gè)可擴(kuò)展性，即后續(xù)數(shù)據(jù)量上漲的情況下，機(jī)器的橫向擴(kuò)展當(dāng)然是沒(méi)有問(wèn)題的，但是部分角色機(jī)器的資源需求是在縱向。
舉個(gè)簡(jiǎn)單例子，Hadoop的datanode可以在橫向上進(jìn)行擴(kuò)展，但是namenode的資源需求則無(wú)法做到。
至于說(shuō)如何進(jìn)行機(jī)器資源評(píng)估，在了解自身業(yè)務(wù)需求的前提下，這里所說(shuō)的業(yè)務(wù)需求，不單純是業(yè)務(wù)范圍，也意味著業(yè)務(wù)范圍承載的數(shù)據(jù)量是什么情況。
在了解自身數(shù)據(jù)量的情況下，多查找其他公司的案例，與其他同行多交流溝通，借鑒其他公司的數(shù)據(jù)量與集群規(guī)模，來(lái)評(píng)估自身所需要的機(jī)器資源。
不過(guò)需要注意一點(diǎn)的是，對(duì)于電商行業(yè)，經(jīng)常會(huì)出現(xiàn)節(jié)日性、活動(dòng)性質(zhì)的流量暴漲。
所以，你的機(jī)器資源一定是需要考慮這些實(shí)際場(chǎng)景負(fù)載的，或者對(duì)于這種場(chǎng)景，你有其他的方案進(jìn)行處理也OK。
4 使用Nginx做數(shù)據(jù)上報(bào)偽服務(wù)
上面說(shuō)到第二個(gè)重點(diǎn)，那就是用戶(hù)行為數(shù)據(jù)的上報(bào)。
了解數(shù)據(jù)上報(bào)以及埋點(diǎn)相關(guān)邏輯的朋友應(yīng)該清楚，其實(shí)所謂的SDK，其本質(zhì)也是一個(gè)接受數(shù)據(jù)上報(bào)的服務(wù)。
直接往上報(bào)服務(wù)中丟數(shù)據(jù)，跟封裝成工具SDK，本質(zhì)的意義是一樣的，我們需要提供一個(gè)對(duì)外的數(shù)據(jù)上報(bào)服務(wù)。
上報(bào)什么數(shù)據(jù)，數(shù)據(jù)以什么格式上報(bào)，這個(gè)在下一章的“數(shù)據(jù)上報(bào)體系”部分詳細(xì)闡述，這里只是對(duì)上報(bào)服務(wù)這塊進(jìn)行講解。
那這意味著，我們需要為客戶(hù)端或者H5的童鞋提供一個(gè)統(tǒng)一的上報(bào)服務(wù)接口，讓他們?cè)谟脩?hù)特定行為操作的時(shí)候。
比如瀏覽了某個(gè)頁(yè)面，操作了某個(gè)按鈕等之類(lèi)的操作，進(jìn)行這種信息的收集統(tǒng)一上報(bào)。
說(shuō)白了，封裝用戶(hù)的行為數(shù)據(jù)，在適當(dāng)時(shí)候調(diào)我們的接口，把用戶(hù)的行為數(shù)據(jù)給我傳過(guò)來(lái)。
那這看似就是一個(gè)后臺(tái)服務(wù)，用于處理上報(bào)過(guò)來(lái)的數(shù)據(jù)。
但是請(qǐng)注意，不管你是一個(gè)服務(wù)也好，偽服務(wù)也好，一般情況下絕不會(huì)直接把獲取到的數(shù)據(jù)直接落地的，這是傳統(tǒng)的思維路子。
要知道上報(bào)的業(yè)務(wù)流量是很大的，特別是你的點(diǎn)位足夠豐滿(mǎn)的情況下，在流量高峰期，你要是敢直接進(jìn)行數(shù)據(jù)落地，它就敢直接把你的服務(wù)給搞死。
一般情況下，我們都會(huì)把數(shù)據(jù)丟給緩存，以解耦上報(bào)與落地兩端的壓力。
既然如此，在有限的人力資源下，在項(xiàng)目時(shí)間有限的前提下，為何要花這么大的精力去維護(hù)一個(gè)服務(wù)呢？于是，有了偽服務(wù)設(shè)想。
我們直接使用Nginx對(duì)外偽裝成一個(gè)Web服務(wù)，提供Restful API，但我們不對(duì)上報(bào)的內(nèi)容做任何處理，直接落地成Nginx的日志，再通過(guò)Flume對(duì)日志進(jìn)行監(jiān)控，丟到Kafka中。
這樣我們就迅速的搭建起一個(gè)上報(bào)“服務(wù)”，提供給客戶(hù)端童鞋以及H5的童鞋，制定好數(shù)據(jù)上報(bào)的規(guī)范，然后就可以坐等數(shù)據(jù)過(guò)來(lái)了。
關(guān)于數(shù)據(jù)的合理性校驗(yàn)、規(guī)范性校驗(yàn)、有效性校驗(yàn)、以及進(jìn)一步的解析，我們都放到Spark Streaming這一層去做。
其實(shí)當(dāng)時(shí)也是調(diào)研過(guò)lua的，在Nginx這一層也是可以做到數(shù)據(jù)完整性以及有效性校驗(yàn)的，但是為了不至于給Nginx端帶來(lái)過(guò)大的負(fù)荷，我們把復(fù)雜的邏輯處理放到后端。
基于這種偽服務(wù)的設(shè)計(jì)，還有一個(gè)好處就是，即使后端鏈路出現(xiàn)故障，但我的原始數(shù)據(jù)是落到LOG中的，了不起我進(jìn)行數(shù)據(jù)的回溯，再通過(guò)LOG清洗出異常的部分就行了。
這也是我們后續(xù)實(shí)時(shí)數(shù)據(jù)容錯(cuò)的核心依據(jù)所在，所以，重點(diǎn)推薦。
5 使用Spark Streaming做實(shí)時(shí)數(shù)據(jù)清洗
接上面的上報(bào)，我們?cè)诤蠖艘粚邮鞘褂肧park Streaming做數(shù)據(jù)校驗(yàn)、進(jìn)一步清洗的。
如果業(yè)務(wù)對(duì)于實(shí)時(shí)性要求不高，我們完全是不必要做數(shù)據(jù)的實(shí)時(shí)鏈路的，只需要周期性的把Nginx中的上報(bào)日志進(jìn)行批量清洗入庫(kù)即可。
但是，一方面基于部分對(duì)實(shí)時(shí)性稍高(其實(shí)也不高，分鐘級(jí)別)，例如電商活動(dòng)期間對(duì)數(shù)據(jù)的實(shí)時(shí)監(jiān)控；另一方面來(lái)說(shuō)，實(shí)時(shí)性的數(shù)據(jù)上報(bào)鏈路是最終的目標(biāo)，為了業(yè)務(wù)的時(shí)效性，遲早是需要做的。
由于我們需要在后端的處理環(huán)節(jié)中，對(duì)數(shù)據(jù)的有效性、規(guī)范性做校驗(yàn)，并且做進(jìn)一步的屬性解析，例如通過(guò)IP解析地理位置之類(lèi)的，所以承載的業(yè)務(wù)邏輯還是蠻復(fù)雜的。
所以，我們打算引入一個(gè)實(shí)時(shí)處理框架來(lái)做這件事。
關(guān)于實(shí)時(shí)框架這塊，我想，熟悉的朋友都會(huì)想到兩個(gè)：Storm與Spark Streaming。
簡(jiǎn)單的說(shuō)一下兩者的對(duì)比。
很久以前翻譯過(guò)一篇文章《翻譯：Storm與Spark Streaming的對(duì)比》，這里只是簡(jiǎn)單的說(shuō)一說(shuō)。
Storm與Spark Streaming最本質(zhì)的區(qū)分在于，Storm是真正實(shí)時(shí)處理，而Spark Streaming的處理本質(zhì)則是微批處理。
所以Storm能夠?qū)?shí)時(shí)業(yè)務(wù)達(dá)到毫秒級(jí)，而Spark Streaming雖然也能達(dá)到亞秒級(jí)，但對(duì)于效率的影響會(huì)比較大，所以一般會(huì)用于秒級(jí)的數(shù)據(jù)處理。
目前就我們自身的業(yè)務(wù)需求來(lái)說(shuō)，對(duì)于實(shí)時(shí)性并沒(méi)有高到毫秒級(jí)的要求。
并且，為了維護(hù)系統(tǒng)平臺(tái)的統(tǒng)一性(統(tǒng)一的平臺(tái)架構(gòu)，統(tǒng)一的YARN資源管理，同一個(gè)垂直生態(tài))，我們選擇使用Spark Streaming作為我們數(shù)據(jù)清洗的入口。
使用Spark Streaming需要解決的一個(gè)問(wèn)題就是，輸出結(jié)果的高度碎片化。
正如上面所說(shuō)，Spark Streaming其核心依然是Spark的路子，在微小的時(shí)間窗內(nèi)，對(duì)微小批量的數(shù)據(jù)進(jìn)行處理，達(dá)到類(lèi)似實(shí)時(shí)的效果。
而其每一個(gè)批量處理之后都是以批量結(jié)果得以輸出，于是，就會(huì)產(chǎn)生大量的碎片文件。
其實(shí)，解決這個(gè)問(wèn)題也簡(jiǎn)單，那就是合并！進(jìn)行周期性的文件合并，這點(diǎn)就不多說(shuō)了。
既然說(shuō)到了Spark Streaming，也就順帶著說(shuō)一說(shuō)Spark這個(gè)生態(tài)。
在很早以前，Hadoop、MapReduce經(jīng)常會(huì)被人提到，但是隨著Spark的興起，已經(jīng)越來(lái)越少人愿意使用MapReduce去批量處理數(shù)據(jù)了。
是的，Spark目前在Hadoop大生態(tài)中，已經(jīng)形成一個(gè)比較完整的子生態(tài):
(1) 包括與數(shù)據(jù)查詢(xún)分析關(guān)聯(lián)的Spark SQL；
(2) 實(shí)時(shí)處理領(lǐng)域的Spark Streaming；
(3) 正常內(nèi)存處理可以替代MapReduce的離線(xiàn)批量；
(4) 還有集成大量機(jī)器學(xué)習(xí)包的MLlib；
(5) 以及還有什么圖形處理的什么鬼(好吧，那個(gè)不是我擅長(zhǎng)的)。
在效率至上的數(shù)據(jù)時(shí)代，MapReduce說(shuō)拋棄就被拋棄了(哈哈，其實(shí)也沒(méi)有這么嚴(yán)重，只是越來(lái)越多人棄用MapReduce，這肯定是事實(shí))。
在體系支撐上，Spark依然成氣候，數(shù)據(jù)的常規(guī)SQL分析，數(shù)據(jù)的內(nèi)存處理、實(shí)時(shí)處理，以及數(shù)據(jù)的深度挖掘等，全部一起打包，好用的不得了，所以越來(lái)越得人心，也是木有辦法的事。
關(guān)于IP地理位置解析，這里也可以分享一下。
IPIP.NET提供的IP庫(kù)實(shí)在是值得推薦的，沒(méi)錢(qián)的可以使用它提供的免費(fèi)版，有錢(qián)的主可以考慮使用使用付費(fèi)版。
其實(shí)免費(fèi)版也沒(méi)有想象中那么不堪，只是他提供的服務(wù)沒(méi)有這么多，更新的頻次少點(diǎn)而已，大部分能解析到市一級(jí)，至于省份這一級(jí)，那是妥妥的沒(méi)問(wèn)題的。
6 結(jié)語(yǔ)
這一章主要闡述如何從局部入手，拆解架構(gòu)圖，進(jìn)行階段性的任務(wù)執(zhí)行，從這個(gè)角度講，上一章節(jié)的標(biāo)題反倒是更適合這個(gè)了。
其中，詳細(xì)講解了部分核心重點(diǎn)，包括架構(gòu)圖的拆解、機(jī)器資源的評(píng)估、Nginx的上報(bào)偽服務(wù)、以及基于Spark Streaming的數(shù)據(jù)清洗等。
但是，個(gè)人認(rèn)為，更重要的是期中闡述一些問(wèn)題的思考方式、價(jià)值觀等。諸如拆解整體規(guī)劃的思考、擴(kuò)展預(yù)留的思考、方案選擇的對(duì)比衡量等。
方法論遠(yuǎn)比現(xiàn)成的方案有用！我一向的觀點(diǎn)是：授人以魚(yú)不如授人以漁。
OK，到這里，本章節(jié)打完收工。
下一章節(jié)將很有意思，內(nèi)容就不過(guò)多暴露了，標(biāo)題已定《從0到1構(gòu)建數(shù)據(jù)生態(tài)之二：與研發(fā)團(tuán)隊(duì)的愛(ài)恨情仇》。
7 致謝
PS：在數(shù)據(jù)生態(tài)構(gòu)建的初期，也咨詢(xún)過(guò)很多業(yè)內(nèi)的同行朋友，他們也給了很多真心的建議，所以，這里給這些大神們致謝，雖然他們不一定能看的見(jiàn)！
哈哈，所謂的排名不分先后，都一律謝過(guò)：
@樂(lè)視云的祝威廉大神
@樂(lè)視云的一斐大神
@極客學(xué)院的馬健大神
@百度的二鐵兄
@前百度現(xiàn)GrowingIO的何健大神
@其他Storm-Hadoop-大數(shù)據(jù)群里，給過(guò)意見(jiàn)或建議的盆友
從0到1構(gòu)建數(shù)據(jù)生態(tài)系列：
《從0到1構(gòu)建數(shù)據(jù)生態(tài)系列之一：蠻荒時(shí)代》
《從0到1構(gòu)建數(shù)據(jù)生態(tài)系列之二：拓荒》
《從0到1構(gòu)建數(shù)據(jù)生態(tài)系列之三：拆解架構(gòu)圖》
《從0到1構(gòu)建數(shù)據(jù)生態(tài)系列之四：與研發(fā)團(tuán)隊(duì)的愛(ài)恨情仇》
《持續(xù)未完~~》
