1 項(xiàng)目背景
小紅書是 一個(gè)很大的系統(tǒng)，我在這個(gè)系統(tǒng)主要負(fù)責(zé)信息流板塊的數(shù)據(jù)處理和分析
，帶領(lǐng)7人開發(fā)小隊(duì)，接手這個(gè)板塊一共兩年半的時(shí)間，經(jīng)歷了數(shù)據(jù)量上萬倍的增長
，也經(jīng)歷用戶量百萬到億的蛻變
2 項(xiàng)目目標(biāo)
我在本項(xiàng)目的目標(biāo)有3個(gè)，1 提高推廣訂單的投入產(chǎn)出比，2 提高推薦列表的用戶喜
好比，3 提高作品的標(biāo)簽準(zhǔn)確度，總體來說就是提高用戶粘性，按照用戶的喜好推薦
作品
3 項(xiàng)目概述
1 整個(gè)架構(gòu)采用基于http通訊srping cloud架構(gòu)，java開發(fā)3名，python3名，R一名。
2 java采用fink+kafka讀取用戶行為記錄
3 R通過mlib計(jì)算用戶行為
4 python通過AI算法計(jì)算用戶標(biāo)簽
5 用戶啟動app會讀取標(biāo)簽喜好列表，通過算法推薦作品
6 用戶的每次行為都會被記錄，每隔一段時(shí)間上傳服務(wù)器
7 數(shù)據(jù)存儲采用Redshift，后轉(zhuǎn)化為DorisDB
8 數(shù)據(jù)分析使用的ETL，后轉(zhuǎn)化為hadoop
項(xiàng)目職責(zé)： 1 項(xiàng)目中擔(dān)任的角色
我在本項(xiàng)目中的兩年半時(shí)間里，一直擔(dān)任著java技術(shù)專家，負(fù)責(zé)小組成員的管理以
及項(xiàng)目的主要開發(fā)，對算法以及架構(gòu)不斷的優(yōu)化調(diào)整
2 項(xiàng)目中遇到的痛點(diǎn)難點(diǎn)
2.1 Redshift無法在不影響線上查詢性能的前提下彈性擴(kuò)展，一旦涉及到擴(kuò)容，就會
涉及到數(shù)據(jù)重分布，從而影響集群的性能以及可用性。
2.2 ETL任務(wù)嚴(yán)重影響集群可用性。在Redshift中同時(shí)進(jìn)行ETL任務(wù)的時(shí)候，會大量搶
占資源，從而影響數(shù)據(jù)分析的效率，導(dǎo)致查詢超時(shí)甚至因?yàn)榧贺?fù)載過大后整個(gè)集群
崩潰不可用。
2.3 沒有良好的存算分離，數(shù)據(jù)存儲容量存在瓶頸，無法滿足隨業(yè)務(wù)而快速增長的數(shù)
據(jù)量存儲需求
3 解決問題的辦法
3.1 隨著數(shù)據(jù)倉庫在Hadoop/Hive體系上搭建和完善，ETL任務(wù)全部轉(zhuǎn)移至Hadoop集
群，這個(gè)階段使用Presto完成OLAP分析。Presto天然和Hive共享元數(shù)據(jù)信息，且共同
使用物理數(shù)據(jù)存儲，即插即用。大量的對數(shù)倉表的靈活查詢使用Presto完成
項(xiàng)目業(yè)績： 1 目標(biāo)達(dá)成情況
1:穩(wěn)定處理上億用戶日活躍的數(shù)據(jù)
2:穩(wěn)定分析每日上萬EB的數(shù)據(jù)量
3:穩(wěn)定完成大型數(shù)據(jù)分析系統(tǒng)的更新迭代
2 我的貢獻(xiàn)
1: 見證了小紅書的發(fā)展
2:經(jīng)歷了數(shù)據(jù)蓬勃壯大的系統(tǒng)升級
3 穩(wěn)定分析了小紅書的數(shù)據(jù)
4 全面負(fù)責(zé)一個(gè)板塊的開發(fā)迭代