idc架構

1、IDC基礎設施架構師是做什麼的？

很唬人的名字，不過實際工作就是機房網管。
這個東西還是有些門道的，如果沒有相關工作經驗，肯定沒法冒充有經驗。如果有思科之類的網管證書，那麼也算有優勢。如果沒有這些證書，那麼你只能拿網路知識來對付了，不過這個工作很需要經驗，沒有人帶過，直接上手困難。

2、"什麼是idc，什麼是伺服器

1、 IDC一般指互聯網數據中心
IDC為互聯網內容提供商（ICP）、企業、媒體和各類網站提供大規模、高質量、安全可靠的專業化伺服器託管、空間租用、網路批發帶寬以及ASP、EC等業務。IDC是對入駐（Hosting）企業、商戶或網站伺服器群託管的場所；是各種模式電子商務賴以安全運作的基礎設施，也是支持企業及其商業聯盟（其分銷商、供應商、客戶等）實施價值鏈管理的平台。 名詞解釋（業務理解非演講內容） ICP：互聯網信息服務，比如新浪、搜狐、網易。互聯網信息服務可分為經營性信息服務和非經營性信息服務兩類。
2、伺服器，也稱伺服器，是提供計算服務的設備。由於伺服器需要響應服務請求，並進行處理，因此一般來說伺服器應具備承擔服務並且保障服務的能力。
伺服器的構成包括處理器、硬碟、內存、系統匯流排等，和通用的計算機架構類似，但是由於需要提供高可靠的服務，因此在處理能力、穩定性、可靠性、安全性、可擴展性、可管理性等方面要求較高。
在網路環境下，根據伺服器提供的服務類型不同，分為文件伺服器，資料庫伺服器，應用程序伺服器，WEB伺服器等。

3、什麼是idc idc有什麼業務

互聯網數據中心（Internet Data Center）簡稱IDC，就是電信部門利用已有的互聯網通信線路、帶寬資源，建立標准化的電信專業級機房環境，為企業、政府提供伺服器託管、租用以及相關增值等方面的全方位服務。

IDC的業務簡介：

業務包括：主機、伺服器、託管、虛擬主機、域名注冊、企業郵局、郵件系統。

增值服務：主機託管、idc、大型知識庫、會員管理、系統集成、虛擬主機、sql資料庫、vpn虛擬專網、web 應用程序、電子支付、國際域名、國內域名、商業網站、網頁設計公司、web 服務、後台管理、郵件伺服器、網頁設計模板。

(3)idc架構擴展資料：

特徵：

IDC有兩個非常重要的顯著特徵：在網路中的位置和總的網路帶寬容量，它構成了網路基礎資源的一部分，就像骨幹網、接入網一樣，它提供了一種高端的數據傳輸(Data Delivery)的服務，提供高速接入的服務。

IDC起源於ICP對網路高速互聯的需求，而且美國仍然處於世界領導者位置。在美國，運營商為了維護自身利益，將網路互聯帶寬設得很低，用戶不得不在每個服務商處都放一台伺服器。為了解決這個問題，IDC應運而生，保證客戶託管的伺服器從各個網路訪問速度都沒有瓶頸。

4、數據中心概念

數據中心是全球協作的特定設備網路，用來在internet網路基礎設施上傳遞、加速、展示、計算、存儲數據信息。

數據中心是一整套復雜的設施。它不僅僅包括計算機系統和其它與之配套的設備（例如通信和存儲系統），還包含冗餘的數據通信連接、環境控制設備、監控設備以及各種安全裝置」。

數據中心就像多功能的建築物，能容納多個伺服器以及通信設備。這些設備被放置在一起是因為它們具有相同的對環境的要求以及物理安全上的需求，並且這樣放置便於維護」，而「並不僅僅是一些伺服器的集合"。

5、數據中心架構圖怎麼畫？

看了 很多下面這個應該是最標準的，參照畫就可以了額。工具嘛viso 即可

6、什麼是數據中心?

數據中心可以分為二種，一是可以上網，也就是可以訪問公網的，二是不上網，只用做數據存放；也就是我們通俗講的IDC/DC。
IDC 通常可以被定義為一
種擁有完善的設備（包括高速互聯網接入帶寬、高性能區域網
絡、安全可靠的機房環境等）、專業化的管理、完善的應用級服
務的服務平台
DC常被和DR放在一起，這種數據中心主要是用做數據備份，冗餘，數據恢復之用.

7、IDC基礎運維和IT運維的區別？

1.普通運維（伺服器、存儲、網路管理等）的基礎上，加強了對具體的軟體產品的了解，能與研發工程師一起進行軟硬體部署架構的設計、性能測試、產品部署上線、平時產品線上的故障監測和偵錯等工作。

2.所以除了基本的伺服器、資料庫操作能力之外，還需要了解一些軟體設計、性能測試優化的知識，如果有相關行業領域里的知識和腳本編寫能力就更好了。

3.通過監控和偵錯保證產品的穩定性，降低故障發生率，進而提高產品的運維效率，降低運維的支出，這些可以看作考核應用運維的幾個方面。

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

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

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

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

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

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

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

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

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

。。。。。。

上面列出的內容看上去和傳統行業數據倉庫用途差不多，並且都要求數據倉庫/數據平台有很好的穩定性、可靠性；但在互聯網行業，除了數據量大之外，越來越多的業務要求時效性，甚至很多是要求實時的 ，另外，互聯網行業的業務變化非常快，不可能像傳統行業一樣，可以使用自頂向下的方法建立數據倉庫，一勞永逸，它要求新的業務很快能融入數據倉庫中來，老的下線的業務，能很方便的從現有的數據倉庫中下線；
其實，互聯網行業的數據倉庫就是所謂的敏捷數據倉庫，不但要求能快速的響應數據，也要求能快速的響應業務；
建設敏捷數據倉庫，除了對架構技術上的要求之外，還有一個很重要的方面，就是數據建模，如果一上來就想著建立一套能兼容所有數據和業務的數據模型，那就又回到傳統數據倉庫的建設上了，很難滿足對業務變化的快速響應。應對這種情況，一般是先將核心的持久化的業務進行深度建模（比如：基於網站日誌建立的網站統計分析模型和用戶瀏覽軌跡模型；基於公司核心用戶數據建立的用戶模型），其它的業務一般都採用維度+寬表的方式來建立數據模型。這塊是後話。
整體架構下面的圖是我們目前使用的數據平台架構圖，其實大多公司應該都差不多：

請點擊輸入圖片描述

邏輯上，一般都有數據採集層、數據存儲與分析層、數據共享層、數據應用層。可能叫法有所不同，本質上的角色都大同小異。
我們從下往上看：
數據採集數據採集層的任務就是把數據從各種數據源中採集和存儲到數據存儲上，期間有可能會做一些簡單的清洗。

數據源的種類比較多：

網站日誌：

作為互聯網行業，網站日誌占的份額最大，網站日誌存儲在多台網站日誌伺服器上，
一般是在每台網站日誌伺服器上部署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開發，然後配置到調度系統就可以了，如果任務異常，會收到告警。這樣，可以使更多的資源專注於業務之上。