回覆列表
-
1 # 我給你的答案
-
2 # 盛昔霞724580
建議可以試試Hadoop了,幾十億的記錄灌到Oracle進行資料分析,還是會比較吃力的。如果用Oracle去做,經過精心設計可能也能吃得消(我沒試過)。但你這裡要對比一下業務資料庫的應用場景和使用者行為分析即日誌分析的差異。在日誌分析時,我們一般是把儘量多和全的資料採集為檔案記錄,然後方便做各種adhoc的分析,不管是單機也好,Hadoop也好,強調的是一個靈活。我們用Oracle做業務資料庫時,在設計理念上,會傾向於精簡的表結構獲取高效能,為了效能會做一些拆表或儘量減少欄位的記錄。這樣一方面是資訊不夠全,另一方面是表結構比較複雜。這樣在做資料分析時,光理解表結構都比較麻煩,特別是對業務人員來說。並且這樣導致分析性的需求強依賴業務資料庫。業務資料庫的變更,就會影響到分析類的支援。現在使用CDH或HDP搭建Hadoop已經是一個很簡單的事情,不妨自己動手搭建試試,反正不虧什麼。如果對自己公司業務發展有信心,用Hadoop是遲早的事。使用不使用Spark,我覺得主要取決於你是否有機器學習的需求,第一步我認為不著急。當然,Spark SQL在查詢效能上,比Hive更好一些。但是Hadoop生態更成熟。
1,預設情況下,oracle的日誌檔案記錄在$ORACLE/rdbms/log目錄下 [plain] view plaincopy [oracle@oracle log]$ pwd /home/oracle/oracle/product/10.2.0/db_1/rdbms/log 日誌檔案為(alert_<ORACLE_SID>.log): [plain] view plaincopy [oracle@oracle log]$ ll 總計 848 -rw-rw-r-- 1 aaa aaa 962 06-20 15:57 alert_TESTDB.log 2,如果不是在預設位置,則可透過sql查詢日誌檔案位置: [plain] view plaincopy SQL> show parameter dump_dest NAME TYPE ------------------------------------ ---------------------- VALUE ------------------------------ background_dump_dest string /home/oracle/oracle/admin/TESTDB/bdump core_dump_dest string /home/oracle/oracle/admin/TESTDB/cdump user_dump_dest string /home/oracle/oracle/admin/TESTDB/udump 其中background_dump_dest的value值即為日誌檔案存放位置