給王凌打Call的，原來是神奇的智能湖倉

“爺青回”

“我們只是老了，並沒有死。”

譚老師作為老粉，熱烈慶祝“甜心教主”王❤凌成為現象級翻紅頂流。

只要地球不爆炸，她的數據就一個都不能丟，還得用好了。

那為王❤凌從頭開發一套大數據與智能系統吧？

答案，沒必要。

不能把精力花在和IT基礎設施你死我活地纏鬥中。

就好比，當你的目的是去開會，那就不能去搭建會議室。

所以，這邊建議電視台：

把所有數據放到公有云上，使用無服務器架構（Serverless），將項目命名為 ：

“王❤凌老粉打Call數據項目”

每一家雲廠商都能拿出足夠的資料來證明自己的產品才是最好的，我們不在此處爭論。

方案技術選型上，一步到位，挑選一朵最大的，全球部署的公有云，方便❤凌文化出海。

用亞馬遜公有云，全方位無死角給❤凌打Call。

首先，王❤凌的視頻，音頻，電視劇，演唱會等大批量歷史數據，不存放在本地IDC上。

現在疫情，供應鏈緊張，硬件採購週期太長，電視台的審批流程也太長，不能等。

直接將❤凌的所有數據妥善存儲在Amazon S3 數據湖中。

不同種類的數據都能存，量大量少都能存，而且不會丟，永遠在數據湖裏，安全，放心。

技術上，這些文件存進S3數據湖自動成為數據API，方便調用，標準一致，取用方便。

怪不得，有人稱S3為事實上的雲計算對象存儲標準。

沒有數據指導的業務，怎麼可能做好？

領導着急看數，數據分析人員更着急，這個情況不允許發生，立刻配備雲數據倉庫Amazon Redshift。

聯合查詢的功能不能少：

比如，某電視台數據分析專家想查手機APP平台和大屏電視機頂盒觀看平台的用户之間的聯繫。

Redshift聯合查詢可以直接從手機App平台（已入湖），大屏電視機頂盒平台（基於數據庫），獲取數據的聯繫。

晚上九點，晚飯後，某一批用户在電視上反覆觀看王❤凌現場舞蹈（產生的行為數據存在數據庫中，包括當時產生的很多標籤）。

然後，我們直接查詢一批用户在手機App中的觀看過和這些行為數據中的標籤相關的視頻（這些數據存在數據湖裏），比如標籤裏有“甜心教主” “電視劇”。

這兩類數據存放在不同的地方，一個在數據庫，一個在數據湖。如果之前沒看過相關視頻（“王❤凌男孩跳舞熱榜”），就向手機App端推送。

實時智能分析必不可少：

先將歷史數據和新鮮（實時）兩種數據同時接入雲數據倉庫Redshift。

Amazon Redshift ML 使數據分析師和數據庫開發人員可以在Redshift 數據倉庫中使用熟悉的 SQL 命令輕鬆創建、訓練和應用機器學習模型。

實時看板必不可少：

某電視台，沒有設置王❤凌線上投票，實在令人遺憾，氛圍感差些些。

建議電視台開展線上投票，並公開實時看板，讓全國粉絲瞭解投票熱度整體進展，即時知道投票效果。

所有產生的實時打榜數據，接入流式數據管道Amazon Kinesis，數據像水流一樣一直灌進來。
並不是所有人時時刻刻在打榜，水流有大有小，而無服務器架構的Kinesis可以基於水流的大小即時彈性擴縮，無需關心流量高峯低谷，安心接入。

Redshift創建流式物化視圖對接Kinesis，結合數據倉庫內歷史數據生成實時看板。

那些不能從電視台數據倉庫裏直接取數的外部團隊，比如，抖音和快手，辦法是電視台藉助Amazon Redshift Data Sharing的功能，將數據安全共享。

查詢併發高峯的時刻，Redshift併發擴展能力也能輕鬆應對。

總而言之，數據倉庫性能越高越好，價格越便宜越好。

這就要靠雲廠商的技術手段了，壓力給到亞馬遜雲科技這邊。

“王❤凌老粉打Call數據項目”項目，危險行為識別必不可少：

用日誌分析服務Amazon OpenSearch，做鏈路追蹤，監視黑產惡意刷榜，確保公平。

“王❤凌老粉打Call數據項目”項目，數據庫選型如下：

1. 如果王❤凌開直播，刷禮物的交易數據，先放入極致彈性的Amazon DynamoDB中，再將歷史數據同步到Redshift數據倉庫。

2. 手機APP用户瀏覽王❤凌視頻的行為，記錄等，也得存入非關係型數據庫DynamoDB中。

本方案，為突發狀況，準備了預案。

突發情況一：

突然，某天，要查詢一遍過去十年的王❤凌數據，可能幾十PB。

方法一：這種使用頻率極低，又要分析海量數據，成本還要低的查詢，就用Amazon Athena。

方法二，搭建一個Hadoop系統。但是，為了幹這件事情，耗費的人力物力非常可怕，從頭幹起大約兩個月。

在Athena裏，查詢按次按量計費，一定要查詢的話，這筆費用可以出。

突發情況二：

“王❤凌男孩跳舞熱榜”現象，讓人始料不及。跟風創作，大量上傳熱舞視頻。

實時處理這些視頻並提取特徵，為下一階段分析提供數據，得用什麼技術呢？

答案是，流式數據分析技術，Amazon Kinesis Analytics。

另外，歷史數據怎麼處理呢？

答案是，使用託管大數據平台Amazon EMR處理大規模歷史數據，為❤凌的每一個歷史視頻都打上標籤。同時EMR Serverless以極簡的開發來處理數據，同時實現最低的成本。

最後強調一句，亞馬遜雲科技Serverless無服務器架構，很黑科技。

“王❤凌老粉打Call數據項目”方案的技術選型部分就介紹完了。

有任何好的方案建議，歡迎留言交流。

初聽還是小學生，再聽已是社會人，支持❤凌，致我們逝去的青春。

（完）