數據存儲屬於哪個部門

A. 數據處理和存儲服務屬於什麼行業

IT行業，可以找當地的系統集成商，謝謝

B. IT部門是干什麼的

IT是Information Technology的簡稱，即信息技術,因此,IT部即指企業的信息技術部.
信息技術一般包括硬體\軟體\應用
第一層是硬體，主要指數據存儲、處理和傳輸的主機和網路通信設備；
第二層是指軟體，包括可用來搜集、存儲、檢索、分析、應用、評估信息的各種軟體，它包括我們通常所指的ERP(企業資源計劃)、CRM(客戶關系管理)、SCM(供應鏈管理)等商用管理軟體，也包括用來加強流程管理的WF(工作流)管理軟體、輔助分析的DW/DM(數據倉庫和數據挖掘)軟體等；
第三層是指應用，指搜集、存儲、檢索、分析、應用、評估使用各種信息，包括應用ERP、CRM、SCM等軟體直接輔助決策，也包括利用其它決策分析模型或藉助DW/DM等技術手段來進一步提高分析的質量，輔助決策者作決策(強調一點，只是輔助而不是替代人決策)。

C. 數據的業務主管部門在數據質量管理中承擔哪像製作

我們要形成一個數據是基礎、平台是支撐、分析挖掘是核心，最根本的是要實現目標導向、問題驅動，實現效率的提升和經濟效益社會效益的挖掘和發揮。

世界頂級大國都把大數據核心技術的研究作為未來搶佔大數據產業自主知識產權的一個核心制高點來探索研究。

第一，從理論和技術角度來看，傳統的計算理論和傳統的數據處理分析技術難以完全適用。一方面是大數據和傳統的中小規模的數據有本質的特徵上的差別。

第二，在傳統的計算平台計算範式方面也有根本性的轉折。我們知道傳統的數據量是中小規模，現在都是 ZB級，10 的 18 次方超大規模的數據量。從數據的結構來說，從傳統的結構化朝大量的非結構化方向發展，從過去以靜態為主朝著流數據發展，從單一的數據源朝著多元異構的方向發展，從多媒體朝著跨媒體融合的方向發展。這些數據特徵的變化使得我們傳統計算理論難以適應。

從計算平台和計算範式來說，從過去的集中存儲向現在的各地多數據中心的分布式存儲方向發展，從多線程並行朝著多機協同的方向發展，從存儲和計算相分離朝著數據和計算緊密深度融合的方向發展，從計算密集型或者數據密集型朝著兩者混合的密集型方向發展，從靜態全量計算朝著動態流式計算的方向發展，這些變化都是大數據分析中將要面臨的理論和計算方面的挑戰。

在大數據分析與處理方面核心技術嚴重缺乏，我們熟悉的大數據處理核心技術的底層的核心軟體、核心系統，像Spark、Hadood、Hbase 這些著名的開源商用軟體幾乎全是被國外壟斷，我們國家在這個領域缺乏自己的自主知識產權。

D. idc機房是什麼

IDC機房是指互聯網數據中心機房。

互聯網數據中心（Internet Data Center）簡稱IDC，就是電信部門利用已有的互聯網通信線路、帶寬資源，建立標准化的電信專業級機房環境。

IDC不僅是數據存儲的中心，而且是數據流通的中心，它應該出現在Internet網路中數據交換最集中的地方。它是伴隨著人們對主機託管和虛擬主機服務提出了更高要求的狀況而產生的，從某種意義上說，它是由ISP的伺服器託管機房演變而來的。

(4)數據存儲屬於哪個部門擴展閱讀：

IDC機房的主要功能：

1、網站發布，單位通過託管主機，從電信部門分配到互聯網靜態IP地址後，即可發布自己的www站點，將自己的產品或服務通過互聯網廣泛宣傳。

2、虛擬主機是單位通過託管主機，將自己主機的海量硬碟空間出租，為其他客戶提供虛擬主機服務，使自己成為ICP服務提供商。

3、電子商務是指單位通過託管主機，建立自己的電子商務系統，通過這個商業平台來為供應商、批發商、經銷商和最終用戶提供完善的服務。

參考資料來源：網路-IDC機房

E. 數據監測屬於哪個部門

數據監測屬於監測部門。
監測部門：負責本區環境質量監測工作；管理和分析環境監測數據，發布空氣、水質量公報等工作；參與應急和環境污染事故糾紛的仲裁監測等工作，並對各環境保護監察所進行有關業務指導和相關工作考核等工作；做好局領導交辦的其它工作。

F. 倉庫數據核查屬於哪個部門

如3級運維體系，一級用戶自己查業務數據，二級是信息部運維組查，三級是數據倉庫供應商查數據；我所面對的企業是這樣的，我現在屬於第三級。用戶自己覺得數據倉庫的數據不對，自己收集的業務數據是對的，則會找運維組，運維組會去查信息流是否正常(如伺服器運轉是否正常、資料庫ETL是否正常)，如都正常，則會轉到數據倉庫供應商檢查是否程序bug或落掉了某個業務點。 可溝通交流，審計部是不會給你核查數據的，審計部主要看各部門是否做的合規，關心的主要是錢。 [email protected]

G. 數據分析員應該屬於公司哪個部門

所在部門：市場研究公司數據部上級職位：數據部經理
編輯本段
主要工作內容/職責/流程

1、根據數據分析方案進行數據分析，在既定時間內提交給市場研究人員；
2、能進行較高級的數據統計分析；
3、公司錄入人員的管理和業績考核；以及對編碼人員的行業知識和問卷結構的培訓；
4、錄入資料庫的設立，數據的校驗，資料庫的邏輯查錯，對部分問卷的核對；

H. 數據中心是什麼其系統結構和工作原理是怎樣的呢

一直想整理一下這塊內容，既然是漫談，就想起什麼說什麼吧。我一直是在互聯網行業，就以互聯網行業來說。
先大概列一下互聯網行業數據倉庫、數據平台的用途：

• 整合公司所有業務數據，建立統一的數據中心；

• 提供各種報表，有給高層的，有給各個業務的；

• 為網站運營提供運營上的數據支持，就是通過數據，讓運營及時了解網站和產品的運營效果；

• 為各個業務提供線上或線下的數據支持，成為公司統一的數據交換與提供平台；

• 分析用戶行為數據，通過數據挖掘來降低投入成本，提高投入效果；比如廣告定向精準投放、用戶個性化推薦等；

• 開發數據產品，直接或間接為公司盈利；

• 建設開放數據平台，開放公司數據；

• 。。。。。。



• 上面列出的內容看上去和傳統行業數據倉庫用途差不多，並且都要求數據倉庫/數據平台有很好的穩定性、可靠性；但在互聯網行業，除了數據量大之外，越來越多的業務要求時效性，甚至很多是要求實時的 ，另外，互聯網行業的業務變化非常快，不可能像傳統行業一樣，可以使用自頂向下的方法建立數據倉庫，一勞永逸，它要求新的業務很快能融入數據倉庫中來，老的下線的業務，能很方便的從現有的數據倉庫中下線；


• 其實，互聯網行業的數據倉庫就是所謂的敏捷數據倉庫，不但要求能快速的響應數據，也要求能快速的響應業務；


• 建設敏捷數據倉庫，除了對架構技術上的要求之外，還有一個很重要的方面，就是數據建模，如果一上來就想著建立一套能兼容所有數據和業務的數據模型，那就又回到傳統數據倉庫的建設上了，很難滿足對業務變化的快速響應。應對這種情況，一般是先將核心的持久化的業務進行深度建模（比如：基於網站日誌建立的網站統計分析模型和用戶瀏覽軌跡模型；基於公司核心用戶數據建立的用戶模型），其它的業務一般都採用維度+寬表的方式來建立數據模型。這塊是後話。


• 整體架構下面的圖是我們目前使用的數據平台架構圖，其實大多公司應該都差不多：


• 邏輯上，一般都有數據採集層、數據存儲與分析層、數據共享層、數據應用層。可能叫法有所不同，本質上的角色都大同小異。


• 我們從下往上看：


• 數據採集數據採集層的任務就是把數據從各種數據源中採集和存儲到數據存儲上，期間有可能會做一些簡單的清洗。



• 數據源的種類比較多：



• 網站日誌：



• 作為互聯網行業，網站日誌占的份額最大，網站日誌存儲在多台網站日誌伺服器上，


• 一般是在每台網站日誌伺服器上部署flume agent，實時的收集網站日誌並存儲到HDFS上；



• 業務資料庫：



• 業務資料庫的種類也是多種多樣，有Mysql、Oracle、SqlServer等，這時候，我們迫切的需要一種能從各種資料庫中將數據同步到HDFS上的工具，Sqoop是一種，但是Sqoop太過繁重，而且不管數據量大小，都需要啟動MapRece來執行，而且需要Hadoop集群的每台機器都能訪問業務資料庫；應對此場景，淘寶開源的DataX，是一個很好的解決方案（可參考文章 《異構數據源海量數據交換工具-Taobao DataX 下載和使用》），有資源的話，可以基於DataX之上做二次開發，就能非常好的解決，我們目前使用的DataHub也是。


• 當然，Flume通過配置與開發，也可以實時的從資料庫中同步數據到HDFS。



• 來自於Ftp/Http的數據源：



• 有可能一些合作夥伴提供的數據，需要通過Ftp/Http等定時獲取，DataX也可以滿足該需求；



• 其他數據源：



• 比如一些手工錄入的數據，只需要提供一個介面或小程序，即可完成；



• 數據存儲與分析毋庸置疑，HDFS是大數據環境下數據倉庫/數據平台最完美的數據存儲解決方案。



• 離線數據分析與計算，也就是對實時性要求不高的部分，在我看來，Hive還是首當其沖的選擇，豐富的數據類型、內置函數；壓縮比非常高的ORC文件存儲格式；非常方便的SQL支持，使得Hive在基於結構化數據上的統計分析遠遠比MapRece要高效的多，一句SQL可以完成的需求，開發MR可能需要上百行代碼；


• 當然，使用Hadoop框架自然而然也提供了MapRece介面，如果真的很樂意開發Java，或者對SQL不熟，那麼也可以使用MapRece來做分析與計算；Spark是這兩年非常火的，經過實踐，它的性能的確比MapRece要好很多，而且和Hive、Yarn結合的越來越好，因此，必須支持使用Spark和SparkSQL來做分析和計算。因為已經有Hadoop Yarn，使用Spark其實是非常容易的，不用單獨部署Spark集群，關於Spark On Yarn的相關文章，可參考：《Spark On Yarn系列文章》


• 實時計算部分，後面單獨說。


• 數據共享這里的數據共享，其實指的是前面數據分析與計算後的結果存放的地方，其實就是關系型資料庫和NOSQL資料庫；



• 前面使用Hive、MR、Spark、SparkSQL分析和計算的結果，還是在HDFS上，但大多業務和應用不可能直接從HDFS上獲取數據，那麼就需要一個數據共享的地方，使得各業務和產品能方便的獲取數據；和數據採集層到HDFS剛好相反，這里需要一個從HDFS將數據同步至其他目標數據源的工具，同樣，DataX也可以滿足。


• 另外，一些實時計算的結果數據可能由實時計算模塊直接寫入數據共享。



• 數據應用

• 業務產品
  



• 業務產品所使用的數據，已經存在於數據共享層，他們直接從數據共享層訪問即可；



• 報表



• 同業務產品，報表所使用的數據，一般也是已經統計匯總好的，存放於數據共享層；



• 即席查詢



• 即席查詢的用戶有很多，有可能是數據開發人員、網站和產品運營人員、數據分析人員、甚至是部門老大，他們都有即席查詢數據的需求；


• 這種即席查詢通常是現有的報表和數據共享層的數據並不能滿足他們的需求，需要從數據存儲層直接查詢。


• 即席查詢一般是通過SQL完成，最大的難度在於響應速度上，使用Hive有點慢，目前我的解決方案是SparkSQL，它的響應速度較Hive快很多，而且能很好的與Hive兼容。


• 當然，你也可以使用Impala，如果不在乎平台中再多一個框架的話。



• OLAP



• 目前，很多的OLAP工具不能很好的支持從HDFS上直接獲取數據，都是通過將需要的數據同步到關系型資料庫中做OLAP，但如果數據量巨大的話，關系型資料庫顯然不行；


• 這時候，需要做相應的開發，從HDFS或者HBase中獲取數據，完成OLAP的功能；


• 比如：根據用戶在界面上選擇的不定的維度和指標，通過開發介面，從HBase中獲取數據來展示。



• 其它數據介面
  



• 這種介面有通用的，有定製的。比如：一個從Redis中獲取用戶屬性的介面是通用的，所有的業務都可以調用這個介面來獲取用戶屬性。



• 實時計算現在業務對數據倉庫實時性的需求越來越多，比如：實時的了解網站的整體流量；實時的獲取一個廣告的曝光和點擊；在海量數據下，依靠傳統資料庫和傳統實現方法基本完成不了，需要的是一種分布式的、高吞吐量的、延時低的、高可靠的實時計算框架；Storm在這塊是比較成熟了，但我選擇Spark Streaming，原因很簡單，不想多引入一個框架到平台中，另外，Spark Streaming比Storm延時性高那麼一點點，那對於我們的需要可以忽略。


• 我們目前使用Spark Streaming實現了實時的網站流量統計、實時的廣告效果統計兩塊功能。


• 做法也很簡單，由Flume在前端日誌伺服器上收集網站日誌和廣告日誌，實時的發送給Spark Streaming，由Spark Streaming完成統計，將數據存儲至Redis，業務通過訪問Redis實時獲取。


• 任務調度與監控在數據倉庫/數據平台中，有各種各樣非常多的程序和任務，比如：數據採集任務、數據同步任務、數據分析任務等；



• 這些任務除了定時調度，還存在非常復雜的任務依賴關系，比如：數據分析任務必須等相應的數據採集任務完成後才能開始；數據同步任務需要等數據分析任務完成後才能開始；這就需要一個非常完善的任務調度與監控系統，它作為數據倉庫/數據平台的中樞，負責調度和監控所有任務的分配與運行。


• 前面有寫過文章，《大數據平台中的任務調度與監控》,這里不再累贅。


• 總結在我看來架構並不是技術越多越新越好，而是在可以滿足需求的情況下，越簡單越穩定越好。目前在我們的數據平台中，開發更多的是關注業務，而不是技術，他們把業務和需求搞清楚了，基本上只需要做簡單的SQL開發，然後配置到調度系統就可以了，如果任務異常，會收到告警。這樣，可以使更多的資源專注於業務之上。

I. 資料庫是什麼意思

資料庫需要從以下幾個方面去了解:

一、資料庫功能:

資料庫(Database)是按照數據結構來組織、存儲和管理數據的倉庫，它產生於距今六十多年前，隨著信息技術和市場的發展，特別是二十世紀九十年代以後，數據管理不再僅僅是存儲和管理數據，而轉變成用戶所需要的各種數據管理的方式。資料庫有很多種類型，從最簡單的存儲有各種數據的表格到能夠進行海量數據存儲的大型資料庫系統都在各個方面得到了廣泛的應用。

在信息化社會，充分有效地管理和利用各類信息資源，是進行科學研究和決策管理的前提條件。資料庫技術是管理信息系統、辦公自動化系統、決策支持系統等各類信息系統的核心部分，是進行科學研究和決策管理的重要技術手段。

二、資料庫定義1:

資料庫(Database)是按照數據結構來組織、存儲和管理數據的建立在計算機存儲設備上的倉庫。

簡單來說是本身可視為電子化的文件櫃——存儲電子文件的處所，用戶可以對文件中的數據進行新增、截取、更新、刪除等操作。

在經濟管理的日常工作中，常常需要把某些相關的數據放進這樣的「倉庫」，並根據管理的需要進行相應的處理。

例如，企業或事業單位的人事部門常常要把本單位職工的基本情況(職工號、姓名、年齡、性別、籍貫、工資、簡歷等)存放在表中，這張表就可以看成是一個資料庫。有了這個"數據倉庫"我們就可以根據需要隨時查詢某職工的基本情況，也可以查詢工資在某個范圍內的職工人數等等。這些工作如果都能在計算機上自動進行，那我們的人事管理就可以達到極高的水平。此外，在財務管理、倉庫管理、生產管理中也需要建立眾多的這種"資料庫"，使其可以利用計算機實現財務、倉庫、生產的自動化管理。

三、資料庫定義2:

嚴格來說，資料庫是長期儲存在計算機內、有組織的、可共享的數據集合。資料庫中的數據指的是以一定的數據模型組織、描述和儲存在一起、具有盡可能小的冗餘度、較高的數據獨立性和易擴展性的特點並可在一定范圍內為多個用戶共享。

這種數據集合具有如下特點：盡可能不重復，以最優方式為某個特定組織的多種應用服務，其數據結構獨立於使用它的應用程序，對數據的增、刪、改、查由統一軟體進行管理和控制。從發展的歷史看，資料庫是數據管理的高級階段，它是由文件管理系統發展起來的。

四、資料庫處理系統:

資料庫是一個單位或是一個應用領域的通用數據處理系統，它存儲的是屬於企業和事業部門、團體和個人的有關數據的集合。資料庫中的數據是從全局觀點出發建立的，按一定的數據模型進行組織、描述和存儲。其結構基於數據間的自然聯系，從而可提供一切必要的存取路徑，且數據不再針對某一應用，而是面向全組織，具有整體的結構化特徵。

資料庫中的數據是為眾多用戶所共享其信息而建立的，已經擺脫了具體程序的限制和制約。不同的用戶可以按各自的用法使用資料庫中的數據；多個用戶可以同時共享資料庫中的數據資源，即不同的用戶可以同時存取資料庫中的同一個數據。數據共享性不僅滿足了各用戶對信息內容的要求，同時也滿足了各用戶之間信息通信的要求。

五、資料庫基本結構:

資料庫的基本結構分三個層次，反映了觀察資料庫的三種不同角度。

以內模式為框架所組成的資料庫叫做物理資料庫；以概念模式為框架所組成的數據叫概念資料庫；以外模式為框架所組成的資料庫叫用戶資料庫。

⑴ 物理數據層。

它是資料庫的最內層，是物理存貯設備上實際存儲的數據的集合。這些數據是原始數據，是用戶加工的對象，由內部模式描述的指令操作處理的位串、字元和字組成。

⑵ 概念數據層。

它是資料庫的中間一層，是資料庫的整體邏輯表示。指出了每個數據的邏輯定義及數據間的邏輯聯系，是存貯記錄的集合。它所涉及的是資料庫所有對象的邏輯關系，而不是它們的物理情況，是資料庫管理員概念下的資料庫。

⑶ 用戶數據層。

它是用戶所看到和使用的資料庫，表示了一個或一些特定用戶使用的數據集合，即邏輯記錄的集合。

資料庫不同層次之間的聯系是通過映射進行轉換的。

六、資料庫主要特點:

⑴ 實現數據共享

數據共享包含所有用戶可同時存取資料庫中的數據，也包括用戶可以用各種方式通過介面使用資料庫，並提供數據共享。

⑵ 減少數據的冗餘度

同文件系統相比，由於資料庫實現了數據共享，從而避免了用戶各自建立應用文件。減少了大量重復數據，減少了數據冗餘，維護了數據的一致性。

⑶ 數據的獨立性

數據的獨立性包括邏輯獨立性（資料庫中資料庫的邏輯結構和應用程序相互獨立）和物理獨立性（數據物理結構的變化不影響數據的邏輯結構）。

⑷ 數據實現集中控制

文件管理方式中，數據處於一種分散的狀態，不同的用戶或同一用戶在不同處理中其文件之間毫無關系。利用資料庫可對數據進行集中控制和管理，並通過數據模型表示各種數據的組織以及數據間的聯系。

⑸數據一致性和可維護性，以確保數據的安全性和可靠性

主要包括：①安全性控制：以防止數據丟失、錯誤更新和越權使用；②完整性控制：保證數據的正確性、有效性和相容性；③並發控制：使在同一時間周期內，允許對數據實現多路存取，又能防止用戶之間的不正常交互作用。

⑹ 故障恢復

由資料庫管理系統提供一套方法，可及時發現故障和修復故障，從而防止數據被破壞。資料庫系統能盡快恢復資料庫系統運行時出現的故障，可能是物理上或是邏輯上的錯誤。比如對系統的誤操作造成的數據錯誤等。

七、資料庫數據種類:

資料庫通常分為層次式資料庫、網路式資料庫和關系式資料庫三種。而不同的資料庫是按不同的數據結構來聯系和組織的。

1.數據結構模型

⑴數據結構

所謂數據結構是指數據的組織形式或數據之間的聯系。

如果用D表示數據，用R表示數據對象之間存在的關系集合，則將DS=(D，R)稱為數據結構。

例如，設有一個電話號碼簿，它記錄了n個人的名字和相應的電話號碼。為了方便地查找某人的電話號碼，將人名和號碼按字典順序排列，並在名字的後面跟隨著對應的電話號碼。這樣，若要查找某人的電話號碼(假定他的名字的第一個字母是Y)，那麼只須查找以Y開頭的那些名字就可以了。該例中，數據的集合D就是人名和電話號碼，它們之間的聯系R就是按字典順序的排列，其相應的數據結構就是DS=(D，R)，即一個數組。

⑵數據結構類型

數據結構又分為數據的邏輯結構和數據的物理結構。

數據的邏輯結構是從邏輯的角度(即數據間的聯系和組織方式)來觀察數據，分析數據，與數據的存儲位置無關；數據的物理結構是指數據在計算機中存放的結構，即數據的邏輯結構在計算機中的實現形式，所以物理結構也被稱為存儲結構。

這里只研究數據的邏輯結構，並將反映和實現數據聯系的方法稱為數據模型。

比較流行的數據模型有三種，即按圖論理論建立的層次結構模型和網狀結構模型以及按關系理論建立的關系結構模型。

2.層次、網狀和關系資料庫系統

⑴層次結構模型

層次結構模型實質上是一種有根結點的定向有序樹(在數學中"樹"被定義為一個無回的連通圖)。下圖是一個高等學校的組織結構圖。這個組織結構圖像一棵樹，校部就是樹根(稱為根結點)，各系、專業、教師、學生等為枝點(稱為結點)，樹根與枝點之間的聯系稱為邊，樹根與邊之比為1:N，即樹根只有一個，樹枝有N個。

按照層次模型建立的資料庫系統稱為層次模型資料庫系統。IMS(Information Management System)是其典型代表。

⑵網狀結構模型

按照網狀數據結構建立的資料庫系統稱為網狀資料庫系統，其典型代表是DBTG(Database Task Group)。用數學方法可將網狀數據結構轉化為層次數據結構。

⑶ 關系結構模型

關系式數據結構把一些復雜的數據結構歸結為簡單的二元關系(即二維表格形式)。例如某單位的職工關系就是一個二元關系。

由關系數據結構組成的資料庫系統被稱為關系資料庫系統。

在關系資料庫中，對數據的操作幾乎全部建立在一個或多個關系表格上，通過對這些關系表格的分類、合並、連接或選取等運算來實現數據的管理。

dBASEⅡ就是這類資料庫管理系統的典型代表。對於一個實際的應用問題（如人事管理問題），有時需要多個關系才能實現。用dBASEⅡ建立起來的一個關系稱為一個資料庫（或稱資料庫文件），而把對應多個關系建立起來的多個資料庫稱為資料庫系統。dBASEⅡ的另一個重要功能是通過建立命令文件來實現對資料庫的使用和管理，對於一個資料庫系統相應的命令序列文件，稱為該資料庫的應用系統。

因此，可以概括地說，一個關系稱為一個資料庫，若干個資料庫可以構成一個資料庫系統。資料庫系統可以派生出各種不同類型的輔助文件和建立它的應用系統。

八、 資料庫類型:

網狀資料庫(Network Database)、關系資料庫(Relational Database)、樹狀資料庫(Hierarchical Database)、面向對象資料庫(Object-oriented Database)等。商業應用中主要是關系資料庫，比如Oracle、DB2、Sybase、MS SQL Server、Informax、MySQL等。

J. 現今各大小企業部門 財務等重要數據數據存儲的途徑有哪些

就內資一般企業都是使用用友或者金蝶來存儲財務數據的，外資企業的話用SAP、或者bean還有一些專業的ERP系統比較多，另外，關於你說的數據一般情況都有遠程備份或者多備份的方案。