今天正好和以前的一個老朋友通了個電話，他在創(chuàng)業(yè)，其實(shí)做的還可以，業(yè)務(wù)發(fā)展的也不錯。但是做互聯(lián)網(wǎng)服務(wù)，尤其是內(nèi)容服務(wù)，不可避免的需要譬如推薦，搜索，精準(zhǔn)推送等功能，而這幾個功能，又比較依賴大數(shù)據(jù)和AI相關(guān)的體系。舉個最簡單的例子，獲取用戶訪問行為，然后做個協(xié)同，然后推薦時需要把用戶看過的內(nèi)容過濾掉，就這個可能就需要Flume,Kafka,流式引擎等，更別提然后還要?dú)w檔日志（或者進(jìn)入數(shù)倉）了。我以前就說，大數(shù)據(jù)是個流程和模式，不是一定要數(shù)據(jù)大才需要。
但是呢，他們這個階段有幾個地方非常尷尬：
- 對硬件資源成本非常敏感
- 沒有大數(shù)據(jù)/AI基礎(chǔ)，缺人缺硬件
【畢竟現(xiàn)在資本瘋狂的年代已經(jīng)過去，很多創(chuàng)業(yè)公司沒辦法大手筆的花錢了?！?/p>
他們用云，但是又用的很謹(jǐn)慎，因?yàn)椤?硬件資源成本】的賬單起伏對他們來說，太敏感，云廠商的各種付費(fèi)模式（按計算資源，按條數(shù)，按內(nèi)存，按存儲等等）讓他們躡手躡腳，本來就不太熟悉大數(shù)據(jù)，一不小心搞下，就花了幾千上萬，他們的工程師壓力太大了。還有就是云廠商提供的各種智能API接口，按調(diào)用次數(shù)付費(fèi)，工程師們壓力也很大，業(yè)務(wù)上來是開心，但是調(diào)用量上來了，費(fèi)用成本也上來了。
所以，他們其實(shí)需要的是：
- 硬件賬單是穩(wěn)定的，所以比如OSS/ECS就非常的好，使用時賬單很穩(wěn)定，而類似MaxCompute,ODPS，PAI這些，就非常不友好，你沒辦法控制好賬單，一個失誤可能就挺要命的。
- 因?yàn)榍懊娴膯栴}，就導(dǎo)致他們很難用云廠商提供的各種計算服務(wù)以及API。在創(chuàng)業(yè)初期，這些東西帶來的價值是小于成本的。但是他們又缺乏響應(yīng)的數(shù)據(jù)和AI的人才，他們可能相對充足的是Web研發(fā)工程師，所以傳統(tǒng)的Hadoop集群，組件太多了，Kafka,HDFS,Yarn，Zookeeper等等,每一個都需要學(xué)習(xí)和維護(hù)。
所以他們真正的需要的是一個基于ECS的開箱即用的“一把梭”的數(shù)據(jù)處理工具加云端的分布式存儲。
- OSS
- Compute Engine based on ECS
解決的痛點(diǎn)在哪呢？
- 成本穩(wěn)定。 你可以買一個T的OSS,然后要10個特定規(guī)格的ECS實(shí)例。這個價格是固定的，不會忽高忽低的。
- 不需要部署，服務(wù)提供方幫你部署好。
基于這個Compute Engine，研發(fā)經(jīng)過一定的學(xué)習(xí)，完成所有推薦系統(tǒng)，精準(zhǔn)營銷所需要的數(shù)據(jù)和AI需求，
所以你就知道為什么Databricks公司的那套Analysis的價值了吧。他妥妥的滿足了上面兩個需求。其實(shí)不僅僅是小公司，大公司也喜歡這樣，因?yàn)榇蠹叶枷矚g成本是穩(wěn)定的東西。
大家可能會好奇，難道你不需要數(shù)倉建設(shè)，需要Hive？ 提起大數(shù)據(jù)就提數(shù)倉是不對的，我之前寫過文章數(shù)據(jù)部門起步階段需要建立數(shù)倉么？里就提到，確實(shí)不需要，尤其是我前文提到的階段。我們只要能把數(shù)據(jù)寫入到OSS,然后通過ComputeEngine 加工，然后將數(shù)據(jù)寫會OSS,寫回到Redis/MySQL等業(yè)務(wù)常用的存儲引擎就可以了。That's ALL. 這個過程你可能做ETL，做流，做AI模型訓(xùn)練，其實(shí)已經(jīng)涵蓋了大部分訴求了。
總結(jié)下，中小企業(yè)要走好數(shù)據(jù)和AI，前期其實(shí)最好是使用一個“一把梭”工具，對于云廠商的功能，去使用那種穩(wěn)定付費(fèi)模式的，比如OSS存儲和ECS就夠了。這種在結(jié)合業(yè)務(wù)，同時最小化和穩(wěn)定化成本的模式，可以將價值極大化，避免承受太多成本壓力。
恩，看樣子我要寫一篇MLSQL Stack如何部署在阿里云，并且以O(shè)SS為存儲的文章了。
