背景：
公司要啟動項目要做一個實時數(shù)據(jù)系統(tǒng)谣辞，去替代現(xiàn)在在oracle上計算的那套東西全部搬到Hadoop平臺上宋距；調(diào)研了Druid变过、Hbase埃元、Kudu，最后定下來方案使用Kudu媚狰。下面是基本
1. 公司的業(yè)務源端數(shù)據(jù)庫是Oracle岛杀，實時同步數(shù)據(jù)的工具就是GoldenGate；
2. 資源的限制崭孤，Kafka集群沒有掛nas盤类嗤，所以暫時我們用的是單機的，沒辦法辨宠，窮只有一個字我只說一次遗锣。
項目訴求：
1.? 自適應：確保源端表在發(fā)生變化的時候，需要通過數(shù)據(jù)包字段來識別表結(jié)構(gòu)是否發(fā)生變化嗤形，然后觸發(fā)目標表變化和原來表數(shù)據(jù)備份精偿；
2.? 自動識別離線數(shù)據(jù)是否完成：因為我們這邊離線數(shù)據(jù)通過調(diào)度平臺來完成，不在實時這部分派殷；
3.? 源端ORACLE保持一致性
系統(tǒng)架構(gòu)：
系統(tǒng)機構(gòu)分離線同步和實時同步兩部分：由于KAFKA分區(qū)的原因會造成少量的數(shù)據(jù)錯亂，所以需要每天凌晨會把T+1離線數(shù)據(jù)同步過來覆蓋掉原來的數(shù)據(jù)（以防有錯）墓阀。
1.? 離線部分：從已有的離線數(shù)據(jù)表毡惜，將關(guān)系型轉(zhuǎn)成非關(guān)系型批量插入KUDU中；
2.? 實時部分：在Oracle 源端裝GoldenGate 的源端斯撮，目的端在一臺裝有KAFKA的機器上（圖方便）经伙，KAFKA的CONSUMER直接消費OGG目的端過來的數(shù)據(jù)，需要做到檢查勿锅、解析帕膜、新增/更新等操作；
????????2.1 ? OGG到KAFKA安裝教程具體見（https://blog.csdn.net/clerk0324/article/details/73498266）：
????????????????中間也踩了不少的坑溢十，導致目的端的replicat啟動不起來垮刹，這個時候需要檢查OGG對應KAFKA配置是否配對了（KAFKA配的lib安裝路、LD_LIBRARY_PATH张弛、JAVA_HOME這些是否都存在）荒典；
????????2.2? KUDU 非關(guān)系型數(shù)據(jù)庫特點（Kudu 自帶的API 酪劫，研究的是這個文檔 :https://github.com/apache/kudu/blob/master/python/kudu/client.pyx）
? ? ? ? ? ? ? ? a. Kudu數(shù)據(jù)庫所有的表必須有主鍵，且主鍵的類型只能是字符型（源端建表的習慣不好寺董，主鍵中有int類型覆糟、還有字段不設置默認值，讓后續(xù)代碼加了很多邏輯去彌補這一麻煩遮咖，所以規(guī)范很重要Ｌ沧帧）；
? ? ? ? ? ? ? ? b. Kudu 在插入數(shù)據(jù)的時候需要所有數(shù)據(jù)項都要有值且非空御吞；
? ? ? ? ? ? ? ? c. 在更新Kudu 數(shù)據(jù)的時候需要按照主鍵去更新麦箍；
? ? ? ? ? ? ? ? d. 為什么不用impala，其實剛開始使用的就是impala魄藕，因為實時解析部分是要一直插入内列、更新的，impala在大概第五分鐘的時候就已經(jīng)操作不了數(shù)據(jù)（進入假死狀態(tài)）背率，而且發(fā)現(xiàn)在進行復雜的SQL的時候话瞧，還沒執(zhí)行完就報錯了，KUDU是支持高并發(fā)的但是impala不行寝姿，所以在解析程序中使用的都是Kudu 自帶的API 交排；
? ? ? ? ? ? ? ? e. 默認會在impala上建一個對應的外部表指向Kudu的同名表，impala應該是通過Kudu表的表名去鏈的饵筑，因為我要備份建新表的時候不重新指向一遍它是找不到新表的埃篓；
? ? ? ? 2.2 ?? KAFKA 消費OGG目的端數(shù)據(jù)解析程序（本系統(tǒng)的最重要部分之一，還有一個最重要是離線批量數(shù)據(jù)由Hive->Kudu ）
? ? ? ? ? ? ? 該段核心承擔了系統(tǒng)實時部分主要功能：
? ? ? ? ? ? ? ? a. 解析字段部分：這是最基本的功能根资，我們選擇同步的字段類型是json架专，而不是用分隔符隔開的一個字符串，首先方便校驗原表字段是否做了變化玄帕，可以讓觸發(fā)自適應去更新Kudu表結(jié)構(gòu)部脚；
????????????????b.過來的key是否在對應同步表的表結(jié)構(gòu)中，若不在觸發(fā)備份 - > 更新表結(jié)構(gòu) 操作裤纹；
? ? ? ? ? ? ? ? c. 判斷離線數(shù)據(jù)是否同步成功：這里有兩個最重要的邏輯：1. 如何判斷離線數(shù)據(jù)是否同步成功委刘；2. 離線數(shù)據(jù)同步是需要時間的，假設離線數(shù)據(jù)同步完花了T分鐘鹰椒，此時如果直接去覆蓋實時表部分必然會將T分鐘內(nèi)更新的數(shù)據(jù)給覆蓋掉锡移；這兩個問題解決，實時的數(shù)據(jù)才能和源端保持一致性漆际；
這就是該項目大概梳理的邏輯部分淆珊；歡迎大家和我交流，也希望能有很多不同的新思路奸汇；
