每個SaaS應用程序背后的數(shù)據(jù)庫存儲有關員工、供應商、客戶及其他合作伙伴的業(yè)務信息。SaaS應用程序支持諸多工作流程，比如面向銷售和營銷的CRM、面向財務的云ERP、面向人力資源的勞動力管理以及其他企業(yè)和部門服務。如今，許多公司使用眾多SaaS應用程序：從Salesforce、Slack、Workday和Atlassian之類的主流產(chǎn)品，到許多小型的SaaS工具，不一而足。

SaaS應用程序不會在孤島中運行，大多數(shù)企業(yè)需要將它們的功能與私有云或公共云中管理的其他企業(yè)應用程序集成起來。

如果跨多個應用程序的工作流程需要集成應用程序，開發(fā)團隊可以利用SaaS平臺的API來觸發(fā)從一個平臺到另一個平臺的事件。許多應用程序和服務需要集成時，可以選擇Boomi、SnapLogic或MuleSoft之類的企業(yè)集成平臺。如果需要遵循“如果這樣，需要那樣”模式的輕量級集成，IFTTT平臺可以提供有效的集成。如果開發(fā)團隊在開發(fā)連接到多個SaaS和企業(yè)工作流程的新應用程序，還應探究Appian、OutSystems和PowWow之類的低代碼平臺。

利用SaaS數(shù)據(jù)以滿足不同的業(yè)務需求

如果你需要將來自SaaS平臺的數(shù)據(jù)與其他數(shù)據(jù)源集成起來怎么辦？可能需要跨SaaS工具集成數(shù)據(jù)，出于這幾個原因：

業(yè)務分析員想使用該數(shù)據(jù)來開發(fā)報告和儀表板。

數(shù)據(jù)科學團隊想要用于機器學習實驗的數(shù)據(jù)。

業(yè)務團隊想要集中數(shù)據(jù)以支持工作流程及其他類型的應用程序。比如說，營銷團隊常常使用客戶數(shù)據(jù)平臺或主數(shù)據(jù)平臺來集中有關客戶、產(chǎn)品和其他業(yè)務實體的數(shù)據(jù)。

IT團隊應提取備份所需的數(shù)據(jù)，或將數(shù)據(jù)遷移到其他平臺。

法務團隊有時需要對基礎數(shù)據(jù)執(zhí)行法律發(fā)現(xiàn)。

數(shù)據(jù)管理員常常想要清理、轉換或豐富基礎數(shù)據(jù)。

當然，你可以利用SaaS平臺的API來提取數(shù)據(jù)，但這可能需要大量的開發(fā)工作來學習API、了解SaaS平臺的數(shù)據(jù)模型、為任何新數(shù)據(jù)創(chuàng)建數(shù)據(jù)存儲區(qū)、編寫代碼以加載數(shù)據(jù)，并為任何轉換開發(fā)邏輯。此外，IT團隊要定義托管該應用程序或服務的云或數(shù)據(jù)中心基礎架構。最后，任何旨在按計劃或按需要運行的數(shù)據(jù)集成都需要日常的支持。對于面臨其他更重要的優(yōu)先事項的開發(fā)團隊和IT部門而言，從頭開始開發(fā)集成可能成本高昂。

另一種方法是考慮數(shù)據(jù)集成、數(shù)據(jù)流、ETL（提取轉換和加載）或其他數(shù)據(jù)準備平臺。處理頻繁變化的大量數(shù)據(jù)時，使用數(shù)據(jù)集成平臺可能是最佳方法，因為這種平臺可實現(xiàn)靈活的提取和轉換。然而，在最終用戶訪問和使用信息之前，它們也需要事先開發(fā)集成機制。

可能需要查詢和管理SaaS數(shù)據(jù)的更輕量級的手段。有時，這種方法對于快速實驗、發(fā)現(xiàn)和構建原型很有用。有時，這種方法可以輕松用于運營或生產(chǎn)需求，尤其在數(shù)據(jù)量很少且查詢吞吐量不大的情況下。以下是三種選擇。

1. 直接查詢SaaS應用程序的BI平臺

如果你的主要需求是報告，那么許多自助式BI和數(shù)據(jù)可視化平臺可以直接連接到更流行的SaaS應用程序。

Tableau可以連接到Intuit Quickbook、Google Analytics、LinkedIn Sales Navigator、ServiceNow、Eloqua、Marketo和Salesforce等平臺。

Microsoft Power BI還與Adobe AnalyTIcs、Facebook、GitHub、MailChimp、Stripe、Quick Base和Zendesk等在線服務集成。

Domo聲稱有1000多個連接件，支持的平臺包括HubSpot、Jira、Instagram、Qualtrics、Shopify、SurveyMonkey、Twitter和Workday等。

至少，這些集成提供了一種查詢和發(fā)現(xiàn)基礎SaaS數(shù)據(jù)源的簡易方法。往好里說，現(xiàn)成的集成足以使最終用戶創(chuàng)建所需的數(shù)據(jù)混合、報告和儀表板。

有幾個方面要考慮。

當列有匹配的鍵時，這些平臺可支持連接和數(shù)據(jù)混合。如果在集成數(shù)據(jù)源或將其與其他數(shù)據(jù)源混合之前需要大量的數(shù)據(jù)轉換，它們就變得較難使用。

評估是否通過實時查詢執(zhí)行SaaS數(shù)據(jù)集成，或者數(shù)據(jù)是提取還是緩存。

如果SaaS應用程序含有大量數(shù)據(jù)、與許多其他數(shù)據(jù)源存在復雜的連接，或者儀表板將被許多用戶同時使用，性能可能是一個因素。

2. 模擬ODBC、JDBC、OData或其他驅動程序的平臺

如果業(yè)務需要的不僅僅是報告和儀表板，仍需要輕量級的集成方法，那么一些商業(yè)工具可將SaaS API轉換成標準數(shù)據(jù)庫驅動程序，比如ODBC、JDBC或OData。對于常用SaaS平臺的驅動程序而言，兩個選擇是Progress DataDirect和CData Driver Technologies。

如果數(shù)據(jù)科學團隊想要在提取數(shù)據(jù)以供分析之前對SaaS數(shù)據(jù)庫執(zhí)行臨時查詢，驅動程序方法可能最有用。對于需要實時查詢SaaS應用程序數(shù)據(jù)的應用開發(fā)人員來說，這也是不錯的選擇。

開發(fā)和數(shù)據(jù)科學團隊應調查該集成的性能，尤其是在需要大量查詢、龐大數(shù)據(jù)集或低延遲的情況下。此外，許多SaaS應用程序根據(jù)API使用情況來限制客戶或向客戶收費，因此如果需要更高的查詢量或數(shù)據(jù)量，這可能是個因素。

3. 可將SaaS數(shù)據(jù)同步到云數(shù)據(jù)庫的輕量級ETL平臺

最后一個方法是將數(shù)據(jù)集成從SaaS應用程序搬到貴企業(yè)建立和管理的云數(shù)據(jù)庫中。該策略增添了一些操作復雜性和成本，如果需要實時查詢SaaS應用程序數(shù)據(jù)，可能不是理想的選擇。但它確實有幾個優(yōu)點：

它讓企業(yè)可以更大程度地控制業(yè)務用戶、數(shù)據(jù)科學家（包括平民數(shù)據(jù)科學家）和應用開發(fā)人員使用的數(shù)據(jù)庫平臺和數(shù)據(jù)架構。平臺和架構應滿足容量、性能和延遲等方面的要求。

獨立于SaaS數(shù)據(jù)庫存儲數(shù)據(jù)可提供更大的靈活性，可根據(jù)下游用戶和應用程序的要求，靈活地轉換、連接、清理或聚合數(shù)據(jù)。

如果面向查詢該數(shù)據(jù)的數(shù)據(jù)安全、數(shù)據(jù)隱私或其他數(shù)據(jù)治理控制措施有別于SaaS應用程序中的訪問和權利控制措施，那么可能需要將數(shù)據(jù)托管在單獨的數(shù)據(jù)庫中。

獨立于SaaS平臺托管數(shù)據(jù)對于更高的數(shù)據(jù)量和查詢量需求而言可能更具成本效益。

雖然你可以將該集成與數(shù)據(jù)集成或準備平臺結合起來，但是仍有一些SaaS數(shù)據(jù)集成平臺擁有可直接連接到許多SaaS應用程序的機制。如果你的目標是將數(shù)據(jù)從SaaS應用程序流式傳輸?shù)皆茢?shù)據(jù)庫，Talend旗下的STItch是一款即插即用的解決方案。你可以選擇要復制的數(shù)據(jù)和復制頻次，但是它不提供用于轉換或過濾數(shù)據(jù)的任何工具。Skyvia提供了一款類似的產(chǎn)品，兩者都有讓開發(fā)團隊可以試一試集成的免費版本。谷歌云旗下的Alooma致力于將數(shù)據(jù)轉移至Google BigQuery、Amazon Redshift和Snowflake之類的大數(shù)據(jù)平臺，并提供一些數(shù)據(jù)轉換功能。

如果貴公司在使用許多SaaS平臺，那么一刀切的策略可能行不通。每條集成路徑都支持不同的SaaS集成，集成的類型必須與預期的業(yè)務需求相一致。比較工具并考慮多種選擇是一條優(yōu)選實踐，數(shù)據(jù)集成需求變化時尤為如此。