按照數據應用的差異階段，我將從數據底層到最后應用，來談談那些數據人的必備技術。

1、大數據平臺

今朝很火，數據源頭，各類炫酷新技能，搭建Hadoop、Hive、Spark、Kylin、Druid、Beam~，前提是你要懂Java，許多平臺都是用Java開拓的。

今朝許多企業都把數據收羅下來了，對付傳統的業務數據，用傳統的數據是完全夠用的，臺灣代理服務器 韓國服務器，但是對付用戶行為和點擊行為這些數據可能許多非布局化的數據，文本、圖像和文本類的，由于數據量太大，許多公司都不知道怎么舉辦存儲。

這內里要辦理的是及時、近及時和離線的大數據框架如何搭建，各數據流之間如何耦合息爭耦，如何舉辦容災、平臺不變、可用是需要重點思量的。

我的感受是：最近兩三年中，這塊人才照舊很稀缺的，因為大數據觀念炒作的這么鋒利，許多企業都被忽悠說，我們也來開始進入大數據行業吧。進入的前提之一就是需要把數據存儲下來，出格是許多用戶行為方面的數據，對付業務的晉升較量明明的，假如你能很好的刻畫用戶，那么對你的產物設計、市場營銷、開拓市場都是有輔佐的?，F階段，許多公司都要做第一步：存儲更多的數據。這也是這塊人員活動性較量高的原因，都被高薪挖走了。

和傳統的SQL差異的是，針對大數據量的非布局式數據，我們所想的就是：用最便宜的本錢存儲數據同時可以或許到達容災、擴展性高、高機能、跨域，從今朝來看，漫衍式已經被證明是個很好的一個方法。

別的，云端會是個很好的偏向，不是每個公司都養得起這么多這么貴的大數據平臺開拓人員和運維人員OPS，從事這個行業的我們要有很好的危機意識，實時孝敬出本身的代價，努力主動的進修新技能、不然就大概被裁減了。

另外，花點錢把數據托管給云處事提供商是對付創業公司可能一些傳統的企業來說是個很好的思路，這樣可以或許最快速簡直定命據對你的代價是什么，而不消采購這么多的處事器、雇傭這么多的運維人員和網站開拓人員。

說了以上這些，主要是想給將來會從事這塊的人可能想存儲數據的公司一點偏向。我本身不做這塊，體會不深，各人看看就行。

這塊事情最被吐槽的一點就是：Hive速度好慢，SQL查詢好慢，集群怎么又掛掉了，hadoop版本進級后，怎么數據跑出來差池了等等。

因此，在這個規模內事情，需要有強大的攻堅本領，而且還需要有快速定位息爭決bug的本領，因為有許多東西都是開源的。因為是開源的，所以你們分明，各類坑爹，甚至呈現無法向下兼容的環境，所以需要強大的Java開拓本領。

假如想在這塊做的很好，還需要有整個系統架構的設計本領、較量的強的抗壓本領息爭決問題的本領、資源收集的本領，可以打入開源社區，這樣就可以隨時follow最新的潮水和技能。

2、數據客棧-ETL

確實做客棧的人很辛苦，單單Oncall就會讓人望而卻步。有很大都據庫工程師，晚上睡覺的時候常常被Oncall電話吵醒，因為數據流程出問題，需要第一時間去排查，是哪個數據源出問題，而且要當即辦理，不然整個數據流程城市受到影響。

假如數據流程受到了影響，你就大概會被大率領一言不合叫到辦公室說：我要的數據怎么還沒有籌備好，我的業務報表本日怎么沒有發出來。

通過上面這個情景，我們可以知道：這是個很重要的崗亭，因為數據流程很重要，抉擇了數據從源頭混亂無章的狀況，通過ETL之后釀成了整齊的數據，這些整齊一致性的數據可以讓你很利便地把各業務的統計功效計較出來，而且可以或許統一口徑。要否則就會釀成有幾個部分，就有幾種統計功效，到時候A部辯白業務增長了5%，B部辯白業務漲了10%，OMG，到底信誰。

至少在以下幾點上，我以為數據客棧人員應該要做好：

a、數據字典的完整性，用的人都但愿可以或許清晰的知道這個字段的邏輯是什么。字段要保持很好的一致性，不要同樣一個字段在差異內外有差異的界說。

b、焦點流程的不變性，不要讓天天訂單主表可以或許利用的時間很不不變，有的時候很早，有的時候要中午才出來，假如不不變就會導致利用數據的人對你很沒有信心。

c、客棧版本迭代不要過于頻繁，要保持差異版本之間的兼容性。不要做好了客棧1.0，很快就把本來的推倒重來，釀成了2.0。在數據客棧中需要思量到延續性，主表的變換不要太頻繁，不然利用的人會很是疾苦，好不容易才用習慣了1.0的表布局，沒步伐這么快舉辦切換。簡樸地說，要能向下兼容。