1. 數據入庫流程
一、規范數據入庫流程
規范化的操作流程是避免操作錯誤產生的有效手段。據此，對航空物探數據入庫過程中的數據質量檢查內容和方法進行了分析，歸納出系統檢查9項和拓撲檢查5項（表5-5）。考慮到在數據入庫過程中，需要給數據採集人員授予資料庫數據編輯和刪除許可權（以便編輯錄入的錯誤數，刪除導入的不正確數據），在編輯或刪除資料庫數據時，有可能錯誤地編輯或刪除已歸檔數據，破壞歸檔數據的完整性和正確性等因素，提出了航空物探資料庫入庫數據質量檢查的規范化流程（圖5-2）。
表5-5 入庫數據系統檢查和拓撲檢查
1）創建項目，在數據入庫前先創建項目，按項目導入或錄入數據。
2）入庫前系統檢查，導入或錄入的入庫數據必須通過系統的入庫前檢查（數據唯一性、數據類型、缺項檢查），才能保存到採集庫中。
3）數據進入採集庫後，須接受入庫後系統檢查。若是空間數據必須接受拓撲檢查，再與原數據文件進行逐位元組比較檢查，均通過後，進人工檢查。
4）人工檢查與人工復核，對項目概況數據、空間要素類數據（圖形和屬性）、文字數據、圖件數據、可製成圖件的對象類數據應進行人工檢查與人工復核。檢查方法是人工比對。該方法勞動強度大，檢查人員要有較強的責任心才能發現其中的錯誤。人工檢查與人工復核的工作內容相同，系統要求人工檢查與人工復核必須由不同人員完成，加強數據檢查力度，盡量消除人為因素造成的錯誤。
圖5-2 規范化的數據入庫流程
5）系統歸檔檢查，對入庫數據的非空欄位進行的檢查。系統歸檔檢查通過後，入庫數據可歸檔存入資料庫。
經測試，嚴格按照該數據入庫流程開展數據入庫工作。航空物探資料庫數據與入庫前原數據文件數據的一致性可達100%。
該流程將入庫數據與資料庫數據分離，單獨建立一個數據採集資料庫（簡稱「採集庫」），把待入庫數據暫存在採集庫中。入庫數據在採集庫中接受各項質量檢查和編輯，或刪除操作，直至達到數據入庫質量要求，歸檔進入資料庫（進入資料庫的數據除資料庫管理員外其他用戶是無權對其實施編輯或刪除操作的），保證資料庫數據的一致性和完整性，為整體提高航空物探資料庫的質量提供了保障。
二、規則化數據檢查方法
50多年來航空物探取得大量的基礎資料和成果資料，這些資料在地學基礎研究、油氣資源評價等領域發揮的重要作用日益顯現。人們越來越重視利用航空物探資料來解決所遇到的地質問題等，同時人們也很想了解所用資料的來源、質量等信息（如資料的測量年代、測量方法、儀器精度、飛行高度、定位精度，數據處理方法等），來評價問題解決的可信度。這也正是本信息系統建設者想要給用戶提供的。歷史已既成事實，許多與資料質量有關的信息，例如在使用數字收錄以前有不少項目的測量儀器精度、飛行高度、定位精度等現已處可尋。
過去的不足證明現在的進步，尊重歷史盡力適應未來的技術發展，是本信息系統建設所遵循的宗旨。因此，根據資料的實際情況，提出了入庫數據有效性檢查的規則化方法，較好地解決了不同年代資料信息不齊全的數據入庫質量檢查問題。
按照通常做法，在軟體代碼中直接編寫出每個資料庫表需要做檢查欄位的有效性檢查代碼。
航空物探信息系統建設
本系統採用規則化方法檢查入庫數據。在完成資料庫結構設計之後，針對每張資料庫表中每個欄位制定了入庫數據正確性的檢查規則，建立動態檢查規則表，針對不同的檢查規則編寫檢查函數，從資料庫中獲取被檢查表資料庫欄位的檢查規則，對入庫數據進行檢查的。規則化方法代碼實現的示例如下：
航空物探信息系統建設
系統檢查採用傳統檢查方法實現代碼量約15345行（表5-6），代碼開發工作量很大，且靈活性差，不利於後期代碼維護和擴展，如添加表或表添加檢查欄位後都需要對代碼進行重新修改和編譯。而本系統的規則化方法代碼量僅495行（表5-6），只有傳統檢查方法代碼的3.22%，且添加表或表添加檢查欄位後不需要修改代碼；用戶在數據入庫時，根據實際需要直接修改檢查規則表即可。
表5-6 系統檢查兩種實現方式代碼量對比表
2. 數據安全怎麼做，安全性更高
隨著大數據的蓬勃發展，大數據的安全問題越來越受到業界的重視。不久前，中國信息通信研究院發表了《大數據安全白皮書》，指出了當前大數據發展面臨的安全問題，並提出了促進大數據安全技術發展的具體建議。
白皮書認為，大數據已經對經濟運行機制、社會生活方式和國家治理能力產生深刻影響，需要從「大安全」的視角認識和解決大數據安全問題。無論是商業策略、社會治理還是國家戰略的制定，都越來越重視大數據的決策支撐能力。但業界同時也要看到，大數據是一把雙刃劍，大數據分析預測的結果對社會安全體系所產生的影響力和破壞力可能是無法預料與提前防範的。
大數據安全是涉及技術、法律、監管、社會治理等領域的綜合性問題，其影響范圍涵蓋國家安全、產業安全和個人合法權益。同時，大數據在數量規模、處理方式、應用理念等方面的革新，不僅會導致大數據平台自身安全需求發生變化，還將帶動數據安全防護理念隨之改變，同時引發對高水平隱私保護技術的需求和期待。
白皮書認為，大數據安全威脅滲透在數據生產、採集、處理和共享等方面，大數據產業鏈的各個環節，風險成因復雜交織；既有外部攻擊，也有內部泄露；既有技術漏洞，也有管理缺陷；既有新技術新模式觸發的新風險，也有傳統安全問題的持續觸發。對於未來大數據安全技術發展，白皮書給出了具體建議：
第一，站在總體安全觀的高度，應構建大數據安全綜合防禦體系
安全是發展的前提，必須全面提高大數據安全技術保障能力，進而構建貫穿大數據應用雲管端的綜合立體防禦體系，以滿足國家大數據戰略和市場應用的需求。一是建立覆蓋數據收集、傳輸、存儲、處理、共享、銷毀全生命周期的安全防護體系，綜合利用數據源驗證、大規模傳輸加密、非關系型資料庫加密存儲、隱私保護、數據交易安全、數據防泄露、追蹤溯源、數據銷毀等技術，與系統現有網路信息安全技術設施相結合，建立縱深的防禦體系；二是提升大數據平台本身的安全防禦能力，引入用戶和組件的身份認證、細粒度的訪問控制、數據操作安全審計、數據脫敏等隱私保護機制，從機制上防止數據的未授權訪問和泄露，同時增加大數據平台組件配置和運行過程中隱含的安全問題的關注，加強對平台緊急安全事件的響應能力；三是實現從被動防禦到主動檢測的轉變，藉助大數據分析、人工智慧等技術，實現自動化威脅識別、風險阻斷和攻擊溯源，從源頭上提升大數據安全防禦水平，提升對未知威脅的防禦能力和防禦效率。
3. 如何建立一個完整可用的安全大數據平台
「
要建立一個大數據系統，我們需要從數據流的源頭跟蹤到最後有價值的輸出，並在現有的Hadoop和大數據生態圈內根據實際需求挑選並整合各部分合適的組件來構建一個能夠支撐多種查詢和分析功能的系統平台。這其中既包括了對數據存儲的選擇，也涵蓋了數據線上和線下處理分離等方面的思考和權衡。此外，沒有任何一個引入大數據解決方案的商業應用在生產環境上承擔的起安全隱患。
1
計算框架篇
大數據的價值
只有在能指導人們做出有價值的決定時，數據才能體現其自身的價值。因此，大數據技術要服務於實際的用途，才是有意義的。一般來說，大數據可以從以下三個方面指導人們做出有價值的決定：
報表生成（比如根據用戶歷史點擊行為的跟蹤和綜合分析、 應用程序活躍程度和用戶粘性計算等）；
診斷分析（例如分析為何用戶粘性下降、根據日誌分析系統為何性能下降、垃圾郵件以及病毒的特徵檢測等）；
決策（例如個性化新聞閱讀或歌曲推薦、預測增加哪些功能能增加用戶粘性、幫助廣告主進行廣告精準投放、設定垃圾郵件和病毒攔截策略等）。
圖 1
進一步來看，大數據技術從以下三個方面解決了傳統技術難以達成的目標（如圖1）：
在歷史數據上的低延遲（互動式）查詢，目標是加快決策過程和時間， 例如分析一個站點為何變緩慢並嘗試修復它；
在實時數據上的低延遲查詢，目的是幫助用戶和應用程序在實時數據上做出決策， 例如實時檢測並阻攔病毒蠕蟲（一個病毒蠕蟲可以在1.3秒內攻擊1百萬台主機）；
更加精細高級的數據處理演算法，這可以幫助用戶做出「更好」的決策， 例如圖數據處理、異常點檢測、趨勢分析及其他機器學習演算法。
蛋糕模式
從將數據轉換成價值的角度來說，在Hadoop生態圈十年蓬勃成長的過程中，YARN和Spark這二者可以算得上是里程碑事件。Yarn的出現使得集群資源管理和數據處理流水線分離，大大革新並推動了大數據應用層面各種框架的發展（SQL on Hadoop框架, 流數據，圖數據，機器學習）。
它使得用戶不再受到MapRece開發模式的約束，而是可以創建種類更為豐富的分布式應用程序，並讓各類應用程序運行在統一的架構上，消除了為其他框架維護獨有資源的開銷。就好比一個多層蛋糕，下面兩層是HDFS和Yarn, 而MapRece就只是蛋糕上層的一根蠟燭而已，在蛋糕上還能插各式各樣的蠟燭。
在這一架構體系中，總體數據處理分析作業分三塊（圖2），在HBase上做互動式查詢（Apache Phoenix, Cloudera Impala等）， 在歷史數據集上編寫MapRece程序抑或利用Hive等做批處理業務， 另外對於實時流數據分析Apache Storm則會是一種標准選擇方案。
雖然Yarn的出現極大地豐富了Hadoop生態圈的應用場景，但仍存有兩個顯而易見的挑戰：一是在一個平台上需要維護三個開發堆棧；二是在不同框架內很難共享數據，比如很難在一個框架內對流數據做互動式查詢。這也意味著我們需要一個更為統一和支持更好抽象的計算框架的出現。
圖 2
一統江湖
Spark的出現使得批處理任務，互動式查詢，實時流數據處理被整合到一個統一的框架內（圖3），同時Spark和現有的開源生態系統也能夠很好地兼容（Hadoop, HDFS, Yarn, Hive, Flume）。 通過啟用內存分布數據集，優化迭代工作負載， 用戶能夠更簡單地操作數據，並在此基礎上開發更為精細的演算法，如機器學習和圖演算法等。
有三個最主要的原因促使Spark目前成為了時下最火的大數據開源社區（擁有超過來自200多個公司的800多個contributors）：
Spark可以擴展部署到超過8000節點並處理PB級別的數據，同時也提供了很多不錯的工具供應用開發者進行管理和部署；
Spark提供了一個互動式shell供開發者可以用Scala或者Python即時性試驗不同的功能；
Spark提供了很多內置函數使得開發者能夠比較容易地寫出低耦合的並且能夠並發執行的代碼，這樣開發人員就更能集中精力地為用戶提供更多的業務功能而不是花費時間在優化並行化代碼之上。
當然Spark也和當年的MapRece一樣不是萬靈葯，比如對實時性要求很高的流數據處理上Apache Storm還是被作為主流選擇， 因為Spark Streaming實際上是microbatch（將一個流數據按時間片切成batch,每個batch提交一個job）而不是事件觸發實時系統，所以雖然支持者們認為microbatch在系統延時性上貢獻並不多，但在生產環境中和Apache Storm相比還不是特別能滿足對低延時要求很高的應用場景。
比如在實踐過程中， 如果統計每條消息的平均處理時間，很容易達到毫秒級別，但一旦統計類似service assurance（確保某條消息在毫秒基本能被處理完成）的指標， 系統的瓶頸有時還是不能避免。
但同時我們不能不注意到，在許多用例當中，與流數據的交互以及和靜態數據集的結合是很有必要的, 例如我們需要在靜態數據集上進行分類器的模型計算，並在已有分類器模型的基礎上，對實時進入系統的流數據進行交互計算來判定類別。
由於Spark的系統設計對各類工作（批處理、流處理以及互動式工作）進行了一個共有抽象，並且生態圈內延伸出了許多豐富的庫（MLlib機器學習庫、SQL語言API、GraphX）, 使得用戶可以在每一批流數據上進行靈活的Spark相關操作，在開發上提供了許多便利。
Spark的成熟使得Hadoop生態圈在短短一年之間發生了翻天覆地的變化， Cloudera和Hortonworks紛紛加入了Spark陣營，而Hadoop項目群中除了Yarn之外已經沒有項目是必須的了（雖然Mesos已在一些場合替代了Yarn）, 因為就連HDFS，Spark都可以不依賴。但很多時候我們仍然需要像Impala這樣的依賴分布式文件系統的MPP解決方案並利用Hive管理文件到表的映射，因此Hadoop傳統生態圈依然有很強的生命力。
另外在這里簡要對比一下互動式分析任務中各類SQL on Hadoop框架，因為這也是我們在實際項目實施中經常遇到的問題。我們主要將注意力集中在Spark SQL, Impala和Hive on Tez上, 其中Spark SQL是三者之中歷史最短的，論文發表在15年的SIGMOD會議上， 原文對比了數據倉庫上不同類型的查詢在Shark（Spark最早對SQL介面提供的支持）、Spark SQL和Impala上的性能比較。
也就是說， 雖然Spark SQL在Shark的基礎上利用Catalyst optimizer在代碼生成上做了很多優化，但總體性能還是比不上Impala, 尤其是當做join操作的時候， Impala可以利用「predicate pushdown」更早對表進行選擇操作從而提高性能。
不過Spark SQL的Catalyst optimizer一直在持續優化中，相信未來會有更多更好的進展。Cloudera的Benchmark評測中Impala一直比其他SQL on Hadoop框架性能更加優越，但同時Hortonworks評測則指出雖然單個數據倉庫查詢Impala可以在很短的時間內完成，但是一旦並發多個查詢Hive on Tez的優勢就展示出來。另外Hive on Tez在SQL表達能力也要比Impala更強（主要是因為Impala的嵌套存儲模型導致的）， 因此根據不同的場景選取不同的解決方案是很有必要的。
圖 3
各領風騷抑或代有才人出？
近一年比較吸引人眼球的Apache Flink（與Spark一樣已有5年歷史，前身已經是柏林理工大學一個研究性項目，被其擁躉推崇為繼MapRece, Yarn，Spark之後第四代大數據分析處理框架）。 與Spark相反，Flink是一個真正的實時流數據處理系統，它將批處理看作是流數據的特例，同Spark一樣它也在嘗試建立一個統一的平台運行批量，流數據，互動式作業以及機器學習，圖演算法等應用。
Flink有一些設計思路是明顯區別於Spark的，一個典型的例子是內存管理，Flink從一開始就堅持自己精確的控制內存使用並且直接操作二進制數據，而Spark一直到1.5版本都還是試用java的內存管理來做數據緩存，這也導致了Spark很容易遭受OOM以及JVM GC帶來的性能損失。
但是從另外一個角度來說, Spark中的RDD在運行時被存成java objects的設計模式也大大降低了用戶編程設計門檻， 同時隨著Tungsten項目的引入，Spark現在也逐漸轉向自身的內存管理， 具體表現為Spark生態圈內從傳統的圍繞RDD（分布式java對象集合）為核心的開發逐漸轉向以DataFrame(分布式行對象集合)為核心。
總的來說，這兩個生態圈目前都在互相學習，Flink的設計基因更為超前一些，但Spark社區活躍度大很多，發展到目前毫無疑問是更為成熟的選擇，比如對數據源的支持（HBase, Cassandra, Parquet, JSON, ORC）更為豐富以及更為統一簡潔的計算表示。另一方面，Apache Flink作為一個由歐洲大陸發起的項目，目前已經擁有來自北美、歐洲以及亞洲的許多貢獻者，這是否能夠一改歐洲在開源世界中一貫的被動角色，我們將在未來拭目以待。
2
NoSQL資料庫篇
NoSQL資料庫在主流選擇上依舊集中在MongoDB, HBase和Cassandra這三者之間。在所有的NoSQL選擇中，用C 編寫的MongoDB幾乎應該是開發者最快也最易部署的選擇。MongoDB是一個面向文檔的資料庫，每個文檔／記錄／數據（包括爬取的網頁數據及其他大型對象如視頻等）是以一種BSON（Binary JSON）的二進制數據格式存儲, 這使得MongoDB並不需要事先定義任何模式, 也就是模式自由（可以把完全不同結構的記錄放在同一個資料庫里）。
MongoDB對於完全索引的支持在應用上是很方便的，同時也具備一般NoSQL分布式資料庫中可擴展，支持復制和故障恢復等功能。 MongoDB一般應用於高度伸縮性的緩存及大尺寸的JSON數據存儲業務中，但不能執行「JOIN」操作，而且數據佔用空間也比較大，最被用戶詬病的就是由於MongoDB提供的是資料庫級鎖粒度導致在一些情況下建索引操作會引發整個資料庫阻塞。一般來說，MongoDB完全可以滿足一些快速迭代的中小型項目的需求。
下面來主要談談Cassandra和HBase之間的比較選擇。Cassandra和HBase有著截然不同的基因血統。HBase和其底層依賴的系統架構源自於著名的Google FileSystem（發表於2003年）和Google BigTable設計（發表於2006年）， 其克服了HDFS注重吞吐量卻犧牲I/O的缺點，提供了一個存儲中間層使得用戶或者應用程序可以隨機讀寫數據。
具體來說，HBase的更新和刪除操作實際上是先發生在內存MemStore中， 當MemStore滿了以後會Flush到StoreFile, 之後當StoreFile文件數量增長到一定閾值後會觸發Compact合並操作，因此HBase的更新操作其實是不斷追加的操作，而最終所有更新和刪除數據的持久化操作都是在之後Compact過程中進行的。
這使得應用程序在向內存MemStore寫入數據後，所做的修改馬上就能得到反映，用戶讀到的數據絕不會是陳舊的數據，保證了I/O高性能和數據完全一致性； 另一方面來說， HBase基於Hadoop生態系統的基因就已經決定了他自身的高度可擴展性、容錯性。
在數據模型上，Cassandra和HBase類似實現了一個key-value提供面向列式存儲服務，其系統設計參考了 Amazon Dynamo (發表於2007年) 分布式哈希（DHT）的P2P結構（實際上大部分Cassandra的初始工作都是由兩位從Amazon的Dynamo組跳槽到Facebook的工程師完成)，同樣具有很高的可擴展性和容錯性等特點。
除此之外， 相對HBase的主從結構，Cassandra去中心化的P2P結構能夠更簡單地部署和維護，比如增加一台機器只需告知Cassandra系統新節點在哪，剩下的交給系統完成就行了。同時，Cassandra對多數據中心的支持也更好，如果需要在多個數據中心進行數據遷移Cassandra會是一個更優的選擇。
Eric Brewer教授提出的經典CAP理論認為任何基於網路的數據共享系統，最多隻能滿足數據一致性、可用性、分區容忍性三要素中的兩個要素。實際分布式系統的設計過程往往都是在一致性與可用性上進行取捨，相比於HBase數據完全一致性的系統設計，Cassandra選擇了在優先考慮數據可用性的基礎上讓用戶自己根據應用程序需求決定系統一致性級別。
比如：用戶可以配置QUONUM參數來決定系統需要幾個節點返回數據才能向客戶端做出響應，ONE指只要有一個節點返回數據就可以對客戶端做出響應，ALL指等於數據復制份數的所有節點都返回結果才能向客戶端做出響應，對於數據一致性要求不是特別高的可以選擇ONE，它是最快的一種方式。
從基因和發展歷史上來說，HBase更適合用做數據倉庫和大規模數據處理與分析（比如對網頁數據建立索引）， 而Cassandra則更適合用作實時事務和互動式查詢服務。Cassandra在國外市場佔有比例和發展要遠比國內紅火， 在不少權威測評網站上排名都已經超過了HBase。目前Apache Cassandra的商業化版本主要由軟體公司DataStax進行開發和銷售推廣。另外還有一些NoSQL分布式資料庫如Riak, CouchDB也都在各自支持的廠商推動下取得了不錯的發展。
雖然我們也考慮到了HBase在實際應用中的不便之處比如對二級索引的支持程度不夠（只支持通過單個行鍵訪問，通過行鍵的范圍查詢，全表掃描），不過在明略的大數據基礎平台上，目前整合的是依然是HBase。
理由也很簡單，HBase出身就與Hadoop的生態系統緊密集成，其能夠很容易與其他SQL on Hadoop框架（Cloudera Impala, Apache Phoenix, or Hive on Tez）進行整合，而不需要重新部署一套分布式資料庫系統，而且可以很方便地將同樣的數據內容在同一個生態系統中根據不同框架需要來變換存儲格式（比如存儲成Hive表或者Parquet格式）。
我們在很多項目中都有需要用到多種SQL on Hadoop框架，來應對不同應用場景的情況，也體會到了在同一生態系統下部署多種框架的簡便性。 但同時我們也遇到了一些問題， 因為HBase項目本身與HDFS和Zookeeper系統分別是由不同開源團隊進行維護的，所以在系統整合時我們需要先對HBase所依賴的其他模塊進行設置再對HBase進行配置，在一定程度上降低了系統維護的友好性。
目前我們也已經在考慮將Cassandra應用到一些新的客戶項目中，因為很多企業級的應用都需要將線上線下資料庫進行分離，HBase更適合存儲離線處理的結果和數據倉庫，而更適合用作實時事務和並發交互性能更好的Cassandra作為線上服務資料庫會是一種很好的選擇。
3
大數據安全篇
隨著越來越多各式各樣的數據被存儲在大數據系統中，任何對企業級數據的破壞都是災難性的，從侵犯隱私到監管違規，甚至會造成公司品牌的破壞並最終影響到股東收益。給大數據系統提供全面且有效的安全解決方案的需求已經十分迫切：
大數據系統存儲著許多重要且敏感的數據，這些數據是企業長久以來的財富
與大數據系統互動的外部系統是動態變化的，這會給系統引入新的安全隱患
在一個企業的內部，不同Business Units會用不同的方式與大數據系統進行交互，比如線上的系統會實時給集群推送數據、數據科學家團隊則需要分析存儲在數據倉庫內的歷史數據、運維團隊則會需要對大數據系統擁有管理許可權。
因此為了保護公司業務、客戶、財務和名譽免於被侵害，大數據系統運維團隊必須將系統安全高度提高到和其他遺留系統一樣的級別。同時大數據系統並不意味著引入大的安全隱患，通過精細完整的設計，仍然能夠把一些傳統的系統安全解決方案對接到最新的大數據集群系統中。
一般來說，一個完整的企業級安全框架包括五個部分：
Administration: 大數據集群系統的集中式管理，設定全局一致的安全策略
Authentication: 對用戶和系統的認證
Authorization：授權個人用戶和組對數據的訪問許可權
Audit：維護數據訪問的日誌記錄
Data Protection：數據脫敏和加密以達到保護數據的目的
系統管理員要能夠提供覆蓋以上五個部分的企業級安全基礎設施，否則任何一環的缺失都可能給整個系統引入安全性風險。
在大數據系統安全集中式管理平台這塊，由Hortonworks推出的開源項目Apache Ranger就可以十分全面地為用戶提供Hadoop生態圈的集中安全策略的管理，並解決授權(Authorization)和審計(Audit)。例如，運維管理員可以輕松地為個人用戶和組對文件、數據等的訪問策略，然後審計對數據源的訪問。
與Ranger提供相似功能的還有Cloudera推出的Apache Sentry項目，相比較而言Ranger的功能會更全面一些。
而在認證（Authentication）方面, 一種普遍採用的解決方案是將基於Kerberos的認證方案對接到企業內部的LDAP環境中， Kerberos也是唯一為Hadoop全面實施的驗證技術。
另外值得一提的是Apache Knox Gateway項目，與Ranger提高集群內部組件以及用戶互相訪問的安全不同，Knox提供的是Hadoop集群與外界的唯一交互介面，也就是說所有與集群交互的REST API都通過Knox處理。這樣，Knox就給大數據系統提供了一個很好的基於邊緣的安全（perimeter-based security）。
基於以上提到的五個安全指標和Hadoop生態圈安全相關的開源項目， 已經足已證明基於Hadoop的大數據平台我們是能夠構建一個集中、一致、全面且有效的安全解決方案。
我市再ITjob管網上面找的
4. 航班管家開放平台——打造航空鐵路出行行業的企業級SaaS服務平台
「 本項目案例由 航班管家 投遞並參與 由數據猿&上海大數據聯盟聯合推出的「行業盤點季之數智化轉型升級」大型主題策劃活動之《2021中國企業數智化轉型升級創新服務企業》榜單/獎項的評選。
航班管家開放平台是航空鐵路出行行業首個SaaS級服務平台，聚焦大交通出行服務行業數字化升級，基於民航局空管局授權的官方動態數據，整合航空、鐵路、場站、旅客、貨運等多維度數據，結合擁有自主知識產權的演算法模型與行業Know-how，面向行業提供多種數據服務產品和數據解決方案，賦能行業合作夥伴、幫助其提效降本。
如數字化程度有待提高的旅行社、票務代理、TMC、企業差旅部門等，用戶在其平台購票後，需要通過其他第三方平台查詢航班/列車動態信息，用戶體驗感和便利程度大大降低，航班管家面向這些企業，提供SaaS級產品【行程服務H5】，客戶可根據自身需求進行頁面個性化配置，然後將配置好的頁面直接嵌入自有APP、公眾號、小程序等產品中，方便用戶在自有平台完成購票、動態查詢等服務，形空乎成服務閉環，提高用塌擾戶體驗，同時降低企業開發成本。
面向數據分散在各個部門、協調難度大，但正在進行數字化轉型的航司、機場等企業，還有需要分析數據的金融、券商、媒體、院校、咨詢公司、研究機構等行業，航班管家提供【智數出行】服務，包括數據分析平台、可視化大屏、大數據分析報告等產品，分析行業數據、洞察行業發展，提供有價值的分析結果與行業洞見，以滿足行業日常工作及決策支撐需要，助力企業數字化轉型升級。
實施時間
開始時間：2021年1月初完成項目立項
里程碑節點：
2021年1月25日
·官網V1.0版本上線。
·華為雲上代碼部署，正式環境搭建完成。
2021年4月8日
·平台V1.0版團虧旦本上線，支持賬號認證、產品服務開通。
2021年5月31日
·平台V2.0版本上線，行程服務產品支持套餐包購買，H5版本官網、產品介紹頁上線。
·首批客戶上線，分貝通、公務之家、QQ瀏覽器、UC瀏覽器等。
2021年6月30日
·平台V3.0版本上線，官網全新改版、行程服務產品支持功能模塊可配置化、支持在線掃碼支付。
截止時間：2021年年8月底
依託於航班管家多年的數據積累及服務B端、C端用戶經驗總結，打造一站式開放平台，致力於為多種行業用戶提供民航、鐵路、航空貨運大交通數據及其衍生產品與服務，如行程服務H5、API介面、大數據分析報告、數據分析工具及可視化等，助力企業提升服務水平、降低成本、提高效率，並為企業決策提供輔助支持。
行程服務H5
為OTA/TMC/旅行社/企業差旅部門等，提供基於H5頁面的航空/鐵路行程全流程信息服務，企業可將H5頁面直接嵌入自有移動端產品中，如APP、公眾號、小程序，讓出行旅客/員工不再依賴其他第三方產品，在自有產品中即可掌握行程動態信息，方便旅客/員工合理安排規劃行程，提升出行體驗，提高服務滿意度，增強用戶黏性，同時降低企業開發維護成本。
API介面
為各類需要航班/列車動態信息、航班/列車准點率、飛機/列車基礎參數、機場/車站基礎設施信息及其他相關數據的企業，提供API介面服務。如用車行業，基於實時的航班/列車動態信息，做好機場/車站接送業務支持，合理安排車輛調度，提高服務效率；保險業，基於准點率數據，實現延誤險動態定價，基於航班/列車動態數據，自動判斷航班延誤/取消是否達到賠付標准，實現自動理賠，提高理賠效率；OTA，提供飛機/列車基礎參數數據，如機型、車型、座椅間距、 娛樂 設施配備等，供用戶在選擇航班時做參考，提升服務體驗感。
數據報告
基於航班管家多年的民航鐵路數據積累，分析民航鐵路交通運輸和旅客出行狀況，提供定期、專題等多種類型的專業分析報告，還可基於行業專家團隊能力提供深度行業咨詢服務，從整體上把握市場趨勢，為日常工作及生產經營決策提供支持。如為發動機製造商，圍繞機隊數據、飛機利用率、停場時長等指標，提供機隊分析報告，幫助其快速掌握航司機隊狀況；為機場、航司、金融、證券、媒體等行業，圍繞計劃/實際航班量、航班執飛率、航班座位數、航班擁擠度、旅客運輸量等指標，提供民航運行周報，從整體上把握民航運行狀況，了解行業趨勢；節假日時發布專題報告，分析旅客出行數據， 探索 旅客出行規律，為航司、旅行社、酒店等企業，在制定節假日產品時，提供數據支持。
數據分析工具及可視化
基於行業領先且專業的民航鐵路出行大數據及擁有自主知識產權的演算法模型，通過可視化平台，將分析、預測數據深入淺出的展現出來。如Mapping System（航線網路圖），提供航司、機場航線布局，並對數據進行分析展示，方便用戶直觀便捷的查機場/航司航線狀況、通航點狀況、空鐵聯運銜接狀況；大數據平台，提供官方統計、機場分析、航司分析、航線分析、鐵路分析等分析模塊，幫助航司/機場快速掌握民航鐵路整體運行狀況，了解對標機場/航司運行狀況，為機場/航司運行、服務提升、產品優化提供數據支撐；為文旅廳，提供空鐵聯運實時監測系統，幫助文旅廳實時掌握機場/火車站實時旅客流量、航班運行狀況、旅客運行狀況，提前做好景區開放、接待籌備等工作。
海量數據實時處理，及時准確對外輸出。我們的數據覆蓋全球1100+家航空公司，5000+座機場，境內航班數據覆蓋率達100%，全球航班覆蓋率達98%，每天處理超過20萬趟航班的動態信息，智能推送40多類旅客行程關懷信息，國內航班實際起降時間准確率達99%。同時，自建鐵路資料庫已覆蓋國內3138個車站，10000+班車次，每日覆蓋中國國內90W+進出站車次。
航班動態的數據是由數據生產者實時解析的，數據生產者將解析的數據發送到Kafka，由消費服務對數據進一步消費處理，最終由消費服務將有效的數據同步到MySQL資料庫中存儲。
全球每天約有10萬次航班的起降，預計每分鍾產生5萬條航班動態數據合計14M，每天產生的數據約20.4G，每月612G，每年7.2T ; 航班管家數據覆蓋全球1100+家航空公司，5000+座機場，境內航班數據覆蓋率達100%，全球航班覆蓋率達98%，每日處理超過20萬趟航班的動態信息。
為了面向行業提供多種數據服務產品和數據解決方案，賦能行業合作夥伴、幫助其提效降本，2021年01月06日，公司領導召集部分員工，確定了項目的大致方向，提出了依託現有的航班、高鐵數據介面，開發一個「航班管家開放平台」的SaaS平台。
01
項目設計
研發人員根據項目提出的需求，第一時間畫了簡單的設計圖。
航班管家開放平台可主要分為3個大模塊和15個子模塊：3個大模塊分別是控制台模塊、數據服務模塊、數據中心模塊。15個子模塊分別是：用戶模塊、鑒權模塊、產品模塊、網關模塊、API數據模塊、H5數據模塊、控制台模塊、管理後台模塊、賬單模塊、余額模塊、批價模塊、支付模塊、時間軸模塊、行程中心模塊、行程消息模塊。
控制台模塊：
提供用戶專屬賬號登陸「航班管家開放平台」的控制台，開通「行程服務」中的產品獲取航班、高鐵服務的專屬API介面數據和下載「數據報告」產品中有價值的大數據分析報告等。
數據服務模塊：
數據中心模塊：
基於民航空管局授權的官方動態數據，整合航空、鐵路、場站、旅客、貨運等多維度數據，結合擁有自主知識產權的演算法模型與行業Know-how，構建有價值的數據。
02
技術選型
技術團隊了解完業務的需求，考慮到用戶的類型和規模，為了保證系統的安全性、可用性、穩定性、可伸縮性和可維護性，確定了以下的架構模式：
2.1、分層模式：
控制台模塊採用的是分層模式：表示層、應用層、數據訪問層。
表示層：
使用Vue.js等進行前端展示，完成集成和數據展示功能。
應用層：
使用Spring Cloud、Log4j、MyBatis等開源框架，Spring Cloud使用的計算機編程語言是Java，保證了系統代碼的可移植性、安全性、可維護性，同時它也是一個分布式系統，保證了系統的可伸縮性、可維護性、可用性。
數據訪問層：
綜合使用Kafka、MySQL、Redis等多種開源技術，高效完成數據存儲、資源調度、數據計算等，為業務及其他環節做支撐。
2.2、主從設備模式
數據中心模塊中的資料庫MySQL採用主從設備模式：主設備儲存數據最終的計算結果，從設備中返回主設備中的計算結果。
MySQL使用主從設備模式，實現了實時災備，在單台機器發生故障的時候，可以迅速的切換到其它機器，即實現了數據的備份，又保證了服務的高可用，同時從設備可以有多個，也保留了服務的擴展性。
2.3、代理模式
採用Nginx伺服器的反向代理，防止主伺服器被惡意攻擊，確保數據的安全，提供數據的防護能力。同時Nginx伺服器提供有負載均衡和動靜分離的實現支持，可以極大的提高服務的安全性、穩定性，可用性。為了進一步保證網路安全，所有的服務均採用HTTPS加密協議進行網路資源傳輸，為用戶良好的體驗效果提供保障。
03
實施過程
2021-01-18
以下模塊分別完成了伺服器端文檔編寫和介面開發並發布測試環境：
1. 產品模塊完成了H5資源和API資源的在線配置相關介面；
2. 鑒權模塊完成了資源訪問的鑒權相關介面；
3. 用戶模塊完成賬戶信息的維護相關介面；
4. API數據模塊完成了航班數據輸出介面、高鐵正晚點數據輸出介面；
5. H5數據模塊完成了航班詳情頁和高鐵詳情頁伺服器端介面；
6. 控制台模塊完成產品列表、應用列表相關介面。
2021-01-25
1. 控制台模塊和產品模塊、鑒權模塊、前端完成聯調和上線；
2. 網關模塊和鑒權模塊、產品模塊、H5數據模塊、API數據模塊完成聯調並上線；
3. 管理後台模塊完成了基礎框架的搭建和許可權系統的開發、測試和部署到線上華為雲。
2021-02-25
以下模塊分別完成了伺服器端文檔編寫和介面開發並發布測試環境：
1. API數據模塊完成高鐵動態、列車時刻表輸出相關介面；
2. H5數據模塊完成航班詳情頁內部跳轉鏈接頁面、高鐵詳情頁內部跳轉鏈接頁面；
3. 時間軸模塊完成卡片元數據和階段卡片關聯的相關介面；
4. 控制台模塊完成用戶注冊、找回密碼、更換手機號、主題配置相關介面；
5. 管理後台模塊完成產品貨架的展示、產品上下架，用戶信息，系統配置。
2021-03-08
1. API數據模塊和網關模塊完成高鐵動態、列車時刻表輸出的聯調、上線；
2. H5數據模塊和網關模塊、前端完成航班詳情頁、高鐵詳情頁內部跳轉鏈接頁面的聯調、上線；
3. 時間軸模塊和管理後台模塊完成卡片元數據和階段卡片關聯的聯調、上線；
4. 控制台模塊和用戶模塊、前端完成戶注冊、找回密碼、更換手機號、主題配置的聯調、上線；
5. 管理後台模塊完成產品貨架的展示、產品上下架、用戶信息、系統配置的上線。
2021-03-26
以下模塊分別完成了伺服器端文檔編寫和介面開發並發布測試環境：
2. 行程消息模塊完成消息推送、消息列表展示的相關介面；
3. 控制台模塊完成用戶的認證、應用的動態配置、銀行卡對公轉賬充值的相關介面；
4. 批價模塊完成了產品的批價處理相關介面；
5. 賬單模塊完成了生成產品的消費訂單相關介面；
6. 余額模塊完成了消費訂單的扣費相關介面
7. 支付模塊完成了企業賬戶信息的維護、銀行卡對公轉賬充值到余額、余額支付、余額查詢的相關介面；
8. 管理後台完成用用戶認證審核、戶充值的訂單和充值處理的相關介面。
2021-04-08
1. 行程中心模塊和網關模塊、控制台模塊完成了聯調、上線；
2. 行程消息模塊和網關模塊、控制台模塊完成了聯調、上線；
3. 賬單模塊和批價模塊、余額模塊、支付模塊完成了聯調、上線；
4. 控制台模塊和支付模塊、管理後台模塊、前端完成了聯調、上線；
5. 管理後台模塊和控制台完成了聯調、上線。
2021-05-15
以下模塊分別完成了伺服器端文檔編寫和介面開發並發布測試環境：
1. 支付模塊完成支付寶、微信掃碼支付的相關介面；
2. 賬單模塊完成了日賬單、月賬單統計和明細查詢的相關介面；
3. 控制台模塊完成了用戶賬單的匯總和明細的展示和導出、行程服務產品套餐包展示和購買和訂單的支付、查詢相關介面；
4. 批價模塊完成行程服務產品套餐包的批價；
5. 管理後台模塊完成產品套餐的錄入、上下架，用戶購買套餐的展示、用戶訂單的相關功能。
2021-05-31
1. 支付模塊和控制台完成掃碼支付的聯調、上線；
2. 賬單模塊和控制台完成賬單統計和明細查詢的聯調、上線；
3. 控制台模塊和支付模塊、前端完成套餐的展示、購買和訂單列表的查詢的聯調和上線；
4. 批價模塊和控制台模塊完成套餐包相關產品的計費調整的聯調和上線；
5. 管理後台模塊完成了測試和上線。
2021-06-18
以下模塊分別完成了伺服器端文檔編寫和介面開發並發布測試環境：
1. 控制台模塊完成支付寶、微信掃碼充值到余額，航班詳情頁、高鐵詳情頁支持功能模塊可配置化；
2. H5數據模塊完成航班詳情頁、高鐵詳情頁功能模塊的動態展示。
2021-06-30
1. 控制台模塊和支付模塊、前端完成掃碼充值聯調、航班/高鐵詳情頁的功能模塊動態配置的聯調、上線；
2. H5數據模塊和前端完成航班詳情頁、高鐵詳情頁功能模塊的動態展示的聯調、上線；
3. 前端完成官網的全新改版上線。
民航局空管局官方授權數據，為航班信息提供了官方來源的數據，充實、完善了底層資料庫。
·與交通行業專業院校、科研院所、金融券商等展開合作，特聘各領域專家組成專家團隊，為客戶提供深度的行業咨詢服務及分析報告產品。
一、項目定位
1. 概述：大交通數據及服務開放平台，為多種行業用戶提供民航、鐵路、航空貨運大交通數據及其衍生產品服務，並根據各行業特色和需求，提供個性化、配套完善的解決方案。
2. 目標：封裝航班管家的各項能力，向平台用戶輸出多種類的產品服務及解決方案。提供一站式自助化線上服務，降低自身人力成本投入。
3．提供成熟穩定的行程服務H5頁面，企業可在自有移動端產品中嵌入航班、列車行程服務及行程管理頁面，以企業自己的品牌，在自有產品中一站式全流程服務出行用戶，讓用戶能輕松管理自己的行程。幫助企業顯著提升用戶出行體驗，更好服務用戶，創造更多商業價值。
4. 可為企業高效快速對接以下成熟型行程服務產品降低企業開發成本、提升用戶出行服務滿意度，如行程管理、航班行程服務、列車行程服務、全場景服務信息推送。用戶可隨時查看已有行程/ 歷史 行程
用戶可自主添加航班、列車行程，支持航班號/起降地查詢航班信息、車次號/出發到達站查詢火車信息，航班行程服務，圍繞用戶航空出行場景，提供精準的航班動態信息，並將航空出行全流程劃分為多個階段，在不同階段提供不同的數據和服務，企業可通過H5頁面將服務嵌入自有產品中，為用戶提供一站式全流程服務。不同行程階段，給用戶提供的服務，可以在平台進行配置。實時、精準呈現航班動態相關信息，大數據預測起飛及到達時間，准確告知值機櫃台和登機口信息，詳細指引登機路線，確保用戶順利登機，航班近期准點率及平均延誤時長統計。
二、目標群體
1. 短期目標群體：
有數據使用需求的中小型用戶，如券商、咨詢公司、學者學生、創業開發者等（對標API介面產品）。
有數據分析需求，需要數字化分析工具的用戶，如機場、航司、政府、製造商等（對標數據平台、數據報告產品）。為C端提供行程服務需求的用戶如中小型OTA、TMC等（對標行程服務產品）。
2. 長期目標群體：
有貨運數據需求的用戶，如物流、貨運代理等（對標貨運服務產品）
為服務的各領域提供專業的解決方案，如OTA、物流、航司、機場、製造商、用車、保險、車聯網、集成系統開發、雲服務等。
成效：
保險：行業數據分析核算，實時核保，賠付周期提升99%，賠付率降低50%，優化用戶服務體驗。
網約車：合理優化網約車資源利用率，平均減少接送機司機空等時間75分鍾/年。
酒店：為酒店提供用戶行程管理，6小時酒店航班信息同步，提高房源利用率，提升「機+酒」服務體驗。
物流：為物流快遞行業提供發貨前中後數據信息參考，航班管家為中國90%的航空快件服務商賦能提效。
航班管家
航班管家是國內領先的智能出行平台，以「航班+高鐵」的行程服務為核心，服務全面覆蓋航班、高鐵以及專車接駁三大出行場景，服務所有大交通出行用戶。面向C端，航班管家為用戶提供航班/列車動態信息、票務/酒店預訂、專車接送、出行攻略內容等在內的一站式出行服務，讓出行成為美好的生活方式；面向B端，航班管家構建覆蓋航班和鐵路出行全場景的企業級SaaS平台，聚焦大交通出行服務行業數字化升級，為OTA、TMC等行業提供多場景服務解決方案，賦能合作夥伴，提效降本。