SQL veri ambarı ve Azure Data Factory ile otomatik enterprise BIAutomated enterprise BI with SQL Data Warehouse and Azure Data Factory

Bu başvuru mimarisi, artımlı yükleme yapma işlemi açıklanır bir ayıklama, yükleme ve dönüştürme (ELT) işlem hattı.This reference architecture shows how to perform incremental loading in an extract, load, and transform (ELT) pipeline. Azure Data Factory ELT işlem hattını otomatik hale getirmek için kullanır.It uses Azure Data Factory to automate the ELT pipeline. İşlem hattı bir şirket içi SQL Server veritabanındaki en son OLTP verileri SQL veri ambarı'na artımlı olarak taşır.The pipeline incrementally moves the latest OLTP data from an on-premises SQL Server database into SQL Data Warehouse. İşlemsel veri analizi için tablosal bir model olarak dönüştürülür.Transactional data is transformed into a tabular model for analysis.

Bu mimari için bir başvuru uygulaması kullanılabilir GitHub.A reference implementation for this architecture is available on GitHub.

SQL veri ambarı ve Azure Data Factory ile otomatik Kurumsal BI mimarisi diyagramı

Bu mimari gösterilen bir derleme SQL veri ambarı ile Enterprise BI, ancak enterprise veri depolama senaryolarında önemli olan bazı özellikler ekler.This architecture builds on the one shown in Enterprise BI with SQL Data Warehouse, but adds some features that are important for enterprise data warehousing scenarios.

  • Data Factory kullanarak işlem hattını Otomasyon.Automation of the pipeline using Data Factory.
  • Artımlı yükleme.Incremental loading.
  • Birden çok veri kaynağına tümleştirme.Integrating multiple data sources.
  • Jeo-uzamsal veriler ve görüntü gibi ikili veriler yükleniyor.Loading binary data such as geospatial data and images.

MimariArchitecture

Mimari aşağıdaki bileşenlerden oluşur.The architecture consists of the following components.

Veri kaynaklarıData sources

Şirket içi SQL Server.On-premises SQL Server. Kaynak verileri şirket içi SQL Server veritabanında bulunur.The source data is located in a SQL Server database on premises. Bu mimari sağlama yüklü SQL sunucunuz ile azure'da bir sanal makine için dağıtım betikleri şirket içi ortamı benzetimini yapmak için.To simulate the on-premises environment, the deployment scripts for this architecture provision a virtual machine in Azure with SQL Server installed. [Wide World Importers OLTP örnek veritabanını] wwi kaynak veritabanı olarak kullanılır.The Wide World Importers OLTP sample database is used as the source database.

Dış veri.External data. Veri ambarları için yaygın bir senaryo, birden çok veri kaynağına tümleştirme sağlamaktır.A common scenario for data warehouses is to integrate multiple data sources. Bu başvuru mimarisi, city populations yıla göre içeren ve OLTP veritabanındaki verileri ile tümleşir dış bir veri kümesine yükler.This reference architecture loads an external data set that contains city populations by year, and integrates it with the data from the OLTP database. Bu veriler için ınsights gibi kullanabilirsiniz: "Her bölgede satış artışı eşleşen veya nüfus artışı aşan?"You can use this data for insights such as: "Does sales growth in each region match or exceed population growth?"

Alımı ve veri depolamaIngestion and data storage

BLOB Depolama.Blob Storage. BLOB Depolama için kaynak verilerini SQL veri ambarı'na yüklemeden önce bir hazırlama alanı olarak kullanılır.Blob storage is used as a staging area for the source data before loading it into SQL Data Warehouse.

Azure SQL Veri Ambarı.Azure SQL Data Warehouse. SQL veri ambarı büyük veriler üzerinde analiz gerçekleştirmek için tasarlanmış bir dağıtılmış sistemidir.SQL Data Warehouse is a distributed system designed to perform analytics on large data. Bu, yüksek performanslı bir analiz çalıştırmak için uygun hale getiren yüksek hacimli paralel işleme (MPP) destekler.It supports massive parallel processing (MPP), which makes it suitable for running high-performance analytics.

Azure veri fabrikası.Azure Data Factory. [Veri Fabrikası] adf veri taşıma ve veri dönüştürmeyi düzenleyen ve otomatikleştiren bir yönetilen hizmettir.Data Factory is a managed service that orchestrates and automates data movement and data transformation. Bu mimaride, ELT işlem çeşitli aşamaları boyunca düzenler.In this architecture, it coordinates the various stages of the ELT process.

Analiz ve RaporlamaAnalysis and reporting

Azure Analysis Services.Azure Analysis Services. Analysis Services , veri modelleme özellikleri sağlayan tam olarak yönetilen bir hizmettir.Analysis Services is a fully managed service that provides data modeling capabilities. Anlam modeli, Analysis Services yüklenir.The semantic model is loaded into Analysis Services.

Power BI.Power BI. Power BI, iş öngörüleri için verileri çözümlemek için İş analizi araçları paketidir.Power BI is a suite of business analytics tools to analyze data for business insights. Bu mimaride, Analysis Services içinde depolanan anlam modeli sorgular.In this architecture, it queries the semantic model stored in Analysis Services.

Kimlik DoğrulamasıAuthentication

Azure Active Directory (Azure AD) aracılığıyla Power BI Analysis Services sunucusuna bağlanan kullanıcıların kimliğini doğrular.Azure Active Directory (Azure AD) authenticates users who connect to the Analysis Services server through Power BI.

Veri Fabrikası kullanımı Azure AD hizmet sorumlusu veya yönetilen hizmet kimliği (MSI) kullanarak SQL veri ambarı'na kimlik doğrulaması için de kullanabilirsiniz.Data Factory can use also use Azure AD to authenticate to SQL Data Warehouse, by using a service principal or Managed Service Identity (MSI). Kolaylık olması için örnek dağıtımı, SQL Server kimlik doğrulamasını kullanır.For simplicity, the example deployment uses SQL Server authentication.

Veri işlem hattıData pipeline

İçinde Azure Data Factory, bir işlem hattı bir etkinlik bir görevi koordine etmek için kullanılan mantıksal grubudur — bu durumda, yükleme ve verileri SQL Data Warehouse'a veri dönüştürme.In Azure Data Factory, a pipeline is a logical grouping of activities used to coordinate a task — in this case, loading and transforming data into SQL Data Warehouse.

Bu başvuru mimarisi, bir dizi alt işlem hatları çalıştıran bir ana işlem hattı tanımlar.This reference architecture defines a master pipeline that runs a sequence of child pipelines. Her bir alt işlem hattı, verileri bir veya daha fazla data warehouse tablolarına yükler.Each child pipeline loads data into one or more data warehouse tables.

Azure Data Factory işlem hattının ekran görüntüsü

Artımlı yüklemeIncremental loading

Otomatik bir ETL veya ELT işlem çalıştırdığınızda, yalnızca önceki çalıştırma bu yana değişen verileri yüklemek için etkili olur.When you run an automated ETL or ELT process, it's most efficient to load only the data that changed since the previous run. Bu adlı bir artımlı yük, tüm verileri yükleyen bir tam yük aygıtlardır.This is called an incremental load, as opposed to a full load that loads all of the data. Artımlı bir yükleme gerçekleştirmek için hangi verilerin değiştirilmesi etkiye tanımlamak için bir yol gerekir.To perform an incremental load, you need a way to identify which data has changed. En yaygın yaklaşımı bir yüksek su işareti değeri bazı sütun değerlerini datetime sütunu ya da benzersiz tamsayı sütunu kaynak tabloda en son değeri izleme anlamına gelir.The most common approach is to use a high water mark value, which means tracking the latest value of some column in the source table, either a datetime column or a unique integer column.

Kullanabileceğiniz SQL Server 2016'dan itibaren zamana bağlı tablolarda.Starting with SQL Server 2016, you can use temporal tables. Veri değişikliklerini tam geçmişini tutmak sistem sürümü tutulan tablolarda şunlardır.These are system-versioned tables that keep a full history of data changes. Veritabanı altyapısı, her değişiklik geçmişini ayrı bir geçmiş tablosunda otomatik olarak kaydeder.The database engine automatically records the history of every change in a separate history table. Bir sorgu için bir FOR system_tıme yan tümcesi ekleyerek geçmiş verileri sorgulayabilirsiniz.You can query the historical data by adding a FOR SYSTEM_TIME clause to a query. Dahili olarak, veritabanı altyapısı geçmiş tablosu sorgular, ancak bu uygulama için saydamdır.Internally, the database engine queries the history table, but this is transparent to the application.

Not

SQL Server'ın önceki sürümleri için kullandığınız değişiklik verilerini yakalama (CDC).For earlier versions of SQL Server, you can use Change Data Capture (CDC). Bu yaklaşım, ayrı değişiklik tablosunun sorgulamak sahip ve bir zaman damgası yerine bir günlük sıra numarası tarafından izlenen değişiklikleri zamana bağlı tablolarda kullanışsız olur.This approach is less convenient than temporal tables, because you have to query a separate change table, and changes are tracked by a log sequence number, rather than a timestamp.

Zamana bağlı tablolarda, zaman içinde değişebilir boyut veriler için kullanışlıdır.Temporal tables are useful for dimension data, which can change over time. Olgu tabloları sabit bir işlem sistemi sürümü geçmişi bu durumda tutma doesn't make Sense bir satış gibi genellikle temsil eder.Fact tables usually represent an immutable transaction such as a sale, in which case keeping the system version history doesn't make sense. Bunun yerine, işlemler, genellikle eşik değeri olarak kullanılabilecek işlem tarihi temsil eden bir sütun sahiptir.Instead, transactions usually have a column that represents the transaction date, which can be used as the watermark value. Örneğin, Wide World Importers OLTP veritabanında Sales.Invoices ve Sales.InvoiceLines tabloları sahip bir LastEditedWhen varsayılan alan sysdatetime().For example, in the Wide World Importers OLTP database, the Sales.Invoices and Sales.InvoiceLines tables have a LastEditedWhen field that defaults to sysdatetime().

ELT işlem hattının genel akışı şöyledir:Here is the general flow for the ELT pipeline:

  1. Kaynak veritabanındaki her tablo için son ELT iş ne zaman çalıştırıldığı kesme zamanı izleme.For each table in the source database, track the cutoff time when the last ELT job ran. Bu bilgiler, veri ambarı'nda Store.Store this information in the data warehouse. (Her zaman ilk kurulum üzerinde ayarlanmış olan ' 1-1-1900'.)(On initial setup, all times are set to '1-1-1900'.)

  2. Adım sırasında verileri dışarı aktarma, kesme zamanı saklı yordamlar kaynak veritabanında bir dizi parametre olarak geçirilir.During the data export step, the cutoff time is passed as a parameter to a set of stored procedures in the source database. Bu saklı yordamlar sorgu değiştirildi veya kesme saatten sonra oluşturulup herhangi bir kayıt için.These stored procedures query for any records that were changed or created after the cutoff time. Satış olgu tablosu için LastEditedWhen sütun kullanılır.For the Sales fact table, the LastEditedWhen column is used. Sistem sürümü tutulan zamana bağlı tablolarda boyut verileri için kullanılır.For the dimension data, system-versioned temporal tables are used.

  3. Veri Geçiş tamamlandığında, kesme zamanları depolayan tablosunu güncelleştirin.When the data migration is complete, update the table that stores the cutoff times.

Kaydetmek de kullanışlıdır bir kökenini her ELT çalıştırmak için.It's also useful to record a lineage for each ELT run. Belirli bir kaydı için kökenini verileri üreten bu çalıştırma ELT kayıtla ilişkilendirir.For a given record, the lineage associates that record with the ELT run that produced the data. ETL her çalıştırma için yeni bir kökenini kayıt gösteren başlangıç ve bitiş yükleme süreleri her tablo için oluşturulur.For each ETL run, a new lineage record is created for every table, showing the starting and ending load times. Her kayıt için kökenini anahtarları boyut ve olgu tablolarının içinde depolanır.The lineage keys for each record are stored in the dimension and fact tables.

Şehir Boyut tablosuna ekran görüntüsü

Yeni bir toplu işlemi veri ambarı'na yüklendikten sonra Analysis Services tablolu modeli yenileyin.After a new batch of data is loaded into the warehouse, refresh the Analysis Services tabular model. Bkz: REST API ile zaman uyumsuz yenileme.See Asynchronous refresh with the REST API.

Veri temizlemeData cleansing

Veri temizleme ELT işleminin bir parçası olmalıdır.Data cleansing should be part of the ELT process. Bu başvuru mimarisinde, bir veri kaynağı, hatalı veri kullanılabilir olduğundan bazı şehirler sıfır popülasyon belki de sahip olduğu Şehir popülasyon tablodur.In this reference architecture, one source of bad data is the city population table, where some cities have zero population, perhaps because no data was available. İşleme sırasında ELT işlem hattı şehirleri Şehir popülasyon tablodan kaldırır.During processing, the ELT pipeline removes those cities from the city population table. Dış tablolar yerine hazırlama tabloları üzerinde temizleme veri gerçekleştirin.Perform data cleansing on staging tables, rather than external tables.

Sıfır popülasyon olan şehirleri Şehir popülasyon tablodan kaldırır. saklı yordam aşağıda verilmiştir.Here is the stored procedure that removes the cities with zero population from the City Population table. (Kaynak dosya bulabilirsiniz burada.)(You can find the source file here.)

DELETE FROM [Integration].[CityPopulation_Staging]
WHERE RowNumber in (SELECT DISTINCT RowNumber
FROM [Integration].[CityPopulation_Staging]
WHERE POPULATION = 0
GROUP BY RowNumber
HAVING COUNT(RowNumber) = 4)

Dış veri kaynaklarıExternal data sources

Veri ambarları genellikle birden çok kaynaktan alınan verileri birleştirin.Data warehouses often consolidate data from multiple sources. Bu başvuru mimarisi, demografik bilgileri veri içeren bir dış veri kaynağını yükler.This reference architecture loads an external data source that contains demographics data. Bu veri kümesinin bir parçası olarak Azure blob depolamada kullanılabilir WorldWideImportersDW örnek.This dataset is available in Azure blob storage as part of the WorldWideImportersDW sample.

Azure Data Factory, blob depolama alanından doğrudan kopyalayabilir kullanarak blob depolama Bağlayıcısı.Azure Data Factory can copy directly from blob storage, using the blob storage connector. Ancak, bu nedenle bir blobu genel Okuma erişimiyle kopyalamak için kullanılamaz bağlayıcı bir bağlantı dizesi veya paylaşılan erişim imzası gerektirir.However, the connector requires a connection string or a shared access signature, so it can't be used to copy a blob with public read access. Geçici çözüm olarak, PolyBase, Blob Depolama alanı üzerinden bir dış tablo oluşturma ve ardından dış tablolar SQL veri ambarı'na kopyalamak için kullanabilirsiniz.As a workaround, you can use PolyBase to create an external table over Blob storage and then copy the external tables into SQL Data Warehouse.

Büyük ikili verileri işlemeHandling large binary data

Kaynak veritabanında tutan bir konum sütunu Şehir tablolu bir Coğrafya uzamsal veri türü.In the source database, the Cities table has a Location column that holds a geography spatial data type. SQL veri ambarı desteklemiyor Coğrafya yerel olarak, bu alan için dönüştürülür türü bir varbinary yükleme sırasında türü.SQL Data Warehouse doesn't support the geography type natively, so this field is converted to a varbinary type during loading. (Bkz desteklenmeyen veri türleri için geçici çözümler.)(See Workarounds for unsupported data types.)

Ancak, PolyBase en fazla sütun boyutunu destekler varbinary(8000), yani bazı veriler kesilebilir.However, PolyBase supports a maximum column size of varbinary(8000), which means some data could be truncated. Verileri dışarı aktarma sırasında öbeklere ayırmak ve ardından öbekleri şu şekilde yeniden birleştirmek için bu sorun için geçici bir çözüm şöyledir:A workaround for this problem is to break the data up into chunks during export, and then reassemble the chunks, as follows:

  1. Konum sütunu için bir geçici hazırlama tablosuna oluşturun.Create a temporary staging table for the Location column.

  2. Her şehir için 1'de elde edilen 8000-bayt öbeklere konum verileri bölme – N satırları her şehir için.For each city, split the location data into 8000-byte chunks, resulting in 1 – N rows for each city.

  3. Öbekleri yeniden birleştirmek için T-SQL kullanma PIVOT satırları sütunlara dönüştürmek ve ardından her şehir için sütun değerlerini birleştirmek için işleci.To reassemble the chunks, use the T-SQL PIVOT operator to convert rows into columns and then concatenate the column values for each city.

Her şehre farklı sayıda coğrafi veriler'e boyutuna bağlı olarak satır içine bölünür zorluktur.The challenge is that each city will be split into a different number of rows, depending on the size of geography data. PIVOT işlecine çalışmak her şehir aynı sayıda satır olması gerekir.For the PIVOT operator to work, every city must have the same number of rows. T-SQL sorgusu Bunun çalışmasını sağlamak için (görüntüleyebileceğiniz burada) her şehir, sonra Özet aynı sayıda sütuna sahip olacak şekilde boş değerler içeren satırları dışarı doldurulacak bazı püf noktaları yapar.To make this work, the T-SQL query (which you can view here) does some tricks to pad out the rows with blank values, so that every city has the same number of columns after the pivot. Aynı anda bir satırlarda döngü daha çok daha hızlı olmasını sonuçlanan sorgu ettik.The resulting query turns out to be much faster than looping through the rows one at a time.

Aynı yaklaşımı, görüntü verileri için kullanılır.The same approach is used for image data.

Yavaş boyutlarını değiştirmeSlowly changing dimensions

Veri boyutu göreceli olarak statik, ancak bunu değiştirebilirsiniz.Dimension data is relatively static, but it can change. Örneğin, bir ürün için farklı ürün kategorisi yeniden.For example, a product might get reassigned to a different product category. Boyutlar yavaş değişen işleme için birçok yaklaşım vardır.There are several approaches to handling slowly changing dimensions. Adlı bir ortak teknik tip 2, yeni bir kayıt boyutu değiştiğinde eklemektir.A common technique, called Type 2, is to add a new record whenever a dimension changes.

Tip 2 yaklaşımı uygulamak için verilen kayıt geçerlilik tarihi aralığının belirttiğiniz ek sütunlar boyut tabloları gerekir.In order to implement the Type 2 approach, dimension tables need additional columns that specify the effective date range for a given record. Bu nedenle Boyut tablosuna yapay bir birincil anahtarı olması gerekir Ayrıca, kaynak veritabanından birincil anahtarlar, çoğaltılır.Also, primary keys from the source database will be duplicated, so the dimension table must have an artificial primary key.

Aşağıdaki görüntüde Dimension.City tabloda gösterilmektedir.The following image shows the Dimension.City table. WWI City ID Kaynak veritabanından birincil anahtar sütunudur.The WWI City ID column is the primary key from the source database. City Key ETL işlem hattı sırasında oluşturulan yapay bir anahtar sütunudur.The City Key column is an artificial key generated during the ETL pipeline. Ayrıca tablo bildirimi Valid From ve Valid To her satırın geçerli olduğu zaman aralığını belirleyen sütun.Also notice that the table has Valid From and Valid To columns, which define the range when each row was valid. Geçerli değerlere sahip bir Valid To eşittir ' 9999-12-31'.Current values have a Valid To equal to '9999-12-31'.

Şehir Boyut tablosuna ekran görüntüsü

Bu yaklaşımın avantajı, analiz için yararlı olabilir geçmiş verileri koruduğundan emin olan.The advantage of this approach is that it preserves historical data, which can be valuable for analysis. Ancak, bu da aynı varlık için birden çok satır olacak anlamına gelir.However, it also means there will be multiple rows for the same entity. Örneğin, eşleşen kayıtları işte WWI City ID 28561 =:For example, here are the records that match WWI City ID = 28561:

Şehir boyut tablonun ikinci ekran görüntüsü

Her satış olgusu için bu durumu kendi lehine Boyut tablosunda Şehir, tek bir satır ile ilişkilendirmek için fatura tarihi karşılık gelen istediğiniz.For each Sales fact, you want to associate that fact with a single row in City dimension table, corresponding to the invoice date. ETL işleminin bir parçası olarak, ek bir sütun oluşturmaAs part of the ETL process, create an additional column that

Aşağıdaki T-SQL sorgusunu, her bir fatura şehri Boyut tablosuna doğru Şehir anahtarından ilişkilendirir geçici bir tablo oluşturur.The following T-SQL query creates a temporary table that associates each invoice with the correct City Key from the City dimension table.

CREATE TABLE CityHolder
WITH (HEAP , DISTRIBUTION = HASH([WWI Invoice ID]))
AS
SELECT DISTINCT s1.[WWI Invoice ID] AS [WWI Invoice ID],
                c.[City Key] AS [City Key]
    FROM [Integration].[Sale_Staging] s1
    CROSS APPLY (
                SELECT TOP 1 [City Key]
                    FROM [Dimension].[City]
                WHERE [WWI City ID] = s1.[WWI City ID]
                    AND s1.[Last Modified When] > [Valid From]
                    AND s1.[Last Modified When] <= [Valid To]
                ORDER BY [Valid From], [City Key] DESC
                ) c

Bu tablo, satış olgu tablosundaki bir sütunu doldurmak için kullanılır:This table is used to populate a column in the Sales fact table:

UPDATE [Integration].[Sale_Staging]
SET [Integration].[Sale_Staging].[WWI Customer ID] =  CustomerHolder.[WWI Customer ID]

Bu sütun için belirli bir satış faturası doğru Şehir kaydı bulmak için bir Power BI sorgu sağlar.This column enables a Power BI query to find the correct City record for a given sales invoice.

Güvenlikle ilgili dikkat edilmesi gerekenlerSecurity considerations

Ek güvenlik için kullandığınız sanal ağ hizmet uç noktaları yalnızca sanal ağ için Azure hizmet kaynaklarının güvenliğini sağlamak için.For additional security, you can use Virtual Network service endpoints to secure Azure service resources to only your virtual network. Bu, yalnızca sanal ağınızdan gelen trafiğe izin verdiğinden, bu kaynaklara genel Internet erişimini tamamen kaldırır.This fully removes public Internet access to those resources, allowing traffic only from your virtual network.

Bu yaklaşım ile Azure'da VNet oluşturma ve Azure Hizmetleri için özel bir hizmet uç noktası oluşturun.With this approach, you create a VNet in Azure and then create private service endpoints for Azure services. Bu hizmetler, ardından bu sanal ağdan trafiği kısıtlanır.Those services are then restricted to traffic from that virtual network. Bir ağ geçidi üzerinden şirket içi ağınızdan de ulaşabilir.You can also reach them from your on-premises network through a gateway.

Aşağıdaki sınırlamaları unutmayın:Be aware of the following limitations:

  • Zaman bu başvuru mimarisinde oluşturulduğu, sanal ağ hizmet uç noktaları Azure depolama ve Azure SQL veri ambarı, ancak Azure Analysis Services için desteklenir.At the time this reference architecture was created, VNet service endpoints are supported for Azure Storage and Azure SQL Data Warehouse, but not for Azure Analysis Service. En son durumu denetlemek burada.Check the latest status here.

  • Azure depolama için hizmet uç noktaları etkinleştirilirse, PolyBase veri depolama alanından SQL Data Warehouse'a veri kopyalanamıyor.If service endpoints are enabled for Azure Storage, PolyBase cannot copy data from Storage into SQL Data Warehouse. Bu sorun için bir risk azaltma yoktur.There is a mitigation for this issue. Daha fazla bilgi için Azure depolama ile sanal ağ hizmet uç noktaları kullanma etkileri.For more information, see Impact of using VNet Service Endpoints with Azure storage.

  • Verileri şirket içinden Azure Depolama'ya taşıma için şirket içi ya da ExpressRoute için genel IP adreslerini beyaz liste gerekir.To move data from on-premises into Azure Storage, you will need to whitelist public IP addresses from your on-premises or ExpressRoute. Ayrıntılar için bkz güvenli hale getirme Azure hizmetlerini sanal ağlar.For details, see Securing Azure services to virtual networks.

  • SQL veri ambarı'ndan verileri okumak Analysis Services'ı etkinleştirmek için SQL veri ambarı hizmet uç noktası içeren sanal ağa bir Windows VM dağıtın.To enable Analysis Services to read data from SQL Data Warehouse, deploy a Windows VM to the virtual network that contains the SQL Data Warehouse service endpoint. Yükleme Azure şirket içi veri ağ geçidi bu VM üzerinde.Install Azure On-premises Data Gateway on this VM. Ardından veri ağ geçidi için Azure Analysis Services sunucunuza bağlanın.Then connect your Azure Analysis service to the data gateway.

Çözümü dağıtmaDeploy the solution

Dağıtma ve çalıştırma başvuru uygulaması için adımları GitHub Benioku.To the deploy and run the reference implementation, follow the steps in the GitHub readme. Aşağıdakileri dağıtır:It deploys the following:

  • Bir şirket içi veritabanı sunucusu benzetimini yapmak için bir Windows VM.A Windows VM to simulate an on-premises database server. Bu, SQL Server 2017 ve Power BI Desktop ile birlikte ilgili araçları içerir.It includes SQL Server 2017 and related tools, along with Power BI Desktop.
  • Blob Depolama SQL Server veritabanından dışarı aktarılan verileri tutmak için sağlayan bir Azure depolama hesabı.An Azure storage account that provides Blob storage to hold data exported from the SQL Server database.
  • Bir Azure SQL veri ambarı örneği.An Azure SQL Data Warehouse instance.
  • Azure Analysis Services örneği.An Azure Analysis Services instance.
  • Azure Data Factory ve Data Factory işlem hattı ELT iş için.Azure Data Factory and the Data Factory pipeline for the ELT job.

Aşağıdaki gözden geçirmek isteyebilirsiniz Azure örnek senaryolar bazı teknolojiler kullanarak özel çözümler göstermektedir:You may want to review the following Azure example scenarios that demonstrate specific solutions using some of the same technologies: