. rdp報表
JavaWeb實現的報表工具,是唯一一款通過web頁面設計報表的工具,僅需簡單拖拽式配置,即可制作出各種復雜、炫酷的報表,商用免費的一款報表工具。
Web類Excel報表設計器,方便的B/S報表設計模式,具有強大的表達式和擴展功能,可以輕松快捷、零編碼地實現各種復雜報表、
輯導語:什么是數據湖?企業可以利用數據湖盡可能保持業務數據的可還原性,解決存儲全域原始數據的問題;而數據中臺的存在則可以幫助幫助企業提升業務處理效率。不過并非所有的企業都需要設立數據中臺。本篇文章里,作者對數據湖與數據中臺進行了詳細的解釋,一起來看一下。
引言:文接上回,沒有閱讀第一部分的小伙伴請點擊《10分鐘帶你了解數據庫、數據倉庫、數據湖、數據中臺的區別與聯系(一)》查看,那我們就開始第二部分的內容吧,如有不準確的地方,還請希望大家進行指正。
上文通過有序性與開放性分別對數據倉庫與數據湖進行描述并對比,現在我們來詳細地了解一下數據湖。
數據湖主要是為了解決存儲全域原始數據,其名稱中的“湖”字將數據湖的含義表現得淋漓盡致。像企業的生產數據(非結構化數據與結構化數據)、業務歷史數據、臨時數據,諸如IOT設備,移動應用程序以及傳統的設備中返回的第三方數據都可以通過ETL工具形成的“水管”存儲進數據湖中。
例如筆者之前在工作過程中接觸的手機信令數據、GPS返回的定位數據等,這些數據實際上并沒有預先定義好相應的數據結構,這就意味著可以先將數據存儲起來而無需對數據進行結構化處理,也無需明確要進行什么分析,由數據從業人員在后續工作中進行探索和嘗試。
上文中提到的結構化數據和非結構化數據,那什么是結構化/非結構化數據呢?下面我們就解釋下兩者的區別與聯系。
舉個例子。
我們收集到了這樣一堆文字信息:
諸如此類的文字信息有幾萬行,我們存在word中,亦或是紙質版文件經由我們掃描成圖片格式的,這類就可以稱為非結構化數據。假設有需求將這些文字信息中按照性別、籍貫、專業等等統計出來,我們在第一篇文章中提到了關系型數據庫,用相關的技術和工具將這些文字信息進行處理,處理后的數據就是結構化數據。
所以結構化數據的定義:是由二維表結構來邏輯表達和實現的數據,嚴格地遵循數據格式與長度規范,主要通過關系型數據庫進行存儲和管理。
非結構化數據:不適于由數據庫二維表來表現的非結構化數據,包括所有格式的辦公文檔、 XML 、 HTML 、各類報表、圖片和音頻、視頻信息等。
回歸正題,企業為什么要建立數據湖呢,首先數據湖中存在一個重要的組成部分ODS(Operating Data Store,操作數據存儲),大家是否記得上一篇文章講過OLTP(On-Line Transaction Processing),OLTP側重于基本的、日常的事務處理,而我們現在提到的ODS就是OLTP數據的快照與歷史。
我們在上文的數據庫一節描述時提到業務數據庫與數據倉庫的結構不同,業務數據庫是為OLTP設計的,是系統的實時狀態的數據,而數據倉庫的數據是為OLAP的需求建設的,是為了深度的多維度分析。所以這樣就會造成基于數據倉庫的數據分析會產生以下的限制:
而從根本上來講,數據湖的最主要作用是盡可能保持業務數據的可還原性。數據湖的定位和搜索引擎類似,我們可以像在搜索引擎中檢索數據一樣,實現按需檢索,即取即用,它存取這原始的未經改變的全量數據,可以存取、處理、分析。
數據湖最早是2011年由Pentaho的首席技術官James Dixon提出的一個概念,他認為諸如數據集市,數據倉庫由于其有序性的特點,勢必會帶來數據孤島效應,而數據湖可以由于其開放性的特點可以解決數據孤島問題。
但隨著數據湖在各類企業的應用,大家都覺得:嗯,這個數據有用,我要放進去;那個數據也有用,我也要放進去;于是把所有的數據不假思索地扔進基于數據湖的相關技術或工具中,沒有規則不成方圓,當我們認為所有數據都有用時,那么所有的數據都是垃圾,數據湖也變成了造成企業成本高企的數據沼澤。
所以這也是為什么“數據湖”叫“湖”,而不叫數據河,數據池亦或是數據海。
首先數據要能“存”,數據要夠“存”,數據要有邊界地“存”。企業級的數據是需要長期積淀的,所以是“數據湖”。
同時湖水天然會進行分層,滿足不同的生態系統要求,這與企業建設統一數據中心,存放管理數據的需求是一致的。熱數據在上層方便流通應用,溫數據、冷數據位于數據中心的不同存儲介質之中,達到數據存儲容量與成本的平衡。
我們終于迎來了最近幾年很火的數據中臺。網上有很多文章關于數據中臺的介紹,什么Hive、Spark、Hadoop、Kalfa等等很多技術名詞,聽上去非常的高大上而且云里霧里的,會使初涉產品的我們望而卻步。
所以接下來我們從何為中臺、何為數據中臺、數據中臺可以做什么三個方面來講講數據中臺。
首先拋開數據,中臺這一概念這兩年在國內大火。說起來源,網上文章都會提到這種組織是2015年馬云參觀Supercell的游戲公司借鑒過來的,并且后來“阿里巴巴”CEO逍遙子提出的組建的“大中臺,小前臺”的組織和業務體制。那么我們能用一個比較淺顯的例子來理解“中臺”一詞么?
當然可以,有一家連鎖且超級便宜的意大利西餐連鎖店“薩莉亞”,相信大部分同學都光顧過,9元的意面,24的披薩,上菜速度超快,雖然比不上傳統西餐,但相比于這個價位,屬實很良心了,而且目前薩莉亞在中國已經開設了將近400家(截止2019年)分店。
那么薩莉亞保持價格低廉同時上菜效率高效的原因是什么?答案很簡單,就是中央廚房進行粗加工,然后門店的廚師僅需要簡單地烹飪即可端上餐桌。相比于傳統餐廳采購(買菜)→配菜→做菜的環節,既減少門店廚師的數量,降低人工成本的同時又加快上菜速度。
回到我們研發流程來看,采購(買菜)→配菜環節就是我們研發的后臺,他們幫助我們解決“有什么”;而配菜→做菜環節就是我們的業務前臺團隊,他們要做的就是根據客戶的“口味”來“做什么”。
而配菜,蔬菜整理這個環節,也就是薩莉亞的“中央廚房”就相當于我們的中臺,僅僅需要門店的需求,中央廚房就可以快速提供對應的材料,提高業務開發效率,減少重復開發成本。
介紹完了“中臺”這一概念,數據中臺相信大家也能舉一反三。沒錯,對于采購來的“菜”就相當于數據,做出來的“菜”就相當于業務部門所以需要的數據應用。
那么配菜環節就相當于IT部門的各種數據算法,每道菜單獨配菜效率慢且冗余度較高,于是“中央廚房”就對數據算法進行規范化,系統化。針對于業務部門所需要的各道菜提供粗加工的半成品,這就是“數據產品”。
這種“中央廚房”配菜的過程就相當于我們所說的“數據中臺”。那么是不是每個企業都必須搭建數據中臺么?數據中臺在業務上能解決什么問題呢?
所有企業是否都需要搭建數據中臺?首先我們知道企業引進一項技術或產品,不在于是否“時髦”,不在于是否“高科技”,而在于是否適合該公司目前的發展,是否能提高公司的利潤,降低公司的成本。
首先數據中臺的作用通過對中臺及數據中臺的描述,總結以下2點:
根據以上提到數據中臺的兩個優勢,針對一個企業是否搭建數據中臺,亦或是說一個企業在一開始從零到一就要構建數據中臺?筆者在此有幾點自己的總結:
首先針對于不同的行業,盡管傳統企業數字化改革正在路上且已經有很多行業已經改革成功,但是針對于大部分傳統企業,別說數據中臺,公司連數據倉庫的時代都沒有到來,“羅馬不是一天建成的”拋去建設數據中臺的財力,時間成本高昂不提,就是對于傳統企業的業務流轉模式,企業員工接受程度來說都是一條難以逾越的鴻溝,數據中臺不可操之過急。
對于一些處于數據倉庫時代的傳統企業或互聯網企業,由于各個部門不停無限地進行滿足其業務支撐點取數要求、業務統計、看數需求,就可以嘗試轉型數據中臺。
對初創企業,業務線單一且業務模式還經常不斷變化,不斷試錯時,沒有能力去進行數據中臺的搭建,換言之就是“先活下去最重要”。
本篇文章分兩部分介紹了數據庫、數據倉庫、數據湖、數據中臺的區別與聯系。
關于數據有人說數據是新的石油資源,國家也將數據作為一種新型生產要素,與傳統生產要素并列。
筆者曾經在泛互聯網以及傳統企業的業務部門都工作一段時間,由于各類原因,相比于泛互聯網行業的數據化相比,傳統企業的數據化之路并不一帆風順。2020年8月,國務院國資委引發《關于加快推進國有企業數字化轉型工作的通知》表現出各國有企業未來數字化轉型將成為必然,如何協助傳統企業進行數字化轉型,利用數據驅動傳統行業迸發新的活力對于數據產品經理,尤其是對ToB的數據產品經理將會是挑戰與機遇。
筆者會繼續努力與大家分享交流其他數據產品相關的文章與內容。
本文由 @快樂的給予 原創發布于人人都是產品經理,未經許可,禁止轉載
題圖來自 Pexels,基于 CC0 協議
編最近發現幾款不錯的開源報表,還提供源碼,現在給大家分享一下,希望能給你帶來幫助!
*請認真填寫需求信息,我們會在24小時內與您取得聯系。