總體架構

 

 

貝殼找房大數據的整體架構，從下到上分為四層：

基礎平臺層。這一層應用的都是比較常見的技術：HDFS 分布式存儲，yarn 分布式調度，以及 HBase 存儲，另外還有一些計算引擎，如 hive、tez、spark、presto、kylin、clickhouse、SparkML 等來滿足各種各樣的基礎需求，同時還有高性能的計算機集群。

基礎平臺層的工作總結起來包括：

一體化監(jiān)控
提供強安全保障
高穩(wěn)定高效率運行
低成本解決方案

能力匯聚層。大家知道每年都有大量的開源組件，那么如何讓上層的業(yè)務方更好的應用這些組件，就是能力匯聚層要完成的工作：

Queryengine，可以通過 queryengine 使用 hive、tez、spark、presto 來查詢整個底層存儲的數據。

Olap 平臺，通過封裝 kylin(預構建)、HBase、Phoenix、presto、clickhouse(流量分析)等引擎能力，打造統(tǒng)一的 olap 平臺來滿足業(yè)務方不同的需求。

流式計算平臺，這個是今天要分享的主題，包括流式計算產品天眼(原秒 X 平臺);然后是數據直通車，它是貝殼平臺打造的一個數據接入平臺，可以進行實時接入和離線接入。

加速計算平臺，底層有高性能集群，上層就需要有加速計算平臺，來滿足業(yè)務方機器學習或者深度學習的需求。

能力匯聚層的工作總結起來包括：

統(tǒng)一入口
靈活分析
能力提效

更上層就是數據倉庫做的事情：

數據內容層。這層主要是做統(tǒng)一數據湖，新房數據湖等等一些數據治理的工作來構建數據倉庫，以滿足更上層業(yè)務方的需求。

能力輸出層。

Adhoc 即席查詢，比如貝殼找房這邊有些城市站，有運營市場，adhoc 可以直接寫一些 sql，調用 queryengine，最終通過各種各樣引擎的能力，來滿足即席查詢的需求。

我們還引進了 Tebleau 軟件，可以用來做 BI 分析，它的底層也是調用 queryengine 查詢數據內容層的數據。

同時我們也構建了統(tǒng)一指標平臺;圖靈，滿足經紀人的需求;羅盤，滿足一些流量分析的需求。

能力輸出層的工作總結起來包括：

基礎支撐
數據組合能力
賦能業(yè)務
數據流流程

 

 

要理解流式數據，首先要知道數據流的流程：

數據接入。為了做好數據分析，同時給用戶畫像、數據挖掘等提供數據物料，就需要做好數據接入層，一般情況下我們面臨的問題主要有：

① 多變：數據來源有業(yè)務 DB、MySQL、Oracle、sql server、第三方存儲 Redis 等多種數據源，怎么對多變的數據源做統(tǒng)一的、及時的接入。

② 異常：舉個例子，某些業(yè)務方經常在半夜刷新數據，這對數據接入的實時性和準確性產生了很大的影響。

③ 效率：

A. 離線數據接入，如何更快的把數據接入進來。
B. 實時數據接入，如何準確的接入，并及時提供需求數據。

針對這些問題，貝殼找房的解決方案就是 Databus(數據直通車)，通過數據直通車來解決上述的三個問題，把行為數據和業(yè)務數據及時、高效的接入計算平臺層，來滿足流式數據的計算和需求。

實時 ETL。主要分為上層的數據治理和下層的計算平臺。數據接入進來之后，采用什么樣的形式存儲，更好的做數據分析，而實時計算又采用什么樣的方式存儲，這里都是通過 Ark 平臺來做實時處理。

數據輸出。如何把數據更好的提供給用戶，這里主要會介紹日志流產品化的平臺天眼。

挑戰(zhàn)

 

 

流式數據平臺面臨的挑戰(zhàn)：

流式元數據管理。公司到底有哪些流式數據?比如 kafka 接了一批日志，MySQL 產生了一批 binlog，各種事務中也產生了一些流式數據。這些流式數據來自哪些業(yè)務方?數據類型是什么?有什么樣的屬性?以貝殼為例，是新房的數據?還是二手房的數據?還是經紀人的數據?還是客戶的數據?里面數據的格式是什么樣的?如何存儲的?如何解析?都需要統(tǒng)一的流式元數據管理平臺，來更好的理解并處理這些數據。

流式數據處理平臺。常見的 Flink、spark streaming 等，對于需求方來說，不可能總寫相應的代碼，來完成操作，這樣成本比較高。如何讓業(yè)務方盡可能簡單的、可配置的進行流式處理操作，這里主要是通過 Ark 流處理平臺完成，后面會重點介紹。

流式數據應用產品。貝殼擁有多個場景，如日志分析、數據挖掘等，每個場景對流式數據都有不同的需求，這就需要我們針對不同需求做不同的產品。

流式計算平臺及應用

1、數據直通車

 

 

數據直通車的架構：

數據接入層分為：

① 流數據接入：貝殼的流數據包括，ngx 日志、dig 埋點、mysql-binlog、tidb-binlog、其他業(yè)務日志等，把這些流數據通過 rsyslog、tidb-binlog-drainer、canal 等接入 kafka。

② 存儲接入：離線數據可能存在 Hive、Mysql、redis、HBase、TiDb 等多種數據存儲源，通過 spark 離線任務、TiSpark 把數據接入到更上層的數據輸出層。

流式數據接入之后，就可以做訂閱，如何 kafka、redis、ES(檢索操作)、HBase(大數據量 KV 操作)等，還可以做周期性同步，T+1 級別的數據，還有我們探索實現的準實時倉庫，目前可以做到 5 分鐘的延遲。

依賴于整個數據接入層、處理層、輸出層的工作，可以滿足：

① 建設完元數據之后，通過應用層就可以查詢到所有元數據的信息，并且知道元數據的變更情況(如果不知道元數據的變更情況，那么數據可是不準確的，和真實的數據是對應不上的)。通過數據直通車，就可以滿足我們的第一個挑戰(zhàn)，完成了所有元數據的管理�？梢约皶r、準確、高效的把數據接入到存儲層，或者為數據處理層準備好數據物料。

② 流數據訂閱

③ binlog 變更查詢等。

元數據與數據倉庫的能力：

 

 

簡單說下元數據管理服務，見右圖，主要通過 TiDB-binlog，獲取業(yè)務數據之后，把數據直接同步到 mysql，變更之后如果能自動處理就自動處理，如果不能自動處理就會發(fā)出告警，由人為來操作，這樣來保證業(yè)務數據是統(tǒng)一的，同時通過 WebUI 接口給用戶來查看，也可以通過 API 接口給其他業(yè)務來調用。比如后面要講的 Ark 平臺就可以直接調用 API 來使用流式數據。

準實時數倉，見左圖，引入 hudi 能力，通過 hudi 和 TiDB 可以準實時的把數據導入數據倉庫之中，用戶可以在 5 分鐘延遲的情況下來滿足對于業(yè)務數據的統(tǒng)計、監(jiān)控、分析的需求。

產品化展示：

 

 

這是平臺的首頁，第一個圖可以提供業(yè)務的執(zhí)行情況，第二個圖告訴我們數據的變更情況，第三個圖是整個業(yè)務成功的情況。

左邊欄：數據字典，元數據能力;實時查詢，準實時數倉查詢的能力;以及埋點管理，數據訂閱管理、數據變化查詢等。

通過數據直通車，解決了數據接入和元數據的管理問題。

 

 

目前可以做到 kafka 集群、埋點 dig、Mysql binlog、七層日志的元數據管理。

2、Ark 流處理平臺

 

 

Ark 整體架構：

引擎層：

① 把數據接入到 Source 源，如 kafka、binlog、dig 等。

② 數據接入之后，在引擎層進行處理，主要方式有三種：Stream SQL、實時規(guī)則匹配、通用模板，其底層依賴于 Spark Streaming 和 Flink。

③ 最終可以把數據輸出到 Sink 中，如： Druid.io 、ES、kafka、HBase 等，這時用戶可以直接調用。

計算平臺層：

通過封裝的方式來構建計算平臺，計算平臺主要通過這樣幾件事兒來完成穩(wěn)定性和通用性的需求，第一個是任務管控，需要管理好我們的任務，如何調度我們的任務，第二個是調優(yōu)診斷，有些用戶寫的任務可能不是特別完善，我們可以自動判斷他的任務是否需要優(yōu)化，并給出優(yōu)化建議，第三個可以引入 Databus 中的數據進行處理和使用，第四個是 SQL IDE，我們會盡可能多的生成 SQL，讓用戶盡可能寫一些少的配置，來應用 Ark 平臺，最后就是監(jiān)控報警，監(jiān)控整個任務的運行情況和延遲情況。

應用層：

通過 API 把我們 Ark 平臺的能力輸出出去：

① 數據清洗
② 實時大屏
③ 實時特征
④ 推薦營銷
⑤ 安全風控

還有其他的一些應用，以及后面會講到的天眼平臺，通過對日志的流式處理統(tǒng)一化及產品化滿足日志的各種訴求。

這就是整個 Ark 流處理平臺提供的能力。

Ark 能力接口：

 

 

數據流(包括日志流、七層日志、mysql、埋點、kafka 集群等)通過 Ark 平臺可以把數據清洗到多個分析引擎中，并且可以通過 TiDB、HBase、redis 做關聯，根據不同的需求把數據關聯到不同的存儲分析引擎中。

產品化展示：

 

 

這個是 SQL IDE 的能力，90% 的 SQL 都是自動生成的，大家只需要配置 m3db 地址，處理的類型等，就可以直接應用 Ark 流處理平臺。這樣就降低了很大的代價，因為 sql 的接入度是最強的。

 

 

這個是 Ark 流處理平臺的首頁，我們簡單介紹一下產品的能力特點：

豐富的應用表達方式
計算結果實時可視化
接入全量流數據源
資源管理 & 調優(yōu)診斷

3、天眼

 

 

傳統(tǒng)的方式，日志接入到 kafka，通過 spark streaming 或者 Apache flink，解析到 druid/es/hive 中來做分析，每次業(yè)務方都是按需來做這些事情，自己做數據清洗，自己在做應用，非常

繁瑣耗時，為了解決這個問題，我們把這些步驟集成到了一個產品天眼中。

 

天眼架構：

數據采集：所有的業(yè)務日志、訪問日志、設備日志以及第三方日志，Metrics 上報，SDK 埋點數據，Agent 數據，都可以通過 Databus 接入到數據處理層，然后再按需放入 Druid.io 、HDFS、ES、Hive、Mysql 中，再通過查詢引擎，可以做到檢索、統(tǒng)計報表、可視化、數據分析、監(jiān)控報警，最終根據數據采集、數據處理、數據服務三層的能力抽象出來多個數據應用，天眼可以做可視化分析、全鏈路監(jiān)控、業(yè)務監(jiān)控、故障管理，以及常見的數據管理、檢索、報警，和開放的 API，讓日志可以做到多種方式的應用到不同的場景。

產品化展示：

 

 

這是天眼的界面，包括實時 QPS 排名，以及多個業(yè)務方的域名，點擊之后可以看到對應域名的整個實時大盤。左邊欄為天眼能力的列表，通過我們的數據直通車、Ark 平臺，對數據日志處理做了一站式的集成和能力的輸出。

總結

 

 

① 做流數據處理，一定要先把流數據字典能力做出來，只有一個清晰的、完整的、可視的流數據字典能力才能讓流數據應用的更好，方便用戶的查詢。

② 豐富的流處理能力，通過產品化的封裝，比如 Spark streaming 和 Flink 有多種流處理能力，通過 Ark 封裝，用戶可以更簡易、自主的配置。

③ 多場景適應能力，根據各種場景，把基礎層提供的數據能力，做一個產品化的封裝，滿足不同場景應用的能力。除了剛剛講的天眼日志分析外，流式處理還有各種的應用，如 AI 對實時的數據挖掘，實時的用戶畫像等。

今天主要為大家分享了貝殼找房的三個平臺，以及流式數據處理的挑戰(zhàn)和一些實戰(zhàn)的經驗。謝謝大家。

介紹：趙國賢，貝殼大數據架構團隊負責人。

標簽： 流式數據的平臺 流式數據處理

版權申明：本站文章部分自網絡，如有侵權，請聯系：west999com@outlook.com
特別注意：本站所有轉載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權歸原作者所有，如需使用，請與原作者聯系。