Szia Habr! Az új kurzusfolyamra való jelentkezés jelenleg nyitva van az OTUS-nál . A tanfolyam kezdetére számítva hagyományosan érdekes anyagok fordítását készítettük el számotokra.
Naponta több mint százmillióan keresik fel a Twittert, hogy megtudják, mi történik a világban, és megvitassák azt. Minden tweet és minden más felhasználói művelet egy eseményt generál, amely elérhető a Twitter belső adatelemzéséhez. Alkalmazottak százai elemzik és vizualizálják ezeket az adatokat, és tapasztalataik javítása a Twitter Data Platform csapatának kiemelt prioritása.
Meggyőződésünk, hogy a széles körű műszaki ismeretekkel rendelkező felhasználóknak képesnek kell lenniük az adatok felfedezésére, és hozzá kell férniük a jól teljesítő SQL-alapú elemző és vizualizációs eszközökhöz. Ez lehetővé tenné a kevésbé technikai felhasználók teljesen új csoportja számára, beleértve az adatelemzőket és a termékmenedzsereket, hogy betekintést nyerhessenek az adatokból, lehetővé téve számukra a Twitter képességeinek jobb megértését és használatát. Így demokratizáljuk az adatelemzést a Twitteren.
Ahogy eszközeink és belső adatelemzési képességeink javultak, a Twitter is javult. Van azonban még mit javítani. A jelenlegi eszközök, például a Scalding programozási tapasztalatot igényelnek. Az SQL-alapú elemzőeszközök, például a Presto és a Vertica teljesítményproblémákkal küzdenek. Az is problémánk, hogy az adatokat több rendszer között osztjuk el anélkül, hogy állandóan hozzáférnénk.
Tavaly bejelentettük , amelyen belül átadjuk a mi a Google Cloud Platformon (GCP). Arra a következtetésre jutottunk, hogy a Google Cloud eszközök segíthet nekünk az analitika, a vizualizáció és a gépi tanulás demokratizálására irányuló kezdeményezéseinkben a Twitteren:
- : vállalati adattárház SQL motor alapú , amely gyorsaságáról, egyszerűségéről híres és megbirkózik vele .
- Big Data vizualizációs eszköz a Google Dokumentumok-szerű együttműködési funkciókkal.
Ebben a cikkben megismerheti ezekkel az eszközökkel kapcsolatos tapasztalatainkat: mit tettünk, mit tanultunk, és mit fogunk tenni ezután. Most a kötegelt és interaktív elemzésekre fogunk összpontosítani. A következő cikkben a valós idejű elemzésről fogunk beszélni.
A Twitter adattárak története
Mielőtt belevágnánk a BigQuery-be, érdemes röviden felidézni a Twitter adattárház történetét. 2011-ben Twitter-adatelemzést végeztek a Vertica és a Hadoop programban. A Pig segítségével MapReduce Hadoop-feladatokat hoztunk létre. 2012-ben lecseréltük a Pig-et a Scalding-re, amely Scala API-val rendelkezett, olyan előnyökkel, mint az összetett folyamatok létrehozásának képessége és az egyszerű tesztelés. Azonban sok adatelemző és termékmenedzser számára, akik kényelmesebben dolgoztak az SQL-lel, ez meglehetősen meredek tanulási görbe volt. 2016 körül kezdtük használni a Presto-t SQL interfészként a Hadoop adatokhoz. A Spark Python felületet kínált, ami jó választássá teszi az ad hoc adattudományhoz és a gépi tanuláshoz.
2018 óta az alábbi eszközöket használjuk adatelemzéshez és megjelenítéshez:
- Forrázás gyártási szállítószalagokhoz
- Scalding és Spark ad hoc adatelemzéshez és gépi tanuláshoz
- Vertica és Presto ad hoc és interaktív SQL elemzéshez
- Druida az idősor-metrikák alacsony interaktív, felfedező és alacsony késleltetésű hozzáféréséhez
- Tableau, Zeppelin és Pivot az adatok megjelenítéséhez
Azt tapasztaltuk, hogy bár ezek az eszközök nagyon hatékony képességeket kínálnak, nehézségekbe ütközött, hogy ezeket a lehetőségeket szélesebb közönség számára elérhetővé tegyük a Twitteren. Platformunk Google Clouddal történő bővítésével arra összpontosítunk, hogy leegyszerűsítsük elemzőeszközeinket az egész Twitter számára.
A Google BigQuery Data Warehouse
A Twitter több csapata már beépítette a BigQuery-t egyes gyártási folyamataiba. Szakértelmüket felhasználva elkezdtük értékelni a BigQuery képességeit minden Twitter-használati esetben. Célunk az volt, hogy a BigQuery szolgáltatást az egész vállalat számára kínáljuk, szabványosítsuk és támogassuk az adatplatform eszközkészletén belül. Ez több okból is nehéz volt. Ki kellett fejlesztenünk egy infrastruktúrát a nagy mennyiségű adat megbízható feldolgozásához, a vállalati szintű adatkezelés támogatásához, a megfelelő hozzáférés-szabályozás biztosításához és az ügyfelek adatvédelmének biztosításához. Ezenkívül rendszereket kellett létrehoznunk az erőforrások elosztására, figyelésére és visszaterhelésére, hogy a csapatok hatékonyan tudják használni a BigQuery-t.
2018 novemberében kiadtuk a BigQuery és a Data Studio vállalati szintű alfa kiadását. A Twitter-alkalmazottaknak felajánlottuk a leggyakrabban használt táblázatainkat törölt személyes adatokkal. A BigQuery-t több mint 250 felhasználó használta különféle csapatokból, beleértve a mérnöki, pénzügyi és marketinges csapatokat. Legutóbb körülbelül 8 ezer kérést futtattak, körülbelül 100 PB-t feldolgozva havonta, nem számítva az ütemezett kéréseket. Miután nagyon pozitív visszajelzéseket kaptunk, úgy döntöttünk, hogy továbblépünk, és a BigQuery-t kínáljuk elsődleges forrásként a Twitteren lévő adatokkal való interakcióhoz.
Íme egy magas szintű diagram a Google BigQuery adattárház architektúrájáról.
A belső Cloud Replicator eszköz segítségével másoljuk az adatokat a helyszíni Hadoop-fürtökről a Google Cloud Storage (GCS) szolgáltatásba. Ezután az Apache Airflow segítségével olyan csővezetékeket hozunk létre, amelyek» adatok betöltéséhez a GCS-ből a BigQuery-be. A Presto-t használjuk a GCS-ben található Parquet vagy Thrift-LZO adatkészletek lekérdezésére. A BQ Blaster egy belső leégető eszköz a HDFS Vertica és a Thrift-LZO adatkészletek BigQuery-be való betöltésére.
A következő szakaszokban megvitatjuk megközelítésünket és szakértelmünket a könnyű használat, a teljesítmény, az adatkezelés, a rendszer állapota és a költségek terén.
Egyszerű használat
Azt találtuk, hogy a felhasználók könnyen elkezdhették a BigQuery használatát, mivel nem volt szükség szoftver telepítésére, és a felhasználók egy intuitív webes felületen keresztül érhetik el. A felhasználóknak azonban meg kellett ismerniük a GCP néhány funkcióját és koncepcióját, beleértve az olyan erőforrásokat, mint a projektek, adatkészletek és táblázatok. Oktatási anyagokat és oktatóanyagokat fejlesztettünk ki, hogy segítsünk a felhasználóknak az indulásban. A megszerzett alapismeretek birtokában a felhasználók könnyen navigálhatnak az adatkészletekben, megtekinthetik a séma- és táblázatadatokat, egyszerű lekérdezéseket futtathatnak, és megjeleníthetik az eredményeket a Data Studio alkalmazásban.
A BigQuery-be történő adatbevitellel az volt a célunk, hogy lehetővé tegyük a HDFS- vagy GCS-adatkészletek zökkenőmentes, egyetlen kattintással történő betöltését. mérlegeltük (az Airflow által kezelt), de nem tudtuk használni a Domain Restricted Sharing biztonsági modellünk miatt (erről bővebben az alábbi Adatkezelés szakaszban olvashat). Kísérleteztünk a Google Data Transfer Service (DTS) használatával a BigQuery-munkaterhelések összehangolására. Míg a DTS-t gyorsan felállították, nem volt rugalmas a függőségekkel rendelkező csővezetékek építéséhez. Alfa-kiadásunkhoz saját Apache Airflow keretrendszert építettünk fel a GCE-ben, és készülünk arra, hogy élesben futhasson, és több adatforrás, például a Vertica támogatására is képes legyen.
Az adatok BigQuery-vé alakításához a felhasználók egyszerű SQL-adatfolyamokat hoznak létre ütemezett lekérdezések segítségével. A függőségekkel rendelkező összetett, többlépcsős csővezetékek esetében a saját Airflow keretrendszerünk vagy a Cloud Composer alkalmazását tervezzük. .
termelékenység
A BigQuery-t általános célú SQL-lekérdezésekhez tervezték, amelyek nagy mennyiségű adatot dolgoznak fel. Nem a tranzakciós adatbázisok által megkövetelt alacsony késleltetésű, nagy áteresztőképességű lekérdezésekre vagy az alacsony késleltetésű idősorelemzésre való. . Az interaktív analitikai lekérdezések esetén felhasználóink egy percnél rövidebb válaszidőre számítanak. Úgy kellett megterveznünk a BigQuery használatát, hogy megfeleljünk ezeknek az elvárásoknak. Annak érdekében, hogy felhasználóink számára kiszámítható teljesítményt nyújthassunk, kihasználtuk a BigQuery funkcionalitását, amely átalánydíj ellenében áll az ügyfelek rendelkezésére, és lehetővé teszi a projekttulajdonosok számára, hogy lekérdezéseikhez minimális helyet foglalhassanak. A BigQuery az SQL-lekérdezések végrehajtásához szükséges számítási teljesítmény egysége.
Több mint 800 lekérdezést elemeztünk, amelyek mindegyike körülbelül 1 TB adatot dolgozott fel, és azt találtuk, hogy az átlagos végrehajtási idő 30 másodperc volt. Azt is megtanultuk, hogy a teljesítmény nagymértékben függ attól, hogy a slotunkat különböző projektekben és feladatokban használjuk. Világosan meg kellett határoznunk a termelési és ad hoc réstartalékainkat, hogy fenntartsuk a teljesítményt az éles felhasználási esetekre és az online elemzésekre. Ez nagymértékben befolyásolta a helyek lefoglalására és a projekthierarchiára vonatkozó tervezésünket.
Az adatkezelésről, a funkcionalitásról és a rendszerek költségéről a következő napokban a fordítás második részében lesz szó, most azonban mindenkit meghívunk , melynek során részletesen tájékozódhat a tanfolyamról, valamint kérdéseket tehet fel szakértőnknek - Egor Mateshuknak (Senior Data Engineer, MaximaTelecom).
Olvass tovább:
Forrás: will.com