淺談大數據平臺的建設思想及產品服務意識

大數據平臺的建設之路漫長、艱難，因此須要統一認知，達成一致的建設思想和目標；進行心理建設，讓你們作好充分的心理準備；充分認識平臺的特色，有正確的的產品和服務意識。

1. 初心、源動力

你們之前從事web開發或者學習web開發，使用的技術棧是servlet+jsp+tomcat，如今流行springboot+vue.js，爲何會這樣？

因爲軟件工程的複用思想，大量重複的、通用的工做，咱們都將其抽象出來，變成了通用開發組件、框架。

大數據技術在一個團隊或者一個公司應用到必定階段，必然進入到平臺階段。由於能夠對一些組件進行封裝、工具化，提升代碼複用和開發效率等。對內能夠給內部開發團隊使用，對外能夠給第三方組織開放大數據服務和能力。

2. 統一平臺的總體建設思路和目標

平臺建設須要培養跳出現象看本質的習慣和思惟。要結合實際的業務場景和用戶需求，不只從技術架構，更要從代價、收益、業務價值、易用性和可維護性等衆多角度進行綜合評估和取捨。

2.1 what?

大數據相關業務開發平臺，是給數據使用者提升方便的平臺、工具。

數據使用者包括：數據分析人員、數據管理人員、數據開發人員、數據運維人員等，不一樣角色對於平臺的需求是不同的。

數據分析人員須要元數據管理、BI自助分析、可視化展現等功能。

數據管理人員須要進行數據資產管理、數據治理等。

數據開發人員在數據分析的基礎手上，還須要數據集成開發環境、工做流調度等，不少公司內部的平臺純粹爲了開發者使用。

數據運維人員要進行集羣的搭建、運維等工做，因爲有了Cloudera、Hortonworks的Hadoop套件，不多有公司強調這方面的平臺組件管理工具。

2.2 target?

大數據平臺的目標是方便使用者，提高工做效率，實際產出了多少價值，下降平臺開發人員運維成本。

目前各家公司使用大數據技術的現狀：組件與大公司相比一個都很多，可是平臺的實際應用水平和所提供的服務時，這些平臺每每是極度原始和簡陋。

• 與大公司平臺成熟度的差距在哪裏？

  產品和服務形態。

好比小米與蘋果的差距？硬件差距相對沒那麼多，小米老是使用業界最早進的硬件，毛利率極低，更多的是軟實力的差距。

如何揚長避短：組件的深度、新技術的探索確實沒法跟大公司比，但本質的東西：平臺的價值、投入產出效益，產品和服務形態，能夠跟其餘公司対飈。特別是阿里雲，他爲了作到通用性，就沒辦法照顧不一樣行業、不一樣層次用戶的訴求。垂直領域的一些訴求，相對比較通用，相對能夠從產品和服務形態與其競爭，特別是當市場規模沒那麼大時，每每是大公司忽略的地方。如抖音、快手，如拼多多、融360，並非與BAT比拼技術能力，也是在比拼產品與服務能力。小公司在組件的使用上，並不會比大公司有那麼大的差距，像阿里雲專家對於多維分析，也沒有更好的解決方案。

• 平臺爲用戶
  1. 解決了哪些問題？
  2. 掃除了哪些障礙？
  3. 提高了多少工做效率？
  4. 產生了哪些附加價值？或者實際產出的價值？投入產出效益？
  • 更深層次
    • 平臺內部組件的橫向聯通能力
    • 業務流程上縱向貫穿打通上下游鏈路的能力

2.3 建設指導方針：四化建設

1. 組件工具化：組件維護、用戶應用開發
   1. SDK：權限控制、操做數據採集、流量監控、屏蔽一些高風險操做、簡化一些用戶的操做(kafka消費者中的偏移量)
   2. HBase SQL(Phoenix)

   3. 儘可能給用戶提供統一sql引擎

   4. 提供一些工具將這些組件、操做封裝起來。不只僅是爲了下降用戶的學習成本，也有助於屏蔽集羣的拓撲佈局、業務操做的命令細節、組件版本的兼容性問題等。

2. 工具平臺化：組件、工具、開發流程整合在一塊兒，統一管理，提供成體系的開發運維管理途徑。

   1. 經過規範開發流程，提升平臺總體的穩定性和可控性，進而提高運維和業務開發的效率。

   2. 哪些是能夠作、應該作也值得作的事情。

3. 平臺服務化：用戶想要的東西，以用戶體驗爲中心。用戶滿意是衡量服務水平的惟一標準。.

4. 平臺產品化
   1. 困境：
      1. 公司角度：團隊資源的投入產出比，對公司業務價值的產出貢獻。
      2. 團隊角度：作得越多錯得越多，服務越好負擔越重。
   2. 如何破？良好的產品形態來換取可衡量的價值產出才能打破。
5. 平臺的適用性：產品定位、服務對象、聚焦核心問題。
   1. 阿里雲的EMR，面向小白用戶，功能簡單。
   2. 企業內部業務開發團隊，業務需求更復雜。

• 一站到底 vs 通用組件建設、組合支持業務

在各類取捨、抉擇中度過，可能須要兩種方式結合。

3. 開發者如何培養正確的產品和服務意識

3.1 平臺服務能力的評估標準

對用戶產生價值。

用戶滿意、易用、可用、簡單、傻瓜。

• 職能定位？平臺+數據處理、上下游全鏈路通吃。
  • 劃分依據：相關係統和特定業務知識是否強關聯。
• 能力？打通上下游系統和業務流程。
  • 以工做流調度系統爲例，從觸發做業運行的角度，調度系統自身的能力包括：各類任務類型的支持、時間/依賴觸發能力的支持、任務計劃的編排管理能力、對任務執行流水、歷史記錄的管理。
  • 和上下游及周邊業務流程的相關能力：
    1. 後端集羣流量、負載的反饋控制能力
    2. 腳本集成開發環境的對接
    3. 與權限系統、數據訂閱系統的連通
    4. 和元數據系統的對接
    5. 與任務測試、發佈環境的對接
    6. 與報警、值班、監控系統的協同
    7. 和數據治理管理系統的協同

3.2 知足用戶的真正需求

• 提供（大）數據處理能力，一站式解決方案，核心服務：

1. 存儲
2. 計算
3. 展現

用戶並不關心具體的集羣、組件。

• 用戶在乎：

1. 高效、穩定、可靠的存儲，知足性能指標。底層存儲並不關心。
2. 高效低成本的開發業務。不太想鑽研各類計算框架
3. 方便、快速的查詢，結果便於理解和溝通，可以有效地支持業務決策。

在知足性能指標的前提下，儘量簡單、方便、易用，獲得想要的數據。

對於中小企業來講，根據業務場景，提供簡單、易行的解決方案，最起碼是封裝好的工具。

對於第三方用戶，主要訴求是幫助挖掘數據價值。

3.3 認清服務的代價，作好心理建設

• 提供服務這麼難，爲何咱們還要作？

基於用戶滿意是評判服務水平的惟一標準。在提供服務時，要有臥薪嚐膽的精神。

1. 由儉入奢易，由奢入儉難。用戶對服務質量的要求只會愈來愈高。
2. 服務口碑取決於服務最差的環節。木桶效應
3. 服務越多，支持的代價越高
4. 需求響應要疾如閃電，功能服務要天長地久。
5. 既要馬兒駝得多，又要馬兒不摔倒
6. 用戶的服務訴求各異，衆口難調。做爲服務提供方，咱們的時間在用戶看來可能並不值錢，而用戶的時間很值錢。

3.4 尋找解決服務代價問題的方案

產品簡單、易用，用戶不會犯錯。

• 路線選擇帶來的服務代價問題？

1. 通用型系統開發難點： 設計難度相對較大，系統成型慢，業務價值產出的壓力很大。
   • 前期妥善溝通方案，「通用+適度」定製，快速推動平臺的構建。
2. 組件服務式系統的挑戰（相對於一站到底的垂直系統）：各個系統之間的依賴關係相對複雜，迭代演進的時候負擔很大。
   • 各個服務組件模塊化、提供所依賴功能的插件封裝機制
   • 具有灰度發佈能力
3. 通用平臺的痛點：對具體業務場景定製程度較低、總體易用性相對較差、使用成本較高。
   • 便捷和通用是矛盾的。
   • 基線+定製，帶來的問題是須要維護多個版本，之前華爲的一些軟件業務線就是這麼幹的。

• 如何下降服務自身的代價？

1. 由儉入奢易，由奢入儉難。用戶對服務質量的要求只會愈來愈高。
   • QOS約定，用戶預期管理。統一認知
   • 向用戶提供：產品定義、路線計劃、已知問題列表、最佳實踐、FAQ等文檔，可參考阿里雲以及其餘開源、商業軟件。讓用戶提早知道服務的能力範圍，溝通或許更順暢。
2. 服務口碑取決於服務最差的環節。木桶效應
   • 管理好用戶的預期和引導用戶。
   • 少糾結過去、多放眼將來。
3. 服務越多，支持的代價越高
   • 運維手段工具化、最佳實踐文檔化。
   • 專家系統：幫助缺少經驗的用戶發現和診斷問題。
4. 需求響應要疾如閃電，功能服務要天長地久。快速迭代和穩定可靠是必然矛盾的。
   • 按期更新
   • 變動提早和用戶溝通
   • 灰度發佈和回滾方案
5. 既要馬兒駝得多，又要馬兒不摔倒
   • 預期管理之向上管理
6. 用戶的服務訴求各異，衆口難調。做爲服務提供方，咱們的時間在用戶看來可能並不值錢，而用戶的時間很值錢。
   • 本質上一致：讓用戶更好的使用大數據平臺。
   • 實現過程如何兼顧，是挑戰。尋找妥協點。

3.5 平臺的產品化思想

功能和服務作得好，還要考慮代價和收益。

3.5.1 從用戶體驗角度談產品設計

1. 別讓用戶有挫敗感。從小白角度去設計，好比數據採集。
2. 提供差別化、階梯化的產品服務。有這麼多子系統，也能夠設計一個簡化的、包含各個子系統功能的定製產品，幫助快速入手。
3. 構建反饋式的產品服務。但凡用戶作了一個動做，或者一件事情狀態發生了變化，要想辦法讓用戶獲得及時的信息反饋。
4. 確保產品實現可持續改進。用戶的使用狀況不能是黑盒，不然沒法改進產品。
   1. 性能監控
   2. 行爲監控：經過埋點
   3. 日誌分析：

3.5.2 從價值和利益的角度談產品思惟

To be or not to be, that is a question.

• 不一樣的層次

1. 是什麼、怎麼作、能不能作
2. 這麼作是爲何
3. 爲何必定要這麼作、有沒有別的解決方案
4. 這麼作值得嗎、作點別的事是否是收益更高

小結

大數據平臺的建設屬於費力不討好的事情，屬於看不見摸不着的事情，須要從頂層來考慮平臺的建設，須要平臺的開發人員沉下心、耐住性子，腳踏實地、一點點完善平臺的功能，利用當前的資源產生最大化的平臺價值。

參考文獻

• 《大數據平臺基礎架構指南》讀書筆記