การพิจารณาบริการและตัวเลือกสถาปัตยกรรมที่มีอยู่ทั้งหมดอาจเป็นเรื่องยากเล็กน้อยเมื่อคิดถึงแพลตฟอร์มข้อมูล
แพลตฟอร์มข้อมูลองค์กรมักประกอบด้วยคลังข้อมูล โมเดลข้อมูล คลังข้อมูล และรายงาน โดยแต่ละแพลตฟอร์มมีวัตถุประสงค์เฉพาะและชุดทักษะที่จำเป็น ในทางตรงกันข้าม การออกแบบใหม่ที่เรียกว่า data lakehouse ได้เกิดขึ้นในช่วงไม่กี่ปีที่ผ่านมา
ความเก่งกาจของ data Lake และการจัดการข้อมูลคลังข้อมูลถูกรวมเข้าด้วยกันในสถาปัตยกรรมการจัดเก็บข้อมูลที่ปฏิวัติวงการซึ่งเรียกว่า "data lakehouse"
เราจะตรวจสอบ data lakehouse ในเชิงลึกในโพสต์นี้ รวมถึงส่วนประกอบ คุณลักษณะ สถาปัตยกรรม และแง่มุมอื่นๆ
Data Lakehouse คืออะไร?
ตามชื่อที่สื่อถึง data lakehouse เป็นสถาปัตยกรรมข้อมูลรูปแบบใหม่ที่รวม data lake กับคลังข้อมูลเพื่อแก้ไขข้อบกพร่องของแต่ละส่วนแยกกัน
โดยพื้นฐานแล้ว ระบบ Lakehouse ใช้ที่เก็บข้อมูลราคาไม่แพงเพื่อรักษาข้อมูลจำนวนมหาศาลในรูปแบบดั้งเดิม เหมือนกับ Data Lake การเพิ่มชั้นข้อมูลเมตาที่ด้านบนของสโตร์ยังช่วยให้มีโครงสร้างข้อมูลและช่วยให้เครื่องมือการจัดการข้อมูลมีประสิทธิภาพเช่นเดียวกับที่พบในคลังข้อมูล
เก็บข้อมูลจำนวนมหาศาลที่มีการจัดระเบียบ กึ่งมีโครงสร้าง และไม่มีโครงสร้าง ที่ได้รับจากแอปพลิเคชัน ระบบ และแกดเจ็ตทางธุรกิจต่างๆ ที่ใช้ทั่วทั้งองค์กร
โดยส่วนใหญ่ Data Lake ใช้โครงสร้างพื้นฐานการจัดเก็บข้อมูลต้นทุนต่ำพร้อม File Application Programming Interface (API) เพื่อจัดเก็บข้อมูลในรูปแบบไฟล์ทั่วไปที่เปิดกว้าง
ทำให้หลายทีมสามารถเข้าถึงข้อมูลทั้งหมดของบริษัทผ่านระบบเดียวสำหรับความคิดริเริ่มที่หลากหลาย เช่น วิทยาศาสตร์ข้อมูล เรียนรู้เครื่องและระบบธุรกิจอัจฉริยะ
คุณสมบัติ
- การจัดเก็บต้นทุนต่ำ Data Lakehouse จะต้องสามารถจัดเก็บข้อมูลในที่จัดเก็บอ็อบเจ็กต์ราคาไม่แพง เช่น Google Cloud พื้นที่จัดเก็บ, Azure Blob Storage, Amazon Simple Storage Service หรือใช้ ORC หรือ Parquet
- ความสามารถในการปรับข้อมูลให้เหมาะสม: การเพิ่มประสิทธิภาพเค้าโครงข้อมูล การแคช และการทำดัชนี เป็นเพียงตัวอย่างเล็กๆ น้อยๆ ของวิธีที่ data lakehouse ต้องสามารถปรับข้อมูลให้เหมาะสมในขณะที่ยังคงรักษารูปแบบดั้งเดิมของข้อมูลไว้
- เลเยอร์ของข้อมูลเมตาของธุรกรรม: นอกเหนือจากการจัดเก็บข้อมูลต้นทุนต่ำที่จำเป็น สิ่งนี้ยังช่วยให้สามารถจัดการข้อมูลซึ่งมีความสำคัญต่อประสิทธิภาพของคลังข้อมูล
- รองรับ Declarative DataFrame API: เครื่องมือ AI ส่วนใหญ่สามารถใช้ DataFrames เพื่อดึงข้อมูลที่เก็บอ็อบเจ็กต์ดิบ การสนับสนุน Declarative DataFrame API เพิ่มความสามารถในการปรับปรุงการนำเสนอและโครงสร้างของข้อมูลแบบไดนามิกเพื่อตอบสนองต่อวิทยาศาสตร์ข้อมูลหรืองาน AI โดยเฉพาะ
- รองรับธุรกรรม ACID: ตัวย่อ ACID ซึ่งย่อมาจาก atomicity ความสม่ำเสมอ การแยกตัว และความทนทาน เป็นองค์ประกอบสำคัญในการกำหนดธุรกรรมและสร้างความมั่นใจในความสอดคล้องและความน่าเชื่อถือของข้อมูล การทำธุรกรรมดังกล่าวก่อนหน้านี้ทำได้เฉพาะในคลังข้อมูล แต่ Lakehouse เสนอทางเลือกในการใช้งานกับ data lakes เช่นกัน. ด้วยไปป์ไลน์ข้อมูลหลายอันรวมถึงการอ่านและเขียนข้อมูลพร้อมกัน สิ่งนี้ช่วยแก้ปัญหาคุณภาพข้อมูลต่ำของหลัง
องค์ประกอบของ Data Lakehouse
สถาปัตยกรรมของ data lakehouse แบ่งออกเป็นสองระดับหลักในระดับสูง ปริมาณข้อมูลของชั้นการจัดเก็บถูกควบคุมโดยแพลตฟอร์ม Lakehouse (กล่าวคือ Data Lake)
โดยไม่ต้องโหลดข้อมูลลงในคลังข้อมูลหรือแปลงเป็นรูปแบบที่เป็นกรรมสิทธิ์ จากนั้นเลเยอร์การประมวลผลก็สามารถสืบค้นข้อมูลในชั้นจัดเก็บข้อมูลได้โดยตรงโดยใช้เครื่องมือต่างๆ
จากนั้น แอป BI ตลอดจนเทคโนโลยี AI และ ML ก็สามารถใช้ข้อมูลได้ การออกแบบนี้ให้ความประหยัดของ Data Lake แต่เนื่องจากเครื่องมือประมวลผลใดๆ สามารถอ่านข้อมูลนี้ได้ ธุรกิจจึงมีอิสระในการทำให้ข้อมูลที่เตรียมไว้สามารถเข้าถึงได้สำหรับการวิเคราะห์โดยระบบต่างๆ ทั้งประสิทธิภาพและต้นทุนของโปรเซสเซอร์สามารถปรับปรุงได้โดยใช้วิธีนี้สำหรับการประมวลผลและการวิเคราะห์
เนื่องจากรองรับธุรกรรมฐานข้อมูลที่เป็นไปตามเกณฑ์ ACID (อะตอมมิก ความสอดคล้อง การแยก และความทนทาน) สถาปัตยกรรมนี้ยังช่วยให้ฝ่ายต่างๆ เข้าถึงและเขียนข้อมูลพร้อมกันภายในระบบได้:
- ปรมาณู หมายถึงความจริงที่ว่าธุรกรรมทั้งหมดหรือไม่มีเลย ประสบความสำเร็จในขณะที่ทำธุรกรรมเสร็จสิ้น ในกรณีที่กระบวนการถูกขัดจังหวะ จะช่วยหลีกเลี่ยงการสูญเสียข้อมูลหรือความเสียหาย
- ความมั่นคง รับประกันธุรกรรมที่เกิดขึ้นในลักษณะที่คาดการณ์ได้และสม่ำเสมอ รักษาความสมบูรณ์ของข้อมูลโดยตรวจสอบให้แน่ใจว่าทุกข้อมูลถูกต้องตามกฎหมายตามกฎที่กำหนดไว้ล่วงหน้า
- ความเหงา ทำให้แน่ใจว่า จนกว่าจะเสร็จสิ้น ไม่มีธุรกรรมใดที่ได้รับผลกระทบจากธุรกรรมอื่นใดภายในระบบ ซึ่งช่วยให้หลายฝ่ายสามารถอ่านและเขียนจากระบบเดียวกันได้พร้อมๆ กันโดยไม่รบกวนซึ่งกันและกัน
- Durability รับประกันว่าการเปลี่ยนแปลงข้อมูลในระบบจะยังคงมีอยู่หลังจากการทำธุรกรรมเสร็จสิ้น แม้ในกรณีที่ระบบล้มเหลว การเปลี่ยนแปลงใด ๆ ที่เกิดจากการทำธุรกรรมจะถูกเก็บไว้ในไฟล์ตลอดไป
สถาปัตยกรรม Data Lakehouse
Databricks (ผู้ริเริ่มและผู้ออกแบบแนวคิด Delta Lake) และ AWS เป็นผู้สนับสนุนหลักสองคนสำหรับแนวคิดของ Data Lakehouse ดังนั้นเราจึงต้องอาศัยความรู้และความเข้าใจในการอธิบายรูปแบบสถาปัตยกรรมของบ้านริมทะเลสาบ
ระบบ data lakehouse โดยทั่วไปจะมีห้าชั้น:
- ชั้นกลืนกิน
- ชั้นเก็บของ
- เลเยอร์ข้อมูลเมตา
- เลเยอร์ API
- ชั้นการบริโภค
ชั้นกลืนกิน
เลเยอร์แรกของระบบมีหน้าที่รวบรวมข้อมูลจากแหล่งต่างๆ และส่งไปยังชั้นจัดเก็บข้อมูล เลเยอร์สามารถใช้โปรโตคอลหลายตัวเพื่อเชื่อมต่อกับแหล่งข้อมูลภายในและภายนอกจำนวนมาก รวมถึงการรวมความสามารถในการประมวลผลข้อมูลแบบแบตช์และสตรีม เช่น
- ฐานข้อมูล NoSQL
- การแชร์ไฟล์
- แอปพลิเคชัน CRM
- เว็บไซต์
- เซ็นเซอร์ IoT,
- สื่อสังคม,
- แอปพลิเคชันซอฟต์แวร์เป็นบริการ (SaaS) และ
- ระบบจัดการฐานข้อมูลเชิงสัมพันธ์ ฯลฯ
ณ จุดนี้ ส่วนประกอบต่างๆ เช่น Apache Kafka สำหรับการสตรีมข้อมูลและ Amazon Data Migration Service (Amazon DMS) สำหรับการนำเข้าข้อมูลจาก RDBMS และฐานข้อมูล NoSQL สามารถใช้ได้
ชั้นเก็บของ
สถาปัตยกรรมบ้านริมทะเลสาบมีไว้เพื่อให้จัดเก็บข้อมูลประเภทต่างๆ เป็นออบเจ็กต์ในที่เก็บอ็อบเจ็กต์ราคาไม่แพง เช่น AWS S3 เครื่องมือไคลเอ็นต์สามารถอ่านรายการเหล่านี้ได้โดยตรงจากร้านค้าโดยใช้รูปแบบไฟล์เปิด
สิ่งนี้ทำให้ API และองค์ประกอบเลเยอร์การบริโภคจำนวนมากเข้าถึงและใช้ข้อมูลเดียวกันได้ ชั้นข้อมูลเมตาจะจัดเก็บสคีมาสำหรับชุดข้อมูลที่มีโครงสร้างและกึ่งมีโครงสร้าง เพื่อให้ส่วนประกอบสามารถนำไปใช้กับข้อมูลได้ในขณะที่อ่าน
ตัวอย่างเช่น แพลตฟอร์ม Hadoop Distributed File System (HDFS) สามารถใช้เพื่อสร้างบริการพื้นที่เก็บข้อมูลบนคลาวด์ที่แยกการประมวลผลและการจัดเก็บในองค์กร Lakehouse เหมาะอย่างยิ่งสำหรับบริการเหล่านี้
เลเยอร์ข้อมูลเมตา
ชั้นข้อมูลเมตาเป็นองค์ประกอบพื้นฐานของ data lakehouse ที่ทำให้การออกแบบนี้แตกต่าง เป็นแค็ตตาล็อกเดียวที่นำเสนอข้อมูลเมตา (ข้อมูลเกี่ยวกับส่วนข้อมูลอื่นๆ) สำหรับรายการทั้งหมดที่จัดเก็บไว้ในทะเลสาบ และให้ผู้ใช้ใช้ความสามารถในการดูแลระบบ เช่น:
- ฐานข้อมูลเวอร์ชันที่สอดคล้องกันจะเห็นได้จากธุรกรรมที่เกิดขึ้นพร้อมกันด้วยธุรกรรม ACID
- การแคชเพื่อบันทึกไฟล์ที่เก็บอ็อบเจ็กต์บนคลาวด์
- การเพิ่มดัชนีโครงสร้างข้อมูลโดยใช้การจัดทำดัชนีเพื่อเพิ่มความเร็วในการประมวลผลแบบสอบถาม
- ใช้การโคลนเป็นศูนย์เพื่อทำซ้ำออบเจ็กต์ข้อมูล และ
- เพื่อจัดเก็บข้อมูลบางเวอร์ชัน ฯลฯ ใช้การกำหนดเวอร์ชันข้อมูล
นอกจากนี้ ชั้นข้อมูลเมตายังเปิดใช้งานการจัดการสคีมา การใช้โทโพโลยีสคีมา DW เช่น สคีมาแบบดาว/เกล็ดหิมะ และการจัดหาการกำกับดูแลข้อมูลและความสามารถในการตรวจสอบโดยตรงบน Data Lake ช่วยเพิ่มความสมบูรณ์ของไปป์ไลน์ข้อมูลทั้งหมด
ฟีเจอร์สำหรับวิวัฒนาการและการบังคับใช้สคีมารวมอยู่ในการจัดการสคีมา การบังคับใช้สคีมาทำให้ผู้ใช้รักษาความสมบูรณ์และคุณภาพของข้อมูลได้ด้วยการปฏิเสธการเขียนที่ไม่เป็นไปตามสคีมาของตาราง
วิวัฒนาการของสคีมาช่วยให้สามารถปรับเปลี่ยนสคีมาปัจจุบันของตารางเพื่อรองรับข้อมูลที่เปลี่ยนแปลงได้ เนื่องจากอินเทอร์เฟซการดูแลระบบเดียวที่ด้านบนของ Data Lake จึงมีความเป็นไปได้ในการควบคุมการเข้าถึงและการตรวจสอบ
เลเยอร์ API
สถาปัตยกรรมชั้นที่สำคัญอีกชั้นหนึ่งปรากฏขึ้นแล้ว โดยโฮสต์ API จำนวนหนึ่งที่ผู้ใช้ปลายทางทุกคนสามารถใช้เพื่อทำงานได้เร็วขึ้นและรับสถิติที่ซับซ้อนยิ่งขึ้น
การใช้ API ข้อมูลเมตาช่วยให้ระบุและเข้าถึงรายการข้อมูลที่จำเป็นสำหรับแอปพลิเคชันที่กำหนดได้ง่ายขึ้น
ในแง่ของไลบรารีการเรียนรู้ของเครื่อง บางไลบรารี เช่น TensorFlow และ Spark MLlib สามารถอ่านรูปแบบไฟล์ที่เปิดอยู่ เช่น Parquet และเข้าถึงชั้นข้อมูลเมตาได้โดยตรง
ในเวลาเดียวกัน DataFrame API ให้โอกาสในการเพิ่มประสิทธิภาพมากขึ้น ทำให้โปรแกรมเมอร์สามารถจัดระเบียบและเปลี่ยนแปลงข้อมูลที่กระจัดกระจายได้
ชั้นการบริโภค
Power BI, Tableau และเครื่องมือและแอปอื่นๆ ถูกโฮสต์ไว้ภายใต้เลเยอร์การบริโภค ด้วยการออกแบบ Lakehouse ข้อมูลเมตาทั้งหมดและข้อมูลทั้งหมดที่เก็บไว้ในทะเลสาบจะสามารถเข้าถึงได้โดยแอปไคลเอ็นต์
ผู้ใช้ทุกคนในบริษัทสามารถใช้บ้านริมทะเลสาบเพื่อดำเนินการได้ทุกประเภท การดำเนินการวิเคราะห์รวมถึงการสร้างแดชบอร์ดข่าวกรองธุรกิจและการเรียกใช้แบบสอบถาม SQL และงานการเรียนรู้ของเครื่อง
ข้อดีของ Data Lakehouse
องค์กรสามารถสร้าง data lakehouse เพื่อรวมแพลตฟอร์มข้อมูลปัจจุบันของตนเป็นหนึ่งเดียวและเพิ่มประสิทธิภาพกระบวนการจัดการข้อมูลทั้งหมด การรื้อสิ่งกีดขวางของไซโลที่เชื่อมต่อแหล่งที่มาต่างๆ เข้าด้วยกัน Data Lakehouse สามารถทดแทนความต้องการโซลูชันที่แตกต่างกันได้
เมื่อเปรียบเทียบกับแหล่งข้อมูลที่ได้รับการดูแลจัดการแล้ว การผสานรวมนี้จะสร้างขั้นตอนจากต้นทางถึงปลายทางที่มีประสิทธิภาพมากขึ้นอย่างเห็นได้ชัด มีข้อดีหลายประการ:
- การบริหารน้อย: แทนที่จะดึงข้อมูลจากข้อมูลดิบและเตรียมข้อมูลเพื่อใช้ภายในคลังข้อมูล Data Lakehouse ยอมให้แหล่งข้อมูลใดๆ ที่เชื่อมโยงกับข้อมูลดังกล่าวมีข้อมูลที่มีอยู่และจัดระเบียบเพื่อการใช้งาน
- เพิ่มความคุ้มค่า: Data Lakehouses สร้างขึ้นโดยใช้โครงสร้างพื้นฐานร่วมสมัยที่แบ่งการคำนวณและการจัดเก็บข้อมูล ทำให้ง่ายต่อการขยายพื้นที่จัดเก็บข้อมูลโดยไม่ต้องเพิ่มพลังในการประมวลผล การใช้พื้นที่จัดเก็บข้อมูลราคาถูกทำให้สามารถปรับขนาดได้อย่างคุ้มค่า
- การกำกับดูแลข้อมูลที่ดีขึ้น: Data Lakehouses ถูกสร้างขึ้นด้วยสถาปัตยกรรมแบบเปิดที่ได้มาตรฐาน ทำให้สามารถควบคุมการรักษาความปลอดภัย ตัวชี้วัด การเข้าถึงตามบทบาท และองค์ประกอบการจัดการที่สำคัญอื่นๆ ได้มากขึ้น การรวมทรัพยากรและแหล่งข้อมูลเข้าด้วยกันจะทำให้การกำกับดูแลง่ายขึ้นและดีขึ้น
- มาตรฐานแบบง่าย: เนื่องจากการเชื่อมต่อถูกจำกัดอย่างสูงในทศวรรษ 1980 เมื่อคลังข้อมูลได้รับการพัฒนาขึ้นเป็นครั้งแรก มาตรฐานสคีมาที่แปลเป็นภาษาท้องถิ่นจึงได้รับการพัฒนาบ่อยครั้งในธุรกิจ แม้กระทั่งในแผนกต่างๆ Data Lakehouse ใช้ประโยชน์จากข้อเท็จจริงที่ว่าขณะนี้ข้อมูลหลายประเภทมีมาตรฐานแบบเปิดสำหรับสคีมาโดยการนำเข้าแหล่งข้อมูลจำนวนมากด้วยสคีมาที่เหมือนกันที่ทับซ้อนกันเพื่อปรับปรุงขั้นตอนต่างๆ
ข้อเสียของ Data Lakehouse
แม้จะมี hoopla ทั้งหมดที่อยู่รอบ ๆ data lakehouses แต่สิ่งสำคัญคือต้องจำไว้ว่าแนวคิดนี้ยังใหม่มาก อย่าลืมชั่งน้ำหนักข้อเสียก่อนที่จะทำการออกแบบใหม่นี้อย่างเต็มที่
- โครงสร้างเสาหิน: การออกแบบแบบรวมทุกอย่างของบ้านริมทะเลสาบมีข้อดีหลายประการ แต่ก็ทำให้เกิดปัญหาบางประการเช่นกัน สถาปัตยกรรมแบบเสาหินมักนำไปสู่บริการที่ไม่ดีสำหรับผู้ใช้ทุกคน และอาจเข้มงวดและดูแลรักษายาก โดยทั่วไปแล้ว สถาปนิกและนักออกแบบชอบสถาปัตยกรรมแบบโมดูลาร์มากกว่าที่พวกเขาสามารถปรับแต่งสำหรับกรณีการใช้งานต่างๆ
- เทคโนโลยียังไม่ค่อยมี: เป้าหมายสุดท้ายทำให้เกิดการเรียนรู้ของเครื่องและปัญญาประดิษฐ์จำนวนมาก ก่อนที่โรงเรือนริมทะเลสาบจะสามารถทำงานได้อย่างที่คิดไว้ เทคโนโลยีเหล่านี้ต้องพัฒนาต่อไป
- ไม่มีความก้าวหน้าอย่างมีนัยสำคัญเหนือโครงสร้างที่มีอยู่: ยังมีความกังขาอยู่มากว่าบ้านริมทะเลสาบที่มีคุณค่าจริง ๆ จะมีส่วนร่วมมากขึ้นเพียงใด ผู้คัดค้านบางคนโต้แย้งว่าการออกแบบคลังสินค้าในทะเลสาบที่จับคู่กับอุปกรณ์อัตโนมัติที่เหมาะสมสามารถบรรลุประสิทธิภาพที่เทียบเท่ากัน
ความท้าทายของ Data Lakehouse
การนำเทคนิค data lakehouse มาใช้อาจเป็นเรื่องยาก เนื่องจากความสลับซับซ้อนของส่วนประกอบต่างๆ จึงไม่ถูกต้องที่จะมองว่า data lakehouse เป็นโครงสร้างในอุดมคติที่ครอบคลุมทุกด้านหรือ "แพลตฟอร์มเดียวสำหรับทุกสิ่ง" สำหรับหนึ่ง
นอกจากนี้ เนื่องจากการนำ data lake มาใช้เพิ่มมากขึ้น ธุรกิจต่างๆ จะต้องย้ายคลังข้อมูลปัจจุบันไปยังพวกเขา โดยอาศัยเพียงคำมั่นสัญญาว่าจะประสบความสำเร็จโดยไม่มีผลประโยชน์ทางเศรษฐกิจที่พิสูจน์ได้
หากมีปัญหาเวลาแฝงหรือการหยุดทำงานตลอดกระบวนการโอน การดำเนินการนี้อาจมีค่าใช้จ่ายสูง ใช้เวลานาน และอาจไม่ปลอดภัย
ผู้ใช้ทางธุรกิจต้องเปิดรับเทคโนโลยีที่มีความเชี่ยวชาญสูง ตามที่ผู้ขายบางรายระบุตลาดโซลูชันโดยชัดแจ้งหรือโดยปริยายเป็น data lakehouses สิ่งเหล่านี้อาจไม่ทำงานกับเครื่องมืออื่น ๆ ที่เชื่อมโยงกับ data lake ที่ศูนย์กลางของระบบเสมอไป ทำให้เกิดปัญหาเพิ่มขึ้น
นอกจากนี้ อาจเป็นเรื่องยากที่จะจัดหาการวิเคราะห์ตลอด 24 ชั่วโมงทุกวันในขณะที่ใช้งานปริมาณงานที่มีความสำคัญต่อธุรกิจ ซึ่งต้องใช้โครงสร้างพื้นฐานที่มีความสามารถในการปรับขนาดที่คุ้มค่า
สรุป
ศูนย์ข้อมูลใหม่ล่าสุดในช่วงไม่กี่ปีที่ผ่านมาคือ data lakehouse. มีการบูรณาการสาขาต่างๆ เช่น เทคโนโลยีสารสนเทศ ซอฟต์แวร์โอเพ่นซอร์ส คอมพิวเตอร์เมฆและโปรโตคอลหน่วยเก็บข้อมูลแบบกระจาย
ช่วยให้ธุรกิจสามารถจัดเก็บข้อมูลทุกประเภทจากที่ใดก็ได้จากศูนย์กลาง ทำให้การจัดการและการวิเคราะห์ง่ายขึ้น Data Lakehouse เป็นแนวคิดที่น่าสนใจทีเดียว
บริษัทใดๆ ก็ตามจะมีความได้เปรียบในการแข่งขันอย่างมากหากสามารถเข้าถึงแพลตฟอร์มข้อมูลแบบครบวงจรได้อย่างรวดเร็วและมีประสิทธิภาพเทียบเท่ากับคลังข้อมูล ในขณะที่มีความยืดหยุ่นเทียบเท่ากับ Data Lake
แนวคิดนี้ยังคงพัฒนาและค่อนข้างใหม่ ด้วยเหตุนี้ จึงอาจต้องใช้เวลาพอสมควรในการพิจารณาว่าบางสิ่งสามารถแพร่ระบาดได้หรือไม่
เราทุกคนควรสงสัยเกี่ยวกับทิศทางที่สถาปัตยกรรมของเลคเฮาส์กำลังมุ่งหน้าไป
เขียนความเห็น