首页 文章 精选 留言 我的

精选列表

搜索[向量化],共10000篇文章
优秀的个人博客,低调大师

黄仁勋基金会向 CoreWeave 购买 1.08 亿美元算力并捐赠给高校

据路透社 5 月 13 日报道,Nvidia CEO 黄仁勋与妻子 Lori 共同创立的慈善基金会(Jensen and Lori Huang Foundation)已向 CoreWeave 购买价值 1.083 亿美元的 AI 算力,并捐赠给大学和非营利研究机构。这是该基金会迄今为止最大规模的公开捐赠行动。 CoreWeave 成立于 2017 年,是一家专注于 GPU 云计算的基础设施提供商,也是 Nvidia 的长期合作伙伴。凭借丰富的 H100、H200 系列芯片储备,CoreWeave 已发展为全球最大的 GPU 云服务商之一,客户包括多家 AI 头部企业。与传统云厂商不同,CoreWeave 的核心差异化在于专门针对 AI 推理和训练工作负载进行硬件优化,其算力租赁模式允许客户按需调用,无需自建数据中心。 此次捐赠的时间节点值得关注。美国政府近年来对部分国家实施了严格的芯片出口管制,但通过慈善基金会向海外高校提供算力,客观上形成了一条绕过直接商业销售的路径。不过受赠机构仍需遵守美国出口法规,慈善捐赠的监管框架与商业销售存在差异,但并非完全没有限制。 高端 GPU 资源长期是学术界的稀缺品。H100、H200 等旗舰芯片的售价高达数万美元,且供货紧张,多数高校难以承担大规模采购成本。黄仁勋基金会的这笔算力捐赠,将使受赠机构能够运行数十亿参数级别的 AI 模型,涵盖大语言模型训练、科学计算、医学影像分析等领域。对于长期受制于算力不足的学术 AI 研究而言,这笔捐赠的实质意义可能超过其账面价值。 参考来源:https://in.marketscreener.com/news/nvidia-ceo-s-foundation-buys-108-million-of-ai-computing-from-coreweave-donates-it-to-researchers-ce7f5bdcd18cf521

优秀的个人博客,低调大师

快手:从 Clickhouse 到 Apache Doris, 实现湖仓分离向湖仓一体架构升级

导读:快手 OLAP 系统为内外多个场景提供数据服务,每天承载近 10 亿的查询请求。原有湖仓分离架构,由离线数据湖和实时数仓组成,面临存储冗余、资源抢占、治理复杂、查询调优难等问题。通过引入 Apache Doris 湖仓一体能力,替换了 Clickhouse ,升级为湖仓一体架构,并结合 Doris 的物化视图改写能力和自动物化服务,实现高性能的数据查询以及灵活的数据治理。 作者|快手大数据架构师 李振炜、曾斯维、周思闽 在当今这个数据洪流的信息时代下,数据已跃升为企业不可或缺的核心资产。深度挖掘并提炼数据内在价值,成为支撑企业战略决策的重要依据。在此背景下,快手建立了 OLAP 系统,该系统在快手应用极为广泛,每天承载近 10 亿的查询请求,为内外多个业务场景提供数据服务。具体场景包括: ToB 系统:商业化报表引擎、商业化 DMP、商业化磁力金牛、电商选品等 内部系统:KwaiBI、春节/活动大屏、APP 分析、数据同步、用户理解中心、APM、CDN 监控、雷达监控系统等 存在的问题 最初,快手 OLAP 系统整体技术架构由离线数据湖和实时数仓这两部分组成,离线数据湖核心引擎为 Hive/Hudi,实时数仓核心引擎为 ClickHouse。OLAP 系统数据源种类非常丰富,全面覆盖结构化、半结构化、非结构化的数据类型,这些数据同步到到数据湖进行 ODS 、 DWD、DWS、ADS 层处理,处理后的数据同步至实时数仓,由数仓对外提供 BI、报表、查询等数据服务。 虽然这套架构已在快手内部稳定运行许久,但随着需求的变化、数据的不断累积,湖仓分离这一架构带来的问题逐渐显现: 冗余存储:虽然将数据入仓到 ClickHouse 能够提高查询性能,但同时导致了数据冗余存储,影响数据就绪时间和存储效率。 资源占用: to ClickHouse 过程也会占用 ClickHouse 集群资源,不仅体现在 Clickhouse 中数据同步系统的资源消耗,且在数据写入后,ClickHouse 内部也有 Compaction 等计算资源的消耗,在高并发查询的时候,并行读写带来更显著的资源抢占问题,可能影响其他查询任务的执行效率和集群的整体性能。 治理复杂:数据工程师需要投入大量人力建立 ADS 层模型,以支持 to ClickHouse 导入工作,并需要投入额外的精力维护导入任务。此外,当报表看板下线后,对应 ADS 层和 to ClickHouse 任务还在运行,造成计算和存储资源的不必要浪费,大部分情况下需要依赖人工介入判断并终止这些任务,这无疑增加了运维管理的复杂度。 此外,随着 ClickHouse 在业务中使用越来越深,查询性能出现瓶颈。排序字段、二级索引、物化视图以及哈希字段的选择和创建对 Clickhouse 查询性能有显著影响,但局限于 Clickhouse 的语言、系统适配性等因素,开发人员的学习及操作门槛都比较高,查询调优的难度比较高。 升级目标及选型 在上述问题驱使下,快手希望引入湖仓一体架构来解决上述问题,希望数仓可直接分析湖中数据,而不需要进行繁琐复杂的数据传输,避免传输及传输过程中引发的数据问题。在该目标的指引下,快手快速锁定 Apache Doris,尽管 Apache Doris 定位于实时数据仓库,但在过去版本中 Apache Doris 一直不拘于数据仓库的能力边界,在湖仓一体方向进行了诸多探索,逐步形成了湖仓一体解决方案: 极致分析性能、助力湖仓查询加速 : 借助强大的分布式 SQL 查询引擎,Apache Doris 对 Parquet、ORC 等开发格式进行了深度适配。凭借灵活的缓存策略和物化视图能力,用户可直接在湖仓数据之上架设 Apache Doris,从而实现高吞吐和低延迟的数据分析能力。 多源联邦分析、消除数据孤岛 : Apache Doris 提供丰富的数据源连接器,可以对各种异构数据源如 Hive、Iceberg、Hudi、关系型数据库进行统一的元数据管理和映射,并可通过标准 SQL 语言进行联邦分析。 湖仓数据无缝集成、自由流转 : 结合 Doris 异步物化视图能力和内置作业调度功能,用户可以便捷的基于 Doris 对湖仓数据进行分层加工处理,从而简化湖仓数据处理的复杂度。 统一数据湖的构建和计算引擎 : Apache Doris 支持主流湖仓的数据写入能力,用户可以基于 Doris 进行统一的数据写入、处理及分析,形成湖仓一体架构下的链路闭环。同时,基于 Arrow Flight 协议的高速数据通道,也进一步提升了 Doris 数据格式的开放性,用户可以在 Doris 上使用其他计算引擎支撑更丰富的计算负载。 基于 Apache Doris 的湖仓一体架构 快手基于 Apache Doris 升级为湖仓一体分析平台,新架构如图所示: 从下至上,主要分为以下几个层级: 数据加工层:数据源数据同步到数据湖仓(Hive/Hudi),并在湖仓系统中完成从 ODS 层到 DWS 层的加工处理, DWS 层到 ADS 层依赖自动物化服务实现(后文详细介绍)。 数据缓存层:ADS 层数据缓存到 Alluxio 中,以提供高性能的数据缓存访问能力。同时,元数据也缓存到元数据管理服务中,以提供统一的、稳定的元数据访问服务。 数据查询层:基于 Apache Doris 提供对 ADS 层数据的高性能查询服务。 另外,快手还开发了两个服务,使得整个分析平台更加智能化和自动化: 查询路由服务:通过分析和预估查询的数据扫描量,将超大查询自动路由到 Spark 引擎,以避免大查询占用过多的 Doris 资源。 自动物化服务:提供 DWS 层到 ADS 层按需自动化加工,智能选择排序字段、哈希字段以及更合理的物化,从而实现对复杂查询或高优看板数据的智能查询加速 在数据查询层中,使用 Apache Doris 替换原先的 Clickhouse,为快手带来了如下收益: 统一存储、简化链路: Doris 可以直接访问湖仓数据。Hive ADS 层的数据不再需要额外导入和存储在 OLAP 系统中,降低了数据维护和存储的成本,同时缩短了数据链路,提升了数据时效性。 查询性能提升: Apache Doris 本身作为高性能的计算引擎,查询性能已有较大的提升。同时结合 Doris 自身的物化视图透明改写能力,以及基于代价的查询优化器能力,可以满足不同数据分析场景下的查询加速需求。 更灵活的数据治理:结合 Doris 的物化视图改写能力和自动物化服务,可以更方便的在 ADS 层进行视图建模,对业务层屏蔽屏蔽复杂的底层实现逻辑。 接下来重点介绍整个湖仓一体架构中,缓存服务和自动物化服务方面的功能和实践经验。 缓存服务与优化 湖仓一体架构下,缓存层主要用于避免远程数据访问可能发生的网络延迟高、网络抖动、带宽不足等问题,提升数据访问的性能和稳定性。缓存的内容大致可以分为元数据缓存 和数据缓存。针对这两种缓存,快手结合 Doris 的系统架构和特性做了适配和优化。 01 元数据缓存 元数据缓存的内容包括库、表、列、分区、文件等元信息。而且元数据缓存服务,除了对缓存信息的存储外,更重要的是能够及时感知元数据的变化,如 Schema 的变化、分区的增删,文件的变更等等。通过实时的变化感知,才能保证元数据的一致性和查询的时效性。 Apache Doris 内置支持了元数据的缓存能力,支持基于 Hive Metastore Event 的元数据增量同步能力,能够很方便的提供高性能、高时效性的元数据缓存服务。然而,由于快手的元数据服务需要与除 Hive Metastore 外的其他系统(如 Alluxio)进行交互,因此无法单纯依赖 Doris 内置的元数据缓存能力。为此,快手基于 Doris 的内置方案自主研发了 Meta Server,作为统一的元数据服务。 如上图所示,Meta Server 负责监听其他服务中的元数据变化,如 Hive Metastore 中的 Schema 变化,Alluxio 中的缓存变化等,并将这些信息持久化到后端的 Meta Store 中。同时,Meta Server 会将元数据定期的推送给 Doris FE 的 Catalog 中,并通过元数据校验服务来保证两边数据得一致性。 此外,针对分区信息缓存策略,快手也结合 Alluxio 的缓存能力进行了改造。 如上图所示。Meta Server 监听到分区变化后,从访问 HDFS 获取最新的文件(Split)列表,持久化存储到 Meta Store 中,并通知 Alluxio 进行缓存预热。而 Doris 在查询时,可以直接访问 Meta Store 获取文件列表。 通过 Meta Server 服务,实现了查询引擎(Doris)、元数据服务(Hive Metastore)、数据缓存服务(Alluxio) 三方联动,在提供高效的元数据访问的同时,也提升了数据缓存的时效性。 02 数据缓存 数据缓存服务支持数据内容以文件形式存储在缓存系统中,以提供本地化的数据访问性能。 Doris 支持内置和外置两种数据缓存服务。内置数据缓存不依赖第三方系统,可以提供开箱即用的缓存能力。而快手为了能够将缓存服务能够和公司内部的其他业务系统更灵活的对接,采用了基于 Alluxio 的外置数据缓存服务,其对外提供 HDFS 兼容的 API,使得 Doris 可以很方便的对接到 Alluxio 文件系统上,像访问 HDFS 一样访问 Alluxio 中的文件。 同时,为了减少数据访问的延迟,快手在上述基础上重点开发了缓存预热功能。缓存预热是非常重要的步骤,预热后的数据存储在 Alluxio 中,提高了查询响应速度。 上一节已经介绍了缓存的元信息如何存储到 Meta Store 中。Doris 会根据查询语句中的分区条件,从 Meta Store 中获取文件列表,并通过 is_cached 字段判断数据是否已经被缓存,并自动选择从 Alluxio 或者 HDFS 中读取。 03 优化效果 通过元数据缓存,与直接从 Hive Metastore 和 HDFS 中获取相比,平均耗时由 800 毫秒降低至约 50 毫秒 ,并且查询耗时并未出现较大波动。 自动物化系统 物化视图是数据仓库系统中的一项重要能力,不仅能够提供数据的分层加工功能,还可通过透明改写实现智能查询加速。快手在内部一直使用物化视图,但初期面临数据加工链路复杂和治理成本高等问题。经过深入分析,发现根本原因在于 ADS 模型的生产和消费由不同角色负责: ADS 模型消费:主要由运营、产品、数据分析和业务研发团队使用,这些需求与业务场景深度耦合,呈现出多样化的特点。 ADS 模型生产:由数据工程师负责,他们需要深入理解业务需求,设计相应的 ADS 模型并进行生产加工,这给工程师带来了较大的理解成本。 因此在数据的分层加工上,快手自研了自动物化服务,实现消费驱动生产,主要流程如下: 数据工程师将所有数据直接交付至 DWS 层。 消费者访问 DWS 层数据表,并基于 DWS 层进行看板和报表的配置。 ADS 层实现自动物化,提供实际的数据访问,物化视图的生产逻辑对数据工程师屏蔽,全部托管在计算引擎 中。 Doris 根据查询自动选择最优的物化视图,从而实现查询加速。 物化视图包括构建、刷新和改写流程,Doris 本身支持相对完善的物化视图功能。但快手选择在外部系统(自研自动物化服务)中实现构建和刷新操作,由 Doris 支持透明改写能力,而非全部采用 Doris 能力,主要原因如下: 物化视图的生成需要大量计算资源。快手每天处理的数据量庞大,涉及数十万张表、数百 PB 的数据增量。如果全部由 Doris 处理,将消耗大量计算资源。因此,利用现有的计算集群资源(如 Spark)可以有效降低计算成本。 高优看板数据就绪需要 SLA 保障,因此物化视图的调度必须和其他系统交互,使用 Doris 内置调度方案需要对内核修改,具有较高的侵入性。 出于整体系统设计考虑,物化视图必须统一闭环到数据湖上,因此其数据必须保存在外表中。而 Doris 的物化视图目前是通过内表形式存储,以确保最佳查询效率。 Doris 内置的物化视图透明改写能力在未命中物化视图时,会降级到原表查询。然而,快手的降级策略要求将这类查询转向 Spark,以避免占用过多的 Doris 计算资源,因此需要引入额外的代码逻辑。 基于以上考虑,快手结合 Doris 的物化视图透明改写能力和自研的物化服务,实现了 KwaiMTMV 自动物化系统。该方案的优势如下: 充分利用 Doris 优化器的视图改写能力,实现灵活的查询改写功能。 利用外部系统实现物化视图生产、管理等过程,使得 Doris 能够更合理的利用计算资源,灵活对接内部服务。 接下来分别从物化发现、物化生产和物化消费这三个方面,系统的介绍 Apache Doris 和物化视图的结合使用。 01 物化发现 物化发现旨在利用不同方式,为用户推荐合理的物化视图。这里采用了如下两种方式: 专家规则:用户主动提供一些维度、指标列的定义,或通过 SQL 样例推导指标列和维度列。 维度定义,如 city,gender等。 指标定义,如 sum(time),count(distinct uid)等。 SQL 样例,如 select sum(time),count(distinct uid) from db.tbl group by city, gender; 分析历史查询:基于历史查询,自动发现物化定义。 识别出全局高频查询算子进行物化,尽可能提高物化复用率。 除了聚合指标维度,还可以自动设置索引、引利分桶字段等。 通过人工和系统自动分析两种方式,可以得到合理的物化视图定义。同时也会将这些物化视图定义存储在 Meta Server 中,并和对应的基础表做关联,以便后续的物化生产和消费。 02 物化生产 基于物化发现得到的物化视图定义,将提交至作业调度平台进行构建。调度平台会根据基表数据的变化和血缘关系,自动调度物化生产任务。同时,它还会自动调整物化生产作业的优先级,确保高优先级任务按时完成。 此外,调度平台中实现了一批 Java UDF,能够将某些指标的聚合中间结果序列化为二进制格式并写入数据文件(如 Parquet/ORC)。Doris 还可以复用这些 UDF,在查询时对二进制数据进行反序列化,从而完成对指标列的上卷运算。 03 物化消费 物化消费,主要分为物化视图注册和物化视图改写阶段。 如上图所示,在物化视图注册阶段,Doris 会定期从 Meta Store 中同步生成的物化视图信息,并在 Doris 中注册类型为 KwaiMTMV的物化视图对象。在查询改写阶段,扩展了 Doris 的物化视图改写能力,使其能够识别KwaiMTMV类型的物化视图,并进行查询改写。 如下是对 author_id指标进行去重的外表查询的改写结果示例。可以看到 Doris 将 count distinct算子改写为了更高效的 Bitmap 算子,并将目的表改写到了合适的物化视图表上。 04 使用效果 引入自动物化系统后,不仅加快了数据模型的交付速度,还显著提升了查询效率。以下是实际测试 SQL 的提升效果: 上图直观展示"数据行数"和"查询耗时"这两个维度在物化前后的对比。百万到百亿级别的数据经过物化处理后,行数压缩至少达 11 倍。在查询耗时方面,针对百亿级别以下的数据,物化后均可实现毫秒级响应,查询性能相比物化前提升至少 6 倍。 湖仓数据查询优化 除缓存服务和物化视图服务外,快手在实际使用过程中总结了一些湖仓查询的优化经验: 外表统计信息:统计信息对查询规划尤为重要,尤其是在复杂关联查询中。然而,外表统计信息存在收集成本较高,各数据源的统计信息类型和统计口径各不相同的问题。为解决该问题,可在 Spark 进程处理湖仓数据时,同步收集统计信息并将其存储在 Meta Server 中,Doris 可以直接访问这些统计信息,从而为查询优化器提供最优的查询计划。 有序文件和合适的 RowGroup 大小:在构建 Parquet 数据时,按主键排序可以确保文件数据有序。这使得谓词下推时能够最大程度地过滤无用的 RowGroup。同时,指定合适的 RowGroup 大小可以有效提高 RowGroup 的过滤率。 使用 Bucket 表:湖中的表可以按规则生成分桶(Bucket)表。Doris 利用分桶信息生成 Colocation Agg 和 Colocation Join 等优化的分布式执行逻辑,避免大量的数据 Shuffle,从而提高查询效率。 结束语 引入 Apache Doris,使快手成功从湖仓分离架构升级到湖仓一体架构。通过 Apache Doris 替换 Clickhouse,实现了统一存储和链路简化,无需数据导入、Doris 能够直接访问湖仓数据。同时,结合 Doris 的物化视图改写能力和自动物化服务,可实现高性能的数据查询以及灵活的数据治理。后续,快手将会进一步探索 Doris 在湖仓一体下的应用实践。具体包括: 公司内部的看板、报表场景将逐步由 Hive to Clickhouse 替换为 Doris 湖仓一体架构,以提升数据处理效率和查询性能。 即席查询(AD-Hoc)场景将逐步从 Presto 迁移到 Doris,并将所有分析引擎统一为 Doris,以简化技术架构并增强数据分析能力。

优秀的个人博客,低调大师

小企业难敌大黑客,美国白宫向遭勒索软件攻击的公司伸出援手

北京时间 7 月 5 日早间消息,据报道,7 月 4 日,美国白宫表示,正在联系美国佛罗里达州一宗勒索软件攻击的受害者,这一次攻击主要围绕该州一家信息技术公司。 在一份声明中,美国负责网络安全的“副国家安全顾问”安妮・纽伯格(Anne Neuberger)表示,美国联邦调查局和国土安全部网络安全部门将会联系所有确认的攻击事件受害者,根据全国性风险评估提供一些帮助。 据报道,这一次攻击围绕佛罗里达州的 Kaseya 公司,这一次攻击所造成的的影响详情尚不得而知,主要原因是该公司的软件主要提供给所谓的“被管理服务提供商”,这其实是一些外包公司,其他企业和机构会利用他们的服务完成一些企业办公室后台 IT 工作,比如安装软件升级包等。 美国 IT 公司“Sophos 集团”的首席信息安全官罗斯・迈科查(Ross McKerchar)表示,这一次勒索软件攻击的目标群体包括了学校、小型公共服务机构、旅游和休闲行业、信贷联盟,以及一些会计机构。 迈科查表示,这一次大范围的攻击再一次表明,面对经济实力强大的网络犯罪集团,中小企业和机构很难进行抗衡。 这位行业高管表示,在网络安全方面,小企业完全不是黑客集团的对手。

优秀的个人博客,低调大师

向Category添加属性)

想到要如何为所有的对象增加实例变量吗?我们知道,使用Category可以很方便地为现有的类增加方法,但却无法直接增加实例变量。不过从Mac OS X v10.6开始,系统提供了Associative References,这个问题就很容易解决了。这种方法也就是所谓的关联(association),我们可以在runtime期间动态地添加任意多的属性,并且随时读取。所用到的两个重要runtime API是: 1 OBJC_EXPORT void objc_setAssociatedObject( id object, const void *key, id value, objc_AssociationPolicy policy) 1 2 OBJC_EXPORT id objc_getAssociatedObject( id object, const void *key) __OSX_AVAILABLE_STARTING(__MAC_10_6, __IPHONE_3_1); 现在我们结合一个实际的例子来说明他们的用法。假设我们现在打算利用category对UILabel进行属性补充,添加FlashColor属性。一般我们有个原则:能用category扩展就不用继承,因为随着继承深度的增加,代码的可维护性也会增加很多。使用category可以这么做: 1 2 3 4 5 6 7 8 #import <UIKit/UIKit.h> #import <objc/runtime.h> @interface UILabel (Associate) //单单从头文件看是不是很像一个类?再看看.m文件你就知道这些都是假象了 - ( nonatomic , retain) UIColor *FlashColor; @end 1 2 3 4 5 6 7 8 9 10 11 12 13 #import "UILabel+Associate.h" @implementation UILabel (Associate)<br><br> @dynamic FlashColor; static char flashColorKey; - ( void ) setFlashColor:(UIColor *) flashColor{ objc_setAssociatedObject( self , &flashColorKey, flashColor, OBJC_ASSOCIATION_RETAIN_NONATOMIC); } - (UIColor *) getFlashColor{ return objc_getAssociatedObject( self , &flashColorKey); } @end 上面的例子有几个需要注意的地方: 1、key:我们注意到在函数签名中key的类型const void *,这表示key仅仅是一个地址,而不是字符串的内容,这也是为说明flashColorKey没有初始化的原因,因为具体指向什么内容我们无所谓,我们要的仅仅是地址!如果在setAssocaitedObject中你传入的是flashColorKey,那get方法得到的值将会是nil。正确的应该是传入地址&flashColorKey。 2、policy:这里的policy跟属性声明中的retain、assign、copy是一样的,不再赘述 3、在implement开始处的@dynamic声明。一般来说@dynamic与@synthesize都可以用来声明属性,@synthesize是默认的声明,意思是编译器在编译阶段自动为你的属性生成setter与getter;而@dynamic则告诉编译器,别慌,小子,编译阶段不用为我生成setter与getter,在runtime我已经自己实现了setter与getter。此处我们选择@dynamic。事实上,二者曾引起stackOverFlow上强烈的争论:请点这里。 下面我们再来看另一个例子,来源于APPLE GUIDE: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 #import <Foundation/Foundation.h> #import <objc/runtime.h> int main ( int argc, const char * argv[]) { @autoreleasepool { /*Seciton 0. 关联数据的Key和Value*/ static char overviewKey; static const char *myOwnKey = "VideoProperty\0" ; static const char intValueKey = 'i' ; NSArray *array = [[ NSArray alloc] initWithObjects:@ "One" , @ "Two" , @ "Three" , nil ]; // For the purposes of illustration, use initWithFormat: to ensure // we get a deallocatable string NSString *overview = [[ NSString alloc] initWithFormat:@ "%@" , @ "First three numbers" ]; NSString *videoKeyValue = @ "This is a video" ; NSNumber *intValue = [[ NSNumber alloc]initWithInt:5]; /*Section 1. 关联数据设置部分*/ objc_setAssociatedObject ( array, &overviewKey, overview, OBJC_ASSOCIATION_RETAIN ); [overview release]; objc_setAssociatedObject ( array, myOwnKey, videoKeyValue, OBJC_ASSOCIATION_RETAIN ); objc_setAssociatedObject ( array, &intValueKey, intValue, OBJC_ASSOCIATION_RETAIN ); /*Section 3. 关联数据查询部分*/ NSString *associatedObject = ( NSString *) objc_getAssociatedObject (array, &overviewKey); NSLog (@ "associatedObject: %@" , associatedObject); NSString *associatedObject2 = ( NSString *) objc_getAssociatedObject(array, myOwnKey); NSLog (@ "Video Key value is %@" , associatedObject2); NSString *assObject3 = ( NSString *) objc_getAssociatedObject(array, &myOwnKey); if ( assObject3 ) { NSLog (@ "不会进入这里! assObject3 应当为nil!" ); } else { NSLog (@ "OK. 通过myOwnKey的地址是得不到数据的!" ); } NSNumber *assKeyValue = ( NSNumber *) objc_getAssociatedObject(array, &intValueKey); NSLog (@ "Int value is %d" ,[assKeyValue intValue]); /*Section 3. 关联数据清理部分*/ objc_setAssociatedObject ( array, &overviewKey, nil , OBJC_ASSOCIATION_ASSIGN ); objc_setAssociatedObject ( array, myOwnKey, nil , OBJC_ASSOCIATION_ASSIGN ); objc_setAssociatedObject ( array, &intValueKey, nil , OBJC_ASSOCIATION_ASSIGN ); [array release]; } return 0; } 本文转自编程小翁博客园博客,原文链接:http://www.cnblogs.com/wengzilin/p/4331685.html,如需转载请自行联系原作者

优秀的个人博客,低调大师

Gartner:政府CIO须从“利旧第一”向“数据第一转变”转变

91%的首席信息官们相信数字世界对于政府来说带来了新型的风险,并且提高了风险的水平。 Gartner的调查显示,政府机构中大量旧有的技术成了阻碍首席信息官帮助自己的组织实现数据化的障碍。来自全球超过2800名首席信息官参加了2015 CIO Agenda调查,回答了关于最大的数字业务机会、威胁、策略等问题,其中有343命首席信息官来自政府部门。 Gartner 的研发总监Rick Howard表示,“政府部门旧有技术的负担让他们在创新的路上只能采用增量改进的方式,而这种情况需要的是灵活性和快速交付的方案。”他表示,“为了在政府部门中展现出‘现在就数字化、数字化第一’的领导风格,首席信息官们必须在IT管理方面放弃之前对于旧有技术束缚的那种从内而外的看法,切换成到公民体验的角度,从外而内地看待问题。这就要开启数字世界,想清楚什么是可能的——首先思考云计算、移动和情景——然后再考虑‘我们如何才能从这里走向哪里?’,利用信息和技术。” 尽管名列政府部门首席信息官在2015年关注的五大技术之一,投入旧有技术的资金规模也比较夸张,特别是联邦政府或者国家一级的政府(参见表一)。约有30%的联邦政府或者国家级政府的首席信息官面临着IT预算降低的局面。而只有15%的州、地方和区域政府机构(SLR)的首席信息官们面临着同样的挑战。但是,这些IT预算的数字呈现出强烈的地区差异。例如,来自欧洲、中东和非洲(EMEA)地区、接受调查的SLR政府部门的首席信息官中有27%的人表示他们的IT预算缩减了,而来自北美SLR的首席信息官中只有9%的人表示自己遇到了同样的情况。同样,预算缩减的情况在亚太地区所有层级的政府部门中尤为严重。 联邦和国家级政府机构(N=125),国防和情报部门(N=41),州、地方和区域政府机构(N=177),所有其他的行业(N=2,467) 资料来源:Gartner(2015年1月) 以技术为中心的模式反映在排名第一和第二的位置上,基础架构和数据中心技术在政府机构和私营企业的首席信息官心中分别位列2015年最关心的技术排名的第一第二。但是,随着厂商们在公共领域的云计算市场上斩获逐渐增加,政府IT部门非常有可能会缓慢地淡化自身作为基础架构提供者和数据中心运营者的角色。相反,他们会成为这些基础服务的经纪人,在构架IT能力的时候,从“利旧第一”转向“数据第一”的思路,并且会在所有的规划过程中问“为什么不用云计算?”在美国,这种趋势反映在州政府机构的首席信息官身上,他们会思考私有、公有、社区和混合云的优势。 Howard先生表示,“通过从管理并提供基础架构转向集中管理共享服务实体或者不同的商业供应商,政府部门的首席信息官能够以身作则,更新IT管理技术,采用在数字时代至关重要的为改变设计的思路。”他表示,“在相对比较短的时间里,云计算已经从一种理念,变成了一种可行性,变成了一种可行的选择,对于一小部分政府机构的首席信息官来说,云计算现在已经是项目的第一选择。” IT供应商在基于云计算的服务模式上正在飞速前进。与此同时,政府机构出于租赁成本和更好的灵活性的考虑,越来越适应本地域或者本国家的云计算解决方案。澳大利亚、美国和英国正在积极地推进云计算第一的战略。 Howard先生表示,“出于对成本、价值和安全性的重视,政府机构的首席信息官们应该开始将公共云作为一种首选的部署选项,如果有必要的话,按照公共云、云、公用或者在站部署的顺序为自己的业务环境做出最合适的选择。”他表示,“当由多个政府或非政府机构提供的相互关联的进程和服务——通过对情景敏感的数据交换实现——政府部门的绩效和社会成果将会真正地发生改变。” 因此,提高商业智能和分析能力继续吸引着各路首席信息官的关注。改善政府服务的机会将会越来越多地牵涉到非结构化的、更难处理的信息,例如多媒体和社交信息。按照数字化业务环境变化的速度,事后的报告所能贡献的价值会越来越少。与其尝试根据过去的数据进行优化,政府部门的首席信息官们更应该生成出向前看的预测分析能力,并且将信息和数据引导的体验结合起来,创造未来。原文发布时间为:2015年7月6日 本文来自云栖社区合作伙伴至顶网,了解相关信息可以关注至顶网

优秀的个人博客,低调大师

向万物互联进发!中国电信智慧双创物联网示范基地启动

智慧物联网正以前所未有的速度改变着我们的生活。家里的煤气、水表再也不用工作人员上门抄表,城市里的垃圾桶也会自己“汇报”垃圾情况,市政路灯会根据日照自动调整光照强度,停车场也会实时告诉你哪里还有空位置……这些智能生活场景在今年可能就会走进千家万户。 近日,中国电信浙江公司召开了主题为“物联世界共创未来”的智慧双创物联网示范基地挂牌暨窄带物联网(NB-IoT)试商用发布会,浙江电信分别与滨江区政府、浙江大学签订了双创战略合作协议,与8家行业客户签订了NB-IoT战略合作协议,共同开启了NB-IoT发展的新篇章。 在4G之后,窄带物联网(NB-IoT)成为了通信行业当下的最大热点,它将为物联网时代带来全面的蜂窝数据连接网络,具备覆盖广、多连接、功耗低、模块成本低等特点。与现有相关网络相比,具备100倍以上的区域覆盖能力。 目前,浙江电信在智慧城市、智能抄表、智能家居等业务领域,全面开展基于NB-IoT的应用试点。在智慧路灯领域,浙江电信携手华为、大云物联,在杭州黄姑山路上成功建成浙江省首个NB-IoT智慧路灯项目。在智能抄表领域,浙江电信联合金卡、先锋电子等行业龙头企业,在杭州滨江区开展智慧燃气表试点;同时,浙江电信与宁波水表合作,在宁波江北区开展智慧水表试点。此外,浙江电信还联合新昌环景科技,在绍兴成功开展基于NB-IoT的智能垃圾压缩箱试点。 目前,由浙江电信打造的省内第一张NB-IoT网络已于3月中旬实现滨江全区覆盖,预计在5月底实现杭州全市覆盖。 本文转自d1net(转载)

优秀的个人博客,低调大师

阿里云一天向厦门集美区初创企业撒了百万新年“红包”!

导读:新年一到阿里云来厦门集美区撒钱来了~为首批通过审核的初创型企业发送160万代金券,助力集美区创新创业。 1月6日,为扶持集美区创新创业企业,帮助全区产业结构转型升级、促进区域经济更好更快发展,集美区科技局召开2016年集美区阿里云服务兑现大会,对符合扶持政策的首批90家企业发放阿里云代金券共160万元。现场签到100多家企业负责人及众创空间代表详细了解集美区及阿里巴巴创新中心对于集美区内初创企业的扶持政策。 阿里云创新中心品牌运营专家小鲜为现场企业详细介绍了阿里云“风池计划”创业扶持政策及阿里云针对集美区内企业的扶持模式,为集美区企业的转型发展保驾护航,助力新一代独角兽的成长。 现场,小歪科技、云脉信息及优客工场作为代表企业及众创空间接收集美区科技局发放的阿里云代金券。 什么?这仅仅是一个开始。据悉,集美区科技局与阿里云计算有限公

资源下载

更多资源
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

用户登录
用户注册