簡介：本次分享主要有4塊內容，小打卡介紹，小打卡數倉場景簡介，小打卡數倉選型思路以及代表性案例分享。

小打卡架構師 申羨

本次分享主要有4塊內容，小打卡介紹，小打卡數倉場景簡介，小打卡數倉選型思路以及代表性案例分享。

首先介紹一下小打卡的業務場景，小打卡是當前領先的小程序興趣社區。在這里能快速發現你感興趣的圈子，加入圈子，有達人帶你玩轉各種興趣，有同好一起分享、一起交流、一起成長。2017年8月公司成立至今，小打卡服務了7000多萬用戶，聚集繪畫、瑜伽、健身、攝影、親子、閱讀、潮玩等品類500多萬個興趣圈子，產生了11億條內容，11億次點贊，兩億次評論。每天有數百萬用戶活躍在小打卡上，產生TB級的數據流入數倉。在這樣的場景下，數倉承載了哪些服務呢？

目前小打卡數倉主要支持的場景包括BI商業決策，數字化運營、推薦系統、監控系統等。BI方面，因為DataWorks易用性，結合小打卡業務特點，在復雜決策場景下提供多維立方體數據，業務人員通過QuickBI自由組合關心的維度、指標。簡單場景，進行基礎的sql培訓，幫助業務人員自身閉環，基本實現全員取數分析，極大地提升了工作效率。運營方面，提供分鐘級乃至實時的內容審核服務，掐斷問題內容過量傳播的風險。推薦方面，實現了對用戶行為的完整跟蹤。結合阿里云實時計算能力，近期完成了推薦系統的實時化，做到用戶行為秒級反饋，實現了對前端性能錯誤的全鏈路監控，事件級別流量可信度監控，以及核心業務流程的流量波動監控等。在數倉的開發維護中，依托DataWorks完備的工具，包含運維中心，智能監控、數據質量監控、數據管理、數據地圖等，以極小的代價實現了所有的需求，以個位數的開發人員滿足了500萬日活的產品。

在數倉選型時，我們充分調研了自建數倉和基于阿里云構建數倉的優劣。初期小打卡數據量不足100g，每日所需的計算資源不足10cu，對數倉的主要訴求是低費用成本及運維成本，開發敏捷，可擴展性高。于是從費用成本、運維成本、開發效率、靈活性等方面，做了自建數倉和依托阿里云構建數倉的調研。

費用成本方面，阿里云服務特點是初期線性，后期階梯，初期數據量小，所需計算資源小，適合按量付費，且可以使用阿里云提供的共享資源，成本極低。中后期隨著數據量的增加，按量付費的費用上升，可以選用阿里云的計算套餐，購買獨享資源。此后費用階梯化，不同的數據規模選用不同的計算套餐。自建服務，特點是初期重、后期線性，在數倉搭建初期就需要一套完整的服務，有大量的資源不是用于業務計算，費用較高，后期規模上升，需要線性的增長集群規模，費用也線性上升。

運維成本方面，阿里云服務幾乎沒有運維成本，集群可用性由阿里云保證，不需要自身投入運維，計算任務由可視化的運維中心，任務自動依賴。此外，阿里云可以保證數據安全，提供資源管控，數據治理等一系列的運維工具。自建服務，不管是集群還是任務，都需要較高的運維成本，需要專人持續對集群服務器進行運維，需要使用開源工具，配置任務依賴。復雜的依賴，開發效率低。此外要保證數據安全，進行資源管理等，都需要自己開發一套工具，一次性成本以及持續成本較高。

開發效率方面，阿里云服務提供線上IDE，一站式完成各種任務開發提交部署，非技術人員掌握簡單的sql，也能自主取數分析，自建服務需要自己完成任務開發，調度開發、個性開發等，非技術人員很難自主取數分析。

靈活性方面，阿里云服務支持云上彈性擴縮容，靈活方便。雖然早期工具層面的API開放有限，但近期已經開放出大量的API可以靈活的對資源和任務進行操作。自建服務，背靠開源生態，可以靈活的按照自己的需求進行開發，但資源的管理不夠靈活便捷，開發成本高。結合以上幾點，基于阿里云構建數倉，在開發人員成本，軟硬件成本都有明顯的優勢。從初期直到現在，基于阿里云構建的數倉服務都有極高的消費比。初期只有一個開發人員的情況下，可以快速地搭建起數倉系統，且費用成本極低。

目前每天有TB級的增量數據，數百萬DAU，數千個周期任務以及多條業務線，得益于DataWorks完備的工具鏈，使得開發人員僅需關心業務邏輯，只需個位數的數據團隊，就能支撐起全部服務。當然在這個過程中我們也遇到了一些挑戰，下面分享一下在數據量突增期間，保障數倉可用性的一些經驗以及總結。2月份日活突然翻了三倍，數倉整體產出時間延遲到早上10點以后，為迅速恢復數倉可用，直接將計算資源翻倍。雖然簡單粗放，但效果不錯，將整體產出時間提前到6:30左右，但核心任務的產出時間無法保證，高峰期計算資源利用率較低，因此必須對任務精細化管理，對資源使用率低的原因進行了定位并解決。

我們先定義了核心任務的判定規則，篩選出符合規則的任務，依托DataWorks運維中心的基線管理機制，將核心任務納入核心基線，通過基線的優先級，保證核心任務能優先得到資源、穩定產出。高峰期資源使用率較低，是由于使用了DataWorks的默認調度資源組，屬于搶占式資源，除了自身任務外，還會受到其他租戶的影響，造成任務調度的不及時，不穩定。因此購買了獨占式的自定義調度資源組，并將所有任務切換到自定義資源組調度，之后，核心任務可以保證穩定在2點前產出，數倉整體任務能在4:30產出完畢，但我們的數據量是周期性遞增，突發性波動的，如何保證數倉可用性問題不再發生，如何保證資源充裕的同時又不過量冗余呢？一方面利用DataWorks提供的資源使用情況可視化監控，結合對數據量變化的監控，資源的使用情況做到了可感知、可預判。另一方面，結合DataWorks提供的元數據表，以及資源優化功能，啟動了任務回收機制，改變了數倉任務只增不減，無效任務長期占用資源的現狀，但資源組升配仍然需要人工手動操作，這樣就會存在資源升級不及時的風險。希望后續可以支持自動彈性調整資源，防止數倉不可用。

下面給大家分享一下小打卡基于實時計算的推薦系統實時化。推薦系統實時化，使數倉具備了用戶行為實時反饋，內容特征實時更新，ab效果實時評估，推薦內容實時安全審核，內容質量實時把關等實時化能力。從以前的只能基于一天前的用戶行為數據，內容特征數據，為用戶提供推薦服務，變成基于秒級延遲的用戶行為數據，以及內容特征進行推薦。推薦內容風險審核，也可以從小時級10分鐘級進入秒級，業務調整空間，沖破了離線統計的桎梏，可以進行更廣闊的嘗試。

在推薦實時化后，產品結合實時化的能力，進行了諸多嘗試，經過多次迭代后，CTR從5%變成了8%~10%，實現了翻倍的提升。在實時任務開發中，為了提高任務的可用性，實現方式經歷了三個階段，以累計pv實時統計為例。
第一階段，依靠一個實時計算任務直接計算結果，一旦需要對任務重啟，就需要重跑一遍歷史全量數據，上游存儲介質需要永久存儲，追趕的時間很長，且期間提供的數據不可用。
第二階段，實時任務只計算增量部分，離線任務計算存量部分。再依靠Java服務，將兩部分數據整合，開發戰線拉得很長。
目前也就是第三階段，將整合增量數據以及存量數據的任務也交給了流計算處理。第一層流計算，負責計算增量數據。第二層流計算負責整合增量存量數據，也因此實時計算任務有了級聯關系，但目前實時計算開發平臺，將所有的任務平鋪管理，在某些需要對級聯任務統一運維的場景支持不太友好，希望后續可以支持可視化的依賴管理，以及級聯運維的，我們能迅速嘗試并落地實施數倉，得益于 Flink sql 強大的能力。 ?

目前我們的流計算任務百分百使用 Flink sql 開發完成，暫未涉及到 Flink sql 解決不了的場景。

謝謝大家！

更多大數據客戶實戰案例：https://developer.aliyun.com/article/772449

原文鏈接：https://developer.aliyun.com/article/777583?

版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。

總結

以上是生活随笔為你收集整理的小打卡基于阿里云构建企业级数仓的实践及总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。