云巨头AWS已经选择通过表格式Apache Iceberg将自家Redshift数据仓库向数据湖延伸,IBM旗下的Netezza上周也做出了相同的决定。
AWS透露称正对Netflix几年前推出的Iceberg表格式提供支持预览,允许用户通过Redshift对外部数据湖中的Apache Iceberg表执行分析查询。
“您现在可以使用Amazon Redshift查询AWS Glue数据目录中的Apache Iceberg表,而其他用户或应用程序可以使用Amazon EMR、Amazon Athena和AWS Glue等符合ACID原则的服务,以安全方式对表进行数据操作。”
但随附的用户指南在细则部分也提出了相关警告,称“仅限新的Iceberg表——不支持对由Apache Parquet表转换为Apache Iceberg表的分区进行查询,也不支持在查询中包含分区列。”
AWS随后又对如何使用该系统查询其云平台以外的数据做了进一步澄清。
“Amazon Redshift允许从AWS(包括Amazon S3)中的数据湖对指向Apache Iceberg的查询提供事务一致性。要对外部数据源(包括Google BigQuery或Google Cloud Stoarge等)运行分析,AWS客户可以使用Amazon Athena的预构建数据源连接器。”
AWS还表示,相关价格将根据Redshift Spectrum或Redshift Serverless的具体使用量而定。
Iceberg阵营迎来的另一位新成员是IBM Netezza,这是一款最初基于PostgreSQL且几乎已经被市场遗忘的数据仓库。我们最后一次听到Netezza的消息,还是在IBM于2010年收购Netezza并将该系统迁移至云端的时候。
IBM软件工程师Mike DeRoy在本周的博文中表示,用户可以使用IBM的watsonx.data智能湖仓技术创建Apache Iceberg格式的表,“允许任何兼容的引擎访问该数据,能够防止您对任何特定引擎产生供应商锁定”。
“IBM正将一流智能湖仓集成引入Netezza引擎,使您能够通过watsonx.data平台及其他数据湖平台查询Iceberg。”
目前,各大主流科技厂商似乎在支持哪种表格式方面存在严重分歧。面对将分析引擎引入任意位置数据这个共同的目标,Snowflake、Cloudera、谷歌,以及如今的AWS和Netezza明显站在了Iceberg一边。而微软、SAP和Databricks则选择了由Databricks创建,Linux基金会负责管理的开源表格式项目。
各家厂商都坚称,自己选择的格式更能反映客户的核心需求,借此证明其决定的合理性。他们还表示,将在未来时机成熟时支持更多格式选项,包括Apache Hudi。
唯一没有明确表态的就只剩下甲骨文了。本月早些时候,甲骨文方面表示正扩展其MySQL HeatWave以查询对象存储中保存的数据。当然,这里指的还是甲骨文自己的对象存储方案。但甲骨文也提到,有计划在未来支持更多开放表格式,可能会从Iceberg和Delta Lake起步。
好文章,需要你的鼓励
在基于Chiplet的架构中,可观测性正成为系统设计的关键缺失环节。多位半导体行业专家指出,AI可从硅层遥测数据中挖掘价值,但前提是架构须提供一致的检测手段、近传感器数据压缩及可编程采集能力。专家们强调,多供应商Chiplet生态系统需要标准化、安全的遥测模式,以实现跨芯片、封装和互联域的故障定位,同时保护敏感运营数据。目前,AI在遥测分析阶段已展现出显著价值,但可观测性的扩展本质上仍是架构问题。
这项研究系统比较了四种AI图像分词策略在640000张星系图像上的表现,发现重建质量与物理属性预测能力之间存在根本性解耦,为天文基础模型的分词器选择提供了实验依据。
生命科学企业在全渠道战略和AI平台上投入巨大,但成效往往不尽如人意。问题根源不在于技术本身,而在于组织架构、数据治理和工作方式未能同步演进。许多转型项目止步于试点阶段,原因是各部门数据孤立、职责不清。要实现从传统CRM向智能互动的真正转型,企业需优先建立统一的数据基础和跨团队协作机制,并将AI能力嵌入日常工作流程,而非将其视为独立模块。
阿里Qwen团队研究如何将大模型的规模化训练思路迁移到机器人操作领域,通过统一多机器人表示与38100小时数据预训练,让机器人在陌生场景和陌生机型上也能完成复杂操作任务。