互联网大数据架构最佳实践（ word 可编辑版）.docxVIP

PAGE PAGE 10 互联网大数据架构最佳实践 互联网大数据架构最佳实践 主题简介： 主题简介： 1. 数据平台技术选型 1. 数据平台技术选型 2. 用户交互实践 3. 大数据团队能力建设 现如今大数据一块有很多的开源项目，因此首先搭建平台的难点其实在于如何选择一个合适的技术来做整 个平台的架构，第二，因为有业务数据，用了平台之后的话，如何用平台把数据分析出来让用户有很好的 交互性的体验。第三个层面就是理工科喜欢建模，而在这整个过程当中，我们会形成一种非数据建模，而 主要是我们如何分不同层面的人员搭配，进而做成这样一个大数据团队。 一、数据平台技术选型 1 、整体框架 这个框架应该是一种大路货，或者更认为是一种比较常见的架构。前面也就是从数据源到消息队列到数据 的清理、数据呈现等这些大家容易想到的东西，而在这样一个大帽子下面，所不一样的东西是具体选用什 么样的组件来填这个空，在不同的场景下，每个人的选择是不大相同的。 像消息队列这一层，我们选用了 Kafka，这是目前大家普遍用到的，因为它有高吞吐量，采用 Push 和 Pull 结合的方式，消费端主动拉取数据。ETL 这块，目前大家都希望采用一种可以自定义的方式，一般来说比较流行的是用 LinkedIn 提供的 Camus 来做从 Kafka 到 HDFS 的数据同步。这应该是一种较为流行的架 构。那么放到HDFS 上面的数据，基本上是为了批处理做准备的，那么在批处理分析的时候，我们选择一个什么样的分析引擎，可能就是一个值得争议的焦点，也就是说，也许在这个分析引擎的下面，有Hive， 有 Spark，有Presto，有Impala，还有其它的东西。 在这些引擎当中的选择或者实践，需要结合具体使用场景。 下面讲讲为什么会选择 Presto 而不是其它。假设在座的各位有Presto 使用经验的话，会发觉 Presto 它是一个 CLI 的用户界面，并没有好的一种Web UI，对一般用户来说，CLI 的使用会有难度，不管这是感觉上的还是实际上的，所以需要有个好的Web UI 来增加易用性。 当前在 GitHub 上面能找到的 Presto webui 的就是 Airbnb 提供的 AirPal，但根据我们的使用经验，不怎么友好，特别在 UTC 的时间设置上，同时它的社区维护已停滞在两年前，这一块我们做了适配，然后用Presto 的 StatementClient 做了 Web UI。前端采用的是jquery 的 easyui, 像刚才讲的批处理这一条线， 就是用在了批处理这一块上。下面这一条线就是说有些数据可能是希望立马存储，立即被搜索到，或者做 简要的分析。 作为搜索引擎，社区这一块，大家耳熟能详的应该是Elasticsearch，Elasticsearch 的社区非常活跃，而且它的推广速度，应用型上面易都很好。但是Elasticsearch 的难点在于如何对它进行好的维护，后面我 会讲到它可能存在的维护痛点。那么，Elasticsearch 有非常强大的搜索能力，响应时间也是非常快的，但是它的用户接口，有自己的一套基于 Lucene 的搜索语法，当然 Lucene 的这一套语法本身是非常极客的， 很简洁，但是一般的人不愿意去学这个东西，因为对于分析师来讲去学，就意味着以前的武功，几十年功 夫白费了。 于是我们就采用了一个插件 Elastisearch-SQL，这样就可以采用 SQL 语句对 Elasticsearch 进行点查询或者范围查询。而且在 Elasticsearch 的演进路径当中，也会支持 SQL，按照之前看到的 ES roadmap, 应该在 17 年最迟不超过 18 年发布 6.×，重要的特性之一是对 SQL 的支持，大家可以看到如果不支持 SQL，就等于是自废武功，或者拒客户于千里之外。 Web UI 是人机交互的部分，我们会进行Ad-hoc 查询，但在整个部门当中有不少程序希望调用查询，也就是应用的接口，采用 SOA 的架构，我们自己开发实现了 BigQuery API，可以通过这种调 Restful 接口方式，进行取数或者分析。那么我们会自动判别到底是到ES 这一侧还是到 Presto 进行取数。 在很多公司的使用当中，数据分析这一块是需要报表的，就是要有很好的Dashboard。 2、ETL PipeLine -- Gobblin 这个是 ETL 相对比较细节的一些东西。快速过一下这个图。在 ETL 的时间当中，比如说为什么不直接用像Spark 或者流的方式，最常见的问题就是小文件的问题，到时候需要清理合并小文件，这很麻烦。如果采用 Zeus 去调度，然后设定一定数目的Partition，就有一个 Map Task 对应，尽可能的