精準(zhǔn)扶貧項目解決方案說明書

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

目錄一、項目存在問題及需解決問題 31.存在問題 31.1. 扶貧信息化建設(shè)管理相對滯后 31.2. 扶貧工作政策及信息上傳下達(dá)不通暢 31.3. 一線幫扶干部缺乏有效線上管理 41.4. 扶貧措施管理和落地原始粗放 41.5. 缺乏全面的數(shù)據(jù)決策分析系統(tǒng) 41.6. 社會扶貧缺乏參與平臺或途徑 41.7. 未建立完整的退出管理機(jī)制 52.需解決問題 5二、解決方案 61.解決方案總體架構(gòu) 62.核心技術(shù) 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ù)據(jù)生產(chǎn) 102.數(shù)據(jù)采集/消費 103.數(shù)據(jù)分析 114.數(shù)據(jù)展示 12

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