搜狗大数据平台建设

1、 搜狗大数据平台建设目 录 TOC o 1-3 h z u HYPERLINK l _Toc520827925 1.前言 PAGEREF _Toc520827925 h 3 HYPERLINK l _Toc520827926 2.搜狗大数据业务概况 PAGEREF _Toc520827926 h 4 HYPERLINK l _Toc520827927 3.搜狗基础运维平台简介 PAGEREF _Toc520827927 h 8 HYPERLINK l _Toc520827928 4.搜狗大数据产品化实践 PAGEREF _Toc520827928 h 16前言如果大家遇到大数据的问题，如何进一

2、步找到自己的价值，如何探索适合自己的中型或者小型公司数据团队在其管理方向的思考和探索。我做过很多项目，负责过搜索、运维、云平台、大数据，见证搜狗的成长过程，目前在做大数据基础平台建设和数据管理应用方向。本文分为三部分：第一，搜狗大数据业务概况，做个基本的介绍。无论是运维平台还是大数据平台，对公司来说都是支撑平台，没有好与坏，只有适合与不适合。第二，搜狗基础运维平台简介。分享跟大数据系统相关的组件和模块。第三，搜狗大数据产品化实践。我们在大数据系统从工具到产品的探索和思路，更多的是产品介绍、思路及我们的理念。搜狗大数据业务概况搜狗是典型的大数据公司，我想表达的是我们的大数据团队也并不容易。如果了

3、解搜索引擎的实现机制会知道，搜索的好与坏和数据量规模有关系，无论市场多大，都必须收集很多的数据，才能保证数据的覆盖度。对搜狗来说，搜索引擎本身的数据量非常大，很多年前我要处理上百亿的数据，现在整个搜索的覆盖大概在2000亿左右。搜狗输入法目前是行业第一的产品，DAU用户规模4亿+，我们在很早的时候就已经面对 4G 内存的机器上万并发的情况。我们在规模体量上和数据规模上面对的问题挺多。通过我的思考，把我对大数据演化方向的理解分享给大家。近期比较火的是以Hadoop 生态为依托的生态系统。经历了几个阶段，每个时间节点并不代表Hadoop的研发时间点，而是被行业接受和逐步用起来的时间点。第一阶段，H

4、adoop高速发展阶段，2010年之前，MapReduce刚刚出来，我们也是从Hadoop0.2版本跟起，更多的解决批量计算问题；第二阶段，2010年前后，从我的感受来说，面太窄，只能依靠数据工程师去写MapReduce。当时Hive的出现，对于大数据系统有了质的飞跃，用户查询使用量也上来了，这时候解决了使用门槛问题，传统的BI、数据工程师、SQL 工程师、传统数据分析工程师都可以学习用到大数据的系统；第三阶段，2012年前后，阿里双十一是代表，整个行业对实时计算的需求比较强烈；第四阶段，近两年来公有云厂商，大家都知道数据应用的价值非常高，有很多的方向。典型的机器学习组件、广告算法等，原来的门

5、槛很高，但是现在正在逐步的降低门槛，能够比较快的把初级模型搭起来。搜狗大概也有几个阶段：第一阶段，我把他称之为专用的搜索大数据时代。我做过研发，我认为搜索是非常典型的系统。大家知道搜索的核心要抓取全网的数据，这就是数据采集的过程。抓下来大量数据要存下来，就是数据存储的问题，而且是大规模数据存储的问题。把数据抓下来后要做排序、超链分析等，这是一个数据分析的过程。后面是快速的搜索和检索。在2006年之前对搜狗来说，我觉得还是一个上古时期，几乎没有开源技术，所有的东西都靠自己研发，一切的一切只是为搜索服务。第二阶段，跟着Hadoop演化，我给定为行业接轨的时代。这时候各种工具和版图慢慢起来，包括核心

6、产品、数据报表、实时计算等应用起来了。第三阶段，从2016年开始我们开始向人工智能发力，前一段时间在互联网大会上，我们有同声传译。由于去年搜狗 IPO 后，我们在商业化方向有很多新的需求。在此情况下，诞生了对大数据团队的新需求和依赖。这是基本服务版图，相信各大公司的差别不太明显，一般都是有数据源、数据采集Agent、数据存储、数据计算、数据应用等等方向。但在每个细节上的优化非常多，包括模块与模块之间连接的地方，服务监控管理、资源调度管理等是很重要的一部分。搜狗也是如此，在拥抱开源技术的基础之上，把周边的服务、模块逐渐的普及和优化的过程。搜狗基础运维平台简介下面简单分享搜狗基础运维平台的思考和建

7、设情况。大概2012年前后，由于当时机器数量比较少，只有小几千台。当时也有类似规模的小公司，大量运维平台开源工具，很多套系统满天飞的状态。后来随着机器和管理规模变大，2012年前后下定决心，完全从开源走向自研。走自研路线主要的需求有：我们需要灵活性的变化，我们要与商业计划、OA系统、财务系统、预算系统打通。管理这么多问题的成本非常高，所以我们有需要打通的需求。并不希望在解决问题时要打开七八个系统，分别找数据来排查问题。在这样的背景下，我们在 2012 年前后把运维工具从开源逐渐转向自研平台。希望平台更加易用，所以我们把所有的从业务视角、用户视角把所有的业务整合起来，我们内部称之为ROC系统，实

8、际是资源管理的中心。我把它定义为更广义的运维平台，因为它不仅有常规的集群管理、域名带宽管理、存储系统管理、监控管理，还有安全审计、采购、工单等平台，把他们都整合在一起，现在搜狗的整个基础运维平台都在这个平台上运行。接下来分享一点搜狗关于在机器管理方面的思考和想法。从机器到集群。我们核心理念是从机器到机群，我们坚持从原来对机器的管理变化到对机群的管理，这件事谈起来很容易，要完整的运转是成本很高的事情，我们至少花了3年时间才把这套东西完整的运行在以目录树管理方式的机群管理方向上。机群叶子为最小模块单位。对于以业务为服务模块时，不管里面有多少台机器，这是标准化的整块服务。实现了所有日常操作组件。为了

9、打造这个目标，我们实现了很多服务的组件，如系统重装、机器保障、上下架搬迁、配置IPNAT、基本软件运行环境，对普通运维工程师来说，在界面操作便能完成日常工作。大数据本身依赖大量的进程、日志数据产生的模块，搜狗以业务集群的叶子节点为最小的运维单位，可以串联进程和日志的定义。举例说明，在任何一种机器上跑一个模块或者一组进程，只需要模块和配置文件，便能完成对进程本身的运维平台的接入。只需要定义进程的基本形态、运行基本情况，这个进程就已经被运维平台接管了。做了这个基本定义后，后面提到跟大数据有关的是我们会对里面的日志做简单的配置，日志就被管理起来。我们的日志管理包括日志在数据上的存储生命周期、日志适合

10、做什么样的压缩、日志进入大数据系统中的限流限速。对进程的定义和对日志怎样进去到大数据的定义，我认为这是大数据系统依赖的基本工具。这两个东西已经做得比较轻量级，只需要在平台上做技术的管理便能达到操作。切到监控版块。我们对大数据运维平台管理/运维人员的日常工作有几大类。其中一类是针对任务失败情况、任务延时情况做事。这依赖的就是监控系统，我们用了很多年监控系统，我会分享介绍我们在监控上的思考和理念。监控分为两大类：第一类，黑盒监控，是用户视角的模拟。我不知道系统长什么样，我们会把所有用户可能访问系统的方式定义出来，各种可能性。我们支持多种监控插件，从TCP、MySQL、Redis等，给定义成黑盒。除

11、了是活和不活之外，我们还做了语义的定制，根据内容访问的不同，选择不同的报警策略。还有一块是完整的现场快照，搜索引擎对这个要求非常高，搜狗可以找到99.994%-99.996%左右，百度可以做到99.997%。我们每个月会抓出几个失败，排查问题非常麻烦。针对该情况，我们做了很详细的现场快照的汇总工作。以前排查千万分之一出错的可能性，是非常困难的。当你发现监控出一个问题时，可以快速的看到里面的快照信息，包括监控机网络状况、执行过程、抓包网卡，看服务器的每一个包和每一个网络如何进行传输，有非常明确的记录。后面即使有非常小概率错误，排查问题也能一目了然，这对我们来说是比较顺手的工具。第二类，白盒监控，

12、是系统视角。对搜狗来说如何设计白盒，黑盒是从业务视角看业务模块好不好，那反过来白盒就是已经知道系统的一切运行状态和日志都收集上来了，要如何发现系统的隐患和问题。我们把所有的数据、模块运行系统日志、进程日志、打印日志都做成标准结构，它一定是标准的结构才能清晰入到监控库中。我觉得它非常好用，它可以做灵活的语义定制。比如我的进程有很多的数据，可以做加减乘除以及各种各样的条件，这对我们来说是搜狗运维平台的利器，我们可以对任何一个我们运维的服务和模块做各种可能监控的方法，这在界面设置可以完成，对Ky的值做各种各样的组合。接下来时报警策略的问题。搜狗发展十几年，我们经历过有大量的监控报警和大量问题出现的阶

13、段，每天在被报警的汪洋大海中活着，我们为当时的状态解决问题。灵活报警，报警策略有很多种，轻量级只是简单的提醒你，比如邮件或者电话提醒你解决问题。我们采集各种各样的数据进行条件的组合，比如10台机器有1台机器故障，你可以发邮件，我第二天处理。如果5台机器故障，会直接把你叫起来。这都可以灵活的配置，这是搜狗用得比较广的方向。监控系统是我们大数据运维工程师日常经常面对的问题，保证日常服务稳定的基础上，我们不断的挖掘系统的隐患，不断的补齐各种各样的监控手段和方法，让系统更加稳定和可靠。我门大数据运维团队有大量的工作是配合公司和业务资源的管理，有人申请新机器、扩容、搬迁、调整，这会占一定的工作时间，我们

14、做了大量系统化和信息化的工作。其思路有点像公有云，对搜狗公司的业务来说，其产品受到严格的管理流程，每个人用多少资源与其商业计划完整挂钩。首先是整个资源，如提预算，我们不是按照机器来算的，而是今年或未来一个季度可能会用到多少存储、多少内存、多少计算资源等，这些资源会转换为业务考核目标，比如产品日活、产品收入增加多少。到了一定规模，到CFO审核后，自动形成机器的采购、上线单，这套流程完全打通。对运维人员来说清晰可见，机器采购完后，会在集群管理上生成采购单，我们就可以进行扩容，然后开放申请。这是申请界面，多租户问题的核心是资源是不是多了，是不是不够，怎样加资源等等如何解决。搜狗在这方面比较清晰，每个

15、人都知道产品下来有多少账号，我申请了多少，留了多少，哪个用得多，哪个用得少，比较便于我们的管理。不存在说不清我们到底要加多少台机器，这对机器和成本管理来说非常有意义。资源管理的后续是如何开放和使用的过程，我们大数据方向做了很多工作。第一，每个产品线和每个业务单元使用的资源，每个月都有对账单，你在哪个集群、哪个资源上用了多少，峰值多少，花费多少钱。对我们来说，每一台机器如何使用有非常清晰的流程。第二，除了对账单，我们还有后续的措施。每个资源和账号使用的过程，我们可以帮他分析和优化。有些产品线和业务资源使用不够均匀，空洞很多。每年做商业计划，这一块是有问题的，你不需要申请那么多，大家是有共识的。这

16、是我们在资源管理方面的思路和想法。整个运维平台涉及很多，对我们大数据团队来说更多面临的问题是日常资源管理、体系管理、成本管理，还有我们要排查解决日常性能、优化性能，对监控系统的依赖和对集群的管理。搜狗大数据产品化实践到了第三块的主题，搜狗大数据产品化实践，我们谈谈差异化的东西。近几年搜狗的发展不是特别快，我们把可靠和稳定问题解决得差不多，最近我们在纠结大数据平台价值问题，我们的运维团队和大数据团队如何创造更多的增值价值和提供服务的思考，希望给大家一些思考。主要为大家介绍我们的思路和实践。最近一两年，我们遇到很多新的问题。AI产品驱动和商业化大数据时代，很多公司出现新问题。原来的数据是自己产的数

17、据自己用，我们只要做好多租户隔离。到现在这个阶段，这时候数据附加值非常高，表现明显的问题是产品之间数据依赖非常高，以前自己用自己的，现在是混在一起大家都在用。这个时候，业务对数据的安全更敏感，跨产品数据共享门槛非常高，我们最近在解决的是如何让公司的数据安全有效的共享。数据安全，我们有以下探索：Hadoop自研。搜狗大概在2009年初开使用Hadoop的系统，当时第一个系统不是做报表这种小打小闹的东西，Hadoop有一个核心算法，就是典型算网页超链关系和排序效果。做了这个之后，这时候多租户管理的问题出现了。我们自己研发了Hadoop权限管理，即使到现在为止，我们还在使用。虽说行业有很多安全和授权

18、解决方案，但我们依然还在用。其好处是轻量级，在Hadoop体系中不需要维护单独的服务，不会对系统配置产生额外的管理成本。关于数据敏感的问题，每个账号支持账号密码级登录认证，我们也支持IP双重认证授权，对IP段进行双重认证。即使账号密码被盗了也没关系，有IP的限制，才能同时访问到数据。虽然是轻量级的工具，对我们后来享受安全的灵活性可以提供很多解决方案和思路。数据使用严格审批和监督。我们开始尝试数据的审批和监管，数据有大量的访问集、资源分配和提高任务管理，有很多会产生谁，什么时间，哪台机器在用什么数据。我么也尝试将这样的数据做信息化，大家从业务方面看到谁在用。数据加密和脱敏。这是我们在产品和产品之

19、间数据交换是做的探索。解决安全问题后，更重要的是如何让不同的产品之间进行共享。搜狗大概有1万多种数据种类，每天涉及的数据文件有一二十亿，很多历史源产生的数据，有一定的管理难度。每个人生活在自己的世界里，只有自己知道自己有什么，你难以知道别人有什么。这是对我们现阶段的一个挑战。我们面对几个问题：公司到底有哪些数据，每天会产生大量的数据、计算结果；公司数据应该怎么申请，才能满足安全和审计规范；如何使用这些数据。第一个方向，我们开始对公司数据做自动发现，我用旁路的模式对数据进行管理和支撑。数据全生命期的管理成本是极高的，刚起步做这件事是非常麻烦，要做大量的工作，本来是可以快速完成的方式，会变得非常慢

20、。我们采用旁路的方式来关联和发现数据，我们是做搜索起家的，我们有很多数据，只要任何一个地方串联了数据，上了集群，通过发现机制都可以被发现。我们根据数据的路径和归属发推荐，让他做认领。比较有意思的地方是我们参考了豆瓣看影评的方式，我们对每个数据贴了很多标签，标签对我们做检索、分类和查验数据非常方便。每天搜索关键词的指数可以做很多标签，只需要做简单的检索就可以看到。我们把旁路的系统称之为数据云，它更像一个搜索引擎，有输入框、分类和导航，让大家对公司全部数据一目了然，有直观的感受。第二个方向，发现了数据后，就是检索数据。我们对数据做了大量结构化和信息化的工作，我们可以通过关键词搜索各种各样的数据。我

21、们会把很多数据设置数据大小、文件数量、更新时间，便于我们做排查，这对管理运维有帮助。我们想处理一块数据时，只需要在系统上花一分钟，便能查到哪些账号下，哪些数据已经半年没人用了，确认后可以删除。这算是完整的信息化的支持。在数据上跑的任务，我们开始构建依赖的路径和版图。我们正在做的更进阶，数据和数据之间的任务有筛查关系，从管理中生产出多任务多路径的关系，我们尝试构建这个路径，更容易看到它的上下游及谁在依赖它。第三个方向，关于数据共享，简单介绍数据仓库。数据仓库的底层引擎很成熟，2010年开始，从Hive开始到后面的Spark、SQL特别多，这是分分钟可以搭起来用的。从搜狗的搜索来说，从这个东西出来

22、之前，还只是专业数据人员在用。后来我们尝试做一些改进，源于谷歌的一个产品，我们把所有的数据通过产品化结构化的方式，让每个人很清晰的看到数据有什么含义，你们可以预览TOP10的数据，方便感知这个东西。第四个方向，在数据共享方面的尝试，除了数据仓库外，我们可以公开Schema和demo的数据，定义为数据字典。通过任务的推荐，每个用户知道哪些数据热门，大家都可以用，其价值是什么，可以看到如何定义这些内容。第五个方向，移动审批。前面主要是数据的发现和数据的查找，我们有移动OA系统，任何数据的使用和申请有流程的。对于搜狗来说，我们觉得现在太麻烦了，即使开源软件或者我们有很多成熟的基础组件，但使用成本依然

23、很高。从数据的产生到数据的使用流程非常长，在里面摸爬滚打很多年才能了解怎么运作起来，数据的使用门槛非常高，数据的清洗、协议处理成本非常高，我们为此采访过很多公司，70%的时间在清洗数据，我们后来花了很长时间想解决这件事。易用性问题，开源性平台有很多基础组件，但想用得好还是比较难的。我们带着新问题切入，如何让大数据平台使用逐步简单，这是我们的出发点。第一，我们做了类似SaaS产品的产品级数据解决方案。做数据时，如果小公司创建，做一个App的时候要用到统计，一定是用现在成熟的技术。我们会有这样的解决方案。搜狗公司在尝试很多新产品，他们只需要装SDK，让所有的数据一目了然。第二，为了让流程变得简单，所有的数据清洗完后可以一键进入数据仓库，让准备工作变得足够少。第三，我们做了一个像google的BigQuery系统，大家写SQL搭一个引擎就可以用，但有这个和没有这个的用户量差好几倍。纯粹非技术人员也可以方便用这个系统，我们用户使用的规模和量差很多。第四，在报表方面，由于搜狗大量工作和报表有关系，我们在此基础之上，配上时间、命名关系，每天都会形成报表，报表的生成工作变得非常