Share via

Migrace dat, ETL a načítání pro migrace Netezza

  • Článek

Tento článek je druhou částí sedmidílné série, která poskytuje pokyny k migraci z Netezza do Azure Synapse Analytics. Tento článek se zaměřuje na osvědčené postupy pro etl a migraci zatížení.

Aspekty migrace dat

Počáteční rozhodnutí o migraci dat z Netezza

Při migraci datového skladu Netezza je potřeba položit několik základních otázek souvisejících s daty. Příklad:

  • Mají se migrovat nepoužívané struktury tabulek?

  • Jaký je nejlepší přístup k migraci, aby se minimalizovalo riziko a dopad na uživatele?

  • Při migraci datových tržítků: Zůstat fyzicky nebo virtuální?

Následující části popisují tyto body v kontextu migrace z Netezza.

Migrovat nepoužívané tabulky?

Tip

Ve starších systémech není neobvyklé, že tabulky budou v průběhu času redundantní – ve většině případů se nemusí migrovat.

Je vhodné migrovat jenom tabulky, které se používají v existujícím systému. Tabulky, které nejsou aktivní, se dají místo migrace archivovat, aby data byla v budoucnu v případě potřeby k dispozici. K určení, které tabulky se používají, je nejlepší místo dokumentace použít systémová metadata a soubory protokolů, protože dokumentace může být za aktuální.

Pokud je tato možnost povolená, tabulky historie dotazů Netezza obsahují informace, které můžou určit, kdy byla daná tabulka naposledy přístupná– a které se pak dají použít k rozhodnutí, jestli je tabulka kandidátem na migraci.

Tady je příklad dotazu, který hledá použití konkrétní tabulky v daném časovém intervalu:

SELECT FORMAT_TABLE_ACCESS (usage),
  hq.submittime
FROM "$v_hist_queries" hq
  INNER JOIN "$hist_table_access_3" hta USING
(NPSID, NPSINSTANCEID, OPID, SESSIONID)
WHERE hq.dbname = 'PROD'
AND hta.schemaname = 'ADMIN'
AND hta.tablename = 'TEST_1'
AND hq.SUBMITTIME > '01-01-2015'
AND hq.SUBMITTIME <= '08-06-2015'
AND
(
  instr(FORMAT_TABLE_ACCESS(usage),'ins') > 0
  OR instr(FORMAT_TABLE_ACCESS(usage),'upd') > 0
  OR instr(FORMAT_TABLE_ACCESS(usage),'del') > 0
)
AND status=0;

| FORMAT_TABLE_ACCESS | SUBMITTIME
----------------------+---------------------------
ins                   | 2015-06-16 18:32:25.728042
ins                   | 2015-06-16 17:46:14.337105
ins                   | 2015-06-16 17:47:14.430995
(3 rows)

Tento dotaz používá pomocnou funkci FORMAT_TABLE_ACCESS a číslici na konci zobrazení, aby odpovídal verzi historie nainstalovaných $v_hist_table_access_3 dotazů.

Jaký je nejlepší přístup k migraci, aby se minimalizovalo riziko a dopad na uživatele?

Tato otázka přichází často, protože společnosti mohou chtít snížit dopad změn na datový model datového skladu, aby se zlepšila flexibilita. Společnosti často vidí příležitost k další modernizaci nebo transformaci dat během migrace ETL. Tento přístup s sebou nese vyšší riziko, protože současně mění více faktorů, což ztěžuje porovnání výsledků starého systému s novým. Změny datového modelu v této části by také mohly ovlivnit nadřazené nebo podřízené úlohy ETL do jiných systémů. Vzhledem k tomuto riziku je lepší po migraci datového skladu tento rozsah přepracovat.

I když se datový model v rámci celkové migrace záměrně změní, je vhodné stávající model migrovat tak, jak je, a Azure Synapse, místo aby se na nové platformě přepracovávat. Tento přístup minimalizuje dopad na stávající produkční systémy a zároveň těží z výkonu a elastické škálovatelnosti platformy Azure pro jednorázové přepracování úloh.

Při migraci z Netezza je často stávající datový model již vhodný pro migraci do Azure Synapse.

Tip

Migrace stávajícího modelu tak, jak je, i když se v budoucnu plánuje změna datového modelu.

Migrovat datová tržiště: Zůstat fyzicky nebo virtuální?

Tip

Virtualizace datových tržítků může ušetřit prostředky úložiště a zpracování.

Ve starších prostředích datového skladu Netezza je běžným postupem vytvořit několik datových tržiště, která jsou strukturovaná tak, aby poskytovala dobrý výkon pro ad hoc samoobslužné dotazy a sestavy pro dané oddělení nebo obchodní funkce v rámci organizace. Datové tržiště se proto obvykle skládá z podmnožiny datového skladu a obsahuje agregované verze dat ve formě, která uživatelům umožňuje snadno se na tato data dotazovat s rychlou dobou odezvy pomocí uživatelsky přívětivých dotazovacích nástrojů, jako jsou Microsoft Power BI, Tableau nebo MicroStrategy. Tento formulář je obvykle dimenzionální datový model. Jedním z použití datových tržítků je zveřejnění dat v použitelné podobě, a to i v případě, že podkladový datový model skladu je něco jiného, například trezor dat.

Samostatná datová tržiště pro jednotlivé obchodní jednotky v rámci organizace můžete použít k implementaci robustních režimů zabezpečení dat tím, že uživatelům povolíte přístup pouze ke konkrétním datovým tržinám, která jsou pro ně relevantní, a odstraníte, zamlžujete nebo anonymizujete citlivá data.

Pokud jsou tato datová tržiště implementovaná jako fyzické tabulky, budou k jejich uložení vyžadovat další prostředky úložiště a další zpracování, aby je bylo možné pravidelně sestavovat a aktualizovat. Data v tržině budou také pouze aktuální jako poslední operace aktualizace, a proto mohou být nevhodná pro vysoce nestálé řídicí panely dat.

Tip

Výkon a škálovatelnost Azure Synapse umožňují virtualizaci bez obětování výkonu.

S nástupem relativně levných škálovatelných architektur MPP, jako je Azure Synapse, a inherentních charakteristik výkonu těchto architektur může být možné, že můžete poskytovat funkce datového tržiště, aniž byste museli vytvořit instanci tržiště jako sady fyzických tabulek. Toho lze dosáhnout efektivní virtualizací datových tržítků prostřednictvím zobrazení SQL do hlavního datového skladu nebo prostřednictvím vrstvy virtualizace pomocí funkcí, jako jsou zobrazení v Azure nebo produkty vizualizace partnerů Microsoftu. Tento přístup zjednodušuje nebo eliminuje potřebu dalšího zpracování úložiště a agregace a snižuje celkový počet databázových objektů, které se mají migrovat.

Tento přístup má další potenciální výhodu. Implementací logiky agregace a spojení v rámci vrstvy virtualizace a prezentováním externích nástrojů pro vytváření sestav prostřednictvím virtualizovaného zobrazení se zpracování potřebné k vytvoření těchto zobrazení "posune dolů" do datového skladu, což je obecně nejlepší místo pro spouštění spojení, agregací a dalších souvisejících operací na velkých objemech dat.

Primárními faktory pro výběr implementace virtuálního datového tržiště před fyzickým datovým tržištěm jsou:

  • Větší flexibilita: Virtuální datové tržiště se snadněji mění než fyzické tabulky a přidružené procesy ETL.

  • Nižší celkové náklady na vlastnictví: Virtualizovaná implementace vyžaduje méně úložišť dat a kopií dat.

  • Odstranění úloh ETL za účelem migrace a zjednodušení architektury datového skladu ve virtualizovaném prostředí

  • Výkon: Přestože fyzická datová tržiště byla v minulosti výkonnější, produkty virtualizace teď implementují inteligentní techniky ukládání do mezipaměti, které zmírňují jejich zmírnění.

Migrace dat z Netezza

Vysvětlení dat

Součástí plánování migrace je podrobné pochopení objemu dat, která je potřeba migrovat, protože to může mít vliv na rozhodování o přístupu k migraci. Pomocí systémových metadat můžete určit fyzický prostor, který "nezpracovaná data" zabírají v tabulkách, které se mají migrovat. V tomto kontextu "nezpracovaná data" znamenají množství místa, které využívají řádky dat v tabulce, s výjimkou režijních nákladů, jako jsou indexy a komprese. To platí zejména pro největší tabulky faktů, protože tyto tabulky obvykle tvoří více než 95 % dat.

Přesný počet dat, která se mají migrovat pro danou tabulku, můžete získat extrahováním reprezentativního vzorku dat – například jednoho milionu řádků – do nekomprimovaného datového souboru ASCII s oddělovači. Potom pomocí velikosti tohoto souboru získáte průměrnou nezpracovanou velikost dat na řádek dané tabulky. Nakonec vynásobte průměrnou velikost celkovým počtem řádků v celé tabulce, abyste získali nezpracovanou velikost dat pro tabulku. Tuto nezpracovanou velikost dat použijte při plánování.

Mapování datového typu Netezza

Tip

Vyhodnoťte dopad nepodporovaných datových typů v rámci přípravné fáze.

Většina datových typů Netezza má v Azure Synapse přímý ekvivalent. Následující tabulka uvádí tyto datové typy společně s doporučeným přístupem k jejich mapování.

Datový typ Netezza datový typ Azure Synapse
BIGINT BIGINT
BINÁRNÍ VARYING(n) VARBINARY(n)
BOOLEAN BIT
BYTEINT TINYINT
CHARACTER VARYING(n) VARCHAR(n)
CHARACTER(n) ZNAK(n)
DATE (Datum) DATE(date)
DECIMAL(p,s) DECIMAL(p,s)
DVOJITÁ PŘESNOST FLOAT
FLOAT(n) FLOAT(n)
CELÉ ČÍSLO INT
INTERVAL Datové typy INTERVAL se v Azure Synapse Analytics v současné době přímo nepodporují, ale je možné je vypočítat pomocí dočasných funkcí, jako je DATEDIFF.
PENÍZE PENÍZE
NÁRODNÍ ZNAK VARYING(n) NVARCHAR(n)
NÁRODNÍ ZNAK(n) NCHAR(n)
NUMERIC(p,s) NUMERIC(p,s)
REÁLNÉ REÁLNÉ
SMALLINT SMALLINT
ST_GEOMETRY(n) Prostorové datové typy, jako jsou ST_GEOMETRY, nejsou v současné době ve službě Azure Synapse Analytics podporované, ale data můžou být uložená jako VARCHAR nebo VARBINARY.
ČAS ČAS
ČAS S ČASOVÝM PÁSMEM DATETIMEOFFSET
ČASOVÉ RAZÍTKO DATETIME

Pomocí metadat z tabulek katalogu Netezza určete, jestli je potřeba některý z těchto datových typů migrovat, a povolte to ve svém plánu migrace. Důležitá zobrazení metadat v netezza pro tento typ dotazu jsou:

  • _V_USER: Zobrazení uživatele poskytuje informace o uživatelích v systému Netezza.

  • _V_TABLE: Zobrazení tabulky obsahuje seznam tabulek vytvořených v výkonnostním systému Netezza.

  • _V_RELATION_COLUMN: Zobrazení systémového katalogu relačních sloupců obsahuje sloupce, které jsou k dispozici v tabulce.

  • _V_OBJECTS: Zobrazení objektů obsahuje seznam různých objektů, jako jsou tabulky, zobrazení, funkce atd., které jsou k dispozici v nástroji Netezza.

Například tento dotaz NEtezza SQL zobrazuje sloupce a typy sloupců:

SELECT
tablename,
  attname AS COL_NAME,
  b.FORMAT_TYPE AS COL_TYPE,
  attnum AS COL_NUM
FROM _v_table a
  JOIN _v_relation_column b
  ON a.objid = b.objid
WHERE a.tablename = 'ATT_TEST'
AND a.schema = 'ADMIN'
ORDER BY attnum;

TABLENAME | COL_NAME    | COL_TYPE             | COL_NUM
----------+-------------+----------------------+--------
ATT_TEST  | COL_INT     | INTEGER              | 1
ATT_TEST  | COL_NUMERIC | NUMERIC(10,2)        | 2
ATT_TEST  | COL_VARCHAR | CHARACTER VARYING(5) | 3
ATT_TEST  | COL_DATE    | DATE                 | 4
(4 rows)

Dotaz je možné upravit tak, aby hledal výskyty nepodporovaných datových typů ve všech tabulkách.

Azure Data Factory můžete použít k přesunu dat ze staršího prostředí Netezza. Další informace najdete v článku Konektor IBM Netezza.

Dodavatelé třetích stran nabízejí nástroje a služby pro automatizaci migrace, včetně mapování datových typů, jak je popsáno výše. Také nástroje ETL třetích stran, jako je Informatica nebo Talend, které se už používají v prostředí Netezza, můžou implementovat všechny požadované transformace dat. V další části se seznámíte s migrací stávajících procesů ETL třetích stran.

Aspekty migrace ETL

Počáteční rozhodnutí týkající se migrace Netezza ETL

Tip

Naplánujte si přístup k migraci ETL předem a tam, kde je to vhodné, využijte zařízení Azure.

Pro zpracování ETL/ELT můžou starší datové sklady Netezza používat vlastní skripty využívající nástroje Netezza, jako jsou nzsql a nzload, nebo nástroje ETL třetích stran, jako jsou Informatica nebo Ab Initio. Někdy datové sklady Netezza používají kombinaci přístupů ETL a ELT, které se v průběhu času vyvíjejí. Při plánování migrace do Azure Synapse musíte určit nejlepší způsob implementace požadovaného zpracování ETL/ELT v novém prostředí a zároveň minimalizovat související náklady a rizika. Další informace o zpracování ETL a ELT najdete v tématu Přístup k návrhu ELT a ETL.

Následující části popisují možnosti migrace a doporučení pro různé případy použití. Tento vývojový diagram shrnuje jeden přístup:

Vývojový diagram možností migrace a doporučení

Prvním krokem je vždy vytvoření inventáře procesů ETL/ELT, které je potřeba migrovat. Stejně jako u jiných kroků je možné, že díky standardním integrovaným funkcím Azure není nutné migrovat některé existující procesy. Pro účely plánování je důležité porozumět rozsahu migrace, která se má provést.

V předchozím vývojovém diagramu se rozhodnutí 1 týká základního rozhodnutí o tom, jestli se má migrace do zcela nativního prostředí Azure provést. Pokud přecházíte do zcela nativního prostředí Azure, doporučujeme přepracovat zpracování ETL pomocí kanálů a aktivit v Azure Data Factory nebo Azure Synapse Pipelines. Pokud nepřesunete do zcela nativního prostředí Azure, pak rozhodnutí 2 spočívá v tom, jestli se už používá stávající nástroj ETL třetí strany.

Tip

Využijte investice do stávajících nástrojů třetích stran ke snížení nákladů a rizik.

Pokud se nástroj ETL třetí strany už používá a zejména pokud se do dovedností hodně investovalo nebo ho využívá několik stávajících pracovních postupů a plánů, pak rozhodnutí č. 3 spočívá v tom, jestli nástroj dokáže efektivně podporovat Azure Synapse jako cílové prostředí. V ideálním případě bude nástroj obsahovat "nativní" konektory, které můžou využívat funkce Azure, jako je PolyBase nebo COPY INTO, k co nejefektivnějšímu načítání dat. Existuje způsob, jak volat externí proces, jako je PolyBase nebo COPY INTO, a předat příslušné parametry. V takovém případě využijte stávající dovednosti a pracovní postupy, Azure Synapse jako nové cílové prostředí.

Pokud se rozhodnete zachovat existující nástroj ETL třetí strany, může mít výhody spuštění tohoto nástroje v prostředí Azure (nikoli na existujícím místním serveru ETL) a Azure Data Factory zpracovávat celkovou orchestraci stávajících pracovních postupů. Jednou z konkrétních výhod je, že z Azure je potřeba stahovat méně dat, zpracovávat je a pak nahrávat zpět do Azure. Rozhodnutí 4 tedy spočívá v tom, jestli nechat stávající nástroj spuštěný tak, jak je, nebo ho přesunout do prostředí Azure, abyste dosáhli výhod nákladů, výkonu a škálovatelnosti.

Přepracování existujících skriptů specifických pro Netezza

Pokud některé nebo všechny stávající zpracování ETL/ELT skladu Netezza zpracovávají vlastní skripty, které využívají nástroje specifické pro Netezza, jako je nzsql nebo nzload, je potřeba tyto skripty překódovat pro nové prostředí Azure Synapse. Podobně pokud byly procesy ETL implementovány pomocí uložených procedur v netezza, bude nutné je také překódovat.

Tip

Inventář úloh ETL, které se mají migrovat, by měl obsahovat skripty a uložené procedury.

Některé prvky procesu ETL se dají snadno migrovat, například jednoduchým hromadným načtením dat z externího souboru do pracovní tabulky. Je dokonce možné tyto části procesu automatizovat, například pomocí PolyBase místo nzload. Další části procesu, které obsahují libovolně složité sql a/nebo uložené procedury, budou trvat delší dobu, než se přepracují.

Jedním ze způsobů, jak otestovat kompatibilitu netezza SQL s Azure Synapse, je zachytit některé reprezentativní příkazy SQL z historie dotazů Netezza, pak před tyto dotazy EXPLAINzadat předponu a pak – za předpokladu migrovaného datového modelu podobného typu v Azure Synapse – spustit tyto EXPLAIN příkazy v Azure Synapse. Jakýkoli nekompatibilní SQL vygeneruje chybu a informace o chybě můžou určit měřítko přepočítávání úlohy.

Partneři Microsoftu nabízejí nástroje a služby pro migraci netezza SQL a uložených procedur do Azure Synapse.

Použití nástrojů ETL třetích stran

Jak je popsáno v předchozí části, v mnoha případech bude stávající starší systém datového skladu již naplněn a udržován produkty ETL třetích stran. Seznam partnerů microsoftu pro integraci dat pro Azure Synapse najdete v tématu Partneři pro integraci dat.

Načítání dat z Netezza

Volby dostupné při načítání dat z Netezza

Tip

Nástroje třetích stran můžou proces migrace zjednodušit a automatizovat, a tím snížit riziko.

Pokud jde o migraci dat z datového skladu Netezza, existuje několik základních otázek souvisejících s načítáním dat, které je potřeba vyřešit. Budete se muset rozhodnout, jak se data fyzicky přesunou ze stávajícího místního prostředí Netezza do Azure Synapse v cloudu a které nástroje se použijí k provedení přenosu a načítání. Zvažte následující otázky, které jsou popsány v dalších částech.

  • Budete extrahovat data do souborů nebo je přesunout přímo přes síťové připojení?

  • Budete orchestrovat proces ze zdrojového systému nebo z cílového prostředí Azure?

  • Které nástroje použijete k automatizaci a správě procesu?

Chcete přenášet data prostřednictvím souborů nebo síťového připojení?

Tip

Seznamte se s objemy dat, které se mají migrovat, a dostupnou šířkou pásma sítě, protože tyto faktory ovlivňují rozhodování o přístupu k migraci.

Po vytvoření databázových tabulek, které se mají migrovat v Azure Synapse, můžete data přesunout a naplnit je ze staršího systému Netezza do nového prostředí. Existují dva základní přístupy:

  • Extrakce souborů: Extrahujte data z tabulek Netezza do plochých souborů, obvykle ve formátu CSV, pomocí příkazu nzsql s parametrem -o nebo příkazem CREATE EXTERNAL TABLE . Kdykoli je to možné, používejte externí tabulku, protože je to nejúčinnější z hlediska propustnosti dat. Následující příklad SQL vytvoří soubor CSV prostřednictvím externí tabulky:

    CREATE EXTERNAL TABLE '/data/export.csv' USING (delimiter ',')
AS SELECT col1, col2, expr1, expr2, col3, col1 || col2 FROM your table;

    Externí tabulku použijte, pokud exportujete data do připojeného systému souborů na místním hostiteli Netezza. Pokud exportujete data do vzdáleného počítače s nainstalovaným rozhraním JDBC, ODBC nebo OLEDB, pak je USING klauzule "remotesource odbc".

    Tento přístup vyžaduje místo pro získání extrahovaných datových souborů. Místo může být místní pro zdrojovou databázi Netezza (pokud je k dispozici dostatečné úložiště) nebo vzdálené v Azure Blob Storage. Nejlepšího výkonu dosáhnete při místním zápisu souboru, protože se tím vyhnete režii sítě.

    Pokud chcete minimalizovat požadavky na úložiště a síťový přenos, je vhodné zkomprimovat extrahované datové soubory pomocí nástroje, jako je gzip.

    Po extrahování lze ploché soubory přesunout do Azure Blob Storage (společně s cílovou Azure Synapse instancí) nebo načíst přímo do Azure Synapse pomocí PolyBase nebo COPY INTO. Metoda fyzického přesunu dat z místního úložiště do cloudového prostředí Azure závisí na množství dat a dostupné šířce pásma sítě.

    Microsoft nabízí různé možnosti pro přesun velkých objemů dat, včetně AzCopy pro přesun souborů v síti do Služby Azure Storage, Azure ExpressRoute pro přesun hromadných dat přes privátní síťové připojení a Azure Data Boxu pro soubory přesouvající se do fyzického paměťového zařízení, které se pak odešle do datacentra Azure k načtení. Další informace najdete v tématu Přenos dat.

  • Přímé extrakce a načítání přes síť: Cílové prostředí Azure odešle požadavek na extrakci dat, obvykle prostřednictvím příkazu SQL, do staršího systému Netezza, aby extrahovali data. Výsledky se odesílají přes síť a načtou se přímo do Azure Synapse, aniž by bylo nutné převést data do přechodných souborů. Omezujícím faktorem v tomto scénáři je obvykle šířka pásma síťového připojení mezi databází Netezza a prostředím Azure. U velmi velkých objemů dat nemusí být tento přístup praktický.

Existuje také hybridní přístup, který používá obě metody. Pro menší tabulky dimenzí a vzorky větších tabulek faktů můžete například použít přístup extrakce přímo ze sítě, abyste rychle poskytli testovací prostředí v Azure Synapse. Pro velké objemy historických tabulek faktů můžete použít přístup k extrakci a přenosu souborů pomocí Azure Data Boxu.

Chcete orchestrovat z Netezza nebo Azure?

Doporučeným přístupem při přechodu na Azure Synapse je orchestrace extrakce a načítání dat z prostředí Azure pomocí služby Azure Synapse Pipelines nebo Azure Data Factory a také přidružených nástrojů, jako je PolyBase nebo COPY INTO, pro co nejefektivnější načítání dat. Tento přístup využívá možnosti Azure a poskytuje snadný způsob vytváření opakovaně použitelných kanálů načítání dat.

Mezi další výhody tohoto přístupu patří menší dopad na systém Netezza během procesu načítání dat, protože proces správy a načítání běží v Azure, a možnost automatizovat proces pomocí kanálů načítání dat založených na metadatech.

Které nástroje je možné použít?

Úkolem transformace a přesunu dat je základní funkcí všech produktů ETL. Pokud se některý z těchto produktů už používá ve stávajícím prostředí Netezza, může použití existujícího nástroje ETL zjednodušit migraci dat z netezza do Azure Synapse. Tento přístup předpokládá, že nástroj ETL podporuje Azure Synapse jako cílové prostředí. Další informace o nástrojích, které podporují Azure Synapse, najdete v tématu Partneři pro integraci dat.

Pokud používáte nástroj ETL, zvažte jeho spuštění v prostředí Azure, abyste mohli využívat výhod cloudového výkonu, škálovatelnosti a nákladů Azure a uvolnili prostředky v datacentru Netezza. Další výhodou je menší přesun dat mezi cloudem a místním prostředím.

Souhrn

Abychom to shrnuli, naše doporučení pro migraci dat a přidružených procesů ETL z Netezza do Azure Synapse jsou:

  • Naplánujte předem, abyste zajistili úspěšné cvičení migrace.

  • Vytvořte podrobný inventář dat a procesů, které se mají migrovat co nejdříve.

  • Pomocí systémových metadat a souborů protokolů můžete přesně porozumět datům a využití procesů. Nespoléhejte na dokumentaci, protože může být za aktuální.

  • Seznamte se s objemy dat, které se mají migrovat, a šířkou pásma sítě mezi místním datacentrem a cloudovými prostředími Azure.

  • Využijte standardní integrované funkce Azure k minimalizaci úloh migrace.

  • Identifikujte a seznamte se s nejúčinnějšími nástroji pro extrakci a načítání dat v prostředích Netezza i Azure. V každé fázi procesu používejte příslušné nástroje.

  • Pomocí zařízení Azure, jako jsou Azure Synapse Pipelines nebo Azure Data Factory, můžete orchestrovat a automatizovat proces migrace a zároveň minimalizovat dopad na systém Netezza.

Další kroky

Další informace o operacích zabezpečení přístupu najdete v dalším článku této série: Zabezpečení, přístup a operace pro migrace Netezza.