本文整理自火山引擎开发者社区技术大讲堂第四期演讲，主要介绍了数据湖仓开源趋势、火山引擎 EMR 的架构及特点，以及如何基于火山引擎 EMR 构建企业级数据湖仓。
数据治理工作有很多挑战，最主要的一点是落地比较困难。 首先，治理工作中与业务有一定的矛盾。 第二，治理涉及的组织和管理难度大。 第三，规范“人”的动作难度大，治理过程中，需要依靠人来推进和执行，人员能力参差不起，组织文化、目标也存在不对齐的情况。 第四，缺乏适配性强的产品工具。因为治理工作范围广，链路长，并且涉及跨部门、跨系统的目标对齐，需要一个完备的产品平台。
『一次开发，多端运行』是研发同学所追求的极致效率，如何用一套代码逻辑解决 Android / iOS 双端的开发向来是客户端工程师们所头疼的问题。而在当前的跨平台开发范式中，由 Google 开源的 Flutter 成为了最受欢迎的方案之一。 在 2022 年 5 月举办的 Google I / O 大会上，Flutter 3.0 版本正式发布，开发者可以通过一个代码库立足 iOS、Android、Web、Windows、macOS、Linux 六大平台，大会数据显示目前全球已经有超过 50 万应用由 Flutter 构建完成。 字节跳动是 Flutter 的深度用户，早在其开源之初便投入了深度的使用、优化与反馈共建。截至 2021 年，字节跳动有超过 70 多款 App 使用 Flutter 开发，累计有超过 600 多位 Flutter 开发者。针对 Flutter 落地过程中出现过的包体积过大、性能收益不明显等问题，字节跳动技术团队均做了大量的优化，并向社区提报大量 PR 并被成功 merge。
大数据架构向云原生演进是行业的重要趋势，火山引擎协助关键金融客户在大数据云原生方向进行了深度实践，形成了整体解决方案，本文将分享火山引擎云原生大数据在金融行业的实践。
对于 FEer 来说，JavaScript 是单线程，同一时间只能执行一个任务，这种模式的好处是实现起来比较简单，执行环境相对单纯；坏处是只要有一个任务耗时很长，后面的任务都必须排队等着，会拖延整个程序的执行。常见的浏览器无响应（假死），往往就是因为某一段 JavaScript 代码长时间运行（比如死循环），导致整个页面卡在这个地方，其他任务无法执行。对于计算类型的任务，需要使用到 CPU，就只能等待任务执行完毕；但是对于很多时候 CPU 都是闲着的，比如在执行 IO 操作（输入输出），ajax 请求，文件读写等，这些操作 CPU 完全可以不管 IO 操作，可以继续往下执行其他任务。异步机制就是为了解决这个问题，这种机制在 JavaScript 内部采用的事件循环机制（Event Loop）。
React 18 提供了一种新的 SSR 渲染模式： Streaming SSR。通过 Streaming SSR，我们可以实现以下两个功能： Streaming HTML：服务端可以分段传输 HTML 到浏览器，而不是像 React 18 以前一样，需要等待服务端渲染完成整个页面后才返回给浏览器。这样，浏览器可以更快的启动 HTML 的渲染，提高 FP、FCP 等性能指标。 Selective Hydration：在浏览器端 hydration 阶段，可以只对已经完成渲染的区域做 hydration，而不需要等待整个页面渲染完成、所有组件的 JS bundle 加载完成，才能开始 hydration。这样可以更早的对已经完成渲染的区域做事件绑定，从而让页面获得更好的可交互性。
技术永远是在“更新”或“替换”中得到发展。 在大数据行业里，2006 年 Hadoop 的诞生，给我们带来了变革意义的改变，大数据生态组件也开始层出不穷。各种不同体型的企业都喜欢选择开源大数据软件来搭建自己的系统，无论是先前十分繁荣的 Hadoop，还是后来涌现出来的 Kafka、Flink 等，都被广泛地使用着。 十多年来，这些系统经历了多轮技术洗礼，我们也随之需要根据新的技术潮流不断地进行调整甚至做技术转型。以 Hadoop 三大组件来说，计算引擎 MapReduce 基本被 Spark 取代。在数据上云的时代，对象存储也取代了一部分 HDFS 文件系统。近几年，云原生又火了起来，行业里再次开始了对大数据体系的云原生改造，同时 K8s 的流行，也让同为资源管理的 YARN 地位越来越尴尬。 然而，过去的技术体系在很多企业系统里仍发挥着很重要的作用，在技术更新迭代的时候，业务不能随意变动，那么我们在新旧技术共存的条件下，如何发挥新技术的最大潜力？
