導讀：埋點數據是數據分析、推薦、運營的基礎，低延時、穩定、高效的埋點數據流對提高用戶體驗有著非常重要的作用。而隨著流量的增大，埋點的增多，在大流量場景下，埋點數據流的建設和治理也面臨不同的挑戰。本文將介紹字節跳動在埋點數據流業務場景遇到的需求和挑戰，以及為了應對這些需求和挑戰在建設和治理過程中的具體實踐。主要包含以下幾個部分內容：
- 埋點數據流簡介
- 埋點數據流建設實踐
- 埋點數據流治理實踐
- 未來規劃
01
埋點數據流簡介
1. 埋點數據流在字節
埋點數據流主要處理的數據是埋點，埋點也叫Event Tracking，是數據和業務之間的橋梁，也是數據分析、推薦、運營的基石。
用戶在使用 App 、小程序、 Web 等各種線上應用時產生的行為數據主要通過埋點的形式進行采集上報，按不同的來源可以分為：
① 客戶端埋點
② Web端埋點
③ 服務端埋點
埋點通過埋點收集服務接收到MQ，經過一系列的Flink實時ETL對埋點進行數據標準化、數據清洗、數據字段擴充、實時風控反作弊等處理，最終分發到不同的下游。下游主要包括推薦、廣告、ABTest、行為分析系統、實時數倉、離線數倉等。因為埋點數據流處在整個數據處理鏈路的最上游，所以決定了“穩定性”是埋點數據流最為關注的一點。
2. 字節的埋點數據流規模
字節跳動埋點數據流的規模比較大，體現在以下幾個方面：
① 接入的業務數量很多，包括抖音、今日頭條、西瓜視頻、番茄小說在內的多個大大小小的App和服務，都接入了埋點數據流。
② 流量很大，當前字節跳動埋點數據流峰值流量超過1億每秒，每天處理超過萬億量級埋點，PB級數據存儲增量。
③ ETL任務規模體量較大，在多個機房部署了超過1000個Flink任務和超過1000個MQ Topic，使用了超過50萬Core CPU資源，單個任務最大超過12萬Core CPU，單個MQ Topic最大達到10000個partition。
在這么巨大的流量和任務規模下，埋點數據流主要處理的是哪些問題？我們來看幾個具體的業務場景。
3. 業務場景-UserAction ETL
在推薦場景中，由于埋點種類多、流量巨大，而推薦只關注其中部分埋點，因此需要通過UserAction ETL對埋點流進行處理，對這個場景來說有兩個需求點：
① 數據流的時效性
② ETL規則動態更新
為了提升下流推薦系統的處理效率，我們在數據流配置ETL規則對推薦關注的埋點進行過濾，并對字段進行刪減、映射、標準化等清洗處理，將埋點打上不同的動作類型標識，處理之后的埋點內部一般稱為UserAction。UserAction與服務端展現、Feature等數據會在推薦Joiner任務的分鐘級窗口中進行拼接處理，產出instance訓練樣本。
舉個例子：一個客戶端的文章點贊埋點，描述了一個用戶在某一個時間點對某一篇文章進行了點贊操作，這個埋點經過埋點收集服務進入ETL鏈路，通過UserAction ETL處理后，實時地進入推薦Joiner任務中拼接生成樣本，更新推薦模型，從而提升用戶的使用體驗。
如果產出UserAction數據的ETL鏈路出現比較大的延遲，就不能在拼接窗口內及時地完成訓練樣本的拼接，可能會導致用戶體驗下降。因此，對于推薦來說，數據流的時效性是比較強的需求。而推薦模型的迭代和產品埋點的變動都可能導致UserAction ETL規則的變動，如果我們把這個ETL規則硬編碼在代碼中，每次修改都需要升級代碼并重啟相關的Flink ETL任務，這樣會影響數據流的穩定性和數據的時效性，因此這個場景的另一個需求是ETL規則的動態更新。
4. 業務場景-數據分流
抖音的埋點Topic晚高峰超過一億每秒，而下游電商、直播、短視頻等不同業務關注的埋點都只是其中一部分。如果每個業務都分別使用一個Flink任務去消費抖音的全量埋點去過濾出自己關注的埋點，會消耗大量的計算資源，同時也會造成MQ集群帶寬扇出非常嚴重，影響MQ集群的穩定性。
因此我們提供了數據分流服務。如何實現？我們使用一個Flink任務去消費上游埋點Topic，通過在任務中配置分流規則的方式，將各個業務關注的埋點分流到下游的小Topic中提供給各業務消費，減少不必要的資源開銷，同時也降低了MQ集群出帶寬。
分流需求大多對SLA有一定要求，斷流和數據延遲可能會影響下流的推薦效果、廣告收入以及數據報表更新等。另外隨著業務的發展，實時數據需求日益增加，分流規則新增和修改變得非常頻繁，如果每次規則變動都需要修改代碼和重啟任務會對下游造成較大影響，因此在數據分流這個場景，規則的動態更新也是比較強的需求。
5. 業務場景-容災降級
另一個場景是容災降級。數據流容災首先考慮的是防止單個機房級別的故障導致埋點數據流完全不可用，因此埋點數據流需要支持多機房的容災部署。其次當出現機房級別的故障時，需要將故障機房的流量快速調度到可用機房實現服務的容災恢復，因此需要埋點數據流具備機房間快速切流的能力。
而數據流降級主要考慮的是埋點數據流容量不足以承載全部流量的場景，比如春晚活動、電商大促這類有較大突發流量的場景。為了保障鏈路的穩定性和可用性，需要服務具備主動或者被動的降級能力。
6. 埋點數據流遇到的挑戰
挑戰主要是流量大和業務多導致的。流量大服務規模就大，不僅會導致成本治理的問題，還會帶來單機故障多、性能瓶頸等因素引發的穩定性問題。而下游業務多、需求變化頻繁，推薦、廣告、實時數倉等下游業務對穩定性和實時性都有比較高的要求。
在流量大、業務多這樣的背景下，如何保障埋點數據流穩定性的同時降低成本、提高效率，是埋點數據流穩定性治理和成本治理面對的挑戰。
--
02
埋點數據流建設實踐
上文我們了解了埋點數據流的業務場景和面對的挑戰，接下來會介紹埋點數據流在ETL鏈路建設和容災與降級能力上的一些實踐。
1. ETL鏈路建設-發展歷程
埋點數據流ETL鏈路發展到現在主要經歷了三個階段。
第一個階段是2018年以前，業務需求快速迭代的早期階段。那時我們主要使用PyJStorm與基于Python/ target=_blank class=infotextkey>Python的規則引擎構建主要的流式處理鏈路。特點是比較靈活，可以快速支持業務的各種需求，伴隨著埋點量的快速上漲，PyJStorm暴露出很多穩定性和運維上的問題，性能也不足以支撐業務增長。2018年內部開始大力推廣Flink，并且針對大量舊任務使用PyJStorm的情況提供了PyJStorm到PyFlink的兼容適配，流式任務托管平臺的建設一定程度上也解決了流式任務運維管理問題，數據流ETL鏈路也在2018年全面遷移到了PyFlink，進入到Flink流式計算的新時代。
第二個階段是2018年到2020年，隨著流量的進一步上漲，PyFlink和kafka的性能瓶頸以及當時使用的JSON數據格式帶來的性能和數據質量問題紛紛顯現出來。與此同時，下流業務對數據延遲、數據質量的敏感程度與日俱增。我們不僅對一些痛點進行了針對性優化，還花費一年多的時間將整個ETL鏈路從PyFlink切換到JAVA Flink，使用基于Groovy的規則引擎替換了基于Python的規則引擎，使用Protobuf替代了JSON，新鏈路相比舊鏈路性能提升了數倍。同時大數據開發平臺和流量平臺的建設提升了埋點數據流在任務開發、ETL規則管理、埋點管理、多機房容災降級等多方面的能力。
第三個階段是從2021年開始至今，進一步提升數據流ETL鏈路的性能和穩定性，在滿足流量增長和需求增長的同時，降低資源成本和運維成本是這一階段的主要目標。我們主要從三個方面進行了優化。
① 優化了引擎性能，隨著流量和ETL規則的不斷增加，我們基于Groovy的規則引擎使用的資源也在不斷增加，所以基于Janino對規則引擎進行了重構，引擎的性能得到了十倍的提升。
② 基于流量平臺建設了一套比較完善的埋點治理體系，通過埋點下線、埋點管控、埋點采樣等手段降低埋點成本。
③ 將鏈路進行了分級，不同的等級的鏈路保障不同的SLA，在資源不足的情況下，優先保障高優鏈路。
接下來是我們2018至2020年之間埋點數據流ETL鏈路建設的一些具體實踐。
2. ETL鏈路建設-基于規則引擎的Flink ETL
在介紹業務場景時，提到我們一個主要的需求是ETL規則的動態更新，那么我們來看一下埋點數據流Flink ETL任務是如何基于規則引擎支持動態更新的，如何在不重啟任務的情況下，實時地更新上下游的Schema信息、規則的處理邏輯以及修改路由拓撲。
首先，我們在流量平臺上配置了上下游數據集的拓撲關系、Schema和ETL規則，然后通過ConfigCenter將這些元數據發送給Flink ETL Job，每個Flink ETL Job的TaskManager都有一個Meta Updater更新線程，更新線程每分鐘通過RPC請求從流量平臺拉取并更新相關的元數據，Source operator從MQ Topic中消費到的數據傳入ProcessFunction，根據MQ Topic對應的Schema信息反序列化為InputMessage，然后進入到規則引擎中，通過規則索引算法匹配出需要運行的規則，每條規則我們抽象為一個Filter模塊和一個Action模塊，Fliter和Action都支持UDF，Filter篩選命中后，會通過Action模塊對數據進行字段的映射和清洗，然后輸出到OutputMessage中，每條規則也指定了對應的下游數據集，路由信息也會一并寫出。
當OutputMessage輸出到Slink后，Slink根據其中的路由信息將數據發送到SlinkManager管理的不同的Client中，然后由對應的Client發送到下游的MQ中。
3. ETL鏈路建設-規則引擎
規則引擎為埋點數據流ETL鏈路提供了動態更新規則的能力，而埋點數據流Flink ETL Job使用的規則引擎也經歷了從Python到Groovy再到Janino的迭代。
由于Python腳本語言本身的靈活性，基于Python實現動態加載規則比較簡單。通過Compile函數可以將一段代碼片段編譯成字節代碼，再通過eval函數進行調用就可以實現。但Python規則引擎存在性能較弱、規則缺乏管理等問題。
遷移到Java Flink后，在流量平臺上統一管理運維ETL規則以及schema、數據集等元數據，用戶在流量平臺編輯相應的ETL規則，從前端發送到后端，經過一系列的校驗最終保存為邏輯規則。引擎會將這個邏輯規則編譯為實際執行的物理規則，基于Groovy的引擎通過GroovyClassLoader動態加載規則和對應的UDF。雖然Groovy引擎性能比Python引擎提升了多倍，但Groovy本身也存在額外的性能開銷，因此我們又借助Janino可以動態高效地編譯Java代碼直接執行的能力，將Groovy替換成了Janino，同時也將處理Protobuf數據時使用的DynamicMessage替換成了GeneratedMessage，整體性能提升了10倍。
除了規則引擎的迭代，我們在平臺側的測試發布和監控方面也做了很多建設。測試發布環節支持了規則的線下測試、線上調試，以及灰度發布的功能。監控環節支持了字段、規則、任務等不同粒度的異常監控，如規則的流量波動報警、任務的資源報警等。
4. ETL鏈路建設-Flink拆分任務
規則引擎的應用解決了埋點數據流ETL鏈路如何快速響應業務需求的問題，實現了ETL規則的動態更新，從而修改ETL規則不需要修改代碼和重啟任務。
但規則引擎本身的迭代、流量增長導致的資源擴容等場景，還是需要升級重啟Flink任務，導致下游斷流。
除了重啟斷流外，大任務還可能在重啟時遇到啟動慢、隊列資源不足或者資源碎片導致起不來等情況。
針對這些痛點我們上線了Flink拆分任務，本質上是將一個大任務拆分為一組子任務，每個子任務按比例去消費上游Topic的部分Partition，按相同的邏輯處理后再分別寫出到下游Topic。
舉個例子：上游Topic有200個Partition，我們在一站式開發平臺上去配置Flink拆分任務時只需要指定每個子任務的流量比例，每個子任務就能自動計算出它需要消費的topic partition區間，其余參數也支持按流量比例自動調整。
拆分任務的應用使得數據流除了規則粒度的灰度發布能力之外，還具備了Job粒度的灰度發布能力，升級擴容的時候不會發生斷流，上線的風險更可控。同時由于拆分任務的各子任務是獨立的，因此單個子任務出現反壓、Failover對下游的影響更小。另一個優點是，單個子任務的資源使用量更小，資源可以同時在多個隊列進行靈活的部署。
5. 容災與降級能力建設
說到ETL鏈路建設，埋點數據流在容災與降級能力建設方面也進行了一些實踐。
首先是容災能力的建設，埋點數據流在Flink, MQ, Yarn, HDFS等組件支持多機房容災的基礎上完成了多機房容災部署，并準備了多種流量調度的預案。
正常情況下流量會均勻打到多個機房，MQ在多個機房間同步，Flink ETL Job默認從本地MQ進行消費，如果某個機房出現故障，我們根據情況可以選擇通過配置下發的方式從客戶端將流量調度到其他非受災機房，也可以在CDN側將流量調度到其他非受災機房。埋點數據流ETL鏈路可以分鐘級地進入容災模式，迅速將故障機房的Flink Job切換到可用的機房。
其次是服務降級能力的建設，主要包含服務端降級策略和客戶端降級策略。服務端降級策略主要通過LB限流、客戶端進行退避重試的機制來實現，客戶端降級策略通過配置下發可以降低埋點的上報頻率。
舉個例子：在春晚活動中參與的用戶很多，口播期間更是有著非常巨大的流量洪峰，2021年春晚活動期間為了應對口播期間的流量洪峰，埋點數據流開啟了客戶端的降級策略，動態降低了一定比例用戶的埋點上報頻率，在口播期間不上報，口播結束后迅速恢復上報。在降級場景下，下游的指標計算是通過消費未降級用戶上報的埋點去估算整體指標。目前我們在此基礎上進行了優化，客戶端目前的降級策略可以更近一步地根據埋點的分級信息去保障高優的埋點不降級，這樣可以在活動場景下保障活動相關的埋點不降級的上報，支持下游指標的準確計算。
--
03
埋點數據流治理實踐
介紹完埋點數據流建設的實踐，接下來給大家分享的是埋點數據流治理方面的一些實踐。埋點數據流治理包含多個治理領域，比如穩定性、成本、埋點質量等，每個治理領域下面又有很多具體的治理項目。
比如在穩定性治理中我們通過優化減少了由于單機問題、MQ性能問題和混布問題等導致的各種穩定性問題；
成本治理方面，我們通過組件選型、性能優化、埋點治理等方式取得了顯著降本增效的成果；
埋點質量治理方面，我們對臟數據問題、埋點字段類型錯誤問題和埋點數據的丟失重復問題進行了監控和治理。
這次我們主要選取了其中部分治理項目和大家分享。
1. 單機問題優化-Flink BacklogRescale
Yarn單機問題導致Flink任務Failover、反壓、消費能力下降是比較常見的case。
單機問題的類型有很多：隊列負載不均、單機load高或者其他進程導致CPU負載高，以及一些硬件故障都可能導致Yarn單機問題。針對Yarn單機問題，我們從Flink和Yarn兩個層面分別進行了優化，最終使單機load高導致的數據延遲減少了80%以上。
首先是Flink層面的優化，在埋點數據流ETL場景中，為了減少不必要的網絡傳輸，我們的Partitioner主要采用的是Rescale Partitioner，而Rescale Partitioner會使用Round-Robin的方式發送數據到下游Channel中。由于單機問題可能導致下游個別Task反壓或者處理延遲從而引起反壓，而實際上在這個場景里面，數據從上游task發送到任何一個下游的Task都是可以的，合理的策略應該是根據下游的Task的處理能力去發送數據，而不是用Round-Robin方式。
另一方面我們注意到Flink Credit-Based flow control反壓機制中，可以用backlog size去判斷下游Task的處理負載，我們也就可以將Round Robin的發送方式修改為根據Channel的Backlog size信息，去選擇負載更低的下游Channel進行發送。這個Feature上線后，隊列的負載變得更加均衡，CPU的使用率也提升了10%。
2. 單機問題優化-Yarn優化
Yarn層面的優化，第一個是隊列資源層面，我們使用獨立的Label隊列可以避免高峰期被其他低優任務影響。
第二個是對于Yarn節點上的DataNode把帶寬打滿或者CPU使用比較高影響節點上埋點數據流Flink任務穩定性的情況，通過給DataNode進行網絡限速，CPU綁核等操作，避免了DataNode對Flink進程的影響。
第三個是Yarn反調度的策略，目前字節跳動Flink使用的Yarn Gang Scheduler會按條件約束選擇性地分配Yarn資源，在任務啟動時均衡的放置Container，但是由于時間的推移，流量的變化等各種因素，隊列還是會出現負載不均衡的情況，所以反調度策略就是為了解決這種負載不均衡而生的二次調度機制。
反調度策略中，Yarn會定期檢查不滿足原有約束的Container，并在這些Container所在節點上篩選出需要重新調度的Container返還給Flink Job Manager，然后Flink會重新調度這些Container，重新調度會按照原有的約束條件嘗試申請等量的可用資源，申請成功后再進行遷移。
另外，我們會針對一些頻繁出問題的節點把它們加入調度的黑名單，在調度的時候避免將container調度到這些節點。
3. MQ優化-Databus應用
在流量迅速增長的階段，埋點數據流Flink任務一開始是通過Kafka Connecter直接寫入Kafka。但由于任務處理的流量非常大，Flink任務中Sink并發比較多，導致批量發送的效率不高，Kafka集群寫入的請求量非常大。并且，由于每個Sink一個或多個Client，Client與Kafka之間建立的連接數也非常多，而Kafka由于Controller的性能瓶頸無法繼續擴容，所以為了緩解Kafka集群的壓力，埋點數據流的Flink任務引入了Databus組件。
Databus是一種以Agent方式部署在各個節點上的MQ寫入組件。Databus Agent可以配置多個Channel，每個Channel對應一個Kafka的Topic。Flink Job每個Task Manager里面的Sink會通過Unix Domain Socket的方式將數據發送到節點上Databus Agent的Channel里面，再由Databus將數據批量地發送到對應的Kafka Topic。由于一個節點上會有多個Task Manager，每個Task Manager都會先把數據發送到節點上的Databus Agent，Databus Agent中的每個Channel實際上聚合了節點上所有Task Manager寫往同一個Topic數據，因此批量發送的效率非常高，極大地降低了Kafka集群的寫入請求量，并且與Kafka集群之間建立的連接數也更少，通過Agent也能方便地設置數據壓縮算法，由于批量發送的原因壓縮效率比較高。在我們開啟了Zstd壓縮后，Kafka集群的寫入帶寬降低了37%，極大地緩解了Kafka集群的壓力。
4. MQ優化-Kafka遷移BMQ
在埋點數據流這種大流量場景下使用Kafka，會經常遇到Broker或者磁盤負載不均、磁盤壞掉等情況導致的穩定性問題，以及Kafka擴容、Broker替換等運維操作也會影響集群任務正常的讀寫性能，除此之外Kafka還有controller性能瓶頸、多機房容災部署成本高等缺點。
為了優化這些問題，BMQ這款字節跳動自研的存儲計算分離的MQ應運而生。BMQ的數據存儲使用了HDFS分布式存儲，每個Partition的數據切分為多個segment，每個segment對應一個HDFS文件，Proxy和Broker都是無狀態的，因此可以支持快速的擴縮容，并且由于沒有數據拷貝所以擴縮容操作也不會影響讀寫性能。
受益于HDFS已經建設得比較完善的多機房容災能力，BMQ多機房容災部署就變得非常簡單，數據同時寫入所有容災機房后再返回成功即可保障多機房容災。數據消費是在每個機房讀取本地的HDFS進行消費，減少了跨機房帶寬。除此之外，由于基于多機房HDFS存儲比Kafka集群多機房部署所需的副本更少，所以最終實現了單GB流量成本對比Kafka下降了50%的資源收益。
5. 成本治理-埋點治理
在埋點治理方面，通過對流量平臺的建設，提供了從埋點設計、埋點注冊、埋點驗證、埋點上報、埋點采樣、流式ETL處理，再到埋點下線的埋點全生命周期的管理能力。
6. 成本治理-埋點管控
目前字節跳動所有的產品都開啟了埋點管控。所有的埋點都需要在我們的流量平臺上注冊埋點元數據之后才能上報。而我們的埋點數據流ETL也只會處理已經注冊的埋點，這是從埋點接入流程上進行的管控。
在埋點上報環節，通過在流量平臺配置埋點的采樣率對指定的埋點進行采樣上報，在一些不需要統計全量埋點的場景能顯著地降低埋點的上報量。
對于已經上報的埋點，通過埋點血緣統計出已經沒有在使用的埋點，自動通知埋點負責人在流量平臺進行自助下線。埋點下線流程完成后會通過服務端動態下發配置到埋點SDK以及埋點數據流ETL任務中，確保未注冊的埋點在上報或者ETL環節被丟棄掉。還支持通過埋點黑名單的方式對一些異常的埋點進行動態的封禁。
7. 埋點治理-埋點分級
埋點分級主要是針對離線存儲成本進行優化，首先在流量平臺上對埋點進行分級，埋點數據流ETL任務會將分級信息寫入到埋點數據中。埋點數據在從MQ Dump到HDFS這個階段根據這些分級的信息將埋點數據寫入不同的HDFS分區路徑下。然后通過不同的Spark任務消費不同分級分區的HDFS數據寫入Hive Table。不同等級的分區可以優先保障高優埋點的產出，另外不同分區也可以配置不同的TTL，通過縮減低優數據的TTL節省了大量的存儲資源。
--
04
未來規劃
目前Flink能做到計算層面的流批一體，但計算和存儲的流批一體還在探索階段，接下來我們也會繼續關注社區的進展。另外我們會嘗試探索一些云原生的實時數據處理框架，嘗試解決資源動態rescale的問題，以此來提升資源利用率。最后是在一些高優鏈路上，我們希望保障更高的SLA，比如端到端的exactly-once語義。
相關技術實踐已經通過火山引擎數據中臺產品對外輸出，大家感興趣的話也可以登陸火山引擎的官網進行了解。
最后打個小廣告這是我們字節跳動數據平臺的官方公眾號，我們會在上面分享我們數據平臺的技術干貨、產品動態和招聘信息。
--
05
精彩問答
Q：業務方查不到自己的埋點數據或者和業務系統的埋點數據對比UV不對，字節跳動是否會遇到這種情況，你們排查的思路是怎樣的？
A：在埋點治理環節有講到，在字節跳動我們把埋點的整個生命周期都管理起來了，從埋點設計開始，到埋點先注冊后上報的管控流程。在埋點上報之前需要通過平臺提供的埋點驗證功能驗證埋點是否上報成功以及埋點字段跟它注冊的元數據是否是匹配的。我們通過這樣的流程可以很大程度上減少埋點上報缺失和埋點質量問題。
Q：中間隊列用MQ不用Kafka是出于什么樣的考慮？
A：如果是問我們為什么從Kafka切換到BMQ，可以了解一下Kafka和一些存儲計算分離MQ的對比如Apache Pulsar，通常來說存儲計算分離架構的MQ會具備更好的伸縮性以及不會因為數據復制帶來讀寫性能的下降，成本也會更低，會更貼近云原生的形態。
Q：埋點的數據質量治理還有什么好的例子嗎？
A：我們現在做的比較多的是埋點上報前的埋點質量治理，比如剛才提到了在上報前通過注冊埋點的信息開發完埋點后用驗證工具去做自動化測試以保障埋點開發的準確性和質量，上報后我們也會用一些離線工具對埋點質量進行監控，但從我們的經驗上來看，上報前埋點質量的把控會解決大部分的問題，上報后的埋點質量治理目前主要是離線的，也能解決一些場景的問題。
Q：埋點數據準確性怎么保障的？埋點數據處理的過程中是給到一個什么樣級別的保障？
A：目前我們的處理鏈路是基于Flink實現的，大多數場景是沒有開啟checkpoint，原因是我們的下游需求很多樣化，有的下游不接受數據的大量重復，有的下游不接受數據延遲，如果開checkpoint，會在任務Failover過程中有大量的數據重復和延遲，這個是下游沒有辦法接受的。我們通過SLA數據質量監控指標是可以觀測出整個鏈路各個環節的數據丟失率和重復率，通過SLA指標來反映和保障數據準確性。
今天的分享就到這里，謝謝大家。
閱讀更多技術干貨文章、下載講師PPT，請關注微信公眾號“DataFunTalk”。
分享嘉賓：劉石偉 字節跳動 埋點數據流技術負責人
編輯整理：Rissy 易顯智能科技
出品平臺：DataFunTalk
