本文主要介绍携程旅行团队数据仓库建设的实施与实践，将从业务痛点、业务目标、项目架构、项目建设等维度进行。
一、业务痛点
随着对实时数据需求的不断增加，离线数据仓库暴露出的业务痛点越来越多，例如：
烟囱开发模式的实时需求。
中间数据的可重用性较差。
与数据开发分离。
数据生产服务周期长。
实时表任务杂乱无章且难以管理。
缺少实时谱系、基本信息、监控等。
实时数据：没有质量监控工具。
实时任务：运维门槛高，质量体系薄弱。
这种典型问题会给我们人类的效率、素质、管理等带来极大的考验，亟需一个系统的平台来解决。
2. 业务目标
围绕已知业务痛点，依托公司现有的计算资源、存储资源、离线数仓标准规范等，我们的目标是构建一个在人力、质量、管理层面的体系。 如下图所示：
1.人类效率水平
实现数据开发解决方案的标准化，如标准化数据处理、兼容性、算力集成等。
分钟级数据部署，实现BI学生级数据接口注册、发布、调试等可视化操作。
2.质量水平
数据内容DQC，如内容是否正确、不完整、及时、是否符合**等。
数据任务预警，如有无延迟、有无背压、吞吐量如何、系统资源是否充足等。
3.管理层
可视化管理平台，如端到端血缘、数据表任务、质量覆盖率等基础信息。
规范一体化数据仓库的全流程，如数据建模规范、数据质量规范、数据治理规范、存储选型规范等。
三、项目结构
项目架构如下，系统主要包括：原始数据、数据开发、数据服务、数据质量、数据管理等模块，提供秒级实时数据处理和分钟级数据服务部署，用于实时数据开发学生和后端数据服务开发。
不同数据的数据首先由标准化的ETL组件进行标准化，数据由流量工具进行预处理，采用流批融合工具和业务数据处理模块进行分层域构建，产生的数据由数据服务模块直接部署进行数据API部署， 最后被业务应用使用，整个环节都会有相应的质量和运维保障体系。
四、项目建设
1.数据开发
本模块主要包括数据预处理工具和数据开发方案选择。
1）流量**工具
由于入口数量多，人流量大，主要问题如下：
可能有多种方法可以解析同一维度中的数据**;
使用的埋地数据占总量的20%左右，资源消耗严重，每个下游都会重复操作;
新增埋点后，需要对数据处理进行开发和干预（极端情况下，所有用户都参与其中）;
如下图所示，流量工具动态接入多个数据源，数据处理简单，标准化后将有效数据写入下游，可以解决上述问题。
2） 业务数据处理解决方案的演变
选项 1 - 简单融合来自 ** 的数据
背景
刚开始的时候，业务需求比较简单，比如计算用户历史的实时订单量，汇总用户历史购买的景点信息等。 这些简单的要求可以抽象为离线数据和实时数据的简单聚合，如数值加减乘除、字符追加、去重和汇总等。
溶液
如下图所示，数据提供者提供标准化的T+1和实时数据访问; 数据处理：T+1和实时数据融合; 一致性检查; 动态规则引擎处理等; 数据存储：聚合数据的水平扩展; 标签映射等。
方案 2 - 支持 SQL
背景
尽管选项 1 具有以下优点：
分层简单且对时间敏感。
规则配置速度快，可以处理大量复杂的 UDF
规则引擎等
兼容整个 J**A 生态系统。
但也有明显的缺点：
BI SQL开发人员基本上无法干预并依赖开发。
在很多SQL场景下，使用J**A的开发成本高，稳定性差。
没有有效的数据分层。
过程数据基本不可用，如果要保存过程数据，需要重复计算，浪费计算资源。
溶液
如下图所示，Kafka 承载数据分层功能，Flink SQL 计算引擎，OLAP 承载数据存储和分层查询，完成了数据仓库系统的典型分层构建。
但是，由于 Kafka 和 OLAP 存储引擎是两个实体，因此可能会存在数据不一致的情况，例如 Kafka 正常，数据库异常，这会导致中间分层数据异常，但最终结果是正常的。 为了解决上述问题，如下图所示，采用传统数据库使用的binlog模式，Kafka数据很大程度上依赖于DB的数据变化，因此最终结果强烈依赖于中间的分层结果，无法避免组件BIG导致的数据不一致， 但大多数场景基本上都可用。
方案 3
背景
但是，选项 2 具有以下优点：
SQL格式。 自然分层查询。
但也有明显的缺点：
数据不一致。
插入binlog时没有问题，但是更新删除不容易，更新时需要大量的去重操作，SQL非常不友好。
对于长期的数据聚合，一些算子，如max和min，具有较大的flink状态，容易出现不稳定。
还要考虑 Kafka 数据乱序导致的数据覆盖问题。
溶液
如下图所示，借用存储引擎的算力，以 Kafka 的二进制日志作为数据计算的触发逻辑，使用 Flink udf 查询数据库进行直接连接。
优势：
SQL格式。 自然分层查询。
数据是一致的。 flink 状态很小。
它可以支持长期持久的数据聚合。
您无需担心无序的二进制日志和更新引起的问题。
弊：
并发是不能承载的，很大程度上取决于OLAP引擎的性能，所以当数据源在数据源中时，我们会限制窗口的速率或水平扩容数据库。
sink 和 drawdown 流的组合被打断了，比如：group by，其实就是一个无脑的upsert，UDF的聚合无法取代Flink的原生聚合;
每个解决方案都有自己的场景，您需要根据不同的业务场景和时延需求来选择解决方案。 目前，我们 86% 的场景可以使用解决方案 3 进行，并且由于 Flink 116、在各类集成特性的加持下，基本可以覆盖后期的所有场景。
2.数据服务
该模块提供数据同步、数据存储、数据查询、数据服务等能力，可在简单场景下实现分钟级数据服务部署能力，节省90%的开发工时。 实现离线数据DQC强依赖、工程端DQC异常、客户端>接口层资源隔离、限流、断路器、全链路沿袭（客户端-服务器端表Hive沿袭）管理等，提供部署各种性能需求接口的能力，按需提供运维保障能力。
架构如下：
3.数据质量
该模块主要分为数据内容质量和数据任务质量。
1） 数据内容
正确性、及时性、稳定性
这部分又分为数据操作变更、数据内容一致性、数据读取一致性、数据正确性和及时性等。 如下图所示，如果数据异常，可以将数据录入公司的HickWall报警中心，并根据预警规则生成报警。 数据内容：会有定时任务，执行用户自定义的SQL语句，将数据写入告警平台，可实现秒级、分钟级预警。
读取一致性
如下图所示，如果在数据读取过程中存在跨表联合查询，如果其中一个表出现问题，大多数情况下不会显示错误的数据，只会显示历史记录中的正确数据，恢复表后会显示所有数据。
例如，如果表2中的数据异常，最近2小时内没有数据，则当数据暴露给用户时，业务需要展示2小时前的数据，异常数据会给出前端异常提醒。
一致性
关于离线和实时数据一致性。 如下图所示，我们用一种简单的方法，直接将实时数据同步到Hudi，使用Hudi对照离线和实时数据进入告警平台。
2） 数据任务
上游任务
依托公司定制的预警埋点、告警中台、计算平台等工具，对上游消息队列是否延迟、音量是否异常等关键指标进行监控预警。
当前任务
您可以对数据处理任务的吞吐量、时延、反压、资源等关键指标进行监控和预警，防止数据处理任务出现长期异常。
4.数据管理
该模块可以串联数据处理、质量等模块，并提供可视化管理平台，如：表沿袭、DQC配置、任务状态、监控等基本信息。
下图显示了每个数据表中上下游数据生产任务的血缘关系。
数据表的质量信息详情如下图所示。
下图总结了各种UDF表的基本信息。
第5章 展望
目前系统基本能够承接团队大部分数据开发需求，后期我们还会在可靠性、稳定性、易用性等方面继续探索，如完善整个数据治理体系、构建数据自动恢复工具、排查运维智能组件、探索服务分析一体化等。
作者丨成瑞**丨***携程科技 （ID： 携程科技） DBAPLUS社区欢迎技术人员投稿，投稿邮箱editor@dbapluscn