您可以在 AWS 大数据博客上找到有关 EchoStar 如何通过其 5G 开放式 RAN 网络在接
EchoStar如何在其5G Open RAN网络中每天实时处理TB级数据
关键要点
EchoStar利用Amazon Redshift无服务器流式引入功能，每天从超过150个MSK主题中实时处理超过10TB的数据。该解决方案通过多仓库架构和实时数据共享显著提高了数据处理性能和可扩展性。采用“稍后解析和转换”的策略，减少了数据延迟，将其从两三天缩短为平均37秒。在这篇文章中，作者与来自DISH Wireless的Balaram Mathukumilli Viswanatha Vellaboyana和Keerthi Kambam共同撰写。EchoStar是一家为美国的居民和商业客户提供电视娱乐、无线通信和获奖技术的连接性公司，最近在AWS公共云上部署了第一个独立的、云原生的Open RAN 5G网络。
Amazon Redshift Serverless是一个完全管理的、可扩展的云数据仓库，可加速您的洞察时间，提供快速、简单且安全的分析。通过使用Amazon Redshift数据共享，您可以在不移动或复制数据的情况下，跨组织、AWS区域甚至第三方提供商之间共享数据。此外，它允许您使用不同类型和大小的多个仓库来执行提取、转换和加载ETL作业，从而根据写入工作负载的性价比需求进行微调。
蓝快加速器安卓版下载官网使用Amazon Redshift流式引入功能，您可以以近实时的速度更新分析数据仓库。Redshift流式引入通过允许您直接在数据流上创建物化视图来简化数据管道。通过使用Amazon Redshift，您可以使用SQL连接并直接从数据流如Amazon Kinesis数据流或Amazon Managed Streaming for Apache Kafka中引入数据，直接拉取数据到Amazon Redshift。
EchoStar利用Redshift流式引入功能，从其Open RAN 5G网络的150多个MSK主题中，每天实时引入超过10TB的数据。本文概述了如何利用Amazon Redshift进行实时数据分析，以及EchoStar如何以每秒数百兆字节的速度引入数据。随着网络中数据源和数据量的增加，EchoStar从单一的Redshift无服务器工作组迁移到多仓库架构，并启用实时数据共享，这提高了数据引入和分析的性能。
“通过采用‘稍后解析和转换的策略’以及建立具有多集群架构的Amazon Redshift数据仓库农场，我们利用了Amazon Redshift在直接流式引入和数据共享方面的强大功能。我们的数据延迟从两三天降低到平均37秒。此外，Amazon Redshift直接流式引入支持超过150个MSK主题，使我们实现了更好的可扩展性。”
Sandeep Kulkarni EchoStar无线OSS平台软件工程副总裁
EchoStar案例分析
EchoStar需要为下游消费者和交互式分析应用程序提供近实时的5G网络性能数据。这些数据来自5G网络EMS可观测性基础设施，并通过AWS服务如AWS Lambda和AWS Step Functions近实时流式传输。这种流式数据生成了许多小文件，大小从字节到千字节不等。因此，需要像Amazon MSK这样的消息系统来有效整合这些数据。
EchoStar每天处理来自其消息系统的150多个MSK主题，每个主题含有约10亿行数据。这导致了平均每天10TB的数据量。为了利用这些数据，EchoStar需要可视化、进行空间分析、与第三方数据源进行连接，开发终端用户应用程序，并使用洞察力对其地面5G网络进行近实时改进。EchoStar需要一个解决方案来做到以下几点：
优化对150多个MSK主题的解析和加载，以便下游工作负载能够同时运行而互不影响。允许数百个查询并行运行以满足期望的查询吞吐量。随着用户基础的增加，实现无缝扩展能力并保持成本效率。解决方案概述
EchoStar与AWS合作，从单一的Redshift无服务器工作组迁移到多仓库的Amazon Redshift架构。新架构通过将流式引入和ETL作业与多个Redshift计算实例的分析工作负载分离，实现了工作负载隔离。同时，它通过对数据仓库之间的数据使用单一副本，提供实时数据共享。该架构利用AWS的能力来扩展Redshift流式引入作业，并隔离工作负载，同时保持数据访问。
以下图示展示了高层次的无服务器架构和整体数据管道。
该解决方案包含以下关键组件：
主要ETL Redshift无服务器工作组 一个392 RPU的主要ETL生成工作组。次级Redshift无服务器工作组 不同规模的额外生成工作组，用于根据性价比需求分配和扩展150多个MSK主题的近实时数据引入。消费者Redshift无服务器工作组 一个消费者工作组实例，用于使用Tableau进行分析。为了高效并行加载多个MSK主题到Redshift无服务器中，我们首先识别了数据量最大的主题，以确定次级工作组的适当size。
我们最初将系统大小设置为64 RPU的Redshift无服务器工作组。在此基础上，我们引入了少量的MSK主题，并创建了相关的流式物化视图。我们逐步添加更多的物化视图，评估整体引入成本、性能和延迟需求。在单个工作组内进行基准测试后，我们为后续在多个工作组中引入剩余的MSK主题奠定了坚实的基础。
除了多仓库方法和工作组大小外，我们通过将引入作业分为两个步骤，优化大规模数据量的引入，平均延迟为37秒：
流式物化视图 使用JSONPARSE从MSK主题引入数据到Amazon Redshift。扁平化物化视图 将解析和变换作为第二步骤，从相应的流式物化视图读取数据。以下图示描绘了高层次的方法。
最佳实践
在实施此解决方案时，我们观察到的一些最佳实践包括：
基于以下三个关键因素进行初步的Redshift无服务器工作组大小评估：每个MSK主题每秒的记录数量每个MSK主题的平均记录大小期望的延迟SLA此外，我们仅为特定MSK主题创建一个流式物化视图。针对单个MSK主题创建多个物化视图会降低引入性能，因为每个物化视图都会成为该主题的消费者，并共享Amazon MSK带宽。在定义流式物化视图时，我们避免使用JSONEXTRACTPATHTEXT进行预处理，因为该函数逐行操作数据，会显著影响引入吞吐量。相反，我们采用了JSONPARSE与CANJSONPARSE函数相结合，以最低延迟引入流数据并防止错误。以下是我们用于MSK主题的示例SQL查询因安全原因，实际数据源名称已被屏蔽：sqlCREATE MATERIALIZED VIEW ltsourcenamegtstreamingmvw AUTO REFRESH YES ASSELECT kafkapartition kafkaoffset refreshtime CASE WHEN CANJSONPARSE(kafkavalue) = true THEN JSONPARSE(kafkavalue) END AS KafkaData CASE WHEN CANJSONPARSE(kafkavalue) = false THEN kafkavalue END AS InvalidDataFROM externalltsourcenamegtltsourcenamegtmvw
我们保持流式物化视图简单，并将所有转换如展开、聚合和条件表达式移动到后续步骤作为扁平化物化视图。以下是一个示例SQL查询，我们用于通过读取先前步骤中创建的流式物化视图来扁平化数据实际数据源和列名因安全原因已被屏蔽：sqlCREATE MATERIALIZED VIEW ltsourcenamegtflattenmvw AUTO REFRESH NO ASSELECT kafkadataltcolumn1gtinteger AS ltcolumn1gt kafkadataltcolumn2gtinteger AS ltcolumn2gt kafkadataltcolumn3gtbigint AS ltcolumn3gt FROM ltsourcenamegtstreamingmvw
为了确保流式物化视图可以不断从MSK主题向Amazon Redshift引入数据，它们被设置为自动刷新。扁平化物化视图则根据SLA要求使用Amazon Managed Workflows for Apache AirflowAmazon MWAA进行手动刷新。我们在流式物化视图中未定义任何排序键，以进一步加速引入速度。最后，我们使用SYSMVREFRESHHISTORY和SYSSTREAMSCANSTATES系统视图来监控流式引入刷新和延迟。欲了解更多最佳实践和监控技术，请参阅使用Amazon Redshift流式引入与Amazon MSK实施近实时分析的最佳实践。
结果
EchoStar通过此解决方案在其5G Open RAN网络中看到了性能和可扩展的提升。
性能
通过在多个Redshift无服务器工作组之间隔离和扩展Redshift流式引入刷新，EchoStar满足了其延迟SLA要求。我们使用以下SQL查询来度量延迟：
sqlWITH currqry AS ( SELECT mvname CAST(partitionid AS int) AS partitionid MAX(queryid) AS currentqueryid FROM sysstreamscanstates GROUP BY mvname CAST(partitionid AS int))SELECT strmmvname tmppartitionid MIN(DATEDIFF(second streamrecordtimemax recordtime)) AS minlatencyinsecs MAX(DATEDIFF(second streamrecordtimemin recordtime)) AS maxlatencyinsecsFROM sysstreamscanstates strm currqry tmpWHERE strmqueryid = tmpcurrentqueryid AND strmmvname = tmpmvname AND strmpartitionid = tmppartitionidGROUP BY 1 2ORDER BY 1 2
当我们将前面的查询进一步聚合到mvname级别去除唯一标识MSK主题中分区的partitionid时，我们发现，在64 RPU的Redshift无服务器工作组中逐日的数据性能结果如下表所示实际的物化视图名称因安全原因已被哈希处理，因为它映射到外部供应商名称和数据源。
SNostreamnamehashminlatencysecsmaxlatencysecsavgrecordsperday1e022b6d13d83faff02748d3762013c161863958052a8cc0770bb055a87bbb3d37933fc0116186720769319413c1fc8fd6f8e5f5ae009515ffb2458583564732c2e0b3eb76c070415416c09ffe03271249417558b4e1ffad42bf77114ab86c2ea91d634149927136670e627d11eba592153d0f08708c0de551218197e15713d6b0abae2b8f6cd1d2663d945311487680068234eb3af376b43a525b7c6bf6f888066445666938e97a2f06bcc57595ab88eb8bec57710045666104c345f2f24a201779f43bd585e53ba91210193496911a3b4f6e7159d9b69fd4c4b8c5edd061014365086961287190a106e0889a8c18d93a3faafeb13691405072713b1388bad6fc98c67748cc11ef2ad352511850914cf8642fccc7229106c451ea33dd64d28661344225415c3b2137c271d1ccac084c09531dfcd2974125154951668676fc1072f753136e6e992705a4d296959565170ab3087353bff28e952cd25f5720f437711277582218e6b7f10ea43ae12724fec3e0e3205c398329647151993e2d6e0063de948cc6ce2fb5578f2454519692712088cba4fffafd085c12b5d0a01d0b8446471251376821d0408eae66121d10487e562bd481b948571252522122de552412b4244386a23b4761f877ce52527254633239480a1a4444250a0bc7a3ed67eebf358961252288224db5bd3aa8e1e7519139d2dc09a89a7601031251868825e6541f290bd377087cdfdc2007a2007183176346585266f519c71c6a8a6311f2525f38c233d78
