十多年來，Salesforce客戶關(guān)系管理（CRM）解決方案一直是幾乎所有業(yè)務(wù)的中心。 但是，盡管它非常適合提高運營效率，但許多人發(fā)現(xiàn)將其用于多維數(shù)據(jù)分析具有挑戰(zhàn)性。這篇文章描述了如何通過現(xiàn)代云數(shù)據(jù)倉庫來擴大您的Salesforce足跡來彌合這種差距。

Salesforce位于您的業(yè)務(wù)中心

Salesforce無疑是軟件即服務(wù)的先驅(qū)，如今您很難找到不使用它的企業(yè)。 此外，當(dāng)前的Salesforce產(chǎn)品已經(jīng)超越了傳統(tǒng)CRM的范圍，幾乎涵蓋了客戶交互過程的每個方面，如下圖所示。

但是，并非每家公司都使用所有Salesforce模塊來運行其業(yè)務(wù)，并且找到不同解決方案的組合并不少見。 在那種情況下，傳統(tǒng)觀點認(rèn)為，每個系統(tǒng)都會將客戶數(shù)據(jù)輸入到Salesforce中，從而使該平臺成為運營洞察力的“重心”。

因此，使用Salesforce回答常見的操作問題相對容易：

• “本季度歐洲的銷售預(yù)測是什么？”
• “本月售出了多少產(chǎn)品？”
• “哪些客戶有客戶支持票？”
• “營銷活動產(chǎn)生了多少線索？”

存儲在Saleforce有什么問題？

如果所有的業(yè)務(wù)數(shù)據(jù)都存儲在Salesforce中，會有什么問題？

• 首先，并非您的所有業(yè)務(wù)數(shù)據(jù)都屬于或需要存在于Salesforce中。在沒有特定業(yè)務(wù)原因的情況下復(fù)制不必要的數(shù)據(jù)只會使Salesforce實例的大小膨脹，并增加存儲成本。
• 其次，Salesforce是針對交易而非分析進(jìn)行優(yōu)化的應(yīng)用程序。每個“數(shù)據(jù)庫表”都是一個具有字段和參考數(shù)據(jù)的對象。例如，“帳戶”對象可以具有許多其他對象的引用。因此，執(zhí)行復(fù)雜的分析非常困難且執(zhí)行緩慢。
• 最后，Salesforce數(shù)據(jù)模型并不總是包含完整的記錄歷史記錄，這意味著幾乎不可能進(jìn)行多維歷史記錄報告。在維建模中，數(shù)字和文本數(shù)據(jù)作為事實和屬性存儲在星型模式中。每個維度在事務(wù)數(shù)據(jù)上提供了不同的視角或軸。

例如，假設(shè)我們決定記錄零售商店中的銷售交易。在Salesforce模型中，在寄存器處進(jìn)行的每筆交易都記錄為銷售或退貨“訂單”對象。該對象可以標(biāo)識產(chǎn)品，客戶，帳戶和交易日期。在維模型中，您可以輕松地按產(chǎn)品，客戶，日期或它們的某種組合檢查所有交易。產(chǎn)品，客戶和日期被視為交易數(shù)據(jù)的維度。

總而言之，這是關(guān)于何時使用在線事務(wù)處理（OLTP）以及何時使用在線分析處理（OLAP）的古老討論。

使用Salesforce數(shù)據(jù)增強您的倉庫

翻版腳本并將數(shù)據(jù)倉庫放在決策中心的最佳時機再合適不過了。 這是因為有幾種出色的云數(shù)據(jù)倉庫產(chǎn)品可供選擇。 諸如Amazon Redshift，Azure Synapse，Google BigQuery和Snowflake Cloud Data Platform的解決方案都是彈性的，按需付費的自助服務(wù)選項。因此，現(xiàn)在您可以將團隊完成工作所需的數(shù)據(jù)導(dǎo)入Salesforce，同時讓相關(guān)的分析系統(tǒng)處理專業(yè)報告。

數(shù)據(jù)映射方法

許多從業(yè)人員會告訴您，Salesforce數(shù)據(jù)模型非常靈活并且易于定制。但是，每個實施倉庫的公司通常都定義一個數(shù)據(jù)模型以適合其整個組織的報告需求。因此，將Salesforce數(shù)據(jù)添加到組織數(shù)據(jù)模型中的效率要比其他方法（即上圖中的黑線）高得多。

將Salesforce與數(shù)據(jù)倉庫同步

使用Salesforce數(shù)據(jù)填充和更新數(shù)據(jù)倉庫需要幾個階段。 第一階段稱為“初始加載”，它提取大量Salesforce數(shù)據(jù)并將其放入倉庫。第二階段著重于通過增量Salesforce更改使數(shù)據(jù)倉庫保持最新狀態(tài)。

初始負(fù)荷

毫不奇怪，有很多選擇可以用Salesforce數(shù)據(jù)加載數(shù)據(jù)倉庫。 最常見的情況如下：

• 手動CSV提取和加載–這是使用Salesforce數(shù)據(jù)加載器將對象導(dǎo)出到CSV文件的最基本和手動的技術(shù)。
• 批量API –如果您有一位熟悉Salesforce批量API的開發(fā)人員，則這是另一種選擇。 開發(fā)人員編寫查詢，以JSON或XML格式返回Salesforce數(shù)據(jù)集，然后可以將其手動或以編程方式加載到數(shù)據(jù)倉庫中。
• ETL – ETL工具在可靠性，功能性，可伸縮性，可用性和價格方面差異很大。 但是，它們都以批處理方式工作，并且需要成功加載數(shù)據(jù)表中的目標(biāo)表。
• CDC –許多變更數(shù)據(jù)捕獲（CDC）解決方案將提供“初始加載”功能，該功能為Salesforce對象生成DDL，在數(shù)據(jù)倉庫中創(chuàng)建表并加載初始Salesforce數(shù)據(jù)集。

增量更新

毫不奇怪，還有多種方法可以使倉庫保持最新數(shù)據(jù)。 它們?nèi)缦拢?

• 批處理ETL –此過程按計劃執(zhí)行ETL流程，以查找自上次運行該過程以來對Salesforce對象的更改。
• “ Salesforce事件” –最簡單的事件是“工作流規(guī)則”，可以在創(chuàng)建，刪除或更新對象時觸發(fā)。 然后，規(guī)則可以調(diào)用出站消息，該出站消息配置為通過Heroku應(yīng)用程序更新外部數(shù)據(jù)倉庫。
• CDC流-在過去的幾年中，Salesforce提供了本機CDC選項，其工作方式與工作流規(guī)則類似。 Salesforce發(fā)布更改事件，這些更改事件可以實時同步到外部數(shù)據(jù)存儲。

CDC的優(yōu)點是可以實時更新外部系統(tǒng)，從而使目標(biāo)數(shù)據(jù)保持最新狀態(tài)。

將Salesforce CDC與Qlik Replicate一起使用

可以說，最好的數(shù)據(jù)移動方法是將Qlik Replicate與Salesforce CDC一起使用，因為這使您能夠在各種各樣的異構(gòu)數(shù)據(jù)庫，數(shù)據(jù)湖和數(shù)據(jù)倉庫平臺之間流傳輸數(shù)據(jù)更改，而不僅僅是Salesforce。另外，Qilk Replicate的無代理解決方案可輕松高效地移動數(shù)據(jù)，而不會影響生產(chǎn)數(shù)據(jù)系統(tǒng)的性能。 

使用Qlik數(shù)據(jù)集成平臺的數(shù)據(jù)倉庫自動化

要考慮的另一個重要問題是倉庫自動化。數(shù)據(jù)倉庫自動化（DWA）可以加速和簡化數(shù)據(jù)倉庫的生命周期，從而更快地獲得洞察力。

盡管DWA的范圍超出了本文章的范圍，但這里提一下，Qlik Data Integration平臺可自動執(zhí)行整個數(shù)據(jù)倉庫生命周期，以加快可用于分析的數(shù)據(jù)的可用性，Qlik的模型驅(qū)動方法通過自動化數(shù)據(jù)倉庫流水線的每個步驟（從數(shù)據(jù)建模和實時提取到數(shù)據(jù)集市的創(chuàng)建和受控制的數(shù)據(jù)使用），來幫助數(shù)據(jù)工程師兌現(xiàn)敏捷數(shù)據(jù)倉庫的承諾。

簡而言之，通過將Salesforce數(shù)據(jù)與DWA相結(jié)合，您可以提高數(shù)據(jù)倉庫的準(zhǔn)確性和效率，從而為業(yè)務(wù)帶來可觀的增長。

點擊獲取Qlik

關(guān)于Qlik

Qlik的愿景是一個數(shù)據(jù)素養(yǎng)的世界，每個人都可以使用數(shù)據(jù)來改善決策并解決他們最具挑戰(zhàn)性的問題。只有Qlik提供端到端的實時數(shù)據(jù)集成和分析解決方案，以幫助組織訪問所有數(shù)據(jù)并將其轉(zhuǎn)化為價值。慧都作為Qlik官方的中國合作伙伴，我們?yōu)镼lik的中國用戶提供產(chǎn)品授權(quán)與實施、定制分析方案、技術(shù)培訓(xùn)等服務(wù)，旨在讓中國企業(yè)的每個Qlik用戶都能探索出數(shù)據(jù)的價值，讓企業(yè)形成分析文化。了解更多信息，請咨詢