根據(jù)數(shù)據(jù)應用的不同階段，我將從數(shù)據(jù)底層到最后應用，來談談那些數(shù)據(jù)人的必備技能。
1、大數(shù)據(jù)平臺
目前很火，數(shù)據(jù)源頭，各種炫酷新技術，搭建Hadoop、Hive、Spark、Kylin、Druid、Beam~，前提是你要懂Java，很多平臺都是用Java開發(fā)的。
目前很多企業(yè)都把數(shù)據(jù)采集下來了，對于傳統(tǒng)的業(yè)務數(shù)據(jù)，用傳統(tǒng)的數(shù)據(jù)是完全夠用的，可是對于用戶行為和點擊行為這些數(shù)據(jù)或者很多非結構化的數(shù)據(jù)，文本、圖像和文本類的，由于數(shù)據(jù)量太大，很多公司都不知道怎么進行存儲。
這里面要解決的是實時、近實時和離線的大數(shù)據(jù)框架如何搭建，各數(shù)據(jù)流之間如何耦合和解耦，如何進行容災、平臺穩(wěn)定、可用是需要重點考慮的。
我的感覺是：最近兩三年中，這塊人才還是很稀缺的，因為大數(shù)據(jù)概念炒作的這么厲害，很多企業(yè)都被忽悠說，我們也來開始進入大數(shù)據(jù)行業(yè)吧。進入的前提之一就是需要把數(shù)據(jù)存儲下來，特別是很多用戶行為方面的數(shù)據(jù)，對于業(yè)務的提升比較明顯的，如果你能很好的刻畫用戶，那么對你的產(chǎn)品設計、市場營銷、開發(fā)市場都是有幫助的?，F(xiàn)階段，很多公司都要做第一步：存儲更多的數(shù)據(jù)。這也是這塊人員流動性比較高的原因，都被高薪挖走了。
和傳統(tǒng)的SQL不同的是，針對大數(shù)據(jù)量的非結構式數(shù)據(jù)，我們所想的就是：用最廉價的成本存儲數(shù)據(jù)同時能夠達到容災、擴展性高、高性能、跨域，從目前來看，分布式已經(jīng)被證明是個很好的一個方式。
另外，云端會是個很好的方向，不是每個公司都養(yǎng)得起這么多這么貴的大數(shù)據(jù)平臺開發(fā)人員和運維人員OPS，從事這個行業(yè)的我們要有很好的危機意識，及時貢獻出自己的價值，積極主動的學習新技術、否則就可能被淘汰了。
此外，花點錢把數(shù)據(jù)托管給云服務提供商是對于創(chuàng)業(yè)公司或者一些傳統(tǒng)的企業(yè)來說是個很好的思路，這樣能夠最快速的確定數(shù)據(jù)對你的價值是什么，而不用采購這么多的服務器、雇傭這么多的運維人員和網(wǎng)站開發(fā)人員。
說了以上這些，主要是想給未來會從事這塊的人或者想存儲數(shù)據(jù)的公司一點方向。我自己不做這塊，體會不深，大家看看就行。
這塊工作最被吐槽的一點就是：Hive速度好慢，SQL查詢好慢，集群怎么又掛掉了，hadoop版本升級后，怎么數(shù)據(jù)跑出來不對了等等。
因此，在這個領域內(nèi)工作，需要有強大的攻堅能力，并且還需要有快速定位和解決bug的能力，因為有很多工具都是開源的。因為是開源的，所以你們懂得，各種坑爹，甚至出現(xiàn)無法向下兼容的情況，所以需要強大的Java開發(fā)能力。
如果想在這塊做的很好，還需要有整個系統(tǒng)架構的設計能力、比較的強的抗壓能力和解決問題的能力、資源收集的能力，可以打入開源社區(qū)，這樣就可以隨時follow最新的潮流和技術。
2、數(shù)據(jù)倉庫-ETL
確實做倉庫的人很辛苦，單單Oncall就會讓人望而卻步。有很多數(shù)據(jù)庫工程師，晚上睡覺的時候經(jīng)常被Oncall電話吵醒，因為數(shù)據(jù)流程出問題，需要第一時間去排查，是哪個數(shù)據(jù)源出問題，并且要立即解決，否則整個數(shù)據(jù)流程都會受到影響。
如果數(shù)據(jù)流程受到了影響，你就可能會被大領導一言不合叫到辦公室說：我要的數(shù)據(jù)怎么還沒有準備好，我的業(yè)務報表今天怎么沒有發(fā)出來。
通過上面這個情景，我們可以知道：這是個很重要的崗位，因為數(shù)據(jù)流程很重要，決定了數(shù)據(jù)從源頭雜亂無章的狀況，通過ETL之后變成了整齊的數(shù)據(jù)，這些整齊一致性的數(shù)據(jù)可以讓你很方便地把各業(yè)務的統(tǒng)計結果計算出來，并且能夠統(tǒng)一口徑。要不然就會變成有幾個部門，就有幾種統(tǒng)計結果，到時候A部門說業(yè)務增長了5%，B部門說業(yè)務漲了10%，OMG，到底信誰。
至少在以下幾點上，我覺得數(shù)據(jù)倉庫人員應該要做好：
a、數(shù)據(jù)字典的完整性，用的人都希望能夠清晰的知道這個字段的邏輯是什么。字段要保持很好的一致性，不要同樣一個字段在不同表里有不同的定義。
b、核心流程的穩(wěn)定性，不要讓每天訂單主表能夠使用的時間很不穩(wěn)定，有的時候很早，有的時候要中午才出來，如果不穩(wěn)定就會導致使用數(shù)據(jù)的人對你很沒有信心。
c、倉庫版本迭代不要過于頻繁，要保持不同版本之間的兼容性。不要做好了倉庫1.0，很快就把原來的推倒重來，變成了2.0。在數(shù)據(jù)倉庫中需要考慮到延續(xù)性，主表的變動不要太頻繁，否則使用的人會非常痛苦，好不容易才用習慣了1.0的表結構，沒辦法這么快進行切換。簡單地說，要能向下兼容。