数据平台已经彻底改变了公司存储、分析和使用数据的方式——但为了更有效地使用它们,它们需要可靠、高性能和透明。数据在制定业务决策和评估产品或 Halodoc 功能的性能方面发挥着重要作用。作为印度尼西亚最大的在线医疗保健公司的数据工程师,我们面临的主要挑战之一是在整个组织内实现数据民主化。Halodoc 的数据工程 (DE) 团队自成立以来一直使用现有的工具和服务来维护和处理大量且多样的数据,但随着业务的增长,我们的数据量也呈指数级增长,需要更多的处理资源。由于现代数据平台从不同的、多样化的系统中收集数据,很容易出现重复记录、错过更新等数据收集问题。为了解决这些问题,我们对数据平台进行了重新评估,并意识到架构债务随着时间的推移积累会导致大多数数据问题。我们数据平台的所有主要功能——提取、转换和存储都存在问题,导致整个数据平台存在质量问题。 现有数据平台 印尼医疗龙头企业Halodoc的数据平台转型之路:数据平台V1.0 在过去几年中为我们提供了很好的服务,但它的扩展性满足不了不断增长的业务需求。
在旧的数据平台中,大部分数据都是定期从各种数据源迁移到 Redshift。将数据加载到 Redshift 后,执行 ELT 以构建服务于各种业务用例的 DWH 或数据集市表。数据平台能够满足我们的大部分需求,但随着数据用例的增加,我们看到业务和数据量增长,为满足业务需求数据平台面临多重挑战。问题如下:
由于数据平台的这些限制,我们意识到第一代数据平台已经走到了尽头。正是在这一点上,我们决定退后一步,想想我们需要从我们的数据平台中得到什么。如果必须的话我们并不害怕从头开始构建一个系统。数据工程团队开始使用支持或减轻上述大部分限制的新数据平台来评估和改进现有架构。我们调研到了 LakeHouse 架构,它在通过具有成本效益的解决方案实现可扩展性以及处理大量数据方面发挥着至关重要的作用。因此我们开始围绕 LakeHouse 架构来构建我们改进后的 Data Platform 2.0。
LakeHouse 架构基本上是 Datalake 和数据仓库的组合,可以在其中无缝地跨湖和仓库移动数据,并遵循对所有数据集的访问权限的安全合规性。在 Halodoc,我们希望构建一个可扩展的解决方案,我们可以根据需要独立扩展存储和计算。我们将以下内容列为我们希望数据基础设施具备的核心功能:
在新架构中,我们利用 S3 作为数据湖,因为它可以无限扩展存储。由于我们计划将可变数据也存储在 S3 中,因此下一个挑战是保持可变 S3 数据的更新。我们评估了几个框架,如 Iceberg、Delta Lake 和 Apache Hudi,它们提供了更新可变数据的能力。由于 Apache Hudi 与 EMR 集成度很好,因此我们开始在 Hudi 之上构建数据湖。
搭建平台的挑战