Megosztás a következőn keresztül:


Adatok betöltése az Azure Cosmos DB-ből az Azure Data Explorerbe

Az Azure Data Explorer Azure Cosmos DB for NoSql változáscsatornahasználatával támogatja adatbetöltési. A Cosmos DB változáscsatorna adatkapcsolata egy betöltési folyamat, amely figyeli a Cosmos DB változáscsatornáját, és betölti az adatokat az Adatkezelő táblájába. A változáscsatorna figyeli az új és frissített dokumentumokat, de nem naplózza a törléseket. Az Azure Data Explorer adatbetöltésével kapcsolatos általános információkért tekintse meg Azure Data Explorer-adatbetöltés áttekintését.

Minden adatkapcsolat figyel egy adott Cosmos DB-tárolót, és adatokat betölt egy adott táblába (több kapcsolat is betölthető egyetlen táblában). A betöltési módszer támogatja a streambetöltést (ha engedélyezve van) és a sorban álló betöltést.

A Cosmos DB változáscsatorna-adatkapcsolatának két fő forgatókönyve a következő:

Ebben a cikkben megtudhatja, hogyan állíthat be Cosmos DB változáscsatorna-adatkapcsolatot az adatok Azure Data Explorerbe való betöltéséhez a rendszer által felügyelt identitással. Mielőtt elkezdené, tekintse át a szempontokat.

Az összekötő beállításához kövesse az alábbi lépéseket:

1. lépés: Válasszon ki egy Azure Data Explorer-táblát, és konfigurálja a táblaleképezési

2. lépés: Cosmos DB-adatkapcsolat létrehozása

3. lépés: Az adatkapcsolat tesztelése

Előfeltételek

1. lépés: Válasszon ki egy Azure Data Explorer-táblát, és konfigurálja a táblaleképezést

Mielőtt létrehoz egy adatkapcsolatot, hozzon létre egy táblát, amelyben tárolni fogja a betöltött adatokat, és alkalmazza a sémának megfelelő leképezést a forrás Cosmos DB-tárolóban. Ha a forgatókönyv több mint egyszerű mezők leképezését igényli, frissítési szabályzatok használatával átalakíthatja a változáscsatornából betöltött adatokat és leképezheti azokat.

Az alábbiakban egy Cosmos DB-tárolóban lévő elem mintaséma látható:

{
    "id": "17313a67-362b-494f-b948-e2a8e95e237e",
    "name": "Cousteau",
    "_rid": "pL0MAJ0Plo0CAAAAAAAAAA==",
    "_self": "dbs/pL0MAA==/colls/pL0MAJ0Plo0=/docs/pL0MAJ0Plo0CAAAAAAAAAA==/",
    "_etag": "\"000037fc-0000-0700-0000-626a44110000\"",
    "_attachments": "attachments/",
    "_ts": 1651131409
}

Táblázat létrehozásához és táblázatleképezés alkalmazásához kövesse az alábbi lépéseket:

  1. Az Azure Data Explorer webes felhasználói felületén a bal oldali navigációs menüben válassza a Lekérdezéslehetőséget, majd válassza ki azt az adatbázist, amelyben létre szeretné hozni a táblát.

  2. Futtassa a következő parancsot egy TestTablenevű tábla létrehozásához.

    .create table TestTable(Id:string, Name:string, _ts:long, _timestamp:datetime)
    
  3. Futtassa a következő parancsot a táblaleképezés létrehozásához.

    A parancs a Cosmos DB JSON-dokumentum egyéni tulajdonságait a TestTable tábla oszlopaihoz rendeli le az alábbiak szerint:

    Cosmos DB tulajdonság Táblázat oszlopa Transzformáció
    azonosító Azonosító Egyik sem
    név Név Egyik sem
    _ts _Ts Egyik sem
    _ts _időbélyeg használatával_ts (UNIX másodperc) értéket átalakítja _timestamp () értékké

    Jegyzet

    A következő időbélyeg-oszlopokat javasoljuk:

    • _ts: Ezzel az oszlopmal egyeztethet adatokat a Cosmos DB-vel.
    • _timestamp: Ezzel az oszloppal hatékony időszűrőket futtathat a Kusto-lekérdezésekben. További információ: A lekérdezés ajánlott eljárása.
    .create table TestTable ingestion json mapping "DocumentMapping"
    ```
    [
        {"column":"Id","path":"$.id"},
        {"column":"Name","path":"$.name"},
        {"column":"_ts","path":"$._ts"},
        {"column":"_timestamp","path":"$._ts", "transform":"DateTimeFromUnixSeconds"}
    ]
    ```
    

Adatok átalakítása és leképezése frissítési szabályzatokkal

Ha a forgatókönyv több mint egyszerű mezők leképezését igényli, a frissítési szabályzatok segítségével átalakíthatja és megfeleltetheti a változáscsatornából betöltött adatokat.

frissítési irányelvek az adatok táblázatba történő betöltés közbeni átalakításának módját jelentik. A Kusto lekérdezési nyelven vannak megírva, és a betöltési folyamaton futnak. A Cosmos DB változáscsatorna-betöltési adatainak átalakítására használhatók, például az alábbi esetekben:

  • A dokumentumok olyan tömböket tartalmaznak, amelyek könnyebben lekérdezhetők, ha több sorban vannak átalakítva a mv-expand operátor használatával.
  • Ki szeretné szűrni a dokumentumokat. A dokumentumokat például típus szerint szűrheti a where operátorral.
  • Összetett logikája nem jeleníthető meg táblázatleképezésben.

A frissítési szabályzatok létrehozásáról és kezeléséről további információt Frissítési szabályzatok áttekintésecímű témakörben talál.

2. lépés: Cosmos DB-adatkapcsolat létrehozása

Az adatösszekötő létrehozásához az alábbi módszereket használhatja:

  1. Az Azure Portalon nyissa meg a fürt áttekintési lapját, majd válassza a Első lépések lapot.

  2. Az Adatbetöltés csempén válassza Adatkapcsolat létrehozása>Cosmos DBlehetőséget.

    Képernyőkép az Első lépések lapról, amelyen a Cosmos DB-adatkapcsolat létrehozása lehetőség látható.

  3. A Cosmos DB Adatkapcsolat létrehozása panelen töltse ki az űrlapot a táblázat adataival:

    Képernyőkép az adatkapcsolat panelről, amelyen az űrlapmezők értékei láthatók.

    Mező Leírás
    adatbázisnév Válassza ki azt az Azure Data Explorer-adatbázist, amelybe adatokat szeretne betöltésre.
    adatkapcsolat-neve Adja meg az adatkapcsolat nevét.
    Előfizetés Válassza ki a Cosmos DB NoSQL-fiókot tartalmazó előfizetést.
    Cosmos DB-fiók Válassza ki azt a Cosmos DB-fiókot, amelyből adatokat szeretne betöltésre.
    SQL adatbázis Válassza ki azt a Cosmos DB-adatbázist, amelyből adatokat szeretne betöltésre.
    SQL-tároló Válassza ki azt a Cosmos DB-tárolót, amelyből adatokat szeretne betöltésre.
    táblanév Adja meg az Azure Data Explorer tábla nevét, amelybe adatokat szeretne betöltésre.
    leképezés neve Igény szerint adja meg az adatkapcsolathoz használni kívánt leképezési nevet.
  4. A Speciális beállítások szakaszban tegye a következőket:

    1. Adja meg az eseménylekérés kezdő dátumát. Ettől az időtől kezdve kezdi meg a csatlakozó az adatok betöltését. Ha nem ad meg időt, az összekötő megkezdi az adatok betöltését az adatkapcsolat létrehozásakor. Az ajánlott dátumformátum az ISO 8601 UTC szabvány, amely a következőképpen van megadva: yyyy-MM-ddTHH:mm:ss.fffffffZ.

    2. Válassza ki a felhasználó által beállított majd aztán az identitást. Alapértelmezés szerint a rendszer által hozzárendelt felügyelt identitást használja a kapcsolat. Szükség esetén használhat egy felhasználó által hozzárendelt identitást.

      Képernyőkép az adatkapcsolat panelről, amelyen az Előzetes beállítások láthatók.

  5. Válassza a Create lehetőséget az adatkapcsolat létrehozásához.

3. lépés: Az adatkapcsolat tesztelése

  1. A Cosmos DB-tárolóba szúrja be a következő dokumentumot:

    {
        "name":"Cousteau"
    }
    
  2. Az Azure Data Explorer webes felhasználói felületén futtassa a következő lekérdezést:

    TestTable
    

    Az eredményhalmaznak a következő képhez hasonlóan kell kinéznie:

    Az eredmények panel képernyőképe, amelyen a betöltött dokumentum látható.

Jegyzet

Az Azure Data Explorer egy aggregációs (kötegelési) szabályzattal rendelkezik az üzenetsoros adatbetöltéshez, amelynek célja a betöltési folyamat optimalizálása. Az alapértelmezett kötegelési szabályzat úgy van konfigurálva, hogy lezárjon egy köteget, ha az alábbi feltételek egyike igaz a kötegre: legfeljebb 5 perc késleltetési idő, egy GB teljes méret vagy 1000 blob. Ezért késést tapasztalhat. Ha további információra van szüksége, tekintse meg a kötegelési szabályzat-et. A késés csökkentése érdekében konfigurálja a táblázatot a streamelés támogatásához. Nézd meg: streamelési szabályzat.

Megfontolások

A Cosmos DB változáscsatornára az alábbi szempontok vonatkoznak:

  • A változások hírcsatornája nem teszi elérhetővé törlési eseményeket.

    A Cosmos DB változáscsatornája csak új és frissített dokumentumokat tartalmaz. Ha tudnia kell a törölt dokumentumokról, konfigurálhatja, hogy a hírcsatorna egy helyreállítható jelölővel jelöljön meg egy Cosmos DB-dokumentumot töröltként. A program hozzáad egy tulajdonságot a frissítési eseményekhez, amelyek jelzik, hogy törölték-e a dokumentumot. Ezután a lekérdezések where operátorával szűrheti őket.

    Ha például a törölt tulajdonságot egy IsDeletednevű táblaoszlophoz rendeli, a törölt dokumentumokat az alábbi lekérdezéssel szűrheti ki:

    TestTable
    | where not(IsDeleted)
    
  • A változáscsatorna csak a dokumentum legújabb frissítését teszi elérhetővé.

    A második szempont következményeinek megértéséhez vizsgálja meg a következő forgatókönyvet:

    A Cosmos DB-tároló A és Bdokumentumokat tartalmaz. A foo nevű tulajdonság változásai az alábbi táblázatban láthatók.

    Dokumentumazonosító tulajdonság foo Esemény Dokumentum időbélyege (_ts)
    Egy Piros Alkotás 10
    B Kék Alkotás 20
    Egy Narancs Frissít 30
    A Rózsaszín Frissítés 40
    B Lila Frissít 50
    Egy Kármin Frissít 50
    B NeonBlue Frissít 70

    A változáscsatorna API-t az adatösszekötő rendszeres időközönként, általában néhány másodpercenként kérdezi le. Minden lekérdezés tartalmazza a tárolóban a hívások között bekövetkezett változásokat, de csak a legfrissebb módosítási verziót dokumentumonként.

    A probléma szemléltetéséhez fontolja meg az API-hívások egy sorozatát a következő időbélyegekkel: 15, 35, 55és 75, amint az az alábbi táblázatban látható.

    API-hívás időbélyege Dokumentumazonosító Tulajdonság foo Dokumentum időbélyege (_ts)
    15 Egy Piros 10
    35 B Kék 20
    35 Egy Narancs 30
    55 B Lila 50
    55 Egy Kármin 60
    75 B NeonBlue 70

    Ha összehasonlítja az API-eredményeket a Cosmos DB-dokumentumban végrehajtott módosítások listájával, láthatja, hogy ezek nem egyeznek. A Aszámú dokumentum frissítési eseménye, amely a változástáblában az időbélyeg 40-nél kiemelve van, nem jelenik meg az API-hívás eredményében.

    Annak megértéséhez, hogy miért nem jelenik meg az esemény, megvizsgáljuk a dokumentum A módosításait az API-hívások 35-ös és 55-ös időbélyegénél. A két hívás között a dokumentum A kétszer módosult, az alábbiak szerint:

    Dokumentumazonosító Tulajdonság foo Esemény Dokumentum időbélyege (_ts)
    Egy Rózsaszín Frissít 40
    Egy Kármin Frissít 50

    Amikor az API-hívás az 55-ös időbélyegnél történik, a változáscsatorna API a dokumentum legújabb verzióját adja vissza. Ebben az esetben a dokumentum legújabb verziója A az 50-es időbélyeg szerinti frissítés, amely a foo tulajdonság frissítését jelenti, Rózsaszín-ről Carmin-re.

    Emiatt az adatösszekötő kihagyhat néhány köztes dokumentummódosítást. Előfordulhat például, hogy néhány esemény kimarad, ha az adatkapcsolati szolgáltatás néhány percig nem működik, vagy ha a dokumentumváltozások gyakorisága magasabb, mint az API lekérdezési gyakorisága. A rendszer azonban minden dokumentum legújabb állapotát rögzíti.

  • Cosmos DB-tároló törlése és visszaállítása nem támogatott

    Az Azure Data Explorer nyomon követi a változáscsatornát úgy, hogy ellenőrzi a "pozíciót" a hírcsatornában. Ez a tároló minden egyes fizikai partíciójára vonatkozóan folytatási token használatával történik. A tároló törlése/ismételt létrehozásakor a folytatási token érvénytelen, és nem áll vissza az alaphelyzetbe. Ebben az esetben törölnie kell és újra létre kell hoznia az adatkapcsolatot.

Költség becslése

Mennyire befolyásolja a Cosmos DB adatkapcsolat használata a Cosmos DB-tároló kérelemegységeinek használatát?

Az összekötő meghívja a Cosmos DB Change Feed API-t a tároló minden fizikai partícióján, akár másodpercenként egyszer is. Ezekhez a meghívásokhoz a következő költségek tartoznak:

Költség Leírás
Rögzített költségek A rögzített költségek másodpercenként körülbelül 2 kérelemegységet jelentenek fizikai partíciónként.
Változó költségek A változó költségek a dokumentumok írásához használt kérelemegységek körülbelül 2%, bár ez a forgatókönyvtől függően változhat. Ha például 100 dokumentumot ír egy Cosmos DB tárolóba, a dokumentumok írásának költsége 1000 kérés-jegység. Az összekötőnek a dokumentum olvasásához való használatának megfelelő költsége körülbelül 2% az írásuk költsége, körülbelül 20 kérelemegység.