關於所謂大數據的一些疑惑

0.如今業界有相對成熟的OLAP和OLTP統一解決方案嗎？相似地TiDB感受都嚴格的限制了業務場景。若是沒有，OLAP和OLTP的統一會是將來的方向和趨勢嗎？會達到mysql或者oracle級別的流行趨勢嗎？若是不能，須要把歷史數據存在倉庫，短時間數據供OLAP,實時數據或者中間表結果表供OLTP，多套數據重複粗放並存？

1.在一個WEB系統中，運營方或業務方直接生成一條SQL或者經過組件提交在後端生成任務JAR，提交到spark，flink集羣，等待結果返回至前端渲染。只有我一我的才強烈想要這種功能嗎？沒有這種功能，是由於有OLAP方案嗎，仍是業務特徵不夠典型？

2.實時計算和離線計算的涇渭分明在spark和flink業已成熟的今天，在技術上已經不存在了。但在業務上呢？隨着業務愈來愈多，T1的方案在凌晨短短的幾個小時窗口可否按時完成（還不談數據延遲）？業務方每個需求都要生成中間表結果表？

3.我的以爲對於大數據技術人員最大的挑戰在於技術選型。相對於WEB開發，哪怕在如今動輒不吹點高併發大流量分佈式都很差意思聊天的今天，除了分佈式事務尚有爭議之外，分佈式鎖，分佈式緩存，擊穿，雪崩，淘汰算法，分佈式惟一健，分庫，分表，讀寫分離，限流，熔斷，降級，微服務都有了比較成熟的公認解決方案。更別說spring套裝一統江湖的野心。但在大數據領域，在各個細分方向都並無通吃的解決方案。每個技術方案都有側重點，不能包打全場。不少狀況是，某種技術BAT在用，我朋友的公司在用，據說還不錯，看官方文檔性能很好。如何根據實際業務場景找到合適的技術方案，是技術，經驗，合做，試錯的結晶。如今的時代，對技術廣度和深度都有很高的要求。


4.敏捷性。針對運營方或者業務方式的某一個需求，好比監控預警需求，可自定義數據源，目標，事件，觸發，臨界點，下游等等，自行獲得結果。而無需技術人員現編碼。

5.脫離了實際場景談性能都是耍流氓。特別針對大數據存儲領域。

6.ETL是髒活累活，不容易出成果。但以爲沒有必要專門針對此搞一個職位。

7.除了BATMD等一二三線大廠，世面上絕大多數公司大談大數據，機器學習，人工智能，重災區是區域鏈（最近發現今年重慶這邊區域鏈又死灰復燃了）。請優雅的保持微笑。 

 

8.多大數據纔算大數據啊？TB級？數據質量的兼顧呢？

 

9.不少狀況下爲了大數據而大數據。