1. 摘要
数据是每项技术业务的支柱，作为一个健康医疗技术平台，Halodoc 更是如此，用户可以通过以下方式与 Halodoc 交互：
- 送药
- 与医生交谈
- 实验室测试
- 医院预约和药物
所有这些交互都会产生高度敏感、多样化且通常是非结构化的数据。 因此随着公司的成长，必须拥有一个强大的数据平台，平台需要满足如下需求：
- 确保数据的隐私和安全
- 在处理结构化和半/非结构化数据时可靠、可扩展、快速且高可用
- 促进为业务/运营团队生成报告和实时仪表板
- 为数据科学团队提供一个平台来运行实验、模型和存储结果
2. 数据平台
Halodoc 基础设施托管在 AWS 上，公司的数据基础设施是 AWS 托管服务和自托管服务的组合，Amazon Redshift 是我们存储各类型数据的主要数据仓库。
该平台的关键组件如下所述
2.1 数据源
Halodoc 生成的数据属于以下类别：
- 事务数据 - 各种后端服务生成的数据，如咨询、药房订单、约会等，这些数据主要来自关系数据库 (MySQL)。
- 数字健康记录 - 医生预约、医疗账单、处方、保险索赔等的医疗报告。这些可能是图像或文件，具体取决于医院和商家合作伙伴。
- 商户库存数据 - 我们商户药店的库存数据可以采用不同的格式（csv、xls），通过不同的工具（SFTP、定制软件）上传。
- 来自后端服务的事件——我们的后端由微服务和一个事件生成/消费平台组成，用于这些服务之间的异步通信。因此跨不同后端服务生成的事件需要进行实时处理。
- 保险索赔/医疗账单- Halodoc作为 TPA 还参与索赔解决、验证索赔和检测欺诈。这些文档可以以各种格式（csv、xls、PDF）获取，需要及时处理以便为患者和保险提供商提供更顺畅的理赔体验。
2.2 批处理管道
批处理管道是我们数据平台的核心，对后端服务和第三方分析工具生成的事务/临时数据进行处理并写入数据仓库。该管道的主要组成部分包括：
- ETL 工具：ETL 代表提取、转换、加载，ETL 工具有多种选择。在 Halodoc ETL 主要使用 Airflow 和 Pentaho。
- Pentaho：Pentaho 是一个提供数据提取、集成、转换、挖掘和加载功能的工具。Pentaho 很大程度上是由 UI 驱动，并且受限于软件提供的功能，在 Halodoc我们正在慢慢地从 Pentaho 转向 Airflow。
- Airflow：Airflow 是一个非常灵活的工具，可以更好地控制转换，同时还可以在现有operator之上构建自己的框架，Airflow 还提供了一个很好的仪表板来监控和查看作业运行状态。
数据仓库和数据湖：数据仓库是经过优化的数据库，可以分析来自不同系统的关系型数据，数据结构和模式是预先定义的，以优化快速 SQL 查询，结果通常用于报告和分析。数据被清理、丰富和转换，以便它可以作为用户可以信任的“单一事实来源”。数据湖则是不同的，因为它存储来自业务线应用程序的关系数据以及来自移动应用程序、物联网设备和社交媒体的非关系数据，捕获数据时未定义数据结构或模式。
- Amazon S3 数据湖：Amazon S3 是 Halodoc 的数据湖。 来自各种来源的所有数据首先转储到各种 S3 存储桶中，然后再加载到 Redshift（我们的数据仓库）中，S3 中的数据也充当备份，以防任何 ETL 作业失败。
- Amazon Redshift：我们使用 Amazon 的 Redshift 作为集中式数据仓库，包含一个六节点 Redshift 集群，数据以有规律的节奏从各种来源流入，Amazon Redshift 针对批量加载和通过复制命令从 S3 加载进行了优化，我们所有的业务分析师、数据科学家和决策者都通过各种可视化工具（Looker/Metabase）、SQL 客户端和其他分析应用程序访问数据。
存储在 Redshift 中的数据被建模为星型模式，根据我们拥有的业务单位，由维度表包围中心事实表。
2.3 实时处理管道
实时数据处理管道作为 Halodoc 事件平台的底层基础设施，Halodoc 的所有后端服务在每次操作/状态更改后都会生成事件，并通过此管道进行处理，大多数基于流的系统由以下 4 个组件组成：
- 基于日志的事件存储：分布式、可追加的基于日志的系统，它收集和存储来自不同来源的数据。例如：Kafka、AWS Kinesis Streams、Google PubSub 等。
- 流计算系统：使用来自事件存储的数据并在其上运行聚合函数，然后将结果存储在服务层存储中，例如AWS Kinesis Data Analytics、Apache Flink、Apache Storm、Apache Spark 等。
- 服务层存储：存储聚合数据并提供优化的查询响应，它也可以存储时间序列数据。例如InfluxDB、Elasticsearch、AWS DynamoDB 等。
- 服务层：为聚合数据提供可视化表示，例如：Kibana、Grafana 等。
架构
- Apache Kafka – Kafka 已成为大多数开源流处理存储层的事实标准，用于以低延迟的流方式存储大量数据。
- Apache Flink：开源平台，为数据流上的分布式计算提供数据分发、通信、状态管理和容错。
- Elasticsearch：开源数据存储，主要针对搜索进行了优化，但后来作为运营和业务指标的服务层存储变得非常流行。
- Kibana/Grafana ：一个连接到 Elasticsearch 数据存储并充当服务层的开源可视化框架。
2.4 数据可视化
有很多可用的数据可视化工具，其中大多数都支持用于构建仪表板的各种数据源。 我们对工具的选择主要受以下因素驱动：
- 易用性：BI 开发人员/分析师必须很容易即可创建和维护报告和仪表板。
- RBAC：我们应该能够为公司中的不同用户提供细粒度的访问。
- 可维护性：工具必须易于维护，无论是在软件升级、部署和故障排除等方面。
考虑到所有这些因素，我们得出了以下工具：
Looker
- Looker 是一款高级工具，可提供丰富的可视化效果，是我们所有 BI 报告的一站式平台。
- 它提供了一种简单的方法来衡量 WoW / MoM 增长并跟踪我们的年度目标。
- 在解决问题时Looker 的支持团队反应迅速，同时提供具有最新功能的软件升级。
Metabase
- Metabase 是一个简单的开源工具，可供公司中的每个人提问和可视化数据。
- 在 Halodoc，Metabase 用作自助服务工具，操作人员和 BI/后端开发人员可以在其中查询以创建自定义报告和仪表板。
- 集成插件以发送有关某些关键业务指标的实时警报，警报渠道包括slack/电子邮件。
Kibana
- 由于使用 Elasticsearch 作为数据源，Kibana 提供了方便的仪表板可视化。
- 所有用于监控实时指标（如商家取消、医生取消等）的实时仪表板都在 Kibana 中创建。
- 客户支持和运营团队依靠这些仪表板做出及时的决策。
2.5 监控数据基础设施
监控和警报对于检查系统和发现生产问题是不可或缺的，它还直接影响平台的可靠性。Halodoc 数据基础设施由各种工具组成，其中一些由 AWS 管理（Redshift、MSK），而另一些则由内部托管（Elasticsearch、Flink）并由我们的开发运营/数据团队维护，用于监控的工具包括：
Cloudwatch：它是 AWS 用于监控指标和警报的事实标准，所有 AWS 托管服务（Redshift、MSK、RDS、DynamoDB）都将其指标发布到 Cloudwatch，我们为以下各项设置了警报：
- CPU 使用率和 Redshift 集群运行状况
- RDS 上的慢查询
- Lambda 错误
- 数据库连接数等等
警报渠道包括通过 Lambda 发送的 slack/电子邮件。
Prometheus 与 Grafana：Prometheus 和 Grafana 的组合越来越流行，作为 DevOps 团队用于存储和可视化时间序列数据的监控，Prometheus 充当存储后端，Grafana 充当分析和可视化的界面。Prometheus 通过这些目标上的导出器从 HTTP 端点抓取指标，从受监控的目标收集指标。
我们已经自托管了一些平台组件，例如 Airflow、Elasticsearch、Flink 等，自托管这些工具的决定是考虑到成本、devops/数据团队的经验和监控成本。
我们为所有这些工具提供了 prometheus 指标导出器，并且使用了用于 Elasticsearch、Airflow 和 Flink 的开源 Grafana 仪表板，同时在 prometheus 上设置了基于多种可用指标的各种阈值的警报设置，以通过 slack/email 告警。
3. 总结
在这篇博客中总结了Halodoc的数据平台，从不同来源的数据到各种可视化工具，我们在选择这些工具时的思考过程，维护和运行此基础设施是一项艰巨的任务，我们不断挑战自己以保持基础设施简单并更有效地解决问题。
可扩展性、可靠性和可维护性是构建 Halodoc 技术平台的三大支柱。后续还将介绍数据平台架构到Lakehouse架构的演进，敬请期待。