何謂五橫，基本還是根據(jù)數(shù)據(jù)的流向自底向上劃分五層，跟傳統(tǒng)的數(shù)據(jù)倉庫其實很類似，數(shù)據(jù)類的系統(tǒng)，概念上還是相通的，分別為數(shù)據(jù)采集層、數(shù)據(jù)處理層、數(shù)據(jù)分析層、數(shù)據(jù)訪問層及應(yīng)用層。同時，大數(shù)據(jù)平臺架構(gòu)跟傳統(tǒng)數(shù)據(jù)倉庫有一個不同，就是同一層次，為了滿足不同的場景，會采用更多的技術(shù)組件，體現(xiàn)百花齊放的特點，這是一個難點。
具體見下圖示例，這張圖是比較經(jīng)典的，也是妥協(xié)的結(jié)果，跟當(dāng)前網(wǎng)上很多的大數(shù)據(jù)架構(gòu)圖都可以作一定的映射。
數(shù)據(jù)采集層：既包括傳統(tǒng)的ETL離線采集、也有實時采集、互聯(lián)網(wǎng)爬蟲解析等等。
數(shù)據(jù)處理層：根據(jù)數(shù)據(jù)處理場景要求不同，可以劃分為HADOOP、MPP、流處理等等。
數(shù)據(jù)分析層：主要包含了分析引擎，比如數(shù)據(jù)挖掘、機器學(xué)習(xí)、 深度學(xué)習(xí)
數(shù)據(jù)訪問層：主要是實現(xiàn)讀寫分離，將偏向應(yīng)用的查詢等能力與計算能力剝離，包括實時查詢、多維查詢、常規(guī)查詢等應(yīng)用場景。
數(shù)據(jù)應(yīng)用層：根據(jù)企業(yè)的特點不同劃分不同類別的應(yīng)用，比如針對運營商，對內(nèi)有精準(zhǔn)營銷、客服投訴、基站分析等，對外有基于位置的客流、基于標(biāo)簽的廣告應(yīng)用等等。
數(shù)據(jù)管理層：這是一縱，主要是實現(xiàn)數(shù)據(jù)的管理和運維，它橫跨多層，實現(xiàn)統(tǒng)一管理。
邏輯上，一般都有數(shù)據(jù)采集層、數(shù)據(jù)存儲與分析層、數(shù)據(jù)共享層、數(shù)據(jù)應(yīng)用層，可能叫法有所不同，本質(zhì)上的角色都大同小異。
--------------------------------------------------
數(shù)據(jù)采集層：
實時采集現(xiàn)在也成了大數(shù)據(jù)平臺的標(biāo)配，估計主流就是FLUME+KAFKA，然后結(jié)合流處理+內(nèi)存數(shù)據(jù)庫吧，這個技術(shù)肯定靠譜，但這類開源的東西好是好，但一旦出現(xiàn)問題往往解決周期往往比較長。除了用FLUME，針對ORACLE數(shù)據(jù)庫的表為了實現(xiàn)實時采集，也可以采用OGG/DSG等技術(shù)實現(xiàn)實時的日志采集，可以解決傳統(tǒng)數(shù)據(jù)倉庫抽全量表的負(fù)荷問題。
企業(yè)級的爬蟲中心的建設(shè)難度蠻大，因為不僅僅是需要爬蟲，還需要建立網(wǎng)址和應(yīng)用知識庫，需要基于網(wǎng)頁文本進(jìn)行中文分詞，倒排序及文本挖掘等，這一套下來，挑戰(zhàn)很大，當(dāng)前已經(jīng)有不少開源組件了，比如solr、lucent、Nutch、ES等等，但要用好它，路漫漫其修遠(yuǎn)兮。
數(shù)據(jù)源的種類比較多：
作為互聯(lián)網(wǎng)行業(yè)，網(wǎng)站日志占的份額最大，網(wǎng)站日志存儲在多臺網(wǎng)站日志服務(wù)器上，一般是在每臺網(wǎng)站日志服務(wù)器上部署flume agent，實時的收集網(wǎng)站日志并存儲到HDFS上；
業(yè)務(wù)數(shù)據(jù)庫的種類也是多種多樣，有Mysql、Oracle、SqlServer等，這時候，我們迫切的需要一種能從各種數(shù)據(jù)庫中將數(shù)據(jù)同步到HDFS上的工具，Sqoop是一種，但是Sqoop太過繁重，而且不管數(shù)據(jù)量大小，都需要啟動MapReduce來執(zhí)行，而且需要Hadoop集群的每臺機器都能訪問業(yè)務(wù)數(shù)據(jù)庫；應(yīng)對此場景，淘寶開源的DataX，是一個很好的解決方案，有資源的話，可以基于DataX之上做二次開發(fā)，就能非常好的解決。當(dāng)然，F(xiàn)lume通過配置與開發(fā)，也可以實時的從數(shù)據(jù)庫中同步數(shù)據(jù)到HDFS。
有可能一些合作伙伴提供的數(shù)據(jù)，需要通過Ftp/Http等定時獲取，DataX也可以滿足該需求；
------------------------------
總得來講，建設(shè)大數(shù)據(jù)采集平臺非常不易，從客戶的角度講，至少要達(dá)到以下三個要求：
多樣化數(shù)據(jù)采集能力：支持對表、文件、消息等多種數(shù)據(jù)的實時增量數(shù)據(jù)采集（使用flume、消息隊列、OGG等技術(shù)）和批量數(shù)據(jù)分布式采集等能力（SQOOP、FTP VOER HDFS），比基于傳統(tǒng)ETL性能有量級上的提升，這是根本。
可視化快速配置能力：提供圖形化的開發(fā)和維護(hù)界面，支持圖形化拖拽式開發(fā)，免代碼編寫，降低采集難度，每配置一個數(shù)據(jù)接口耗時很短，以降低人工成本。
統(tǒng)一調(diào)度管控能力：實現(xiàn)采集任務(wù)的統(tǒng)一調(diào)度，可支持Hadoop的多種技術(shù)組件（如 MapReduce、Spark 、HIVE）、關(guān)系型數(shù)據(jù)庫存儲過程、 shell腳本等，支持多種調(diào)度策略（時間/接口通知/手工）。
-------------------------------
數(shù)據(jù)處理層
MPP應(yīng)該來說，是采用分布式架構(gòu)對于傳統(tǒng)數(shù)據(jù)倉庫最好的替代，畢竟其實際上是變了種的關(guān)系型數(shù)據(jù)庫，對于SQL提供完整支持，在HIVE做了轉(zhuǎn)化分析后，數(shù)據(jù)倉庫的融合建模用它來做性能綽綽有余，其性價比較傳統(tǒng)DB2更好一點，比如經(jīng)過實用，Gbase30-40臺集群就能超過2臺頂配的IBM 780。
MPP現(xiàn)在產(chǎn)品很多，很難做優(yōu)劣判斷，但一些實踐結(jié)果可以說下，GBASE不錯，公司很多系統(tǒng)已經(jīng)在上面跑了，主要還是國產(chǎn)的，技術(shù)服務(wù)保障相對靠譜，ASTER還有待觀望，自帶一些算法庫是有其一些優(yōu)勢，GreenPlum、Vertica沒用過，不好說。
-----------------------------------
只嘗試過STORM和IBM STREAM，推薦IBM STREAM，雖然是商業(yè)版本，但其處理能力超過STORM不是一點半點，據(jù)說STORM也基本不更新了，但其實數(shù)據(jù)量不大，用啥都可以，從應(yīng)用的角度講，諸如IBM這種商業(yè)版本，是不錯的選擇，支撐各類實時應(yīng)用場景綽綽有余。
流處理集群以流處理技術(shù)結(jié)合內(nèi)存數(shù)據(jù)庫，用以實時及準(zhǔn)實時數(shù)據(jù)處理，基于IBM Streams流處理集群承載公司的實時業(yè)務(wù)：
---------------------------------
數(shù)據(jù)開放層
HBASE很好用，基于列存儲，查詢速度毫秒級，對于一般的百億級的記錄查詢那也是能力杠杠的，具有一定的高可用性，我們生產(chǎn)上的詳單查詢、指標(biāo)庫查詢都是很好的應(yīng)用場景。但讀取數(shù)據(jù)方面只支持通過key或者key范圍讀取，因此要設(shè)計好rowkey。
---如何設(shè)計好HBASE RowKey？
Redis是K-V數(shù)據(jù)庫，讀寫速度比HBASE更快，大多時候，HBASE能做的，Redis也能做，但Redis是基于內(nèi)存的，主要用在key-value 的內(nèi)存緩存，有丟失數(shù)據(jù)的可能，當(dāng)前標(biāo)簽實時查詢會用到它，合作過的互聯(lián)網(wǎng)或廣告公司大多采用該技術(shù)，但如果數(shù)據(jù)越來越大，那么，HBASE估計就是唯一的選擇了？
另外已經(jīng)基于IMPALA提供互聯(lián)網(wǎng)日志的實時在線查詢應(yīng)用，也在嘗試在營銷平臺采用SQLFire和GemFire實現(xiàn)分布式的基于內(nèi)存的SQL關(guān)聯(lián)分析，雖然速度可以，但也是BUG多多，引入和改造的代價較大。
Kylin當(dāng)前算是基于hadoop/SPARK的多維分析的殺手級工具，應(yīng)用的場景非常多，希望有機會使用。
-------------------
數(shù)據(jù)應(yīng)用層
每個企業(yè)應(yīng)根據(jù)自己的實際規(guī)劃自己的應(yīng)用，其實搞應(yīng)用藍(lán)圖很難，大數(shù)據(jù)架構(gòu)越上層越不穩(wěn)定，因為變化太快，以下是運營商對外變現(xiàn)當(dāng)前階段還算通用的一張應(yīng)用規(guī)劃圖，供參考：
什么是Druid,Flink,phoenix,redis?
▲滴滴大數(shù)據(jù)體系架構(gòu)圖
▲知乎大數(shù)據(jù)平臺架構(gòu)圖
▲騰訊云大數(shù)據(jù)平臺架構(gòu)圖(EMR)
-----------------------------
什么是canal? Presto? Kylin?
數(shù)據(jù)開發(fā)的平臺，這張圖比較細(xì)，這是詳細(xì)的整體數(shù)據(jù)流架構(gòu)圖。包括最左邊是數(shù)據(jù)接入，上面是流式計算，然后是Hadoop離線計算。
將上圖左上角擴(kuò)大來看，首先是數(shù)據(jù)接入與流式計算，電商系統(tǒng)產(chǎn)生數(shù)據(jù)分兩個場景，一個是追加型的日志型數(shù)據(jù)，另外是關(guān)系型數(shù)據(jù)的維度數(shù)據(jù)。對于前一種是使用Flume比較標(biāo)準(zhǔn)化的大家都在用的日志收集系統(tǒng)，最近使用了阿里開源的Canal，之后有三個下游，所有的流式數(shù)據(jù)都是走Kafka這套流走的。
數(shù)據(jù)收集特性：
對于數(shù)據(jù)收集平臺，日志數(shù)據(jù)是多接口的，可以打到文件里觀察文件，也可以更新數(shù)據(jù)庫表。關(guān)系型數(shù)據(jù)庫是基于Binlog獲取增量的，如果做數(shù)據(jù)倉庫的話有大量的關(guān)系型數(shù)據(jù)庫，有一些變更沒法發(fā)現(xiàn)等情況，可以通過Binlog手段可以解決。通過一個Kafka消息隊列集中化分發(fā)支持下游，目前支持了850以上的日志類型，峰值每秒有百萬介入。
流式計算平臺特性：
構(gòu)建流式計算平臺的時候充分考慮了開發(fā)的復(fù)雜度，基于Storm。有一個在線的開發(fā)平臺，測試開發(fā)過程都在在線平臺上做，提供一個相當(dāng)于對Storm應(yīng)用場景的封裝，有一個拓?fù)溟_發(fā)框架，因為是流式計算，我們也做了延遲統(tǒng)計和報警，現(xiàn)在支持1100以上的實時拓?fù)?，秒級實時數(shù)據(jù)流延遲。
這幅圖是離線數(shù)據(jù)平臺的部署架構(gòu)圖，最下面是三個基礎(chǔ)服務(wù)，包括Yarn、HDFS、HiveMeta。不同的計算場景提供不同的計算引擎支持。如果是新建的公司，其實這里是有一些架構(gòu)選型的。Cloud Table是自己做的HBase分裝封口。我們使用Hive構(gòu)建數(shù)據(jù)倉庫，用Spark在數(shù)據(jù)挖掘和機器學(xué)習(xí)，Presto支持Adhoc上查詢，也可能寫一些復(fù)雜的SQL。對應(yīng)關(guān)系這里Presto沒有部署到Y(jié)arn，跟Yarn是同步的，Spark是on Yarn跑。
建設(shè)敏捷數(shù)據(jù)倉庫，除了對架構(gòu)技術(shù)上的要求之外，還有一個很重要的方面，就是數(shù)據(jù)建模，如果一上來就想著建立一套能兼容所有數(shù)據(jù)和業(yè)務(wù)的數(shù)據(jù)模型，那就又回到傳統(tǒng)數(shù)據(jù)倉庫的建設(shè)上了，很難滿足對業(yè)務(wù)變化的快速響應(yīng)。應(yīng)對這種情況，一般是先將核心的持久化的業(yè)務(wù)進(jìn)行深度建模（比如：基于網(wǎng)站日志建立的網(wǎng)站統(tǒng)計分析模型和用戶瀏覽軌跡模型；基于公司核心用戶數(shù)據(jù)建立的用戶模型），其它的業(yè)務(wù)一般都采用維度+寬表的方式來建立數(shù)據(jù)模型，這塊是后話。
這里的數(shù)據(jù)共享，其實指的是前面數(shù)據(jù)分析與計算后的結(jié)果存放的地方，其實就是關(guān)系型數(shù)據(jù)庫和NOSQL數(shù)據(jù)庫；
前面使用Hive、MR、Spark、SparkSQL分析和計算的結(jié)果，還是在HDFS上，但大多業(yè)務(wù)和應(yīng)用不可能直接從HDFS上獲取數(shù)據(jù)，那么就需要一個數(shù)據(jù)共享的地方，使得各業(yè)務(wù)和產(chǎn)品能方便的獲取數(shù)據(jù)；和數(shù)據(jù)采集層到HDFS剛好相反，這里需要一個從HDFS將數(shù)據(jù)同步至其他目標(biāo)數(shù)據(jù)源的工具，同樣，DataX也可以滿足。另外，一些實時計算的結(jié)果數(shù)據(jù)可能由實時計算模塊直接寫入數(shù)據(jù)共享。
即席查詢一般是通過SQL完成，最大的難度在于響應(yīng)速度上，使用Hive有點慢，可以用SparkSQL，它的響應(yīng)速度較Hive快很多，而且能很好的與Hive兼容。
實時計算：Storm在這塊是比較成熟了，但我選擇Spark Streaming，原因很簡單，不想多引入一個框架到平臺中，另外，Spark Streaming比Storm延時性高那么一點點，那對于我們的需要可以忽略。
我們目前使用Spark Streaming實現(xiàn)了實時的網(wǎng)站流量統(tǒng)計、實時的廣告效果統(tǒng)計兩塊功能。
做法也很簡單，由Flume在前端日志服務(wù)器上收集網(wǎng)站日志和廣告日志，實時的發(fā)送給Spark Streaming，由Spark Streaming完成統(tǒng)計，將數(shù)據(jù)存儲至Redis，業(yè)務(wù)通過訪問Redis實時獲取。
當(dāng)前，頭條每日處理數(shù)據(jù)量為 7.8 PB、訓(xùn)練樣本量 200 億條、服務(wù)器總量 40000 臺、Hadoop 節(jié)點 3000 臺。
數(shù)據(jù)生命周期分為生成、傳輸、入庫和統(tǒng)計/分析/挖掘，每個環(huán)節(jié)的難度都會隨著數(shù)據(jù)規(guī)模的變大而上升。平臺建設(shè)面臨的挑戰(zhàn)是由龐大的數(shù)據(jù)量和業(yè)務(wù)復(fù)雜度給數(shù)據(jù)生成、采集、傳輸、存儲和計算等帶來的一系列問題。
(1)數(shù)據(jù)生成與采集——SDK、用戶埋點
一般情況下，數(shù)據(jù)生成與采集是很簡單的事，但對于頭條這個功能眾多的 APP 來講，難點就在于每個功能背后都是一個團(tuán)隊獨立運營。如果每個團(tuán)隊都用自研的數(shù)據(jù)采集方法，那會給后續(xù)的進(jìn)程帶來巨大的困擾。
怎么辦呢?因為頭條屬于 C 端業(yè)務(wù)公司，主要以日志形式為主，數(shù)據(jù)的主要來源是用戶行為，那么就采用事件模型來描述日志，以 SDK 形式接入，支持客戶端、服務(wù)端埋點。
這里需要注意的是：數(shù)據(jù)質(zhì)量很重要，埋點規(guī)范趁早確立，臟數(shù)據(jù)是不可避免的，可以引入必要的約束、清洗等。
埋點的管理，也由通過文檔、Wiki 等方式演進(jìn)成埋點管理系統(tǒng)，覆蓋整個埋點生命周期。這樣一來，也得到了埋點元信息的描述，后續(xù)可應(yīng)用在數(shù)據(jù)清洗、分析平臺等場景，同時埋點的上線流程實現(xiàn)標(biāo)準(zhǔn)化，客戶端也可進(jìn)行自動化測試。
SDK。數(shù)據(jù)平臺實現(xiàn)了通用的客戶端埋點 SDK 和服務(wù)端埋點 SDK，放棄之前按約定生成數(shù)據(jù)的方式，可以保證生成的日志符合埋點規(guī)范，并統(tǒng)一 App 啟動、設(shè)備標(biāo)識等的基本口徑，也減少了新 App 適配成本。
對數(shù)據(jù)的描述由使用 JSON 改為 Protobuf，這樣就可通過 IDL 實現(xiàn)強制約束，包括數(shù)據(jù)類型、字段命名等。
除了日志數(shù)據(jù)，關(guān)系數(shù)據(jù)庫中的數(shù)據(jù)也是數(shù)據(jù)分析的重要來源。頭條在數(shù)據(jù)的采集方式上，用 Spark 實現(xiàn)類 Sqoop 的分布式抓取替代了早期定期用單機全量抓取 MySQL 數(shù)據(jù)表的方式，有效的提升了抓取速度，突破了單機瓶頸。
再之后為了減少 MySQL 壓力，選用 Canal 來接收 MySQL binlog，離線 merge 出全量表，這樣就不再直接讀 MySQL 了，而且對千萬/億級大表的處理速度也會更快。
(2)數(shù)據(jù)傳輸——Kafka 做消息總線連接在線和離線系統(tǒng)
數(shù)據(jù)在客戶端向服務(wù)端回傳或者直接在服務(wù)端產(chǎn)生時，可以認(rèn)為是在線狀態(tài)。當(dāng)數(shù)據(jù)落地到統(tǒng)計分析相關(guān)的基礎(chǔ)設(shè)施時，就變成離線的狀態(tài)了。在線系統(tǒng)和離線系統(tǒng)采用消息隊列來連接。
頭條的數(shù)據(jù)傳輸以 Kafka 作為數(shù)據(jù)總線，所有實時和離線數(shù)據(jù)的接入都要通過 Kafka，包括日志、binlog 等。這里值得注意的是：盡早引入消息隊列，與業(yè)務(wù)系統(tǒng)解耦。
頭條的數(shù)據(jù)基礎(chǔ)設(shè)施以社區(qū)開源版本作為基礎(chǔ)，并做了大量的改進(jìn)，也回饋給了社區(qū)，同時還有很多自研的組件。
因為以目前的數(shù)據(jù)和集群規(guī)模，直接使用社區(qū)版本乃至企業(yè)版的產(chǎn)品，都會遇到大量困難。像數(shù)據(jù)接入，就使用自研 Databus，作為單機 Agent，封裝 Kafka 寫入，提供異步寫入、buffer、統(tǒng)一配置等 feature。
Kafka 數(shù)據(jù)通過 Dump 落地到 HDFS，供后續(xù)離線處理使用。隨著數(shù)據(jù)規(guī)模的增加，Dump 的實現(xiàn)也經(jīng)歷了幾個階段。最初實現(xiàn)用的是類似 Flume 模式的單機上傳，很快遇到了瓶頸，實現(xiàn)改成了通過 Storm 來實現(xiàn)多機分布式的上傳，支持的數(shù)據(jù)吞吐量大幅增加。
現(xiàn)在開發(fā)了一個叫 DumpService 的服務(wù)，作為托管服務(wù)方便整合到平臺工具上，底層實現(xiàn)切換到了 SparkStreaming，并實現(xiàn)了 exactly-once 語義，保證 Dump 數(shù)據(jù)不丟不重。
(3)數(shù)據(jù)入庫——數(shù)據(jù)倉庫、ETL(抽取轉(zhuǎn)換加載)
頭條的數(shù)據(jù)源很復(fù)雜，直接拿來做分析并不方便。但是到數(shù)據(jù)倉庫這一層級，會通過數(shù)據(jù)處理的過程，也就是 ETL，把它建設(shè)成一個層次完備的適合分析的一個個有價值的數(shù)倉。在數(shù)倉之上，就可以讓數(shù)據(jù)分析師和數(shù)據(jù) RD 通過 SQL 和多維分析等更高效的手段使用數(shù)據(jù)。
數(shù)據(jù)倉庫中數(shù)據(jù)表的元信息都放在 Hivemetastore 里，數(shù)據(jù)表在 HDFS 上的存儲格式以 Parquet 為主，這是一種列式存儲格式，對于嵌套數(shù)據(jù)結(jié)構(gòu)的支持也很好。
頭條有多種 ETL 的實現(xiàn)模式在并存，對于底層數(shù)據(jù)構(gòu)建，一種選擇是使用 Python 通過 HadoopStreaming 來實現(xiàn) Map Reduce 的任務(wù)，但現(xiàn)在更傾向于使用 Spark 直接生成 Parquet 數(shù)據(jù)，Spark 相比 MapReduce 有更豐富的處理原語，代碼實現(xiàn)可以更簡潔，也減少了中間數(shù)據(jù)的落地量。對于高層次的數(shù)據(jù)表，會直接使用 HiveSQL 來描述 ETL 過程。
(4)數(shù)據(jù)計算——計算引擎的演進(jìn)
數(shù)據(jù)倉庫中的數(shù)據(jù)表如何能被高效的查詢很關(guān)鍵，因為這會直接關(guān)系到數(shù)據(jù)分析的效率。常見的查詢引擎可以歸到三個模式中，Batch 類、MPP 類、Cube 類，頭條在 3 種模式上都有所應(yīng)用。
頭條最早使用的查詢引擎是 InfoBright，Infopight 可以認(rèn)為是支持了列式存儲的 MySQL，對分析類查詢更友好，但 Infopight 只支持單機。隨著數(shù)據(jù)量的增加，很快換成了 Hive，Hive 是一個很穩(wěn)定的選擇，但速度一般。
為了更好的支持 Adhoc 交互式查詢，頭條開始調(diào)研 MPP 類查詢引擎，先后使用過 Impala 和 Presto，但在頭條的數(shù)據(jù)量級下都遇到了穩(wěn)定性的問題。
頭條現(xiàn)在的方案是混合使用 Spark SQL 和 Hive，并自研 QAP 查詢分析系統(tǒng)，自動分析并分發(fā)查詢 SQL 到適合的查詢引擎。在 Cube 類查詢引擎上，頭條采用了 Kylin，現(xiàn)在也是Kylin 在國內(nèi)最大的用戶之一。
(5)數(shù)據(jù)門戶——為業(yè)務(wù)的數(shù)據(jù)分析提供整體解決方案
對于大部分需求相對簡單的公司來說，數(shù)據(jù)最終可以產(chǎn)出報表就夠用了，如做一個面向管理層的報表，可以讓老板直觀的了解一些關(guān)鍵性指標(biāo)，這是最基礎(chǔ)的數(shù)據(jù)應(yīng)用模式。
再深入一點，就需要匯總各種來源的業(yè)務(wù)數(shù)據(jù)，提供多種維度和指標(biāo)來進(jìn)行更深入的探索型分析，得到的結(jié)論用來指導(dǎo)產(chǎn)品的迭代和運營。頭條絕大部分業(yè)務(wù)都是數(shù)據(jù)驅(qū)動的，都需要產(chǎn)出和分析大量的數(shù)據(jù)，這就或多或少需要用到平臺提供的系列工具。
頭條開發(fā)了一套叫數(shù)據(jù)門戶的平臺系統(tǒng)，提供給業(yè)務(wù)部門使用，對數(shù)據(jù)生命周期各個環(huán)節(jié)都提供了相應(yīng)支持。數(shù)據(jù)門戶提供的工具都是聲明式的，也就是讓使用者只需要說明要實現(xiàn)什么目的，具體實現(xiàn)的復(fù)雜細(xì)節(jié)都隱藏起來，對使用者更友好。
通過這些工具，可以讓業(yè)務(wù)部門的 RD 、分析師、PM 等將精力放在業(yè)務(wù)分析本身，而不是去學(xué)習(xí)大量數(shù)據(jù)基礎(chǔ)設(shè)施的使用方法。
聯(lián)系客服
