一、背景

事情是從公司前段時間的需求說起边篮，大家知道宜信是一個互聯(lián)網(wǎng)金融企業(yè)鸽凶，我們的很多數(shù)據(jù)與標(biāo)準(zhǔn)互聯(lián)網(wǎng)企業(yè)不同，大致來說就是：

玩數(shù)據(jù)的人都知道數(shù)據(jù)是非常有價值的，然后這些數(shù)據(jù)是保存在各個系統(tǒng)的數(shù)據(jù)庫中琉挖，如何讓需要數(shù)據(jù)的使用方得到一致性启泣、實時的數(shù)據(jù)呢?

過去的通用做法有幾種是：

DBA開放各個系統(tǒng)的備庫，在業(yè)務(wù)低峰期(比如夜間)示辈，使用方各自抽取所需數(shù)據(jù)寥茫。由于抽取時間不同，各個數(shù)據(jù)使用方數(shù)據(jù)不一致矾麻，數(shù)據(jù)發(fā)生沖突纱耻，而且重復(fù)抽取，相信不少DBA很頭疼這個事情险耀。

公司統(tǒng)一的大數(shù)據(jù)平臺弄喘，通過Sqoop 在業(yè)務(wù)低峰期到各個系統(tǒng)統(tǒng)一抽取數(shù)據(jù)， 并保存到Hive表中, 然后為其他數(shù)據(jù)使用方提供數(shù)據(jù)服務(wù)甩牺。這種做法解決了一致性問題蘑志，但時效性差，基本是T+1的時效贬派。

基于trigger的方式獲取增量變更卖漫，主要問題是業(yè)務(wù)方侵入性大，而且trigger也帶來性能損失赠群。

這些方案都不算完美羊始。我們在了解和考慮了不同實現(xiàn)方式后，最后借鑒了 linkedin的思想查描，認(rèn)為要想同時解決數(shù)據(jù)一致性和實時性突委，比較合理的方法應(yīng)該是來自于log。

(此圖來自：https://www.confluent.io/blog/using-logs-to-build-a-solid-data-infrastructure-or-why-dual-writes-are-a-bad-idea/)

把增量的Log作為一切系統(tǒng)的基礎(chǔ)冬三。后續(xù)的數(shù)據(jù)使用方匀油，通過訂閱kafka來消費log。

比如：

大數(shù)據(jù)的使用方可以將數(shù)據(jù)保存到Hive表或者Parquet文件給Hive或Spark查詢;

提供搜索服務(wù)的使用方可以保存到Elasticsearch或HBase 中;

提供緩存服務(wù)的使用方可以將日志緩存到Redis或alluxio中;

數(shù)據(jù)同步的使用方可以將數(shù)據(jù)保存到自己的數(shù)據(jù)庫中;

由于kafka的日志是可以重復(fù)消費的勾笆，并且緩存一段時間敌蚜，各個使用方可以通過消費kafka的日志來達(dá)到既能保持與數(shù)據(jù)庫的一致性，也能保證實時性;

為什么使用log和kafka作為基礎(chǔ)窝爪，而不使用Sqoop進(jìn)行抽取呢? 因為：

為什么不使用dual write(雙寫)呢?弛车，請參考https://www.confluent.io/blog/using-logs-to-build-a-solid-data-infrastructure-or-why-dual-writes-are-a-bad-idea/

我這里就不多做解釋了。

二蒲每、總體架構(gòu)

于是我們提出了構(gòu)建一個基于log的公司級的平臺的想法纷跛。

下面解釋一下DWS平臺， DWS平臺是有3個子項目組成：

Dbus(數(shù)據(jù)總線)：負(fù)責(zé)實時將數(shù)據(jù)從源端實時抽出邀杏，并轉(zhuǎn)換為約定的自帶schema的json格式數(shù)據(jù)(UMS 數(shù)據(jù))贫奠，放入kafka中;

Wormhole(數(shù)據(jù)交換平臺)：負(fù)責(zé)從kafka讀出數(shù)據(jù) 將數(shù)據(jù)寫入到目標(biāo)中;

Swifts(實時計算平臺)：負(fù)責(zé)從kafka中讀出數(shù)據(jù)，實時計算，并將數(shù)據(jù)寫回kafka中唤崭。

圖中：

Log extractor和dbus共同完成數(shù)據(jù)抽取和數(shù)據(jù)轉(zhuǎn)換拷恨，抽取包括全量和增量抽取。

Wormhole可以將所有日志數(shù)據(jù)保存到HDFS中; 還可以將數(shù)據(jù)落地到所有支持jdbc的數(shù)據(jù)庫谢肾，落地到HBash挑随，Elasticsearch，Cassandra等;

Swifts支持以配置和SQL的方式實現(xiàn)對進(jìn)行流式計算勒叠，包括支持流式j(luò)oin兜挨，look up，filter眯分，window aggregation等功能;

Dbus web是dbus的配置管理端拌汇，rider除了配置管理以外，還包括對Wormhole和Swifts運行時管理弊决，數(shù)據(jù)質(zhì)量校驗等噪舀。

由于時間關(guān)系，我今天主要介紹DWS中的Dbus和Wormhole飘诗，在需要的時候附帶介紹一下Swifts与倡。

三、dbus解決方案

日志解析

如前面所說昆稿，Dbus主要解決的是將日志從源端實時的抽出纺座。 這里我們以MySQL為例子，簡單說明如何實現(xiàn)溉潭。

我們知道净响，雖然MySQL InnoDB有自己的log州泊，MySQL主備同步是通過binlog來實現(xiàn)的御毅。如下圖：

圖片來自：https://github.com/alibaba/canal

而binlog有三種模式：

Row 模式：日志中會記錄成每一行數(shù)據(jù)被修改的形式，然后在slave端再對相同的數(shù)據(jù)進(jìn)行修改滤馍。

Statement 模式: 每一條會修改數(shù)據(jù)的sql都會記錄到 master的bin-log中畏陕。slave在復(fù)制的時候SQL進(jìn)程會解析成和原來master端執(zhí)行過的相同的SQL來再次執(zhí)行配乓。

Mixed模式： MySQL會根據(jù)執(zhí)行的每一條具體的sql語句來區(qū)分對待記錄的日志形式，也就是在Statement和Row之間選擇一種惠毁。

他們各自的優(yōu)缺點如下：

此處來自：http://www.jquerycn.cn/a_13625

由于statement 模式的缺點犹芹，在與我們的DBA溝通過程中了解到，實際生產(chǎn)過程中都使用row 模式進(jìn)行復(fù)制仁讨。這使得讀取全量日志成為可能羽莺。

通常我們的MySQL布局是采用 2個master主庫(vip)+ 1個slave從庫 + 1個backup容災(zāi)庫 的解決方案，由于容災(zāi)庫通常是用于異地容災(zāi)洞豁，實時性不高也不便于部署。

為了最小化對源端產(chǎn)生影響，顯然我們讀取binlog日志應(yīng)該從slave從庫讀取丈挟。

讀取binlog的方案比較多刁卜，github上不少，參考https://github.com/search?utf8=%E2%9C%93&q=binlog曙咽。最終我們選用了阿里的canal做位日志抽取方蛔趴。

Canal最早被用于阿里中美機房同步， canal原理相對比較簡單：

Canal模擬MySQL Slave的交互協(xié)議例朱，偽裝自己為MySQL Slave孝情，向MySQL Slave發(fā)送dump協(xié)議

MySQL master收到dump請求，開始推送binary log給Slave(也就是canal)

Canal解析binary log對象(原始為byte流)

圖片來自：https://github.com/alibaba/canal

解決方案

Dbus 的MySQL版主要解決方案如下：

對于增量的log洒嗤，通過訂閱Canal Server的方式箫荡，我們得到了MySQL的增量日志：

按照Canal的輸出，日志是protobuf格式渔隶，開發(fā)增量Storm程序羔挡，將數(shù)據(jù)實時轉(zhuǎn)換為我們定義的UMS格式(json格式,稍后我會介紹)，并保存到kafka中;

增量Storm程序還負(fù)責(zé)捕獲schema變化间唉，以控制版本號;

增量Storm的配置信息保存在Zookeeper中绞灼，以滿足高可用需求。

Kafka既作為輸出結(jié)果也作為處理過程中的緩沖器和消息解構(gòu)區(qū)呈野。

在考慮使用Storm作為解決方案的時候低矮，我們主要是認(rèn)為Storm有以下優(yōu)點：

技術(shù)相對成熟，比較穩(wěn)定被冒，與kafka搭配也算標(biāo)準(zhǔn)組合;

實時性比較高商佛，能夠滿足實時性需求;

滿足高可用需求;

通過配置Storm并發(fā)度，可以活動性能擴(kuò)展的能力;

全量抽取

對于流水表姆打，有增量部分就夠了良姆，但是許多表需要知道最初(已存在)的信息。這時候我們需要initial load(第一次加載)幔戏。

對于initial load(第一次加載)玛追，同樣開發(fā)了全量抽取Storm程序通過jdbc連接的方式，從源端數(shù)據(jù)庫的備庫進(jìn)行拉取闲延。initial load是拉全部數(shù)據(jù)痊剖，所以我們推薦在業(yè)務(wù)低峰期進(jìn)行。好在只做一次垒玲，不需要每天都做陆馁。

全量抽取，我們借鑒了Sqoop的思想合愈。將全量抽取Storm分為了2 個部分：

數(shù)據(jù)分片

實際抽取

數(shù)據(jù)分片需要考慮分片列叮贩，按照配置和自動選擇列將數(shù)據(jù)按照范圍來分片击狮，并將分片信息保存到kafka中。

下面是具體的分片策略：

全量抽取的Storm程序是讀取kafka的分片信息益老，采用多個并發(fā)度并行連接數(shù)據(jù)庫備庫進(jìn)行拉取彪蓬。因為抽取的時間可能很長。抽取過程中將實時狀態(tài)寫到Zookeeper中捺萌，便于心跳程序監(jiān)控档冬。

統(tǒng)一消息格式

無論是增量還是全量，最終輸出到kafka中的消息都是我們約定的一個統(tǒng)一消息格式,稱為UMS(unified message schema)格式桃纯。

如下圖所示：

消息中schema部分酷誓，定義了namespace 是由 類型+數(shù)據(jù)源名+schema名+表名+版本號+分庫號+分表號 能夠描述整個公司的所有表，通過一個namespace就能唯一定位态坦。

_ums_op_ 表明數(shù)據(jù)的類型是I(insert)盐数，U(update)，D(刪除);

_ums_ts_ 發(fā)生增刪改的事件的時間戳驮配，顯然新的數(shù)據(jù)發(fā)生的時間戳更新;

_ums_id_ 消息的唯一id娘扩，保證消息是唯一的，但這里我們保證了消息的先后順序(稍后解釋);

payload是指具體的數(shù)據(jù)壮锻，一個json包里面可以包含1條至多條數(shù)據(jù)琐旁，提高數(shù)據(jù)的有效載荷。

UMS中支持的數(shù)據(jù)類型猜绣，參考了Hive類型并進(jìn)行簡化灰殴，基本上包含了所有數(shù)據(jù)類型。

全量和增量的一致性

在整個數(shù)據(jù)傳輸中掰邢，為了盡量的保證日志消息的順序性牺陶，kafka我們使用的是1個partition的方式。在一般情況下辣之，基本上是順序的和唯一的掰伸。

但是我們知道寫kafka會失敗，有可能重寫怀估，Storm也用重做機制狮鸭，因此，我們并不嚴(yán)格保證exactly once和完全的順序性多搀，但保證的是at least once歧蕉。

因此_ums_id_變得尤為重要。

對于全量抽取康铭，_ums_id_是唯一的惯退，從zk中每個并發(fā)度分別取不同的id片區(qū)，保證了唯一性和性能从藤，填寫負(fù)數(shù)催跪，不會與增量數(shù)據(jù)沖突锁蠕，也保證他們是早于增量消息的。

對于增量抽取叠荠，我們使用的是MySQL的日志文件號 + 日志偏移量作為唯一id匿沛。Id作為64位的long整數(shù)扫责，高7位用于日志文件號榛鼎，低12位作為日志偏移量。

例如：000103000012345678鳖孤。 103 是日志文件號者娱，12345678 是日志偏移量。

這樣苏揣，從日志層面保證了物理唯一性(即便重做也這個id號也不變)黄鳍，同時也保證了順序性(還能定位日志)。通過比較_ums_id_ 消費日志就能通過比較_ums_id_知道哪條消息更新平匈。

其實_ums_ts_與_ums_id_意圖是類似的框沟，只不過有時候_ums_ts_可能會重復(fù),即在1毫秒中發(fā)生了多個操作，這樣就得靠比較_ums_id_了增炭。

心跳監(jiān)控和預(yù)警

整個系統(tǒng)涉及到數(shù)據(jù)庫的主備同步忍燥，Canal Server，多個并發(fā)度Storm進(jìn)程等各個環(huán)節(jié)隙姿。

因此對流程的監(jiān)控和預(yù)警就尤為重要梅垄。

通過心跳模塊，例如每分鐘(可配置)對每個被抽取的表插入一條心態(tài)數(shù)據(jù)并保存發(fā)送時間输玷，這個心跳表也被抽取队丝，跟隨著整個流程下來，與被同步表在實際上走相同的邏輯(因為多個并發(fā)的的Storm可能有不同的分支)欲鹏，當(dāng)收到心跳包的時候机久，即便沒有任何增刪改的數(shù)據(jù)，也能證明整條鏈路是通的赔嚎。

Storm程序和心跳程序?qū)?shù)據(jù)發(fā)送公共的統(tǒng)計topic膘盖，再由統(tǒng)計程序保存到influxdb中，使用grafana進(jìn)行展示尽狠，就可以看到如下效果：

圖中是某業(yè)務(wù)系統(tǒng)的實時監(jiān)控信息衔憨。上面是實時流量情況，下面是實時延時情況袄膏〖迹可以看到，實時性還是很不錯的沉馆，基本上1~2秒數(shù)據(jù)就已經(jīng)到末端kafka中码党。

Granfana提供的是一種實時監(jiān)控能力德崭。

如果出現(xiàn)延時，則是通過dbus的心跳模塊發(fā)送郵件報警或短信報警揖盘。

實時脫敏

考慮到數(shù)據(jù)安全性眉厨，對于有脫敏需求的場景，Dbus的全量storm和增量storm程序也完成了實時脫敏的功能兽狭。脫敏方式有3種：

總結(jié)一下：簡單的說憾股，Dbus就是將各種源的數(shù)據(jù)，實時的導(dǎo)出箕慧，并以UMS的方式提供訂閱服球， 支持實時脫敏，實際監(jiān)控和報警颠焦。

四斩熊、Wormhole解決方案

說完Dbus，該說一下Wormhole伐庭，為什么兩個項目不是一個粉渠，而要通過kafka來對接呢?

其中很大一個原因就是解耦，kafka具有天然的解耦能力圾另，程序直接可以通過kafka做異步的消息傳遞霸株。Dbus和Wornhole內(nèi)部也使用了kafka做消息傳遞和解耦。

另外一個原因就是盯捌，UMS是自描述的淳衙，通過訂閱kafka，任何有能力的使用方來直接消費UMS來使用饺著。

雖然UMS的結(jié)果可以直接訂閱箫攀，但還需要開發(fā)的工作。Wormhole解決的是：提供一鍵式的配置幼衰，將kafka中的數(shù)據(jù)落地到各種系統(tǒng)中靴跛，讓沒有開發(fā)能力的數(shù)據(jù)使用方通過wormhole來實現(xiàn)使用數(shù)據(jù)。

如圖所示渡嚣，Wormhole 可以將kafka中的UMS 落地到各種系統(tǒng)梢睛，目前用的最多的HDFS，JDBC的數(shù)據(jù)庫和HBase识椰。

在技術(shù)棧上绝葡， wormhole選擇使用spark streaming來進(jìn)行。

在Wormhole中腹鹉，一條flow是指從一個namaspace從源端到目標(biāo)端藏畅。一個spark streaming服務(wù)于多條flow。

選用Spark的理由是很充分的：

Spark天然的支持各種異構(gòu)存儲系統(tǒng);

雖然Spark Stream比Storm延時稍差功咒，但Spark有著更好的吞吐量和更好的計算性能;

Spark在支持并行計算方面有更強的靈活性;

Spark提供了一個技術(shù)棧內(nèi)解決Sparking Job愉阎，Spark Streaming绞蹦，Spark SQL的統(tǒng)一功能，便于后期開發(fā);

這里補充說一下Swifts的作用：

Swifts的本質(zhì)是讀取kafka中的UMS數(shù)據(jù)榜旦，進(jìn)行實時計算幽七，將結(jié)果寫入到kafka的另外一個topic。

實時計算可以是很多種方式：比如過濾filter溅呢，projection(投影)澡屡，lookup， 流式j(luò)oin window aggregation藕届，可以完成各種具有業(yè)務(wù)價值的流式實時計算挪蹭。

Wormhole和Swifts對比如下：

落HDFS

通過Wormhole Wpark Streaming程序消費kafka的UMS亭饵，首先UMS log可以被保存到HDFS上休偶。

kafka一般只保存若干天的信息，不會保存全部信息辜羊，而HDFS中可以保存所有的歷史增刪改的信息踏兜。這就使得很多事情變?yōu)榭赡埽?/p>

通過重放HDFS中的日志，我們能夠還原任意時間的歷史快照八秃。

可以做拉鏈表碱妆，還原每一條記錄的歷史信息，便于分析;

當(dāng)程序出現(xiàn)錯誤是昔驱，可以通過回灌(backfill)疹尾，重新消費消息，重新形成新的快照骤肛。

可以說HDFS中的日志是很多的事情基礎(chǔ)纳本。

介于Spark原生對parquet支持的很好，Spark SQL能夠?qū)arquet提供很好的查詢腋颠。UMS落地到HDFS上是保存到Parquet文件中的繁成。Parquet的內(nèi)容是所有l(wèi)og的增刪改信息以及_ums_id_，_ums_ts_都存下來淑玫。

Wormhole spark streaming根據(jù)namespace 將數(shù)據(jù)分布存儲到不同的目錄中巾腕，即不同的表和版本放在不同目錄中。

由于每次寫的Parquet都是小文件絮蒿，大家知道HDFS對于小文件性能并不好尊搬，因此另外還有一個job，每天定時將這些的Parquet文件進(jìn)行合并成大文件土涝。

每個Parquet文件目錄都帶有文件數(shù)據(jù)的起始時間和結(jié)束時間佛寿。這樣在回灌數(shù)據(jù)時，可以根據(jù)選取的時間范圍來決定需要讀取哪些Parquet文件回铛，不必讀取全部數(shù)據(jù)狗准。

插入或更新數(shù)據(jù)的冪等性

常常我們遇到的需求是克锣，將數(shù)據(jù)經(jīng)過加工落地到數(shù)據(jù)庫或HBase中。那么這里涉及到的一個問題就是腔长，什么樣的數(shù)據(jù)可以被更新到數(shù)據(jù)?

這里最重要的一個原則就是數(shù)據(jù)的冪等性袭祟。

無論是遇到增刪改任何的數(shù)據(jù)，我們面臨的問題都是：

該更新哪一行;

更新的策略是什么捞附。

對于第一個問題巾乳，其實就需要定位數(shù)據(jù)要找一個唯一的鍵，常見的有：

使用業(yè)務(wù)庫的主鍵;

由業(yè)務(wù)方指定幾個列做聯(lián)合唯一索引;

對于第二個問題鸟召，就涉及到_ums_id_了胆绊，因為我們已經(jīng)保證了_ums_id_大的值更新，因此在找到對應(yīng)數(shù)據(jù)行后欧募，根據(jù)這個原則來進(jìn)行替換更新压状。

之所以要軟刪除和加入_is_active_列，是為了這樣一種情況：

如果已經(jīng)插入的_ums_id_比較大跟继，是刪除的數(shù)據(jù)(表明這個數(shù)據(jù)已經(jīng)刪除了)种冬， 如果不是軟刪除，此時插入一個_ums_id_小的數(shù)據(jù)(舊數(shù)據(jù))舔糖，就會真的插入進(jìn)去娱两。

這就導(dǎo)致舊數(shù)據(jù)被插入了。不冪等了金吗。所以被刪除的數(shù)據(jù)依然保留(軟刪除)是有價值的十兢，它能被用于保證數(shù)據(jù)的冪等性。

HBase的保存

插入數(shù)據(jù)到Hbase中摇庙，相當(dāng)要簡單一些旱物。不同的是HBase可以保留多個版本的數(shù)據(jù)(當(dāng)然也可以只保留一個版本)默認(rèn)是保留3個版本;

因此插入數(shù)據(jù)到HBase，需要解決的問題是：

選擇合適的rowkey：Rowkey的設(shè)計是可以選的跟匆，用戶可以選擇源表的主鍵异袄，也可以選擇若干列做聯(lián)合主鍵。

選擇合適的version：使用_ums_id_+ 較大的偏移量(比如100億) 作為row的version玛臂。

Version的選擇很有意思烤蜕，利用_ums_id_的唯一性和自增性，與version自身的比較關(guān)系一致：即version較大等價于_ums_id_較大迹冤，對應(yīng)的版本較新讽营。

從提高性能的角度，我們可以將整個Spark Streaming的Dataset集合直接插入到HBase泡徙，不需要比較橱鹏。讓HBase基于version自動替我們判斷哪些數(shù)據(jù)可以保留，哪些數(shù)據(jù)不需要保留。

Jdbc的插入數(shù)據(jù)：

插入數(shù)據(jù)到數(shù)據(jù)庫中莉兰，保證冪等的原理雖然簡單挑围，要想提高性能在實現(xiàn)上就變得復(fù)雜很多，總不能一條一條的比較然后在插入或更新糖荒。

我們知道Spark的RDD/dataset都是以集合的方式來操作以提高性能杉辙，同樣的我們需要以集合操作的方式實現(xiàn)冪等性。

具體思路是：

首先根據(jù)集合中的主鍵到目標(biāo)數(shù)據(jù)庫中查詢捶朵，得到一個已有數(shù)據(jù)集合;

與dataset中的集合比較蜘矢，分出兩類：

A：不存在的數(shù)據(jù)，即這部分?jǐn)?shù)據(jù)insert就可以;

B：存在的數(shù)據(jù)综看，比較_ums_id_品腹， 最終只將哪些_ums_id_更新較大row到目標(biāo)數(shù)據(jù)庫，小的直接拋棄红碑。

使用Spark的同學(xué)都知道舞吭，RDD/dataset都是可以partition的，可以使用多個worker并進(jìn)行操作以提高效率句喷。

在考慮并發(fā)情況下镣典，插入和更新都可能出現(xiàn)失敗，那么還有考慮失敗后的策略唾琼。

比如：因為別的worker已經(jīng)插入，那么因為唯一性約束插入失敗澎剥，那么需要改為更新锡溯，還要比較_ums_id_看是否能夠更新。

對于無法插入其他情況(比如目標(biāo)系統(tǒng)有問題)哑姚，Wormhole還有重試機制祭饭。說起來細(xì)節(jié)特別多。這里就不多介紹了叙量。

有些還在開發(fā)中倡蝙。

插入到其他存儲中的就不多介紹了，總的原則是：根據(jù)各自存儲自身特性绞佩，設(shè)計基于集合的寺鸥，并發(fā)的插入數(shù)據(jù)實現(xiàn)。這些都是Wormhole為了性能而做的努力品山，使用Wormhole的用戶不必關(guān)心 胆建。

五、運用案例

實時營銷

說了那么多肘交，DWS有什么實際運用呢?下面我來介紹某系統(tǒng)使用DWS實現(xiàn)了的實時營銷笆载。

如上圖所示：

系統(tǒng)A的數(shù)據(jù)都保存到自己的數(shù)據(jù)庫中，我們知道，宜信提供很多金融服務(wù)凉驻，其中包括借款腻要，而借款過程中很重要的就是信用審核。

借款人需要提供證明具有信用價值的信息涝登，比如央行征信報告闯第，是具有最強信用數(shù)據(jù)的數(shù)據(jù)。 而銀行流水缀拭，網(wǎng)購流水也是具有較強的信用屬性的數(shù)據(jù)咳短。

借款人通過Web或手機APP在系統(tǒng)A中填寫信用信息時，可能會某些原因無法繼續(xù)蛛淋，雖然可能這個借款人是一個優(yōu)質(zhì)潛在客戶咙好，但以前由于無法或很久才能知道這個信息，所以實際上這樣的客戶是流失了褐荷。

應(yīng)用了DWS以后勾效，借款人已經(jīng)填寫的信息已經(jīng)記錄到數(shù)據(jù)庫中，并通過DWS實時的進(jìn)行抽取叛甫、計算和落地到目標(biāo)庫中层宫。根據(jù)對客戶的打分，評價出優(yōu)質(zhì)客戶其监。然后立刻將這個客戶的信息輸出到客服系統(tǒng)中萌腿。

客服人員在很短的時間(幾分鐘以內(nèi))就通過打電話的方式聯(lián)系上這個借款人(潛客)，進(jìn)行客戶關(guān)懷抖苦，將這個潛客轉(zhuǎn)換為真正的客戶毁菱。我們知道借款是有時效性的，如果時間太久就沒有價值了锌历。

如果沒有實時抽取/計算/落庫的能力贮庞，那么這一切都無法實現(xiàn)。

實時報表系統(tǒng)

另外一個實時報表的應(yīng)用如下：

我們數(shù)據(jù)使用方的數(shù)據(jù)來自多個系統(tǒng)究西，以前是通過T+1的方式獲得報表信息窗慎，然后指導(dǎo)第二天的運營，這樣時效性很差卤材。

通過DWS遮斥，將數(shù)據(jù)從多個系統(tǒng)中實時抽取，計算和落地商膊，并提供報表展示伏伐，使得運營可以及時作出部署和調(diào)整，快速應(yīng)對晕拆。

六藐翎、總結(jié)

說了那么多材蹬，大致總結(jié)一下：

DWS技術(shù)上基于主流實時流式大數(shù)據(jù)技術(shù)框架，高可用大吞吐強水平擴(kuò)容吝镣，低延遲高容錯最終一致堤器。

DWS能力上支持異構(gòu)多源多目標(biāo)系統(tǒng)，支持多數(shù)據(jù)格式(結(jié)構(gòu)化半結(jié)構(gòu)化非結(jié)構(gòu)化數(shù)據(jù))和實時技術(shù)能力末贾。

DWS將三個子項目合并作為一個平臺推出闸溃，使得我們具備了實時的能力， 驅(qū)動各種實時場景應(yīng)用拱撵。

適合場景包括：實時同步/實時計算/實時監(jiān)控/實時報表/實時分析/實時洞察/實時管理/實時運營/實時決策

感謝大家的聆聽辉川，此次分享到此為止。

Q&A

Q1：Oracle log reader有開源方案嗎?

A1：對于Oracle業(yè)界也有許多商業(yè)解決方案拴测，例如：Oracle GoldenGate(原來的goldengate), Oracle Xstream, IBM InfoSphere Change Data Capture(原來的DataMirror)乓旗，Dell SharePlex (原來的Quest)，國內(nèi)的DSG superSync等集索，開源的方案好用的很少屿愚。

Q2：這個項目投入了多少人力物力?感覺有點復(fù)雜。

Q2：DWS是三個子項目組成务荆，平均每個項目5~7人妆距。是有點復(fù)雜，其實也是試圖使用大數(shù)據(jù)技術(shù)來解決我們公司目前遇到的困難函匕。

因為是搞大數(shù)據(jù)相關(guān)技術(shù)娱据，所有團(tuán)隊里面的兄弟姐妹都還是比較happy的：)

其實這里面，Dbus和Wormhole相對固定模式化浦箱，容易輕松復(fù)用吸耿。Swifts實時計算是與每個業(yè)務(wù)相關(guān)比較大的，自定義比較強酷窥，相對比較麻煩一些。

Q3：宜信的這個DWS系統(tǒng)會開源么?

A3：我們也考慮過向社區(qū)貢獻(xiàn)伴网，就像宜信的其他開源項目一樣蓬推，目前項目剛剛成形，還有待進(jìn)一步磨煉澡腾，我相信未來的某個時候沸伏，我們會給它開源出來。

Q4：架構(gòu)師怎么理解动分，是不是系統(tǒng)工程師?

A4：不是系統(tǒng)工程師毅糟，在我們宜信有多位架構(gòu)師，應(yīng)該算是以技術(shù)驅(qū)動業(yè)務(wù)的技術(shù)管理人員澜公。包含產(chǎn)品設(shè)計姆另，技術(shù)管理等。

Q5：復(fù)制方案是否是OGG?

A5：OGG與上面提到的其他商業(yè)解決方案都是可選方案。