高稳定性的网站设计制作题库网站怎样做

高稳定性的网站设计制作,题库网站怎样做,华为2021年营收和利润,木兰网简介在 Uber#xff0c;数据湖是支持整个公司分析和机器学习的基础平台。历史上#xff0c;进入数据湖的摄取#xff08;Ingestion#xff09;是由批处理作业驱动的#xff0c;其数据新鲜度#xff08;Freshness#xff09;以小时衡量。随着业务需求向近实时洞察演变数据湖是支持整个公司分析和机器学习的基础平台。历史上进入数据湖的摄取Ingestion是由批处理作业驱动的其数据新鲜度Freshness以小时衡量。随着业务需求向近实时洞察演变我们重新构建了基于 Apache Flink® 运行的摄取架构实现了更新鲜的数据、更低的成本以及 PB 级规模的可扩展运营。在过去的一年里我们构建并验证了 IngestionNext这是一个以 Flink 为核心的新型流式摄取系统。我们在 Uber 一些最大的数据集上证明了它的性能设计了用于操作数千个作业的控制平面并解决了流处理特有的挑战如小文件生成、分区倾斜和检查点同步。本博客描述了 IngestionNext 的设计以及显示出其相比批处理摄取具有更高的新鲜度和显著效率提升的早期结果。为什么要流式处理促使我们要从批处理转向流式处理的两个关键驱动因素是数据新鲜度和成本效率。随着业务发展速度加快Uber 的交付、乘客、出行、财务和营销分析组织不断要求更新鲜的数据以支持实时实验和模型开发。批处理摄取提供的数据会有数小时的延迟——在某些情况下甚至数天——这限制了迭代和决策的速度。通过在 Flink 上重新搭建摄取平台我们将新鲜度从数小时缩短到了数分钟。这一转变直接加速了全公司的模型发布、实验速度和分析准确性。在考虑成本效率时Apache Spark™ 批处理作业在设计上就是资源密集型的。它们按固定间隔编排大型分布式计算即使工作负载有所变化也是如此。在 Uber 的规模下——数千个数据集和数百 PB 的数据——这意味着每天有数十万个 CPU 核心在运行。流式处理消除了频繁批处理调度的开销使资源能够以更平滑、更高效的方式随流量进行扩展。架构概览IngestionNext 摄取系统由多个层组成。图 1IngestionNext 架构。在数据平面事件到达 Apache Kafka® 并被 Flink 作业消费。这些作业以 Apache Hudi™ 格式写入数据湖提供事务提交、回滚和时间旅行Time Travel功能。新鲜度和完整性是端到端衡量的从源端到目标端。大规模管理摄取需要自动化。我们设计了一个控制平面用于处理作业生命周期创建、部署、重启、停止、删除、配置更改和健康验证。这使得能够一致且安全地跨数千个数据集运行摄取。该系统还设计了区域故障转移和回退策略以维持可用性。在发生中断的情况下摄取作业可以跨区域转移或暂时以批处理模式运行从而确保连续性且无数据丢失。主要挑战与解决方案小文件流式摄取通常会生成许多小的 Apache Parquet™ 文件这会显著降低查询性能并增加元数据和存储开销。当数据连续到达且必须近实时写入时这是一个常见的挑战。传统且最常见的合并方法是逐记录record by record操作的需要对每个 Parquet 文件进行解压缩从列式格式解码为行格式进行合并然后再重新编码和压缩。虽然这种方法功能上可行但由于重复的编码/解码转换其计算量大且速度慢。图 2逐记录合并 Parquet 文件。为了克服这个问题我们引入了行组row-group级合并它直接在 Parquet 的原生列式结构上操作。这种设计避免了昂贵的重新压缩并将压缩compaction速度提高了一个数量级10倍以上。开源社区的努力例如 Apache Hudi PR #13365探索了感知模式演变schema-evolution-aware的合并利用填充和掩码来对齐不同的模式但这增加了大量的实现复杂性和维护风险。图 3带有数据掩码的行组合并。我们的方法通过强制模式一致性简化了该过程——仅合并共享相同模式的文件。这消除了对掩码或底层代码修改的需求在减少开发开销的同时提供了更快、更高效且更可靠的压缩。图 4通过对模式进行分组实现的简化行组合并。分区倾斜我们面临的另一个问题是短暂的下游减速如垃圾回收暂停会导致 Flink 子任务之间的 Kafka 消费不平衡。数据倾斜会导致压缩效率降低和查询速度变慢。我们通过运维调优将并行度与分区对齐调整拉取参数、连接器级别的公平性轮询、对重负载分区进行暂停/恢复、每个分区的配额以及改进的可观测性每个分区的滞后指标、感知倾斜的自动扩缩容和针对性警报解决了这个问题。检查点和提交同步我们还发现Flink 检查点跟踪已消费的偏移量而 Hudi 提交跟踪写入操作。如果在故障期间它们出现错位可能会导致数据丢失或重复。为了解决这个问题我们扩展了 Hudi 提交元数据以嵌入 Flink 检查点 ID从而在回滚或故障转移期间实现确定性的恢复。结果我们将数据集接入到基于 Flink 的摄取平台并证实基于 Flink 的摄取提供了分钟级的新鲜度同时相对于批处理减少了 25% 的计算使用量。下面是一个数据新鲜度得到改善的例子。图 5流式摄取前后对比后续步骤通过 IngestionNext我们将从在线 Kafka 到离线原始数据湖的摄取方式由批处理转变为流式处理从而显著改善了数据摄取延迟。然而新鲜度在下游的原始数据转换和分析环节仍然停滞不前。为了真正加速数据新鲜度我们必须将这种实时能力扩展到端到端——从摄取到转换再到实时洞察和分析。这在当下尤为关键。Uber 的数据湖支持着交付、出行、机器学习、乘客、市场、地图、财务和营销分析组织这使得数据新鲜度成为这些领域的重中之重。大多数数据集源于摄取但如果没有更快的下游转换和访问数据在决策点仍然是陈旧的。业务影响涵盖实验、风险检测、个性化和运营分析——在这些领域陈旧的数据会延缓创新降低响应能力并限制做出主动的、数据驱动决策的能力。结论我们从批处理到流式处理的旅程标志着 Uber 数据平台演进中的一个重要里程碑。通过在 Apache Flink 上重构摄取架构IngestionNext 在 Uber 的 PB 级数据湖上提供了更新鲜的数据、更强的可靠性和可扩展的效率。该系统的设计强调自动化弹性和操作简便性使工程师能够专注于构建数据驱动的产品而不是管理数据管道。对工程师而言其吸引力不仅在于技术基础——流式摄取、检查点同步和容错控制平面——还在于思维方式的系统性转变将新鲜度视为数据质量的一等维度。随着 IngestionNext 在生产环境中的验证下一个前沿领域在于扩展流式 ETL 和分析以完成实时数据闭环赋能 Uber 的所有团队充满信心地更快行动。封面照片归属“Fast running stream. Nikon D3100. DSC_0384” 由 Robert.Pittman 拍摄依据 CC BY-NC-ND 2.0 协议授权。Apache Flink、Flink 和 Flink 标志、Apache Spark、Apache Parquet、Kafka 和 Hudi 是 Apache Software Foundation 在美国和其他国家的注册商标或商标。 Presto® 是 LF Projects, LLC 的注册商标。