百度|按下搜索按钮的那一刻，你希望多久看到结果？
文章图片
文章图片
文章图片
我们从未发现距离大数据竟如此之近 。
虽然在日常的新闻报道中 ， 我们常能听到大数据这个名词 ， 但更多只是一个概念 。 直到伴随新冠疫情防控的展开 ， 扫码已经成为大家出行的“常规操作”的时候 ， 我们才发现无论是进入商场、小区还是乘坐公共交通 ， 手机和口罩已成为大众“必需品” ， 而根据扫码信息追踪个人活动轨迹的大数据技术居然就在身边 。
特别是伴随着近日北京疫情的爆发 ， 醒目直观的“新冠病例活动地图” 刷爆了朋友圈 ， 这种公开、透明的方式也大大降低了民众的恐惧感 ， 提升了对于疫情防控的信心 。 显然 ， 这些轨迹的追踪都是基于大数据实现的 ， 而借助于数据分析 ， 我们甚至可以对某些尚不自知的“密切接触者”在第一时间进行观察与隔离 。
其实这种技术在疫情之初就已经应用于防控一线 ， 早在今年2月 ， 百度地图就在北京、上海、深圳、郑州等全国49个城市上线了“新冠病例曾活动场所” 专题地图 ， 帮助公众准确掌握官方发布的相关信息 ， 减少不必要的恐慌情绪 ， 并协助社区有针对性地开展疫情防控 ， 遏制疫情的进一步扩散 。
不仅如此 ， 百度的大数据搜索平台在提供疫情热搜、热搜谣言辟谣等服务 ， 并借助多维度的搜索大数据报告的同时 ， 还能够根据搜索结果对于未来人流迁移进行预测 。 比如在刚刚过去的端午小长假中 ， “12306”相关内容的搜索热度同比下降59% ， 各旅游OTA平台的搜索热度同比下降57% 。
由此看来 ， 大数据已经影响到我们生活的方方面面 ， 无论是数据分析还是数据查询 ， 我们都希望能够在第一时间尽快完成 ， 而这除了需要优化的软件与算法支持之外 ， 更需要强大性能的硬件 ， 特别是能够对数据库进行加速的硬件产品 。 这也就是我们今天要介绍的主角——英特尔傲腾持久内存 。
【百度|按下搜索按钮的那一刻，你希望多久看到结果？】回顾大数据发展 ， 我们发现这个概念大概在2012年以后就进入了快速上升的通道 ， 特别是Hadoop分布式架构的出现让大数据更容易被整个行业所接受 。 之后随着时间的演变 ， Hadoop被一种名为Spark的技术所取代 ， 后者的特点就是通过拓展内存计算可在海量数据的迭代式计算和交互式计算中提供远快于Hadoop的运算速度 。 同时 ， Spark支持SQL请求、流数据处理、机器学习和图表处理 ， 提高开发者效率 。
百度自主研发的BIG SQL数据处理平台正是以Spark SQL为基础 ， 并引入了众多新功能和性能拓展 。 当然对于百度这样的互联网巨头来说 ， 每日产生的数据将以千百万计 ， 仅就大家最熟悉也最常用的搜索业务来说就已经是一个庞大的数字 ， 也对后台系统造成了压力 。
我们在网上进行查询的时候总希望后台能够“秒级响应” ， 最好是点击鼠标立刻就出现结果 ， 这种查询就被称为交互式查询 。 虽然同样要访问大型数据库 ， 但是交互式查询却具有非常特定且具体的筛选条件 ， 仅以查询相对少量的数据为目的 ， 因此就需要能在几秒内甚至几毫秒内返回 。
但问题在于 ， 这种需求对于百度已有的Spark SQL造成了巨大挑战 ， 事实上Spark SQL无法实现交互式查询所要求的性能 。 为解决这一难题 ， 百度与英特尔合作实施了Spark平台优化分析包（OAP）项目合作 ， 使用索引和缓存技术来加速交互式查询响应 ， 推动百度BigSQL实现令人满意的交互式查询性能 。
当查询具有非常特定的筛选条件时 ， OAP可以在符合条件的列上创建索引 。 通过索引 ， OAP能够识别目标行 ， 同时跳过后端存储上不必要的数据扫描 。 由于索引文件与原始数据文件保持分离 ， 在创建或删除索引时均无需重写原始数据文件 。
OAP的实现方式是通过与列数据文件并排创建与存储完整的B+Tree索引 ， 从而实现快速的跨越搜索 。 这有点像我们去商场买东西——比如想买一件衬衫 ， 我们可以直接在商场平面图中查询男装在几层 ， 再根据长裤、衬衫、外套等信息进行筛选 ， 这样就能快速的找到目标 ， 而不需要逐层逐店去寻找 。
另外一种加快查询速度的有效方式就是缓存热点数据 ， 通过把影响性能的关键数据或热点数据缓存到高速的存储设备中 ， 比如内存中 ， 可以在建立索引的基础上进一步提高查询性能 。 基于“最近最少使用（LRU）策略” ， 当缓存达到最大容量时 ， 那些最近最少使用的数据项将被淘汰 ， 为缓存最新数据释放空间 。 另外 ， 百度 BigSQL 还启用了一个高级缓存管理器 ， 可以主动填充热点列 ， 并清除缓存中不再需要的列 。
当然这种清除并非是无限制的 。 特别是对于百度这样规模的平台来说 ， 随着业务的不断发展 ， 后台的数据集规模日趋庞大 ， 热点数据量势必会超过缓存空间容量 ， 最终导致性能下降 。 这也就势必要求系统缓存足够大 ， 客户自然需要采购更大容量的内存 。
但这并非是每个客户都能实现的 。 首先 ， 内存的价格非常昂贵 ， 即便是在如今芯片价格走低的情况下 ， 大容量内存的价格依然如同“天文数字” 。 其次 ， 在Spark 环境中 ， 因为每个节点上可配置的总内存容量有上限 ， 并不能无限扩展；第三 ， 内存的优势在于较高的随机访问带宽和较低的延迟 ， 而将其用于大量数据缓存和顺序数据的读取无疑是“大材小用” 。 正是考虑到上述三大原因 ， 百度将目光转向了英特尔的主打产品——傲腾持久内存 。
相对于传统内存来说 ， 傲腾持久内存是一种特殊的存在 。 虽然在名字中有“内存”的字样 ， 但是它本质上还是一种介于内存与传统存储之间的产品 。 更值得一提的是 ， 傲腾持久内存具备了“内存模式”和“应用直接访问模式”两种运行状态 。 当处于“内存模式”下 ， 傲腾持久内存无需重新编写软件就可以当作内存使用 ， 并且在性能上也与内存非常接近 。
在“应用直接访问模式”下 ， 经过专门改进的应用程序可从产品固有的持久性中充分获取价值并获得更大的容量 。 针对百度需求的特性 ， 这里的傲腾持久内存采用了这一模式 ， 以确保应用程序能完全决策如何使用设备空间 。
同时 ， 英特尔还对OAP进行了扩展 ， 加入了内存管理器插件 ， 并采用了基于傲腾持久内存的内存管理器分配缓存空间 。 这样一来 ， 用户就可以在传统内存和傲腾持久内存之间自由切换 ， 甚至是将两者共同使用——比如用内存缓存索引 ， 而使用傲腾持久内存缓存数据 。
实践也证明了傲腾持久内存的有效性 。 在百度进行的、数据集大小为1TB的测试中 ， 相同容量的内存与傲腾持久内存时 ， 后者的性能与前者非常接近 ， 可以达到内存性能的88.3% 。 而伴随着数据集容量的提升 ， 当数据集达到3T的时候 ， 内存已经不足以缓存所有数据 ， 但是傲腾持久内存依然游刃有余 ， 性能反超内存高达6倍之多 。
随后进行的百度线上实际业务的测试更证明了傲腾持久内存的超高性价比 。 当内存与傲腾持久内存都被设置为50%的常用数据列时 ， 傲腾持久内存的缓存速度仅比内存低约12% 。 而如果考虑到相同成本的情况下 ， 只有傲腾持久内存拥有足够容量来缓存所有热点数据 ， 且性能较内存高出 22％ ， 同时避免了30% 的底层系统I/O请求 。
“我们使用来自英特尔的傲腾持久内存 ， 在缓存质量得到保证的同时 ， 极大地提升了集群的处理能力 ， 获得明显的 TCO 收益” ， 百度资深系统工程师黎世勇如是说 。 事实上 ， 借助于英特尔傲腾持久内存的加持 ， 百度图灵集群的工作负载降低了30% ， 平均查询延时降低了20% ， 每个傲腾持久内存服务器实例Spark/OAP性能提高了50％ ， 而成本仅增加了20％ 。
毫无疑问 ， 英特尔傲腾持久内存无论是在性价比还是在缓存容量表现上 ， 都比传统内存更加出色 。 虽然在低数据集容量的时候性能略有落后 ， 但是傲腾持久内存的性价比依旧突出 ， 尤其是高数据集下的大缓存优势更是无可争议的行业领先 。
一直以来 ， 如何实现数据库应用加速是行业中的难题 ， 特别对于百度这样以搜索为核心业务的公司来说 ， 更侧重于提升数据检索的应用体验 。 这一次 ， 英特尔借助傲腾持久内存提供了更优化的查询方式 ， 将检索时间从秒级降低到了次秒级 ， 在提升用户体验的同时也提供了超高的性价比 。
如今 ， 大数据分析已经成为了行业应用的主流 ， 特别是国家所倡导的”新基建“更是将大数据中心作为核心应用之一 。 伴随着近年来全球数据规模呈指数级增长 ， 谁能解决企业的数据应用需求问题 ， 谁就能把握未来的数据时代 。
按下搜索按钮的那一刻 ， 你希望多久看到结果？
推荐阅读
- 中国搜索|凌晨4点！全程高能！
- 娱乐全搜索|当明星变成游戏人物，罗云熙从英气变柔美，王一博最不像本人
- 美柚|美柚：婴幼儿肠胃问题7月相关搜索量环比增长45%
- EV视界|百度Apollo牵头，中国首个高等级自动驾驶标准将出台
- 猫眼|猫眼宣发能力再升级 为行业复苏按下“快进键”
- 文艺复兴科技Q2降低医药股持仓比例，增持中概股拼多多(PDD.US)和百度(BIDU.US)
- 中国搜索|细节曝光！曾春亮被捕时裤子被扒是这个原因！
- |天津港保税区海洋产业发展按下“快进键”
- 百度与国家开放大学达成战略合作，共同加速中国AI人才培养
- 中国搜索|国务院政策答问平台，来了！