The post has been translated automatically. Original language: Russian
Lakehouse is not a "silver bullet", it does not solve all problems. When working with data, difficulties usually lie in the plane of organizational processes and culture on the customer's side. This culture needs to be built and maintained. The role of technology is to make data access, management, and analytical insights as convenient as possible. But technology is just a tool: it helps, but it will not give answers to a person who is not ready to use it. So this is not a panacea, but a reasonable evolution of technical approaches — another round of changes. The key to success lies beyond technology itself: in organizational decisions and, among other things, in the political will that makes working with data a strategy, a project goal, and a norm for all employees of the company.
Are there any areas that are not yet "ripe" for using Lakehouse? Yes. I would talk here not so much about directions as about anti—patterns - cases where Lakehouse is not needed. Any technology and architecture is appropriate only in their scenarios. If the amount of data is in gigabytes rather than terabytes, meaning it's not big data, Lakehouse won't do any good — it 's shooting sparrows with a cannon and an erroneous architectural choice. If the data is strictly structured, changes extremely rarely, and a Data Warehouse has already been built, there is no point in switching to Lakehouse: it will be replacing one with another without winning. If an organization is not ready to change its approaches to working with data, to build a culture and processes of Data Governance, then Lakehouse is also inapplicable. Governance is the DNA of the system: without a catalog of data and metadata Lakehouse will quickly turn into a "swamp". But if all these conditions are met: there is really a lot of data, the company is ready to change and maintain order in the data, then Lakehouse is justified. The range of tasks being solved is enormous: from data engineering and analytics to BI and ML scenarios.
Lakehouse — не «серебряная пуля», он не решает всех проблем. В работе с данными сложности, как правило, лежат в плоскости организационных процессов и культуры на стороне заказчика. Эту культуру нужно выстраивать и поддерживать. Роль технологий — сделать доступ к данным, управление ими и получение аналитических инсайтов максимально удобными. Но технология — лишь инструмент: она помогает, но не даст ответов человеку, который не готов ей пользоваться. Так что это не панацея, а разумная эволюция технических подходов — очередной виток изменений. Ключ к успеху остается за рамками собственно технологий: в организационных решениях и в том числе в политической воле, которая делает работу с данными стратегией, целью проекта и нормой для всех сотрудников компании.
Есть ли направления, которые пока еще не «созрели» для использования Lakehouse? Да. Я бы говорил здесь не столько о направлениях, сколько об антипаттернах — случаях, когда Lakehouse не нужен. Любая технология и архитектура уместна лишь в своих сценариях. Если объем данных исчисляется гигабайтами, а не терабайтами, то есть это не большие данные, Lakehouse не принесет пользы — это стрельба из пушки по воробьям и ошибочный архитектурный выбор. Если данные строго структурированы, крайне редко меняются и уже построен Data Warehouse, смысла переходить на Lakehouse нет: это будет замена одного на другое без выигрыша. Если организация не готова менять подходы к работе с данными, выстраивать культуру и процессы Data Governance, то Lakehouse также неприменим. Governance — это ДНК системы: без каталога данных и метаданных Lakehouse быстро превратится в «болото». Но если все эти условия соблюдены: данных действительно много, компания готова меняться и поддерживать порядок в данных, — тогда Lakehouse оправдан. Спектр решаемых задач при этом колоссален: от дата-инженерии и аналитики до BI- и ML-сценариев.
Share
