Ajánlott eljárások: GDPR- és CCPA-megfelelőség a Delta Lake használatával

Ez a cikk azt ismerteti, hogyan használható a Delta Lake Azure Databricks az Általános adatvédelmi rendelet (GDPR) és a California Consumer Privacy Act (CCPA) megfelelőségének kezelésére az adattóban. Mivel a Delta Lake egy tranzakciós réteget ad hozzá, amely strukturált adatkezelést biztosít a data lake-re épülve, jelentősen leegyszerűsítheti és felgyorsíthatja a személyes adatok (más néven "személyes adatok") megkeresését és eltávolítását a fogyasztói GDPR- vagy CCPA-kérelmekre válaszul.

A feladat

A szervezet több száz terabájtnyi személyes adatot kezelhet a felhőben. Ezeknek az adatkészleteknek a GDPR-be és CCPA-ba való behozása rendkívül fontos, de ez nagy kihívást jelenthet, különösen az adattóban tárolt nagyobb adatkészletek esetén.

A kihívás általában a következő tényezőkből ered:

  • Ha nagy mennyiségű (petabájtos nagyságrendű) adat található a felhőben, a felhasználói adatok több adatkészletben és helyen tárolhatók és oszthatóak el.
  • Az adott felhasználók adatainak keresésére használt pont- vagy alkalmi lekérdezések költségesek (a haystack mutatóihoz hasonló), mert gyakran teljes táblavizsgálatot igényel. A GDPR/CCPA-megfelelőség találgatásos megközelítése több feladat különböző táblákon való működését eredményezheti, ami több hét mérnöki és üzemeltetési munkát eredményez.
  • A data lake-ek eredendően hozzáfűzőek, és nem támogatják a sorszintű "törlési" vagy "frissítési" műveletek natív módon való elvégzését, ami azt jelenti, hogy át kell írnia az adatpartíciókat. A tipikus Data Lake-ajánlatok nem biztosítanak ACID tranzakciós képességeket vagy hatékony módszereket a releváns adatok megkeresése érdekében. Emellett az olvasási/írási konzisztencia is problémát jelent: a felhasználói adatok data lake-ről való kiírása során az adatokat beolvasott folyamatokat meg kell védeni az olyan anyagoktól, amelyek hatással vannak a hagyományos RDBMS-re.
  • Az adattóban az adathigiénia kihívást jelent, mivel a data lake-ek a kialakításuk alapján támogatják a rendelkezésre állást és a partíciótűrést a konzisztenciával. A megtisztított adatokhoz kötelező és szigorú eljárások és szabványok szükségesek.

Ennek eredményeképpen a felhasználói adatokat ilyen méretekben kezelő szervezetek gyakran bonyolult, költséges és időigényes folyamatokat írnak a GDPR és a CCPA kezeléséhez. Előfordulhat például, hogy az adattó egyes részeit saját adatraktározási technológiákba tölti fel, ahol a GDPR- és CCPA-megfelelőséghez kapcsolódó törlési tevékenységeket végez. Ez összetettebbé teszi az adatokat, és csökkenti az adatok hűségét azáltal, hogy az adatok több másolatát kényszeríti ki. Emellett az ilyen adattárház-technológiákból egy data lake-be történő adatáthelyre exportáláshoz újraoptimalizálásra lehet szükség a lekérdezési teljesítmény javítása érdekében. Ez is több adatmásolatot hoz létre és tart fenn.

Hogyan foglalkozik a Delta Lake a kihívással?

A fent felsorolt problémák megoldásához a Data Lake GDPR- és CCPA-kompatibilisségének optimális megközelítéséhez a következő feltételekre van szükség:

  • "Személyes információs elemek( ) olyan kulcsokra történő álnevesítése ," vagy visszaverhető tokenizálása, amelyek pseudonyms külsőleg nem azonosíthatók.
  • Storage az adatokat az azonosítók helyett pszeudonevekkel összekapcsolva;
  • Szigorú hozzáférési és használatú szabályzatok karbantartása az azonosítók és álnevek kombinációjára;
  • Folyamatokra vagy gyűjtőkre vonatkozó szabályzatok a nyers adatok eltávolításához az alkalmazandó jogszabályoknak való megfelelést segítő ütemtervek alapján;
  • Folyamatok strukturálása az azonosító megkeresésében és eltávolításában az álnevek és azonosítók közötti kapcsolat megsemmisítéséhez
  • Az ACID-képességek átfedik a data lake-et, így megakadályozva, hogy az olvasókat hátrányosan befolyásolja a törlési vagy frissítési műveletek a data lake-ben való végrehajtásához.
  • Nagy teljesítményű folyamat, amely támogatja például 5TB adat 10 percen belüli tisztítását.

A Delta Lake rendkívül hatékony eszköz ezeknek a GDPR- és CCPA-megfelelőségi követelményeknek a teljesítéséhez, mivel strukturált adatkezelési rendszere tranzakciós képességekkel egészíti ki a data lake-et. A Delta Lake jól szervezett, jól méretezett, jól indexelt, statisztikákkal kompatibilis adatkészletei lehetővé teszik az adatok gyors és egyszerű keresését, módosítását és tisztítását olyan szabványos SQL DML-utasításokkal, mint a , a és a DELETEUPDATEMERGE INTO .

A következő szakaszokban ismertetett két eset bemutatja, hogyan konvertálhatja meglévő adatait a Delta Lake-re, és hogyan törölheti és törölheti gyorsan és hatékonyan a személyes adatokat. Ez a cikk emellett a személyes adatok álnevesítésére és a Delta Lake lekérdezési teljesítményének javítására vonatkozó lehetőségeket is javasol.

Személyes adatok törlése

Ez a példa bemutatja, milyen hatékony lehet a Delta Lake a személyes adatok data lake-ről való törlésekor.

A mintaadatkészlet

A cikkben ismertetett munkafolyamat egy 65 000 000 sorral és annyi különböző ügyfél-adattal rendelkező mintaadatkészletet tartalmazó adatbázisra hivatkozik, amely gdpr 3,228 GB adatot tartalmaz. Az ügyfél személyes adatait az adatbázis customers táblája rögzíti.

A tábla gdpr.customers sémája a következő:

|-- c_customer_sk: integer (nullable = true)
|-- c_customer_id: string (nullable = true)
|-- c_current_cdemo_sk: integer (nullable = true)
|-- c_current_hdemo_sk: integer (nullable = true)
|-- c_current_addr_sk: integer (nullable = true)
|-- c_first_shipto_date_sk: integer (nullable = true)
|-- c_first_sales_date_sk: integer (nullable = true)
|-- c_salutation: string (nullable = true)
|-- c_first_name: string (nullable = true)
|-- c_last_name: string (nullable = true)
|-- c_preferred_cust_flag: string (nullable = true)
|-- c_birth_day: integer (nullable = true)
|-- c_birth_month: integer (nullable = true)
|-- c_birth_year: integer (nullable = true)
|-- c_birth_country: string (nullable = true)
|-- c_email_address: string (nullable = true)
|-- c_last_review_date: string (nullable = true)

Azon ügyfelek listája, akik GDPR-enként (GDPR) és CCPA-nként (CCPA) kérik őket, egy tranzakciós adatbázistáblából,, amely egy gdpr.customer_delete_keys online portálon van kitöltve. A törölni szükséges kulcsok (eltérő felhasználók) az eredeti adatkészletből vett eredeti kulcsok körülbelül 10%-át (337,615 MB) gdpr.customers képviselik.

A tábla gdpr.customer_delete_keys sémája a következő mezőket tartalmazza:

|-- c_customer_sk: integer (nullable = true)
|-- c_customer_id: string (nullable = true)

A kulcs c_customer_id azonosítja a törölni akaró ügyfeleket.

1. lépés: Táblák konvertálása Delta formátumba

A Delta Lake-hez való első lépésekhez be kell szereznie a nyers adatokat (Parquet, CSV, JSON stb.), és felügyelt Delta-táblákként kell kiírni őket. Ha az adatok már Parquet-formátumúak, a használatával átalakíthatja a már használatban lévő Parquet-fájlokat Delta-táblákká, anélkül, hogy bármilyen adatot CONVERT TO DELTA újraír. Ha nem, a már ismert Apache Spark api-k használatával átírhatja a formátumot a Delta-ra. Mivel a Delta Lake a Parquetet használja, amely egy nyílt fájlformátum, a konvertált adatok nem lesznek zárolva: szükség esetén gyorsan és egyszerűen konvertálhatja vissza az adatokat más formátumra.

Ez a példa konvertálja a Parquet-táblát customers az gdpr adatbázisban.

CONVERT TO DELTA gdpr.customers

2. lépés: Törlések végrehajtása

Miután Delta Lake-táblává konvertálta a táblákat, törölheti az elfelejtett felhasználók személyes adatait.

Megjegyzés

Az alábbi példa az ügyfél személyes adatainak egyszerű törlését foglalja magában a customers táblából. Jobb eljárás a munkatáblákban található összes személyes ügyféladat álnevesítése (mielőtt megkapja az adatalany kérelmét), és törli az ügyfélbejegyzést a "keresési táblázatból", amely az ügyfelet a álnévhez leképezi, ugyanakkor gondoskodik arról, hogy a munkatáblákban lévő adatok ne használhatók az ügyfél identitásának újraépítéséhez. Részletekért lásd: Adatok pszeudoneve.

Megjegyzés

Az alábbi példák a teljesítményszámok alapján szemléltetik bizonyos teljesítménybeállítások hatását. Ezek a számok a fent leírt adathalmazban vannak rögzítve egy 3 munkavégző csomóponttal rendelkező fürtön, amelyek mindegyikének 90 GB memóriája és 12 magja van; az illesztő 30 GB memóriával és 4 maggal.

Itt látható egy egyszerű Delta Lake-művelet, amely törli a táblában szereplő ügyfeleket DELETE FROMcustomer_delete_keys a gdpr.customers mintatáblából:

DELETE FROM `gdpr.customers` AS t1 WHERE EXISTS (SELECT c_customer_id FROM gdpr.customer_delete_keys WHERE t1.c_customer_id = c_customer_id)

A tesztelés során ez a művelet túl sokáig tartott: a fájlok keresése 32 másodpercet vett igénybe, a fájlok átírása pedig 2,6 percet vett igénybe. A megfelelő fájlok kereséséhez szükséges idő csökkentése érdekében növelje a szórási küszöbértéket:

set spark.sql.autoBroadcastJoinThreshold = 104857600;

Ez a szórási tipp arra utasítja a Sparkot, hogy minden megadott táblát szórással közvetítsen, amikor egy másik táblához vagy nézethez csatlakozik. Ez a beállítás a fájlkeresést 8 másodpercre, a írást pedig 1,6 percre dobott el.

A Delta Lake Z-ordering (többdimenziós fürtözés)még jobban felgyorsíthatja a teljesítményt. A Z-Ordering az adatok tartománypartíció-alapú elrendezését hozza létre, és indexeli ezt az információt a Delta-táblában. A Delta Lake ezt a z-indexet használja a művelet által érintett fájlok DELETE kereséséhez.

A Z-Ordering előnyeinek kihasználása érdekében tisztában kell lennie a törölt adatok céltáblában való terjesztésével. Ha például az adatok , akár néhány kulcs esetén is, az adatkészlet fájljainak 90%-a között vannak elterjesztve, akkor az adatok több mint 90%-át fogja újraírni. A Z-Ordering a megfelelő kulcsoszlopok alapján csökkenti az érintett fájlok számát, és sokkal hatékonyabbá teszi az újraírásokat.

Ebben az esetben a delete futtatása előtt a Z-Order oszlop szerint c_customer_id kell eltennünk:

OPTIMIZE gdpr.customers Z-ORDER BY c_customer_id

A Z-rendelés után a fájlok keresése 7 másodpercet vett igénybe, az írás pedig 50 másodpercre csökkent.

3. lépés: Elavult adatok tisztítása

Attól függően, hogy egy fogyasztói kérés után mennyi ideig törli az adatokat és a mögöttes Data Lake-ben, előfordulhat, hogy törölnie kell a táblaelőzményeket és a mögöttes nyers adatokat.

Alapértelmezés szerint a Delta Lake 30 napig őrzi meg a táblaelőzményeket, és elérhetővé teszi az "idő utazásához" és a visszaállításhoz. Ez azt jelenti, hogy a szervezet felhasználói akkor is megtekinthetik az előzményadatokat, ha törölte a személyes adatokat egy Delta-táblából, és vissza tudják azt mondani a tábla egy olyan verziójára, amelyben a személyes adatok továbbra is tárolva vannak. Ha úgy dönt, hogy a GDPR- vagy CCPA-megfelelőség megköveteli, hogy ezek az elavult rekordok az alapértelmezett megőrzési időszak előtt ne legyen lekérdezhetőek, a VACUUM függvény használatával eltávolíthatja a Delta-tábla által már nem hivatkozott és a megadott megőrzési küszöbértéknél régebbi fájlokat. Miután eltávolította a táblaelőzményeket a VACUUM paranccsal, az összes felhasználó elveszíti az előzmények megtekintésének és a visszaállításnak a képességét.

Ha törölni szeretné az összes olyan ügyfelet, aki az adatai törlését kérte, majd a 7 napnál régebbi összes táblaelőzményt el szeretné távolítani, egyszerűen futtassa a következőt:

VACUUM gdpr.customers

A 7 napnál fiatalabb összetevők eltávolításához használja a RETAIN num HOURS következő lehetőséget:

VACUUM gdpr.customers RETAIN 100 HOURS

Továbbá, ha a Spark API-k használatával Delta-táblákat hozott létre a nem Parquet-fájlok Delta-fájllá való átírásához (nem pedig a Parquet-fájlok helyszíni Delta Lake-té való átalakításához), a nyers adatok továbbra is tartalmazhatnak személyes adatokat, amelyekről törölt vagy anonimizált. A Databricks azt javasolja, hogy a nyers adatok automatikus eltávolításához állítson be legalább 30 napos adatmegőrzési szabályzatot a felhőszolgáltatónál.

Adatok álneve

Bár a fent leírt törlési módszer szigorúan lehetővé teszi, hogy a szervezet eleget tegyen a GDPR-nek és a CCPA-nak a személyes adatok törlésére vonatkozó követelménynek, ennek számos hátránya is van. Az első az, hogy a GDPR nem engedélyezi a személyes adatok további feldolgozását, miután érvényes törlési kérelem érkezett. Ennek következtében, ha az adatokat nem álnevesített módon tárolják – azaz a személyes azonosításra alkalmas adatok mesterséges azonosítóval vagy álnévvel való cseréjével – az adat tulajdonosi kérelem beérkezését megelőzően az összes csatolt információt törölnie kell. Ha azonban korábban álnevesítette a mögöttes adatokat, a törlési kötelezettségének az azonosítót az azonosítót az álnévhez (feltéve, hogy maga az adat nem azonosítható) egyszerű megsemmisítése teljesíti, és megőrizheti az adatok fennmaradó részét.

Egy tipikus álnevesítési forgatókönyvben egy biztonságos "keresési táblázatot" tart meg, amely leképezi az ügyfél személyes azonosítóit (nevét, e-mail-címét stb.) a pszeudonévre. Ez nem csupán a törlés egyszerűségét teszi lehetővé, hanem azzal is, hogy lehetővé teszi a felhasználói identitás ideiglenes visszaállítását a felhasználói adatok időről időre való frissítéséhez. Ez egy anonimizálási forgatókönyvben megtagadott előny, amelyben definíció szerint az ügyfél identitása soha nem állítható vissza, és minden ügyféladat statikus és előzményadatokból áll.

Egy egyszerű álnevesítési példaként tekintsük meg a törlési példában frissített ügyféltáblát. Az álnevesítési forgatókönyvben létrehozhat egy táblát, amely tartalmazza az ügyfél azonosításához használható összes ügyféladatot, valamint egy további oszlopot egy gdpr.customers_lookup álnevesített e-mail-címhez. Most már használhatja a pszeudo e-mail-címet kulcsként az ügyfelekre hivatkozó adattáblákban, és ha arra kérik, hogy felejtse el ezt az információt, egyszerűen törölheti ezeket az információkat a táblából, és a többi információ örökre nem azonosítható gdpr.customers_lookup maradhat.

A tábla gdpr.customers_lookup sémája a következő:

|-- c_customer_id: string (nullable = true)
|-- c_email_address: string (nullable = true)
|-- c_email_address_pseudonym: string (nullable = true)
|-- c_first_name: string (nullable = true)
|-- c_last_name: string (nullable = true)

Customer lookup table

Ebben a forgatókönyvben a fennmaradó, az ügyfél azonosítására nem használható ügyféladatokat helyezze egy nevű álnevesített gdpr.customers_pseudo táblába:

|-- c_email_address_pseudonym: string (nullable = true)
|-- c_customer_sk: integer (nullable = true)
|-- c_current_cdemo_sk: integer (nullable = true)
|-- c_current_hdemo_sk: integer (nullable = true)
|-- c_current_addr_sk: integer (nullable = true)
|-- c_first_shipto_date_sk: integer (nullable = true)
|-- c_first_sales_date_sk: integer (nullable = true)
|-- c_salutation: string (nullable = true)
|-- c_preferred_cust_flag: string (nullable = true)
|-- c_birth_year: integer (nullable = true)
|-- c_birth_country: string (nullable = true)
|-- c_last_review_date: string (nullable = true)

Customer pseudonymized table

Ügyféladatok álnevesítés a Delta Lake használatával

A személyes adatok álnevesítésének egyik erős módja az egyutas titkosítási kivonatolás és a meg nem ett sóval vagy sóval való sózás. A kivonatolás rögzített hosszúságú ujjlenyomatot vált fel, amely nem fordítható vissza a számításon. A Salting véletlenszerű sztringet ad hozzá az adatokhoz, amelyek kivonatolásával frusztrálhatja a keresési vagy "figyelő" táblákat használó támadókat, amelyek több millió ismert e-mail-cím vagy jelszó kivonatát tartalmazzák.

Az oszlopot úgy használhatja, hogy hozzáad egy véletlenszerű titkos c_email_address sztringkonstanst a kivonatolás előtt. Ezt a titkos sztringet titkos Azure Databricks tárolhatja, hogy további biztonságot adjon a salt értékhez. Ha a Azure Databricks illetéktelen felhasználók megpróbálnak hozzáférni a titkos adatokhoz, a felhasználók a már nem engedélyezett értékeket fogják látni.

dbutils.secrets.get(scope = "salt", key = "useremail")
res0: String = [REDACTED]

Megjegyzés

Ez egy egyszerű példa a saltolás szemléltetésére. Ha ugyanazt a sót használja az összes ügyfélkulcshoz, az nem jó módszer a támadások enyhítésére; Csak hosszabbra teszi az ügyfélkulcsokat. Biztonságosabb módszer, ha minden felhasználóhoz véletlenszerű sót hozunk létre. Lásd: Erősebbé tenni a álnevesítést.

A oszlopot a besziratása után kivonatot kaphat, és a kivonatot a következő ként használhatja a c_email_addressgdpr.customers_lookupc_email_address_pseudonym táblához:

UPDATE gdpr.customers_lookup SET c_email_address_pseudonym = sha2(c_email_address,256)

Most már használhatja ezt az értéket az összes ügyfél által kulcsolt táblához.

Az álnevesítés erősebbé tenni

Annak érdekében, hogy csökkentse annak a kockázatát, hogy egy adott só sérülése akár egyetlen sót is veszélyeztethet az adatbázisban, célszerű a különböző sót (ügyfelenként vagy akár felhasználónként egyet) használni. Feltéve, hogy az álneves azonosítóhoz csatolt adatok nem tartalmaznak személy azonosítására képes információt, ha törli azt a rekordot, amelyből a felhasználóhoz kapcsolódik, és nem tudja újra létrehozni, a fennmaradó adatokat teljesen névtelenül kell renderelni, így kívül esnek a GDPR és a CCPA hatókörében. Számos szervezet dönt úgy, hogy felhasználónként több sót hoz létre, és teljes mértékben anonimizált adatokat hoz létre az adatvédelmi törvény hatókörének kívül, ha ezeket a sót rendszeres időközönként, az üzleti szükségnek megfelelően rotálta.

Ne feledje, hogy az adatok "személyesek" vagy "azonosíthatók" nem elemszintű, hanem tömbszintű elemzések. Így bár az olyan nyilvánvaló dolgok, mint az e-mail-címek egyértelműen személyesek, olyan dolgok kombinációi, amelyek önmagukban nem személyesek, személyesek is lehetnek. Lásd például a következőt: az USA 1990-es népének elemzése alapján az Egyesült Államok népesség 87%-a egyedileg azonosítható az irányítószám három attribútuma, a születési dátum és a nem https://aboutmyinfo.org/identity/about alapján. Tehát amikor arról dönt, hogy mit tároljon a személyes azonosítók táblázatának vagy a csak álneves információkat tároló munkatábláknak, gondolja át, hogy a látszólag nem azonosítható információk ütközése maga is azonosítható-e. Győződjön meg arról, hogy a saját adatvédelmi megfelelősége olyan belső folyamatokkal is összhangban van, amelyek megakadályozzák a nem azonosítható információkkal (például különbségi adatvédelem, adatvédelmi megőrző hisztogramok stb.) való újraazonosítási kísérleteket. Bár előfordulhat, hogy soha nem lehet teljesen megakadályozni az újraazonosítást, ezeknek a lépéseknek a lépései nagyban hozzájárulnak a segítséghez.

Jobb lekérdezési teljesítmény

2. lépés: A Törlés végrehajtása azt mutatta be, hogyan javítható a Delta Lake lekérdezési teljesítménye a szórási küszöbérték és a Z-ordering növelésével, valamint további teljesítményjavítási eljárásokkal is érdemes tisztában lennie:

  • Győződjön meg arról, hogy a kulcsoszlopok egy tábla első 32 oszlopában vannak. A Delta Lake az első 32 oszlop statisztikáit gyűjti, és ezek a statisztikák segítenek azonosítani a fájlokat törlés vagy frissítés céljából.
  • A Delta Lake on Azure Databricks-ban elérhető automatikus optimalizálás funkcióval automatikusan kis méretű fájlokat tömöríthet a Delta-táblákba történő egyes írások során, és jelentős előnyöket biztosít az aktívan lekérdezett táblák számára, különösen olyan esetekben, amikor a Delta Lake egyébként több kisméretű fájlt is használna. Ha útmutatásra van szüksége a használatukról, tekintse meg az Automatikus optimalizálás útmutatót.
  • Csökkentse a forrástábla méretét (a BroadcastHashJoin fájlhoz). Ez segít a Delta Lake-nek a dinamikus fájlcsonkolásban, amikor meghatározza a törléshez szükséges adatokat. Ez különösen akkor segít, ha a törlési műveletek nincsenek partícióhatáron.
  • Minden módosítási művelethez(például ) a lehető legspecifikusabbnak kell lennie, megtéve a keresési záradékban szereplő összes DELETE feltételt. Ez leszűkíti a találatok számát, és megakadályozza a tranzakciós ütközéseket.
  • Folyamatosan finomhangolhatja a Spark-elosztást, a fürtkihasználtságot és a tárolórendszer optimális írását.

Tudjon meg többet

A Delta Lake on Azure Databricks a Delta Lake és a Delta Engine útmutatóban olvashat bővebben.

A Delta Lake Databricks-szakértők által írt GDPR-hez és CCPA-megfelelőséghez való használatával kapcsolatos blogokért lásd:

További információ a személyes adatok kiürítésről a Azure Databricks munkaterületen: Munkaterület-tároló kezelése.