Talaan ng nilalaman[Tago][Ipakita]
Maaaring medyo mahirap isaalang-alang ang lahat ng magagamit na serbisyo at opsyon sa arkitektura kapag nag-iisip tungkol sa mga platform ng data.
Ang isang platform ng data ng enterprise ay kadalasang binubuo ng mga warehouse ng data, mga modelo ng data, lawa ng data, at mga ulat, bawat isa ay may partikular na layunin at hanay ng mga kasanayang kinakailangan. Sa kabaligtaran, isang bagong disenyo na tinatawag na data lakehouse ang lumitaw sa nakalipas na ilang taon.
Ang versatility ng data lakes at data warehouse data management ay pinagsama sa isang rebolusyonaryong arkitektura ng storage ng data na tinatawag na "data lakehouse."
Susuriin namin ang data lakehouse nang malalim sa post na ito, kasama ang mga bahagi, feature, arkitektura, at iba pang aspeto nito.
Ano ang Data Lakehouse?
Gaya ng ipinahihiwatig ng pangalan, ang data lakehouse ay isang bagong uri ng arkitektura ng data na pinagsasama ang isang data lake sa isang data warehouse upang lutasin ang mga pagkukulang ng bawat isa nang hiwalay.
Sa esensya, ang sistema ng lakehouse ay gumagamit ng murang imbakan upang mapanatili ang napakalaking dami ng data sa kanilang mga orihinal na anyo, katulad ng mga lawa ng data. Ang pagdaragdag ng metadata layer sa itaas ng store ay nagbibigay din ng istruktura ng data at nagbibigay-kapangyarihan sa mga tool sa pamamahala ng data tulad ng mga makikita sa mga data warehouse.
Nag-iimbak ito ng napakalaking volume ng organisado, semi-structured, at unstructured na data na nakukuha nila mula sa iba't ibang application ng negosyo, system, at gadget na ginagamit sa kabuuan ng kanilang organisasyon.
Kadalasan, ang mga data lakes ay gumagamit ng murang imprastraktura ng storage na may file application programming interface (API) upang mag-imbak ng data sa bukas, generic na mga format ng file.
Ginagawa nitong posible para sa maraming koponan na ma-access ang lahat ng data ng kumpanya sa pamamagitan ng isang sistema para sa iba't ibang mga hakbangin, tulad ng data science, machine learning, at katalinuhan sa negosyo.
Mga tampok
- Imbakan na mura. Ang isang data lakehouse ay dapat na makapag-imbak ng data sa murang imbakan ng bagay, gaya ng Google Cloud Storage, Azure Blob Storage, Amazon Simple Storage Service, o katutubong gamit ang ORC o Parquet.
- Kakayahan para sa pag-optimize ng data: Ang pag-optimize ng layout ng data, pag-cache, at pag-index ay ilang mga halimbawa kung paano dapat ma-optimize ng data lakehouse ang data habang pinapanatili ang orihinal na format ng data.
- Isang layer ng transactional metadata: Sa itaas ng mahalagang murang storage, binibigyang-daan nito ang mga kakayahan sa pamamahala ng data na mahalaga para sa pagganap ng data warehouse.
- Suporta para sa Declarative DataFrame API: Ang karamihan sa mga tool ng AI ay maaaring gumamit ng DataFrames upang kunin ang data ng raw object store. Pinapataas ng suporta para sa Declarative DataFrame API ang kakayahang dynamic na pahusayin ang presentasyon at istraktura ng data bilang tugon sa partikular na data science o AI na gawain.
- Suporta para sa mga transaksyon sa ACID: Ang acronym na ACID, na kumakatawan sa atomicity, consistency, isolation, at durability, ay isang kritikal na bahagi sa pagtukoy ng isang transaksyon at pagtiyak ng consistency at dependability ng data. Ang ganitong mga transaksyon ay dati lamang posible sa mga data warehouse, ngunit ang Nag-aalok ang lakehouse ng opsyon na gamitin ang mga ito sa mga lawa ng data din. Sa ilang mga pipeline ng data kasama ang kasabay na pagbabasa at pagsusulat ng data, nalulutas nito ang problema ng mababang kalidad ng data ng huli.
Mga Elemento ng Data Lakehouse
Ang arkitektura ng data lakehouse ay nahahati sa dalawang pangunahing tier sa isang mataas na antas. Ang paggamit ng data ng layer ng imbakan ay kinokontrol ng platform ng Lakehouse (ibig sabihin, ang lawa ng data).
Nang hindi kinakailangang i-load ang data sa isang data warehouse o i-convert ito sa isang pagmamay-ari na format, magagawa ng processing layer na direktang i-query ang data sa storage layer gamit ang isang hanay ng mga tool.
Pagkatapos, magagamit ng mga BI app, pati na rin ang mga teknolohiya ng AI at ML, ang data. Ang economics ng isang data lake ay ibinibigay ng disenyong ito, ngunit dahil ang anumang makina sa pagpoproseso ay maaaring basahin ang data na ito, ang mga negosyo ay may kalayaan na gawing naa-access ang inihandang data para sa pagsusuri ng isang hanay ng mga system. Ang pagganap at gastos ng processor ay parehong mapapabuti sa pamamagitan ng paggamit ng paraang ito para sa pagproseso at pagsusuri.
Dahil sa suporta nito para sa mga transaksyon sa database na sumusunod sa sumusunod na pamantayan ng ACID (atomicity, consistency, isolation, at durability), binibigyang-daan din ng arkitektura ang maraming partido na ma-access at magsulat ng data nang sabay-sabay sa loob ng system:
- Atomisidad tumutukoy sa katotohanan na ang buong transaksyon o wala nito, ay nagtagumpay habang kinukumpleto ang isang transaksyon. Kung sakaling maantala ang isang proseso, nakakatulong ito na maiwasan ang pagkawala ng data o katiwalian.
- Hindi pagbabago ginagarantiyahan ang mga transaksyon na nangyayari sa isang predictable, pare-parehong paraan. Pinapanatili nito ang integridad ng data sa pamamagitan ng pagtiyak na ang bawat data ay lehitimo alinsunod sa mga paunang natukoy na panuntunan.
- Paghihiwalay tinitiyak na, hanggang sa matapos ito, walang transaksyon ang maaaring maapektuhan ng anumang iba pang transaksyon sa loob ng system. Nagbibigay-daan ito sa maraming partido na magbasa at magsulat mula sa parehong sistema nang sabay-sabay nang hindi nakikialam sa isa't isa.
- Tibay ginagarantiyahan na ang mga pagbabago sa data sa isang system ay patuloy na umiiral pagkatapos ng isang transaksyon, kahit na sa kaganapan ng isang pagkabigo ng system. Ang anumang mga pagbabagong dulot ng isang transaksyon ay pinananatili sa file magpakailanman.
Arkitektura ng Data Lakehouse
Ang Databricks (ang innovator at taga-disenyo ng kanilang konsepto ng Delta Lake) at ang AWS ay ang dalawang pangunahing tagapagtaguyod para sa konsepto ng isang data lakehouse. Sa gayon ay aasa tayo sa kanilang kaalaman at pananaw upang ilarawan ang layout ng arkitektura ng mga lakehouse.
Ang isang data lakehouse system ay karaniwang may limang layer:
- Layer ng paglunok
- Layer ng imbakan
- Layer ng metadata
- API layer
- Layer ng pagkonsumo
Layer ng paglunok
Ang unang layer ng system ay namamahala sa pagkolekta ng data mula sa iba't ibang mga mapagkukunan at pagpapadala nito sa layer ng imbakan. Ang layer ay maaaring gumamit ng ilang mga protocol upang kumonekta sa maraming panloob at panlabas na mga mapagkukunan, kabilang ang pagsasama-sama ng batch at streaming na mga kakayahan sa pagproseso ng data, tulad ng
- Mga database ng NoSQL,
- mga pagbabahagi ng file
- Mga aplikasyon ng CRM,
- mga website,
- Mga sensor ng IoT,
- Social Media,
- Software bilang isang Serbisyo (SaaS) na mga application, at
- relational database management system, atbp.
Sa puntong ito, ang mga bahagi tulad ng Apache Kafka para sa data streaming at Amazon Data Migration Service (Amazon DMS) para sa pag-import ng data mula sa mga RDBMS at NoSQL database ay maaaring gamitin.
Layer ng imbakan
Ang arkitektura ng lakehouse ay sinadya upang paganahin ang pag-imbak ng iba't ibang uri ng data bilang mga bagay sa murang mga tindahan ng bagay, tulad ng AWS S3. Gamit ang mga bukas na format ng file, maaaring basahin ng mga tool ng kliyente ang mga item na ito nang direkta mula sa tindahan.
Ginagawa nitong posible para sa maraming API at mga bahagi ng layer ng pagkonsumo na ma-access at magamit ang parehong data. Ang metadata layer ay nag-iimbak ng mga schema para sa structured at semi-structured na mga dataset para mailapat ng mga bahagi ang mga ito sa data habang binabasa nila ito.
Ang Hadoop Distributed File System (HDFS) platform, halimbawa, ay maaaring gamitin upang bumuo ng cloud repository services na naghahati sa computing at storage on-premises. Tamang-tama ang Lakehouse para sa mga serbisyong ito.
Layer ng metadata
Ang metadata layer ay ang pangunahing bahagi ng isang data lakehouse na nagpapakilala sa disenyong ito. Isa itong katalogo na nag-aalok ng metadata (impormasyon tungkol sa iba pang piraso ng data) para sa lahat ng item na nakaimbak sa lawa at nagbibigay-daan sa mga user na gumamit ng mga kakayahan sa pangangasiwa tulad ng:
- Ang isang pare-parehong bersyon ng database ay nakikita ng kasabay na mga transaksyon salamat sa mga transaksyon ng ACID;
- pag-cache upang i-save ang mga file ng cloud object store;
- pagdaragdag ng mga index ng istruktura ng data gamit ang pag-index upang mapabilis ang pagproseso ng query;
- gamit ang zero-copy cloning para duplicate ang mga object ng data; at
- para mag-imbak ng ilang partikular na bersyon ng data, atbp., gumamit ng data versioning.
Bukod pa rito, binibigyang-daan ng layer ng metadata ang pagpapatupad ng pamamahala ng schema, ang paggamit ng mga topologie ng DW schema tulad ng mga schema ng star/snowflake, at ang pagbibigay ng pamamahala ng data at kakayahan sa pag-audit nang direkta sa data lake, na nagpapahusay sa integridad ng buong pipeline ng data.
Kasama sa pamamahala ng schema ang mga feature para sa ebolusyon at pagpapatupad ng schema. Sa pamamagitan ng pagtanggi sa anumang pagsusulat na hindi nakakatugon sa schema ng talahanayan, binibigyang-daan ng pagpapatupad ng schema ang mga user na mapanatili ang integridad at kalidad ng data.
Binibigyang-daan ng ebolusyon ng schema ang kasalukuyang schema ng talahanayan na mabago upang ma-accommodate ang pagbabago ng data. Dahil sa iisang interface ng administrasyon sa ibabaw ng data lake, mayroon ding access control at mga posibilidad sa pag-audit.
API layer
Ang isa pang mahalagang layer ng arkitektura ay naroroon na ngayon, na nagho-host ng ilang mga API na magagamit ng lahat ng end user upang magsagawa ng mga trabaho nang mas mabilis at makakuha ng mas sopistikadong istatistika.
Ang paggamit ng mga metadata API ay nagpapadali sa pagtukoy at pag-access sa mga item ng data na kailangan para sa isang partikular na application.
Sa mga tuntunin ng mga library ng machine learning, ang ilan sa mga ito, gaya ng TensorFlow at Spark MLlib, ay makakabasa ng mga bukas na format ng file tulad ng Parquet at direktang ma-access ang metadata layer.
Kasabay nito, ang mga DataFrame API ay nag-aalok ng mas malaking pagkakataon para sa pag-optimize, na nagbibigay-daan sa mga programmer na ayusin at baguhin ang dispersed data.
Layer ng pagkonsumo
Ang Power BI, Tableau, at iba pang mga tool at app ay naka-host sa ilalim ng layer ng pagkonsumo. Gamit ang disenyo ng lakehouse, ang lahat ng metadata at lahat ng data na pinananatili sa isang lawa ay naa-access ng mga app ng kliyente.
Ang lakehouse ay maaaring gamitin ng lahat ng mga gumagamit sa loob ng isang kumpanya upang maisagawa ang lahat ng uri ng mga operasyon ng analytics, kabilang ang paggawa ng mga dashboard ng business intelligence at pagpapatakbo ng mga query sa SQL at mga gawain sa machine learning.
Mga Bentahe ng Data Lakehouse
Ang mga organisasyon ay maaaring lumikha ng isang data lakehouse upang pag-isahin ang kanilang kasalukuyang platform ng data at i-optimize ang kanilang buong proseso ng pamamahala ng data. Sa pamamagitan ng pagtanggal sa mga hadlang ng silo na nagkokonekta sa iba't ibang mapagkukunan, maaaring palitan ng data lakehouse ang pangangailangan para sa mga natatanging solusyon.
Kung ikukumpara sa mga na-curate na pinagmumulan ng data, ang pagsasamang ito ay gumagawa ng isang makabuluhang mas epektibong end-to-end na pamamaraan. Ito ay may ilang mga pakinabang:
- Mas kaunting administrasyon: Sa halip na mag-extract ng data mula sa raw data at ihanda ito para sa paggamit sa loob ng isang data warehouse, pinapayagan ng isang data lakehouse ang anumang mga source na naka-link dito na magkaroon ng kanilang data na available at maayos para magamit.
- Tumaas na cost-effectiveness: Ang mga lakehouse ng data ay itinayo gamit ang kontemporaryong imprastraktura na naghahati sa pagtutuos at pag-iimbak, na ginagawang simple ang pagpapalawak ng imbakan nang hindi pinapataas ang kapangyarihan ng pag-compute. Ang paggamit lamang ng murang data storage ay nagreresulta sa scalability na cost-effective.
- Mas mahusay na pamamahala ng data: Ang mga data lakehouse ay itinayo gamit ang standardized open architecture, na nagbibigay-daan para sa higit na kontrol sa seguridad, mga sukatan, pag-access na nakabatay sa tungkulin, at iba pang mahahalagang bahagi ng pamamahala. Sa pamamagitan ng pagsasama-sama ng mga mapagkukunan at mga mapagkukunan ng data, pinapasimple at pinapahusay ng mga ito ang pamamahala.
- Mga pinasimpleng pamantayan: Dahil ang koneksyon ay lubos na pinaghihigpitan noong 1980s, noong unang binuo ang mga data warehouse, ang mga lokal na pamantayan ng schema ay madalas na binuo sa loob ng mga negosyo, kahit na mga departamento. Ginagamit ng mga lakehouse ng data ang katotohanan na maraming uri ng data ang mayroon na ngayong bukas na mga pamantayan para sa schema sa pamamagitan ng pag-ingest ng maraming data source na may magkakapatong na unipormeng schema upang i-streamline ang mga pamamaraan.
Mga Kakulangan ng Data Lakehouse
Sa kabila ng lahat ng kaguluhang nakapalibot sa mga data lakehouse, mahalagang tandaan na ang ideya ay bago pa rin. Siguraduhing timbangin ang mga disadvantages bago ganap na gumawa sa bagong disenyo na ito.
- Monolithic na istraktura: Ang lahat-ng-napapabilang na disenyo ng isang lakehouse ay nag-aalok ng ilang mga pakinabang, ngunit ito rin ay nagpapataas ng ilang mga problema. Ang monolitikong arkitektura ay madalas na humahantong sa hindi magandang serbisyo para sa lahat ng mga gumagamit at maaaring maging matibay at mahirap mapanatili. Kadalasan, gusto ng mga arkitekto at taga-disenyo ang isang mas modular na arkitektura na maaari nilang i-customize para sa iba't ibang kaso ng paggamit.
- Ang teknolohiya ay hindi pa naroroon: ang pangwakas na layunin ay nangangailangan ng malaking halaga ng machine learning at artificial intelligence. Bago ang mga lakehouse ay maaaring gumanap bilang naisip, ang mga teknolohiyang ito ay dapat na umunlad pa.
- Hindi isang makabuluhang pag-unlad sa mga umiiral na istruktura: Mayroon pa ring malaking pag-aalinlangan sa kung gaano karaming halaga ang talagang maiaambag ng mga lakehouse. Naninindigan ang ilang detractors na ang disenyo ng lake-warehouse na ipinares sa naaangkop na automated na kagamitan ay makakamit ang maihahambing na kahusayan.
Mga Hamon ng Data Lakehouse
Maaaring mahirap gamitin ang pamamaraan ng data lakehouse. Dahil sa pagiging kumplikado ng mga bahagi ng bahagi nito, hindi tama na tingnan ang data lakehouse bilang isang sumasaklaw sa lahat ng perpektong istraktura o "isang platform para sa lahat," para sa isa.
Bukod pa rito, dahil sa dumaraming paggamit ng mga data lakes, ang mga negosyo ay kailangang ilipat ang kanilang kasalukuyang mga data warehouse sa kanila, umaasa lamang sa isang pangako ng tagumpay na walang maipakitang benepisyo sa ekonomiya.
Kung mayroong anumang mga problema sa latency o outage sa buong proseso ng paglilipat, maaaring mauwi ito sa pagiging mahal, nakakaubos ng oras, at marahil ay hindi ligtas.
Dapat tanggapin ng mga user ng negosyo ang mga mataas na espesyalisadong teknolohiya, ayon sa ilang partikular na vendor na hayag o tuwirang nagbe-market ng mga solusyon bilang mga data lakehouse. Maaaring hindi palaging gumagana ang mga ito sa iba pang mga tool na naka-link sa data lake sa gitna ng system, na nagdaragdag sa mga isyu.
Bukod pa rito, maaaring mahirap magbigay ng 24/7 analytics habang nagpapatakbo ng mga gawaing kritikal sa negosyo, na nangangailangan ng imprastraktura na may cost-effective na scalability.
Konklusyon
Ang pinakabagong iba't ibang mga sentro ng data sa mga nakaraang taon ay ang data lakehouse. Pinagsasama nito ang iba't ibang larangan, tulad ng teknolohiya ng impormasyon, open-source software, cloud computing, at ibinahagi na mga protocol ng imbakan.
Binibigyang-daan nito ang mga negosyo na mag-imbak sa gitna ng lahat ng uri ng data mula sa anumang lokasyon, na pinapasimple ang pamamahala at pagsusuri. Ang Data Lakehouse ay isang medyo nakakaintriga na konsepto.
Ang anumang kumpanya ay magkakaroon ng isang makabuluhang competitive edge kung ito ay may access sa isang all-in-one na platform ng data na kasing bilis at episyente gaya ng isang data warehouse habang nababaluktot din gaya ng isang data lake.
Ang ideya ay umuunlad pa rin at nananatiling medyo bago. Bilang resulta, maaaring tumagal ng ilang oras upang matukoy kung ang isang bagay ay maaaring lumaganap o hindi.
Dapat tayong lahat ay maging interesado tungkol sa direksyon kung saan patungo ang arkitektura ng Lakehouse.
Mag-iwan ng Sagot