[.com原稿]在去头条的路上，我一直在思考这样的数据驱动，哪个方向的访问量会更受关注公司。个性化新闻推荐、不同业务算法差异、敏感信息屏蔽、新闻源抓取？然而，在这个阳光明媚、暖洋洋的午后，在与今日头条数据基础平台架构师王野长达一个多小时的交流中，我们的话题却不知不觉围绕着一个主题展开，那就是如何使用数据。基础数据平台——数据驱动型企业发展到一定水平所必需的。今日头条（以下简称今日头条）成立于2012年，2014年王野加入，当时公司只有300人。随着公司的发展，数据量成倍增长，见证了基础数据平台从无到有，从小到大的过程，所以由他来解读平台的方方面面非常合适。王野·今日头条基础数据平台架构师什么时候需要搭建数据基础平台？对于创业公司来说，核心是服务好用户，迭代产品功能。当公司发展到一定阶段，业务开始多元化，经营开始精细化，对数据的需求增加，产生的数据量和数据处理的复杂度也显着增加。这个时候就该搭建基础数据平台了。王野介绍，2014年，今日头条每天只有几百万活跃用户，支撑产品是重中之重，没有专人负责做数据。随着很多复杂业务的上线，会同步招聘大量的PM（产品经理）和运营。基于根深蒂固的数据驱动思维，不断提出各种数据需求。这时候就不再是几个数据工程师一个人就能解决问题了，而是让PM和运维直接去分析数据。门槛也很高。面对这些情况，今日头条的做法是成立数据平台团队，将Hadoop、Hive、Spark、Kylin等数据基础设施打包成工具，将这些工具与常用的分析模型结合成一个完整的解决方案，然后将这些进行整合解决方案解决方案以平台的形式提供给业务部门。数据平台也有一个演化过程。不需要一开始就很大很全，只要不同阶段采用的技术能够匹配当时的需求即可。基础数据平台的职责是什么？推荐业务是今日头条最重要的业务之一。根据需求，搭建全公司通用的数据平台。用户数据（内容偏好、行为轨迹、阅读时长等）是今日头条最大的数据来源。这些记录的数据反映了用户的兴趣，将以各种形式传输和存储，并提供给全公司各业务系统调用。同时维护RD（analyst）数据工具集（日志采集、入库、调度、依赖管理、查询、元数据、报表），通用用户行为分析平台PM及运维，底层查询引擎（Hive、Presto、Kylin等OLAP查询）引擎，支撑上层数据平台和数据仓库），平台基础数据仓库，协助维护业务部门数据仓库。基础数据平台建设需要面对哪些挑战？数据生命周期分为生成、传输、入库、统计/分析/挖掘，每个环节的难度都会随着数据规模的增大而增加。目前，今日头条每天处理7.8PB的数据，200亿个训练样本，4万台服务器，3000个Hadoop节点。庞大的数据量和业务复杂性给数据的生成、采集、传输、存储和计算带来的一系列问题是平台建设需要克服的挑战。数据的生成和采集——SDK，用户追踪总的来说，数据的生成和采集很简单，但是对于今日头条这个功能众多的APP来说，难点在于每个功能都是由一个团队独立操作的。如果每个团队都采用自研的数据采集方式，会给后续流程带来巨大的麻烦。那我们该怎么办呢？王野介绍了他们的分析决策过程。今日头条属于C端业务公司，以日志形式为主，数据的主要来源是用户行为。然后使用事件模型描述日志，以SDK的形式接入，支持Client和Server埋点。这里需要注意的是：数据质量很重要，埋点规范应尽快建立。脏数据是不可避免的，可以引入必要的约束和清洗。埋点是用户使用某个功能时产生的一段数据。今日头条早期，日志格式由各个业务场景自定义，然后统一到事件模型中，保证了信息的结构化和自描述性，降低了后续使用的成本，复用了一个统一的分析清洗流程和数据仓库导入入库和行为分析平台。埋点管理也通过文档、wiki等方式演变成埋点管理体系，覆盖埋点全生命周期。这样也得到了埋点的元信息描述，后续可以应用于数据清洗、分析平台等场景。同时埋点上线流程标准化，客户端也可以进行自动化测试。数据平台实现了通用的客户端追踪SDK和服务端追踪SDK，摒弃了以往根据协议生成数据的方式，可以保证生成的日志符合追踪规范，统一了基础口径App启动、设备识别等，降低新App适配成本。数据的描述由使用JSON改为Protobuf，这样可以通过IDL实现强制约束，包括数据类型、字段命名等。除了日志数据，关系数据库中的数据也是数据分析的重要来源。在数据采集方式上，今日头条采用Spark实现类Sqoop的分布式爬取，替代了早期定时使用单机全量抓取Mysql数据表的方式，有效提升了爬取速度，突破了单机机瓶颈。然后为了减轻Mysql的压力，使用Canal接收Mysql的binlog，离线全表合并，不再直接读取Mysql，千万级/亿级表的处理速度将更快。数据传输——Kafka作为消息总线连接线上和线下系统。客户端返回服务端或者直接在服务端产生的数据都可以认为是在线的。当数据落地到与统计分析相关的基础设施上时，就变成了离线状态。在线系统和离线系统通过消息队列连接。今日头条的数据传输使用Kafka作为数据总线，所有实时和离线的数据访问都必须经过Kafka，包括日志、binlog等。王野提醒，这里值得注意的是：尽快引入消息队列并将其与业务系统解耦。今日头条的数据基础设施基于社区开源版本，做了很多改进回馈社区。还有很多自主研发的组件。因为以现在的数据和集群规模，如果直接使用社区版甚至企业版的产品，会遇到很多困难。在数据访问方面，自研Databus作为单机Agent，封装了Kafka写法，提供了异步写法、缓冲、统一配置等特性。Kafka数据dump到HDFS进行后续离线处理。随着数据量的增加，Dump的实现也经历了几个阶段。最初实现是类似Flume模式的单机上传，但很快遇到瓶颈，改实现为通过Storm实现多机分布式上传，支持的数据吞吐量大幅提升。现在已经开发了一个名为DumpService的服务。作为托管服务，它可以很容易地集成到平台工具中。底层实现转为SparkStreaming，实现exactly-once语义，保证dump数据不丢失、不重复。数据仓库——数据仓库，头条的ETL（抽取、转换和加载）数据源非常复杂，直接拿来做分析不方便。但是在数据仓库层面，通过数据处理的过程，也就是ETL，会构建成适合分析的完整的一层有价值的数据仓库。在数据仓库之上，数据分析师和数据RD可以通过SQL和多维分析更高效地使用数据。数据仓库中数据表的元信息存储在Hivemetastore中。HDFS上数据表的存储格式主要是Parquet，是一种列式存储格式，支持嵌套数据结构。今日头条多种ETL实现方式并存。对于底层数据构建，一种选择是使用Python通过HadoopStreaming实现MapReduce任务，但现在更倾向于使用Spark直接生成Parquet数据。与MapReduce相比，Spark拥有更丰富的处理原语，代码实现可以更加简洁，同时也减少了中间数据落地量。对于高层数据表，直接使用HiveSQL来描述ETL过程。数据计算——计算引擎的演进如何高效查询数据仓库中的数据表是至关重要的，因为这将直接影响数据分析的效率。常见的查询引擎可以分为三种模式，Batch、MPP和Cube。今日头条在所有三种模式中都有使用。今日头条最早使用的查询引擎是InfoBright。Infopight可以看作是支持列式存储的Mysql，对分析查询比较友好，但是Infopight只支持单机。随着数据量的增加，我很快就切换到了Hive。Hive是一个很稳定的选择，但是速度一般。为了更好地支持Adhoc交互式查询，今日头条开始研究MPP查询引擎，先后使用了Impala和Presto，但都在今日头条的数据量下遇到了稳定性问题。今日头条目前的计划是结合使用SparkSQL和Hive，开发自己的QAP查询分析系统，自动分析查询SQL并将其分发到合适的查询引擎。在Cube查询引擎方面，今日头条使用的是麒麟，目前是中国麒麟最大的用户之一。数据入口——提供业务数据分析的整体解决方案。对于大多数需求比较简单的企业来说，数据最终生成报表就足够了。比如给管理层做报表，可以让老板直观的了解一些关键指标，这是最基本的数据应用模式。再往前走一点，需要汇总各种来源的业务数据，提供多个维度和指标进行更深入的探索性分析，得出结论来指导产品迭代和运营。王野表示，今日头条绝大部分业务都是数据驱动的，都需要产生和分析大量的数据，这或多或少需要借助平台提供的一系列工具。今日头条开发了一个名为数据入口的平台系统，提供给业务部门，为数据生命周期的各个环节提供相应的支持。数据门户提供的工具都是声明式的，即用户只需要指定自己想要达到什么目的，隐藏了具体实现的复杂细节，更加人性化。通过这些工具，业务部门的RD、分析师、PM等可以专注于业务分析本身，而不是去学习如何使用大量的数据基础设施。数据抽取平台QueryEditor数据抽取平台QueryEditor使用接口数据抽取平台QueryEditor进行数据生命周期管理，对Kafka数据转储、数据仓库存储、SQL查询托管提供统一支持。数据基础平台的理念与方向——降低使用门槛，提升工具易用性数据基础平台的理念是提供整体解决方案，降低数据使用门槛，方便各类业务接入。互联网产品的数据分析模式也比较固定，如事件多维分析、留存分析、漏斗分析等，将这些分析模式从工具中抽象出来，也能覆盖大部分常见需求。同时希望PM等业务相关人员能够更直接的掌握数据，通过相关工具的支持，自己实现数据需求，努力解放业务中工程师的生产力部门，以免被各种临时运行数据需求所困扰。对于更专业的数据分析师的工作，也会提供更专业的工具支持。
