TB級(jí)大數(shù)據(jù)應(yīng)用搭建實(shí)踐

1、 TB級(jí)大數(shù)據(jù)應(yīng)用搭建實(shí)踐本文介紹的BigData APP基本目標(biāo)是支撐100,000+用戶、120億條數(shù)據(jù)、TB級(jí)存儲(chǔ)、秒級(jí)響應(yīng)。比起性能，更受用戶歡迎的功能在于支持不同機(jī)構(gòu)或業(yè)務(wù)條線發(fā)布數(shù)據(jù)，支持不同崗位不同角色不同用戶按需訂閱，而這些絲毫不用技術(shù)人員介入。如上邏輯架構(gòu)圖，Oracle、GreenPlum、Teradata不同系列的數(shù)據(jù)庫產(chǎn)品（不同的計(jì)算區(qū)）計(jì)算出來的各種指標(biāo)，通過ETL技術(shù)把各種數(shù)據(jù)源源不斷地匯入公共訪問區(qū)，接著通過Redis、HBase和Kylin等時(shí)下流行的開源技術(shù)實(shí)現(xiàn)兩級(jí)緩存以應(yīng)對(duì)海量的移動(dòng)用數(shù)訪問。移動(dòng)端采用了HTML5技術(shù)屏蔽設(shè)備操作系統(tǒng)差異，同時(shí)VUE.js和

2、ECharts等技術(shù)實(shí)現(xiàn)了數(shù)據(jù)展現(xiàn)和自動(dòng)推送。通過參數(shù)化設(shè)計(jì)將業(yè)務(wù)運(yùn)營從開發(fā)中分離出來，讓工程師更加關(guān)注如何支持好業(yè)務(wù)數(shù)據(jù)和用戶自然增長(zhǎng)。這種自我生長(zhǎng)的APP模式，就像一顆樹苗，依靠樹根從土壤（GreenPlum和Teradata構(gòu)成的計(jì)算區(qū)）源源不斷地吸收養(yǎng)分，再通過樹干（公共訪問區(qū)）以及樹枝（各級(jí)Cache）生出樹葉（用戶在移動(dòng)APP端用數(shù)），通過這種架構(gòu)的孕育，樹苗長(zhǎng)成參天大樹不過是時(shí)間問題。（注：樹型架構(gòu)，出處參見高煥堂 Annpping Kao所著思考軟件，創(chuàng)新設(shè)計(jì)A段架構(gòu)師的思考技術(shù)第5頁“1.4軟件的復(fù)雜時(shí)本質(zhì)性的-架構(gòu)師從復(fù)雜設(shè)計(jì)出簡(jiǎn)單”）這個(gè)APP從什么時(shí)候開始蘊(yùn)藏著如此巨大

3、的能量？1962年9月12日，肯尼迪發(fā)表了著名的月球演說之后（/seh/ricetalk.htm），NASA硬著頭皮開始登月，阿波羅1號(hào)竟然在地面就爆炸了，經(jīng)歷多次失敗，直到阿波羅8號(hào)首次完成了載人環(huán)行月球一周并返回地球之后，NASA才確信人類登上月球只是時(shí)間問題。很多人知道阿波羅11號(hào)登月成功，卻不知道在肯尼迪航天中心紀(jì)念的是阿波羅8號(hào)，因?yàn)檫@個(gè)阿波羅8號(hào)是工程師所懷念的成功原型。是的，這幾個(gè)簡(jiǎn)單的界面就是Data APP的“阿波羅8號(hào)”，接下來重點(diǎn)介紹如何通過敏捷開發(fā)打造出這個(gè)“阿波羅8號(hào)”。知易行難（2016年5月-2016年8月）把時(shí)間撥回到2016年5月-8月這段時(shí)間，在如此體量而又

4、優(yōu)越的企業(yè)平臺(tái)，引入技術(shù)不是一蹴而就的事情，要完成一個(gè)從沒實(shí)踐過的應(yīng)用，通常分三步走：第一步，按圖索驥。大數(shù)據(jù)這條路上，一定要看每年發(fā)布的大數(shù)據(jù)藍(lán)圖（Big Data LandScape由Matt Turck首先于2012年提出，通過這張圖的更新，可以找到業(yè)界的技術(shù)投資潮流）。這張圖的使用訣竅，在于要透過復(fù)雜的表象按照大數(shù)據(jù)技術(shù)的抽象分類（可參考）來尋找可能的技術(shù)方向。這個(gè)項(xiàng)目剛開始的時(shí)候，我們想法很簡(jiǎn)單，采用H5技術(shù)屏蔽IOS和Android，用ECharts實(shí)現(xiàn)移動(dòng)端數(shù)據(jù)可視化，沿用數(shù)據(jù)平臺(tái)公共訪問區(qū)已有的GreenPlum。第二步，按部就班。一項(xiàng)技術(shù)要成為企業(yè)的選擇，必須經(jīng)歷一系列的測(cè)試

5、，從功能到非功能，根據(jù)預(yù)先設(shè)定的指標(biāo)進(jìn)行匹配，找到最合適的。入選企業(yè)級(jí)技術(shù)產(chǎn)品目錄后，再逐步推廣，產(chǎn)生規(guī)模效應(yīng)。選好的技術(shù)不涉及商業(yè)產(chǎn)品，時(shí)間緊任務(wù)重，趕快出活才是硬道理。第三步，用戶至上。在應(yīng)用架構(gòu)、數(shù)據(jù)架構(gòu)和技術(shù)平臺(tái)幾個(gè)層級(jí)上，解決了共享問題之后，要按照用戶體驗(yàn)組合這些組件服務(wù)，在保證后臺(tái)功能相對(duì)穩(wěn)定的同時(shí)，積極擁抱用戶在前端需求的快速變化。用戶體驗(yàn)組（移動(dòng)端用數(shù)需求負(fù)責(zé)人），多次走訪基層網(wǎng)點(diǎn)和分行部門及高層的管理人員，按照不同崗位提煉出了典型應(yīng)用場(chǎng)景（晨會(huì)、周會(huì)、經(jīng)營分析會(huì)），形成了100多頁需求。邏輯推理加穩(wěn)步執(zhí)行，這頓想象中共襄盛舉的數(shù)據(jù)自助餐應(yīng)該水到渠成。經(jīng)過三個(gè)月的努力，按計(jì)劃到

6、了初始版本交付的時(shí)間。原計(jì)劃要交付分行三類管理崗位和一個(gè)總行部門的功能，結(jié)果只交付了基層網(wǎng)點(diǎn)負(fù)責(zé)人的部分頁面。就拿首頁來說，在測(cè)試環(huán)境還好，上了生產(chǎn)之后，運(yùn)行了一周慘不忍睹，頁面要跑10來秒，數(shù)據(jù)對(duì)不上、缺數(shù)也是常有的事。更悲哀的是，付出艱辛努力經(jīng)歷了試運(yùn)行失敗的同志們，還要被“不就是推幾個(gè)數(shù)到手機(jī)上這么簡(jiǎn)單的事情”的質(zhì)疑所摧殘。一切印證了一句古話，大道至簡(jiǎn)，知易行難！置之死地而后生（2016年9月）按照原有需求交付軟件，已經(jīng)不現(xiàn)實(shí)了。要解決問題，得先看看到底發(fā)生了什么？負(fù)責(zé)需求的業(yè)務(wù)人員說：“我們?cè)O(shè)計(jì)了20幾個(gè)場(chǎng)景，需求寫了幾百頁，我們從來沒有這么認(rèn)真對(duì)待過需求”負(fù)責(zé)指導(dǎo)實(shí)施的架構(gòu)師說：“我

7、們選擇了最先進(jìn)最流行的技術(shù)，實(shí)現(xiàn)了H5典型頁面和數(shù)據(jù)服務(wù)，數(shù)據(jù)慢主要是因?yàn)椋ǚ凑莿e人，不是自己，列了一些）”負(fù)責(zé)實(shí)施任勞任怨一臉無辜地程序員說：“手機(jī)頁面需求大版本變更了3次，我們100多個(gè)頁面足足做了3次，我們沒日沒夜加班也就實(shí)現(xiàn)了總量60%的頁面功能，程序能部署上線已經(jīng)不錯(cuò)了如果沒有變更，或許會(huì)好一點(diǎn)?！眳⑴c項(xiàng)目的每個(gè)人說的都沒有錯(cuò)，可是結(jié)果不好，沒有人承擔(dān)責(zé)任，一定是整個(gè)團(tuán)隊(duì)都出了問題。回顧雄心壯志開啟移動(dòng)端開發(fā)的初衷，在沒有公司資源輔助投入的情況下，我們作為甲方中的乙方，似乎把業(yè)務(wù)人員的口味調(diào)高了；隨著項(xiàng)目深入，業(yè)務(wù)人員對(duì)移動(dòng)端的認(rèn)知穩(wěn)步提升，三次大規(guī)模的需求變更就是業(yè)務(wù)人員進(jìn)步的實(shí)

8、證。其實(shí)，大家都害怕移動(dòng)端不能一炮打響！然而，隨著時(shí)間的發(fā)展，每個(gè)人都熱情高漲的添磚加瓦，要啥給啥，只有技術(shù)人員為進(jìn)度所迫不斷降低對(duì)自己的要求（包括范圍和質(zhì)量），缺乏溝通也沒有實(shí)時(shí)的產(chǎn)出物可以驗(yàn)證，而交付和期望的差距已經(jīng)發(fā)展到不可收拾的境地。到了約定交付的時(shí)候，發(fā)現(xiàn)業(yè)務(wù)用戶的情感在瞬間熄滅，領(lǐng)導(dǎo)層的許諾也隨之崩塌，這也是許多瀑布型項(xiàng)目失敗的原因。我們?nèi)绾尾拍芘まD(zhuǎn)這個(gè)局面？想起這三年關(guān)注的數(shù)據(jù)敏捷開發(fā)，干脆把死馬當(dāng)活馬醫(yī)，于是這次危機(jī)就成了我們敏捷開發(fā)實(shí)踐的機(jī)會(huì)。于是，我們就按敏捷的教科書上說的，第一要把需求變成用戶故事，第二要把故事按輕重緩急排個(gè)序，實(shí)施團(tuán)隊(duì)在此基礎(chǔ)上構(gòu)建軟件的最小可運(yùn)行集。第

9、一天，我們就依葫蘆畫瓢把原來的Word需求文檔，通過CV大法整理成教科書中要求的用戶故事的樣子作為XX（具體人名），為了XX目的，需要提供XX功能。整理了不到十個(gè)用戶故事，小伙伴們開始懷疑這樣做的意義！敏捷的本意就是關(guān)注目標(biāo)，避免過于浪費(fèi)的過程。把內(nèi)容寫在便簽紙上，貼在墻上，標(biāo)上約束，足夠提醒程序員要做什么。最關(guān)鍵的是，要讓技術(shù)人員和業(yè)務(wù)人員通過直接溝通在故事的驗(yàn)收標(biāo)準(zhǔn)（測(cè)試用例）達(dá)成一致?？吹轿孱伭谋愫瀳D片了嗎，黃色或綠色便簽用來寫用戶故事，橙色用來寫約束，紅色用來標(biāo)問題或是技術(shù)債。事情做完或問題解決后，便簽就會(huì)從墻上摘下來放進(jìn)盒子里，隨著時(shí)間的推移，放進(jìn)盒子里的便簽越來越多，團(tuán)隊(duì)的自信

10、心就這么一點(diǎn)一點(diǎn)的找回來，大家慢慢的忘了什么事情做不成，而只去想“能做成什么”。還有一個(gè)事情要說一下，關(guān)于用戶故事的排序問題，如果直接詢問業(yè)務(wù)人員，很難得到確定的回答。那個(gè)時(shí)候已經(jīng)九月初離第二次試運(yùn)行上線只有一個(gè)月了，如果每一天都當(dāng)作最后一天來過，用戶需要的是什么，我們又能做出什么回應(yīng)？運(yùn)氣很好，恰恰是這兩個(gè)問題，把我們和用戶拉到了一起。畢加索抽象公牛的手稿，啟發(fā)了我們對(duì)抽象的思考。按不同崗位的工作場(chǎng)景編寫的需求，本質(zhì)的訴求在于讓業(yè)務(wù)人員通過手機(jī)移動(dòng)端隨時(shí)可以看到關(guān)鍵指標(biāo)，而不在于業(yè)務(wù)場(chǎng)景和頁面需求的多少。有了抽象思維，整個(gè)小組達(dá)成了共識(shí)，與其“按期交付100個(gè)不可運(yùn)行的頁面“，不如“只交付最

11、有用且保證質(zhì)量的5個(gè)頁面”。我們開始意識(shí)到，通過抽象思維，可以總結(jié)頁面模式，不需要那么多頁面和場(chǎng)景也能達(dá)到目的。可是，什么樣的頁面模式才能達(dá)到我們的目的？我們?nèi)绾握业健鞍⒉_8號(hào)”？我們的運(yùn)氣很好，珅哥用VUE改出的第一套頁面模板（首頁、指標(biāo)趨勢(shì)分析、機(jī)構(gòu)信息和結(jié)構(gòu)解析四個(gè)頁面），就得到了用戶和其他開發(fā)人員的認(rèn)可，再多的指標(biāo)再多的場(chǎng)景，只要把這個(gè)四個(gè)頁面的性能調(diào)到1秒以內(nèi)，任何指標(biāo)分分鐘實(shí)施完。為了測(cè)試用戶體驗(yàn)，我們甚至把業(yè)務(wù)參數(shù)化設(shè)計(jì)也放到一邊，改用json配置先看看哪些業(yè)務(wù)參數(shù)易變。是不是很神奇？以為我會(huì)說得很曲折，必須承認(rèn)就是運(yùn)氣！天下武功，唯快不破（2016年10月-2016年11月）

12、教科書上說，要擁抱變化！實(shí)踐告訴我們，很多時(shí)候，人不是害怕改變，而是害怕被改變，想著主動(dòng)改變或許就不會(huì)那么害怕改變，這需要勇氣。當(dāng)需求變成了用戶故事，我們的設(shè)計(jì)開發(fā)也變成了”測(cè)試驅(qū)動(dòng)開發(fā)TDD+持續(xù)集成CI“?？陀^的說，不是每個(gè)人都馬上適應(yīng)TDD，更苛刻地說，大部分人無法適應(yīng)TDD思維。把TDD上升到精神層面，可能挑戰(zhàn)的是人的惰性，堅(jiān)持下來會(huì)激發(fā)人的激情，做不好就會(huì)全軍覆沒。作為可以借鑒的經(jīng)驗(yàn)，我們把TDD先下降到戰(zhàn)術(shù)層面，把TDD當(dāng)作帶測(cè)試案例的需求文檔，把TDD當(dāng)作設(shè)計(jì)思路的形成過程，那就說TDD對(duì)工程師的好處在于可以省略掉需求分析和設(shè)計(jì)文檔（還好沒有正式立項(xiàng)，要不會(huì)有人追殺我的）。TDD

13、真是敏捷開發(fā)的重要一環(huán)，沒有有效的測(cè)試程序，識(shí)別技術(shù)債也是空想，重構(gòu)會(huì)成為空中樓閣，CI就如同行尸走肉般無用。TDD是敏捷轉(zhuǎn)型技術(shù)部分的底線，沒有退讓的余地。所以，我們先用免文檔誘導(dǎo)，再靠行政命令固化，最后曉之以情動(dòng)之以理，把所以同志帶到TDD的道路上。結(jié)果，意想不到的是最后轉(zhuǎn)型的人居然是團(tuán)隊(duì)里最資深的成員（此處略去稱謂，簡(jiǎn)稱“老大哥”）。還好，逮到了一次機(jī)會(huì)。老大哥每個(gè)周末都辛勤地用CV大法（拷貝+粘貼）應(yīng)付指標(biāo)口徑的變更（變更來自數(shù)據(jù)分析師的修正），在我看來，這是用戰(zhàn)術(shù)上的勤奮掩蓋戰(zhàn)略上的懶惰。慢慢的，大哥頂不住了，找我增援。我以“2 Piazzas”法則（敏捷重要法則之一，團(tuán)隊(duì)不宜太大，

14、兩個(gè)披薩夠吃為宜，當(dāng)然，我們團(tuán)隊(duì)里最壯的哥們經(jīng)常挑戰(zhàn)這個(gè)法則，因?yàn)樗粋€(gè)人就能吃兩Pizza）為由拒絕了。同時(shí)，找了和大哥最親密的小伙伴小鋒，一起研究代碼，寫了幾個(gè)TDD的范例，同時(shí)直接重構(gòu)出幾個(gè)函數(shù)。當(dāng)江湖上最后一位大哥擁抱了TDD，通往快速迭代的道路上就再也沒有障礙了。領(lǐng)導(dǎo)特別關(guān)注的項(xiàng)目，壓力雖然大，也有很多好處，我們爭(zhēng)取到了每周上一次線的頻繁犯錯(cuò)機(jī)會(huì)。根據(jù)用戶故事和技術(shù)債，我們擬定了一周上功能一周調(diào)性能的策略。敏捷響應(yīng)業(yè)務(wù)的速度，讓業(yè)務(wù)人員都驚呆了，11月19日版本封版前一天，試點(diǎn)分行又提出了新的崗位和指標(biāo)變更需求，結(jié)果我們用了半天就完成了，并順利封版上線，從側(cè)翼支持了江西行新一代三期試

15、點(diǎn)。時(shí)間就這樣，一周一周一月一月得過去了，我們的APP在功能上收獲了“用戶直接訂閱指標(biāo)”、“后臺(tái)配置指標(biāo)全集”、“不同指標(biāo)適應(yīng)不同維度”、“按用戶要求設(shè)立警戒線”等等大塊功能，為了滿足毫秒級(jí)響應(yīng)的用戶體驗(yàn)，也慢慢地集成了Redis、Mondrian、Kylin等多種技術(shù)，完成了手機(jī)APPOLAP的多級(jí)緩存，完成了大規(guī)模用戶推廣的準(zhǔn)備工作。天下武功，唯快不破。在這個(gè)快速迭代的過程中，我們知道，成功的秘訣在于快?！翱臁辈皇峭倒p料，而是緊盯目標(biāo)，只要能達(dá)到效果就上，絕不浪費(fèi)時(shí)間猶豫不決，每一次的故事，我們只在乎，APP是不是能更快的支撐業(yè)務(wù)變更、是不是能運(yùn)行得更快、是不是能讓運(yùn)維更方便。無招勝有招不得不承認(rèn)，這次敏捷轉(zhuǎn)型有些偶然性，沒有多少掙扎（前面其實(shí)有三個(gè)月試了個(gè)大錯(cuò)死不承認(rèn)），我們就找到了“阿波羅八號(hào)”原型。絕境中，傳統(tǒng)開發(fā)到敏捷開發(fā)的轉(zhuǎn)型。若是將來運(yùn)氣沒有那么好，咋辦？是的，如果開發(fā)不能讓業(yè)務(wù)通過運(yùn)營進(jìn)行發(fā)展，那么開發(fā)就是失敗的；如果開發(fā)次次都只靠拍腦袋想解決方案，那翻船的可能性也會(huì)大增。Matt說：“BigData success is not about implementing on