某遊戲公司随着業務快速發展，使用者行為日志快速增長，需要從海量的點選流日志和激活日志中挖掘資料的價值，比如廣告轉化率、激活率，每日安裝使用者成本等等。
業務挑戰
原來使用GreenPlum做實時計算和統計分析。但是GreenPlum存在以下缺陷，難以應對業務的快速發展:
- GreenPlum架構難以應對日益複雜的計算任務；
- Greenplum的單表分區數目有限制，同時多級分區支援不夠友好，不适用單表資料量比較大且需要永久儲存的日志，如果單個分區表資料量比較大的時候查詢性能無法滿足業務性能需求；
- Greenplum擴容時由于資料要重分布會比較慢；
- Greenplum不适合處理非結構化的資料。
解決方案
在這樣的背景下選擇了阿裡雲HBase SQL服務(Phoenix)+
Spark服務建構實時計算和資料倉庫解決方案，其中HBase SQL提供線上查詢能力、Spark提供流式處理、複雜分析等能力來滿足業務需求。下面是業務資料倉庫架構圖：
如上圖梳理業務資料，對資料進行分層存儲在HBase SQL(Phoenix)+Spark中：
- 操作資料層：手遊用戶端、使用者中心、廣告監測、遊戲伺服器等産生的原始日志；
- 資料明細層：”操作資料層”使用Spark Streaming等進行資料去噪、去重、字段規範後寫入HBase SQL服務，也可以直接使用JDBC寫入資料；
- 資料彙總層：”資料明細層”的資料可以定期使用Spark SQL(按天或者按小時)ETL(比如關聯維表、過濾、聚合)後寫入到”資料彙總層”。資料彙總層的資料供後續的複雜分析；
- 應用資料層：直接對外提供資料查詢服務(基于HBase SQL服務)支撐上層大資料風控、廣告推薦、海量資料精細化營運；“資料彙總層“的資料經過處理後會把結果資料寫入到HBase SQL中對外提供查詢服務。
價值
- 毫秒級識别攔截代充訂單。HBase SQL(Phoenix) 高并發實時讀寫，TPS可達百萬量級，并發十萬量級，毫秒級簡單查詢；
- Spark優秀的計算能力。同樣作業Spark基于列式存儲Parquet的分析在資料量大的情況下比Greenplum叢集有10倍的性能提升。支撐了廣告轉化率、激活率，安裝使用者成本，資料驅動精細化營運等業務計算需求；
- 一站式解決方案。Spark服務原生支援通過SQL讀取HBase SQL(Phoenix)資料能力，具備列裁剪、謂詞下推、分區裁剪等優化；高效的把HBase SQL線上庫的資料ETL後歸檔到Spark資料倉庫；
- 聚焦業務。全托管的Spark服務保證了作業運作的穩定性，釋放運維人力，同時資料工作台降低了spark作業管理成本。使用者也調研過ecs自建Hadoop生态，最終選擇了HBase的Spark服務，包括以下原因：
| 開源Hadoop生态(ECS自建) | ||
| 服務模式 | 全托管，免運維，提供SLA保障，開箱即用 | 投入團隊研發和運維服務，無SLA保障 |
| 産品功能 | 一站式解決方案，Spark深度融合HBase服務，精心調優，無需配置 | 功能繁雜，開源元件多，學習，配置調優成本高 |
| 性能 | Spark分析HBase的connector深度優化，内置connector，無需配置 | 社群版本，connector配置繁瑣，無品質和SLA保障 |
| 易用性 | 專門的Spark的資料工作台、restful 服務、command line | 缺少企業級的資料工作台 |
技術社群
群福利：群内每周進行群直播技術分享及問答
加入方式1：點選
link申請加入
加入方式2：釘釘掃碼加入
