精準扶貧項目解決方案說明書

精準扶貧項目解決方案說明書XX科技股份有限公司編制

目錄一、項目存在問題及需解決問題 31.存在問題 31.1. 扶貧信息化建設管理相對滯后 31.2. 扶貧工作政策及信息上傳下達不通暢 31.3. 一線幫扶干部缺乏有效線上管理 41.4. 扶貧措施管理和落地原始粗放 41.5. 缺乏全面的數(shù)據決策分析系統(tǒng) 41.6. 社會扶貧缺乏參與平臺或途徑 41.7. 未建立完整的退出管理機制 52.需解決問題 5二、解決方案 61.解決方案總體架構 62.核心技術 7（1）Hadoop 7（2）SpringMVC 7（3）MyBatis 8（4）Echarts 8（5）MySQL 8（6）Hive 8（7）HBASE 9（8）Zookeeper 9（9）Flume 9三、開發(fā)范圍 101.數(shù)據生產 102.數(shù)據采集/消費 103.數(shù)據分析 114.數(shù)據展示 12

項目存在問題及需解決問題存在問題我國政府歷來高度重視扶貧工作，國家“十三五”規(guī)劃明確提出扶貧工作在2020年的整體目標為“實現(xiàn)農村貧困人口全面脫貧”，精準扶貧已成為全黨和各級政府實現(xiàn)同步小康的共識。目前距2020年還有不到4年時間，扶貧開發(fā)工作已進入“啃硬骨頭、攻堅拔寨”的沖刺期。扶貧信息化建設作為推進精準扶貧、精準脫貧的基礎性工作和檢驗“扶貧工作六個精準”的重要平臺，發(fā)揮著越來越重要的作用。而在歷年的扶貧工作中，伴隨著扶貧對象的多樣化，扶貧項目多樣化、資金使用多樣化、扶貧措施多樣化、人力資源配置多樣化，面對資金統(tǒng)一監(jiān)管、脫貧效果統(tǒng)一評估、區(qū)域協(xié)同發(fā)展、上級部門無法及時掌握扶貧干部幫扶情況等一系列問題，傳統(tǒng)的扶貧建檔立卡信息管理已越來越不能滿足現(xiàn)有的信息化扶貧管理要求。扶貧信息化建設管理相對滯后各地扶貧單位大多使用國扶辦的“扶貧開發(fā)信息管理系統(tǒng)”，囿于全國信息數(shù)據的龐大，功能模塊設計有一定局限性。建檔立卡無法滿足扶貧的過程管理和精準要求。扶貧數(shù)據基本依靠扶貧干部手動紙質填寫收集，數(shù)據填報基本依靠后臺專人不定時人工操作，費時費力且更新不夠及時。扶貧工作是一個動態(tài)過程，由于貧困戶數(shù)量、致貧原因、脫貧返貧數(shù)據經常變化，而數(shù)據滯后給統(tǒng)計匯總工作帶來極大困難。一方面，傳統(tǒng)的逐級匯總、上報方式難以應對如此規(guī)模的信息統(tǒng)計；另一方面，數(shù)據更新不及時也造成統(tǒng)計數(shù)據不準確，精準扶貧工作落實和扶貧成效均難以體現(xiàn)。扶貧工作政策及信息上傳下達不通暢工作任務的下達、分配常通過會議、電話等方式，造成工作安排缺乏高效性；上級部門無法實時掌握幫扶干部的幫扶工作情況，導致對基層幫扶干部的幫扶工作難以監(jiān)督。貧困戶和幫扶干部通過紙質文件查詢政策信息效率較低，扶貧工作政策及信息上傳下達不通暢。一線幫扶干部缺乏有效線上管理駐村幫扶干部的工作管理粗放，貧困戶遍訪、扶貧過程、扶貧紀事等扶貧工作動態(tài)跟蹤和評估機制缺乏精確的數(shù)據支撐，難以做到準確考核和有效獎懲。扶貧措施管理和落地原始粗放扶貧不僅是扶貧辦一個部門，也是政府各層面所有部門參與的大扶貧，扶貧項目尤其是資金是各方管理，專項扶貧項目和資金管理各部門各自為政，未打通業(yè)務關鍵數(shù)據，幫扶干部無法全面掌握幫扶對象資金情況。貧困戶實際情況掌握不清楚，產業(yè)項目的實施缺乏科學的制定過程，以農產品銷售為例，以粗放、簡單的模式難以穩(wěn)定的提供產品輸出，很難形成規(guī)模效應，這也是制約農產品輸出和產村電商發(fā)展的重要原因。缺乏全面的數(shù)據決策分析系統(tǒng)缺乏指揮調度大屏展示，當?shù)卣拖嚓P部門無法及時掌握區(qū)域扶貧全局、扶貧項目工程落實實施、扶貧資源配置和風險應急處置等情況；數(shù)據的分析呈現(xiàn)仍以手工統(tǒng)計層層匯總、文字匯報的方式，信息滯后容易虛報、瞞報。社會扶貧缺乏參與平臺或途徑貧困戶受限于知識水平與經濟條件，獲取幫扶政策、信息的渠道有限，處于信息匱乏狀況。社會扶貧力量缺乏獲得貧困戶信息及訴求的渠道，有心幫扶但難以找到真正的幫扶對象，缺乏參與平臺和幫扶途徑。未建立完整的退出管理機制在國家扶貧辦根據年收入單一脫貧標準的基礎上，各地政府結合當?shù)胤鲐毈F(xiàn)狀制定一套符合當?shù)靥攸c的脫貧評估標準，這就要求扶貧系統(tǒng)具備靈活的貧困戶貧困村脫貧評估指標、脫貧評估規(guī)則配置支撐。傳統(tǒng)退出只看收入是否達標，很難通過新的脫貧驗收評估要求。需解決問題扶貧信息化建設管理相對滯后扶貧工作政策及信息上傳下達不通暢一線幫扶干部缺乏有效線上管理扶貧措施管理和落地原始粗放缺乏全面的數(shù)據決策分析系統(tǒng)社會扶貧缺乏參與平臺或途徑解決方案解決方案總體架構圖1精準扶貧解決方案總體架構HBase是一個分布式的、面向列的開源數(shù)據庫，該技術來源于FayChang所撰寫的Google論文“Bigtable：一個結構化數(shù)據的分布式存儲系統(tǒng)”。就像Bigtable利用了Google文件系統(tǒng)（FileSystem）所提供的分布式數(shù)據存儲一樣，HBase在Hadoop之上提供了類似于Bigtable的能力。HBase是Apache的Hadoop項目的子項目。HBase不同于一般的關系數(shù)據庫，它是一個適合于非結構化數(shù)據存儲的數(shù)據庫。另一個不同的是HBase基于列的而不是基于行的模式。系統(tǒng)采用面向對象的軟件設計方法，把整個系統(tǒng)看作是多個離散對象的組合。系統(tǒng)設計時，首先把業(yè)務流程分解成功能模塊及其業(yè)務實體對象，然后根據業(yè)務流程分析對于這些業(yè)務實體對象的操作方法，形成業(yè)務處理對象，最后把各個功能模塊關聯(lián)起來，形成系統(tǒng)。軟件設計是一個將需求轉變?yōu)檐浖倪^程，系統(tǒng)通過逐步求精使得設計陳述逐漸接近于源代碼。系統(tǒng)程序采用MVC的設計思想，將展現(xiàn)邏輯、控制邏輯、業(yè)務處理邏輯分離。系統(tǒng)采用參數(shù)化的設計思想，定義和管理系統(tǒng)的實體及配置，調整實體以適應外部變化。系統(tǒng)采用J2EE技術保證程序邏輯實現(xiàn)的平臺無關性，并便于安裝部署。系統(tǒng)采用AJAX技術，提高客戶操作的交互性，保證實際使用的易用性。系統(tǒng)采用echarts可視化框架實現(xiàn)數(shù)據展示。核心技術HadoopHadoop是一個由Apache基金會所開發(fā)的分布式系統(tǒng)基礎架構。用戶可以在不了解分布式底層細節(jié)的情況下，開發(fā)分布式程序。充分利用集群的威力進行高速運算和存儲。SpringMVCSpringMVC：屬于SpringFrameWork的后續(xù)產品，已經融合在SpringWebFlow里面。Spring框架提供了構建Web應用程序的全功能MVC模塊。MyBatisMYBatis：是支持普通SQL查詢，存儲過程和高級映射的優(yōu)秀持久層框架。MyBatis消除了幾乎所有的JDBC代碼和參數(shù)的手工設置以及結果集的檢索。MyBatis使用簡單的XML或注解用于配置和原始映射，將接口和Java的POJOs（PlainOldJavaObjects，普通的Java對象）映射成數(shù)據庫中的記錄。EchartsECharts是一款基于Javascript的數(shù)據可視化圖表庫，提供直觀，生動，可交互，可個性化定制的數(shù)據可視化圖表。MySQLMySQL是一個關系型數(shù)據庫管理系統(tǒng)，由瑞典MySQLAB公司開發(fā)，屬于Oracle旗下產品。MySQL是最流行的關系型數(shù)據庫管理系統(tǒng)之一，在WEB應用方面，MySQL是最好的RDBMS(RelationalDatabaseManagementSystem，關系數(shù)據庫管理系統(tǒng))應用軟件之一。MySQL是一種關系型數(shù)據庫管理系統(tǒng)，關系數(shù)據庫將數(shù)據保存在不同的表中，而不是將所有數(shù)據放在一個大倉庫內，這樣就增加了速度并提高了靈活性。MySQL所使用的SQL語言是用于訪問數(shù)據庫的最常用標準化語言。MySQL軟件采用了雙授權政策，分為社區(qū)版和商業(yè)版，由于其體積小、速度快、總體擁有成本低，尤其是開放源碼這一特點，一般中小型網站的開發(fā)都選擇MySQL作為網站數(shù)據庫。HiveHive是基于Hadoop構建的一套數(shù)據倉庫分析系統(tǒng)，它提供了豐富的SQL查詢方式來分析存儲在Hadoop分布式文件系統(tǒng)中的數(shù)據：可以將結構化的數(shù)據文件映射為一張數(shù)據庫表，并提供完整的SQL查詢功能；可以將SQL語句轉換為MapReduce任務運行，通過自己的SQL查詢分析需要的內容，這套SQL簡稱HiveSQL，使不熟悉mapreduce的用戶可以很方便地利用SQL語言查詢、匯總和分析數(shù)據。而mapreduce開發(fā)人員可以把自己寫的mapper和reducer作為插件來支持hive做更復雜的數(shù)據分析。它與關系型數(shù)據庫的SQL略有不同，但支持了絕大多數(shù)的語句如DDL、DML以及常見的聚合函數(shù)、連接查詢、條件查詢。它還提供了一系列的：具進行數(shù)據提取轉化加載，用來存儲、查詢和分析存儲在Hadoop中的大規(guī)模數(shù)據集，并支持UDF（User-DefinedFunction）、UDAF(User-DefnesAggregateFunction)和UDTF（User-DefinedTable-GeneratingFunction），也可以實現(xiàn)對map和reduce函數(shù)的定制，為數(shù)據操作提供了良好的伸縮性和可擴展性。HBASEHBase–HadoopDatabase，是一個高可靠性、高性能、面向列、可伸縮的分布式存儲系統(tǒng)，利用HBase技術可在廉價PCServer上搭建起大規(guī)模結構化存儲集群。ZookeeperZooKeeper是一個分布式的，開放源碼的分布式應用程序協(xié)調服務，是Google的Chubby一個開源的實現(xiàn)，是Hadoop和Hbase的重要組件。它是一個為分布式應用提供一致性服務的軟件，提供的功能包括：配置維護、域名服務、分布式同步、組服務等。FlumeFlume是Cloudera提供的一個高可用的，高可靠的，分布式的海量日志采集、聚合和傳輸?shù)南到y(tǒng)，F(xiàn)lume支持在日志系統(tǒng)中定制各類數(shù)據發(fā)送方，用于收集數(shù)據；同時，F(xiàn)lume提供對數(shù)據進行簡單處理，并寫到各種數(shù)據接受方（可定制）的能力。開發(fā)范圍數(shù)據生產對于該模塊的業(yè)務，即數(shù)據生產過程，一般并不會讓你來進行操作，數(shù)據生產是一套完整且嚴密的體系，這樣可以保證數(shù)據的安全性。但是如果涉及到項目的一體化方案的設計（數(shù)據的產生、存儲、分析、展示），則必須清楚每一個環(huán)節(jié)是如何處理的，包括其中每個環(huán)境可能隱藏的問題；數(shù)據結構，數(shù)據內容可能出現(xiàn)的問題。數(shù)據采集/消費數(shù)據采集模塊（消費），在企業(yè)中你要清楚流式數(shù)據采集框架flume和kafka的定位是什么。我們在此需要將實時數(shù)據通過flume采集到kafka然后供給給hbase消費。flume：cloudera公司研發(fā)適合下游數(shù)據消費者不多的情況；適合數(shù)據安全性要求不高的操作；適合與Hadoop生態(tài)圈對接的操作。kafka：linkedin公司研發(fā)適合數(shù)據下游消費眾多的情況；適合數(shù)據安全性要求較高的操作（支持replication）；因此我們常用的一種模型是：線上數(shù)據-->flume-->kafka-->flume(根據情景增刪該流程)-->HDFS線上數(shù)據-->flume-->