目录质量对流媒体视频服务的重要性Databricks QoS解决方案概述视频QoS解决方案体系结构为分析做好准备创建仪表板/虚拟网络操作中心创建（接近）实时警报下一步：机器学习Databricks流式视频解决方案入门质量对流媒体视频服务的重要性随着传统付费电视继续停滞不前，内容拥有者已经接受了直接面向消费者（D2C）订阅和广告支持的流媒体服务，以使他们的内容库货币化。对于那些整个商业模式都围绕着生产大量内容并将其授权给分销商的公司来说，现在要转变为拥有整个玻璃到玻璃的体验，就需要新的能力，例如为向消费者提供内容而构建媒体供应链，支持各种设备和操作系统的应用程序，以及执行客户关系职能，如帐单和客户服务。每月提供视频点播服务（SVOD）和视频点播服务，订阅服务运营商需要每月/每周/每天向用户证明其价值（观看者离开AVOD（广告支持的视频点播）的障碍甚至更低——只需打开不同的应用程序或频道）。流媒体视频质量（包括缓冲、延迟、像素化、抖动、丢包和空白屏幕）的一般质量，无论是增加用户流失还是降低视频占用，都有显著的业务影响。当你开始流媒体时，你会意识到有太多的地方会出现中断，观众体验可能会受到影响，不管是prem服务器还是云端服务器，在传输过程中，无论是CDN级别还是ISP级别，还是观看者的家庭网络；还是播放级别的播放器/客户端问题。在n x 104并发拖缆上断开的与在n x 105或n x 106处断开的不同。没有发布前测试可以完全复制真实世界的用户，以及他们在频道浏览、点击进入和退出应用程序、从不同设备同时登录等过程中，将即使是最冗余的系统也推到崩溃点的能力。由于电视的性质，在吸引最多观众的最重要、最引人注目的活动中，事情会出问题。如果你开始在社交媒体上收到投诉，你怎么知道这些投诉是针对某个用户的，还是针对某个地区或某个国家的问题？如果是全国性的，是跨越所有设备还是仅某些类型（例如，可能是原始设备制造商在旧设备类型上更新了操作系统，最终导致与客户机的兼容性问题）？当您考虑用户数量、用户正在执行的操作数量以及体验中的切换次数（服务器到CDN到ISP到家庭网络到客户端）时，识别、纠正和防止观众体验质量问题就变成了一个大数据问题。服务质量（Quality of Service，QoS）有助于理解这些数据流的意义，这样您就可以了解出哪里出了问题，哪里出了问题，为什么出了问题。最终，你可以进入预测分析，围绕什么可能出问题，以及如何在任何事情发生之前补救它。Databricks QoS解决方案概述该解决方案的目的是为任何希望改善其QoS系统的流媒体视频平台提供核心。它基于AWS实验室提供的AWS流媒体分析解决方案，然后我们在其基础上添加Databricks作为一个统一的数据分析平台，用于实时洞察和高级分析功能。通过使用Databricks，流式平台可以更快地获得见解，利用由健壮可靠的数据管道提供支持的最完整和最新的数据集；通过使用支持管理端到端机器学习生命周期的协作环境加快数据科学，缩短新功能的上市时间通过为数据工程和数据科学提供一个统一的平台，跨整个软件开发周期的运营成本。视频QoS解决方案体系结构由于视频流量高峰时段需要低延迟监控警报和高度可扩展的基础设施等复杂性，直接的体系结构选择是Delta体系结构-两种标准大数据体系结构（如Lambda和Kappa体系结构）在维护多个管道类型（流式和批处理）以及缺乏对统一数据工程和数据科学方法的支持。Delta体系结构是下一代范例，它使组织中所有类型的数据角色都能更高效地工作：数据工程师无需在批处理和流式处理之间进行选择，就可以以经济高效的方式连续开发数据管道数据分析员可以获得接近实时的见解，并更快地回答他们的BI查询数据科学家可以开发出更好的机器学习模型，使用更可靠的数据集，并支持时间旅行，以促进可重复的实验和报告图1数据管道使用"多跳"方法的Delta体系结构使用Delta架构编写数据管道遵循多层"多跳"方法的最佳实践，在这种方法中，我们逐步向数据添加结构："青铜"表或摄取表通常是原生格式（JSON、CSV或txt）的原始数据集，"银色"表表示已清理/转换的数据集，可用于报告或数据科学和"黄金"表是最后的表示层。对于纯流使用案例，在中间Delta表中具体化数据帧的选项基本上只是延迟/sla和成本之间的折衷（例如实时监视警报与基于新内容的推荐系统的更新）。图2当在Delta表中具体化数据帧时，仍然可以实现流结构这种方法中"跳数"的数量直接受下游消费者数量、聚合复杂性（例如，结构化流媒体对链接多个聚合施加了某些限制）和运营效率的最大化。QoS解决方案体系结构集中于数据处理的最佳实践，而不是一个完整的VOD（视频点播）解决方案—一些标准组件（如"前门"服务Amazon API网关）避开了高层架构，以保持对数据和分析的关注。图3 QoS平台高层架构为分析做好准备QoS解决方案中包含的两个数据源（应用程序事件和CDN日志）都使用JSON格式，非常适合于数据交换–允许您表示复杂的嵌套结构，但不可扩展且难以维护作为data lake/analytics系统的存储格式。为了使数据可以在整个组织中直接查询，青铜色到银色的管道（"让每个人都可以使用您的数据"管道）应该将任何原始格式转换为Delta格式，并包括任何监管机构要求的所有质量检查或数据屏蔽。视频应用程序事件基于该体系结构，视频应用事件被直接推送到Kinesis流中，然后被摄取到Delta-append-only表中，而不会对模式进行任何更改。图4应用程序事件的原始格式使用这种模式可以让大量的下游消费者以流模式处理数据，而不必缩放Kinesis流的吞吐量。作为使用增量表作为接收器的副作用（支持优化！），我们不必担心处理窗口的大小会影响目标表中的文件数，这在大数据世界中被称为"小文件"问题。时间戳和消息类型都是从JSON事件中提取的，以便能够对数据进行分区，并允许消费者选择要处理的事件类型。再次，将事件的单个动态流与Delta"events"表结合在一起，降低了操作复杂性，同时使高峰时段的缩放更容易。图5所有的细节都是从JSON中提取出来的Silver表CDN日志CDN日志被传送到S3，因此处理它们的最简单的方法是Databricks Auto Loader，它在新数据文件到达S3时递增并高效地处理它们，而不需要任何额外的设置。自动加载器_df=spark.readStream.format（"云文件"）\.选项（"cloudFiles.format"，"json"）\.选项（"cloudFiles.region"，区域）\.load（输入位置）anonymized_df=自动加载程序_数据框选择（"*"，ip匿名器（'requestip'）。别名（'ip'））\.drop（'requestip'）\.withColumn（"origin"，将\u ip_映射到\u位置（col（'ip'））匿名化_数据流写入流\.option（'检查点位置'，检查点位置）\.format（'delta'）\.table（silver_数据库+'.cdn\u logs'）由于日志包含IP（根据GDPR法规被视为个人数据），"使您的数据对所有人都可用"管道必须包括匿名步骤。可以使用不同的技术，但是我们决定只从IPv4中去掉最后的八位字节，从IPv6中去掉最后80位。最重要的是，该数据集还包含了原产国和ISP提供商的信息，这些信息将在稍后的网络运营中心用于本地化。创建仪表板/虚拟网络操作中心流媒体公司需要尽可能接近实时地监控网络性能和用户体验，跟踪到单个级别，并能够在段级别进行抽象，轻松定义新的段，例如由地理位置、设备、网络和/或当前和历史查看行为定义的段。对于流媒体公司来说，这意味着采用电信网络的网络运营中心（NOC）概念来监控流媒体体验的健康状况