做a的网站有哪些,苏州做网站设计,网站恶意点击软件,果合gohe网站建设大模型、实时需求高涨 AGI 时代#xff0c;以 ChatGPT、Midjourney 等为代表的大模型迅速应用加速了 AI 普及#xff0c;越来越多的企业选择搭建自己的 AI 基础设施#xff0c;训练行业大模型。 另一方面#xff0c;企业为了在瞬息万变的市场环境中更快的做出商业决策…大模型、实时需求高涨 AGI 时代以 ChatGPT、Midjourney 等为代表的大模型迅速应用加速了 AI 普及越来越多的企业选择搭建自己的 AI 基础设施训练行业大模型。 另一方面企业为了在瞬息万变的市场环境中更快的做出商业决策正在将数据平台从离线转向实时数据平台。“双十一 ”和春晚直播实时大屏、银行和证券交易行为实时监控、电商和短视频的实时个性化推荐等只是全行业在线化的冰山一角。 AI 实时俨然成为了企业数据平台无法避免的技术焦点。那么如何让企业数据平台拥抱AI实时的双重能力为什么难实现
对于现阶段的大数据平台和传统数据仓库等企业数据平台姑且不论同时整合 AI 实时单独的 AI 平台或者实时数据平台都不得不通过复杂架构耗费大量资源和人力来实现。我们不妨先来分别看看现在的 AI 和实时架构是如何实现的。
AI 与数据平台
机器学习和人工智能的模型训练采用结构化数据和非结构化数据。结构化数据价值非常高数据质量也非常好因此有些 AI 问题主要基于结构化的数据建模。一个很典型的例子就是银行基于结构化数据面向个人客户开发的信用评分卡既有可解释性又能满足实时的信用评估。
那么传统数仓的大量结构化数据该如何被用于训练 AI 模型呢常见的方式是当机器学习平台需要访问数据集时需要先通过 JDBC 或者外部表的形式把数据从数据仓库导出到分布式存储中然后再并行处理这些数据用以进行模型训练和分析。在大规模数据处理场景中这种不断导出数据的方式显然是不现实的因为导出 TB 或者 PB 级别的数据通常得花好几个小时甚至几天的时间既费力又费时。
在过去几年中在业界产生广泛影响力的机器学习和 AI 模型几乎都是从非结构化数据中获取的。尽管在传统数据仓库中可以将非结构化数据视为简单的文本或二进制类型 (TEXT、VARCHAR、BLOB)然而通过这种方式训练AI模型效率低下同样需要从数据仓库中导出数据后再做建模。
因此企业逐渐选择数据湖这种更加开放的形态来训练 AI 模型。结构化数据和非结构化数据文本和图像等直接进入数据湖以数据湖开放的存储格式存储如 ORC 和 Parquet使用开源工具去直接操作数据。传统数据湖平台通常由 Hadoop 实现因为 Hadoop 的局限性比如缺乏事务支持缺乏很好的数据治理方法等等数据湖都难免形成数据沼泽。
实时数据平台
传统数据平台不仅在 AI 模型的支持上出现了诸多问题在实时数据处理方面也面临着极大挑战。
传统数据平台的数据处理流程一般是这样的。首先从业务系统 CRM、ERP 或者其他数据源把这些业务数据收集过来然后经过离线数据 ETL 对数据进行数据清洗、数据加工。在这个过程中会涉及数据建模和分层最终会把加工后的数据提供给 BI 工具或者写到数据库并推到一个在线服务系统供用户进行访问这些用户包括用户、运营人员或管理团队等等。
我们可以发现即便在没有做实时数据处理的情况下这样的数据处理链路就已经很冗长了。然而当我们不解决既有离线问题的情况下就向实时转型问题将更加复杂。
实时数据是如何处理的
目前主要采用传统 Lambda 和 Kappa 架构。以 Lambda 架构的实现方法为例Lambda 以传统的离线数仓为主然后引入了实时数据的处理链路。T1 数据仍然是走传统离线数仓链路然后再加上一个实时的数据链路再把这些实时数据和离线数据汇总到一起然后再通过一个服务层提供数据服务对外提供的服务可能是点查询也可能是做复杂分析。 离线链路用 Hive/Spark实时用 Flink。但在实际的落地中如果需要引入实时查询可能要再加上 ClickHouse/Drill/Presto如果需要做数据的离线归档还需要 Hive为了满足一些高并发点查询需求还要再引入了 HBase 和 MySQL。引入这么多产品组件本质原因还是缺少一个在并发、性能和开放性兼顾的产品。
因此 Lambda 架构并没有从源头上解决传统离线数仓的问题而是在传统离线数仓上加了一条链路让整个系统变得更加复杂。数据可能会存两份或者存多份实时链路和离线链路数据也不统一。除此之外整个架构维护起来是非常复杂的学习和开发成本比较高。
如何破局
为了实现用更丰富的数据源训练 AI 模型我们以极高的代价将数仓的数据导出后再并行处理为了实现实时数据处理我们不惜选择冗长的数据处理链路造成多份数据和多个计算引擎烟囱林立。这些痛点都将我们引向对一个问题的思考我们能不能只用一份数据精简计算引擎
答案是可以的。
当下存储和计算的数据无非是结构化、非结构化和流式数据。破局的第一步就是在数据的存储方面采用开放格式的一份数据如 Parquet、ORC、Hudi 等。各个计算引擎都使用开放的数据格式如 ORC 或 Parquet 等数据以开放文件格式被写入数据平台之后就能被多个引擎多次直接读取和使用。
有了存储的开放性在计算引擎方面我们就可以尽量优化和减少计算引擎的数量并针对结构化数据、非结构化数据和流式数据选用各具优势的计算引擎● 针对流数据的计算采用常见的 Flink● 针对非结构化数据和机器学习可以采用 Spark● 针对结构化数据需要兼容开放数据格式兼顾实时查询、离线分析、高并发和高可用的分析引擎比如偶数的 OushuDB。 至此开放格式一份数据多个引擎的架构初步形成这样的“一数多擎”架构形成了可以破局当前企业数据困境的方案——实时湖仓Realtime Lakehouse。
“一数多擎”是我们在多个行业的湖仓一体项目落地中不断迭代的最佳实践。企业在选择多个引擎时一定需要基于“化繁为简”和“扬长避短”原则比如 OushuDB 可以完全实现Hive、Presto、ClickHouse、HBase 等引擎的功能引入 OushuDB 后就不需要再依赖这些引擎这样可以极大简化系统开发和运维的复杂度。Flink 擅长流处理就使用 Flink 做流处理而不是使用 Flink 来做 SQL 查询Spark 擅长做机器学习就使用 Spark 做机器学习而不是使用 Spark 来做流处理和 SQL 查询。Hive 查询慢就不必再保留 Hive可以使用 OushuDB 取代。
开放的“一数多擎”带来哪些价值
●首先就是开放本身的价值开放直接解决了当前数据平台在AI模型训练和实时数据处理过程中多份数据造成的数据冗余和数据不一致。同时开放的格式让湖仓一体很容易获得最优的 SQL 引擎、ETL、流处理引擎和机器学习引擎的支持。●其次一份数据整合了非结构化数据和结构化数据存储图像、文本可以直接用于 AI 模型训练结构化数据也无需被多次读取、复制和导出。●再次“一数多擎”必然要求彻底的存算分离架构让企业湖仓平台不受集群规模的限制动态扩展集群规模。
● 另外由于过往实时、离线数据处理链路极其冗长和复杂造成数据建模、元数据管理、数据治理都难以高效的实施“一数多擎”精简了不必要的引擎组件整个架构变得简洁既为数据建模、数据治理提供了平台基础又让学习、开发和维护成本都大幅下降。
总结
IDC 调研显示企业在数字化商业过程中更加关心利用数据和信息来创造自身竞争优势因此实现底层统一的数据管理是进行上层资产管理和业务决策分析的关键。 以往由于技术水平的制约和方案的局限性我们难以实现底层统一的数据管理。因此为了能用更丰富的数据源训练AI模型我们以极高的代价将数仓的数据导出为了实现实时数据处理我们不惜选择冗长的数据处理链路造成多份数据和多个计算引擎烟囱林立。 于是才有了我们现在讨论的问题及对应总结出的方案基于开放的数据格式存储一份数据避免数据冗余有针对性的精选优势引擎组件通过具备“一数多擎”架构的实时湖仓方案我们可以同时解决 AI 和实时数据处理在过去所面临的困境逐步形成完整的企业数智生态。
