(一)明確目的，確定構(gòu)成要素。即便針對同一個系統(tǒng)，由于建模的目的不同，構(gòu)造出來的模型是不同。根據(jù)物流系統(tǒng)的物流信息和研究目的，可以決定模型的大小，同時構(gòu)造模型的目的還決定了模型的最小構(gòu)成要素。

       (二)模型的簡單化和高精度模型。如果簡單的模型包含實際系統(tǒng)的信息少，那么模型的精度就差。模型的簡單化和高精度要求之間是相互矛盾的。高精度的模型一般比較復(fù)雜，如果某種復(fù)雜的模型，成本很高，對于實際應(yīng)用必要性不大，則這種模型就值得簡化。當然，也要注意過分的模型精度不夠，模型的簡化就失去了應(yīng)用的意義。廣州物流公司：m.zhu555.cn 

       (三)沒有固定不變的建模方法。作為建立模型的一個特征，就是無法確定哪一種模型是最好的。建立模型的方法根據(jù)目的不同而不同。因為在建模時，假定條件、前提、理論都是技術(shù)研究人員根據(jù)其知識結(jié)構(gòu)、研究經(jīng)驗決定的。

       (四)模型的驗證。為了確認模型的準確，必須進行驗證，這在建立模型的時候非常重要。如果能將試驗進行比較時，驗證比較容易。但是，利用預(yù)測模型推測未來值時，除了利用過去的數(shù)據(jù)進行驗證外，還必須采取其他各種方法。

       模型驗證應(yīng)該注意兩種情況：一種是模型本身就不適當；另一種是模型本身適當，但是參數(shù)不合適。在參數(shù)過多的情況下，確定不合適的參數(shù)就非常復(fù)雜。在這種情況下，就應(yīng)該首先應(yīng)用盡量簡單的、能表現(xiàn)系統(tǒng)本質(zhì)的模型，然后再把具有各種功能的子系統(tǒng)加進去。在些過程中，逐次對參數(shù)值進行檢驗。在模型整體建成后，再改變參數(shù)值對于整體影響也不大。在些影響下，對于不進行變換的數(shù)學(xué)模型中的參數(shù)更容易發(fā)現(xiàn)其中的錯誤。

新增的數(shù)據(jù)，可以直接插入，但是更新的數(shù)據(jù)，我們需要把原紀錄更新掉，或者先刪除再插入，以前我們還會記錄一個數(shù)據(jù)插入的狀態(tài)，如果是更新的，就記一個“update”，如果是插入的就記一個“insert”，到了這里，應(yīng)該知道為啥需要有主鍵了吧，如果沒有主鍵，你咋知道這條記錄到底變沒變過。

使用增量，一般需要兩套表，一套表用來存增量數(shù)據(jù)，一套用來存完整的全量數(shù)據(jù)。

3. etl_insert_time

不管是增量還是全量，我都比較喜歡加一個時間戳字段，用來標識記錄的插入時間，這個尤其是在對比增量數(shù)據(jù)的時候，排查數(shù)據(jù)問題很有用。

4. 我們公司的同步機制

我們呢，一創(chuàng)業(yè)公司，數(shù)據(jù)量不算多，使用的都是阿里云的工具，一開始為了方便，所有的數(shù)據(jù)，都是全量來的，剛看了眼數(shù)據(jù)量又10幾T吧，其中很多是歷史數(shù)據(jù)。

雖然我們是全量來的，但是為了捕捉記錄數(shù)據(jù)的變化，用的是pt（分區(qū)）的方式，每天都是一個全量快照，這也是現(xiàn)在存儲便宜的一種處理方法，簡單粗暴。我剛來的時候，就提過搞成增量，被拒絕了，后來也沒有人來搞這個，表太多了，修改起來成本太高。

5. 基于Hive的增量

Hive現(xiàn)在也算是標配了，上面說的增量方案，可能還是基于關(guān)系型數(shù)據(jù)庫的，在Hive上，由于運算能力更強大，可以不考慮數(shù)據(jù)量的問題，所以衍生出來幾種方案。主要原因還是Hive上對于delete操作的支持問題，盡量不要有delete。

• 排序（row_number）

我們依然每天獲取增量數(shù)據(jù)，然后將增量數(shù)據(jù)插入到每個分區(qū)中，每個分區(qū)都是當天的增量數(shù)據(jù)，當然數(shù)據(jù)變化的話，同一個主鍵的記錄會出現(xiàn)在多個分區(qū)中，所以如果我們要獲取最新的完整版數(shù)據(jù)，可以使用row_number根據(jù)主鍵和時間排序，獲取最新版本的全量數(shù)據(jù)廣州物流公司：www.4008407856.com 

新聞中心相關(guān)線路查詢