背景

大數(shù)據(jù)時(shí)代，數(shù)據(jù)的重要性不言而喻，尤其對(duì)于互聯(lián)網(wǎng)公司，隨著業(yè)務(wù)的快速變化，商業(yè)模式的不斷創(chuàng)新、用戶體驗(yàn)個(gè)性化、實(shí)時(shí)化需求日益突出，海量數(shù)據(jù)實(shí)時(shí)處理在商業(yè)方面的需求越來(lái)越大。如何通過(guò)數(shù)據(jù)快速分析出用戶的行為，以便做出準(zhǔn)確的決策，越來(lái)越體現(xiàn)一個(gè)公司的價(jià)值。現(xiàn)階段對(duì)于實(shí)時(shí)數(shù)據(jù)的建設(shè)比較單一，主要存在以下問(wèn)題：

實(shí)時(shí)倉(cāng)庫(kù)建設(shè)不足，維度及指標(biāo)不夠豐富，無(wú)法快速滿足不同業(yè)務(wù)需求。

實(shí)時(shí)數(shù)據(jù)和離線數(shù)據(jù)對(duì)比不靈活，無(wú)法自動(dòng)化新增對(duì)比基期數(shù)據(jù)，且對(duì)比數(shù)據(jù)無(wú)法預(yù)先生產(chǎn)。

數(shù)據(jù)監(jiān)控不及時(shí)，一旦數(shù)據(jù)出現(xiàn)問(wèn)題而無(wú)法及時(shí)監(jiān)控到，就會(huì)影響業(yè)務(wù)分析決策。

因此，本文將基于美團(tuán)大交通實(shí)時(shí)數(shù)據(jù)產(chǎn)品，從面臨的挑戰(zhàn)、總體解決方案、數(shù)據(jù)設(shè)計(jì)架構(gòu)、后臺(tái)設(shè)計(jì)架構(gòu)等幾個(gè)方面，詳細(xì)介紹實(shí)時(shí)數(shù)據(jù)系統(tǒng)的整體建設(shè)思路。

挑戰(zhàn)

實(shí)時(shí)流數(shù)據(jù)來(lái)源系統(tǒng)較多，處理非常復(fù)雜，并且不同業(yè)務(wù)場(chǎng)景對(duì)實(shí)時(shí)數(shù)據(jù)的要求不同，因此在建設(shè)過(guò)程主要有以下挑戰(zhàn)：

如何在保證數(shù)據(jù)準(zhǔn)確性的前提下實(shí)現(xiàn)多實(shí)時(shí)流關(guān)聯(lián)；實(shí)時(shí)流出現(xiàn)延遲、亂序、重復(fù)時(shí)如何解決。 流式計(jì)算中通常需要將多個(gè)實(shí)時(shí)流按某些主鍵進(jìn)行關(guān)聯(lián)得到特定的實(shí)時(shí)數(shù)據(jù)，但不同于離線數(shù)據(jù)表關(guān)聯(lián)，實(shí)時(shí)流的到達(dá)是一個(gè)增量的過(guò)程，無(wú)法獲取實(shí)時(shí)流的全量數(shù)據(jù)，并且實(shí)時(shí)流的達(dá)到次序無(wú)法確定，因此在進(jìn)行關(guān)聯(lián)時(shí)需要考慮存儲(chǔ)一些中間狀態(tài)及下發(fā)策略問(wèn)題。

實(shí)時(shí)流可復(fù)用性，實(shí)時(shí)流的處理不能只為解決一個(gè)問(wèn)題，而是一類甚至幾類問(wèn)題，需要從業(yè)務(wù)角度對(duì)數(shù)據(jù)進(jìn)行抽象，分層建設(shè)，以快速滿足不同場(chǎng)景下對(duì)數(shù)據(jù)的要求。

中臺(tái)服務(wù)如何保證查詢性能、數(shù)據(jù)預(yù)警及數(shù)據(jù)安全。 實(shí)時(shí)數(shù)據(jù)指標(biāo)維度較為豐富，多維度聚合查詢場(chǎng)景對(duì)服務(wù)層的性能要求較高，需要服務(wù)層能夠支持較快的計(jì)算能力和響應(yīng)能力；同時(shí)數(shù)據(jù)出現(xiàn)問(wèn)題后，需要做好及時(shí)監(jiān)控并快速修復(fù)。

如何保證產(chǎn)品應(yīng)用需求個(gè)性化。 實(shí)時(shí)數(shù)據(jù)與離線數(shù)據(jù)對(duì)比不靈活，需要提供可配置方案，并能夠及時(shí)生產(chǎn)離線數(shù)據(jù)。

解決思路

我們?cè)诔浞质崂順I(yè)務(wù)需求的基礎(chǔ)上，重新對(duì)實(shí)時(shí)流進(jìn)行了建設(shè)，將實(shí)時(shí)數(shù)據(jù)分層建模，并對(duì)外提供統(tǒng)一的接口，保證數(shù)據(jù)同源同口徑；同時(shí)，在數(shù)據(jù)服務(wù)層，增加可配置信息模塊解決了配置信息不能自動(dòng)化的問(wèn)題，在數(shù)據(jù)處理策略上做了多線程處理、預(yù)計(jì)算、數(shù)據(jù)降級(jí)等優(yōu)化，在數(shù)據(jù)安全方面增加數(shù)據(jù)審計(jì)功能，更好地提升了產(chǎn)品的用戶體驗(yàn)。

總體方案

產(chǎn)品整體建設(shè)方案基于美團(tuán)技術(shù)平臺(tái)，總共分為源數(shù)據(jù)層、存儲(chǔ)層、服務(wù)層及WEB層，整體架構(gòu)如下所示：

• 源數(shù)據(jù)層：主要提供三部分?jǐn)?shù)據(jù)，實(shí)時(shí)數(shù)據(jù)、離線數(shù)據(jù)、配置信息、維度信息。
• 存儲(chǔ)層：源數(shù)據(jù)清洗后放入相應(yīng)的存儲(chǔ)引擎中，為服務(wù)層提供數(shù)據(jù)服務(wù)。
• 服務(wù)層：提供三部分功能，數(shù)據(jù)API服務(wù)、預(yù)計(jì)算服務(wù)、權(quán)限服務(wù)、數(shù)據(jù)審計(jì)服務(wù)。
• Web層：使用Echarts可視化數(shù)據(jù)。

數(shù)據(jù)層

數(shù)據(jù)架構(gòu)

依托于美團(tuán)提供的公共資源平臺(tái)，數(shù)據(jù)架構(gòu)按功能分為數(shù)據(jù)采集、數(shù)據(jù)處理、數(shù)據(jù)存儲(chǔ)、數(shù)據(jù)服務(wù)四層，如下所示：

數(shù)據(jù)采集

數(shù)據(jù)來(lái)源主要有兩種：業(yè)務(wù)上報(bào)的Log日志及數(shù)據(jù)庫(kù)Binlog日志。這些日志通過(guò)美團(tuán)日志中心進(jìn)行采集后存儲(chǔ)在消息中間件Kafka中，并按照不同的分類存儲(chǔ)在不同的Topic中，供下游訂閱。

數(shù)據(jù)處理

數(shù)據(jù)處理顧名思義，就是對(duì)采集的實(shí)時(shí)流進(jìn)行邏輯處理，按業(yè)務(wù)需求輸出對(duì)應(yīng)的實(shí)時(shí)數(shù)據(jù)，因此這一步驟是流式計(jì)算的關(guān)鍵，分兩步進(jìn)行：數(shù)據(jù)加工、數(shù)據(jù)推送。

數(shù)據(jù)加工：數(shù)據(jù)加工通常需要在流式計(jì)算系統(tǒng)中進(jìn)行，目前流行的流式處理系統(tǒng)主要有Storm、Spark Streaming系統(tǒng)及Flink系統(tǒng)，這些系統(tǒng)都能在不同的應(yīng)用場(chǎng)景下發(fā)揮很好處理能力，并各有優(yōu)缺點(diǎn)，如下圖所示：

|計(jì)算框架|吞吐量|延遲|傳輸保障|處理模式|成熟度| |:—:|:—:|:—:|:—:|:—:|:—:|:—:| |Storm |低|毫秒級(jí)|At least once|單條處理|成熟| |Spark Streaming |高|秒級(jí)|Exactly once|微批處理|成熟| |Flink |高|毫秒級(jí)|Exactly once|單條處理/微批處理|新興|

最終我們選擇Storm作為實(shí)時(shí)數(shù)據(jù)處理框架，并借助公司提供的通用組件來(lái)簡(jiǎn)化拓?fù)溟_發(fā)流程和重復(fù)代碼編碼。例如，組件MTSimpleLogBolt的主要功能是將Kafka中讀取的數(shù)據(jù)（Log or Binlog）解析成Java實(shí)體對(duì)象；組件StormConfHelper的功能是獲取Storm作業(yè)應(yīng)用配置信息。

數(shù)據(jù)推送：將處理好的數(shù)據(jù)推送到存儲(chǔ)引擎中。

數(shù)據(jù)存儲(chǔ)

數(shù)據(jù)加工完成后會(huì)被存儲(chǔ)到實(shí)時(shí)存儲(chǔ)引擎中，以提供給下游使用。目前常用的存儲(chǔ)引擎主要有MySQL、Druid、Elasticsearch、Redis、Tair比較如下：

存儲(chǔ)引擎優(yōu)點(diǎn)缺點(diǎn)

MySQL	使用簡(jiǎn)單，支持?jǐn)?shù)據(jù)量小	數(shù)據(jù)量大，對(duì)MySQL的壓力大,查詢性能慢
Druid	數(shù)據(jù)預(yù)計(jì)算	不支持精確查詢
Elasticsearch	查詢效率快，支持常用聚合操作；可以做到精確去重	查詢條件受限
Redis	內(nèi)存存儲(chǔ)KV，查詢效率高	寫入資源有限，不支持大數(shù)據(jù)量寫入
Tair	持久化和非持久化兩種緩存，查詢效率高	單節(jié)點(diǎn)性能比Redis較弱
Kylin	多維查詢預(yù)計(jì)算	不支持實(shí)時(shí)

綜上比較，由于實(shí)時(shí)數(shù)據(jù)量較大，且數(shù)據(jù)精度要求較高，因此我們最終選擇交易存儲(chǔ)使用ES，流量存儲(chǔ)使用Druid，維度存儲(chǔ)使用Tair，中間數(shù)據(jù)存儲(chǔ)使用Redis；而離線數(shù)據(jù)，我們采用Hive和Kylin存儲(chǔ)。

數(shù)據(jù)服務(wù)

將存儲(chǔ)引擎數(shù)據(jù)統(tǒng)一對(duì)外提供查詢服務(wù)，支持不同業(yè)務(wù)應(yīng)用場(chǎng)景。

具體實(shí)現(xiàn)

實(shí)時(shí)流處理流程

整個(gè)數(shù)據(jù)層架構(gòu)上主要分為實(shí)時(shí)數(shù)據(jù)和離線數(shù)據(jù)兩部分：實(shí)時(shí)數(shù)據(jù)分為交易的Binlog日志和流量的Log日志，經(jīng)過(guò)Strom框架處理后寫入Kafka，再經(jīng)過(guò)DataLinkStreaming分別寫入ES和Druid；離線數(shù)據(jù)通過(guò)Hive處理寫入Kylin。

下圖所示為一條消息的處理流程：

兩個(gè)Topic分別是order_base（主要存放訂單基本信息：訂單id、訂單狀態(tài)、支付時(shí)間、票量、金額等）；order_biz（主要存放訂單的擴(kuò)展信息：訂單id、訂單類型、出發(fā)時(shí)間、到達(dá)時(shí)間、出發(fā)城市、到達(dá)城市）。我們最終要拿到一條包括上述全部?jī)?nèi)容的一條記錄。

具體例子：Bolt在處理一條記錄時(shí)，首先判斷這條記錄是base還是biz，如果是base則寫入緩存中base的Category中，如果是biz則寫入biz的Category中。以order_id為Key，如果是base則去和biz關(guān)聯(lián)，如果biz存在則代表能夠關(guān)聯(lián)上，這時(shí)發(fā)送關(guān)聯(lián)后的完整數(shù)據(jù)，同時(shí)刪除該主鍵（order_key）記錄；如果biz中不存在，則說(shuō)明沒(méi)關(guān)聯(lián)上，這時(shí)可能biz的數(shù)據(jù)延遲或者是丟失，為了保證主數(shù)據(jù)的準(zhǔn)確性，這時(shí)我們只發(fā)送base的數(shù)據(jù)，緩存中的數(shù)據(jù)保留不被刪除。如果這條消息是biz，則首先會(huì)更新緩存中該主鍵的biz記錄，然后去和base關(guān)聯(lián)，關(guān)聯(lián)上則發(fā)送同時(shí)刪除base中數(shù)據(jù)，否則不發(fā)送。此時(shí)我們會(huì)根據(jù)ES的Update特性去更新之前的數(shù)據(jù)。從現(xiàn)實(shí)效果來(lái)看保證了99.2%的數(shù)據(jù)完整性，符合預(yù)期。

數(shù)據(jù)寫入

在Topic2es的數(shù)據(jù)推送中，通過(guò)DataLinkString工具（底層Spark Streaming）實(shí)現(xiàn)了Kafka2es的微批次同步，一方面通過(guò)多并發(fā)batch寫入ES獲得了良好的吞吐，另一方面提供了5秒的實(shí)時(shí)寫入效率，保證了ES查詢的實(shí)時(shí)可見(jiàn)。同時(shí)我們也維護(hù)了Kafka的Offset，可以提供At lease once的同步服務(wù)，并結(jié)合ES的主鍵，可以做到Exactly once，有效解決了數(shù)據(jù)重復(fù)問(wèn)題。

ES索引設(shè)計(jì)及優(yōu)化

在數(shù)據(jù)寫入ES過(guò)程中，由于數(shù)據(jù)量大，索引時(shí)間區(qū)間長(zhǎng)，在建設(shè)索引時(shí)需要考慮合理設(shè)計(jì)保證查詢效率，因此主要有以下三點(diǎn)優(yōu)化：

• 寫入優(yōu)化 在通過(guò)DataLinkString寫入ES時(shí)，在集群可接受的范圍內(nèi)，數(shù)據(jù)Shuffle后再分組，增加Client并發(fā)數(shù)，提升寫入效率。
• 數(shù)據(jù)結(jié)構(gòu)化 根據(jù)需要設(shè)計(jì)了索引的模版，使用了最小的足夠用的數(shù)據(jù)類型。
• 按天建索引 通過(guò)模版按天建索引，避免影響磁盤IO效率，同時(shí)通過(guò)別名兼容搜索一致性。
• 設(shè)置合理的分片和副本數(shù) 如果分片數(shù)過(guò)少或過(guò)多都會(huì)導(dǎo)致檢索比較慢。分片數(shù)過(guò)多會(huì)導(dǎo)致檢索時(shí)打開比較多的文件，另外也會(huì)影響多臺(tái)服務(wù)器之間通訊。而分片數(shù)過(guò)少為導(dǎo)至單個(gè)分片索引過(guò)大，所以檢索速度慢。在確定分片數(shù)之前需要進(jìn)行單服務(wù)單索引單分片的測(cè)試。 我們根據(jù) 索引分片數(shù)=數(shù)據(jù)總量/單分片數(shù) 設(shè)置了合理的分片數(shù)。

實(shí)時(shí)數(shù)據(jù)倉(cāng)庫(kù)模型

整個(gè)實(shí)時(shí)數(shù)據(jù)開發(fā)遵循大交通實(shí)時(shí)數(shù)倉(cāng)的分層設(shè)計(jì)，在此也做一下簡(jiǎn)單介紹，實(shí)時(shí)數(shù)倉(cāng)架構(gòu)如下：

• ODS層：包含美團(tuán)頁(yè)面流量日志、模塊事件日志以及用戶操作的Binlog信息日志，是直接從業(yè)務(wù)系統(tǒng)采集過(guò)來(lái)的原始數(shù)據(jù)。
• 事實(shí)明細(xì)層：根據(jù)主題和業(yè)務(wù)過(guò)程，生成訂單事實(shí)和流量事實(shí)。
• 匯總層：對(duì)明細(xì)層的數(shù)據(jù)擴(kuò)展業(yè)務(wù)常用的維度信息，形成主題寬表。
• App層：針對(duì)不同應(yīng)用在匯總層基礎(chǔ)上加工擴(kuò)展的聚合數(shù)據(jù)，如火車票在搶票業(yè)務(wù)下的交易數(shù)據(jù)匯總信息。

規(guī)范建模后，業(yè)務(wù)需求來(lái)臨時(shí)，只需要在App層建模即可，底層數(shù)據(jù)統(tǒng)一維護(hù)。

中臺(tái)服務(wù)層

后臺(tái)服務(wù)主要實(shí)現(xiàn) 登陸驗(yàn)證和權(quán)限驗(yàn)證(UPM)、指標(biāo)邏輯計(jì)算和API、預(yù)計(jì)算服務(wù)、數(shù)據(jù)質(zhì)量監(jiān)控、數(shù)據(jù)審計(jì)功能。由于數(shù)據(jù)量大且實(shí)時(shí)性要求較高，在實(shí)現(xiàn)過(guò)程遇到如下挑戰(zhàn)：

• 如何保證查詢響應(yīng)性能。
• 服務(wù)發(fā)生故障后，數(shù)據(jù)降級(jí)方案。
• 數(shù)據(jù)監(jiān)控預(yù)警方案及數(shù)據(jù)出現(xiàn)問(wèn)題解決方案。

針對(duì)以上問(wèn)題，下面進(jìn)行一一詳述:

性能響應(yīng)優(yōu)化

服務(wù)層處理數(shù)據(jù)過(guò)程中，由于數(shù)據(jù)量大，在查詢時(shí)需要一定的響應(yīng)時(shí)間，所以在保證響應(yīng)性能方面，主要做了以下優(yōu)化：

項(xiàng)目初始由于數(shù)據(jù)量不是很大，采用單線程直接查詢ES，能夠滿足需求。

隨著節(jié)假日來(lái)臨，數(shù)據(jù)量大增，并行查詢?nèi)舜卧龆?#xff0c;查詢響應(yīng)變慢，無(wú)法快速響應(yīng)結(jié)果，因此引入緩存技術(shù)，將中間結(jié)果進(jìn)行緩存，并在緩存有效期內(nèi)，直接讀取緩存數(shù)據(jù)大大提高了時(shí)間效率；并且在此基礎(chǔ)上，引入Master-Worker多線程模式，將多指標(biāo)查詢拆分，并行查詢ES，使得查詢響應(yīng)大大提高。

雖然問(wèn)題得到解決，但仍存在一個(gè)問(wèn)題，就是每次都是現(xiàn)查ES及部分中間緩存結(jié)果，尤其是第一次查詢，需要完全走ES，這樣就會(huì)讓第一個(gè)查詢數(shù)據(jù)的用戶體驗(yàn)較差，因此引入預(yù)計(jì)算服務(wù)，通過(guò)定時(shí)調(diào)度任務(wù)，將部分重要維度下的指標(biāo)進(jìn)行預(yù)計(jì)算放入緩存，用戶查詢時(shí)直接讀取緩存數(shù)據(jù)。而一些不常用的維度下的數(shù)據(jù)，采用的策略是，第一個(gè)用戶查詢時(shí)現(xiàn)查ES，并將結(jié)果數(shù)據(jù)預(yù)加載到緩存，后續(xù)所有用戶再次查詢直接讀緩存數(shù)據(jù)，這樣既能保證用戶體驗(yàn)，也不至于占用太多緩存空間。

數(shù)據(jù)降級(jí)方案

使用緩存避免不了出現(xiàn)一些問(wèn)題，比如緩存失效、緩存雪崩等問(wèn)題，針對(duì)緩存雪崩問(wèn)題，通過(guò)設(shè)置不同Key的過(guò)期時(shí)間能夠很好的解決；而對(duì)于緩存數(shù)據(jù)失效，我們有自己的數(shù)據(jù)降級(jí)方案，具體方案如下：

預(yù)計(jì)算數(shù)據(jù)會(huì)分別在Redis、Tair和本地緩存中存儲(chǔ)一份以保證查詢效率，當(dāng)查詢Redis數(shù)據(jù)不存在時(shí)，會(huì)去Tair中讀取數(shù)據(jù)，Tair也為空時(shí)，會(huì)讀取本地緩存，只有當(dāng)本地緩存數(shù)據(jù)也為空時(shí)，才會(huì)現(xiàn)查ES做聚合計(jì)算，這樣也會(huì)降低ES的查詢壓力。

數(shù)據(jù)監(jiān)控

實(shí)時(shí)監(jiān)控預(yù)警非常重要，在數(shù)據(jù)出現(xiàn)問(wèn)題時(shí)，一方面能夠及時(shí)通知我們快速定位修復(fù)數(shù)據(jù)，另一方面也能夠及時(shí)周知業(yè)務(wù)同學(xué)，避免做出錯(cuò)誤分析。基于此，我們做了兩方面的實(shí)時(shí)監(jiān)控，其一是對(duì)源實(shí)時(shí)流在Storm處理層面的監(jiān)控，確保源實(shí)時(shí)流正確生產(chǎn)；其二是對(duì)展示的匯總數(shù)據(jù)進(jìn)行監(jiān)控，確保產(chǎn)品展示指標(biāo)數(shù)據(jù)正常。 針對(duì)數(shù)據(jù)出現(xiàn)問(wèn)題預(yù)警，我們?cè)诮鉀Q方案上規(guī)范了流程：

監(jiān)控報(bào)警機(jī)制及時(shí)周知相關(guān)同學(xué)。

第一時(shí)間通過(guò)產(chǎn)品上方的黃條提示用戶哪些數(shù)據(jù)異常。

快速定位問(wèn)題，給出修復(fù)方案。

目前對(duì)于實(shí)時(shí)異常數(shù)據(jù)的修補(bǔ)，主要有兩種方法：

針對(duì)特殊情況的數(shù)據(jù)修補(bǔ)方案第一靈活指定Offset，重新消費(fèi)Kafka數(shù)據(jù)。

預(yù)留了Hive2es的準(zhǔn)實(shí)時(shí)重導(dǎo)功能,確保生產(chǎn)數(shù)據(jù)的準(zhǔn)確和完整。

數(shù)據(jù)安全

在以數(shù)據(jù)取勝的時(shí)代，數(shù)據(jù)的安全不言而喻，我們采用公司提供的UPM權(quán)限接口進(jìn)行二級(jí)權(quán)限管理并加入審計(jì)功能及水印功能，能夠準(zhǔn)確記錄用戶的所有訪問(wèn)以及操作記錄，并且將日志數(shù)據(jù)格式化到數(shù)據(jù)庫(kù)中，進(jìn)行實(shí)時(shí)監(jiān)控分析。

總結(jié)

實(shí)時(shí)數(shù)據(jù)可以為業(yè)務(wù)特定場(chǎng)景分析決策提供巨大支持，尤其對(duì)于大交通節(jié)假日及春運(yùn)期間。在大交通實(shí)時(shí)戰(zhàn)場(chǎng)沙盤產(chǎn)品化過(guò)程中，我們投入了大量的思考和實(shí)踐，主要取得以下收益：

可視化的產(chǎn)品，為業(yè)務(wù)方實(shí)時(shí)分析提供極大便利，取得較好的反饋。

優(yōu)化實(shí)時(shí)數(shù)據(jù)倉(cāng)庫(kù)建設(shè)，合理分層建模，規(guī)范命名設(shè)計(jì)，統(tǒng)一維度建設(shè)和指標(biāo)口徑，對(duì)外提供統(tǒng)一接口，保證數(shù)據(jù)規(guī)范準(zhǔn)確。

在Storm框架下實(shí)時(shí)開發(fā)和數(shù)據(jù)寫入方面積累了一定的經(jīng)驗(yàn)。

服務(wù)層支持可配置信息，可以靈活配置個(gè)性化信息。

服務(wù)層性能及獲取數(shù)據(jù)策略的優(yōu)化，為用戶帶來(lái)更好的產(chǎn)品體驗(yàn)。

加入我們

最后插播一個(gè)招聘廣告，我們是一群擅長(zhǎng)大數(shù)據(jù)領(lǐng)域數(shù)據(jù)建設(shè)、數(shù)倉(cāng)建設(shè)、數(shù)據(jù)治理及數(shù)據(jù)BI應(yīng)用建設(shè)的工程師，期待更多能手加入，感興趣的可以投遞個(gè)人簡(jiǎn)歷到郵箱：yangguang09#meituan.com，歡迎您的加入。

作者介紹

• 娣娣，美團(tuán)數(shù)據(jù)開發(fā)工程師，2015年加入美團(tuán)，從事數(shù)據(jù)倉(cāng)庫(kù)建設(shè)、大數(shù)據(jù)產(chǎn)品開發(fā)工作。
• 曉磊，美團(tuán)數(shù)據(jù)開發(fā)工程師，2017年加入美團(tuán)，從事數(shù)據(jù)倉(cāng)庫(kù)建設(shè)、大數(shù)據(jù)產(chǎn)品開發(fā)工作。

總結(jié)

以上是生活随笔為你收集整理的实时数据产品实践——美团大交通战场沙盘的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。