第339章 奈飞有多牛哔（1 / 2）

杨振并没有过多解释流媒体平台的优势和前景。

技术上的事儿，也确实不是几个小白，就能轻易听懂的。

但不可否认的是，却恰恰就是技术，在引领着几乎每一个行业的前进和更迭。

简单、便捷、更好的体验、更优质的服务、更人性化的享受……这些，才是改变人类日常生活的关键因素。

而这一切，其实无一例外，都是建立在技术日益完善、不断发展基础之上的。

流媒体平台，自然也不会例外。

而后世，不管是国内的爱奇异、腾信视频、友酷，还是国外的奈飞、Hulu、Amazon Prime Video、HBO Max、Apple TV+、迪士尼的三件套等……

能从这一领域竞争中杀将出来的，就没有一個是在技术上的毫无建树的。

当然了，这会儿国内，还处于起步阶段，国外也仅仅只有两个还过的去的对手，那就是奈飞和Hulu。

而且正如杨振所说，这俩目前也就是在摸索着前进，还远远算不上对手。

无非也就是觉得依托互联网，应该是一个很不错的未来风口而已。

但究竟方向在哪儿，需要从哪些方面去实现，未来又是什么样子的……那就是两眼一抹黑了。

嘉禾的微视频却是不一样的，因为有杨振嘛！

所以，对于流媒体平台以后的发展情况，以及在技术、架构、组织和文化上的趋势走向，几乎可以说是一目了然的。

后世有无数人都在推崇苹果、谷歌、英伟达在科技领域的创新。

但其实在杨振眼里，其实奈飞在这些方面，也同样做的一点儿都不差。

比如微服务、微服务技术栈的核心组件、开源战略、公有云战略、云平台服务、云原生架构、数据仓库、容器技术、发布管道Paved Road、反脆弱架构理念、组织架构Bus Dev Ops、架构+中间件+运维+大数据闭环的云平台工程……

每一个单独拎出来，其实都算不上有多么亮眼，甚至有些，还带着些反常规的属性。

但你只要稍微深入了解一下，就会感慨它的强悍了。

比如后世，它在移动和Web上，用的是Swift和Kotlin来构建原生移动app，用React构建Web应用；

前后端通信用的是Graph QL；

后台服务使用了ZUUL、Eureka、Spring Boot框架技术；

数据库用的是EV cache、Cassandra、Cockroach DB等数据库；

消息/流处理用的是Apache Kafka、Flink；

视频存储用的是S3和Open ect；

数据处理上，Flink和Spark做数据处理，Tableau做可视化、Redshift用于结构化数据仓库；

CI/CD上使用了多种工具，比如JIRA、fluence、Pager Duty、Jenkins、Gradle、onkey、Spinnaker、Altas等去完成……

这其中，绝大多数可都是奈飞自己搞出来的，而将它们组合在一起，所展现出来的能量，也是足以让人瞠目结舌的。

这，就是奈飞赖以成名，用以搜集影音大数据背后的数据工程技术架构了。

这是一个为了支持全球影音流媒体，而搭建的一个庞大的基础架构。

有专门的团队，负责将上千亿流媒体时长的数据，转换成各种分析洞察，以此决定奈飞怎么去为客户，推荐更合适的视频。

而数亿客户，通过数千种不同类型的设备和软件，产生的事件资讯，更是多达百万种。

所以如何将这些资讯，汇集整理成容易理解的合理形式，以支持各种个性化的应用，以及分析的需求，就是一项很大系统工程。

所以奈飞从2007年，推出线上视频流媒体服务开始，就在打造自己的数据仓库系统，并陆续研发出了许多数据技术和工具，用来支持各种数据工程实务上的需求。

从内容绩效评估、观众理解分析、程序化发展战略等各方面，去推动整个数据工程的发展。

整个数据工程技术架构的核心原则，其实很简单，那就是要让常见需求更容易进行，而且可以兼顾到不同层级的定制化需求。

但这也就决定了，很多任务和工具，都需要由他们自己去开发。

要知道，数据工程技术架构中最典型的两大数据流程，就是批处理和流媒体处理。

这也是企业常见的两种数据流程。

但想要全靠自身去研发，那难度可就太高了，但是没有办法，这事儿从外面，还真就找不到现成的，所以也只能靠自力更生了。

而批处理流程有四大关键步骤：

第一步，是数据转换和逻辑汇集处理，这里会涉及到云储存、云计算和大数据；

第二步，在数据汇集整理后，还需要一套成熟的数据品质生态圈工具，在数据品质管控、单元数据异常检测，以及审核机制管理上，确