 今天小編又挖到了他的一篇技術(shù)稿   圖2是一個使用hadoop構(gòu)建的完整現(xiàn)代數(shù)倉，展現(xiàn)了從數(shù)據(jù)接入、數(shù)據(jù)處理到數(shù)據(jù)展示的整體邏輯架構(gòu)。 左邊表示數(shù)據(jù)的ETL過程：實(shí)時數(shù)據(jù)一般通過Kafka等MQ進(jìn)入平臺；現(xiàn)有系統(tǒng)的存量數(shù)據(jù)、第三方數(shù)據(jù)及非/半結(jié)構(gòu)化數(shù)據(jù)通過文件傳輸方式進(jìn)入平臺；增量數(shù)據(jù)通過Sqoop、Kettle等ETL工具T+1進(jìn)入平臺，此外星環(huán)開發(fā)的TDA組件能夠幫助這部分?jǐn)?shù)據(jù)做到T+0的準(zhǔn)實(shí)時同步。所有數(shù)據(jù)最后匯總到右邊的數(shù)據(jù)倉庫。 關(guān)于數(shù)據(jù)倉庫內(nèi)部的數(shù)據(jù)處理我們有專題分享，這里不再贅述。 數(shù)據(jù)倉庫之上有五種類型的平臺分別支撐不同類型的應(yīng)用。 3.1 數(shù)據(jù)請求邏輯  4. 如果已經(jīng)有供數(shù)系統(tǒng)，則需要業(yè)務(wù)部門的領(lǐng)導(dǎo)在系統(tǒng)內(nèi)進(jìn)行權(quán)限審批，審批通過才能獲得數(shù)據(jù)。 在整個數(shù)據(jù)請求過程中，業(yè)務(wù)部門和科技部門權(quán)力多有交叉，數(shù)據(jù)層和系統(tǒng)層界限模糊不清，簡單的數(shù)據(jù)請求卻需要復(fù)雜的處理邏輯。 3.1.2. 改進(jìn)后邏輯  3. 通過則業(yè)務(wù)人員可以自助查詢數(shù)據(jù)。 整套流程都在統(tǒng)一建設(shè)的自助分析平臺之上，不再涉及科技部門和系統(tǒng)層面。業(yè)務(wù)部門只需要提數(shù)據(jù)需求，權(quán)限審批由專門的信息管理部門統(tǒng)一管理。信息管理部門根據(jù)平臺是否有這份數(shù)據(jù)、業(yè)務(wù)人員是否有權(quán)限獲取這份數(shù)據(jù)進(jìn)行審批。如果審批通過了，業(yè)務(wù)人員就可以自助查詢；如果拒絕，則直接結(jié)束。 3.2. 權(quán)限控制 首先，平臺需要4A認(rèn)證。所謂的4A就是Account、Authentication、Authorization和Audit。  如同傳統(tǒng)的關(guān)系型數(shù)據(jù)庫，Inceptor有基于角色的訪問控制（RBAC）。數(shù)據(jù)庫的建表查表權(quán)限、數(shù)據(jù)表的增刪改查權(quán)限都可以賦權(quán)給角色或個人。角色是一類特殊的權(quán)限集合，每種權(quán)限可以先賦予角色，再將角色賦予個人用戶，形成類似分組的權(quán)限管控。 平臺中有多種類型的數(shù)據(jù)，有些是客戶關(guān)系，有些是交易明細(xì)。這些表放在不同的庫的不同表中，從主題級別將不同的訪問權(quán)限賦予不同的用戶，如CRM信息賦予營銷人員、交易數(shù)據(jù)賦予財(cái)務(wù)人員。 在大數(shù)據(jù)場景下，有非常多的寬表，一張表中的信息量非常大，可能有幾十甚至上百個字段。如交易信息中，既有客戶身份證、手機(jī)號等敏感信息，也有交易額、數(shù)據(jù)源等非敏感信息。數(shù)據(jù)分析師只允許訪問非敏感信息，而管理員允許訪問敏感信息。該場景下需要讓不同用戶訪問同一張表的不同字段。在傳統(tǒng)的關(guān)系型數(shù)據(jù)庫中，往往通過建視圖的方式控制列級權(quán)限，但是如果權(quán)限分類一多，就會生成非常多的視圖難以管理。針對該場景，星環(huán)開發(fā)了列級權(quán)限，可以在原表上賦予不同用戶不同字段的訪問權(quán)限，方便管理。 3.3. 資源隔離 如果沒有計(jì)算資源隔離，一個用戶在分析平臺上提交了一個SQL任務(wù)，把計(jì)算資源占光，會影響其他用戶的正常使用。 因此需要限定每個用戶的計(jì)算資源。用戶提交任務(wù)時可以申請專有的資源池供自己使用。物理集群根據(jù)當(dāng)前是否有空閑的CPU和內(nèi)存等計(jì)算資源、當(dāng)前用戶是否有獨(dú)享資源的權(quán)限決定是否為其分配專有資源。如果沒有分配，當(dāng)前用戶只能使用共享資源進(jìn)行作業(yè)，根據(jù)作業(yè)優(yōu)先級分配到隊(duì)列里，進(jìn)行作業(yè)調(diào)度。一個虛擬集群里可以有多個隊(duì)列。  3.3.2. 存儲資源隔離 一個平臺的存儲空間是有限的，如果用戶無限放入文件，平臺很快就不堪重負(fù)。所以這里涉及到存儲資源的隔離。 C用戶分配的空間比較小，達(dá)到上限了，這時候就不允許上傳數(shù)據(jù)了。  一般的Hadoop解決方案中，大數(shù)據(jù)平臺只能調(diào)用存儲于HDFS和HBase之上的數(shù)據(jù)。然而有一些數(shù)據(jù)不適合從外部轉(zhuǎn)存到HDFS或HBase中，如頻繁改動的維度表，每次關(guān)聯(lián)之前都要從生產(chǎn)庫中將維度表完整的抽取過來再做關(guān)聯(lián)。  4.1. 整體邏輯架構(gòu)  圖9是星環(huán)常用的日志處理技術(shù)的完整邏輯框架。 數(shù)據(jù)源可以是各種應(yīng)用系統(tǒng)的日志，或網(wǎng)站的訪問信息。 5. 處理完的信息可以直接錄入持久化存儲層，如Inceptor、Hyperbase、ElasticSearch等。  在傳統(tǒng)的預(yù)警方案中，某個系統(tǒng)的預(yù)警線一般是一條水平線，但實(shí)際上機(jī)器的性能是會波動的，有忙時性能和閑時性能的區(qū)別。如果以固定的閾值作為監(jiān)控指標(biāo)缺少指導(dǎo)意義，因?yàn)槊r指標(biāo)總是偏高，閑時指標(biāo)總是偏低，無法判斷出性能異常。 硬件規(guī)劃是另一類日志分析的應(yīng)用場景。對于傳統(tǒng)的應(yīng)用，硬件大多是需要時增加即可，早一點(diǎn)晚一點(diǎn)成本區(qū)別不大。但是在大數(shù)據(jù)場景下，數(shù)據(jù)快速增長，硬件規(guī)模也很大，早采購可能導(dǎo)致硬件限制成本上升，晚采購可能導(dǎo)致存儲空間不足數(shù)據(jù)溢出，或是計(jì)算性能不足無法及時處理數(shù)據(jù)。 目前，關(guān)系型數(shù)據(jù)庫和Hadoop之間一般通過Sqoop增量抽取或數(shù)據(jù)文件傳輸?shù)确绞酵?。但是這種方案有一些問題。首先，調(diào)度比較復(fù)雜。其次，時間延遲比較大，現(xiàn)在一般只能做到T+1。 星環(huán)開發(fā)了一個準(zhǔn)實(shí)時的同步工具TDA（Transwarp Data Alive）： 4. HDFS上有調(diào)度監(jiān)控程序，將日志信息在Inceptor上重演一遍，完成從關(guān)系型數(shù)據(jù)庫到Hadoop的同步。 圖13. 準(zhǔn)實(shí)時同步技術(shù)實(shí)現(xiàn)T+0 ODS 最后附上大神的皂片供大家膜拜~
|
|
|
